There are two fundamentally different architectures to implement identity management: the federated (or networked) approach, and the claims-based approach. I have written about the risks associated with federated identity management before, and about the "identity crisis" in general: 1, 2, 3 and 4. In a talk Gregory Neven gave at our institute, he mentioned a risk of using a federated identity management system I wasn't explicitly aware of.
In a federated identity management system, if user wants to access a service, he is redirected to his identity provider (IdP). The user must sign in to his IdP, who then signs a statement about the attributes that are valid for the user that are relevant for providing the service. The federated approach is very popular currently: Facebook connect, and many national eID schemes (like DigiD in the Netherlands) work that way. SAML is the underlying standard for these systems.
The problem is that the IdP must be online. In particular the signing key used to sign the statements the IdP issues about the user attributes must be online. Yet this signing key is, depending on the kind of attributes the IdP can vouch for, a highly valuable and therefore sensitive piece of data. And it is quite difficult to both make a piece of data highly available and very secure at the same time.
In the claims based approach, made popular in attribute based credential (ABC) schemes, the identity provider is not online: it is not involved when verifying user attributes. In ABC schemes the user obtains his credentials from the IdP in a separate phase. For high security attributes (like attributes that provide access to very sensitive information) the IdP may even require the user to go through a complex issuing protocol, that may even require him to visit a specific location with a credential issuing terminal. The signing key can be much better protected in these cases. This may be relevant for instance in critical infrastructures, financial transactions, and military or law-enforcement applications.
The Identity Management system adopted in the SocIoTal EU project follows a claim-based approach with Attribute Based Credentials (ABC). The IdM relies on the Idemix cryptographic library providing additional means to deal with IoT scenarios where consumers and providers’ can be not only traditional computers, but also smart objects (e.g. smartphones). The IdM endows smart objects with means to control and manage their private data in their smartphone, defining partial identities over their whole identity, which are derived from the credential obtained from de Issuer. The subject smart object can choose the adopted partial identity according to the he context, ensuring a privacy-preserving solution with minimal disclosure of personal information.
Unlike in traditional IdMs, the subject smart object is not redirected to its online Identity Provider (IdP) during the transaction, so that the IdP is not involved when the target device verifies the smart object’s attributes. It avoids the security risk pointed out in this post.
Dear Jaap-Henk,
In both scenarios you would keep the key in a Secure Signing Module from which exporting is physically impossible. I therefor do not see how high availability leads to a lower security of the signing key itself.
You could make a point that the software is available online and therefore it may be easier manipulate systems (e.g. introduce logic that leads to unintended use of the key that is stored securely). Is this the better protection that you refer to?
The issuing process that you describe is actually being used in PKI-Overheid and there is a broad installed based of token that have been issued securely. We are using them, too.
And, btw, we are still interested in IRMA.
Martijn