To prevent the abuse of a stolen or a lost identity card, an eID cardholder must be able to block or cancel the card via a revocation management scheme [20]. If the eID card chips have a dedicated public-private key pair, then revocation is simple because the cards can be cancelled by means of a chip-specific public key that can be compared with a global revocation list. But such chip-specific feature is unique for a person and this leads to a direct identification or tracking of the eID card- holder thereby undermining the data protection and privacy friendly design of the nPA’s eID function. For example, an online age-restricted service that requires only the proof of age must not be able to use a unique revocation attribute to cross-reference these data with a service that receives other attributes of the user such as name, address etc., from the identify document. This aspect is important especially when it comes to the restricted identification (Pseudonym) function of nPA as it thrives to achieve cross-domain unlinkability to preserve the privacy of a user. To avoid such conflicts, nPA uses service-specific revocation lists. This means that every identity card transmits a service-specific and card-specific revo- cation attribute to the service provider during the electronic identification process, which the provider then checks against his individual, i.e. service-specific revoca-
tion list [1].
If a service provider supports nPA’s eID function, then a service-specific re- vocation list is generated from a global revocation list. The chip on the eID card calculates a card-specific and service-specific revocation token and sends it to the service provider during an authentication. This token can then be compared with the entries in service provider’s revocation list in order to identify revoked ID cards. The procedure followed in this revocation scheme is describes in the following steps:
• Initialization of the Revocation Service: The revocation service generates a key pair and publishes its public key referred to as the revocation sector public key PKRevSector.
• Initialization of a service provider: The eID CA generates a revocation key pair for its registered service providers; the public key referred to as PKSector
is calculated from the chosen private key SKSector15 and the revocation sec-
tor public key PKRevSector. The service provider then receives a certificate
containing its sector public key PKSector.
• TheID card manufacturer generates a revocation key, a revocation password and a revocation code and sends them to the revocation service. The revo- cation key is the public key of the key pair generated during the production of the ID card (PKID of chip authentication) and for security reasons, its
length is 256 bits; the corresponding private key (SKID) is stored securely on
the card chip and used for generating the revocation token. The revocation password is a conventional password that is randomly chosen during the card production, sent to the municipality where it is stored in a database; this password cannot be changed and it is sent to the eID cardholder along with the eID PIN code for the eID card. The revocation code is a cryptographic hash value of a concatenation of the cardholder’s date of birth, surname, first name and revocation password; this code is generated during the card production and sent to the revocation service along with the revocation key and to the municipality where it can be stored.
• In the case of loss or stealth of an eID card, the cardholder can initiate the revocation at the municipality, with the police or via the revocation hotline. Once the revocation code is transferred to the revocation service, it looks up the respective revocation key and projects it into the revocation sector, a mathematical operation that requires the revocation service’s private key
15Note: SK
SKRevSector. This so-called ’activated revocation key’ is then distributed to
all the eID certification authorities [20].
• The eID Certification Authority (eID CA) transforms this revocation key into a service provider specific revocation token by making use of the unique public key of the card PKID (used in Restricted Identification protocol) and
service provider specific private key (SKSector).
• During the eID authentication, the eID card calculates the same revocation token in the same way as it calulates the service-provider specific pseudonym (Refer to Restricted Identification protocol in Section 2.5). This revocation token is contained in the service provider-specific revocation list; this enables the service provider to recognize that the eID card has been revoked. • Revocation of the service providers i.e rights to read data from the chip
should also be revocable. Usually CVCA certificates have a short validity (depending on the data that can be read from the chip from 2 upto 30 days) and a recall of such a certificate can be realized by the non-issuing of a new one for this service provider.
An overview of nPA revocation process is provided by the Figure 2.6. This figure is taken from the document on the privacy-friendly revocation method used in German national eID card by Bender et al. [20].
Advantages of nPA revocation management scheme are listed below: • The use of the service provider-specific and the card-specific revocation to-
kens makes it impossible for a service provider to recognize an eID card that has already authenticated to another service provider thereby achieving privacy in the form of cross-domain unlinkability.
• The revocation service being the central institution in this scheme also cannot derive the service provider-specific and card-specific revocation tokens from the revocation keys (without the help from the service provider and the eID certification authority). Thus, it is impossible to track an eID card by making use of the revocation mechanism.
• The revocation of lost or stolen eID cards should be available all the time i.e 24 hours a day and 7 days a week even when the eID cardholder is away from home. This would require storing of all the personal information necessary for the identification of the cardholders along with the revocation keys in the revocation service’s database. Such a generation of central database of the citizens is prohibited by the German law. The alternative solution that is
Figure 2.6: Overview of the nPA revocation process for a lost or a stolen eID card adopted in nPA revocation scheme is that the revocation service’s database stores only the revocation keys and their respective revocation code which is the cryptographic hash value over the concatenation of the cardholder’s date of birth, surname, first name and revocation password. This privacy-friendly implementation of revocation management thus allows an effective revoking of ID cards without the need of a central register that contains the citizens’ personal information.
• Revocation password is a randomly chosen conventional password sent to the municipality and to the user by the ID manufacturer and it cannot be changed by the user. This password is susceptible to hacks, for instance, dictionary attacks. Revocation code is in turn generated using the card- holder’s date of birth, surname, first name (that are available on the card) and revocation password. So the entropy of the generated revocation code is low.
• Within the same domain of a service provider, the revocation token still makes tracking possible.