
Extracting the private key from a TREZOR with an oscilloscope (2015) - mlejva
https://jochen-hoenicke.de/trezor-power-analysis/
======
jnwatson
The term of art for this kind of attack is SPA (simple power analysis). The
fact that this is possible means that this is amateur hour engineering, with
very little security QA. The more sophisticated attacks use DPA, differential
power analysis, which accumulate the results of multiple runs and performs
statistical analysis.

When I was on a team that made a similar device over a decade ago, we were up
to our eyeballs in academic papers about SPA and DPA hardware and software
countermeasures. That doesn't mean we didn't make any mistakes, but at least
we were knowledgeable enough to hook an oscilloscope up and see what's going
on.

These guys completely ignored an entire class of attacks, known in detail for
a couple decades, (in reality since 1943, declassified 1972 ([1]). I wouldn't
trust these guys to protect anything of value.

[1] [https://www.wired.com/2008/04/nsa-releases-
se/](https://www.wired.com/2008/04/nsa-releases-se/)

~~~
monochromatic
Are there simple techniques that can mitigate these attacks?

~~~
tzs
In this particular attack, it looks like the attacker measured the power drawn
over USB. This could probably be defeated by buffering power.

Include some kind of energy storage on the device, such as a battery or an
ultra-capacitor. Your external power source (e.g., USB) charges your storage
device, and your computation is powered from the storage device. Only charge
the storage device between complete operations.

Someone watching power over USB would then see no power draw during key
operations, and a smooth power draw between operations.

If your threat model includes attackers that will be able to probe inside the
device while it is doing operations, and so who could look at the power on the
far side of the battery or capacity, then buffering power won't be sufficient.

~~~
exoesquitur
Anyone measuring power will have the capability to bypass / defeat any
external power filtering. To be of value this must be done at the die level.

------
nope96
They hired him after this:

[https://medium.com/@satoshilabs/ethical-hacker-and-
bitcoin-h...](https://medium.com/@satoshilabs/ethical-hacker-and-bitcoin-hero-
johoe-joins-satoshilabs-as-trezor-cryptographer-36c9a6b10d52#.2wri5l7fx)

------
atdrummond
This was published in 2015. Updating to a more recent firmware, which requires
a PIN when computing the public key, eliminates the utility of such an attack.

~~~
aaron_m04
Interesting. Do you have a link where I could read more about this?

~~~
cyphunk
[https://github.com/trezor/trezor-
mcu/commits/master?after=31...](https://github.com/trezor/trezor-
mcu/commits/master?after=3185eb0fd444701e2bc976555545fe08d572c957+769)

As jochen mentions in his timeline in the post trezor asked he delay
publication until they could fix the bug in release 1.3.3. he says they
included a fix on Mar 30 which you'll find in the link above

------
bonyt
It's amazing how hard it is to make something secure when considering side
channels. Almost any bit of information can be used to extrapolate more - just
consider this type of power-based attack, timing attacks, meltdown/spectre,
CBC padding oracles, etc.

Plus, suddenly people are pumping millions (or billions) into private keys on
little devices, it is amazing.

~~~
etherael
It seems that way from the outside, I'll grant. But I'll explain by analogy
why I don't think it's as crazy as one might otherwise at first glance assume.

It's possible to create gold artificially, but because of the cost of doing it
vs just purchasing the natural stuff, you can be almost certain any gold you
come into contact with is not artificially created.

In much the same way, even though there are indeed tons of theoretical attacks
that compromise various crypto keys linked to massive fortunes, because of the
way the sector has evolved in terms of not making high value keys available in
a low security context, and mitigating those threats in a high security
context, the likelihood that any given crypto "account" you care to mention
will ever be hacked is similarly low. It's not worth the attackers to invest
the necessary resources to snag your minor android wallet stash, and even if
they tried to bring those resources to bear on Xapo's vaults, they would fail.

Also, the sector as a whole has basically pioneered a whole new class of
security measures, at least to the extent they're now in reasonably wide
circulation, and improved security consciousness and software in general
around the space immensely, exactly because now a bug isn't just some time and
embarrassment, it may well be losing millions of dollars in value. In that
context it makes sense to invest in the security to do it right and think
carefully about all possible attack surfaces and vulnerabilities.

------
touart
There was another successful attack on another hardware wallet (Ledger) 3
months ago, by tampering the firmware used in one of the MCU - (Post by the
author: [https://saleemrashid.com/2018/03/20/breaking-ledger-
security...](https://saleemrashid.com/2018/03/20/breaking-ledger-security-
model/) ; HN thread:
[https://news.ycombinator.com/item?id=16627725](https://news.ycombinator.com/item?id=16627725))

------
remcob
Some impressive work in this field has been done by Tel Aviv University. They
where able to get private keys out of a laptop by merely touching the laptop
[1] or placing a smartphone nearby [2].

[1]:
[http://www.tau.ac.il/~tromer/handsoff/](http://www.tau.ac.il/~tromer/handsoff/)
[2]:
[https://www.tau.ac.il/~tromer/acoustic/](https://www.tau.ac.il/~tromer/acoustic/)

------
zeroDivisible
"Silence on the wire" [1] hypothesizes finding the state of systems from the
outside world - or based on the lack of information. Found it entertaining to
read and this article somehow reminded me about it.

[1]
[https://www.goodreads.com/book/show/82994.Silence_on_the_Wir...](https://www.goodreads.com/book/show/82994.Silence_on_the_Wire)

~~~
godelmachine
I got Silence on the Wire after reading your comment. Let's see how it is.

------
sbhn
Html5 oscilloscope if anyone needs one [https://github.com/Sean-
Bradley/Oscilloscope](https://github.com/Sean-Bradley/Oscilloscope)

------
kxyvr
Awhile back, I was looking at using a TREZOR as a U2F key. I liked it since
the interface looked good, confirmation of sending the key on the device
itself, and the software was open source. For those two reasons, it looked
nicer than using a Yubikey, which closed it source with the Yubikey 4 and
didn't provide confirmation on the device itself.

That said, this attack didn't make the TREZOR look great. What's a good option
for a U2F key? On a similar topic, with WebAuthn, is it worth waiting for
FIDO2 keys?

~~~
Fnoord
I recommend to use 2FA asap. Whatever implementation is better than none,
though it depends on your attack surface/vector and even on the question how
good your 1st factor is (your password).

You can get a cheap, good YubiKey which is U2F/FIDO2 certified for 20 USD/EUR
[1]. These communicate over USB-A or USB-C depending on the one you buy. We're
in a transition of USB-A to USB-C that's always a rough time. Do you go for
backwards compatibility, the (better) future standard, or both (buying two)?

If you prefer Bluetooth or NFC the one I mentioned above is too limited. Then
Google recommends a Feitan for the former, and I recommend a YubiKey NEO for
the latter. YubiKey NEO is also open source.

With regards to TREZOR/Ledger, 2FA usage is more of a nice by-product. People
buy it as Bitcoin wallet 2FA and that it can be used for more is an
afterthought. One that can save you a couple of bucks though.

Either way I recommend at least 1 2FA backup. Could be codes, or an app, or a
second YubiKey, or even SMS. Though, obviously, each of these has their
weaknesses you could host the codes in e.g. cryptosteel [2] at a notary. I
plan to do that with my important passwords (ie. the password for my password
manager).

[1] [https://www.yubico.com/product/security-key-by-
yubico/](https://www.yubico.com/product/security-key-by-yubico/)

[2] [https://cryptosteel.com/](https://cryptosteel.com/)

------
nebulous1
I did not know you could get dirt cheap USB oscilloscopes

~~~
rpcope1
The "oscilloscope" Jochen used for this is a huge piece of junk, quite
frankly. I wrote the library he used to interface with the scope for this
attack, and I frankly wouldn't even bother touching that "scope" unless I
needed a kind of quick two port DAQ. It would be far smarter to spend a little
more and buy a Rigol 1102 (or similar) instead.

In terms of technically why it's really a bad piece of hardware, I can
elaborate if someone wants details, but at a high level it lacks any form of
hardware triggering (and everything is pretty much driven by the relatively
slow on-board 8051 (no FPGA or anything similar)), and data transfer only
happens over bulk USB transfers; furthermore sometimes the firmware just drops
data.

~~~
vardump
> the relatively slow on-board 8051

Cypress FX2LP?

It's pretty sad indeed. 48 MHz clock and performance is maybe 2 MIPS, if
that...

~~~
rpcope1
Yeah, I think that was it. It's kind of fun to program (in the sense that 8051
assembler is usually less crazy than x86/x64 assembler), but it's way
underpowered in that way it got used for the 6022BE.

~~~
vardump
In case this could help to improve that scope, I'll share my best FX2LP trick:

The key to get the best out of FX2LP is to set MPAGE to 0xe6. This way you can
index USB registers at 0xe6xx through 8051 r0 and r1 -- no need to load
register address to DPTR. Most interestingly, this also works for XAUTODAT1
and XAUTODAT2 registers, which can act as (optionally auto-incrementing)
read/write pointers anywhere in xram. This enables "fast" memcopy, memfill,
strlen, etc.

If r0 points to XAUTODAT1 and r1 to XAUTODAT2, and auto-incrementing is
enabled, memcpy becomes just this:

    
    
      memcpy_loop:
        movx a, @r0
        movx @r1, a
        djnz r7, memcpy_loop
    
    

AUTOPTR1H/AUTOPTR1L and AUTOPTR2H/AUTOPTR2L set the pointer address.

With FX2LP autopointers, 8051 native DPTR isn't typically needed at all.

------
knorker
Tell me again how we're supposed to be competent enough to run our own banks,
and that as long as we never make a mistake reversing transactions are not a
needed feature...

------
doyoulikeworms
Is there an underground ring of hardware wallet crackers? Are we living in a
cyberpunk future already?

~~~
Cthulhu_
I'm not sure to be honest, but I wouldn't be surprised if there would be hack
attempts or people looking for those if they er, "found" a hardware wallet
somewhere. Anyone that has a hardware wallet is bound to have a nontrivial
amount of cryptocurrencies on there.

------
k_vi
trezor or ledger?

~~~
4x3l
or bitbox?

