Hacker News Reader

Comment by hdevalence | Hacker News Reader

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).

View on HN

> 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.

The only way to be sure that your HSM is about to sign what you told it to is if it shows you what was sent to it to sign. Otherwise you’re trusting that something didn’t MITM between your computer and the HSM (eg: driver) such that you see one thing but end up signing something else.

I don't think this is true: I can be certain that my HSM signed what I wanted it to sign by verifying the signature against my known input. I know what I asked it to sign, so this is trivial.

A screen doesn't eliminate the necessity of this check; it's a pure convenience. And that's not to say that it's a bad one, per se, just one that is in tension with the normal key management desiderata (as few moving pieces as possible, as little code as possible, etc.).

> I can be certain that my HSM signed what I wanted it to sign by verifying the signature against my known input.

But what if, after checking, you realize that instead of "send $50 to $friend for dinner", you signed "send my life savings to $fraudster"? That's the main attacker model of cryptocurrency wallets.

That's the kind of attacker model I wouldn't invite in the first place!

But more seriously: I've never fully understood why this is such a common issue with cryptocurrencies. My understanding of how Bitcoin works is that you need to actually submit your transaction for inclusion in a block, meaning that you have ample opportunity to verify the transaction's correctness before offering it for submission. Why aren't hardware wallets encouraging that?

Where would you verify the transaction and potentially choose to not submit it?

If it's on your computer or phone, this means that you trust it enough to not need a hardware wallet in the first place.

If your computer is compromised, you can trust the attacker to take care of the submission for you.

> you have ample opportunity to verify the transaction's correctness before offering it for submission

I think the idea is malware on your computer could submit the signed, fraudulent transaction against your will.

How is the rest of the network supposed to tell the difference between you signing and submitting a transaction and you signing and then a malicious program on your machine submitting the transaction?

> with a normal security module I control the inputs and outputs

In the threat model that hardware wallets address, you don't, though. Your computer could be running malware that swaps your desired target address with that of the attacker, for example.

In that sense, they go beyond (low-level) HSMs by introducing a trusted user interface so that you can verify what you sign.

However, they arguably also fall short of really solving that problem: What are you going to compare the destination address to, if you can't trust your computer to correctly display it?

> 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).

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.

Reply on news.ycombinator.com