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

Title: TC USE FOR IDENTIFICATION

TC use for identification

Digital identity is broadly interpreted as “the digital representation of a set of claims made by one digital subject about itself or another digital subject” – Wikipedia. While digital subjects can represent either human or non-human (device, computers, digital resources…), the value of a Digital identity pertains only in the context in which it is used: a Digital identity used for identification in an enterprise’s network could be irrelevant for identification for an email account, for performing a digital signature on a document, or for accessing a private place. Hence, for a single entity, Digital identity does not need to be unified across different contexts, but rather unique in each domain of application.

However, any Digital identity is meaningful only if the attributes it associates to the corresponding digital subject are authentic. Therefore, authentication mechanisms are crucial to ensure correct identification and to prevent from identity theft. Authentication mechanisms used for correctly authenticating a digital identity are mainly implemented in software and hardware, but can sometimes rely on physical authentication techniques such as iris scanning for human unique identification.  

In this section, we give ideas on how TC can help securing the Digital identity, especially in the context of authentication.  

TPM credentials storage

Digital Identity can be presented by several means. In many cases, the authenticity of a Digital Identity is crucial to its value. This is why a username is associated to a password, a Public Certificate is signed by a Certificate Authority’s private key, a bankcard is associated to a PIN, a digital signature is associated to a private key… Passwords, Private Keys, PINs are known only to the corresponding digital subject. Their confidentiality to the digital subject is necessary to ensure prevention from identity theft. Since a Digital Identity is only relevant if its authenticity can be proven, the way the corresponding confidential information is protected is crucial. In some cases, the confidential information can be memorized (in the case of a PIN or the answer for a challenge-question), but in other cases it needs to be stored in digital form, mainly on hardware devices such as harddisks or smartcards. In most cases, the confidential information has to be provided to other hardware or software in order to be processed for authenticating the Digital Identity. 

For this reason, encryption schemes are widely used nowadays to protect the confidential information corresponding to Digital Identities. Authentication mechanisms rely heavily on those encryption schemes to ensure secure authentication of Digital Identity. The encryption schemes are used to protect the confidential information both in storage and during communication for authentication purposes.  

Trusted Computing can contribute to the protection of confidential information corresponding to Digital Identities, and can therefore ensure their authenticity. One of the major advantages of a TPM is its ability to provide tamper-proof protection of data and keys entrusted to it. This feature can be employed to efficiently protect the confidential information in hardware. As mentioned in section 4.1.3, the Storage Root Key embedded in a TPM can be used to wrap TPM protected keys which are themselves used to encrypt sensible information on a storage device, as shown in Figure 4. This means that the confidential information associated to a Digital Identity can be saved encrypted on a harddisk or smartcard, with the encryption key shielded by a TPM attached to the device.

The decryption of the information is controlled by some strict rules that can be pre-defined by the digital subject with help of TC functionalities. This could be based on special authentication mechanisms that allow the digital subject to authenticate himself to its own device in order to access the confidential information corresponding to his Digital Identity. Moreover, the decryption of the confidential information can also depend on integrity checks of the device’s software and hardware configurations. In other words, the TPM “binds” the confidential information with the authenticity of the user claiming the Digital Identity, and the platforms configuration on which the confidential information is meant to be decrypted and processed. In the case where this information should be communicated to other platforms, the TPM can also bind it to some pre-defined secure configuration of the target platform in order to ensure that its confidentiality is maintained. 

This process greatly ensures the confidentiality of private information associated with a Digital Identity, which in turn improves its authenticity and hence its value since identity theft is considerably reduced. 

TPM-based authentication policies

The confidentiality of credentials associated to a Digital Identity is not only important for the digital subject himself, but also for the other digital entities to which the Digital Identity is authenticated. In fact, the authenticity of the Digital Identity is evaluated by the verifying entity. The latter can verify if the provided credentials are truly associated with the claimed Digital Identity. Therefore, it is of great interest for the verifying entity to ensure that the confidentiality of the credentials is well preserved and not subject to leakage, whether in storage or during communication. One important factor for ensuring this feature is the state or configuration of the digital subject’s hardware and software used to store and communicate the credentials. 

The Remote Attestation feature of Trusted Computing can significantly help achieving this requirement. TPMs allow the attestation of a certain state of a certain system as well as the generation of partial identities for its user in form of signed cryptographic keys or certificates (combined type 1 and 3 identity management).  

To ensure security of digital transactions, a Trusted Platform can attest its integrity using cryptography. Earlier versions of TPM specifications required the involvement of a Trusted Third Party (TTP) [124].  

In short, a user who wants to initiate a certain transaction over the Internet would go to a TTP, attest to it that he has a Trusted Platform and tell it his identity. The TTP then would issue him a certificate he could show to his transaction partner. As the TTP would still be able to reveal the user’s real identity from this certificate, the certificate is a pseudonym and therefore a partial identity. The user would not need to reveal his real identity to his transaction partner while the latter can rest assured that the user has a Trusted Platform. This can be regarded as a privacy-compliant scenario. 

The TC Remote Attestation feature can therefore allow a new type of authentication policy that is not concerned with the real identity of the device’s user, but rather with the specifications of the device itself. In that case, the Digital Identity in focus is that of the user’s platform, and the platforms credentials associated to this Digital Identity are entrusted to the corresponding TPM. TPM-supported devices can therefore be authenticated to a network service without any need to reveal the identity of their users. This type of authentication policy opens the door for a new perspective of networking where any user has access to network services as long as the behaviour of his device is pre-determined. 

TC platforms identity management

Identity Management can be improved by TC platforms in several ways depending on the purpose of the IMS. As explained in 8.2, three types of IMS are defined, each with a different purpose. 

In the case of type 1 identity management, authentication and authorization can be significantly improved with the deployment of TC infrastructures within an identity domain but also between different identity domains.  

The TC attestation protocols can help establish trust between the authenticating party and the Authentication Server (AS) or the Policy Decision Point (PDP). The device used for supplying the identity credentials, supported by TC, will be able to attest its status (software stack and hardware configuration) to the AS by means of an attestation certificate. This would prove to the AS that the platform used to supply the identity credentials is conformant with some predefined “secure configuration” and would therefore allow the AS to trust the corresponding device and securely authenticate the user. Trust can also be established in the other direction, with the AS providing an attestation certificate to the user, which would prove to the user that it is not a bogus AS.  

Moreover, TC can play an important role in establishing trust between different identity domains. A pre-defined credentials issuing policy can be enforced on Credential Providers belonging to more than one identity domain. This would allow a Credential Provider in one identity domain A to issue credentials for a user to access services in another identity domain B. At the moment of issuing the credentials, the identity domain A should be trustworthy, i.e. adhering to some pre-defined issuance policy. Such a policy can only be enforced by the use of TC. The credentials can be verified by identity domain B to have been issued with the enforced issuance policy at identity domain B by means of TC signatures. Hence mutual trust established between different identity domains based on TC can improve identity management in terms of interoperability.  

Business use cases

Based on the ideas and perspectives proposed in sections 8.4.1, 8.4.2 and 8.4.3, several business use cases of TC-based identification and identity management can be envisioned. 

First, the tamper-resistance nature of a TPM can be employed to give a solid ground for future authentication mechanisms. As a result, crucial identification information can be more confidentially stored and communicated, which would support various use cases such as mobile commerce. For example, users of mobile devices will have more confidence storing their creditcard information on their devices, and supplying them during a transaction. On the other hand, transaction peers will be able to verify, through adequate protocols, that the identification information is entrusted to a TPM, which would enhance the trust of the peers in the identity claimed by the mobile user. Hence, the level of confidence in the authentication and identification mechanisms is brought to a higher level, and that would boost the transactions rate. 

Another business use case of TC-based infrastructure, which supports anonymity, relies on the idea of “trustworthy platforms”. As explained in 8.4.2, a TC-based platform will be able to attest its configuration and specifications to a network peer. This would enable business use cases requiring confidence in the behaviour of platforms, rather than in the identity of the person using them. Possible applications would be online gaming, or online gambling, where the contributors would require trustworthiness of their peers’ platforms without needing any reveal of identity. A strict policy on platforms’ external network access, operating systems properties and configuration, applications installation can hence be enforced on any platform attempting to join. In this case, a contributor to the game would be confident that its peers will not be able of treachery without those peers having to reveal their real identities. The digital identity of the platforms could be relevant in such a use case in order to identify the platforms eligible to join the network whenever they have successfully attested a configuration which is conformant to the policy. 

One more possible business use case of TC for identity management relies on the concept described in 8.4.3 where trust is established between different identity domains. The advantage of this kind of schemes lies in the fluidity of business processes requiring identification of users in different identity domain. An example scenario would be services in large scale organizations. An organization having different identity domains for separate services or departments would usually require a user to provide different credentials to each of the corresponding servers. With the deployment of a TC infrastructure, a trust policy defining which identity domain can issue credentials for other specific identity domains can be enforced across the organization’s servers. This way, an employee in one department authenticated by the corresponding identity domain would be able to obtain credentials from this domain to be used for authentication in another identity domain, if the policy allows it. This kind of schemes is realizable with the use of TPM signatures to enforce the trust policy.