Schneier on Security

Clive Robinson • May 29, 2008 10:23 AM

The real problem with TPM is total lack of transparacy to or control by the user therefor they cannot trust it (by definition).

In it’s current form you as the computer user have to blindly trust the TPM manufacturer / owner or compleatly forgo any of it’s (supposed) benifits. Basicaly it’s an all or nothing senario currently although technicaly there is no real reason it should be (side channel issues permitting).

When the current form of TPM is active you can not run any other code other than that signed by the TPM owner. So you cannot (in theory only) examine what is happening on your system nore can you prevent signed code from doing what it pleases.

Further when DRM and TPM are tied together which is the most likley senario then you can nolonger own anything on your computer just borrow it at the whim of the owners of either the DRM system or any other paid up member of the TPM owners clique.

Allthough TPM does have some advantages the industry is never likley to be in a postition where you as a computer owner will be able to dare risk using it your liability would be way to high.

One of the many scary aspects of the current TPM is it’s functionality as the “ultimat roorkit”. That is the ability of the TPM owner or one of their clique to almost invisably re-write history.

This is simply by denial of access to, the replacment of or the creation of false data in a way that you the user have no control over, and potentialy have no way to prove is / has happened.

As we move into the true “digital age” just about everything will be in digital form mostly on fully mutable storage. TPM will prevent you ever getting real low level access to the storage so you will not be able to show that what you thought you had was now gone (except possibly by meta evidence).

Further you will not be able to show it has been changed even if you have a hard copy as who will belive you, it will be easier for them to belive you have forged your hard copy.

Even if the storage is not mutable it may well be impossible to get access to the real data stored on it. As the TPM program can chose under direction of it’s owner (not you the user) to not register it at the presentation or lower layer in a way that alows you to be aware of it’s existance.

Clive Robinson • May 30, 2008 7:57 AM

There appears to be some confusion about TPM and how to look at it. Broadly there are four basic normal use “TPM” viewpoints,

1, Hardware : just the chip and it’s capabilities.
2, OS-designer : designer of a TPM-OS
3, App-designer : designer of apps to run on TPM-OS.
4, Normal User : who has a TPM-OS with TPM-Apps installed.

There are additional view points such as that of a person researching TPM and DRM systems however they are not what would be considered “normal use” viewpoints.

After the implementation of a mass market TPM-OS and TPM-Apps the majority view of TPM-System will be that of the normal “users” (4). Which will be based on what problems the overall TPM-System causes them, the ordinary user will not see any benifits of TPM-Systems, only problems.

This is becauses when a TPM-System is running correctly it should be “invisable ” to the user, in the same way as DNS and routing protocols.

On re-reading my earlier post (at May 29, 2008 10:23 AM) I realise I did not make it clear which view point (4) I was arguing from.

In mitigation 😉 I will blaim the fact that I was posting from a mobile phone whilst waiting in a hospital for minor surgery.

Curiously in the UK Hospitals appear to have given up the battle on mobile phone use 8) but saddly not on laptops yet 8(

@ Paeniteo,

“@Clive: “In it’s current form you as the computer user have to blindly trust the TPM manufacturer.”
Which is true for every single piece of hardware out there, not just a TPM.”

First off you did not quote me correctly you left the “/ owner” off, and secondly what you say is not quite true in a TPM-System.

In a non TPM-System a user can load or enable additional software as and when they see fit. If sufficiently knowledgable they can even “roll their own”, in a TPM-System this will be at best problematical (ie they will have to follow the route laid out by the “chosen few / clique”).

Further if the software is to help diagnose problems (say Soft-ICE at one end through to Dr Watson at the other) it will most definatly have to be approved by the TPM owner (ie the OS in current TPM systems) before it is allowed to execute.

The whole point of TPM from the viewpoint of “OS wide DRM is an absolute necessity” is to stop the use by others than the “chosen few” of software that runs at a sufficiently low level it would enable the DRM to be examined / circumvented.

If you take the viewpoint that “content is king” then the viewpoint of the main “content” providers will dictate the direction of the design of a TPM-OS that the “content” will be allowed on by it’s providers.

Therefore if the TPM Manufacturer does not fully disclose the API except to the “chosen few” then “clean room” “reverse engineering” will not be possible. Which has been the route used in the past by some device driver writers who were not part of the manufactures “chosen few”. Also the same route for those developing VMs and emmulators such as WINE etc.

The above covers most of your points in that you are looking at the “hardware level” and I was looking at it from the viewpoint of a user of a TPM-System.

Which bings me on to your final comment,

“If you don’t want that your OS abuses a TPM to do things that you don’t like, then, by any means, install a different OS..!”

That sadly is an argument equivalent to “If you have nothing to hide you do not need secrecy”.

As Bruce once pointed out on this blog he uses a Microsoft Operating System and various people gave the “yah boo sucks” response. To which Bruce and others gave valid reasons as to why they had to use MS OS’s which boils down to,

Often your chocie of OS is dictated by the application you wish to use or the wishes of others for such important reasons as compatability.

@ALL

At the hardware level TPM fully outside of the CPU is an “evolutionary dead end” for things like DRM.

This is because it will always be possible to find ways around it by sufficiently skilled people, often with quite minimal resources as has been demonstrated on more than one occasion with games consoles.

Further even if TPM is fully in the CPU, if the system memory (RAM / Cache / Storage) remains outside and it’s contents are not uniquely encrypted for the particular CPU then it likewise will be possible to find ways around it.

Even then I suspect it will always be vulnerable to various attacks due to the use of poor crypto (ie week algorithum or bad implementation) or to “side channel” attacks that will reveal “secret information” such as session keys etc.

The reason that usable “side channels” will always be there in mass produced equipment is quite simple due to there requirements on “efficiency” with respects to “utility and resources”.

To build an system without the potential for side channel use means that you have to reduce the potential bandwidth of any side channels (known or unknown) below that which “secret information” could be passed in a usefull time frame (the effective life of the product for consumer equipment).

The measures required to do this have two downsides,

1) they impose such significant restraints on a system that it is functionality is inversly proportional to it’s utility (that is it only works for single use products with extreamly limited utility and interfaces such as crypto equipment)

2) they mandate the use of resources vastly dispreportionate to the systems purpose (that is the cost is so high it can only be justiffied for specialised high security applications).

Both of which are not going to happen in mass consumer items without draconian incentives (ie legislation).