You are here: Resources > FIDIS Deliverables > HighTechID > D3.9: Study on the Impact of Trusted Computing on Identity and Identity Management > 

D3.9: Study on the Impact of Trusted Computing on Identity and Identity Management

TC identity and Consumer Privacy  Title:
TC PLATFORMS AND ANONYMITY
 TC and Identity Management – a Use Case Scenario

 

TC platforms and Anonymity

While TC based anonymity services have been discussed in 6.2.2, we focus in the following on the implications of TC features on identification of individuals and general identity management systems. 

TC implementations and anonymity

One of the major advantages of TC is the ability of TC platform to perform attestation. This would help the system to prove its security properties to a remote system. However, current implementations of TC do not take the privacy issues into account. In fact, the credentials sent by a platform to prove its security properties can reveal identifying information about the platform, and maybe its user. The anonymity during transactions, which is important in many scenarios, could hence be compromised. The concepts of “Privacy Certification Authority” and “Direct Anonymous Attestation” (next sections) were proposed by the TCG to enhance the privacy aspect during remote attestation.  

TC can hence play an important role both in a network of anonymity (in case correct implementation of DAA is achieved), but also in a network of identity. In fact TC can help achieving a network with a trusted infrastructure and full anonymity. This would be useful for a network where all partners would like to perform transactions with other peers with secure computing platforms without having to reveal any identification information about them or requiring any such information from their peers. 

On the other hand, TC can help achieve a network where all partners are considerably sure of the identity of their transaction peers, since the attestation certificate of the peer contains identification information and is generated by a TPM which can be considered truthworthy. 

Privacy Certification Authorities (CAs)

Privay CAs are a kind of Trusted Third Parties that have been defined by the TCG. The role of the Privacy CA is to certify to partners exchanging information that each of them is truly a secure computing platform. This requires all partners to fully trust the Privacy CA, which is hard to achieve.  

The protocol used for this kind of certification requires the partner to provide some private information about his platform. This information is used by privacy CA in order to verify the trustworthiness of the partner before certifying the security properties of the platform to another partner. The word “Privacy” stems from the fact that the Privacy CA does not need to reveal the real identity and other private information of the partner to another partner, but rather has just to certify its trustworthiness. This means that “privacy” is achieved between communicating partners thanks to the Privacy CA. However, enough identity and private information need to be revealed to the Privacy CA himself. 

This led to the design of the “Direct Anonymous Attestation (DAA) protocol” by the TCG (next section) which aims at providing this level of privacy between communicating partners without the need for a Privacy CA. The goal is to avoid revealing private information to a third party. 

When considering identity management systems, the need for a Privacy CA is crucial, and at the same time not really problematic. The reason is that IMS are usually of centralized nature, which means that a central management authority at the heart of the IMS has to be trusted in all cases in order to certify the validity of the claimed identity. This means that this central authority can in principle play the role of a “Privacy CA” which can certify for any partner that the peer partner has a secure computing platform. 

The requirement for a protocol such as DAA to avoid the presence of a Privacy CA would be relevant for example in the case where the IMS is responsible for identification during inter-organizational transactions. In this kind of scheme, the IMS is independent from the partners, and “fully” trusting it and revealing private platform information to it could be a risk. An IMS would be able to use this revealed information to identify the peers of a certain transaction, and to link certain transactions to certain identities. This could cause both an anonymity and a privacy breach.  

Direct Anonymous Attestation (DAA)

The DDA protocol defined in version 1.2 can prevent the identity of the TC platform’s user when carrying on remote attestation. The anonymous remote attestation can help in anonymous communication and enhance identity management.  

In TPM specifications version 1.2, the aforementioned Direct Anonymous Attestation (DAA) has been introduced. DAA allows attestation of a Trusted Platform without the involvement of any other party, trusted or not. DAA gives the user certificates that do not reveal his identity and look different each time. These certificates, called credentials, are unlinkable [126]. Therefore, this scenario can be regarded a privacy-friendly (type 3 identity management). 

As mentioned before, content providers are not interested in offering anonymity to their customers; their main interest is establishing a centrally managed identity management (type 1 IMS). It is therefore unlikely, that a privacy-friendly mechanism such as DAA will be able to unfold its privacy potential to the masses, as long as the TTP scheme exists. It should therefore be dropped from future TPM specifications for the benefit of DAA. But this is also unlikely as there are other applications (apart from the privacy context), where the use of TTPs makes sense. So “best practices” as suggested by the Article 29 Group [127] will have not only to be established, but in addition should be made obligatory. 

 

 

TC identity and Consumer Privacy  fidis-wp3-del3.9_Study_on_the_Impact_of_Trusted_Computing_on_Identity_and_Identity_Management_v1.1.sxw  TC and Identity Management – a Use Case Scenario
28 / 38