Off-chain anonymous transactions by secure transfer of private keys

[Crowex]

What is the protocol to establish an authenticated and encrypted channel between the smart cards that is resistant to MITM attacks?

Presumably the cards must present a certificate signed by a trusted (by the card) authority.

No trusted third party server – information is secured by each smartcard, there is no central server to be trusted with transaction details or that the system depends on for its operation.

[gmaxwell]

No trusted third party server – information is secured by each smartcard, there is no central server to be trusted with transaction details or that the system depends on for its operation.

A third party certificate authority which certifies the cards as being ones that will respect the anti-doublespending requirement.

Otherwise I just load one of these keys onto a fake card which double spends it. The tamper-resistance only matters if you actually can tell that you're talking to one of these tamper resistant cards.

[drazvan]

Exactly. The recipient of the funds presents his signed RSA-2048 key signed by the issuer (us) and a nonce. The sender verifies the signature (to ensure that it comes from a trusted card), then uses its own RSA key to sign a message containing the Bitcoin private key + Bitcoin public key concatenated with the nonce and the destination address, then encrypts the message with the recipient public key and sends the encrypted data together with its own signed public key to the wallet.

So it basically signs a message saying "I hereby certify that the key <BITCOIN_PRIVATE_KEY> with corresponding <BITCOIN_PUBLIC_KEY> has been transferred via an encrypted channel to <RSA_DESTINATION_KEY> with a random nonce of <NONCE>", encrypts it and sends it over to the other side.

The recipient checks the certificate of the sender, then decrypts the message, compares the nonce to the one it has sent out (to prevent replay attacks), compares the destination address to its own (to prevent replays of messages sent to someone else), compares the public key with the one it computes locally from the private key, verifies the signature, then stores the key into its private storage.

I'm aware that there is a lot of redundancy in there (the Bitcoin public key can always be computed from the private key), but it helps keep parties honest.

[drazvan]

No trusted third party server – information is secured by each smartcard, there is no central server to be trusted with transaction details or that the system depends on for its operation.

A third party certificate authority which certifies the cards as being ones that will respect the anti-doublespending requirement.

Otherwise I just load one of these keys onto a fake card which double spends it. The tamper-resistance only matters if you actually can tell that you're talking to one of these tamper resistant cards.

Correct, the only time the issuer is involved is at manufacture time when the RSA keys identifying each card are securely generated on-card and stored, then their corresponding public keys are signed by the issuer and the certificates are also stored by the card to be presented to other cards.

Just as gmaxwell said, each card needs to make sure that it's talking to a similar card, not to a generic chip with fake RSA keys on it.

[piotr_n]

But how do you see the accounting part?
If the only thing the card can transfer is a Bitcoin private key, then it should be somehow known how many coins are there, behind this private key..
How do you see this?

[drazvan]

But how do you see the accounting part?
If the only thing the card can transfer is a Bitcoin private key, then it should be somehow known how many coins are there, behind this private key..
How do you see this?

That's the beauty of it... it doesn't ... the card never knows anything about Bitcoins or balances or anything like that. That's the job of the wallet running on your smartphone or whatever you have the OtherCoin card inserted into. The wallet acts like any other "watching" wallet, it can monitor balances, etc. It's only when it tries to pay from that address that it needs the private key - and it can either ask the card for it (in which case it's removed from secure storage and the wallet just uses it on the Bitcoin network) or it can ask the card to securely send it to the recipient's card (in which case it is encrypted with the recipient's RSA key and given to the wallet in encrypted form to be sent to the other end).

The card cannot sign Bitcoin transactions and only acts as a very "stubborn" Bitcoin key generator - you can ask it to generate a key, it will give you the corresponding public key but keep the private key secure, allowing you to do anything other than transfer the funds away. It's the wallet's job to monitor the blockchain, establish balances and communicate to the recipient (since the card has no communication capabilities other than its physical interface to the smartphone using the microSD slot).

[piotr_n]

But how do you see the accounting part?
If the only thing the card can transfer is a Bitcoin private key, then it should be somehow known how many coins are there, behind this private key..
How do you see this?

That's the beauty of it... it doesn't ... the card never knows anything about Bitcoins or balances or anything like that. That's the job of the wallet running on your smartphone or whatever you have the OtherCoin card inserted into. The wallet acts like any other "watching" wallet, it can monitor balances, etc. It's only when it tries to pay from that address that it needs the private key - and it can either ask the card for it (in which case it's removed from secure storage and the wallet just uses it on the Bitcoin network) or it can ask the card to securely send it to the recipient's card (in which case it is encrypted with the recipient's RSA key and given to the wallet in encrypted form to be sent to the other end).

The card cannot sign Bitcoin transactions and only acts as a very "stubborn" Bitcoin key generator - you can ask it to generate a key, it will give you the corresponding public key but keep the private key secure, allowing you to do anything other than transfer the funds away. It's the wallet's job to monitor the blockchain, establish balances and communicate to the recipient (since the card has communication capabilities other than its physical interface to the smartphone using the microSD slot).

I am thinking whether it would be possible to use such a card for offline transactions.
I mean, if you arm it with private keys that have access to some predefined amount of coins (e.g. 0.1 BTC each) - then you could essentially trade such a credits offline.

[gmaxwell]

I am thinking whether it would be possible to use such a card for offline transactions.
I mean, if you arm it with private keys that have access to some predefined amount of coins (e.g. 0.1 BTC) - then you could essentially trade such a credits offline.

Right, so what you need to do is have a snapshot of pre-existing coins that are in circulation in this system. Today you could accomplish that with just a copy of the utxo set. (e.g. only about 250 mbytes of data)

Another alternative, if the device knows what the address of its private key is... is that it can give you SPV fragments to show that key being paid... and then you only have to have (possibly somewhat old) block headers, to verify the amount.

There is some online preparation, but the actual payments can be offline.

[piotr_n]

Yeah.
If you assume a trust in the authority that made the card, then you can as well ask the card itself how many coins are covered by a private key it gives you.
it should give you the info signed with its private key, that is signed with the authority's private key - so it's all about the trust to the authority and you can move coins offline.

It's a brilliant idea, @drazvan

[gmaxwell]

Yeah.
If you assume a trust in the authority that made the card, then you can as well ask the card itself how many coins are covered by a private key it gives you.
it should give you the info signed with its private key, that is signed with the authority private key - so it's all about the trust to the authority and you can move coins offline.

One possibility though is making so that the authority doesn't have to fill it.   Card generates a private key, and then won't let you do anything with it until you provide the card with SPV proof (e.g. txn, fragment and 200 blocks of some suitable minimum difficulty) that the private key it generated has been paid.

[piotr_n]

Card generates a private key, and then won't let you do anything with it until you provide the card with SPV proof (e.g. txn, fragment and 200 blocks of some suitable minimum difficulty) that the private key it generated has been paid.

And then you can pop it up later, after it has already left the factory...

Seems like we're creating history here

[Crowex]

No trusted third party server – information is secured by each smartcard, there is no central server to be trusted with transaction details or that the system depends on for its operation.

A third party certificate authority which certifies the cards as being ones that will respect the anti-doublespending requirement.

Otherwise I just load one of these keys onto a fake card which double spends it. The tamper-resistance only matters if you actually can tell that you're talking to one of these tamper resistant cards.

Correct, the only time the issuer is involved is at manufacture time when the RSA keys identifying each card are securely generated on-card and stored, then their corresponding public keys are signed by the issuer and the certificates are also stored by the card to be presented to other cards.

Just as gmaxwell said, each card needs to make sure that it's talking to a similar card, not to a generic chip with fake RSA keys on it.

So if someone brings out a new card after my card was issued and I haven't got the certificate for this new card stored on my card, then what is the protocol to establish authenticity and encryption?

[piotr_n]

So if someone brings out a new card after my card was issued and I haven't got the certificate for this new card stored on my card, then what is the protocol to establish authenticity and encryption?

If I might answer, since I think I already understand...

There is one master key - and its private part is kept by the issuing authority.
This key never changes and its public part is known to everyone.

You talking to a new card, just verify if the public RSA key the card gives you is signed with the authority's master key.
If it is - you assume the card is legit and anything it tells you is backed by the authority.

Since it isn't easy to hack a card, each time such an event would happen, its unique (though signed by the authority) key can be published and added to the blacklist - and the public blacklist would be updated from time to time by any party who would like to accept such a cards, thus minimizing the loses and discouraging the hackers.

[gmaxwell]

And then you can pop it up later, after it has already left the factory...
Seems like we're creating history here

Well, keep your enthusiasm bounded: This is strictly less secure than Bitcoin itself. If someone compromises a single card then the whole infrastructure is busted: Everyone becomes potentially vulnerable to double spending by an evil device which has seen the private keys they're holding, so they'd have to go redeem their coins on the network and pay them into new, hopefully more secure, cards.

It's a absolutely fantastic trade-off though: the reduction in security comes with privacy and convenience improvements. Even online, its useful for allowing instant transactions.

I'll make the idea even stronger:  Once you support in-field loading, it should be possible to "refresh" the coins on the card by spending them and doing a new in-field load.  If you successfully do that the coins you have refreshed are protected from double-spending by earlier holders.

Periodic refreshing would prevent a situation where someone runs a "spy card" that remembers a lot of private keys and does a lot of transactions and then suddenly one day captures up all the non-redeemed coins on the keys they've seen.

[piotr_n]

And then you can pop it up later, after it has already left the factory...
Seems like we're creating history here

Well, keep your enthusiasm bounded: This is strictly less secure than Bitcoin itself. If someone compromises a single card then the whole infrastructure is busted: Everyone becomes potentially vulnerable to double spending by an evil device which has seen the private keys they're holding, so they'd have to go redeem their coins on the network and pay them into new, hopefully more secure, cards.

Of course. But I believe we are rather talking about small payments here.
It obviously shall not be used for million dollar payments, but can be very handy for tens of dollars payment - hacking a smart card for such a small amounts is just unprofitable.

[drazvan]

Yeah.
If you assume a trust in the authority that made the card, then you can as well ask the card itself how many coins are covered by a private key it gives you.
it should give you the info signed with its private key, that is signed with the authority private key - so it's all about the trust to the authority and you can move coins offline.

One possibility though is making so that the authority doesn't have to fill it.   Card generates a private key, and then won't let you do anything with it until you provide the card with SPV proof (e.g. txn, fragment and 200 blocks of some suitable minimum difficulty) that the private key it generated has been paid.

In the current implementation, the card does not know anything about Bitcoin balances (it cannot parse transactions or do anything Bitcoin-related). It doesn't even know the actual address you're going to use (since that is always the sum of 2 public addresses - one that it generates and another one that the wallet generates).

However, the wallet holding the OtherCoin card does know the address, so part of the protocol could be demonstrating to the other wallet (not the card) that the funds are there. This could be done completely outside the smartcard - a wallet to wallet transfer of transaction data to prove that a certain output has a certain value, just like gmaxwell suggested. I really like that idea!

[piotr_n]

So you already have an implementation?
Good for you, man!

If you need developers experienced in both; bitcoin and smartcards, let me know
It all can be done - the hardest part IMO is to find an authority that this community would trust.
Normally banks do it - but these people in here are all about not trusting banks

[Crowex]

So if someone brings out a new card after my card was issued and I haven't got the certificate for this new card stored on my card, then what is the protocol to establish authenticity and encryption?

If I might answer, since I think I already understand...

There is one master key - and its private part is kept by the issuing authority.
This key never changes and its public part is known to everyone.

You talking to a new card, just verify if the public RSA key the card gives you is signed with the authority's master key.
If it is - you assume the card is legit and anything it tells you is backed by the authority.

Since it isn't easy to hack a card, each time such an event would happen, it's unique (though signed by the authority) key can be published and added to the blacklist - and the public blacklist would be updated from time to time by any party who would like to accept such a cards, thus minimizing the loses and discouraging the hackers.

ok, thanks, I didn't understand that part of it

[drazvan]

So you already have an implementation?
Good for you, man!

If you need developers experienced in both; bitcoin and smartcards, let me know
It all can be done - the hardest part IMO is to find an authority that this community would trust.
Normally banks do it - but these people in here are all about not trusting banks

Most of the smartcard code is complete, yes (I would say around 80% of it). There's no code on the wallet side yet, I want to complete the smartcard part and freeze the functionality before I move on to the wallet side. I'm in the process of trying to raise some seed funds to allow me to work on this full time (getting it to this point took about 3 months of me working weekends and in-between other projects).

About the issuing authority, I mentioned a bit earlier that I intend to have multiple authorities/issuers certifying cards. The code cannot be open-sourced due to the NDA restrictions put in place by the hardware manufacturers (if you've worked with NXP before you know what I mean ), but I guess we can always share information and source with a third party / issuer if they are also under an NDA.

I could use some help with the development, just need to figure out the financials first, doing this part-time is annoyingly slow.

[wiggi]

Is the tamper-resistance mostly hardware related, i.e. which of these 2 things
- read raw memory data from card and disassemble the chip, comprehend how the chip works and emulate it in software
and
- hack the resulting (probably still encrypted and highly obfuscated) executable
would be more difficult for the attacker?

In other words, I wonder if a pure software implementation of OtherCoin is possible (in principle).