[cobratbq]

The device I primarily had in mind is tillitis' TKey. Essentially a general purpose (slow) processing unit. The secret is 32-bytes long and given no storage, that's essentially all you work with. However, the secret is dependent on device + program-binary + 32-byte-user-secret.

A certificate is also a secret + certified public key, right? So, if you cannot store the certification on the TKey (no persistence) than you're left with the same construction. Right now, I'm skipping the complexity of certs (PKCS11, IIRC) etc. The identity being persistent is in order to authenticate the device.

[pclmulqdq]

> However, the secret is dependent on device + program-binary + 32-byte-user-secret.

If this is for anyone but yourself, you're going to need a certificate chain. An FPGA like the TKey can also store a significant amount of data in a ROM and you should have no problem storing it.

[cobratbq]

To check: did you realize that you plug this device in your USB port, then send a program to it, then start using the device with that program loaded? (This is at run-time, every time, right?) Because the secret is generated for this specific combination, different programs will also have different secrets.

I get that you would want to authn the hardware itself. If that is your point, sure, you're right. However, that aims to address a slightly different problem, because then the certificate chain is tied to the hardware only. Note that part of the charm of the _identity_ generated in the program, is that the identity changes if only a single byte of program-binary is different. So it protects from malicious binaries too. (But not bugs in the program itself.)