Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Offline merchant payments #2

Open
emschwartz opened this issue Mar 9, 2017 · 4 comments
Open

Offline merchant payments #2

emschwartz opened this issue Mar 9, 2017 · 4 comments

Comments

@emschwartz
Copy link
Collaborator

emschwartz commented Mar 9, 2017

From Security Issue #2:

A provider that stores a list of thrusted Ledgers, and can be stored offline for efficieny as well. Once a tapFi is detected and selected to pay, it's bank signature will be verified with it's own provider, and decide to accept the payment based on the whitelist/blacklist of keys.

The merchant needs to trust both the ledger, the tapFi hardware manufacturer, and the particular tapFi device. This suggests the tapFi device will need to have a key embedded by the manufacturer that is signed by both the manufacturer and the ledger, and the tapFi should store the certificates of both the ledger and manufacturer.

For blacklisting compromised devices, @justmoon suggested using a Bloom Filter that could be maintained by some data provider and merchants could subscribe to receive regular updates.

@ivanseidel
Copy link
Collaborator

The Bloom Filter looks like a good idea indeed!

About thrusting the Hardware manufacturer, that might not be needed.

The hardware can generate it's own private/public key. The bank will just sign it's public key with with expiration and max-spending cost, and allow the ledger to verify it's identity by it using it's own public-key.

The merchant, would then use the signature from the Bank given to the tapFi to trust payments. That way, we don't have to store tapFi's information on the Store, neither manufacturer.

What do you think?

@emschwartz
Copy link
Collaborator Author

Banks would not want to sign the public key of a device that's trivial to tamper with. You need assurance from the hardware manufacturer that the device will not spend more offline than it's supposed to AND that the user can't just open the device and disable that check.

@ivanseidel
Copy link
Collaborator

ivanseidel commented Mar 9, 2017

That makes sense.. so, why not validating that on the Ledger during the sign of the key of the tapFi? Then, only banks would need to know about the Hardware's.

Pros are:

  • Store wouldn't be able to avoid payments from specific tapFi brands
  • If the bank doesn't trust a tapFi hardware, it won't sign a key for it, and will not be able to provide proof that the bank issued it. (No need for the store to store hardware related information)

@dappelt
Copy link
Collaborator

dappelt commented Mar 13, 2017

I think the following information should be signed by the ledger owner (i.e. your bank) and stored in a TapFI:

  1. User X has an account on ledger L.
  2. User X has an allowance of Y ledger units. A ledger unit is the currency in which the ledger is denominated.
  3. The public key PK of user X. This is used to establish an authenticated and confidential communication channel with the merchant terminal.

In this scenario, we assume the private key can not be extracted from the tapfi, even if an attacker has physical access to the device. If the device would be handed out by the ledger owner, he would only hand out such devices that he trusts to be tamper-resistant (this would address Evan's comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants