7

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.

Charles
  • 50,943
  • 13
  • 104
  • 142
synthesizerpatel
  • 27,321
  • 5
  • 74
  • 91
  • I don't exactly understand what you mean by "signing the application". To my understanding a signature just proofs the integrity, but does not prevent unauthorized access in any way. So I don't get the point... – Scolytus Feb 03 '12 at 16:36
  • What I hope to achieve is proving that the hardware that the binary is running on is 'valid' hardware - if the hardware platform is unknown (not part of the signing chain or however it's supposed to work) the binary would not run. Obviously someone could modify the assembly to change a JE to a JNE to invert the behavior but thats not what I'm trying to stop. Just want to make it difficult to migrate the binary to an unsupported platform. – synthesizerpatel Feb 03 '12 at 18:05
  • Do you need any further information? – Scolytus Feb 26 '12 at 15:21
  • I do, I'm getting it using TrouSerS so I can answer the question without using the java toolkit. I'll accept your answer when I'm done documenting. – synthesizerpatel Feb 27 '12 at 00:56
  • Any progress on your documentation? – Scolytus Sep 24 '12 at 14:32
  • I'll just stop by time to time to see whether you need something else... ;) – Scolytus Mar 14 '13 at 16:15

1 Answers1

5

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.

Scolytus
  • 16,338
  • 6
  • 46
  • 69
  • Thanks for the concise answer - I added A/B/C headings to break up the sections as I have a couple more questions - I'm fairly new to trousers/TPM so I apologize in advance. How do I accomplish (A.2.), is that something I do using openssl? Any examples available? (A.3.) Is that in the TPM itself? For (C.*), are there any examples you could point me towards? I understand in an abstract way what is to be accomplished but if there's something I could derive from it would be ideal. Thanks again, at the very least I understand the lexicon to use when discussing the problem which is a big help! – synthesizerpatel Feb 03 '12 at 19:17
  • 1
    The instructions provided _almost_ got me where I needed to be, but definitely were 99% of what was necessary. I was able to do all the TPM work using the openssl stuff - the only caveat was there was a _bug_ in the openssl version I was using that had me stymied for weeks. I'm no longer at the job I did this project for, so I don't have access to my notes. BUT, I do commend Scolytus for his precise and excellent explanation. Kudos sir! Accepted your answer. – synthesizerpatel Mar 27 '13 at 09:35