Hacker News new | more | comments | ask | show | jobs | submit login
Extracting the Private Key from a TREZOR (jochen-hoenicke.de)
169 points by csomar on Dec 27, 2015 | hide | past | web | favorite | 21 comments



Hey, I work for SatoshiLabs makers of TREZOR, just a small note.

Jochen did a responsible disclosure and this has been fixed already in the firmware before the article hit. Also he is actively submitting patches to the firmware, which is awesome.

I will also note we have a bug bounty program - see http://satoshilabs.com/security/

Also, see us at 32c3, some of us are here :)


I know nothing about TREZORs, but I found it odd that the article mentioned a lack of time resolution in resolving certain events, but made no mention of looking for decoupling capacitors or removing them. Does anyone know if the TREZOR design includes decoupling caps?


I find his ability to relate changes in voltage to steps in the programming logic truly amazing.


+1


It seems like a cheap defense against side channel attacks would be to spam the power line with random, significant loads at integer divisors of the processor frequency. This would substantially increase the window required for statistical inference of what's going on in the processor.


The attacker could just put the probe closer to the CPU.


You could put the noise source deep inside the CPU.


Fascinating. Best look into side channels via electrical analysis I've seen. Thanks.


Are their any small form factor smart card like devices that are immune from side channel attacks like these? It seems like using constant power without much hardware to buffer stuff out is very difficult.


Yes; this was Cryptography Research's main line of business for a long time. Rambus owns them now.

http://www.rambus.com/security/dpa-countermeasures/

The solutions for many (most?) of these problems are patented.


"The solutions for many (most?) of these problems are patented."

Very aggravating that this is still true.


Back when I was doing crypto at the algorithm implementation level, I found the proceedings of the CHES[1] conference had a lot of good information on where the public state of the art was regarding side channel attack and defence.

Keep in mind that side channels are very much a moving target - an implementation that isn't vulnerable to a known attack today could fall to an attack discovered tomorrow. Unless you take extradinary measures to prevent physical measurements of your implementation and detect and respond to physical tamper events, some kind of attack (practical or not) will probably turn up during the useful life of an implementation, in my experience.

With small and/or low-cost devices, such physical countermeasures are usually impractical, so you have to take extra care on the HW/SW algorithm implementation side to avoid vulnerabilities.

[1] https://www.cryptoexperts.com/ches2015/index.html


You need both constant power hardware and software to be immune (and to related timing attacks). The libsecp256k1 library for example is designed to be timing attack resistant, but I'm still working on verifying how power sidechannel resistant it is.

Using an internal power source, like a primary lithium cell, is one way to circumvent the power sidechannel. But power sidechannels can also easily become RF sidechannels, so it's still good to minimize them.


nothing is immune. Any crypto is breakable by someone who is sufficiently smarter than the person who invented the crypto. This is why crypto security is so hard. There is always someone sufficiently smarter.

In general the strongest security is always physical security (attack dogs, machine guns, etc). The problem with that, of course, is that someone more vicious might come along. Also, physical security is somewhat vulnerable to physical degradation (earthquakes, fires, etc) Also, physical security is pretty awkward to implement and maintain, plus it really complicates access and transfer of secured materials.


What an excellent article. I've understood how side-channel attacks could occur, but this is the first thing that I've read that makes the link to how they actually are performed. Thank you.


I have no idea how TREZOR is actually designed, but I would assume they could avoid this kind of security issue by using a secure element/smart card to perform the cryptographic operations.


Well, the TREZOR is already a dedicated "smart card". If you ran the same code on a smart card, you'd have the same side channel attacks.


AFAIK Trezor implements crypto in software running on a general-purpose ARM microcontroller. I don't know if there are any secure chips that support Bitcoin-compatible ECC.


Would not doing a random amount of extra calculations during this step not address this issue better than having a constant time calculation? Of course, fundamentally, if something has access to the hardware, good luck securing things. A dedicated attacker will figure out a way to bypass the PIN.


That was just astonishing. If someone is looking for a definition of hacking, that's it.


This is really over the TOP hacking, thanks for sharing.




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: