[ESHOP launched] Trezor: Bitcoin hardware wallet

[mila]

One more comment: If I understand this correctly, the Trezor use case for signing transaction never reuses adresses. If k=1 was used all the time, only the private keys of the dead address will be revealed. There is still no known way to steal your BTC in this scenario.

iirc knowledge of any deterministic private key compromises whole seed, all addresses

http://satoshilabs.com/news/2013-10-31-celebrate-day-of-bitcoin-with-trezor/#more-206
will you update the number of stolen or lost coins?

[1714685225]

1714685225

[1714685225]

1714685225

[1714685225]

1714685225

[BurtW]

iirc knowledge of any deterministic private key compromises whole seed, all addresses

You might need two.

[stick]

I have a question (to devs or anyone else):

I read trezor uses RFC6979 deterministic ecdsa signatures to prevent leaking of seed or any other private data through the "random" number used in non-deterministic signatures. I read that here

Is there an easy way to check wether this is true by looking at a transaction signed by trezor?

You can easily see that the signatures produced by TREZOR are deterministic, because they produce same result for same combination of private key/message (that's what we use in unit testing afterall ...)

I am not sure if BitcoinJ uses deterministic signatures by default and if they use the same pseudorandom function as described in RFC6979, but if both are true you can try importing TREZOR's seed into Wallet32 and see if they produce the same signatures for the same combination of privkey/message.

[ticoti]

is this already launched?
what's the price?

[stick]

is this already launched?
what's the price?

It will be launched in July. Price will be announced then.

[klokan]

iirc knowledge of any deterministic private key compromises whole seed, all addresses

The seed is "compromised" in a sense that some information about it is revealed. But the seed is not revealed itself. That is the whole reason to use HMAC in keys derivation. There is no known method to derive other siblink private keys in the deterministic wallets, i.e. no way to steal BTC. You can derive children nodes in the hierarchy, but those are not used for anything.

[kkurtmann]

is this already launched?
what's the price?

It will be launched in July. Price will be announced then.

so... 3 to 7 weeks. Good news everyone!

[molecular]

  The answer to your question is NO. There is no simple way to chech this. There is a difficult way to test that in your particular test scenario RFC6979 is used.

One more comment: If I understand this correctly, the Trezor use case for signing transaction never reuses adresses. If k=1 was used all the time, only the private keys of the dead address will be revealed. There is still no known way to steal your BTC in this scenario. So the RFC6979 is good to have, but you are safe even without it.

Please correct me if I'm wrong.

I think you're wrong: the idea could be for the trezor devs to use k = <seed XOR some secret> in order to leak the seeds of people to the blockchain, visible only to them, of course.

It's a potential attack by the trezor devs, not just anyone.

[molecular]

I have a question (to devs or anyone else):

I read trezor uses RFC6979 deterministic ecdsa signatures to prevent leaking of seed or any other private data through the "random" number used in non-deterministic signatures. I read that here

Is there an easy way to check wether this is true by looking at a transaction signed by trezor?

I am not sure if BitcoinJ uses deterministic signatures by default and if they use the same pseudorandom function as described in RFC6979, but if both are true you can try importing TREZOR's seed into Wallet32 and see if they produce the same signatures for the same combination of privkey/message.

Thanks, stick, for that description / suggestion. I will try this once I get my plastic trezors (I have my metal one in "productive" use now and don't want to fiddle with it).

You can easily see that the signatures produced by TREZOR are deterministic, because they produce same result for same combination of private key/message (that's what we use in unit testing afterall ...)

Seeing they are deterministic isn't an indication against you potentially leeking seeds through the k value, is it? Even if you leaked seeds like that, signatures could still be deterministic.

Btw: thanks again for an awesome product, I can't wait to give some plastics away to friends, who I can then finally offer a good method to store their BTC.

[stick]

Seeing they are deterministic isn't an indication against you potentially leeking seeds through the k value, is it? Even if you leaked seeds like that, signatures could still be deterministic.

Right. That's why I continued with the comment and suggested the check against other BIP39+BIP44+RFC6979 implementations (which currently might be just Wallet32 or at least very close to it).

[molecular]

Seeing they are deterministic isn't an indication against you potentially leeking seeds through the k value, is it? Even if you leaked seeds like that, signatures could still be deterministic.

Right. That's why I continued with the comment and suggested the check against other BIP39+BIP44+RFC6979 implementations (which currently might be just Wallet32 or at least very close to it).

Yes, and that's why I thanked you for your suggestion .

I had noticed that the potential attack I was talking about was misunderstood by some. Sorry for repeating myself and reordering your answers.

BTW: Don't you need some sleep? You've been up until at least 3 last night and going at it again already? Well, good morning

[stick]

BTW: Don't you need some sleep? You've been up until at least 3 last night and going at it again already? Well, good morning

Haha, good point!

[macaron]

Looking forward to it's release! Hope this will change bitcoin security

[xeroc]

Looking forward to it's release! Hope this will change bitcoin security

It will/does not change bitcoin security .. its just a way to store your money securely

[klokan]

  The answer to your question is NO. There is no simple way to chech this. There is a difficult way to test that in your particular test scenario RFC6979 is used.

One more comment: If I understand this correctly, the Trezor use case for signing transaction never reuses adresses. If k=1 was used all the time, only the private keys of the dead address will be revealed. There is still no known way to steal your BTC in this scenario. So the RFC6979 is good to have, but you are safe even without it.

Please correct me if I'm wrong.

I think you're wrong: the idea could be for the trezor devs to use k = <seed XOR some secret> in order to leak the seeds of people to the blockchain, visible only to them, of course.

It's a potential attack by the trezor devs, not just anyone.

There are million of ways how wallet devs (including trezor devs) can leak your seed. Some quick ideas:

1. Use above when the amount is above 10BTC (you don't care about poor guys anyway).
2. Use only last 16bits of RFC6979 and xor this with seed. This way k is still deterministic, but easy to break.
3. Leak the seed in 1000th transaction (or milionth...)
4. Leak the seed with some particular transaction. I.e. if the amount mod 97 is 32, leak the seed.
5. Leak the seed with the special, undocumented command in the interface.
6. Combine some of above or invent your own.

In my opinion, the true random k is a better option than RFC6979, but some devs don't even know how to generate random numbers and they still write wallets to store your money....

[molecular]

Looking forward to it's release! Hope this will change bitcoin security

It will/does not change bitcoin security .. its just a way to store your money securely

Storage is part of "Bitcoin" in the broader sense.

[molecular]

  The answer to your question is NO. There is no simple way to chech this. There is a difficult way to test that in your particular test scenario RFC6979 is used.

One more comment: If I understand this correctly, the Trezor use case for signing transaction never reuses adresses. If k=1 was used all the time, only the private keys of the dead address will be revealed. There is still no known way to steal your BTC in this scenario. So the RFC6979 is good to have, but you are safe even without it.

Please correct me if I'm wrong.

I think you're wrong: the idea could be for the trezor devs to use k = <seed XOR some secret> in order to leak the seeds of people to the blockchain, visible only to them, of course.

It's a potential attack by the trezor devs, not just anyone.

There are million of ways how wallet devs (including trezor devs) can leak your seed. Some quick ideas:

thanks for your answer.

let me comment on the items in your list while thinking of RFC6979 compliance testing (assuming it's possible and done by at least some):

1. Use above when the amount is above 10BTC (you don't care about poor guys anyway).

RFC6979 non-compliance can be detected with any single transaction above 10 BTC (there are going to be many of these, because "change")  

2. Use only last 16bits of RFC6979 and xor this with seed. This way k is still deterministic, but easy to break.

RFC6979 compliance test will result in: FAIL (or am I wrong here? not sure)

3. Leak the seed in 1000th transaction (or milionth...)
4. Leak the seed with some particular transaction. I.e. if the amount mod 97 is 32, leak the seed.
5. Leak the seed with the special, undocumented command in the interface.

even if they only leak the seed in a low percentage of transactions, there is risk of detection by RFC6979 compliance test. Once detected, shit hits fan and it's over for them. Risk too high for reward (at least compared to when using random k)

6. Combine some of above or invent your own.

Since all of above are weak approaches, this one is also weak.

In my opinion, the true random k is a better option than RFC6979, but some devs don't even know how to generate random numbers and they still write wallets to store your money....

In my opinion it's not. True random k cannot be checked for at all. It's easy to slowly leak the seed (bit by bit if need be, or completely in one go XORed with or encrypted to attacker secret) in the "random" numbers without anyone being able to prove it. (just noticed XOR would be a bad idea since it would enable "freeloaders")

[slush]

1. Use above when the amount is above 10BTC (you don't care about poor guys anyway).
2. Use only last 16bits of RFC6979 and xor this with seed. This way k is still deterministic, but easy to break.
3. Leak the seed in 1000th transaction (or milionth...)
4. Leak the seed with some particular transaction. I.e. if the amount mod 97 is 32, leak the seed.
5. Leak the seed with the special, undocumented command in the interface.
6. Combine some of above or invent your own.

All these attack vectors are actually very easy to find in source code or even by blackbox testing. We're preparing deterministic build environment for Trezor firmware, so then any interested developer will be able to read sources, build them and compare hash with hash of signed firmware release by SatoshiLabs. Then he can publish on his website (and sign with his gpg key) that he agreed that our binary distribution does what it is supposed to do.

Actually we would like to have a network of independent code reviewers, who will read our commits and sign every stable release. Then it will be extremely hard to prepare any attack even by us. If anybody here is interested in such job, please email to info@satoshilabs.com.

[klokan]

even if they only leak the seed in a low percentage of transactions, there is risk of detection by RFC6979 compliance test. Once detected, shit hits fan and it's over for them. Risk too high for reward (at least compared to when using random k)

6. Combine some of above or invent your own.

Since all of above are weak approaches, this one is also weak.

In my opinion, the true random k is a better option than RFC6979, but some devs don't even know how to generate random numbers and they still write wallets to store your money....

In my opinion it's not. True random k cannot be checked for at all. It's easy to slowly leak the seed (bit by bit if need be, or completely in one go XORed with or encrypted to attacker secret) in the "random" numbers without anyone being able to prove it. (just noticed XOR would be a bad idea since it would enable "freeloaders")

Let me be clear here. I'm talking about ALL wallets, not just Trezor. Using above techniques, you can have deterministic signatures, that comply with RFC6979 most of the time and when they don't they leak your seed. You will not detect is, because the only test you actually do is to check whether it is deterministic, not whether it is RFC6979 compliant (i.e. equality across multiple runs). You can sell or spread your hardware/software wallet for a while while collecting the keys and when competition crushes you eventually, then you can use all those seeds you collected to clear their wallets and fly to Carribean.

I'm not saying that this is Trezor guys intention. I'm just saying that if this was any wallet maker intention it would be EXTREMELLY difficult to find. It is easy to prove it from code, but I disagree that it is simple to prove in blackbox testing. It depends on your luck. From this perspective I really like this initiative of signing the build by third parties. If only everybody did this. But still there are problems like the bootloader that is not signed by anyone etc.

You see, proving that you are not evil is difficult. In a sense, it is similar to using random K in signatures. In the code it is easy to see whether the number comes from the HW rng that is on the chip (much simpler than checking your RFC6979 implementation). But it is impossible to prove this from the generated signature.

[stick]

But it is impossible to prove this from the generated signature.

That's why we would love to setup a deterministic build environment using Vagrant or Docker. So independent "builders" can easily run it and confirm that the signed distributed binary comes really from the published source which can be audited. Currently other tasks have higher priority, though.