I've been comissioned to use TPM to add a licensing system to an existing software project. The idea is to use TPM to uniquely identify the computer (that runs GNU/Linux, probably CentOS/RHEL/Fedora) so that the license file can only be used in that computer. Before knowing about TPM we were going to use a composition of MAC address, motherboard ID and other serial codes present to try to uniquely ID the computer, but most of those weren't tamper-proof.

I've been reading about TPM but I'm a bit confused about the multiple features it seems to offer. As far as I know, using either the Endorsement Key or the an Attestation Identity Key is the key here (pun intended), but other than that I'm not sure how I should proceed or even if I'm actually correct in my approach. Maybe there's an easier way of doing what I'm looking for.

  • I can't answer your question, but I want to ask you a different one. Are you really doing your users any favors by doing this? Just remember, TPM isn't supported in any cloud for example.
    – Jesse K
    Jul 21, 2016 at 19:31
  • 1
    Note that TPM was only standardized in 2009 with version 2 in 2014. This means that the ecosystem is diverse and some older computers may not even have one.
    – AstroDan
    Jul 21, 2016 at 20:45
  • @JesseKeilson our product is not intended for a wide audience. It's a desktop app and we'll control the platforms where it's deployed, so we'll make sure TPM is available. Jul 21, 2016 at 20:51
  • This is a losing battle. It's impossible to protect an application from being copied by someone who has physical access to the machine. You can make it appear complicated, but an attacker only need to modify your application to skip the license check.
    – Lie Ryan
    Dec 19, 2016 at 10:49
  • I suspect the OP is aware of the trade-offs, and is looking for a standalone TPM based verification of unique identity.
    – TSG
    Aug 25, 2022 at 0:07

1 Answer 1


As you are going to run a open source OS, attestation will not work as reliably. The TPM will be able to attestate up to the loader of the OS, but after that, attestation becomes difficult as open source software is easy to modify.

I would suggest using the attestation identity key, to create a remote attestation signature (TPM_Quote) and then use a cloud service to host most parts of your application.

The client app just acts as a "dumb interface" to the cloud server, and the TPM_Quote is sent to the server as a "login". This can also be used to negotiate a "session key" that only the TPM and your server, can use to encrypt/decrypt.

This means that a cracker can copy your application until the cows come home, it wont matter, as your server will not accept a TPM_Quote from a tampered system.

This also makes it easy to revoke licenses if they are misused, for example if a customer is for example abusing a personal license by lending out RDP/VNC access to the computer to individuals outside of the customers premises.

Note that unencrypted application still needs to be available to the host OS, so regardless of which TPM features you use, it will still be crackable as long as the verification is done locally. Even if you use attestation with sealed storage and curtained memory, a cracker will still be able to crack the application, as sealed storage and curtained memory can only contain data, not executeable code. (yes, you can have executeable code in for example curtained memory, but for the host OS to be able to execute it, you need to move it outside of curtained memory).

Thats why you need to use a cloud service, so you can enforce the non-tampered state of the client computer from a central location that a cracker cannot physically access, and then host the application on this location, so even if the cracker has complete access to the client-side source code, they cannot take advantage of the service in question.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .