Hardware-Level DRM: Using TPM 2.0 and Secure Boot to Lock Down Model Weights

Every software license check shares the same weakness: it runs on hardware the operator controls, using a CPU whose instruction stream the operator can observe, and against a filesystem the operator can read. Once a model's weights land on a disk that someone else administers, "protection" implemented purely in software is really just an inconvenience. A root user can attach a debugger to the inference process, dump GPU memory, or copy the weight files directly and run them anywhere, license flag or not. This is true no matter how well-obfuscated the check is, because obfuscation is a delay, not a boundary.

The boundary has to move somewhere the operator's root access doesn't reach. That is what a Trusted Platform Module and a Secure Boot chain are for. They do not make weights impossible to extract in some absolute sense (nothing running on general-purpose hardware achieves that), but they change the threat from "read a file" to "defeat a hardware root of trust," which is a fundamentally different engineering problem, and one that Element 31's sealed appliances are built around from the board up rather than bolted on after the fact.

What a TPM actually is

A TPM 2.0 module is a small, physically isolated cryptographic co-processor. It has its own processing, its own memory, and, critically, its own key storage that the host CPU cannot read out directly. Keys generated inside the TPM can be marked non-exportable, meaning the private key material never exists anywhere the host operating system, a hypervisor, or an attacker with a live memory dump can see it. The TPM will use the key to sign or decrypt on request, but it will not hand the key itself to anything, including a request from an administrator account.

The other core TPM primitive is the Platform Configuration Register, or PCR. As the machine boots, each stage of firmware and each loaded component gets measured (hashed), and that hash is extended into a PCR before the component is allowed to execute. The result is a chain: the CPU microcode measures the bootloader before running it, the bootloader measures the kernel before running it, and so on. Because each measurement folds into the previous one, the final PCR values are a cryptographic fingerprint of the exact boot sequence that occurred. Change one byte of firmware, one kernel parameter, or the boot order itself, and the PCR values downstream come out different. There is no way to fake a matching PCR value without actually having run the matching software.

Sealing instead of checking

The practical technique that turns those two primitives into weight protection is called sealing. Instead of storing a decryption key for the model weights in a config file or an environment variable, both readable by anyone with disk access, the key is sealed to a specific set of PCR values inside the TPM. The TPM will only release that key if the current PCR values match the ones present when the key was sealed.

This inverts the usual license-check logic. A conventional check asks the software, at runtime, "are you licensed?", and the software can be patched to always answer yes. A sealed key asks nothing; it simply refuses to unseal unless the machine's own boot measurements prove that the expected firmware, bootloader, and kernel actually ran, unmodified, in the expected order. An attacker who patches the bootloader to skip a check, loads a different kernel to get root-level memory access, or boots from external media to mount the disk and copy files off it changes the PCR chain in the process, and the TPM simply will not produce the key. The weights on disk remain ciphertext.

This is the architecture Substrate uses underneath both Forge and Czar: the encrypted weight volume never has a plaintext key sitting anywhere on persistent storage, and the unseal operation happens once, in memory, as part of a verified boot sequence that the appliance owner cannot short-circuit without altering the very measurements the TPM depends on.

Secure Boot closes the gap TPM sealing leaves open

TPM sealing by itself protects the key at rest, but it doesn't stop someone from booting an entirely different, attacker-controlled operating system on the same hardware and simply never touching the sealed key at all, instead going straight for whatever else is reachable, or attempting to read GPU memory during a later legitimate inference run. That's the gap UEFI Secure Boot is designed to close on the front end.

Secure Boot works by requiring every executable loaded during boot, the bootloader, boot drivers, the kernel, to carry a cryptographic signature that chains up to a key embedded in the platform firmware itself. If a component isn't signed by a trusted key, the firmware refuses to execute it, full stop, before any operating system code has had a chance to run. Combined with a TPM measuring each stage anyway, Secure Boot and measured boot are complementary: Secure Boot is a gate that blocks unsigned code outright, while TPM measurement is a ledger that proves, after the fact and cryptographically, exactly what did run. An appliance that implements both makes "boot something else and go around the protection" and "boot the real thing but with one file modified" both fail, for different, overlapping reasons.

Where this still has limits

None of this claims to be unbreakable, and any credible technical discussion of hardware roots of trust has to say so plainly. TPMs have had documented bus-sniffing and fault-injection attacks against certain implementations and certain physical access scenarios; Secure Boot key material has leaked from vendors before; and a sufficiently resourced, sufficiently motivated adversary with unlimited physical access and lab equipment is a different threat model than an IT administrator with a shell prompt. What TPM sealing and Secure Boot change is the cost and skill floor of extraction, moving it from "anyone with sudo and a debugger" to "someone capable of hardware-level attacks against a specific chip," which is a different population of adversary entirely. Additional physical countermeasures (tamper-evident enclosures, potting, intrusion switches that trigger key erasure) are designed to raise the cost against that population further still.

This is also why the protection has to be paired with an integrity story, not just a secrecy one. A weight file that only decrypts after a verified boot is protected from casual copying, but the appliance also needs to guarantee that the model actually running is the one that was shipped, that inference isn't happening against a silently substituted or fine-tuned variant. The same PCR chain that gates key release also gives an appliance owner or auditor something concrete to check: the boot measurements are evidence, not a promise.

Why this matters more for on-prem AI than it did for on-prem software

Traditional on-prem software protection has decades of precedent (license servers, dongles, obfuscated binaries) because the thing being protected was executable logic, which is inherently harder to extract meaning from even once copied. Model weights are different. A checkpoint file is not obfuscated by its nature; given the weights and the architecture, the model runs, full stop, on any compatible hardware, with no reverse engineering required. That makes weights closer to a cryptographic secret than to a compiled binary, and it's why the protection scheme has to look more like key management (sealing, hardware roots of trust, measured boot) than like traditional software licensing.

For an ISV shipping its own model inside a sealed appliance under its own brand through a Chassis engagement, or for a buyer deploying Forge or Czar in an environment where the hardware itself is inside someone else's facility, this is the actual question underneath "is this secure": not whether there's a login screen, but whether the weights can survive an operator with a screwdriver and root access. TPM sealing and Secure Boot are the primitives that make the answer something other than "we're trusting you not to look."