| > I don't understand what option one has to do with any of this, if you can switch keys there's nothing any amount of extra hardware can do. In that case, just use the key you switched to. Take TLS/HTTPS as an example. The underlying assumption is that your browser's and/or OS certificate store are trusted. If an attacker compromises your machine and adds a new certificate to that "trusted" store, all secure communication is broken. That is the inherent weakness of public-key crypto. Back to the Yubikey scenario. Let's say a remote server R wants to talk to the Yubikey Y on your PC. Y initially generates a key pair and then (somehow) securely delivers the public key to the remote server R. Clearly, whenever R sends something to Y, an attacker wouldn't be able to decrypt the message unless it has the private key which is securely stored on the HSM. Scenario (1) above was looking at the case of an attacker who somehow "tricks" R into updating/replacing/revoking the original public key and inserting his own key into the remote key database. If successful, the attacker could then intercept all inbound communication from the remote server and decrypt it. > The sales page promises the following, but I didn't quickly find any details on how it works: It looks like marketing speak to me honestly. If the computer/server the Yubikey is talking to is compromised, there really is nothing stopping an attacker from using the Yubikey to perform arbitrary encryptions and decryptions. |
[edited] That is why I don't see this as relevant, it is outside the threat model any HSM attempts to protect against. More mitigation is possible than the YubiHSM provides, using a display/inputs on the HSM itself to verify keys and choose/confirm operations.
I appreciate your patience in carefully explaining your perspective, and this issue is definitely something to keep in mind in general.