|
|
Subscribe / Log in / New account

Yes for DRM

Yes for DRM

Posted Aug 13, 2025 0:53 UTC (Wed) by SLi (subscriber, #53131)
In reply to: Yes for DRM by farnz
Parent article: Don't fear the TPM

> 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.


to post comments

Yes for DRM

Posted Aug 13, 2025 1:17 UTC (Wed) by mjg59 (subscriber, #23239) [Link]

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

Yes for DRM

Posted Aug 13, 2025 9:38 UTC (Wed) by farnz (subscriber, #17727) [Link] (1 responses)

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.

Yes for DRM

Posted Aug 13, 2025 13:13 UTC (Wed) by pizza (subscriber, #46) [Link]

> 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.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds