Hacker News Reader

Comment by mistahenry | Hacker News Reader

To me, this is full admission of a complete lack of security competency. Building a hardware wallet without using a smart card or some other secure element that at least has mitigation’s against voltage/clock glitching, detects light, reduces the ability to measure power consumption, etc is negligent.

Either they don’t know how to design secure solutions or they wanted to use cheaper chips since tamper resistant chips cost more. Neither is a good look

View on HN

As most on HN know, if anyone has physical access it's game over - so when I read "critical flaw" in the title to me that meant remote key extraction (or similar remote flaw), and since there's nothing remote about this I consider it a clickbait article. No, what has been written up is not "critical".

physical in-person key extraction after literally opening up a piece of hardware and glitching its exposed innards isn't a "critical flaw". it's baseline expectation.

I would rate the issue raised in the article as "not a bug, won't-fix." with the explanation that "Physical key extraction will always be possible regardless of anything we do."

or are people here claiming that their "better" competitors (who are using "better" hardware, more "correctly") are immune from physical attacks?

EDIT: I am keeping this even if it gets voted to -4. I don't believe a physical, local (in person) glitching attack on the innards of a device, which requires physical access and opening it, constitutes a "critical" vulnerability on a hardware cryptographic device.

IMO there's a huge difference between invasive and non-invasive attacks. I would expect something that bills itself as "The safe place for your coins" to require a bit more effort, know-how, and tools to read out my keys than "a couple hundred dollars of equipment" and a python program.

> if anyone has physical access it's game over

It's actually not when you use a series of common defenses that wipe the chip when tampering is detected. Of course it's still possible to determine the private keys via perfectly executed microprobing...but there's a huge difference here. Invasive attacks require significant time in very expensive laboratories per attack, which very well may fail.

Let's say managed to steal my wallet which leverages a secure element with tampering protection. If you're unaware that voltage/clock glitching will wipe the device, you may try and then you've lost. But let's say you're aware so you want to go the microprobing route. Do you have the necessary lasers and acids to get directly to the circuitry you want to read out without accidentally compromising the integrity of the top-layer sensor meshes? Do you possess a focused ion beam station (only costs ~500k USD)? By using this mesh I've made the extraction significantly more tedious and requiring far higher levels of precision for you. You've got my smart card, but I wouldn't call it "Game Over" by any means. Maybe in this amount of time I figured out that my wallet is missing.

This attack here on the Tresor, though, requires physical access but can be automated. Here, physical access really is game over. I would rate this issue as "Trezor shows themselves to be an inferior solution, will not use to store my keys"

Read here if you want to see more on techniques for readout and known countermeasures. https://www.cl.cam.ac.uk/~mgk25/sc99-tamper.pdf

Inferior to what? The only other hardware wallet with large market share?

Have a look at this: https://saleemrashid.com/2018/03/20/breaking-ledger-security...

Interesting comment, thanks. What would you say about my other question: how good are tamper evident seals - for example would a tamper evident seal on the enclosure show visually whether it has been opened (for example to exploit the flaw this article is about), or are tamper evident seals easy to get around or re-apply undetected?

Depends on the seal; most are not particularly strong and the rest require thorough and well-designed inspection procedures.

> if anyone has physical access it's game over

That's true but for only for threat models that assume decapping and other extreme efforts.

https://en.wikipedia.org/wiki/Secure_cryptoprocessor

How extreme is decapping? How much equipment and how much time does it require? How often does it destroy the chip or cause damage? How obvious is it that it occurred?

While we're at it, for the last question, tamper evidence, how good are tamper evidence seals - for example would a tamper evident seal on the enclosure show visually whether it has been opened (for example to exploit the flaw this article is about), or are tamper evident seals easy to get around or re-apply undetected?

Decapping requires dissolving the plastic with acid. Attacking the chip from there is typically done in a Focused Ion Beam workstation (about $500k), and the risk of destroying the chip depends on too many factors. Some chips have photosensitive elements that generate just enough voltage to wipe their memory if they're exposed to light via decapping.

Tamper evident seals can often be defeated with nothing more than a PTFE (Teflon) knife made from shim stock.

thanks

Trezor's security features list [0] mentions firmware verification, JTAG, and welding - strongly implying that intends on at least some resistance to physical attack. This is not uncommon for hardware cryptography modules. Since 2001, the federal government has had a certification program, FIPS 140-2 [1], recognizing four different levels of physical attack resistance.

The security engineering industry is very interested in the capability to physically ship secrets to potentially hostile actors inside devices that limit their use or duplication. There are many many applications:

- Payment cards: EMV credit/debit, transit, laundry, parking, prepaid electric meters, etc.

- DRM: Widevine for Netflix, DCP for your local movie theater, anti-piracy and anti-cheat in your Xbox.

- Privacy: the iPhone's Secure Element only decrypts user data given the right PIN, rate limits or caps attempts, resists extraction of private key, much to FBI's disappointment.

- Root of trust: enterprise HSMs for PKI will only enable signing operations with their internal private keys after the presentation of a quorum of operator credentials [2].

Ross Anderson's Security Engineering has a great chapter on this [3].

[0] https://trezor.io/security/ [1] https://en.wikipedia.org/wiki/FIPS_140-2 [2] https://www.cloudflare.com/dns/dnssec/root-signing-ceremony/ [3] https://www.cl.cam.ac.uk/~rja14/Papers/SEv3-ch18-dec18.pdf

Reply on news.ycombinator.com