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.1: Overview on IMS
The idemix Credential System
Idemix is an identity management system based on anonymous credentials and zero-knowledge protocols. It was developed by the IBM Zurich Research Laboratory, Switzerland. In this system, users may maintain unlinkable pseudonyms with different organisations, obtain credentials signed by these organisations certifying certain attributes, and prove these attributes to verifying organisations.
By using idemix, users may have control on their identity attributes. They can choose which attributes they want to show or prove to a certain organisation. The system allows for minimal data leakage, as well as for pseudonymous identity management. Moreover, idemix implements accountability mechanisms, allowing for de-anonymisation under certain conditions.
This work describes the functionality of the idemix credential system. More details can be found in [Cam01, Cam02].
Basic Credential Protocols
The core of the idemix system consists of the protocols described in [Cam01]. This section describes these protocols in terms of parameterised primitives of which functionality can be easily explained and mapped to system interfaces.
The entities in the system are users, who obtain and show credentials, and organisations issuing and verifying credentials. Another type of organisation, de-anonymising organisation, is discussed below. Thus, a user U can obtain a credential C from an (issuing) organisation OI; and then show the credential C to another (verifying) organisation OV. A credential is always issued on a pseudonym N under which U is registered with (or known by) the issuing organisation OI. A credential may have certain attributes (attr). When showing a credential, the user can choose which of the credential’s attributes shall be revealed.
Pseudonym registration, credential issuing and credential verification are interactive protocols between the user and the specific organisation. A user U has a (single) master secret SU, which is linked to all the pseudonyms and credentials issued to that user. Issuing and verifying organisations all have a public/private key pair (PK,SK). The organisation issuing a credential uses its private key to generate the credential; the credential can then be verified using the issuing organisation’s public key, either by the user when receiving the credential, or later on by any organisation to which the user shows the credential. When showing a credential, the user uses the public key of the verifying organisation which, in turn, needs its private key in the protocol. Figure 5.5.1 shows the model for basic credentials protocols.
Figure : Basic credential system protocols
Obtaining a credential from OI and showing it to OV works as follows. First, U contacts OI and establishes a pseudonym N with OI. If N is eligible to get a credential with an attribute attr, OI produces a credential C by signing a statement containing attr and N and sends C to U. Now U can to show this credential to OV. That is, using a zero-knowledge proof, U convinces OV of (1) possessing a signature generated by OI on a statement containing attr and N, and (2) knowing the master secret key SU related to N. We stress that U does not reveal any other information to OV. In particular, U does not send OV the actual credential. This way of showing a credential together with the zero-knowledge property of the proof ensures the unlinkability of different showings of a credential and also the unlinkability of a showing of a credential to the pseudonym to which the credential was issued. This means that U can show C to OV (or any other verifier) an unlimited number of times, without these credential shows becoming linkable to each other or to a pseudonym. (Exceptions are one-show credentials, which are discussed in detail below). This unlinkability is maintained even if OV and OI are the same organisation (or pool their data).
Note that from this unlinkability property it follows that the user is anonymous towards the verifying organisation. Of course, this property of the pseudonym system can only provide real anonymity to the user if the communication channel used supports anonymity [Cha81].
While, in general, this approach to showing a credential is not very efficient, the special signature scheme used by the credential system [Cam01, Cam02] allows for an efficient realisation of the zero-knowledge proof described above. In fact, is indicated by our performance results, the computational complexity for both the user and the verifying organisation executing the protocol for showing a credential corresponds to generating a small number of signatures in the standard RSA signature scheme.
The fact that all of a user’s credentials are linked to his master secret, sharing a credential would imply also giving away one’s master secret not only ensure that user cannot pool their credentials but also allows to implement for measures to discourage users from sharing their credentials.
One way to do this is PKI-assured non-transferability, where the user’s master secret key is tied to some valuable secret key from outside the system (e.g., the secret key that gives access to the user’s bank account) [Dwo96,Gol98,Lys99]. Thus sharing a credential implies also sharing this valuable secret key. However, such a valuable key does not always exist. Another, novel way of achieving this is all-or-nothing non-transferability [Cam01]. Here, sharing just one pseudonym or credential implies sharing all of the user’s other credentials and pseudonyms in the system, i.e., sharing all of the user’s secret keys inside the system.
In cases where the verifier and the issuer is the same entity, the sharing credentials can be limited by the approach proposed by Stubblebine, Syverson, and Goldschlag [Stu99]. In this approach a credential can only be used once, but each time a credential is used, a new credential is issued. Thus, when a credential is given away, only the person using the credential first is given the next credential. This mechanism makes sharing access to a resource tedious.
Using the so-called Fiat-Shamir heuristic [Fia86], the protocol for showing a credential can also be turned into a signature scheme. The meaning of a signature will then be “a person possessing a credential issued by OI has signed this message.”
Both all-or-nothing non-transferability as well as the signature functionality will only be implemented in a future version of the prototype.
Credential Options and Attributes
Credentials can have options (such as one-show, or multi-show) and attributes. The one-show credentials incorporate an off-line double-spending test [Cha88]: when showing a one-show credential more than once (to the same or different organisations), this results in transcripts from which the issuing organisation can extract the pseudonym N on which it was issued.
Examples of credential attributes can be an expiry date, the user’s age, a credential subtype. When showing a credential, the user can choose which attribute(s) to prove something about, and what to prove about them. E.g., when showing a credential that has attributes (exp-date = “2002-05-19”, age = 55), the user can decide to prove only that age > 18.
Parameters of the Show Protocol
In this section, we describe two optional parameters that may be enabled when showing credentials. The first one allows for the implementation of accountability measures by requiring the user to provide encrypted identity information. The second one extends the functionality of the system by providing primitives with which the user can prove ownership of several credentials.
De-Anonymisible Show of a Credential
De-anonymising mechanisms allow to reveal the identity of a user (global de-anonymisation, also called global anonymity revocation) or to reveal a user’s pseudonym with an issuing organisation (local de-anonymisation or local anonymity revocation). Global de-anonymisation allows for global accountability of transactions (e.g., for identifying a user performing illegal transactions); local anonymity revocation can be applied by the issuing organisation to take measures when a user misuses his credential. Both types of de-anonymisation are optional and require U’s cooperation when showing a credential. They require the existence of a designated third party, a de-anonymising organisation OD (see Figure 5.5.2) OD has a public-private encryption-decryption key pair (PKD, SKD). Using this variant of the show protocol, U encrypts N with OD’s public encryption key. This encryption is verifiable (denoted EVD(N)), which means that OV has proof that OD can decrypt and reveal the relevant N from OV’s show protocol transcript. There may be several de-anonymising organisations in the system, from which U may be able to choose. By including also a de-anonymisation condition, U can decide under which condition he consents to the transcript being de-anonymised. Later, when deemed necessary by OV, OV can send the transcript to OD. OD can then decide whether this condition is fulfilled and, if so, de-anonymise the transcript and returns N (local de-anonymisation).
Figure : De-anonymisation
Global de-anonymisation uses essentially the same technique. It requires, in addition, the existence of a special credential issuing organisation, a Root Pseudonym Authority, which only issues credentials on pseudonyms of which it knows the mapping with a real user identity. A user typically has a single pseudonym (root pseudonym) with the Root Pseudonym Authority, and one credential (root credential) on that root pseudonym (additional pseudonyms or credentials with the Root Pseudonym Authority would anyway be linkable to the user).
Showing a Credential Relative to a Pseudonym
Using this option, U, who has obtained a credential C by OI on NI, and who is known under pseudonym NV to OV, proves possession of C to OV, while also proving that the pseudonym to which C was issued belongs to the same user as does NV. More precisely, the user proves that the same master secret key SU that is linked to NV is also linked to the credential C and the pseudonym (NI) the credential C is issued on.
This option is mandatory for U to convince OV of possession of several credentials. Without using the option, two users each possessing a different credential could each show their credential to OV and fool OV into believing that it talked to a single user possessing both credentials.
Furthermore, this option is also mandatory if showing of a credential is a precondition for a user to get another credential. The reason for this can be seen from the following example. Let us assume that U wants to obtain a credential from OVI; OVI, in order to issue such a credential, requires U to show a credential by OI. If U has such a credential, he first registers a pseudonym NVI with OVI, and then shows the credential by OI to OVI, upon which OVI considers the precondition to be satisfied and issues the new credential on NVI. If U has no such credential, he can try to collaborate with U’ (who does own the credential) by asking U’ to perform the second step (showing the credential by OVI). And indeed, if OVI does not require U to show the OI credential relative to a specific pseudonym, U will obtain the credential from OVI without fulfilling the precondition. By requiring the show of the OI credential relative to NVI, OVI enforces that the same user who showed the OI credential gets the new OVI credential.
Summary
Idemix implements a flexible user-controlled identity management system. Users have a master secret which is used in the protocols to securely establish pseudonyms with organisations; obtain signed credentials issued by the organisations; and show the credentials. The protocols do not leak any information on the identity of the user, as idemix implements “zero-knowledge protocols”. Note that an anonymous communication channel is required in order to protect the identity of the user at the communication layer.
Credential shows are unlinkable to each other and to the user’s pseudonym, even towards the issuing organisation. This allows for privacy enhancing identity management. Idemix implements optional accountability by requesting the user to provide a verifiable encryption of his pseudonym. Optionally, users may also prove ownership of several credentials.
17 / 31 |