LWN: Comments on "Don't fear the TPM"

Yes for DRM

nim-nim — Thu, 28 Aug 2025 15:21:26 +0000

> I'd have more trust in the security of an anti-cheat driver whose primary goal is to resist hostile adversaries

It’s not designed to resist hostile adversaries in a general sense, it’s designed to resist abuse within the game. The anti cheat devs would not care less about all the other ways their driver could be abused.

Suse

leromarinvit — Fri, 15 Aug 2025 22:24:57 +0000

Yes, GRUB will measure every action it takes, which makes measured boot challenging (see e.g. https://github.com/fedora-silverblue/issue-tracker/issues...). I gather that's at least part of the reason SUSE switched to systemd-boot (for MicroOS at least), which is more predictable in this regard.

a meaningful subject line

raven667 — Fri, 15 Aug 2025 18:40:32 +0000

>> generate asymmetric keys, such as SSH keys or signing keys, on the device that cannot be exfiltrated

> But why would I want to do that? I want to back up these things to my normal backup storage.

> its use demonstrates that a user has access to a specific piece of hardware

> But what’s the use? Hardware goes kaputt. I can quickly obtain a replacement, restore onto it and things work as before, if I don’t use the TPM for/like that.

Not everyone has the same security requirements, for a fancier HSM the answer to backup/restore is cutting the key into chunks and storing parts of the key on smartcards that are distributed to multiple people requiring some number of them to come together to combine their key parts into a whole signing key. For more everyday situations with something like a Yubikey the answer can be buying two of them, and enrolling both everywhere you need it, then storing one safely as a backup. For something protected by a TPM like on-disk encryption you can use normal backup methods for the data while the system is unlocked and accessible, with whatever encryption policy for the backup you want separate from the host full-disk-encryption, knowing that if the hardware breaks, or the key is intentionally destroyed, the data is inaccessible even if the disk/nvme itself is "fine". I'm would guess for things like TPM you don't have to create the key on the TPM, I think you can create a private key on the host and push it into the device one-time as a write-only operation, similar to how a Yubikey can store some number of TOTP/HOTP tokens. I thought Passkeys worked the same way but it seems that there are mechanisms to sync the actual private keys between devices, or transfer them during device upgrades, rather than enrolling each device under your control with a separate hardware-locked key into each service doing key-based auth. The security properties of a key embedded in a physical object are easier to reason about though, no amount of OS-level RCE bug can remotely access a key sitting on my desk, it would take literal ninjas coming through my walls which is a whole different thing.

Suse

claudex — Fri, 15 Aug 2025 15:46:57 +0000

I'll understand better the challenge. I have grub on the system where I checked, and this mean that all the parsed config is an event for the PCR8. With things like:

> Raw: grub_cmd: [ xy = xy ]\000
> Raw: grub_cmd: insmod all_video\000
> Raw: grub_cmd: set gfxpayload=keep\000

So it'll be challenging for a program to predict it. However, it should works to script it since I know what should change, so I'll try to predict it for my system. But it can't be easily done without UKI at a distribution level, even with the hash of the initrd.

Use case for TPM-tied credentials

farnz — Fri, 15 Aug 2025 11:06:59 +0000

> its use demonstrates that a user has access to a specific piece of hardware
But what’s the use? Hardware goes kaputt. I can quickly obtain a replacement, restore onto it and things work as before, if I don’t use the TPM for/like that.

The use case is hardware that can be tampered with by an attacker in some way; if the attacker images your disk, then the TPM-backed secret doesn't let them decrypt it, and they've gained nothing. If you've set up a measured boot system, with the TPM only releasing symmetric keys when the measurements are correct, then the attacker also can't tamper with your system to exfiltrate data without you losing the ability to use that hardware for the intended purpose.

And you can still replace the hardware in this situation - it's just that instead of being able to take a HDD/SSD out of a failed machine and plug it into a new machine, you have to create new secrets on a new machine and restore from a securely kept backup. All you're doing is stopping an attacker from being able to do the same if they can borrow your laptop while you're (e.g.) drinking coffee with friends.

Underlying this is that it's only useful in cases where you need a guarantee that the user has access to a machine which has not been tampered with since you last verified its trustworthiness via physical access; my work laptop has FDE keys in the TPM so that I can boot without network available, but I need an alternative keying method (e.g. access to a secured physical network, a FIDO U2F device, a long passphrase) to get in if my device appears to have been tampered with (even if I did the tampering). My home server, however, is physically secure, and does not use a TPM to boot.

Suse

Cyberax — Thu, 14 Aug 2025 05:50:32 +0000

> I don't understand why the UKI is needed.

It simplifies the checking logic. You just need to verify one binary that has everything and then chainload into it. With classic initrd you also need to measure it (and the kernel cmdline).

a meaningful subject line

mirabilos — Wed, 13 Aug 2025 19:21:44 +0000

> generate asymmetric keys, such as SSH keys or signing keys, on the device that cannot be exfiltrated

But why would I want to do that? I want to back up these things to my normal backup storage.

> its use demonstrates that a user has access to a specific piece of hardware

But what’s the use? Hardware goes kaputt. I can quickly obtain a replacement, restore onto it and things work as before, if I don’t use the TPM for/like that.

Also, the RNG on TPMs is notoriously bad; the baseline for such an RNG is incredibly low (PRNG with “unknown and not exfiltratable seed” suffices), there’s no guarantee for entropy. (Full disclosure: I have written software to use a TPM 1.2, to read from its RNG and put this as *additional* source into the kernel entropy pool. Never as single source.) This is another good reason why a TPM should never be used to generate any cryptographic key, its random bits are not much better than those of plastic router boxen. Always let the OS do it — and not just Linux /dev/urandom with its crippled pool size either. touch ~/.rnd and then put 「openssl rand -rand ~/.rnd -writerand ~/.rnd 4 >/dev/urandom」 into your crontab, run it at least hourly. Over time, enough entropy will amass in ~/.rnd (each call also reads from the kernel and mixes that into the seed file), and a few bits will also find their way back to the kernel each call, which is not a bad thing either.

> 2048-bit RSA keys

Right. It’s called baseline for a reason…

> AMD's integral TPM has some problems with the random-number generator

*cough*

> everyone builds their own initrd

Better that way. I can include things to set up the network so I can unlock LUKS via SSH ;-)

But good to know that dracut is not something one wants to play with, I’ll stick to initramfs-tools as well then.

(OT: the plain text format doesn’t do quotes well, apparently ☹)

Yes for DRM

pizza — Wed, 13 Aug 2025 13:13:10 +0000

> Or, for even more sophistication, my hardware device sits between the discrete TPM on my gaming motherboard and the mobo connector, and simply filters out TPM commands that would show that my cheat driver is present -

There's a lot of precedent here; most so-called console "modchips" work this way.

Yes for DRM

farnz — Wed, 13 Aug 2025 09:38:17 +0000

The userspace on the clean system is under attacker control; kernelspace (and thus userspace) on the dirty system is under attacker control. How do you propose to allow the userspace code on the dirty system to ask for a secret in such a way that the kernelspace on the dirty system can't proxy the request to a userspace process under its control on the clean system, and proxy the result back?

More generally, given that I can buy TPMs off the shelf (e.g. this TPM 2.0 evaluation board), what stops me from having a custom device that gets sent the same sequence of TPM 2.0 commands as a "real" TPM on a motherboard (hence has the "correct" hash values - all I need is a motherboard with an external TPM, such as the ASUS ROG STRIX TRX40-XE GAMING, where I can intercept the SPI bus to a discrete TPM and see what happens), but isn't actually reflecting the state of the "dirty" system?

Or, for even more sophistication, my hardware device sits between the discrete TPM on my gaming motherboard and the mobo connector, and simply filters out TPM commands that would show that my cheat driver is present - relying on my cheat driver modifying kernel data structures like the log to agree with the TPM.

Suse

claudex — Wed, 13 Aug 2025 08:35:48 +0000

Thanks, I didn't know this tool. I'll try it and report my finding if I obtain meaningful result (positive of negative).

Suse

leromarinvit — Wed, 13 Aug 2025 08:11:16 +0000

This blog post describing an early draft of the feature also doesn't mention NV. It seems to me the requirement came as an implementation detail based on how the systemd folks chose to implement it. I can understand that it's likely easier to argue about from a security perspective that way, and given that newly developed features tend to mostly be deployed on rather newer hardware than the old stuff that doesn't support NV, I can see why they did it that way.

Suse

leromarinvit — Wed, 13 Aug 2025 08:02:21 +0000

This is also how I understand systemd-pcrlock's manpage:

lock-kernel-initrd FILE, unlock-kernel-initrd
Generates/removes a .pcrlock file based on a kernel initrd cpio archive. This is useful for predicting measurements the Linux kernel makes to PCR 9 ("kernel-initrd"). Do not use for systemd-stub(7) UKIs, as the initrd is combined dynamically from various sources and hence does not take a single input, like this command.
This writes/removes the file /var/lib/pcrlock.d/720-kernel-initrd.pcrlock/generated.pcrlock.
Added in version 255.

But like I said, I wasn't able to try it out, so I'm not really qualified to say if it works that way.

Suse

claudex — Wed, 13 Aug 2025 07:55:41 +0000

I don't understand why the UKI is needed. This allow to have a known value. But why can't it work with a classic initrd with the value computed on the host where it is generated ?

Suse

cyphar — Wed, 13 Aug 2025 07:06:27 +0000

This feature works using UKIs (Unified Kernel Images), which bundle the UEFI boot stub, kernel image, permitted command-line(s), optionally an initrd, and some other resources. This produces a single PE binary that can be signed as a bundle and verified. The idea is for the UKI to be produced by the vendor of your kernel updates, and because there isn't an initrd that is being re-generated on the users' machine, you therefore can predict the PCR values that will be loaded when booting it -- so when updating the updater can rebind your TPM-sealed LUKS keys to the new PCR values.

This doesn't require changing the PCR values you bind your TPM-sealed keys to (if you already do this today) -- in fact, it allows you to require more PCR values for your LUKS key to be unsealed because more of the boot chain is predictable and it avoids the kinds of attacks you mention.

Yes for DRM

mjg59 — Wed, 13 Aug 2025 01:17:36 +0000

You can also just plug in a second TPM and give it whatever set of measurements you want…

Yes for DRM

SLi — Wed, 13 Aug 2025 00:53:36 +0000

> Remote attestation, as offered by the TPM, allows you to confirm that the user has access to a clean system, but not that the processes involved in attestation are actually running on that clean system.

Yes, this is true. But I think there's another fix besides what you suggest. The remote is now able to encrypt secrets so that only the clean system can access them. Because it's a clean system, it presumably won't leak them to the unclean system. This can be used for DRM (and is the common way to do DRM, I would claim). Typically you give the clean system a key to access encrypted secrets.

Who holds the keys?

Wol — Mon, 11 Aug 2025 18:25:49 +0000

The problem with the "dumbing down" of language (in general) is that it makes clear communication impossible.

For example - in the realm of computers - the number of people who now just talk about RAM. With no clue whether it's actually RAM, or disk. (Made even worse now by those systems that have matching RAM and SSD, 32GB of each maybe.)

Or the COMPUTER LECTURER who re-purposed "real time" to mean "interactive". I had a bit of a go at him but he was unrepentant. And now, twenty years on, I'm working in an industry when real-time errors (that's real real-time) are a major cause of errors and real physical crashes that damage equipment and take systems out of service for hours at a time ...

> Probably for a non-expert, it's close enough to make sense.

The problem is when the non-expert NEEDS to understand the issue, at which point the fact they can't even use the words correctly becomes a MAJOR problem.

Cheers,
Wol

Who holds the keys?

intelfx — Mon, 11 Aug 2025 17:46:52 +0000

> I think what's happening here is that TPM seems to be becoming a generic name for all HSMs

At most it might be this way for HSMs _integrated into the platform_ (as reflected in the name, Trusted _Platform_ Module).

There is a variety of pluggable (PCI, USB) HSMs and, to my knowledge, nobody is trying to call them TPMs.

Yes for DRM

farnz — Mon, 11 Aug 2025 16:13:20 +0000

The core problem is that, having loaded a "bad" driver, the bad driver can lie through its teeth to the game client. Once the bad driver is loaded, it is, for all reasonable purposes, part of the kernel, and can (for example) redirect the "execute this binary, protecting its memory from everyone else, and attest to it" API to let it launch the binary on the clean system, and attest to the signed attest from the clean system.

Underlying this is that as soon as the "bad" driver is loaded, the OS is in a known-bad state, and anything running on that OS can't trust it. Remote attestation, as offered by the TPM, allows you to confirm that the user has access to a clean system, but not that the processes involved in attestation are actually running on that clean system. This is irrespective of the OS; once you have an untrusted system that has full userspace access to a clean system, you can get the attestations from the clean system, and send them back in place of the attestations that you can get from your "dirty" system.

The fix is to not support general systems; either the "dirty" system's kernel space must be locked down so that you cannot run "unwanted" but signed drivers (games console model), or the "clean" system's user and kernel space must be locked down so that the "dirty" system can't run arbitrary userspace on it to get attestation answers from the clean system.

Yes for DRM (but possibly not on Windows, at least in the current state)

SLi — Mon, 11 Aug 2025 16:02:33 +0000

Ok, apparently, looking into what Windows does (and I may still be wrong):

- Windows really stops the measurement chain mostly early, i.e. what ends up in the PCRs is firmware and bootloader measurements and some info about the OS loader and early kernel init.
- Crucially, I think it *doesn't* routinely post-boot driver loads, which obviously breaks the chain if you can load your own driver (so you can only reliably attest to what happened in early boot).
- Device Health Attestation (DHA) apparently can attest to: 1) if Secure Boot is on or off; 2) BitLocker status; 3) Code integrity policy (whether kernel-mode driver signing is enforced); but it does not give you a hash of every loaded driver.
- Anti-cheat vendors rely more on the driver signing enforcement and their own kernel driver scanning, not PCR measurements (and that obviously can be subverted by drivers loaded before the anti-cheat driver, even if not easy), plus hardware identity (from TPM) for bans.

So, I would claim that locking down the system at a level where a game vendor can reliably blacklist drivers is doable using a TPM, but it would require a future version of Windows to start measuring all driver loads.

Who holds the keys?

SLi — Mon, 11 Aug 2025 15:46:54 +0000

I understand how the proper use of terminology seems and is important, but I also think "TPM" is much better known a name than "HSM", and I think what's happening here is that TPM seems to be becoming a generic name for all HSMs. A bit like kleenex, aspirin or escalator. Probably for a non-expert, it's close enough to make sense.

Yes for DRM

SLi — Mon, 11 Aug 2025 15:38:36 +0000

Yes, this could be possible. The normal way to do this with e.g. DRM protected content is to design the system so that in a clean system you cannot extract some secrets—for example, in a video player the system gets access to a media decryption key and promises to leak neither that key or decrypted data, and that promise is backed by either doing the processing in hardware (easier to contain) or guaranteed by the OS.

I think that at least if the game loads a kernel driver, this should be doable, assuming really a "clean system", and I admit that with the current technology that's not really easy if you need to support tons of hardware—but that's where blacklisting bad drivers could come into play. And certainly some kernel APIs could be designed for doing something like this from the user space; at the simplest, something like "execute this binary, protecting its memory from everyone else, and attest to it". The kernel would then have a function `attest(nonce)` that gives the process a signed attest that:

1. This is an .exe with hash $hash
2. I started it so that its memory is not accessible from outside
3. The TPM state is $state (signed by the TPM, nonced by the nonce)

(1) and (2) are guaranteed only by the OS being in a known good state, which is the weakest link. (3) is guaranteed by the TPM.

... but I admit that at this point, speculating about what Windows does or could do, I am a bit out of my depth. I know TPM well enough as a concept to believe that this is something it should enable. I should probably go read about how it's really used by Windows; I only know the period until the bootloader starts pretty well, and I have some idea about how systemd uses it on Linux.

Yes for DRM

farnz — Mon, 11 Aug 2025 15:16:16 +0000

If the cheat system really wants to push the limits, you have two systems; one is clean, and can answer all the TPM queries you want answered. The second runs the dirty driver, which redirects your TPM log request across to the clean system, gets you a verified answer (which passes, since the cheat code is in userspace on the second system) and returns it as-if it came from the dirty system.

The result is that you've correctly proven that the clean system exists and is in the control of the user trying to cheat. But that's not what you wanted to know - you wanted to know that the system you are running on is the clean system, and not the dirty system.

Yes for DRM

SLi — Mon, 11 Aug 2025 14:58:47 +0000

I don't think that's true. The log is protected by the state of the TPM which you cannot rewind. The protocol would go something like this:

1. Client: Please give me access to the game server!
2. Remote: Ok, let's see. Tell me who you are and show me your TPM logs. Here's a challenge nonce.
3. Client: I'm a TPM by FooCorp. Here's the certificate from FooCorp for my public key. And here's your challenge nonce to prove that this is not a replay. Here's the TPM logs. I have attached a signed attestation with your nonce from the TPM that my PCRs correspond to what the log says.
4. Remote: Excellent, looks clean. You are welcome.

Now of course if nothing else prevents it (i.e. there's no mechanism to, for example, for the game to get a notification if a driver is about to be loaded), the game server can just ask you to periodically reattest that you are still in that state or to provide the logs up to the state where you are.

Now what is logged in those measured logs is of course up to the operating system, but it definitely should contain a hash of the driver and most likely other information about its provenance (if it's signed, who has signed it, size, filename, other metadata, hash). The game server could even theoretically require you to send the unknown driver for analysis (they know its hash).

Passkeys

tekNico — Mon, 11 Aug 2025 10:48:36 +0000

> integrating a tiny numeric keypad into your security key. Nobody does that as far as I have heard of.

The Trezor hardware wallets do that.

Make Passwords a Thing of the Past
FIDO2 Is Now Available on Trezor Model T
https://blog.trezor.io/make-passwords-a-thing-of-the-past...

Yes for DRM

farnz — Mon, 11 Aug 2025 09:40:32 +0000

The problem is that such a log could be truncated by the rogue driver - you remove the last entry when you load (which you can do, since you're in kernel space - albeit you may need a helper app to tell you what the log "should" look like without you), and now it's impossible to distinguish this attested log from one on a system without the rogue driver.

The protection against rogue drivers is via driver signing; if the driver is signed, it's trusted. Once it's loaded, it can rearrange memory so that everything looks plausible for the situation where the driver was never loaded, including resetting logs and changing flags to hide itself.

Yes for DRM

SLi — Sun, 10 Aug 2025 20:02:07 +0000

Does this mean that Windows does not maintain a (measured) log of what it loaded that can be attested to? This would still provide the game company hashes and probably some level of other self provided identities of the drivers, attestably at least until the rogue driver, which seems to provide at least some kind of a plausible target for blacklisting.

Yes for DRM

Cyberax — Sun, 10 Aug 2025 19:57:02 +0000

You can disable secure boot, enable the unsafe mode in Windows, install the rootkit, and then re-enable the secure boot.

Windows will happily re-measure the boot chain with the rootkit. The values of TPM registers will be different so you will lose access to any previously sealed secrets, but there's no way for the anti-cheat driver to pre-compute the "correct" values.

It's possible in theory to build a robust DRM system with the TPM, but it requires coordination and periodic updates for all the PC manufacturers.

Yes for DRM

SLi — Sun, 10 Aug 2025 14:02:45 +0000

Isn't it used to measure them, though? Or if not, at least I think it could be (I know that before bootloader they are, have no idea what Windows does). And of course logged in a TPM log or an operating system equivalent of one, which together with measuring means that a game server can require you to provide the logs from the power on moment to the present and use the TPM to attest that that corresponds to your current measurement state. This means that the game company would see at least the hash of a driver that allows a compromise, given a successful attestation.

Yes for DRM

Cyberax — Sun, 10 Aug 2025 02:22:17 +0000

The TPM is not used to verify the exact set of loaded drivers. And once you get access to the kernel-level IO, you can install a "forever rootkit" that would virtualize the real IO, hiding the rootkit from the OS and patching the code used to detect it.

This is doubly easier because the rootkit doesn't have to hide from the computer's owner.

And this is not a theory, the current generation of most advanced cheats (e.g. https://blurred.gg/guides/info ) works like this, along with DMA-based RAM snooping. As I understand, the custom rootkit keeps the IOMMU disabled for the DMA engine to work.

Yes for DRM

SLi — Sat, 09 Aug 2025 17:05:04 +0000

I think there's an important distinction to be made between vulnerabilities in drivers or other software and the entire model being broken. Even in the practical sense. If one driver has such a vulnerability and people start to abuse it, 1) it can be fixed, 2) the game company can just start requiring that the attested chain does not contain that (potentially old version of) the driver.

This is different from if there's a fundamentally unpluggable hole that you can exploit by e.g. running a specific EFI binary before booting. In the first case, detecting and fixing this is possible. In the second case, you can exploit weaknesses in the exploit to try to detect it, but those should generally be patchable and (near-)perfection is attainable.

Blacklisting drivers known to be used for cheating is _much_ easier than whitelisting everything that should be allowed.

Yes for DRM

mb — Sat, 09 Aug 2025 16:30:07 +0000

>Doesn't the same potential exist for all drivers?

Sure. That's why such code in the trust chain must be minimized instead of adding code to try to prevent kiddies from cheating.

This chain of trust doesn't work in practice, because there probably are tens of millions of lines of code that must be trusted between the root of the trust in UEFI and the trusting application in userspace.
IMO this technique is fundamentally flawed.

>I'd have more trust in the security of an anti-cheat driver whose primary goal is to resist hostile adversaries, than a random driver for e.g. my keyboard LEDs where the developers probably had no interest in security and never expected to be attacked.

Yeah, well. The keyboard driver is present regardless of whether there is an anti-cheat driver or not.
Adding an anti-cheat driver can only weaken the system as a whole, if it contains a bug.

Yes for DRM

excors — Sat, 09 Aug 2025 16:07:14 +0000

> I'm not sure if Microsoft is willing to sign those drivers

They are: "The driver has been signed by Riot’s own EV cert, which has in turn been signed by Microsoft as per their code signing process." (https://www.riotgames.com/en/news/a-message-about-vanguar...)

> there is a lot of potential for abuse if somebody manages to extract the driver and convince it to behave slightly differently than intended

Doesn't the same potential exist for all drivers? I'd have more trust in the security of an anti-cheat driver whose primary goal is to resist hostile adversaries, than a random driver for e.g. my keyboard LEDs where the developers probably had no interest in security and never expected to be attacked.

Yes for DRM

NYKevin — Sat, 09 Aug 2025 06:14:52 +0000

> This means that a TPM can attest that the boot chain only contained Microsoft-signed elements in an unforgeable way to a game server, which basically means that you don't have cheat tricks in your kernel.

The problem with this idea is that most of these games are already using their own kernel drivers to snoop on players and (supposedly) prevent cheating. I'm not sure if Microsoft is willing to sign those drivers - there is a lot of potential for abuse if somebody manages to extract the driver and convince it to behave slightly differently than intended.

Passkeys

NYKevin — Sat, 09 Aug 2025 06:03:45 +0000

> The problem is: To do true user-presence-confirmation, you'd need a trusted link between your sensor and the secure element; either via a dedicated non-programmable signal path that can be set to true if presence is confirmed, or some kind of cryptographic pairing and sealed channel between the sensor and the secure element.

There's a very straightforward way of doing this. It's called "stop using TPMs to do things that security keys were designed to do." A security key integrates the sensor into the same hardware that has the chip, so the path is indeed trusted unless somebody has physically opened the key (which is rather difficult to do remotely, hence making it good enough for verifying non-authenticated user presence, which probably sounds pointless, but is quite helpful in slowing down a remote attacker's lateral movement through a large network).

Of course, the downside is that it is much easier to steal a security key than to desolder and run off with a TPM. But one could easily imagine a setup where the security key is permanently attached to the device instead of hanging off a USB port. Still not as secure as something soldered directly to the motherboard, but life is a series of tradeoffs, and you can always treat the passkey as a second factor (in addition to a password) if you're paranoid.

Unfortunately, the story with PINs is much more grim. If you don't trust the OS (and hardware, and firmware, and the Intel Management Engine that everybody keeps telling me is "probably fine," etc.), then the OS can keylog them, and there's basically nothing you can do about it, short of integrating a tiny numeric keypad into your security key. Nobody does that as far as I have heard of. OTOH, if you're really worried about this class of attack, then you probably work for a three-letter agency.

> Funnily enough however, afaik even macOS doesn't implement this security level for passkeys atm; the user can also simply enter their password instead without ever touching the fingerprint sensor.

Passkeys were not and have never been intended as a full replacement for passwords in all circumstances. They are intended to make passwords the backup flow, not to remove them entirely. It is good and proper for macOS to accept a password in lieu of a passkey.

Yes for DRM

Cyberax — Fri, 08 Aug 2025 18:56:50 +0000

> Valorant does use TPM remote attestation to some extent

TPMs are not well-suited for remote attestation. They can attest that the running software is the same as it was at some point in the past, but you can't pre-compute the expected hash values for an arbitrary PC.

This is fine if your goal is to protect a corporate laptop, as you can guarantee that you install the software in a clean environment. But a dedicated cheater can start subverting the system during the installation so it's _never_ in a clean slate state.

Though it certainly makes attacks much more complicated, which is the end-goal for the anti-cheat protections.

Passkeys

muase — Fri, 08 Aug 2025 15:38:05 +0000

Good point – I didn't distinguish between FIDO2 hardware-backed keys (=non-exportable), and syncable passkeys in my mind. You're completely right – with passkeys, as opposed to "classical" FIDO2 keypairs, the passkey needs to be usable outside the SE; and while you could enforce true user-presence-confirmation for unsealing the passkey, it would be kinda pointless.

Future of DRM

SLi — Fri, 08 Aug 2025 10:54:42 +0000

I see currently two plausible avenues for DRM if the industry coalesces around them.

The first one indeed uses TPM and Secure Boot to require that you're running approved software only at the kernel level. If it controls everything from bootloader to kernel, it's already going to be quite limiting and annoying. If it wants to protect against hardware too, I believe it would need to either drop support for many legacy PCI devices or maintain a whitelist of allowed legacy PCI devices; and then you'd require signed PCI option ROMs (and that firmware be careful to not enable PCI DMA without IOMMU). But I believe a solution absolutely exists where a game company can require that all the non-userland software that ran anywhere in the chain from power on to game start is signed by a company they trust.

The second option, which I think would be more secure but would require buy in from CPU vendors and is not going to happen in a few years would be using some sort of secure enclave mechanisms of CPUs that allow running untamperable, unobservable code even in an untrusted and hostile OS or hypervisor. Features like this exist on the latest server CPUs, but they're not 100% there yet, and to control the full chain it will also require things like the enclave getting untamperable control of some hardware like mice and keyboards (enforced by CPU).

Those things would likely also allow unanalyzable malware, which many would likely find annoying. But there are also pretty neat uses for this at least on servers; it is nice to be able to run code on the cloud that the cloud vendor could not observe without help from the CPU vendor. And, in some sense, I would be annoyed by not being able to do the same stuff on my home computer as on the cloud :)

This is being frantically developed for the server/cloud use case; we'll see if it makes its way to consumer CPUs.

Yes for DRM

SLi — Fri, 08 Aug 2025 10:25:19 +0000

Why is it not possible? I don't know exactly how the Windows Secure Boot pipeline works, but I'd assume it would exclude loading untrusted (~not Microsoft-signed) kernel drivers?

This means that a TPM can attest that the boot chain only contained Microsoft-signed elements in an unforgeable way to a game server, which basically means that you don't have cheat tricks in your kernel.

This does leave open some avenues like PCI devices that (I think) can in most cases compromise the secure boot chain already before the bootloader, or flashing a custom BIOS. These will change the measurements, but, as said, there's no way it's possible to maintain a whitelist of good firmware and PCI option ROMs.

Yes for DRM

excors — Fri, 08 Aug 2025 09:36:29 +0000

Valorant does use TPM remote attestation to some extent (and I expect the other modern anti-cheat systems are similar). Some cheats use a nearly-undetectable hypervisor to emulate the TPM and provide innocent-looking fake responses to the anti-cheat system, and attestation lets the anti-cheat system detect that.

I think it's primarily using the TPM as a hard-to-spoof hardware ID, so that banned players can't simply make a new free account and start playing again, though it can be bypassed by using an external TPM chip (instead of fTPM) and replacing it with a new chip every time you get banned. Secure Boot is an extra hurdle since you have to enroll new keys before it'll boot with your kernel-level cheat (unless you find another way to bypass it), and I presume the anti-cheat can detect those non-standard keys and will consider it an additional point of suspicion.

It's not perfect but it doesn't need to be - it's one of many layers that combine to make cheating more awkward for users to set up and less profitable for cheat makers, to keep the number of cheaters low enough to not ruin the game for everyone else.