32032141

Even if the firmware on both firmwares are completely virgin, this doesn't say much about the safety of the device. I agree that security is not all or nothing, protection in layers is always the goal of secure products. I do however caution that it can cause complacency if things are presented as bulletproof, you need to be up front about what tools such as attestation afford you. In this case it can not tell you that the device is safe or not tamptered with.

This is true. Many of these devices are using effectively joke crypto libraries however, theres a world of difference between something that needs a sophisticated setup, and the python crypto library that was transliterated into C and makes absolutely no effort at being constant time. The original Trezor software took something in the order of 300ms to produce a single signature. You could probably have done recovery of the nonce from ec multiply with a stopwatch.

If your security appliance is using an ECDSA library for Arduino that has absolutely zero tests or review, you just outright lost. Some of the more well known products in the space do exactly this.

https://github.com/kmackay/micro-ecc/blob/master/test/test_e...

Agreed. Researchers owe the companies absolutely nothing.

Ledger has for a long time been grossly inept in security, there's really nothing absurd about this attack at all. In the Bitcoin industry we frequently see very detailed setup for long timeframe attacks and substantial effort going into identity theft and physical compromise. Worse, for these deices in particular a backdoored device is almost undetectable due to the way ECDSA can be used to transmit encrypted data in its signatures.

Ledger was recently compromised, or showed that they have no release process (both equally bad) by releasing a version of their application which stole user funds. Their claim is that they released a development version from a dirty git clone that contained "testing" code which happened to have a hardcoded address for sending every transaction to.

https://www.ledger.fr/2018/08/03/important-message-concernin...

I've been doing security research in this industry for a while and it's effectively not worth anybodies time to attempt to report hardware wallet, or software bugs 'responsibly'. I've found that by far the most common responses are being told that the attack doesn't fit into their design (as here), it's not reasonable to expect, or that for some reason. For a long time the Trezor wallets custom crypto library was simply python transliterated and had a sidechannel attack so large that you could measure the EC multiply operation with a SDR from across a room. This was supposedly out of their scope (but has been since somewhat fixed, but not entirely) for some reason, despite being something that is easily fixed using industry standard constant time operations.

Responses you do get at protecting the fact that a lot of the bugs are burned into hardware and can't be fixed by anything but them re-issuing it. It's not in the interests to ever acknowledge issues.

This is largely the issue with 'hardware wallets', the security models aren't particularly well defined and this leads to ambiguity like this. You're absolutely correct in that the concern is the device is not genuine, which is what attestation of the firmware is supposed to prevent. In the case of the Ledger, the attestation doesn't prove anything about the safety of the device unfortunately for a number of reasons (this attack, and other logical ones).

The obvious one is that the security domains in the device are idiotic. There's a "secure" processor with almost no processing power or IO, and a "insecure" one which handles the screen, buttons and IO. Both of them handle secrets (for example, the seed shown on the screen), which leaves you with essentially no gain whatsoever.

The more logical hardware implant than the one shown at CCC is a bluetooth module that can simply read the I2C lines going to the screen and transmit the seed as a beacon whenever it is plugged in. This has the advantage of not needing presence as with their demonstration, and with assistance doesn't need any physical presence.

I described this as a concept for a security review of a cold storage setup which was "unbreakable". Is this sort of thing realistic? Perhaps. Is a $5 wrench attack more sensible? Probably. It's worth considering what supply chain attacks are possible though.