I'm not sure if we're talking about the same things. I am not confident that I understand your comment well enough to confirm/reject, so I'm going to clarify for that reason.

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