In Part I of this post, I briefly discussed Trusted Platform Modules (TPMs) and the core services they can offer. In this part, I’ll go through some of the controversial issues that surround these services.
One of the key services is remote attestation. TPMs carry in their user-nonmodifiable, nonvolatile memory an endorsement key (EK), which is generated by the TPM manufacturer. This key will be used later to prove the authenticity of your TPM. The problem here is obvious. EKs will enable vendors (who have supplied you with the TPM, cryptographic certificates, or even software) to uniquely identify your machine and track its activity. So, the Trusted Computing Group (TCG) had to come with the Direct Anonymous Attestation (DAA) protocol to address that problem. (DAA uses a zero-knowledge proof to prove authenticity without revealing the owner’s identity.) Although DAA is in the current TPM specifications, it’s still optional for manufacturers to implement it and we have not yet seen any public implementation.
The second issue comes around the concept of sealing, which is the idea of binding a piece of data to a specific state of the machine. In other words, I can give you this piece of software that you will be able to invoke (or reveal) only when your machine is under a very specific state. Thus, I can control the environment that you’re trying to use with that data. For example, I can stop your accessing my online banking portal because your machine seems to be running some unidentified software, or I can give you this movie that can be played no more than three times. Apart from the DRM issues that I am not going to discuss, sealing can be used as a tool for vendor lock-in, which would allow software vendors to restrict the types of applications people can run concurrently with their own software.
From the software-security point of view, sealing is a good idea–as we can maintain a machine’s integrity under strict controls. On the other hand, this method can lead to anti-competitive practices against other software vendors (especially the small ones). Much of the work done in this area to lessen the effect of vendor lock-in comes under the concept of “trusted virtualization,” which I might write about later.
Finally, the TCG described the TPM model as an opt-in technology, and it should probably remain so. But if we look at other platforms, such as mobile devices, it would be hard to imagine vendors not trying to enforce TPM usage on them.

June 1st, 2008 at 5:46 am
Remote attestation is more useful, I think, for corporates and software licensing. I could see virus protection software, for instance, being properly managed in a corporate environment through the use of attestation. I’m not sure of what the cost/benefits are, but I feel that one of the first real uses of the TPMs in the corporate environment will be for accounting of site licenced packages.
TPMs on mobile devices (MTMs) are mandatory (well, MRTMs only, not MLTMs, but let’s not get into that!) but they need that to enforce legal regulations surrounding wireless use, and to protect the SIM card, etc.
Looking forward to the article on trusted virtualisation, but every time I think about it my brain hurts!
June 2nd, 2008 at 9:22 am
This system is basically the ultimate whitelist. However, total control of this list is in the hands of the OS vendor. If the OS vendor allows another vendor’s software, then that vendor has some control over what other (OS vendor approved) software runs concurrently and can interact with your software. Microsoft would have the capability to, for example, deny the ability to run Quicken and approve only MS Money for your financial software needs. A more insidious setup would be to allow Quicken to run but deny access to the internet for transaction downloading.
From a common sense perspective, I just don’t see any government or corporation wanting Microsoft to be in absolute control of their servers, desktops, and data.
June 3rd, 2008 at 12:51 pm
I think the situation with PCs is going to continue to be very different than for small specialized mobile devices. The PC is traditionally an open platform, and customer expectations will insure that it stays that way. Actually there is nothing about the TPM that would particularly entice OS vendors to close the platform. In fact to the extent that TPM and improved OS technology improve separation between processes, the argument for closing the platform is weakened, as insecure applications cannot harm other applications or the OS.
To take this argument to its logical conclusion, imagine that Microsoft announced that Windows 7 will only run Microsoft-approved applications. Anyone who does not understand that this would doom the product and probably the company forever should not be commenting on this issue. Yet when people talk about TPM they automatically assume that just such idiotic maneuvers will be common among OS vendors.
Vendor lock-in is potentially an issue, but here it is best left up to the market. Products with open specifications and data structures will compete with those that close their specs. I think in today’s world we are seeing movement towards more open source, open specs and open implementations. I suspect this concern about lock-in is largely going to be a thing of the past.
June 12th, 2008 at 11:41 am
Lenovo and other OS vendors as manufactures are already locking in their hardware by means of using DMI during BIOS booting.
I bought a new wireless minicard, to replace the OEM unit in my Lenovo Y510 IdeaPad which is sold on the Y510 notebook.
To make a long story short, I had to purchase the same wireless card from Lenovo so the computer would boot.
This insures only Lenovo hardware that’s been certified with their blessings to run in my Lenovo Y510 computer.
It works against competition, as now i have NO choice, but to purchase only what Lenovo wants to offer me for that specific type of notebook.
I only had needed to replace the old OEM wireless minicard that came with 802.11.g with another using 802.11.n here. Nobody selling me the same product will tell me about DMI management.
It’s like DRM, as it should be called “digital rights restrictions” and not digital rights management for which is very misleading.
If things continue ahead in this direction, it will not be long before even the most simple task will be beyond our reach as a consumer. We will be living in a word completely under the policies of some corporation, that has no accountability, as the legal code forbids suing any corporation as an individual.
Meaning, these restrictions can be abused by denying competition, restricting usage, and worse limiting prior innovation to the hands of only a few.
It only serves the wealthy, while making the people indentured servants. So how is that wise?