| > `blake2s(device-secret, program-binary, user-secret)` Ok, I think this is still a fairly standard situation. I understand it that the above quoted text represents the device's long term private key? If so... You can do this: - device derives a long-term public device key from the long-term private key - client generates a fresh public/private session keypair - client and server perform a Diffie-Hellman exchange, resulting in shared_session_key - client also verifies device's long-term public key is correct (a simple equality check) At this point the client and server now have a shared_session_key, and you're in standard territory. Next problems are replay attack prevention and forward secrecy. The two-birds-with-one-stone for that is for each side to: - generate fresh a ephemeral keypair - encrypt using the shared_session_key (with a random nonce) - perform another Diffie-Hellman exchange This results in a shared_ephemeral_key. This key can now be used to communicate securely, but you'll need to use incrementing integers as nonces for each message in the ephemeral session to prevent replay attacks. None of this needs storage. |
> I understand it that the above quoted text represents the device's long term private key?
The device owns an internal, inaccessible long-term 32-byte key called UDS. (I called it "device secret" in other comments.) The device contains fairly minimal firmware, primarily there to initialize the device and accept the bytes that are the program-binary.
When a program-binary is sent, it is written to memory. Then a secret is derived for the program, called CDI. Then device-firmware passes over control to the firmware-binary by jumping to the entry-point (IIRC).
`CDI = blake2s(UDS, blake2s(program-binary), 32-byte-user-secret)`. (Note: this is done in device-firmware and only the CDI is exposed to the program.
> You can do this:
I think here we're on the right track, but I'm guessing you're suggesting an rough idea. So, yeah, from the CDI one can derive a key for identity.
So the current protocol describes using that deterministically generated identity for authentication, and generate random bytes for deriving an ephemeral keypair for the key-exchange.
The client only needs an ephemeral keypair so relies on proper randomness only. (And it keeps a record of the identity public key, to verify its proof.)
> Next problems are replay attack prevention and forward secrecy. The two-birds-with-one-stone for that is for each side to:
I think these are not possible. Assuming (for this discussion) that your client is honest, you start off every session with proper randomness in your (unpredictable) ephemeral key. So from the first message on, replays are not feasible. Forward secrecy should be covered given that the whole session key, as it is established, is based off fresh input from randomness.
This, of course, leaves open the discussion on long-running sessions that keep using the same key without rotation. This is not addressed.