Title: GENERAL SHORTCOMINGS FOR USING TCP ON THE SERVICE SIDE

Some of the general problems of Trusted Computing are already mentioned in section . The FIDIS Deliverable 3.9 “Study on the Impact of Trusted Computing on Identity and Identity Management” (Alkassar and Husseiki, 2007) explains in even more details regarding problems and controversial issues of Trusted Computing in general. Therefore here we concentrate on problems and shortcomings which are more specific to the usage of Trusted Computing on the service side.

A problem (which refers back to the general problems and shortcomings of Trusted Computing) is that Trusted Computing for enhancing the security / privacy of business processes on the service side might force users to eventually use Trusted Computing even on the client side implying that they also get all the drawbacks arising from Trusted Computing (e.g. threats to privacy due to the identifying endorsement key, loss of control etc.). 

One of the most fundamental problems with using the current version of Trusted Computing (as specified and developed by the Trusted Computing Group) on the service side is that the specifications were made with an attacker model in mind which offers protection only against “software based” attacks—but not against “hardware based” attacks i.e. if the attacker has physical access to the hardware of the system. This attacker model might be appropriated for PCs of end users—but it is not appropriated in cases where service providers outsource some of their business processes to third parties and try to secure this outsourcing by means of Trusted Computing. In these scenarios clearly the party one wants to protect against has full access to the hardware and can manipulate them in a way which will thwart the security assumptions of Trusted Computing. 

Another problem is that drawing a clear line what Trusted Computing can achieve is  difficult. If we assume that Trusted Computing is absolutely perfect, why do we need any controlling (i.e. logging and auditing)? An argument is that verifying complex software with respect to trustworthiness is impossible or at least very difficult. This is especially true, if parts of the software which violates the privacy / security policy are written in a “trustworthy way” i.e. if the violation is not obvious.  This directly leads to the conclusion that the controlling part of the software (audit and logging) and the core business logic have to be implemented by different manufactures. Moreover these parts should be certified separately by independent third parties. Fulfilling both requirements seems to be infeasible given today’s market situation.

If Trusted Computing is not 100% secure (the highly realistic view) then not only the core business logic and functionality might be compromised by an attacker—but also the measures for logging and auditing might fail e.g. be manipulated by the attacker. As all of the three general principles mentioned above are based on the same assumptions about Trusted Computing they will all fail if the assumptions do not longer hold. But people might still trust the systems as they are based on “Trusted Computing”, which might let them think, that the technology in itself is highly secure and trustworthy. More general: the people might tend to become less sensitive for privacy / security threats and problems, because they believe (assume), that everything now is safe due to the use of Trusted Computing. 

Most of the technologies related to Trusted Computing are not widely used or even available today. The specification for usage of Trusted Computing on servers as published by the Trusted Computing group seems to be very preliminary. It does not address problems related to Trusted Computing and modern server side technologies like virtualisation and partitioning. The last revision (0.8) is from March 23rd, 2005. No visible changes seem to happen since then. Moreover many of the proposed security and privacy solutions are based on very clear and static overall processing environments. In practice a much more dynamic environment (e.g. new version of or patches for the operating system and the business software etc.) will be used. It is unclear at the moment if and how the integrity measurements (including remote attestation) should work there.