A discussion surrounding four privacy preserving solutions, namely U-prove, Idemix, the French eID, and the German eID, which strives to find the most suitable solution for a government issued eID
by Marjo Geers, IDM Competence Center
For secure electronic identification, smart card based PKI solutions and Identity Provider solutions with one-time-password generators (OTP) have been used for many years. The wish, however, to protect the user’s privacy by disclosing only the minimum amount of required information, has led to privacy preserving electronic identification solutions. Although electronic identification and privacy protection may sound as a contradiction in terms at first instance, in practice preserving the user’s privacy is at current the most important concern of eID-issuing organizations and governments.
As users are getting more and more used to online transactions, they expect to be able to do all their business online. Also those transactions which require a high level of assurance regarding the identities of the parties in the transactions, or at least about the rights of those parties to perform the transactions. With users performing more and more online transactions, they also expect a user-friendly solution. For example, no need to use different credentials for different online services (username-password combinations, OTP tokens, bank cards in combination with tokens, SMS, …). Besides, issuing a separate credential for each online service is not cost-effective for the service providers (SPs). To provide users with a more user-friendly solution and to prevent the cost of resetting forgotten passwords, quite a number of web shops allow user log-in via Facebook or Twitter accounts.
These social media accounts, however, give little guarantee about the authenticity of the user credentials and are therefore not suitable for those transactions requiring high assurance. For this type of transaction a trusted Credential Issuer (CI) or Identity Provider (IdP) is required. A government organization can be a suitable party to act as or delegate the role of CI/IdP for those credentials which need a high degree of certainty. The government can be responsible for this role for transactions between citizens and government organizations (C2G, public domain), but also for transactions of customers with businesses (C2B, private domain). It is obvious for the government to take this role in the private sector, since it may be government rules private SPs have to comply with.Since government issued identity documents like passports and driver licenses are also used in the private sector, and since the government has a responsibility for creating and maintaining a secure environment. This is why in many countries a government issued, secure, electronic identity document for online authentication, an eID, has been issued for quite some time. Most of these government schemes for electronic identification have been based on classic PKI technology, sometimes (in combination with) an IdP. The current opinion, however, is that these solutions do not sufficiently protect the user’s privacy. Protecting the user’s privacy as much as possible while using these eIDs, is considered very important. Therefore new eID solutions have been developed with privacy preserving characteristics.
Here, we discuss the four most well-known electronic identification solutions with privacy preserving characteristics. Two are developed as national schemes and are the eID solutions of Germany and France. The other two are developed in scientific research environments and adopted by large companies: U-prove (Microsoft) and Idemix (IBM).
Identification and privacy
For electronic identification some different schemes are possible. Most of the government issued eIDs rely on PKI technology. The eID contains a public-private key pair and a certificate issued by a trusted party linking the public key to the holder. When an SP requires user authentication, it may send a challenge to the user, which the user signs with his/her private key by using his/her eID. The response, together with the certificate, is sent back to the SP. The SP will verify the response and the certificate. From the certificate the identity of the user and all attributes related to the user included in the certificate, can be extracted. An alternative is that when the user needs to be authenticated by an SP, the user is forwarded to an IdP, the user authenticates to the IdP and the IdP provides the SP with the required information.
These two solutions, however, do not protect the user’s privacy. In case the user authenticates directly to the SP using a certificate, the SP finds out all information contained in the certificate. In case the authentication takes place via an IdP, the IdP knows which user is doing business with which SP. Since privacy protection is highly valued in many societies, new solutions have been developed which provide a high level of trust. However, at the same time, the user’s privacy must be preserved as much as possible. These solutions protect the user’s privacy by only providing those credentials which are absolutely necessary for the transactions (data minimalization) and by giving the opportunity to use a different identifier with different SPs or in different transactions with the same SP (pseudonimization) (see Figure 1). Examples of data minimalization also include only ascertaining the user’s age is within a certain range or above/below a certain threshold. This may be required for online purchases, discounts, chat boxes, and the likes or by ascertaining the user lives in a certain city/province without disclosing the full address. In those cases it is not the actual value of the attribute which is transferred, but the answer to a question which involves comparison with the at-tribute. The possibility to use pseudonimization is required to prevent data coupling between SPs and between sessions with one SP.
Preserving the user’s privacy is especially important in case of a multi-purpose eID, i.e. an eID issued by one party and used by several other parties. This is what is envisioned for government issued eIDs all over Europe. The government will issue an eID, but since it will not be profitable if it will only be used in government communication, the eID will also be available for private sector use. In addition the private sector will have a reliable authentication means.
eID Solution characteristics
General consensus exists in the eID community on the desired eID characteristics. The characteristics as described below are e.g. shared by the American National Strategy for Trusted Identities in Cyberspace (NSTIC) [1], the European Network and Information Security Agency (ENISA) [2], several national governments [3,4] and research groups [5,6,7]. Privacy and security are the main reasons for these characteristics.
User consent
The user should be in control of information regarding him/herself and be able to decide which information (attributes) will be shared and which information will not be shared with the SP. This means that the user must know which information about him/her is proposed to be shared with the SP and agree this information may indeed be shared. Note that this does not mean the assurance about the correctness of the information lies with the user. It is the CI or IdP which guarantees the attribute values.
Another factor is that only the legitimate holder of the credentials may give this approval. It may not be possible that if an eID is lost or stolen someone else acts in the holder’s name or that when the system is infected by malware a hacker acts in the holder’s name. Therefore a form of user identification needs to take place before the eID releases the information. This may be implemented in several ways, but most commonly the user is asked for a PIN which is verified by the eID. To avoid sensitivity to malware the PIN should be entered via a secure PIN-pad.
Service Provider authentication
Before the user shares information about him/herself with the SP, the user should know with a high degree of certainty with which party he/she is going to exchange information. Therefore the SP should first authenticate to the user. It is good practice that the authentication of the SP will be handled by the eID and that the result of the authentication will be shown to the user. In this way the eID can check the SP based on a certificate is sued by a trusted third party or a shared secret and stop the transaction if the SP is unknown or does not possess the right credentials. The user can perform a sanity check and stop the transaction if the SP is authenticated by the eID but differs from the SP the user thought to be involved with in a transaction. Since the information regarding the SP will be shown to the user via a user interface, this is susceptible to malware and authentication by the eID is required.
Insusceptibility to malware
The solution should not be susceptible to malware. eIDs are highly resistant to malware, contrary to PCsand (to a lesser extent) mobile devices. Therefore the transaction should take place between the eID and the SP under end-to-end security. This is realized by creating a secure channel which guarantees message integrity, message origin (authenticity) and confidentiality.
Data minimalization
To protect the user’s privacy only the information absolutely required for the transaction should be shared with the SP. This means that sometimes only name and date of birth suffice (address not required) or only the guarantee that the user belongs to a certain age group. In the latter case the SP only gets a response to its question whether a certain criterion is fulfilled, not what the exact value of the attribute is.
Pseudonimization
To protect the user’s privacy even further the user should be able to use a pseudonym instead of his/her actual name for certain transactions. In many cases the SP’s main interest is detecting a returning customer, not knowing the official name of the customer. Besides, some even argue that the user should be in control about the pseudonym it uses with one SP in different sessions, i.e. not even a fixed pseudonym for a certain SP. The use of pseudonyms prevents that SPs can exchange information about customers thus obtaining more data about the customer. Under certain well-defined conditions it should be possible to raise the anonymity. This should involve an independent third party which verifies fulfillment of the conditions.
No hotspot
It should not be possible for an Issuer or IdP to know or determine with which SP the user is performing a transaction. This will infringe the user’s privacy. This requirement should hold even if the Issuer/IdP and the SP (to which the user released certain credentials but no identifying information) collaborate or coincide and try to match user identifiers with transactions based on time or transaction number. So the scheme may not contain a hotspot where information about both the transaction and a unique user identifier coincides.
Revocation
If an eID is lost or stolen it should be possible to revoke it. Therefore it should be possible to produce a black-list on basis of which eIDs are rejected. Revocation should also work in case the eID generates pseudonyms and in case the eID only indicates whether a criterion is fulfilled. This makes revocation more complicated.
Updateability
Since the validity period of eIDs can be quite long, i.e. up to ten years when combined with an identity card or driving license, it is important that the attributes associated with the eID can be updated during the operational phase. Addresses e.g. may change. It might also be convenient that the attributes are extensible, i.e. that other attributes can be added. In case the attributes are provided by an IdP during the operational phase both updateability and extensibility are straightforward. In case the attributes are on the eID itself, an update mechanism must be available to update the attributes. Extension of the attributes will require an update of the applet on the eID or replacement of the eID itself.
Middleware
The eID will communicate with the SP and the user via a card reader, a PC, other user device (e.g. a mobile phone) or a terminal, and for the SP via the Internet or a dedicated connection. To address the eID via the card reader, middleware will be used. Middleware may also be required to communicate with the user. Preferably this middleware is generic, i.e. independent of the eID application and the device OS, and does not need to be installed by the user.
Offline use
In former days eIDs would need to be usable in offline situations, i.e. without a connection to an IdP or other eID service. Nowadays, however, almost all apparatus is online (even for a cigarette vending machine this will not be problematic) and the eID will mainly be used for online transactions anyway. If an IdP and other required services are implemented with back-up facilities, availability of the eID solution can be guaranteed with high certainty. Therefore the requirement that the eID can be used offline is not an important requirement anymore.
eID Solutions – U-prove
The U-prove solution for electronic identification was developed by Stefan Brands and his company Credentia and later acquired by Microsoft who has made it publicly available as a successor of Windows Cardspace. In the U-prove solution the user together with a CI create a certificate containing a number of attributes. A public-private key pair of the user is associated with the certificate. The correctness of the attributes can be guaranteed by the CI. The user can request a short-lived certificate during a transaction with an SP (this may be required by the SP to guarantee the attributes are up-to-date) or the user can request a long-lived certificate before the transaction. The latter option prevents that even if the Issuer and SP collaborate they cannot link the request and use of a certificate based on time and in this way identify the user. Certificates can be used more than once. The CI can add data to the certificate which will always be visible when the certificate is used, e.g. an expiration date. The user can add data to the certificate which is not visible to the CI and therefore also not attested by the CI. This may e.g. be a pseudonym. The user may request as many certificates as required allowing the use of different pseudonyms. In this solution it is not possible to disclose the identity of the person using a pseudonym.
When the user needs to authenticate to an SP (prove certain attributes), he/she can send a selection of the attributes in the certificate to the SP. The user will use the private key associated with the certificate in this process to prevent replay attacks. The SP is able to verify the correctness of the attributes based on the signature created partially by the CI. For this the SP needs the CI public key.
The technology can be implemented in such a way that an eID is required to generate the proof for the SP. In this way the solution does not depend on software only and is insusceptible to malware/illegitimate use. A presented U-Prove token can be revoked by the user him/herself by making the token identifier available for blacklisting. Revocation is not possible by the CI without collaboration of the user.
eID Solutions – Idemix
Idemix, short for Identity Mixer, was developed by Jan Camenisch et al. for IBM. At a high level Idemix functions quite similar to U-prove. Differences exist on a cryptographic level and Idemix has some other options.
Idemix, just like U-prove, has a CI sign a number of credentials, from which the user can later choose,
when authentication is required, which to present. The Issuer can attest the credentials. A user master secret key is associated with the certificate to link all attributes and pseudonyms of one certificate together. In this way it is prevented that attributes from different users are provided in one authentication process. Pseudonyms are derived from the secret key. This can be done in such a way that only the user can show certain pseudonyms belong to him/her. It can also be that the SP requires the same pseudonym will be used each time the user performs a transaction with the SP. In that case the SP will require a so-called domain pseudonym which is derived from the user secret key by using the SP (or domain) identifier.
With Idemix SPs need a public-private key pair and corresponding certificate. When the user needs to prove an attribute, he/she uses the public key of the SP and his/her master secret key. The SP in turn, needs its private key in the protocol and the public key certificate of the CI to verify the attribute. Showing attributes involves a zero-knowledge proof. The actual credential is not transferred. The technology can be implemented in such a way that an eID is required. In this way the solution does not depend on software only and is insusceptible to malware/illegitimate use. Performance of a smart card based solution, however, is challenging for Idemix. Revocation by the CI is not a standard feature of Idemix.
Idemix and U-prove are anonymous credential schemes. Anonymous credentials essentially are privacy-enhancing public-key infrastructures which require standardization to be widely used. Anonymous credential systems are far more complex than ordinary signature schemes since they provide more functionality in order to address all of the requirements of a public key infrastructure with privacy-protection. In the ABC4Trust project the goal is to address the federation and interchangeability of technologies that support trustworthy yet privacy-preserving Attribute-Based Credentials (ABC).
This means that ABC4Trust strives to define a common unified architecture for ABC systems like U-prove and Idemix to allow comparing of their respective features and combining them on common platforms.
French eID
The specifications for the French eID solution have been developed by smart card vendors Gemalto and Oberthur in collaboration with the French National Agency for Secure Documents (ANTS). The French eID is not yet operational. Implementation is held back by the French Senate. In the French eID solution (unsigned) attributes are stored on the eID itself. The eID Issuer assures the correctness of these attributes (at issuance).
In a transaction where user authentication is required (i.e. prove certain attributes), the SP must first authenticate to the eID. This is done on basis of a symmetric SP specific key, which the eID can derive from a master key on basis of the SP identifier. The SP will then indicate to the eID which attributes are required. The eID will send this criteria list to the IdP after it has authenticated itself to the IdP (method not specified). By sending the criteria list via the eID, the IdP is not aware which SP sent the list. The SP and IdP together, however, seem to be able to determine together, based on the point in time, which user has been in contact with the SP. The IdP will verify that the eID has not been revoked and does not need to be updated. Then it will obtain the required attribute values from the card or just the result of a comparison.
The IdP could also add attributes not present on the card. The IdP will sign these attributes or comparison results and send them back to the eID. The eID will open a new secure session with the SP in which the SP has to authenticate again. This time SP authentication takes place on basis of a Card Verifiable certificate issued by a trusted party. The session with the SP is linked to the previous session on basis of an ephemeral eID key pair. Then the eID will send the IdP signed ‘certificate’ to the SP. The SP can verify this by using the IdP public key. Pseudonyms can be chosen by the user him/herself. The SP can ask whether the name filled-out by the user corresponds to his real name. Revocation can be done by a central party since the IdP is able to check revocation during each session with the eID.
German eID
The German eID has been issued on the German national identity card since November 1, 2010. The card is issued by the Bundesdrückerei while the specifications have been developed and made publicly available by the Federal Office for Information Security (BSI).
In the German eID solution unsigned attributes are stored on the eID. The Issuer guarantees the correctness of the attributes (at issuance). During a transaction in which user authentication is required the attributes or the result of a comparison are provided to the SP by the eID itself without intervention of an IdP or CI.
During a transaction the SP first needs to authenticate to the card via a public-private key pair and Card Verifiable certificate containing information about the attributes to which the SP is entitled. After the SP has been authenticated by the eID and the user has agreed with providing the required attributes the eID ‘authenticates’ to the SP as a genuine eID using a non-unique key pair and a secure channel is set-up between the eID and the SP. Then the attributes to which the SP is entitled or the results of a comparison are transferred to the SP via this secure channel. In this way the keys used for setting up the secure channel cannot be used to identify the eID unambiguously and the data are not signed and therefore the proof-of-evidence is non-transferable.
The eID can calculate an SP (or sector) specific pseudonym based on the SP (or sector) identifier. This pseudonym will be determined by the eID and be the same for each transaction with the SP.
The attributes can be updated, also online, by authorities with the proper authorizations. This, however, will
require the user offering his/her eID at one of these authorities. Revocation can be done by a central party via an SP (or sector) specific black-list. The German eID uses mechanisms like PACE, EAC (TA and CA) and PA which have also been used in electronic passports for quite some time.
Vision on eID
The German eID solution is an elegant and relatively simple solution providing more or less all required
characteristics. It has proven itself in practice. Not only has the German eID been in use since the end of 2010 without any serious issues being identified up till now, it is also based on cryptographic mechanisms which have been in use for quite some time in ePassports. This means it has been available on a broad scale and been submitted to tests by hackers.
The German eID solution is much more straightforward than the French eID solution. In the French eID solution the use of both an Issuer (which provides and attests the attributes on the eID) and an IdP (to create a certificate) seems superfluous. Also the use of both a symmetrical cryptographic key and a public-private key pair with CV certificate to identify the SP seems superfluous. Besides, in case of the French eID solution the privacy protection of the user seems not optimal since it deems possible to identify the user by combining the times of contact with SP and IdP. If this is correct, this is a serious flaw of the French eID solution.
The U-prove and Idemix solutions must be mathematically sound solutions since they have been publicly known and studied for quite some time in the academic world. However, they have not yet proven themselves in practice and some implementation security flaws may be detected if they are rolled-out on a large scale. In fact Idemix has some performance issues in case it needs to be imple-mented on a smart card. Revocation is not incorporated by default, requiring additional mechanisms to be added. The same holds for SP authentication in case of U-prove.
Based on these arguments we consider the German eID solution the most suitable solution for a government issued eID to be used in the public and private sector. It will protect the user’s privacy while at the same time provide good security to both user and SP.
by Marjo Geers
IDM Competence Center