I was suspecting that as DRM at least appears to one of the main motivators (along side trojan/malware protection) for trustworthy computing that probably you will not be able to put the TPM into debug mode (ie manipulate code without affecting the hash attested in debug mode). Ability to do so breaks DRM.
Also bear in mind the vista model where it has been described that inserting an unsigned device driver into the kernel will disable some media playback (requiring DRM). And also the secure (encrypted) path between trusted agent and video/audio card, and between video/audio card and monitor/speakers. The HDMI spec has these features, and you can already buy HDMI cards and monitors (though I dont know if they have the encryption features implemented/enabled). I think generally full user control model will not be viewed compatible. Ie there will be a direct conflict between user ability to debug attested apps and DRM. So then enters the possibility to debug all apps except special ones flagged as DRM, but if that technical ability is there, you wont have wait long for it to be used for all things: file formats locked to editors, per processor encrypted binaries, rented by the hour software you cant debug or inspect memory space of etc. I think the current CPUs / memory managers do not have the ring -1 / curtained memory features, but already a year ago or more Intel and AMD were talking about these features. So its possible the for example hypervisor extra virtualization functionality in recent processors ties with those features, and is already delivered? Anyone know? The device driver signing thing is clearly bypassable without a TPM, and we know TPMs are not widely available at present. ("All" that is required is to disable or nop out the driver signature verification in the OS; or replace the CA or cert it is verified against with your own and sign your own drivers). How long until that OS binary patch is made? Adam On Tue, Oct 10, 2006 at 12:56:07PM +0100, Brian Gladman wrote: > I haven't been keeping up to date with this trusted computing stuff over > the last two years but when I was last involved it was accepted that it > was vital that the owner of a machine (not necessarily the user) should > be able to do the sort of things you suggest and also be able to exert > ultimate control over how a computing system presents itself to the > outside world. > > Only in this way can we undermine the treacherous computing model of > "trusted machines with untrusted owners" and replace it with a model in > which "trust in this machine requires trust in its owner" on which real > information security ultimately depends (I might add that even this > model has serious potential problems when most machine owners do not > understand security). > > Does anyone know the current state of affairs on this issue within the > Trusted Computing Group (and the marketed products of its members)? > > Adam Back wrote: > > So the part about being able to detect viruses, trojans and attest > > them between client-server apps that the client and server have a > > mutual interest to secure is fine and good. > > > > The bad part is that the user is not given control to modify the hash > > and attest as if it were the original so that he can insert his own > > code, debug, modify etc. > > > > (All that is needed is a debug option in the BIOS to do this that only > > the user can change, via BIOS setup.) --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]