5 ePassport and eID Technologies
95
Hence invalidating eIDs and replacing them with new ones on a large scale might be
infeasible. Unfortunately, one cannot exclude that a security flaw or an exploit will
be found after deployment. Therefore it would be reasonable to design in advance
pragmatic strategies for such situations which are not based on replacement.
As an eID is issued for a long period of time (typically 10 years in the case of
personal ID documents and passports), inevitably many generations of eIDs will
have to coexist and interact with the existing systems. On the other hand, if a
user gets a new eID replacing the expired one, they should be able to continue all
activities as the same person. This might be a problem, since transferring the signing
keys from the old eID to a new eID might be technically impossible or forbidden
due to, e.g., requirements for “secure signature creation devices”.
Malicious Provider/Document Issuer Before an eID is given to its owner it has
to go through procedures implemented by the hardware and software provider and
the document issuer responsible for personalization of the eID. These procedures
may be not strict enough and/or depend on the internal policies of these parties.
This can open doors for implementing trapdoors or intentional creation of security
weaknesses.
A malicious hardware provider can implement secret backdoors that reveal the
secret keys of the eID (created during personalization) or provide a means to trace
the eID. Similar backdoors can be implemented in software by the document issuer.
A malicious issuer can still infer information about users, even if the software is
somehow protected (e.g., installed by a different authority). In many cases the secret
keys used by the cryptographic protocols can be generated on-card (i.e., by the eID
without revealing the secret key to anyone). However, the owner of the document
has no guarantee that this is how the keys have been generated. What is more, in
many cases the secret keys cannot be generated on-card since secret system keys
have to be involved.
A different attack technique is to use a flawed random number generator that
would allow an attacker to predict the secret key generated by the document and
break any protocol based on randomness generated by an eID. The problem can be
also caused by a flawed software library. This was the case for the Estonian eID,
where many RSA moduli were created in a way that made their factorization easy.
Interoperability While in the area of biometric passports we have to deal with
a de facto worldwide standard, in the case of personal ID documents there are a
variety of different solutions and concepts. At the same time, the expectation is that
an eID may interact with any system and communicate with any reader. This is
costly and hardly possible from the technical point of view. The problem has been
recognized by the European Union as an obstacle to the internal market. The eIDAS
regulation [546] attempts to find a solution to this problem. The approach chosen by
eIDAS is as follows. Assume that an eID J attempts to connect to a terminal T in a
third country. Then:
• the terminal T redirects the connection request of J to an online authentication
service A of the country of origin of J ,
95
Hence invalidating eIDs and replacing them with new ones on a large scale might be
infeasible. Unfortunately, one cannot exclude that a security flaw or an exploit will
be found after deployment. Therefore it would be reasonable to design in advance
pragmatic strategies for such situations which are not based on replacement.
As an eID is issued for a long period of time (typically 10 years in the case of
personal ID documents and passports), inevitably many generations of eIDs will
have to coexist and interact with the existing systems. On the other hand, if a
user gets a new eID replacing the expired one, they should be able to continue all
activities as the same person. This might be a problem, since transferring the signing
keys from the old eID to a new eID might be technically impossible or forbidden
due to, e.g., requirements for “secure signature creation devices”.
Malicious Provider/Document Issuer Before an eID is given to its owner it has
to go through procedures implemented by the hardware and software provider and
the document issuer responsible for personalization of the eID. These procedures
may be not strict enough and/or depend on the internal policies of these parties.
This can open doors for implementing trapdoors or intentional creation of security
weaknesses.
A malicious hardware provider can implement secret backdoors that reveal the
secret keys of the eID (created during personalization) or provide a means to trace
the eID. Similar backdoors can be implemented in software by the document issuer.
A malicious issuer can still infer information about users, even if the software is
somehow protected (e.g., installed by a different authority). In many cases the secret
keys used by the cryptographic protocols can be generated on-card (i.e., by the eID
without revealing the secret key to anyone). However, the owner of the document
has no guarantee that this is how the keys have been generated. What is more, in
many cases the secret keys cannot be generated on-card since secret system keys
have to be involved.
A different attack technique is to use a flawed random number generator that
would allow an attacker to predict the secret key generated by the document and
break any protocol based on randomness generated by an eID. The problem can be
also caused by a flawed software library. This was the case for the Estonian eID,
where many RSA moduli were created in a way that made their factorization easy.
Interoperability While in the area of biometric passports we have to deal with
a de facto worldwide standard, in the case of personal ID documents there are a
variety of different solutions and concepts. At the same time, the expectation is that
an eID may interact with any system and communicate with any reader. This is
costly and hardly possible from the technical point of view. The problem has been
recognized by the European Union as an obstacle to the internal market. The eIDAS
regulation [546] attempts to find a solution to this problem. The approach chosen by
eIDAS is as follows. Assume that an eID J attempts to connect to a terminal T in a
third country. Then:
• the terminal T redirects the connection request of J to an online authentication
service A of the country of origin of J ,