How do you implement the TPM license key platform on Linux?

I was asked to implement what constitutes a TPM license key for an x86_64 device with a TPM chip. In fact, it is desirable that the software released for the device can only work on the device itself, so that if the software is transferred to a virtual machine or other equipment that it refuses to work.

I do not expect that the solution will be resistant to reverse engineering, but rather a typical โ€œkeyโ€ solution that will discourage normal users and honest corporate clients.

I have successfully built and enabled TPMs, as well as TrouSerS and the openssl-tpm-engine code - I can successfully take charge of TPM, but apart from this, the available documentation does not quite cover this case-case - or if so, I still could not find a simple english solution.

I would prefer if you could rely on the secret secret of private keys stored in TPM, and not on the use of hashes of platform components (the hard drive may die, the processor may be replaced, etc. I would prefer err on the client side, so that the system will not become unusable after a regular hardware upgrade.

Ideally, I suspect that this solution can be designed in such a way that when making public keys for each device, they are collected and added to the signature key chain so that the software can be signed against one key that each device could store in TPM, instead of to require software to be signed several times? I could be wrong here, but there must be some kind of mass method of satisfying the platform authentication method, otherwise it would be very difficult to scale.

+4
source share
1 answer

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.

+3
source

Source: https://habr.com/ru/post/1394450/


All Articles