Off-chain anonymous transactions by secure transfer of private keys - page 6.

gmaxwell

staff

Activity: 4242

Merit: 8672

Quote from: piotr_n on October 30, 2013, 02:31:48 PM

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

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

legendary

Activity: 2053

Merit: 1356

aka tonikt

Quote from: Crowex on October 30, 2013, 02:32:19 PM

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.

Crowex

member

Activity: 111

Merit: 10

Quote from: drazvan on October 30, 2013, 02:07:42 PM

Quote from: gmaxwell on October 30, 2013, 02:03:11 PM

Quote from: Crowex on October 30, 2013, 02:00:14 PM

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

legendary

Activity: 2053

Merit: 1356

aka tonikt

Quote from: gmaxwell on October 30, 2013, 02:29:38 PM

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 Wink

gmaxwell

staff

Activity: 4242

Merit: 8672

Quote from: piotr_n on October 30, 2013, 02:25:21 PM

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

legendary

Activity: 2053

Merit: 1356

aka tonikt

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

staff

Activity: 4242

Merit: 8672

Quote from: piotr_n on October 30, 2013, 02:19:31 PM

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

legendary

Activity: 2053

Merit: 1356

aka tonikt

Quote from: drazvan on October 30, 2013, 02:13:22 PM

Quote from: piotr_n on October 30, 2013, 02:07:50 PM

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.

drazvan

full member

Activity: 191

Merit: 100

Quote from: piotr_n on October 30, 2013, 02:07:50 PM

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

legendary

Activity: 2053

Merit: 1356

aka tonikt

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

full member

Activity: 191

Merit: 100

Quote from: gmaxwell on October 30, 2013, 02:03:11 PM

Quote from: Crowex on October 30, 2013, 02:00:14 PM

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.

drazvan

full member

Activity: 191

Merit: 100

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 with corresponding has been transferred via an encrypted channel to with a random nonce of ", 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.

gmaxwell

staff

Activity: 4242

Merit: 8672

Quote from: Crowex on October 30, 2013, 02:00:14 PM

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.

Crowex

member

Activity: 111

Merit: 10

Quote from: gmaxwell on October 30, 2013, 01:41:15 PM

Quote from: Crowex on October 30, 2013, 01:38:34 PM

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

staff

Activity: 4242

Merit: 8672

Quote from: Crowex on October 30, 2013, 01:38:34 PM

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.

Crowex

member

Activity: 111

Merit: 10

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

piotr_n

legendary

Activity: 2053

Merit: 1356

aka tonikt

Cool - thanks for explaining.

So REVEAL removes the Bitcoin from the card's balance storage, though keeps it in the card's NVM, encrypted with the recipient's RSA.
The recipient can request this RSA encrypted key as many times, as it wants - until it gives the REMOVE command, which essentially frees the memory in card A.

Yeah, I like this idea.
And sorry for not reading through carefully, at the first time, asking these questions instead.

But it's all clear now and I like it - I think it can work.

drazvan

full member

Activity: 191

Merit: 100

Piotr, the way it works is that there are two separate operations. The first one (called REVEAL) takes the Bitcoin private key out of the secure storage, encrypts it with the RSA-2048 public key of the recipient, then moves it to a public buffer (no longer in secure storage) that the wallet can read it from as many times as it wants. Once the wallet has successfully forwarded that encrypted key to the other end, it issues a second command called REMOVE that clears the public buffer. The Bitcoin private key is erased from secure storage as soon as REVEAL is called, but it is still available in its encrypted form (decryptable only by the recipient) in the public buffer until REMOVE is called.

So in the case of a communication breakdown, the sender can keep reading it from the buffer (or just cache it internally since it's encrypted) and retry sending it to the recipient that is now the only entity capable of recovering that Bitcoin private key.

The scheme also does replay protection by using a nonce sent together with the RSA public key (preventing you from resending an old recorded payment message to a recipient to convince him to reimport the key into its private storage).

piotr_n

legendary

Activity: 2053

Merit: 1356

aka tonikt

Quote from: drazvan on October 30, 2013, 07:31:26 AM

Piotr_n, there is no private key that all the cards share. They all share the public key of the issuer in order to be able to verify other cards and ensure that the Bitcoin private keys are only transferred to cards issued with the same restrictions and running the same software.

Each card comes with its own "device key" (I think this is called an "endorsement key" in TPM world - see http://en.wikipedia.org/wiki/Trusted_Platform_Module ). The root private key (used to sign the endorsement keys) is definitely not present on any of the cards.

Oh, OK.
So each card would have a unique private key and its corresponding public key, that would be signed by the issuing authority?

Now it starts making much more sense.
This can indeed work - as long as the private key used to sign the public keys of the cards they manufacture does not leak out of the authority.
Which is again: usually only a matter of time and money...

But OK - let's assume that it won't leak out.

In such case I have another concern.
From what I understand moving bitcoins from one card to another means sending the key from card A to B - storing it in card B, while destroying it in card A.
But is there some reliable method to avoid destroying the key in A too soon, or too late?
If you destroy it too soon, the coins will get lost - if you do it too late, you might end up with the same key being owned by two cards.

drazvan

full member

Activity: 191

Merit: 100

Quote from: gmaxwell on October 29, 2013, 08:55:25 PM

Thats kinda bad for privacy. You could use a cryptographically secure bloom filter to improve privacy, but it's probably asking too much for your CPU power.

Interesting, done right you could probably make it so your alert mechnism wrote a cryptographic proof that could be showed to other people.

That's actually the plan, but we need to make sure that the person reporting the hack is not the person that has actually hacked the card. If we have a physically intact card that contains a private key that we've seen a spend operation for on the blockchain and the card can keep track of the previous owners of that private key, it can be asked to reveal that chain of previous owners. If two or more physically and logically intact OtherCoins report this, we can compare the chains and find the actual card that has performed the double spend.

The wallet will most probably employ Bloom filters to monitor the blockchain - but most wallets already do that, don't they? The wallet knows the public keys / addresses to look for and it's up to it to fine tune the Bloom filter to not reveal the exact addresses it's looking at. I wouldn't want to implement that on the smartcard.

Topic: Off-chain anonymous transactions by secure transfer of private keys - page 6. (Read 17282 times)