Yes, that is a correct way to rephrase my question. I'm imagining that the TPM will prevent access to hollywood.com, unless the device in question is 'trusted' by the owners of hollywood.com, in the sense of not having been tampered with by the enduser. (That is what 'trusted' computing means... giving the remote server some assurance that the local PC can be trusted to keep the enduser from making a photocopy of what they see/hear/read. They can always use an external digicam, I suppose, but that is hardly convenient.)
I muddied the waters a bit by talking about Jane and her 'PC', which as you correctly point out, would imply that WindowsUpdate and firmware-flashing (not to mention enduser twiddling of settings in the BIOS like boot-order) would keep interfering with. The better example -- way more likely to happen in 2015+ once the signed EK requirement goes into effect -- is some sort of personal media player device.
Think in terms of iOS and Kindle and even Google Nexus: there is no 'boot order' because there is purposely no expandable storage, there is no way to access the BIOS settings at all, the bootloader is locked down tight as a drum. But go further than them, slightly, and imagine that you are booting into a hypervisor. On top of that, you have two guests: one is an eggshell-thin playback platform, with hardly any actual code inside of it. *This* is the guest that can be verified via TPM and PCR magic, preventing Jane from getting to hollywood.com unless her device is pristine.
The details of how the playback-guest would function are hand-wavy, here, but basically I'm imagining that it would have a network driver and a very simple SSL-aware wget or cURL implementation, which would download the latest *actual* executable from hollywood.com, each and every time you turned on the playback-guest. Any updates to the media player part of the device would generally be server-side ones, that way, which would not require TPM updates at all. The TPM would just verify pristine BIOS, pristine bootloader, pristine hypervisor, pristine media-playback-guest "OS", pristine network driver, pristine cURL, and pristine hollywood.com SSL cert... plus maybe one or two things I forgot. The end.
As for the other hypervisor guest, it would be a general purpose OS, which could be used for email, browsing other websites (not hollywood.com for media-playback of course!), and other non-DRM-protected functionality. None of this area would need to be especially secured, and typical auto-updates could happen over in the general-purpose-guest without screwing up the PCR values stored in the TPM related to the media-playback-guest.
Anyways, methinks that we are going to see devices built along these lines, in less than a decade, once the TPM + EK is more widely deployed, and the hypervisor tech is a bit more mature (presumably Jane will want to watch hollywood.com stuff without 'logging out' of her general purpose OS-guest so there needs to be a cross-guest window manager or somesuch... which prevents the unsecured OS from ever actually seeing the hollywood.com bits ... those go straight from the media-OS-guest to the screen without the generic-OS-guest being able to intercept them).
With luck, by then the average person will know better than to by a device which doesn't come with free-as-in-freedom by default, but that seems more like wishful thinking, as opposed to statistically probable. :-(
p.s. I'm *not* positive it's impossible to make the general purpose guest-OS work in a similar fashion, with just a thin eggshell on the client, which can only connect to os-saas.com for downloading your apps (and only then if you have paid your subscription fees in full for this month....)
Re: state-of-the-art digital restrictions circa 2015
I muddied the waters a bit by talking about Jane and her 'PC', which as you correctly point out, would imply that WindowsUpdate and firmware-flashing (not to mention enduser twiddling of settings in the BIOS like boot-order) would keep interfering with. The better example -- way more likely to happen in 2015+ once the signed EK requirement goes into effect -- is some sort of personal media player device.
Think in terms of iOS and Kindle and even Google Nexus: there is no 'boot order' because there is purposely no expandable storage, there is no way to access the BIOS settings at all, the bootloader is locked down tight as a drum. But go further than them, slightly, and imagine that you are booting into a hypervisor. On top of that, you have two guests: one is an eggshell-thin playback platform, with hardly any actual code inside of it. *This* is the guest that can be verified via TPM and PCR magic, preventing Jane from getting to hollywood.com unless her device is pristine.
The details of how the playback-guest would function are hand-wavy, here, but basically I'm imagining that it would have a network driver and a very simple SSL-aware wget or cURL implementation, which would download the latest *actual* executable from hollywood.com, each and every time you turned on the playback-guest. Any updates to the media player part of the device would generally be server-side ones, that way, which would not require TPM updates at all. The TPM would just verify pristine BIOS, pristine bootloader, pristine hypervisor, pristine media-playback-guest "OS", pristine network driver, pristine cURL, and pristine hollywood.com SSL cert... plus maybe one or two things I forgot. The end.
As for the other hypervisor guest, it would be a general purpose OS, which could be used for email, browsing other websites (not hollywood.com for media-playback of course!), and other non-DRM-protected functionality. None of this area would need to be especially secured, and typical auto-updates could happen over in the general-purpose-guest without screwing up the PCR values stored in the TPM related to the media-playback-guest.
Anyways, methinks that we are going to see devices built along these lines, in less than a decade, once the TPM + EK is more widely deployed, and the hypervisor tech is a bit more mature (presumably Jane will want to watch hollywood.com stuff without 'logging out' of her general purpose OS-guest so there needs to be a cross-guest window manager or somesuch... which prevents the unsecured OS from ever actually seeing the hollywood.com bits ... those go straight from the media-OS-guest to the screen without the generic-OS-guest being able to intercept them).
With luck, by then the average person will know better than to by a device which doesn't come with free-as-in-freedom by default, but that seems more like wishful thinking, as opposed to statistically probable. :-(
p.s. I'm *not* positive it's impossible to make the general purpose guest-OS work in a similar fashion, with just a thin eggshell on the client, which can only connect to os-saas.com for downloading your apps (and only then if you have paid your subscription fees in full for this month....)