[Cyph0n]

I don't follow. Firstly, where is the encrypted request coming from? And more importantly, why would the CPU need to forge a request when it can just send an arbitrary plaintext to the HSM for signing (i.e., using the HSM as a signing oracle)?

[SomeStupidPoint]

How does it get arbitrary requests signed?

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.

[j_s]

The technical details need to be answered by someone with hands-on experience, but the YubiHSM1 manual documents use of AEAD (RFC 3610: Authenticated Encryption with Associated Data), and references AEAD/client keys required for two modes of operation (HSM/WSAPI). Also: truckloads of reminders to never re-use a nonce in AES-CCM.

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