If an attacker controls your computer, there is always the possibility of a man in the middle, even if you use a Yubikey. The attacker could simply wait for a request to the HSM and intercept the response.
plaintext <-> crypto <-> blob <-> *compromised server/anything but quantum computing* <-> blob <-> crypto / YubiHSM
*my compromised PC* <-> plaintext <-> crypto <-> blob <-> crypto / Yubikey
My point is that I could securely "crypto" from my academic-dreamland/whatever secure computer through any transport to a YubiHSM connected to a compromised PC, if I trust Yubico (and the supply chain delivering their hardware) and the YubiHSM's initial/one-time setup.
1. A somehow convinces the remote party that the actual public key is X' instead of X. Ciphertext comes in, attacker decrypts it. Done.
2. A intercepts ciphertext, feeds it to Yubikey for decryption, and gets the resulting plaintext over USB (or whatever). Note: this is assuming that the Yubikey doesn't have encrypted filesystem support or similar.
Combining 1&2, A can use the Yubikey as an oracle to perform unlimited authentications, signing, and decryptions.
The only advantage provided by a Yubikey is that your keys cannot be remotely exfiltrated. Physical attacks on the hardware are still possible though.
It is true that hardware tokens without an integrated external I/O (not through the PC it is plugged into) are vulnerable to this type of attack during initial key setup. Maybe they should support using the indicator LED to morse code thumbprints or something, but if you can't trust I/O to the device during setup you're going to have a bad time. I will quote my original caveat here:
> Just plug it into a computer with a CPU you do trust first to get the official public key(s) for future verifications!
Your second point seems to be that the plaintext has to be exposed (either going in or coming out) at the USB/hardware interface level, which makes more sense to discuss. The sales page promises the following, but I didn't quickly find any details on how it works:
https://www.yubico.com/products/yubihsm/
Secure session between HSM and application
The integrity and privacy of commands and data in transit between the HSM and applications are protected using a mutually authenticated, integrity and confidentiality protected tunnel.
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.
I agree completely. It's just something to keep in mind.
I don't know about Yubikeys, but if they can sign their emitted plaintext, they could be used to similar effect.
The module only supported two interfaces:
1. Network -> Buffer, where it takes a packet with a particular structure and encrypted data and emits a signed plaintext.
2. Buffer -> Network, where it takes a request, result, and proof object and sends them out after signing and encrypting.
We were using it to front solvers that did a lot of work to solve constraints and emitted a proof object, so clients would send us requests (not our problem how they generate them) and then we had to show we did the right thing. The CPU didn't know either key, so it could either:
1. Compute the right thing, have results signed.
2. Compute something that doesn't match the signed request; have its faulty proof signed and returned. (Detected by the consumer when they verify.)
3. Fail to compute.
So this was guarding the case where a CPU was compromised and could possibly emit faulty (or malicious) results.
The point is that HSMs can allow for securing a computation chain if you can securely sign the root, even against compromised CPUs.
Most interactions with remote servers involve higher-level crypto primitives, but if a secure client has these keys it should be possible to interact securely with a remote YubiHSM (assuming secure initial setup, keys must remain secure, etc.).
As long as you mitigate the current exploit, you've stopped any forgeries from that point forward.