Trezor hardware Bitcoin wallet – Security glitches reveal private keys

https://medium.com/@Zero404Cool/trezor-security-glitches-reveal-your-private-keys-761eeab03ff8

by mbgaxyz • 9 years ago

83 46 9 years ago

GrumpyNl• 9 years ago

Wow, nicely done. Feel sorry for the people who bought a Trezor.

avian• 9 years ago

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).

trezormcu2• 9 years ago

This appeared recently, it seems http://saleemrashid.com/2017/08/17/extracting-trezor-secrets...

mason55• 9 years ago

The TREZOR people have posted on Reddit that this article is describing a known issue which was fixed in the last firmware update yesterday.

londons_explore2• 9 years ago

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.

celticninja2• 9 years ago

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

sowbug4• 9 years ago

Any secret must be stored "in a reversible way" or else it's useless.

stickac2• 9 years ago

Not if the read protection level 2 is used. Which has been used since the beginning.

ttam• 9 years ago

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

popol12• 9 years ago

The Ledger nano S seems of much better quality, and is cheaper.

StavrosK• 9 years ago

I do love mine, it supports quite a few cryptocurrencies as well.

DennisP• 9 years ago

And it uses actual secure hardware, originally designed for smart cards.

j_s• 9 years ago

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

zargon• 9 years ago

That's less than a month away.

runeks4• 9 years ago

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.

majinboo• 9 years ago

Sensationalistic article and 2BTC needed to download the mentionned source code of the hack, sounds like a scam

runeks4• 9 years ago

This is exactly why I’m hesitant to buy a hardware Bitcoin wallet. Not because I know they are insecure, but simply because I don’t trust them to be careful enough when they have no liability in case they make mistakes. For now, as far as I can see, the best bet on offline Bitcoin wallet security is a WiFi-less Raspberry Pi-like device, with a “USB-stick interface” (for transferring unsigned/signed transactions) and USB auto-run turned off.

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”.

theli0nheart2• 9 years ago

Why do you prefer physical hardware over plain paper?

markild2• 9 years ago

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

zeven72• 9 years ago

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.

raulk2• 9 years ago

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.

hanklazard• 9 years ago

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).

jron• 9 years ago

A password for key derivation prevents this attack and all other physical attacks. Trezor has supported this since day one.

lisper3• 9 years ago

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.

hdhzy• 9 years ago

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).

lisper3• 9 years ago

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.

fpgaminer2• 9 years ago

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.

stickac2• 9 years ago

trezor uses RDP level 2

also check https://blog.trezor.io/addressing-concerns-about-trezor-firm...

fpgaminer2• 9 years ago

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.

znpy• 9 years ago

So this blows my plan of buying a trezor and leaving it in a safe in the bank. I guess.

celticninja2• 9 years ago

a safety deposit box where you have the key would suffice as it requires physical access to achieve this attack

philanthropist• 9 years ago

Anyone know if Ledger Nano S devices are vulnerable to this kind of attack? Do they use different hardware?

Philosopher• 9 years ago

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?

Trezor hardware Bitcoin wallet – Security glitches reveal private keys

Related Stories