[nocoment]

> Are there any TPM implementations where the user doesn't control the TPM?

The design of the TPM prevents the user from ever fully controlling it, so complete revocation of access is unnecessary. Anything in the system/bootup can update a PCR, revoking some or all access to essential keys.

Take the chromebook I am using right now. The user can disable secureboot (which isn't actually implemented with the TPM) and use an unsigned image, but can not create an image signed by themselves.

With either boot, I nominally have control of the TPM, so far so good. But the PCR values written by the boot process will be different so I can not use keys from one boot in the other. For example, my encrypted filesystems from the google boot are inaccessible.

This is great for the security of my data if my chromebook is stolen. But it also means a web service like my companies' VPN or MPAA's movie server could demand that I use attestment to show I am using a google configured chromebook, if I did a custom boot the attestment will not have the right PCR values, so I am incapable of using the service.

> TPMs aren't needed to provide a DRM scenario - UEFI Secure Boot can do that by itself, right?

AFAIK, UEFI secure boot limits the device based on a list of public keys, but has no access to any form of secret key. So booting an insecure clone to contact a DRM protected service (or otherwise emulate the secured device) works perfectly fine.

[MichaelGG]

The scenario you outlined is exactly the point of a TPM. In the case of an "MPAA movie server", exactly how would they verify the remote attestation? As I understand, they'd need to have some way of verifying your key. You would have had to opt-in to such a feature, right? The simple act of having a TPM doesn't give arbitrary third parties the capability to verify remote attestation. Unless I'm missing something critical.

On Secure Boot, you're right that a clone works. But if your device doesn't have an open Secure Boot system, like WinRT, then that device is DRM'd up as the OS can fully decide which programs to allow. An insecure clone means another device, but point taken.

[nocoment]

Yep, to be clear I was pointing out that a TPM with remote attestation can't avoid implementing DRM in the true sense of protecting specific content to the extent possible on the device.

I think the permanently gimped system stuff like a key restricted secure boot is really something else. It is in some sense an acknowledgment of the impossibility of DRM actually preventing every single copier and gains more from leveraging its play time monopoly to lower the value of all non-DRM content which may or may not be pirated.

A system that denied all open content with a TPM would indeed be very broken in terms of design and would only start to make sense if the hardware was much more customized than a typical PC platform.

[dlitz]

Another problem with UEFI Secure Boot is that boot images can apparently only be signed by one key, which is why we see crazy things like Canonical going to Microsoft to get their Ubuntu images signed. (It's a nice, subtle, anti-competitive trick, IMHO.)