5 ms·

One of the rules of thumb for long-term key storage (especially secure hardware storage) is parsimony: you don't want any unnecessary hardware or software (both

One of the rules of thumb for long-term key storage (especially secure hardware storage) is parsimony: you don't want any unnecessary hardware or software (both because it makes the storage less resilient, and because it introduces additional security concerns). Given that, I'm not sure I understand why you'd put an e-Ink display (much less a JPEG parser, presumably, given the NFT stuff) on what should really just be an HSM. That seems like asking for trouble. Edit: Not to mention Bluetooth and wireless charging, apparently.

popol12 4y ago
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 ?
- friend_and_foe 4y ago
  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.
  - hdevalence 4y ago
    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.
    - maxbond 4y ago
      > 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.
      - hdevalence 4y ago
        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-model-of-a-wireless-hardware-wallet https://www.ledger.com/ledger-nano-x-bluetooth-security-mode...
        lxgr 4y ago
        > 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.
- pclmulqdq 4y ago
  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.
  - leni536 4y ago
    Would putting the bluetooth stack on a dedicated IC be an adequate securiry measure?
    - woodruffw 4y ago
      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.
      - lxgr 4y ago
        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.
        woodruffw 4y ago
        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.
        leni536 4y ago
        The whole reason of the display on the device is to show both the amount and destination before signing the transaction.
hdevalence 4y ago
If your secure hardware doesn’t have a display, how do you know what you’re signing? You can’t, so you’re forced to trust that the software talking to the HSM isn’t lying to you about what data it’s asking to be signed, and at that point you’re only marginally more secure than not using an HSM at all. (Sure, it’s harder to steal the long-term key material, but if I compromise your software, I get a signing oracle, and that might be good enough.) This is actually something that the blockchain ecosystem gets right: every hardware wallet has a secure display of some kind, to avoid blind signing, because it’s a context where security actually matters (unlike, e.g., “signing git commits with a yubikey”, which nobody cares enough about to attack).
- bonestamp2 4y ago
  Not to mention, you already trust github if your code is there, and you can typically get that code back from the git history, so it's not usually a big risk to authenticate with a yubikey.
- schmuelio 4y ago
  > unlike, e.g., “signing git commits with a yubikey”, which nobody cares enough about to attack I'm not so sure about this one, there's plenty of damage you could do if you were a malicious actor who could send trusted commits to a git repo. Especially if said repo were for some important software (like Linux, wget, glibc, etc. I know they're not necessarily on public repos but we're assuming at least somewhat targeted attacks here).
- woodruffw 4y ago
  > If your secure hardware doesn’t have a display, how do you know what you’re signing? I might be missing what you mean, but with a normal security module I control the inputs and outputs: the device only signs what I tell it to sign, and I can test it for honesty by verifying that any signature(s) I get back are actually signatures over the inputs I put in. That still requires me to trust that my interface to the hardware is the only interface, but that's the point of the parsimony (no bluetooth to worry about!). HSMs have plenty of problems (and I've encountered a good share of them from designing trust ceremonies), but I don't think adding a screen addresses any of them. If I was an attacker, the pins on an e-ink display would probably be much easier to tamper with than the secure hardware itself.

popol12 4y ago

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 ?

friend_and_foe 4y ago
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.
- hdevalence 4y ago
  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.
  - maxbond 4y ago
    > 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.
    - hdevalence 4y ago
      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-model-of-a-wireless-hardware-wallet https://www.ledger.com/ledger-nano-x-bluetooth-security-mode...
      - lxgr 4y ago
        > 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.
pclmulqdq 4y ago
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.
- leni536 4y ago
  Would putting the bluetooth stack on a dedicated IC be an adequate securiry measure?
  - woodruffw 4y ago
    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.
    - lxgr 4y ago
      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.
      - woodruffw 4y ago
        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.
      - leni536 4y ago
        The whole reason of the display on the device is to show both the amount and destination before signing the transaction.

hdevalence 4y ago

If your secure hardware doesn’t have a display, how do you know what you’re signing? You can’t, so you’re forced to trust that the software talking to the HSM isn’t lying to you about what data it’s asking to be signed, and at that point you’re only marginally more secure than not using an HSM at all. (Sure, it’s harder to steal the long-term key material, but if I compromise your software, I get a signing oracle, and that might be good enough.) This is actually something that the blockchain ecosystem gets right: every hardware wallet has a secure display of some kind, to avoid blind signing, because it’s a context where security actually matters (unlike, e.g., “signing git commits with a yubikey”, which nobody cares enough about to attack).

bonestamp2 4y ago
Not to mention, you already trust github if your code is there, and you can typically get that code back from the git history, so it's not usually a big risk to authenticate with a yubikey.
schmuelio 4y ago
> unlike, e.g., “signing git commits with a yubikey”, which nobody cares enough about to attack I'm not so sure about this one, there's plenty of damage you could do if you were a malicious actor who could send trusted commits to a git repo. Especially if said repo were for some important software (like Linux, wget, glibc, etc. I know they're not necessarily on public repos but we're assuming at least somewhat targeted attacks here).
woodruffw 4y ago
> If your secure hardware doesn’t have a display, how do you know what you’re signing? I might be missing what you mean, but with a normal security module I control the inputs and outputs: the device only signs what I tell it to sign, and I can test it for honesty by verifying that any signature(s) I get back are actually signatures over the inputs I put in. That still requires me to trust that my interface to the hardware is the only interface, but that's the point of the parsimony (no bluetooth to worry about!). HSMs have plenty of problems (and I've encountered a good share of them from designing trust ceremonies), but I don't think adding a screen addresses any of them. If I was an attacker, the pins on an e-ink display would probably be much easier to tamper with than the secure hardware itself.