COMPARISON OF EID SOLUTIONS WITH PRIVACY PRESERVING CHARACTERISTICS

Transcription

1 COMPARISON OF EID SOLUTIONS WITH PRIVACY PRESERVING CHARACTERISTICS May 2012 WHITE PAPER BY MARJO GEERS, CONSULTANT, FOR THE IDM COMPETENCE CENTER Author Marjo Geers has more than 10 years of experience as a consultant in IT security. She is specialized in electronic Identification, Authentication and Signatures (IAS), secure documents and secure electronic transactions. Marjo has been advising government and private organizations regarding eid solutions, driver and vehicle identification, and PKI infrastructures for e-passport verification and electronic signatures. Marjo is involved in standardization work via CEN TC224/WG15 (European Citizen Card) and CEN/ETSI STF 425 (Rationalized Framework for esignature Standardization). Abstract 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 contradictio in terminis at first instance, in practice preserving the user s privacy is at current the most important concern of eid-issuing organizations and governments. In this whitepaper we discuss 4 privacy preserving solutions, namely U-prove, Idemix, the French eid, and the German eid. We compare the solutions and argue our opinion about the most suitable solution for a government issued eid. Key Words: eid, IAS, electronic identification, privacy preserving credentials, anonymous credentials. Introduction 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 1/12

2 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. In this paper we discuss the four most wellknown 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). We consider the cases in which U-prove and Idemix make use of a hardware token, most likely a smart card, since this provides for better user authentication. The issues regarding privacy protection in electronic identification schemes are discussed in section two. The desired characteristics of privacy preserving eid solutions are discussed in section three. Then the four different eid solutions are described in section four, and in section five a comparison between the solutions is made based on the characteristics described in section three. In section six Collis vision on the most suitable solution for a government issued eid is discussed. 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 minimalisation) and by giving the opportunity to use a different identifier with different SPs or in different transactions with the same SP (pseudonimisation) (see Figure 1). 2/12

3 Figure 1: General purpose eid for authentication with several Service Providers Examples of data minimalisation 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 attribute. The possibility to use pseudonimisation 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. 3. eid Solution Characteristics In this section the characteristics on which an eid solution should be judged are discussed. 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- 3/12

4 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 (end-to-end secure channel) The solution should not be susceptible to malware. eids are highly resistant to malware, contrary to PCs and (to a lesser extent) mobile devices. Therefore the transaction should take place between the eid and the SP under endto-end security. This is realised by creating a secure channel which guarantees message integrity, message origin (authenticity) and confidentiality. Data minimalisation 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. 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 (coupling between IdP & SP) 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. Pseudonimisation 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 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 licence, 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, 4/12

5 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 straight forward. 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. 4. eid Solutions U-prove The U-prove solution [8] 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. 5/12

6 A high-level schematic representation of U- prove is given in Figure 2. For more information regarding U-prove see [8]. 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. Figure 2: Schematic representation of U-prove Idemix Idemix, short for Identity Mixer, was developed by Jan Camenisch et al. for IBM [9]. 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 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. A high-level schematic representation of Idemix is given in Figure 3. For more information regarding Idemix, see [9]. Figure 3: Schematic representation 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 6/12

7 a public key infrastructure with privacy-protection. In the ABC4Trust project [10] 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 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 [3] (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. A high-level schematic representation of the French eid solution is given in Figure 3. For more information on the French eid, see [3]. Figure 4: Schematic representation of French eid German eid The German eid has been issued on the German national identity card since November 1, The card is issued by the Bundesdrückerei while the specifications [4] have been developed and made publicly available by the Federal Office for Information Security (BSI). In the German eid solution [4] 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 7/12

8 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. A high-level schematic representation of the German eid solution is given in Figure 4. For more information on the German eid, see [4]. 8/12

9 Characteristic U-prove Idemix French eid German eid User consent - Requested attributes shown to user via IdP - Distinction in mandatory and optional attributes - Requested attributes shown to user via Bürger client SP authentication by eid Not incorporated but can be added (via publicprivate key pair) 1 (via shared secret key & later in transaction via CV certificate) 1 (via EAC-TA) Insusceptibility to malware (end-toend security) (in case an eid is used. An eid though is no mandatory part of the U-prove scheme) (in case an eid is used. An eid though is no mandatory part of the Idemix scheme) Secure Channel via DH or ECDH key exchange - eid key pair ephemeral - eid public key signed by IdP - requires IdP certificate at SP - SP key pair ephemeral Secure Channel via ECDH key exchange (EAC-CA) - eid key pair NOT unique - eid public key signed by Issuer - requires Isser certificate at SP - SP key pair ephemeral Data minimalisation Attributes in certificate. eid used for cryptographic calculation. Result of comparison can be transferred to SP Attributes in certificate. eid used for cryptographic calculation. Result of comparison can be transferred to SP Attributes on eid. eid can perform Comparison - Attribute value or result of Comparison signed by IdP - IdP can indicate validity period. Attributes on eid. eid can perform Comparison - Attributes are not signed because of portability of evidence. SP relies on correctness on basis of trust in eid. 1 The mechanisms used for SP authentication are quite similar for the German eid, French eid, and Idemix although different names are used to identify the mechanism. 2 Earlier on in the transaction before user authentication by the eid takes place a secure channel is established via PACE. 9/12

10 Characteristic U-prove Idemix French eid German eid Pseudonimisation, between SPs & between sessions with same SP. User may obtain as many certificates as required. Pseudonyms not known to CI and therefore not revocable without additional measures, between SPs & in some cases between sessions with same SP. SP can require same domain pseudonym in each session. Pseudonyms calculated on basis of user master key and in case of domain pseudonym on basis of SP identifier Pseudonyms not known to CI and therefore not revocable without additional measures, between SPs & between sessions with same SP (different possibilities). User can choose pseudonym in transaction with SP. SP can check via transaction process whether the user provided a pseudonym. Pseudonym not on eid or in certificate. Hash over certificate is identifier for SP. User may obtain as many certificates as required. (Alternatively a (one) pseudonym may be present on the eid.) Revocation on basis of eid via IdP., between SPs Pseudonyms calculated by eid on basis of SP identifier. Revocation on basis of pseudonyms possible via SP specific black-list No hotspot Revocation No hotspot in case of long-lived certificates, hotspot in case of shortlived certificates No, not in basic model, although extensions may provide it No hotspot No, not in basic model, although extensions may provide it linking of eid to SP by IdP and SP seems possible based on transaction time Revocation via IdP check of eid No hotspot Revocation via SP specific black list Updateability (extensibility) Of attributes, extensibility via IdP Of attributes, no extensibility Middleware Offline use Requires some form of middleware in case an eid is used in case of long-lived certificates Requires some form of middleware in case an eid is used. Requires generic middleware according to ISO No Requires generic middleware according to ISO and Bürgerclient 10/12

11 6. Collis 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. It will protect the user s privacy while at the same time provide good security to both user and SP. References 1. rss_viewer/nsticstrategy_ pdf national-strategy-trusted-identities-cyberspaceand-your-privacy 2. Privacy Features of European eid Card Specifications by ENISA, see activities/identity-and-trust/privacy-and-trust/eid/ eid-cards-en 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 implemented 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 TR-Privacy_Preserving_Cr 4. blob=publicationfile html 5. cardis.html 11/12

12 6. publications.html Collis Sparked your interest? Want to learn more? Collis provides training courses on Contactless and Mobile Payments and the Trusted Service Manager. Furthermore, Collis has been technology partner for a wide range of NFC Implementations around the world. To learn more about Collis go to the website: About Collis Collis the market leader in secure transaction technology. Collis strong global team is dedicated to delivering innovative solutions to the finance, government, transport and telecom sectors. Collis is the independent, trusted party assisting MNOs, SPs and TSM operators with setting up their NFC/TSM infrastructure and defining their mobile payments strategy. Collis delivers the required expertise through consulting services, test tools and simulators and our mobile test centre concept. All these offerings are essential for a successful implementation of mobile payments, wallets or TSM infrastructures. With over 15 years experience in the secure technology industry, Collis has served hundreds of customers globally with successful implementations of EMV, NFC, mobile payments ID documents and TSM. Collis offers technical and business consultancy, accredited training courses, state-of-the art test tools and simulators and test centre services. Collis has been accredited to perform MasterCard Formal Approval Services and consulting services. Our test tools and simulators have been certified and qualified by the world s leading payments associations (Visa, MasterCard, JCB, American Express and others) as well as industry bodies (EMVco, GlobalPlatform). Collis was acquired by UL in April 2012 to provide end-to-end transaction security globally. Collis locations Collis Global Leiden, The Netherlands Collis GB Edinburgh, Scotland Collis Middle East & Africa Dubai, United Arab Emirates Collis Pacific Auckland, New Zealand Collis Latin America & Caribbean Sao Paolo, Brazil Collis Asia Singapore Collis America Minneapolis, USA Collis Nordic Helsinki, Finland 12/12