On 09/02/07, Michael Sparks wrote: > "Tim Thornton" <[EMAIL PROTECTED]> writes: >... > > No, this /is/ an implementation problem, and can be overcome with a > > trusted hardware element on the platform. At that stage, the hoop > > will be more than simply running some code. > > Trusted element? Trusted by whom? The so-called "trusted computing" > platform is a double edged sword - whilst it can be used by a user to > implement a data store they personally trust[1] the situations where a it > is used by a remote party to trust the user, is from a users perspective > not trustable. > > The reason for this is it places an element of _their_ hardware under the > control of a third party. This is actually a _untrustable_ hardware > element from the perspective of the perspective of the user. There have > been somewhat less flattering descriptions of this. > > Personally I'd prefer it if people stated by *whom* such hardware elements > are to be trusted in these discussions. Personally I prefer to own > hardware devices that do what I tell them to, when I tell them to, and how.
The difficulty with stating by whom the element is to be trusted, is that it depends on the application. For a disk encryption application, I trust the device, for a DRM application, the music provider trusts it, for a VPN encryption driver, my company trusts it. The commonality between all applications is that there is one party that /is/ trusted by all users, and that's the supplier of the secure element. If that trust doesn't exist, then the device is useless. > Otherwise you're (probably inadvertantly) continuing the false implication > that such systems are more trustable by their _owners_ whereas in practice > it depends on HOW such systems are controlled by software installed on > them as to whether the system is more trustable by their owners (safe > personal store) or by third parties. Absolutely. > [1] Since you can access the TCPA from userspace to store/retrieve keys to > make encrypting your own file system under your control & passphrase. > (There's a tutorial for this in a Linux World issue from about 3 or 4 > years ago which is quite interesting) > > (as an aside, given you can emulate a TCPA based system in software > however even that doesn't really actually solve your implementation issue, > since you just virtualise the entire platform including TCPA module - > which would of course happen if you provide people with a sufficient > incentive...) The TPM was designed with this in mind, and each TPM has its own keys. Because they're internal to the TPM and can't be extracted by software, you can have confidence in the TPM's authenticity. -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. Unofficial list archive: http://www.mail-archive.com/[email protected]/
