The new German eId card has security, privacy and usability limitations.

I recently learnt that the new German identity card (or nPA for neuer Personalausweis has security, privacy and usability problems. This was brought to my attention during a number of discussions with experts, as well as a recent publication by a group of researcher from Frauenhofer SIT. The findings have been verified against the official documentation. The issues concern the eID application on the card that is to be used for authentication on the Internet (and not the electronic passport functionality that is also present on the same card).

The eID application on the card supports, among other things, the following three functions when accessing an on-line service.

• Authentication of the card holder.
• Privacy friendly verification of the age and place or region of residence of the cardholder.
• Restricted Identification, which generates a secure pseudonym that represents the user within a particular application domain (e.g. the financial sector, or health care, or government services).

When the eID application is used, first a secure channel is set up between the smart card and the server. Chip authentication is based on a private key that is stored on the card. For privacy reasons, this key is shared with a batch of other cards. I am told the size of the batch is 500 (but I have been unable to verify this number) 1.5 million cards. Sharing a key is necessary, because otherwise a particular card could be traced using the corresponding public key that is transmitted to the terminal at the start of the chip authentication phase.

Security of the authentication feature of the eID application is not very strong, because the data provided by the card (e.g. cardholder name) is not signed. (Note that in the passport application on the same card, this data is signed.) Instead, it is assumed that by virtue of the secure channel between the card and the server and the fact that authenticity of the chip is verified through chip authentication, the card will reliably deliver the correct data to the server. This means that if the private key of a single key used for chip authentication is compromised, an attacker can create a card that can send arbitrary data that will be accepted by the server at face value. As a consequence, the attacker can impersonate an arbitrary person.

Privacy protection offered by sharing the same chip authentication key with a batch of cards appears to be ok. If the batch was small (which initially appeared to be the case), there are two options:

• Cards in the same batch are distributed randomly over the country. This means that it is highly unlikely that two cards from the same batch (with the same key) will be owned by two people living in the same place. As a consequence it is very likely that the public key of a card uniquely identifies a person, at least when he is using the card at or around his place of residence. (This is most notably a concern when using the eID application in offline scenario's like buying cigarettes from a vending machine, and to a much lesser extent in on-line scenario's.)
• Cards in the same batch are all issued to people that all live in the same place. But then the public key reveals the place of residence of the card holder.

So this is a case of 'damned if you and damned if you don't'...

Finally, the restricted identification feature is designed in such a way that it is not very practical. The general idea of such a feature is to generate a pseudonym based on the identity of the user as well as a sector specific public value shared among all services within this sector. Typically, a hash-function is used for this to ensure that the resulting pseudonym cannot be used to retrieve the underlying user identity. With such a setup, the pseudonyms for the same user at different sectors cannot be linked to each other (but the same user will always have the same pseudonym within a single sector). Unfortunately, the eID application does not use a user identifier but instead uses a secret key on the card as input to the hash function. This leads to problems when the user looses the card, or if the card needs to be replaced. In that case, the secret key is no longer available, and the user will get a new card with a new key. Then the restricted identification feature will generate a different pseudonym for this user based on this new key. As a results, all data associated with the old pseudonym are no longer accessible to the user, as he cannot prove that he 'is' the owner of that old pseudonym. [Note added 10-05-2012: part 3 of BSI TR-03110 defines generation of this key to be out of scope of the specification. It does however suggest to use a key stored by a third party to generate this key (which would solve this issue). However, German law does not allow that a German citizin is assigned a unique lifelong number, which such a key would in fact be...]