Hacker News Reader

Comment by popol12 | Hacker News Reader

Sounds like you have never used hardware wallets, these are not just a yubikey with a button to push and a notification diode. Having a screen is essential to display information about the transactions you're going to sign . Recent blockchains and new bitcoin signing schemes tend to have big chunks of data that require screen estate to be validated by the signer, so the bigger the better. The nano S and nano X screen were a pain to use with their super small screens, this improvement is welcomed. About Bluetooth, well, that's simply a transport layer, like USB. Pretty convenient when you want to trigger a transaction from your phone. People don't necessarily use these devices with a cable and a laptop.

I don't see a use for wireless charging. Maybe you can charge your wallet by placing it over your phone ?

View on HN

Bluetooth is a huge attack surface. Most Bluetooth stacks are something like 100k lines of C, written by electrical engineers. It's a nest of bugs and vulnerabilities.

There's probably more code in the Bluetooth stack than the entire rest of the code on the device.

Would putting the bluetooth stack on a dedicated IC be an adequate securiry measure?

I think the presence of any connection and data transfer is more important than the physical layout of the hardware. Compare, for example, baseband exploits.

Baseband exploits are as devastating as they are because at least until a few years ago, they've had full SoC memory access and as a result more privileges than even the operating system running on the SoC.

Treating the baseband more like a peripheral device and less as a coprocessor can prevent against much of this attack surface.

That said, just adding Bluetooth (even given a perfectly isolated stack) opens several unnecessary attack vectors, including a MITM between the wallet and the device driving it. This could be used to e.g. subtly modify destination addresses or transfer amounts.

Right. I'm not saying it isn't a reasonable hardening choice, only that it isn't a proof of security. It's table stakes for something claiming to be secure hardware in 2022.

The whole reason of the display on the device is to show both the amount and destination before signing the transaction.

Yes, a display is essential for the wallet use case.

But why make it such a large/complex one, that definitely requires more trusted hardware and software in the validation and confirmation path?

Their previous wallets did this much better, in my opinion. The Stax just seems flashy at the expense of security.

It might be, and it might not be. It's hard to say.

If your device can receive OTA updates via Bluetooth, no. If your device has a "developer" API, almost certainly no. If the two chips share a power rail, possibly not. Without serious thought to security of requests and responses (such that MITMs are impossible), no.

There are a lot of ways this can go wrong even with separate chips.

As OTA updates would be signed just like regular updates, can you detail how they would make Bluetooth less secure than USB ?

Yes, a compromised Bluetooth chip may be able to replay an old update or simply block a new one and leave you with a vulnerable version of your software.

First case you describe is not possible, there’s no downgrading possible on ledger ‘s OS, it’s up only

Second case would be obvious to user, he would see the failing attempts at updating.

This is worth a read if you haven't seen it:

pt 1: https://googleprojectzero.blogspot.com/2017/04/over-air-expl... pt 2: https://googleprojectzero.blogspot.com/2017/04/over-air-expl...

TLDR: Google research exploits wifi firmware of broadcom chip in iphone, then uses that to exploit a driver bug, and manages to root the iphone. All without even connecting it to a specific AP, just from broadcast packets.

Are there any clean (maybe open source) stacks out there?

Bluetooth is a wireless technology, and including it necessitates an onboard power source, a battery. This changes the security model a lot, an attacker now only needs proximity to the device, not physical access.

No, the attacker still needs physical access to the device, because signing requires on-device approval.

The security model already assumes that the entity requesting authorization is untrusted, so the security model is basically unchanged. An attacker who can forge BT packets to submit bad data for approval is not really different from an attacker who compromises the laptop/phone/etc to submit bad data for approval.

> No, the attacker still needs physical access to the device, because signing requires on-device approval.

You're assuming that the Bluetooth implementation does not introduce vulnerabilities that thwart this assumption; GP & GGGP are suggesting that you shouldn't have to make this assumption in a hardware wallet (or hardware that requires this very high level of assurance), by not including it at all. The same goes for, say, an attacker who's able to swap your wireless charger for a malicious one, and potentially execute a power usage-based side channel if you access the device while it's charging, or who's able to extract some useful information from the RF noise produced by the monitor.

The counterargument to this, in my mind, would be that you plan to use these features of the wallet regularly, and that they provide sufficient benefit to justify the risk (which you may argue is quite modest), and perhaps that you've implemented additional mitigations against them (like never using it while it's charging). Your argument about a monitor adding additional assurance in a sibling thread was quite good I thought, and a tact I didn't anticipate in this list originally.

Yes, but for this reason, the Bluetooth implementation is on physically separate, untrusted hardware that has no access to the buttons or screen other than by communication with the secure element (see [0] for the Nano X; I’m assuming the Stax will be basically similar).

So this isn’t really different from having a USB cable: in either case, some untrusted messages arrive at the secure element over some wires, and get processed there. The only difference is that the wires come from another chip on-device rather than from an external cable.

[0]: https://www.ledger.com/ledger-nano-x-bluetooth-security-mode...

> I’m assuming the Stax will be basically similar

I'd be surprised if that was the case. Nano X and S+ use the secure element for key operations as well as for user I/O (display and button control), which is significantly better than delegating that to a "main processor".

Given the complexity of driving a touchscreen and e-ink display, I think they might have had to return to that weaker "multi-chip" model (used in the original Nano and earlier and by many other hardware wallets), where the non-secure chip drives both the UI and I/O, rather than only latter.

Reply on news.ycombinator.com