TPM Licensing: Architecture and Common Pitfalls

TPM-based licensing solves a real problem: how do you ensure your software only runs on authorized hardware, without a fragile license server in the critical path?

The core idea is simple — the TPM holds a key that never leaves the device. Your license is encrypted to that key. Only that device can decrypt and use it.

Architecture overview

A working implementation has three phases:

1. Device enrollment (factory or field)

During provisioning, the device generates an Attestation Key (AK) bound to its Endorsement Key hierarchy. The AK’s public portion is registered with your licensing backend, tied to a device serial number and SKU.

2. License issuance

Your backend issues a license blob encrypted to the device’s TPM public key using TPM2_MakeCredential. The device decrypts it using TPM2_ActivateCredential. This guarantees the license can only be activated on the device that requested it.

3. Runtime enforcement

On each startup, the application asks the TPM to unseal a secret (your license validation key) against a PCR policy. The PCR policy encodes the expected system state — if the firmware has been tampered with, PCR values change, unsealing fails, and the application refuses to start.

Common pitfalls

Pitfall 1: PCR binding sounds safe — it’s fragile in practice

PCR binding is the first thing people reach for: encrypt license to EK, seal secret to PCR policy, done. The problem is that PCR values change with almost every system event. PCR0 covers the bootloader — a firmware update invalidates all existing licenses. PCR7 covers Secure Boot keys — rotate certificates and you’re re-provisioning the fleet. In practice, PCR binding in commercial products creates more operational incidents than security benefits.

The practical alternative: bind to the EK alone, sign the license with your CA’s private key on the server side, and verify the signature on the device. The license is cryptographically bound to one TPM (only that EK can activate it), and a firmware update does not break anything.

Pitfall 2: PCR10 / IMA — the worst offender

If you do decide to use PCR sealing, exclude PCR10 entirely. IMA (Integrity Measurement Architecture) extends PCR10 on every executed file hash. Every application update, every library update — policy fails, device locks up. The only realistic use case for PCR10 in licensing is a completely locked-down device where no software ever changes, which is rarely the real world.

Pitfall 3: Unprotected TPM bus

On embedded boards where the TPM communicates over I2C or SPI, an attacker with a logic analyzer can read every command and response on the wire in minutes — including your unsealed secrets. TPM 2.0 supports parameter encryption via TPM2_StartAuthSession with TPM_SE_HMAC and a symmetric cipher. Use it. Without encrypted sessions, the physical bus is an open book regardless of your cryptographic architecture.

Pitfall 4: Treating tpm2-tools as production code

tpm2-tools is excellent for prototyping but calling shell commands from production code is fragile and slow. Use tpm2-tss directly — ESAPI for full control, FAPI if you want a simpler abstraction at the cost of some flexibility.

Pitfall 5: /dev/tpmrm0 open to all processes

If any process on the device can open /dev/tpmrm0, any process can issue TPM commands — including commands that impersonate your license manager. This enables a blind oracle attack: an unprivileged process crafts inputs, observes responses, and eventually reconstructs the secrets your application considers authoritative. Lock device permissions to the specific user or group your application runs as. On systems where your app runs in a container, this means explicit device access control at the container level, not just the host.

One important caveat: if someone gains root access to the device, these permissions offer no protection — root can re-open the device node or inject directly. TPM is not a substitute for OS-level security. Defense must be layered: hardened OS, no unnecessary services, proper user separation, and TPM as one component in that stack.

A related but separate topic: software obfuscation of the validation logic itself. If the code that calls the TPM is readable, an attacker can understand and bypass the check before any TPM command is issued. Most commercial obfuscators are broken quickly today with disassembler tooling and AI-assisted analysis. Virtualization-based obfuscation is significantly harder to reverse — but it is slow and adds complexity, so apply it only to the critical validation path, not the whole binary.

Pitfall 6: TPM relay and farm attacks

An attacker can intercept all traffic between your application and the TPM and forward it over a network to a single real TPM shared across many cloned devices. Each cloned device presents valid TPM responses — because they are. The defense is a TPM NV monotonic counter that increments on each license check. A response replayed from another device will have a stale counter value, which fails validation.

This is a real architectural choice: our own early designs explicitly skipped NV writes to simplify the implementation, and the trade-off is documented — the system is not resilient against TPM farm attacks. If your licensing value is high enough, the NV counter is worth the complexity.

Pitfall 7: NV index address conflicts

TPM NV indices are a shared namespace — the OS, TPM manufacturer, and other applications may already occupy the index you choose. Coordinate NV index allocation before integration, not after a production collision.

Pitfall 8: No key migration path

TPMs fail. If your license is permanently bound to a single TPM with no re-provisioning workflow, a hardware failure bricks the device from the customer’s perspective. Design the re-enrollment flow before it becomes urgent — ideally before you ship the first unit.

Designing a TPM licensing system for your product? We’ve built this for industrial devices — get in touch.