Privacy Friendly Applications using Citizen Cards based on Cryptographic Smartcards

Raul Sanchez-Reillo, Ivan Rubio-Polo, Raul Alonso-Moreno, Aitor Mendaza-Ormaza University Carlos III of Madrid

University Group for Identification Technologies (GUTI) Avda. Universidad, 30; 28911 Leganes (Madrid), SPAIN

{rsreillo, irubio, ramoreno, amendaza}@ing.uc3m.es

Abstract—Citizen Cards are being deployed nowadays. Several applications are being developed using such cards. Different kind of services can be provided with such cards, from services demanded by the Administration, to applications from private companies. Unfortunately there is a great amount of applications that are not able nowadays to use the security these cards offer, due to their requirement of keeping the end-user anonymous. This requirement can be forced by the kind of application (e.g. restricted to certain ages), of by data protection laws, where there is no need to access personal data to provide a local service. Authors are proposing in this paper two solutions for this kind of services, benefiting from the already deployed citizen cards, reducing the cost of developing a new card, as well as maintain the card system.

Keywords- Cryptographic Smartcards, Privacy Protection, Private Key Infrastructure (PKI), Anonymity

I. INTRODUCTION Identification cards are used worldwide for a great variety

of applications. One of the most compromising applications is establishing a citizen card, in order to be able to identify all citizens in a certain region/state/country. With that identification, all citizens are allowed to access those services developed for them. When those services involve handling personal information, then a high level of security is required. This is where smartcards can provide a confident way to assure personal information privacy.

Nowadays, many implementations of citizen cards are based on using cryptographic smartcards. This kind of smartcards provides Public Key Infrastructure (PKI) mechanisms, i.e. public key algorithms such as RSA. Thanks to PKI and smartcards, privacy is achieved for a high number of applications, as well as for the identification of the cardholder. Examples of such applications include taxes declaration and payment, registration to social services, etc.

If the citizen card is widely deployed and its legality is assured, then even private companies can consider it as a viable and trustable way of identifying their potential/current customers. Therefore they can offer services as bank account opening, access to the customer profile, electronic commerce,

etc. They can even be considered as a substitute for other identification products, such as a credit or debit card. This is possible as the card offers a perfect link between the user requesting a service, i.e. his/her real identity, and the client identity registered by the service provider.

Unfortunately, although theoretically this kind of services could be currently available, their deployment is just starting, and applications are being defined nowadays. Several kinds of business are looking forward the availability of this kind of solutions. But from those services, some of them will have to face some privacy concerns that impact seriously their business. Those applications do require that same level of trust, but not disclosing identification information. Examples of such applications include access to adult websites, tobacco or alcohol vending machines, execution of parent guided games and applications, or access to local anonymous services. In this kind of applications it is important to use a trusted channel and a valid information generator, but without transmitting information about the real identity of the citizen.

One solution for such kind of requirement would be that those services will implement their own security infrastructure, increasing costs and making their potential clients to go through a new enrolment process.

As this kind of solution faces a large number of inconveniences, authors have developed a solution for providing the required level of trust, but using the same infrastructure that the citizen card uses. This paper will show this work. After this introduction, the next section will cover the general idea of a PKI-based citizen card, and the traditional applications involved. After that, section III will analyze those applications dealing with anonymity and its privacy requirements. Then, section IV will detail the solution proposed and its implementations, providing the advantages and disadvantages of each of the implementations. Finally conclusions and future working lines will be provided.

II. PKI-BASED CITIZEN CARDS AND THEIR APPLICATIONS The idea of having a citizen card comes from the need of

identifying one region citizens in order to provide certain services. This is quite extended in certain countries, where there is a National ID Card, which is used by Governmental This work has been funded by the SEGUR@ Project, within the Industry

Ministry in Spain.

978-1-4244-4170-9/09/$25.00 ©2009 IEEE 189

services as to identify the citizen and check whether he/she can be applying for a certain service.

In certain countries, this is so much accepted by the citizens, and this card is used in a great variety of applications, not only from the Administration, but also from private companies. Checking the age at the entrance of a club, obtaining the identity and address of a person prior to open a bank account, or showing the nationality for entering a museum at lower rates, are examples of this kind of needs.

Even in countries where the idea of having a National ID Card is not welcomed, as the same needs are present, other means of identification have been adopted. Driving licenses, college ID cards or credit cards are being used in those applications. This is driving users to carry a large amount of cards for specific applications, but after all, to perform the same simple function: identifying the card holder. Such trend is also applied to those countries with a National ID Card.

Along the last decade Administrations have started a new trend, trying to provide ID cards that will provide identification services for a large amount of applications. In some cases, this has been started not by countries, but by certain cities or regions. Therefore, the term "citizen card" has been launched, as a generalized term for all kind of ID cards, as long as they are provided by an Administration.

At the same time, the use of electronic means for providing services has been increased, i.e. Internet based services. This has led Administrations to consider how to provide their citizens with an electronic identity, so that the same act of identifying a person can be achieved through Internet. To provide such mean of identification the following premises shall be present:

• Each citizen shall be provided with a unique identifier.

• Transactions, communications, or just the process of identifying the citizen have to be guaranteed. Therefore the requirements of providing authenticity and integrity of the transaction are a must.

• The exchange of information between the citizen and the service provider shall be able to guarantee confidentiality, if desired by both parties.

• There shall be a third party that assures that the electronic identity of such user relates to the real identity of the card holder. This means that if a citizen card is telling that the name of the card holder is Thomas, it shall not happen that such card holder is named Alexander. Allowing this will make the card to lose its trust, and therefore, service providers will not be willing to use it.

As it will be stated later on in this paper, and as it has been shown in many previous works [1][2], Public Key Infrastructure (PKI) solutions with a proper enrolment process, can cover all the above mentioned requirements.

The rest of this section will cover the identification needs requested to a citizen card, as well as how the PKI shall be designed. To illustrate this, a set of example applications will be provided.

A. Citizen Cards and Services Expected Citizen Cards, either physically or electronically, shall

supply certain information about the card holder. Depending on the geographical region, cultural traditions or services to be provided, such information may differ. But most of citizen cards provide the following information:

• Information about the issuance of the document:

o Document number: This is usually considered as a direct link to the citizen's identity.

o Issuer identification

o Issuance date. Sometimes there are two of these dates: the first issuance, and the date of the renewal of the document.

o Expiration date

• Name and surname/s of the card holder

• Residence:

o Address

o City and Region/State

o Country of Residence

• Nationality

• Date of birth

• Graphical means for authentication, such as a face photograph, handwritten signature, etc.

• Electronic means for authentication, such as a Personal Identification Number (PIN code), or biometric references.

• Electronic identity data (as it will be shown in the following subsection).

• Other data. Depending on the country certain extra information may be provided, such as:

o Parents name

o Religion

o Blood group

o Physical description

o etc.

With such information a large amount of services can be provided. Thanks to the different means of authentication, a direct link about the information stated in the document and the physical person showing the document can be performed. Also, most of the relevant information of the citizen is stated in the document, so this is a fast and reliable way to fill in forms for all kind of services, as well as to check such information. Also if the service provider does want to check only some of these data, e.g. the age, he/she can override the rest of the information, except the checking of who the issuer is, and if such service provider relies on the card issuer.

190

B. Public Key Infrastructure (PKI) related to Citizen Cards How PKI can be used to establish an identity relationship

between a client and a service provider can be found in multiple references. Some of them can be [3][4][5]. To summarize this theory, this subsection will explain briefly the main ideas, as to understand the most important facts that will be used in the following sections.

PKI is a generalized term that was originated from the works published about how to use Public Key Algorithms to assure the validity of an electronic transaction. Public Key Algorithms, such as RSA or ECC (Elliptic Curve Cryptography), are based on the idea that each user has a pair of keys, related between them, so that what is ciphered with one key can only be deciphered with its corresponding pair. If one of those two keys is kept secretly by the user (Secret Key, SK), the other one can be made completely public (Public Key, PK). Ways to make such key as public as possible can be inserting it in a public directory, or just sending it freely within the electronic transaction.

Systems become more complex as somebody has to generate and provide such key pairs, to maintain the list of valid keys (or the list of those key pairs that are not longer valid), and to guarantee that the keys generated have been generated by a reliable issuer. These plus other needs, make the implementation of this kind of solution sensibly complex, needing a serious infrastructure to hold this kind of services. This is why the term PKI was created and is the one used nowadays.

The idea is the same as with traditional documents. We can identify a citizen using, for example, his passport, because some relevant information is stated in such document. At the same time, we can check that such document has the shape and antifraud mechanisms that are expected from a passport, and we can also check who has been the issuer of such passport. Therefore we can derive if the issuer is valid, then if the document is valid, and finally if the identification information that we are looking for in the document is valid for our application.

Another way to look at how this process is performed is considering that the user is providing some information that is CERTIFIED by a relevant organization as being valid. This way to understand the process is a common practice when providing some other information such as the University marks or the new residence after moving to a new home. But in this case it is also interesting to understand the process in such a way, because the terminology used in PKI has much to do with the certification concept. In a PKI the same process has to be followed.

1. The service provider receives some information by a citizen.

2. Such information has to be certified as valid by the citizen (this is equivalent as the citizen signing a form in the real world).

a. This will be performed by ciphering such information with the citizen's secret key (SK).

3. The service provider has to check such certification, by requesting the Public Key (PK). Once received, the service provider can decipher the message using the PK, and obtain the information provided by the citizen. Such PK can be obtained from a known directory or by the same information provided by the citizen.

4. The service provider shall verify if such PK is reliable (this is like checking if the ID document is a valid one). Therefore the PK has to be checked for its authenticity. If such authenticity is proven, then the service provider have the assurance that the information provided by the citizen is not only correct, but also coming from a trustable source.

The way to assure that the PK is generated by a reliable issuer, is by providing it not by itself, but ciphered with the SK of the issuer, and providing some reference about who the issuer is. This is called the user's certificate. The certificate is nothing but a known structure containing some information about the citizen, the issuer, and a ciphered version of the user's PK, ciphered with the issuer's SK.

Once the service provider receives the user's certificate, the issuer identification is located, and the service provider can check if such issuer is in his list of reliable issuers. If so, the service provider will know the issuer PK, and can decipher the citizen's PK. With the citizen's PK, the service provider can now check the authenticity and content of the transaction made by the citizen. If the service provider accepts all the previously mentioned steps, then the transaction can follow.

Therefore service providers have to deal with certificates, and as many ways to establish a certificate exist, it comes out the need of using a standard structure for them. One of the most used structures is coming from the Recommendation X.509 [6]. These certificates contain the following information:

• Certificate

o Version

o Serial Number

o Signature Algorithm ID

o Issuer Distinguished Name

o Validity

Not Before

Not After

o Subject

o Subject Public Key Info

Public Key Algorithm

Subject Public Key

o Issuer Unique Identifier (Optional)

o Subject Unique Identifier (Optional)

o Extensions (Optional)

• Certificate Signature Algorithm

191

• Certificate Signature

Within the extensions important information can be included, such as:

• Key Usage to determine the kind of services that should be used with this certificate.

• Authority Information Access, providing information about how to contact the Authority Center, and its certificates.

Last but not least, is important to note that in the Subject field, usually the real name of the user, plus some other information is included (such as the document number). This will be the major drawback for applications requiring anonymity.

Once the structure and functionality of a PKI has been described, there is the need to know how a citizen card interacts with such PKI. When a citizen card is related to a PKI-based architecture, it is based on smartcard technology. This means that at least, the user's certificates are stored securely in the smartcard. But the most recommended implementation is using a cryptographic card to implement the citizen card. Such kind of smart cards are able to perform cryptographic operations, such as ciphering with the SK or PK as requested, keeping the SK always inside the card, and only allowing the outcome of the PK.

Therefore, when a transaction is to be signed by a citizen, it is ciphered by the smartcard, and then the user's certificate is attached to the electronic transaction (if the system is designed without a certificate directory). Depending on the architecture chosen, the smartcard can request a card holder verification via a PIN code or a biometric presentation.

C. Applications with PKI-based Citizen Cards With the information provided by the citizen's certificate,

plus the rest of the information stored in the smartcard, a large amount of applications can be developed. Some examples are provided for illustration purposes:

• Tax Declaration: Using the citizen card, a challenge can be sent to the card and the response can be verified. After receiving such response, the user's certificated is checked, the real identity of the user obtained, and the signing of the challenge checked. With all these steps, the user identity is obtained and most of the frauds have been overcome. Then, such identity can be used to connect to bank systems, property registers and other kind of servers related to tax declaration, so to obtain all financial information needed for such application. Once all data is retrieved, the user can update such information and then, after he/she agrees on the declaration, all data can be signed and sent to the relevant Administration to confirm the user decision on what concepts are included in the declaration.

• Payments: From the same initial procedure used in Tax Declaration, the identity of the user is declared. Therefore it can be used for linking to any

Administration or Service Provider and the relevant Bank, as to provide a signed version of the payment form, including the banking details, and process such payment.

• User authentication to access web services: By sending a challenge to be signed by the citizen card, the card sends the identity, which can be used at any login screen from any web service, to allow the citizen to access such service. This kind of services can include not only electronic banking access, but also e-mail servers or any other kind of web portal.

• Filling forms: As most of the user's data is included inside the smartcard, either at the certificate or in internal files within the card, this information can be used to allow the automatic filling of certain forms in Internet. Through the certificate checking, integrity of such data can be guaranteed.

III. APPLICATIONS REQUIRING ANONIMITY All the above applications can benefit from all information

and services provided by the citizen card. As it can be seen now, any service provider has now a mean to identify its clients, and therefore save all login mechanisms, benefiting from the creation of a secure channel between the service provider and the application. Unfortunately there are a lot of services that would like to obtain such benefits, but they cannot do that due to their need of anonymity. This need of anonymity, as it will be shown below, can come from the sensitivity of the services accessed, or just by the lack of need of knowing more information that what is really needed (which, in some countries is a must, in order to respect some personal data protection laws).

A. Examples of Privacy Concerned Applications As already mentioned, there are a multiple number of

applications where anonymity is required. Some of them because of cultural conditions, others due to religious or legal restrictions, and others for convenience and being in accordance with some data protection laws. Here we can see some of those applications:

• Access to adult sites. There is a great concern about how people can access adult sites, which is an extremely wealthy business, and how to restrict its access to people not compliant to legal constraints. This is more complicated when considering providing the service internationally, as different countries and cultures might have their own limits to consider a citizen as adult. Childhood Protection Organizations, as well as Religious Organizations are requesting mechanisms to deny its access to non-authorized people.

• Electronic voting [7]. Voting is a right that everybody has in modern society. But traditionally voting is considered as anonymous, as to obtain a realistic state of mind without any kind of conditioning from pressure groups. This kind of application request that the identity of the user is not registered, but a guarantee

192

that each citizen can use the system just one single time per voting.

• Automatic teller machines for age restricted products, such as tobacco or spirits. This kind of machines have to prove the age of the consumer, but with a limited possibility of connecting to web services as to check on-line revocation lists. In this applications only the age checking is important (may be, in some countries also the nationality and/or religion). The rest of the information shall be discarded.

• Access control to location restricted services, such as city swimming pools, gyms or other kind of local services. Again, in these applications only the location is needed, so the rest of the information shall be discarded.

B. Privacy Requirements Noting the above mentioned examples, a set of

requirements can be stated as to be used as guidelines for a developer of any of these applications:

• The real identity of the user shall not be disclosed, or at least removed before leaving the environment of the user. As to avoid the Big Brother effect in the client, real identity information shall be removed from the transaction as near as possible to the user.

• Only the relevant information shall be provided through an authenticated channel, i.e. if only the location is needed, no other information has to be retrieved. Therefore the solution to be developed shall provide functions to return only the requested information.

• In any kind of application, a cardholder authentication shall be requested, as to both, verify that the user is really the card holder, and to notify the cardholder that a verification of his/her condition is going to be performed.

IV. SOLUTION PROPOSED

A. General Architecture The suggested architecture consists of four clearly

differentiated parts:

1. One recognized Certification Authority that can validate the client certificates. In order to do this, it will check both their validity and that they are not in a revocation state. To carry out its functions it will use PK cryptography. A fundamental condition is that users involved in the system can trust in this entity.

2. A Testing Laboratory accredited to certificate that the different system components have passed a set of documented and standardized tests in such a way that it can be guaranteed that, both the software and the hardware used, comply with the

security and functionality requirements described for the system.

3. Server. It is a purely software part of the system which will communicate with the client in a reliable and completely anonymous way.

4. Client. It will consist of two modules:

a. A software module to make possible the communication with the different hardware modules, also used to obtain a valid intermediate certificate recognized by the server and send such certificate to the server though a reliable channel.

b. A hardware module, so that it can be guaranteed that the individual identity is at all times in the client. This module will carry out both cryptographic functions and information storage. It will also consist of a smartcard reader to access the Citizen Card data.

Depending on the way the system is going to transmit the information, two different types of architectures will be differentiated: on-line and off-line.

B. On-line architectures Next, the function of each element of the system for on-line architectures will be detailed:

• Certification Authority (CA). In this type of systems, the CA has to verify that the certificate sent by the client, which is stored in the Citizen Card chip, is a valid certificate and is not in a revocation list. This process will be done every time the user wants to establish a communication, i.e. a session with the server.

• Testing Laboratory. It has to evaluate, according to an specific methodology, that the software and hardware elements have passed a set of tests that guarantee, on the one side, that these elements do not misuse personal information and, on the other hand, that they fulfil the described security requisites. Basically, is the element that guarantees that each component does what it has to do.

• Client. Once the software is installed and the hardware is connected, it will have to carry out the following actions:

1. Access the individual certificate. In order to do this, the user will insert his/her Citizen Card in the card reader and will introduce his/her PIN. This way, it will be possible to obtain the corresponding certificate and check its validity by sending it to the CA.

2. Once verified the certificate, the software module will generate the new certificate X.509, but only storing the user

193

information that not compromises his/her anonymity. This way, the new certificate will consist of the following information:

Certificate

• Version

• Serial Number

• Signature Algorithm ID

• Validity

o Not Before

o Not After

• Subject Public Key Info

o Public Key Algorithm

o Subject Public Key

• Extensions (Optional)

Certificate Signature Algorithm

Certificate Signature

3. Once generated this new certificate, already recognized by the CA, it will be stored in the hardware module chip. This way, it will act as a new Citizen Card, but only with the information that does not compromise the user identity. From this moment on, the user can communicate with the server the same way as in PK systems described for Citizen Card, with the same level of guarantee, but without transmitting his/her identity. In order to do this, the user will be asked a PIN, so that the user authenticity will be guaranteed.

4. Next step in the process is to communicate the client with the server. To do this, the client requests access to the server, which then requests the client the certificate generated in the previous step, properly signed with the client private key, and previous insertion of the PIN. As far as the server is concerned, it receives the certificate, which is certificated by the CA and contains the client PK, which can be used to repeat the signature process and check the received data validity.

5. In the last step, the server informs the client about the success or failure of the operation, giving also the client access to the requested information.

Figure 1. Architecture for on-line systems

C. Off-line architectures As stated earlier in this document, there are several use

cases where there is no need, or it is not available, the use of a network connection. Examples of such applications are automatic vending machines for tobacco and alcohol, or access control systems to restricted facilities. For these scenarios the architecture proposed is similar to the one detailed for on-line systems. But in this case, all elements are enclosed in a single device, and therefore security is less compromised.

For such systems, a real time certification authority is not available. Therefore, in order to check the validity of the certificates, only the format and values for each of the fields. But sometimes there is the possibility of using off-line revocation lists that can be updated from time to time. In such cases, if a stolen card is used, the system can reject such card and deny the service.

On the other hand, the testing laboratory shall evaluate those modules to be integrated in those systems (e.g. the vending machines). Those modules will isolate the information at the citizen card with the rest of the systems, and will avoid a misuse of any personal data. The testing laboratory might seal the module as to guarantee to the user that he/she is using a device that has been properly evaluated and that his/her rights are saved.

The steps to be followed in this kind of systems are:

1. The citizen will insert his/her citizen card so that the identification module can extract the certificate, verify its validity and generate a new certificate with the same fields described for the on-line case. Such intermediate certificate will be stored at the module chip, guaranteeing its validity and keeping it securely.

2. The user will establish his/her new PIN code, which will be requested by the application each time an authentication is needed. This way the application is sure that the user of the system is the card holder of the citizen card.

3. Finally the communication will be established, not through a network connection, but through a communication interface. Such interface shall not transmit personal information, and all data related to the user real identity will be removed. Therefore the module or machine manufacturer will not be

194

able to use any personal information for their commercial interest.

4. Once the communication has been established, the system will allow the access, or it will deny it. If access is granted, the user will be able to use such system.

Figure 2. Architecture for off-line systems

V. CONCLUSIONS There is a huge amount of applications that require a high

level of security, as well as verifying certain parameters from the end-user. Citizen cards can provide the means to achieve these goals, but unfortunately the above mentioned services require anonymity. Therefore the personal information from the citizen shall be removed from the transaction, as well as from the building of the secure channel.

Authors have proposed two solutions for this kind of services. One of the solutions is for on-line services, i.e. those services that are provided through a network connection such as Internet. Certain parameters are allowed to be checked, while the rest of the personal data is removed from any transmission. The other solution is dealing with off-line systems, i.e. those systems without any network connection, such as vending machines for adult products (e.g. tobacco, spirits, etc.). These two solutions provide guarantee for both the service providers and the users. The first ones are sure that the client being accessing is a valid one, while the users are sure that their identity is not transferred, so data protection laws are assured.

REFERENCES [1] Serpanos, D. N.;Douligeris, C.; Network Security. June 2007. [2] John R. Vacca; Public Key Infrastructure: Building Trusted Applications

and Web Services. 2004. [3] Kaoru Kurosawa, Swee-Huay Heng: From Digital Signature to ID-based

Identification/Signature. Public Key Cryptography 2004:248-261 [4] Chan H. Lee, Xiaotie Deng, Huafei Zhu: Design and Security Analysis

of Anonymous Group Identification Protocols. Public Key Cryptography 2002:188-198

[5] Joaquín Torres Márquez, Mildrey Carbonell, Jesús Téllez Isaac, José María Sierra: Application of Network Smart Cards to Citizens Identification Systems. CARDIS 2008:241-254

[6] ITU-T. "Recommendation X.509: Information Technology - Open Systems Interconnection - The Directory: Authentication Framework". http://www.itu.int/rec/T-REC-X.509/en.

[7] Gisela Meister, Detlef Hühnlein, Jan Eichholz, Roberto Araujo: eVoting with the European Citizen Card. BIOSIG 2008:67-78

195