Resources
Identity Use Cases & Scenarios.- FIDIS Deliverables.
- Identity of Identity.
- Interoperability.
- Profiling.
- Forensic Implications.
- HighTechID.
- D3.1: Overview on IMS.
- D3.2: A study on PKI and biometrics.
- D3.3: Study on Mobile Identity Management.
- D3.5: Workshop on ID-Documents.
- D3.6: Study on ID Documents.
- D3.7: A Structured Collection on RFID Literature.
- D3.8: Study on protocols with respect to identity and identification – an insight on network protocols and privacy-aware communication.
- D3.9: Study on the Impact of Trusted Computing on Identity and Identity Management.
- D3.10: Biometrics in identity management.
- D3.11: Report on the Maintenance of the IMS Database.
- D3.15: Report on the Maintenance of the ISM Database.
- D3.17: Identity Management Systems – recent developments.
- D12.1: Integrated Workshop on Emerging AmI Technologies.
- D12.2: Study on Emerging AmI Technologies.
- D12.3: A Holistic Privacy Framework for RFID Applications.
- D12.4: Integrated Workshop on Emerging AmI.
- D12.5: Use cases and scenarios of emerging technologies.
- D12.6: A Study on ICT Implants.
- D12.7: Identity-related Crime in Europe – Big Problem or Big Hype?.
- D12.10: Normality Mining: Results from a Tracking Study.
- Privacy and legal-social content.
- Mobility and Identity.
- Other.
- IDIS Journal.
- FIDIS Interactive.
- Press & Events.
- In-House Journal.
- Booklets
- Identity in a Networked World.
- Identity R/Evolution.
D3.9: Study on the Impact of Trusted Computing on Identity and Identity Management
 |
Title: ARCHITECTURE |
 |
Architecture
The idea behind the architecture is to benefit from the advantages of different TCG specifications in order to establish a trusted infrastructure that allows fulfilment of the requirements mentioned above. The architecture is shown below, together with the protocol needed for establishing the trust, especially across identity domains.
Figure 8: Interoperable credentials across Identifier Domains [140]
The architecture integrates the role of Privacy-CA explained in section 8.6.2. The Privacy-CA’s main role in this case is to check the trustworthiness of the Identity Provider residing in Identifier Domain A, and to issue him an AIK credential with authorizing attribute. For this purpose, the Identity Provider has to communicate his Endorsement Key provided by his TPM vendor, and an AIK generated by his TPM (cf. 4.2.2).
After regular authentication and authorization of the user, which is usually based on a pre-defined policy, the Identity Provider will then be able to issue an identity credential for the requesting user. This credential should include the AIK credential obtained from the Privacy-CA, in addition to status information in the form of integrity measurements performed and stored in the TPM.
The user will then use his identity credential to authenticate and authorize himself at a Service Provider belonging to Identifier Domain B.
Since the status information is TPM-generated, it can be compared to reference values. The Service Provider will attempt to validate the identity credential of the user based on the AIK credential provided by the Privacy-CA, and the verification of the status information trustworthiness.
With this protocol, a Service Provider residing in Identifier Domain B will be able to accept identity credentials issued by Identity Providers in Identifier Domain A, and that is based on the trust in the Privacy-CA, and the integration of TPM hardware and functionalities.
| |
   |
|
| 32 / 38 |
