On Saturday 10 February 2007 22:29, Tim Thornton wrote: > [ lots of interesting material ]
Having read /some/ of this now, it might useful to repeat in back to help others in the thread understand the basic ideas, or to allow me to be corrected if I've misunderstood :-). (The DRM use case will stay controversial, but I suspect understanding what's going on is useful.) In a trusted computing scenario, you don't actually own one computer, you own two in a single box - it just looks like one. (well, given the amount of tech inside a PC these days, its more a minimum of two computers in the box, a GPU can be called a computer as well) +-----+ +-------------------+ | TPM |<---->| Main computer | | | | (running some OS) | +-----+ +-------------------+ The TPM by definition of being a computer has its own CPU, local storage, and so on. Part of it's design is that at manufacture it is given it's own private/public key pair. At this stage, this is little different (conceptually) from 2 computers connected over a network by an ssh link. The difference is that the connection is significantly harder to snoop. However, in the way it's used, it more resembles the way SSL - ie https for those unfamiliar. With SSL there's two modes: * Trusted & secure * Untrusted & secure In both scenarios you have exchange of keys in order to set up a session key for allowing you to be happy with sending your credit card details over the network (among many other uses). This is what I mean by secure. However you can have a secure link directly to someone pretending to be your bank, so you don't know if the link is trusted. Well, in SSL/TLS/HTTPS (take your pick, the principles are the same), you essentially get your public key signed by a trusted third party. These trusted third parties include Verisign, Thawte [1] etc. [1] Founded by Mark Shuttleworth, which is where he made his fortune, and is the reason Ubuntu exists today... ie You can either run a SSL/TLS enabled webserver whose keys have been signed by one of these third parties, or not. ie if you consider the two computers above by the following metaphor: * The TPM as an HTTPS website * The Main computer as a browser Because the keys in the TPM have been signed by someone else, that browser can check to see if the TPM is a real TPM or not. Now the problem with this approach however is that it introduces potential bottlenecks into the system. As a result, there is another step you can add in. Given this basic chain - can you make it such that the main computer can verify the TPM without talking the third party all the time? Well, if you get the TPM to talk (via the main computer in this case hopefully obviously) to another third party you can do this: * The TPM authenticates itself to this other third party * It generates a special key (DAA) which the third party then signs, giving the TPM a certificate. It can sign this using a private key and publish the public key. Let's call that pubic key "PK". Applications can either download PK on demand or even compile it into their code. This includes open source apps because it's not a secret. * Any one application who wishes to authenticate any TPM then does this: * It essentially asks the TPM to sign something using this key (DAA), and also provides the certificate as signed by the third party. Since the PK is public, the application can verify the that the thing just signed by the TPM is valid. Again, whilst that may sound relatively esoteric, it's actually very much the same technique as using PGP or GPG for email. You have public/private keys. You get your public key signed by someone. The slight difference (I think) is that recipients can be given another public key to use to verify the sender. As a result, this makes it clearly possible to create a "rogue" TPM (including virtualised ones) but people can tell the difference. Probably the weakest link in the chain here is the DAA's public certificate, but then that's why revocation gets built in as well. The other obvious weak point is where the TPM's are originally endorsed, since to be useful it needs to be networked, and software bugs are easier to find/exploit than cracking a large address space. To put this into context, your computer can do the equivalent of connecting at startup to a machine only you own, and only you have access to. This machine can be used to check the integrity of your system, and unlock secrets on the system. That machine cannot be accessed directly by others which gives you a level of confidence in this process. Ignoring the DRM usecase or restricting your computer scenarios, having a secure location for helping check system integrity and protecting the contents of your harddrive, is useful. Clearly the same technology can be used by an operating system that wishes to prevent you from (eg) replacing video drivers or audio drivers, and that same operating system can also enforce whatever restrictions it likes. When that operating system starts up it could use the TPM to check its own integrity and decide to shut down functionality or simply not start up based on the results of this check, but it's not inherently caused by the TPM module or the TCPA approach. After all, package installers and email clients do similar things. A package installer can choose not to install a package if its MD5 fails or if its signed if the signature is bogus. Similarly some email clients act very differently depending on whether the email has been signed and whether the signature is verifiable. So whilst TCPA and a TPM can be used to implement "treacherous computing" it's like any other technology - it has good/sensible uses too. Given how many people cried foul over XP's activation (which if extended could be used for the DAA scenario), and the fact that some installers for XP don't require activation, I'd be surprised if at a later point in time anyone implemented a system that required activation as a key point. (That said, it's entirely practical in a games console environment, since you could do that activation at manufacture) However there's other interesting uses too - it potentially enables widespread use of PGP/GPG with good quality keys for email (among other things). This increases the likelihood at some point in time for people to use TPMs as the basis for encrypting all their personal communications (as advocated by some) and being able to expect the recipient to be able to decrypt the communications. Combine this with OpenID and you probably have some very interesting, and positive for the user, scenarios. Anyway, thanks for the pointers Tim, I'll keep on pondering them, and feel free to point out where I've oversimplified to the point of misinforming or simply misunderstood some points. Regards, Michael. -- Kamaelia Project Lead http://kamaelia.sourceforge.net/Home Senior Research Engineer, BBC Research [all opinions above are my own, no one elses :) ] - 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/backstage@lists.bbc.co.uk/