Question

I’ve been asked to implement what amounts to a license-dongle using TPM for an x86_64 appliance which has a TPM chip. Essentially what is desired is to ensure that software released for the appliance can only run on the appliance itself such that if the software is migrated to a virtual machine or different hardware that it would refuse to function.

I don’t expect the solution to be reverse-engineering resistant, but rather a typical ‘dongle’ type solution where it will impede normal users and keep enterprise customers honest.

I have successfully built and included the TPM modules, as well as TrouSerS, and the openssl-tpm-engine code – I can successfully take ownership of the TPM but beyond that the available documentation doesn’t quite cover this use-case – or if it does I’ve so far been unable to find a plain english solution.

I’d prefer if possible to rely on the secret nature of the private keys stored in the TPM rather than utilizing the platform components hashes (a hard-drive may die, CPU may be replaced, etc.. I’d rather err on the side of the customer such that the system doesn’t become unusable after a routine hardware upgrade.

As well, ideally I suspect that this solution could be designed such that in manufacturing the public keys of each appliance are collected and added to a signing keychain so that the software could be signed against a single key that each appliance could have stored in the TPM, rather than requiring that the software be signed multiple times? I could be mistaken here but there has to be some bulk method of satisfying the platform authentication method otherwise it would seem very difficult to scale.

Answer 1

If the appliance is setup by you, you can follow this scheme:

A. Before shipping:

1. Take ownership – also creates a Storage Root Key (SRK)
2. Create a non migratable signing key
3. Store the wrapped key in the trusted keystore on the platform
4. Store the public key of the created key somewhere in your DB/file-system/what-so-ever

B. Preparing the application:

1. You have to ship the public key together with the binary of the application
2. I would not compile the public key to the binary, instead I would prefer to use something like a CA system where only the root CA public key is compiled. The public part of the TPM signing key can then be shipped as a certificate file. This prevents from compiling the binary for each appliance individually.

C. When starting the application:

1. Create a NONCE
2. Let the TPM sign the NONCE
3. Read the certificate and verify it
4. Extract the public key from the verified certificate
5. Verify the signature returned by the TPM using the obtained public key (and of course check whether the signed data equals the NONCE)
6. If the signature is valid => you are happy

Note 1: From a theoretical point of view this solution is insecure since the binary can be patched. You know that, so this should work.

Note 2: If the appliance is not setup by yourself, you can’t trust the public key a customer might give you.

---

Edit 1: explain certain points more precisely

@A.2: Since I use jtt & jTSS instead of TrouSerS I don’t know whether there is a command line tool included in the TrouSerS package to create keys. But I know for sure that it provides the proper API to do so. Anyway, jtt for example has a command create_key which does this. When you use this tool you’ll have the problem that the key store of jTSS and TrouSerS is AFAIK not compatible.

@A.3: No, there are no keys stored inside the TPM besides the Storage Root Key (SRk) and the Endorsement Key (EK). But the TPM guarantees that no private part of the keys belonging to the TPM will ever be outside the TPM in an unencrypted format. So you have a key-store which is somehow managed by a Trusted Software Stack (TSS -> jTSS, TrouSerS) that contains the encrypted key material. The TSS is also responsible for loading the proper keys in the TPM before using them for example for a signing operation.

@C*: The cryptographic part on the application side is quite standard. I don’t know how your knowledge in that field is. For the TPM part again the TSSs provide high-level APIs. I don’t know whether there are existing command line tools for signing with the TPM.