Trezor hardware Bitcoin wallet – Security glitches reveal private keys(medium.com)
medium.com
Trezor hardware Bitcoin wallet – Security glitches reveal private keys
https://medium.com/@Zero404Cool/trezor-security-glitches-reveal-your-private-keys-761eeab03ff8
47 コメント
Same here, raspi works well for me (I taped over the Ethernet port so I don't accidentally connect it at some future date)
I think the only issue comes with the future case where I'm actually trying to transact in crypto, rather than just collect (speculate) long-term assets. I suppose at that point, I'll just use a software wallet on my phone and keep much smaller amounts there (much like savings vs checking account).
I think the only issue comes with the future case where I'm actually trying to transact in crypto, rather than just collect (speculate) long-term assets. I suppose at that point, I'll just use a software wallet on my phone and keep much smaller amounts there (much like savings vs checking account).
I wish it was easy enough to derive a Bitcoin address from a private key using pen and paper so that I could just make up a private key, write it down, work out a few details, and then have a Bitcoin address I could provide to anyone... with only human error as a possible problem or attack vector.
Bitcoin addresses are derived from the public key, which in turn derives from a private key. So you can already do what you propose, as long as your private keys satisfies the strength that Bitcoin requires.
The math is not trivial enough to do with pen and paper.
If it was, how secure would Bitcoin be? How much more vulnerable would it make it to brute-force attacks?
There's nothing stopping you from applying the key derivation algo step by step using a calculator, or an offline computer.
It would make for an insightful, albeit time-consuming, experiment.
https://bitcoin.stackexchange.com/a/29880
There's nothing stopping you from applying the key derivation algo step by step using a calculator, or an offline computer.
It would make for an insightful, albeit time-consuming, experiment.
https://bitcoin.stackexchange.com/a/29880
> If it was, how secure would Bitcoin be?
It doesn’t matter how easy/simple it is to derive a public key from a private key. What matters is how easy it is to go in the opposite direction. As your link shows, it’s not that hard to do elliptic curve multiplication by hand, and there’s no need for it to be hard/complex.
It doesn’t matter how easy/simple it is to derive a public key from a private key. What matters is how easy it is to go in the opposite direction. As your link shows, it’s not that hard to do elliptic curve multiplication by hand, and there’s no need for it to be hard/complex.
Why do you prefer physical hardware over plain paper?
The selling point of hardware wallets is that they do the signing for you, in an assumed safe sandbox.
I believe to make an analog with paper, you would:
- Spin up an offline VM with some bitcoin wallet software capable of doing offline signing.
- Import your private key
- Import the transaction data in a controlled matter, e.g QR code
- Sign the transaction
- Transport the signed transaction back to an online device in a controlled manner, e.g QR code
- Publish the transaction with the online device
I believe to make an analog with paper, you would:
- Spin up an offline VM with some bitcoin wallet software capable of doing offline signing.
- Import your private key
- Import the transaction data in a controlled matter, e.g QR code
- Sign the transaction
- Transport the signed transaction back to an online device in a controlled manner, e.g QR code
- Publish the transaction with the online device
Ah, that makes sense. However, if you're not interested in spending, just storing for a long period of time, they are more or less equivalent in terms of security, I'm assuming?
One use case to consider is that your successors in interest are the ones doing the spending. I.e., you are dead. It would be such a shame if they typed the private key into the family's malware-infested Windows PC and then wondered why the balance was zero.
A hardware wallet firewalls your loved ones from that risk.
A hardware wallet firewalls your loved ones from that risk.
Yes, I'd say so.
You would probably not own a hardware wallet without storing the keywords for recovering the private key on paper (or similar). At that point it is more or less how you store the paper that will affect your level of security.
You would probably not own a hardware wallet without storing the keywords for recovering the private key on paper (or similar). At that point it is more or less how you store the paper that will affect your level of security.
I make a device similar to the Trezor but fully open-source:
https://sc4.us/hsm
I'm looking for someone to help port a bitcoin wallet app to it, either as a contractor or on a volunteer basis. If you're interested please contact me off line. Contact info in my profile or on the site.
https://sc4.us/hsm
I'm looking for someone to help port a bitcoin wallet app to it, either as a contractor or on a volunteer basis. If you're interested please contact me off line. Contact info in my profile or on the site.
Very cool. I'll definitely subscribe and watch for how this progresses. I'll like that it is minimal but still have display. Unfortunately if someone controls user machine they still can spoof the destination address so it's still possible to sign a bad transaction (as noted in the FAQ).
Yes, that's true, but this is no different than any hardware wallet that obtains transactions to sign through a client machine. In fact, if you think about it, this must be the case.
However, such an attack would be very difficult to actually carry out because it's not enough for the attacker to send the transaction to the SC4-HSM. The attacker also has to somehow trick you into pushing the button on the HSM. So the probably have to 1) time their attack to exactly coincide with you wanting to sign a transaction, 2) trick your client into thinking the HSM has sent it the proper handshake and 3) hope you don't notice that the value on the HSM display is wrong. It's possible, but really really hard to do without being noticed.
However, such an attack would be very difficult to actually carry out because it's not enough for the attacker to send the transaction to the SC4-HSM. The attacker also has to somehow trick you into pushing the button on the HSM. So the probably have to 1) time their attack to exactly coincide with you wanting to sign a transaction, 2) trick your client into thinking the HSM has sent it the proper handshake and 3) hope you don't notice that the value on the HSM display is wrong. It's possible, but really really hard to do without being noticed.
Why not display the destination address, so the user can check whether this corresponds with what is expected?
The device itself can easily check whether the change address belongs to its own private key, simply by requiring the online computer to provide the key index of the change address, and the device deriving this key to make sure it owns it.
The device itself can easily check whether the change address belongs to its own private key, simply by requiring the online computer to provide the key index of the change address, and the device deriving this key to make sure it owns it.
> Why not display the destination address, so the user can check whether this corresponds with what is expected?
Well, yeah, of course. What did you think it would do?
> The device itself can easily check whether the change address belongs to its own private key
Well, yeah, but how does that help? Usually you want to send money to other people (i.e. to keys you don't own), no?
Well, yeah, of course. What did you think it would do?
> The device itself can easily check whether the change address belongs to its own private key
Well, yeah, but how does that help? Usually you want to send money to other people (i.e. to keys you don't own), no?
Sensationalistic article and 2BTC needed to download the mentionned source code of the hack, sounds like a scam
The TREZOR people have posted on Reddit that this article is describing a known issue which was fixed in the last firmware update yesterday.
If the secret key is stored in a reversible way in a chip not designed against physical attacks, I fail to see how they could do a software fix?
Sure they might have stopped anything getting copied to SRAM, but the data is still sitting there in flash ready to be read out by almost any method.
Sure they might have stopped anything getting copied to SRAM, but the data is still sitting there in flash ready to be read out by almost any method.
Article claims it works against unreleased Trezor V2 and software version 1.5.2 but Trezor say this is incorrect. So I would take the claims with a pinch of salt, especially they are charging almost $9k to download the software
Any secret must be stored "in a reversible way" or else it's useless.
Right, but then you should store it "in a chip designed against physical attacks", as the person you replied to mentioned.
That isn't a panacea. Even though secure elements today have clever defenses against physical attack, they're no match against a sufficiently-funded adversary.
Contrast cryptography, where no amount of money or human effort could defeat, say, 256-bit symmetric encryption.
The reason this matters is that if you accept that defeating physical defenses is always a matter of money, then you must next decide the attack cost that's sufficiently high to protect your assets.
Then when you learn that the cost to defeat any hardware wallet, including Trezor, is already very high, you understand that we might as well be debating the merits of 255- vs. 256-bit encryption.
(Note that this is not meant to draw an equivalence between hardware Bitcoin wallets and modern symmetric cryptography. There is a big difference. But not a difference that improves the infeasibility of mounting an attack against your Trezor with 25 BTC in it.)
Contrast cryptography, where no amount of money or human effort could defeat, say, 256-bit symmetric encryption.
The reason this matters is that if you accept that defeating physical defenses is always a matter of money, then you must next decide the attack cost that's sufficiently high to protect your assets.
Then when you learn that the cost to defeat any hardware wallet, including Trezor, is already very high, you understand that we might as well be debating the merits of 255- vs. 256-bit encryption.
(Note that this is not meant to draw an equivalence between hardware Bitcoin wallets and modern symmetric cryptography. There is a big difference. But not a difference that improves the infeasibility of mounting an attack against your Trezor with 25 BTC in it.)
If I had 250 BTC (half a million dollars), I would be quite confident that someone would try to steal it if a simple power supply glitching trick could extract it.
Whereas if it is in a physically protected chip (like many credit card chips), I would feel rather safe knowing the tech and expertise to extract it costs more than half a million dollars.
Whereas if it is in a physically protected chip (like many credit card chips), I would feel rather safe knowing the tech and expertise to extract it costs more than half a million dollars.
We're in agreement on the general idea of a cost-benefit analysis for security, but your numbers are a bit off. 250BTC is worth over $1M USD (especially if you owned it as of Aug 1 and thus also have 250 Bitcoin Cash).
Breaking into your house to steal a hardware wallet has a significant cost/risk in many people's minds. If someone is willing to break into your house, they're probably also willing to beat you senseless until you transfer them your bitcoin, because you surely value it less than your own life. That's why I think the cost to defeat hardware is high in general, but not especially relevant if your threat model includes targeted attacks.
Breaking into your house to steal a hardware wallet has a significant cost/risk in many people's minds. If someone is willing to break into your house, they're probably also willing to beat you senseless until you transfer them your bitcoin, because you surely value it less than your own life. That's why I think the cost to defeat hardware is high in general, but not especially relevant if your threat model includes targeted attacks.
Not if the read protection level 2 is used. Which has been used since the beginning.
How true is this article? http://saleemrashid.com/2017/08/17/extracting-trezor-secrets...
from the article:
> Since Trezor has finally provided the hot-fix for this particular hack we can also fully disclose how it works.
But they claim there are other similar hacks
> Since Trezor has finally provided the hot-fix for this particular hack we can also fully disclose how it works.
But they claim there are other similar hacks
A password for key derivation prevents this attack and all other physical attacks. Trezor has supported this since day one.
The Ledger nano S seems of much better quality, and is cheaper.
Does this device display the destination Bitcoin address? I haven’t been able to find out, but it looks to me like the display isn’t big enough for that. If it does not, it makes it a lot less useful, as malware can just silently replace the destination address.
Good luck getting a hold of one any time soon!
https://www.ledgerwallet.com/products/ledger-nano-s
Estimated shipping date for all new orders processed from our factory: September 15, 2017
https://www.ledgerwallet.com/products/ledger-nano-s
Estimated shipping date for all new orders processed from our factory: September 15, 2017
That's less than a month away.
And it uses actual secure hardware, originally designed for smart cards.
I do love mine, it supports quite a few cryptocurrencies as well.
This article is hard to read; it's very disjoint and doesn't give much detail. So I'll see if I can pierce the fog.
According to another commenter, the Trezor uses an STM32F205. A quick skim through EEVblog's teardown and it does look like they use that device, and only that device (no other peripheral security devices).
On a quick skim of the STM32F205's Programming Manual I don't see any mention of RDP or Read protection. In STM32 devices that's the Flash register that prevents readback of data stored in the device's flash and can also disable the device's debug interfaces.
So ... if all that is accurate then the "attack" is very straightforward. Just open the device, hook into the debug interface (SWD/JTAG) and dump the Flash. Easy.
The only way to defend against such an attack is to either 1) Encrypt the contents of the device with a user password or 2) use anti-tamper methods which would erase the device in case of tampering. Since I don't believe the Trezor has a battery, #2 seems unlikely. #1 is already possible on a Trezor, but is optional.
If all this is the case, then yeah ... there's nothing that can be done to stop it (besides the password).
I'm actually really surprised.
When I built my Bitcoin hardware wallet, even before the Trezor, I used an STM32 device that had RDP. With RDP enabled, there's no specified way to dump the chip's Flash and the debug interfaces are disabled (1). I also had a touch screen on the device, so a real password could be used (not just a pin code). Combined with aggressive PBKDF2 iterations, even if someone got into the Flash memory your data would still be protected behind strong encryption.
Also, in a recent re-iteration of the device, I'm actually using _two_ MCUs. One MCU is the communications MCU and the other is the secure MCU. The comms MCU connects to USB, Bluetooth, etc and talks to the secure MCU over SPI. The secure MCU connects to the display and touchscreen. The reason for this split is to prevent any bugs in the USB/Bluetooth/etc stack from allowing access to your secure data.
Unfortunately my real job got in the way and I never finished productizing my hardware wallet. Maybe I should resurrect that project...
Anyway, I'm surprised the Trezor didn't use a more secure STM32 device. It would hardly have cost more.
(1) Of course, it's foolish to trust MCU manufacturers to have good security. For example, in the course of securing an NXP MCU which also has readback protection I discovered a way to bypass the protection and dump RAM contents off a warm device. That's why I planned for strong password protection on my devices, as a second line of defense. I've even considered using an FPGA instead, as, for example, Lattice FPGA devices are designed by competent security engineers. Even delidding secured Lattice FPGAs device will wipe all secrets. But FPGAs can be rather pricey and take more time to develop with.
EDIT: In hindsight, thinking about it more ... if your Trezor doesn't have a pincode, can't someone with physical access to your Trezor just spend your coins anyway? Not much need for a "hack" there.
Of course, lack of RDP is still a problem. Pin codes can be "strong" if the device has RDP, because the device can rate-limit pincode tests. But if you can dump the Flash, then the pincode offers 0 protection since offline bruteforcing the pincode from the encrypted Flash would take no time at all.
According to another commenter, the Trezor uses an STM32F205. A quick skim through EEVblog's teardown and it does look like they use that device, and only that device (no other peripheral security devices).
On a quick skim of the STM32F205's Programming Manual I don't see any mention of RDP or Read protection. In STM32 devices that's the Flash register that prevents readback of data stored in the device's flash and can also disable the device's debug interfaces.
So ... if all that is accurate then the "attack" is very straightforward. Just open the device, hook into the debug interface (SWD/JTAG) and dump the Flash. Easy.
The only way to defend against such an attack is to either 1) Encrypt the contents of the device with a user password or 2) use anti-tamper methods which would erase the device in case of tampering. Since I don't believe the Trezor has a battery, #2 seems unlikely. #1 is already possible on a Trezor, but is optional.
If all this is the case, then yeah ... there's nothing that can be done to stop it (besides the password).
I'm actually really surprised.
When I built my Bitcoin hardware wallet, even before the Trezor, I used an STM32 device that had RDP. With RDP enabled, there's no specified way to dump the chip's Flash and the debug interfaces are disabled (1). I also had a touch screen on the device, so a real password could be used (not just a pin code). Combined with aggressive PBKDF2 iterations, even if someone got into the Flash memory your data would still be protected behind strong encryption.
Also, in a recent re-iteration of the device, I'm actually using _two_ MCUs. One MCU is the communications MCU and the other is the secure MCU. The comms MCU connects to USB, Bluetooth, etc and talks to the secure MCU over SPI. The secure MCU connects to the display and touchscreen. The reason for this split is to prevent any bugs in the USB/Bluetooth/etc stack from allowing access to your secure data.
Unfortunately my real job got in the way and I never finished productizing my hardware wallet. Maybe I should resurrect that project...
Anyway, I'm surprised the Trezor didn't use a more secure STM32 device. It would hardly have cost more.
(1) Of course, it's foolish to trust MCU manufacturers to have good security. For example, in the course of securing an NXP MCU which also has readback protection I discovered a way to bypass the protection and dump RAM contents off a warm device. That's why I planned for strong password protection on my devices, as a second line of defense. I've even considered using an FPGA instead, as, for example, Lattice FPGA devices are designed by competent security engineers. Even delidding secured Lattice FPGAs device will wipe all secrets. But FPGAs can be rather pricey and take more time to develop with.
EDIT: In hindsight, thinking about it more ... if your Trezor doesn't have a pincode, can't someone with physical access to your Trezor just spend your coins anyway? Not much need for a "hack" there.
Of course, lack of RDP is still a problem. Pin codes can be "strong" if the device has RDP, because the device can rate-limit pincode tests. But if you can dump the Flash, then the pincode offers 0 protection since offline bruteforcing the pincode from the encrypted Flash would take no time at all.
trezor uses RDP level 2
also check https://blog.trezor.io/addressing-concerns-about-trezor-firm...
also check https://blog.trezor.io/addressing-concerns-about-trezor-firm...
Thank you for the clarification.
Looks like STM documents RDP for the STM32F205 chip in the "Flash programming manual". I'm used to it being covered in the normal "Programming manual". Link for the curious: http://www.st.com/content/ccc/resource/technical/document/pr...
Sorry for any confusion my previous comment may have caused.
Looks like STM documents RDP for the STM32F205 chip in the "Flash programming manual". I'm used to it being covered in the normal "Programming manual". Link for the curious: http://www.st.com/content/ccc/resource/technical/document/pr...
Sorry for any confusion my previous comment may have caused.
So this blows my plan of buying a trezor and leaving it in a safe in the bank. I guess.
a safety deposit box where you have the key would suffice as it requires physical access to achieve this attack
Anyone know if Ledger Nano S devices are vulnerable to this kind of attack? Do they use different hardware?
I'm a tech noob, so here's my question: does this mean that whenever you connect your Trezor to a computer, you run the risk of it being hacked (conditional upon your computer being infected)? Or does the hacker need physical access to your Trezor?
Wow, nicely done. Feel sorry for the people who bought a Trezor.
While the hack itself might be interesting, this is horrible, sensationalistic writing and lacks any kind of technical details. It even manages to mistype the microcontroller type (it's STM32F205, not ST32F05).
This appeared recently, it seems http://saleemrashid.com/2017/08/17/extracting-trezor-secrets...
We really need a hardware wallet company to partner up with an insurance company, such that the incentives of the users and wallet-producers are aligned. Claiming you have a secure device, while at the same time disclaiming all responsibility for money-stealing bugs, seems disingenuous to me. “Our device is much more secure than anything else out there, but we’re not willing to risk a dime to support this claim”.