Hacker News Reader

Hacker News

Comment by FLUX-YOU | Hacker News Reader

Parent Full thread

FLUX-YOU

>Extracting a secret key from an supposedly PIN protected device looks in scope to me.

Prevented by not letting anyone casually hook up an oscilloscope to your TREZOR.

View on HN

Why not just use a USB drive if your threat model doesn't involve physical access to the device?

Because a USB drive is less secure for this use case.

If you stick a USB drive into a compromised computer to make a transaction, a virus can steal the private key.

If you stick a Trezor or Ledger into a compromised computer to make a transaction, your private key is still safe.

Malware on the host PC can steal your private key. An attacker who gets brief physical access (eg, you look away for a minute) can quickly copy a USB drive.

While this attack shows the trezor is probably a bit amateur-hour, it does provide some amount of value.

That's not how it works. The trezor is not a USB storage device, it is a usb serial port that communicates with an MCU.

No one claimed it is...

I can see how reading my comment in isolation would be confusing.

Specifically, I was answering the question "Why not just use a USB drive"

Because any process with i/o capability on the host OS can read the private key on the USB?

Short of a oscilloscope hiding in the computer you use (totally possible), no process can derive the private key from the Trezor in theory.

Even if you have processes that blatantly copy every USB's contents (or even log all interactions verbosely) and log all key presses/clipboard interactions on the machine, you can still use a Trezor without compromising anything.

You can also verify that your clipboard is not being manipulated as the Trezor can verify the address it will be signing a transaction with on the display.

the oscilloscope has 20 MHz bandwith, any old VGA monitor (CRT/LCD/etc) has at least 3 30MHz ADCs (1024x768x60=~60Msps=~30MHz bandwidth).

ADC's may be expensive in low volume discrete form, but integrated in (standardized!) peripheral bus (USB) controllers, this could be very cheap.

As always, it depends on the threat model: do you wish to protect against manufacturers/nation states or not?

I would love to read a more thorough explanation of what you're suggesting.

I believe they are suggesting that the above comment "Short of a oscilloscope hiding in the computer you use" might not be so far fetched. The hardware needed to do the type of analysis used for this attack has been around a long time and is presumably very cheap at scale. So if for example a nation/company that has control over the manufacture of a large number of USB controllers decided they wanted to be able to do this kind of power analysis on all USB devices plugged into their controllers they could do so easily.

Esentially adding a micro controller with an Analog to Digital converter that can watch the power pin inside the USB controller/port itself would be relatively simple and cheap.

Although they don’t have 20MHz of bandwidth and the necessary sample rate there are USB3 power delivery controllers on the market today which do exactly that. Some even embed the microcontroller too.

Just like you can prevent a "paper wallet" from being compromised by not letting anyone casually look at it?

If I invested in one of these hardware wallets, I'd be interested in making it cost at least $X where $X is greater than the value in the wallet. I'd also like some time component, Y, that would allow me to transfer the money before the private key was found.

Cost $X to attack? That makes complete sense. And if you know the physical device is compromised then you can "break the seal" by restoring the seed phrase on another device to transfer the funds elsewhere before an attacker is able.

The main selling point of hardware wallets is that they can interface with an internet-connected device to sign transactions without exposing the private key to that device, which has a much larger attack profile.

That sounds like a work-around/mitigation, not a solution.

There's very few solutions to "physical access = game over".

There's a whole industry that's doing just that. Look up Hardware Security Modules. It is likely that you have a security device like that in the machine you are using right now (a Trusted Platform Module). People didn't simply threw their hands up, there are solutions for various problems in this space, with physical access being present in the threat model.

>It is likely that you have a security device like that in the machine you are using right now

funny you say that, because TPMs aren't actually mandated to be tamper resistant, only tamper evident[1]. what this means is that you won't be able to extract the keys without destroying the device, but if you delid the chip and probe it, you can probably extract the keys. I suspect it's the same with other HSMs you see in everyday life (smart cards, smartphone with trustzone, etc.).

[1] sorry i don't have a better source: https://media.ccc.de/v/32c3-7343-beyond_anti_evil_maid

Smart cards are tamper resistant by definition. See https://people.cs.uchicago.edu/~dinoj/smartcard/security.htm....

i did a quick skim of the article for "resist" and couldn't find anything to back your claim. all the article says is that smart cards have better security because they're isolated from the host (which is a security measure, but doesn't say anything about physical tampering resistance), and that some smart cards have tamper resistance built in.

For true tamper resistance you need to have some way to actually detect tampering and erase the secrets, which usually leads to some battery-backed SRAM and associated tamper response circuitry.

While there are some smart cards and smartcard-like HSMs (Fortezza comes to mind, but it uses the battery primarily for integrated RTC and seems to not contain any tamper detection mechanism) with integrated battery, common smartcards does not have battery.

If you'd like more evidence of what I'm saying, read Smart Cards, Tokens, Security and Applications or Secure Smart Embedded Devices, Platforms and Applications. Both are graduate textbooks covering smart card design and development.

The term "smart card" is frequently misused in popular nomenclature. As a technical term, it refers specifically to contact or contact-less (like NFC) cards with an embedded chip which are, at minimum, physically tamper resistant. For example, a typical credit card is not a smart card. A SIM card is a smart card (or token).

Tamper resistant does not imply tamper proof, which can also be a source of confusion.

There are different devices for different security needs. When you're protecting the key material for a revocable certificate, tamper evidence is sufficient: when you detect tampering, revoke the certificate. FIPS 140-2 Level 2 devices provide this level of security and are common in end-user credentials like smart card badges and the TPMs in laptops. FIPS 140-2 Level 3 provides tamper resistance meant to defeat most attacks, that's the device you'd want to use to protect a root of trust or important encryption key. Level 4 devices are meant to hold up against as many attacks as possible, even when the attacker can push the physical operating environment far outside normal bounds (solvents, liquid nitrogen, extreme heat, etc).

There's no absolute solution. But that doesn't mean that they shouldn't have protected against well-understood classes of attack. Vulnerability to an attack that needs 5 minutes of physical access would be much better than vulnerability to an attack that needs 30 seconds.

Reply on news.ycombinator.com