
Trezor hardware Bitcoin wallet – Security glitches reveal private keys - mbgaxyz
https://medium.com/@Zero404Cool/trezor-security-glitches-reveal-your-private-keys-761eeab03ff8
======
runeks
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”_.

~~~
zeven7
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.

~~~
raulk
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.

~~~
zeven7
The math is not trivial enough to do with pen and paper.

~~~
raulk
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](https://bitcoin.stackexchange.com/a/29880)

~~~
runeks
> 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.

------
lisper
I make a device similar to the Trezor but fully open-source:

[https://sc4.us/hsm](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
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).

~~~
lisper
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.

~~~
runeks
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.

~~~
lisper
> 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?

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

------
mason55
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_explore
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.

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

~~~
jjnoakes
Right, but then you should store it "in a chip designed against physical
attacks", as the person you replied to mentioned.

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

~~~
londons_explore
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.

~~~
sowbug
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.

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

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

~~~
j_s
Good luck getting a hold of one any time soon!

[https://www.ledgerwallet.com/products/ledger-
nano-s](https://www.ledgerwallet.com/products/ledger-nano-s)

 _Estimated shipping date for all new orders processed from our factory:
September 15, 2017_

~~~
zargon
That's less than a month away.

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

~~~
stickac
trezor uses RDP level 2

also check [https://blog.trezor.io/addressing-concerns-about-trezor-
firm...](https://blog.trezor.io/addressing-concerns-about-trezor-
firmware-1-5-2-4c1f766034c7)

~~~
fpgaminer
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...](http://www.st.com/content/ccc/resource/technical/document/programming_manual/f7/7e/b9/a8/31/58/41/7b/CD00233952.pdf/files/CD00233952.pdf/jcr:content/translations/en.CD00233952.pdf)

Sorry for any confusion my previous comment may have caused.

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

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

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

------
Philosopher
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?

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

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

~~~
trezormcu
This appeared recently, it seems
[http://saleemrashid.com/2017/08/17/extracting-trezor-
secrets...](http://saleemrashid.com/2017/08/17/extracting-trezor-secrets-
sram/)

