If the device is configured by you, you can follow this scheme:
a. Before sending:
- Take ownership - also creates a root storage key (SRK)
- Creating a Transitional Signature Key
- Store the wrapped key in a secure key store on the platform
- Save the public key of the generated key somewhere in your DB / file system / something-never
B. Preparation of the application:
- You must send the public key along with the application binary
- I would not collect the public key in binary format, instead I would prefer to use something like a CA system in which only the public key of the public CA is compiled. The public portion of the TPM signature key can then be sent as a certificate file. This prevents compiling the binary for each device separately.
C. When starting the application:
- Create NONCE
- Let TPM sign NONCE
- Read the certificate and confirm it
- Extract public key from verified certificate
- Verify the signature returned by TPM using the received public key (and, of course, verify that the signed data matches NONCE)
- If the signature is valid => you are satisfied
Note 1: From a theoretical point of view, this solution is unsafe, since the binary file can be fixed. You know this should work.
Note 2: If the device is not configured independently, you cannot trust the public key that the client can provide you.
Edit 1: explain more accurately some points
@ A.2: Since I use jtt and jTSS instead of TrouSerS. I do not know if there is a command line tool included in the TrouSerS package for generating keys. But I know for sure that it provides the appropriate API for this. Anyway, jtt, for example, has a create_key command that does this. When you use this tool, you will have a problem that the jTSS and TrouSerS keystore is incompatible with AFAIK.
@ A.3: No, there are no keys stored inside the TPM except for the storage key (SRk) and approval key (EK). But TPM ensures that no private part of the keys owned by TPM will ever be outside the TPM in an unencrypted format. Thus, you have a keystore that is somehow managed using the Trusted Software Stack (TSS โ jTSS, TrouSerS), which contains encrypted key material. TSS is also responsible for loading the correct keys into the TPM before using them, for example, for a signing operation.
@C *: the cryptographic part on the application side is pretty standard. I do not know how your knowledge in this area. For the TPM part, again, TSSs provide high-level APIs. I don't know if existing command line tools exist for signing up with TPM.
source share