94
L. Hanzlik and M. Kutyłowski
5.4 PKI
In standard situations the Public Key Infrastructure (PKI) is built on top of trust
relations. A user chooses roots of trust—entities that are trusted by him. A root of
trust can delegate trust to other entities, creating a chain of trust. In the end, the user
will accept/trust any entity that can prove itself to be a member of a chain of trust.
To confirm trust relations, the entities issue certificates signed with their secret keys.
A similar approach could be implemented in the eID scenario, but we face
substantial technical problems. The hardware chip of an eID might be severely
limited in computational power and memory size. Storing many roots of trust
and verifying long chains of trust would immediately make an eID solution quite
inefficient. For this reason a simplified approach has been adopted:
• the root of trust is set to one entity, namely the country verifying certificate
authority (CVCA),
• the CVCA delegates its rights to domestic and foreign document verifiers that
delegate rights to terminals—so the trust chains have a length of at most 2,
• certificates have a form enabling easy verification on hardware with limited
resources (card verifiable certificates, CVC).
This PKI allows for interoperability between passports issued by different countries.
However, in order to inspect a passport, a document verifier must be trusted by
the document owner’s CVCA, which requires cooperation between two countries.
Practically it turns out to be a problem.
Another serious problem is revoking certificates. In a standard situation it is
implemented using certificate revocation lists (CRL) and an online certificate status
protocol (OCSP). In the case of eID systems this may lead to technical problems:
• an eID has no memory available for storing CRLs,
• an eID has no direct access to the OCSP server,
• verification may turn out to be too slow from a practical point of view,
• an eID has no internal battery and therefore no internal clock. It can only store
the time last seen, so a terminal may authenticate itself with an outdated CRL.
The solution implemented in ePassports is to use short-term certificates for terminals. Thereby, a terminal that has to be revoked simply does not receive a new
certificate.
5.5 Challenges for eID Systems
In this section we focus on some fundamental issues that do not concern eIDs
directly, but nevertheless are crucial for their success in practice.
Deployment of eIDs Due to financial costs, the deployment of eIDs has to be
a continuous process, where the production capacities are used evenly over time.
L. Hanzlik and M. Kutyłowski
5.4 PKI
In standard situations the Public Key Infrastructure (PKI) is built on top of trust
relations. A user chooses roots of trust—entities that are trusted by him. A root of
trust can delegate trust to other entities, creating a chain of trust. In the end, the user
will accept/trust any entity that can prove itself to be a member of a chain of trust.
To confirm trust relations, the entities issue certificates signed with their secret keys.
A similar approach could be implemented in the eID scenario, but we face
substantial technical problems. The hardware chip of an eID might be severely
limited in computational power and memory size. Storing many roots of trust
and verifying long chains of trust would immediately make an eID solution quite
inefficient. For this reason a simplified approach has been adopted:
• the root of trust is set to one entity, namely the country verifying certificate
authority (CVCA),
• the CVCA delegates its rights to domestic and foreign document verifiers that
delegate rights to terminals—so the trust chains have a length of at most 2,
• certificates have a form enabling easy verification on hardware with limited
resources (card verifiable certificates, CVC).
This PKI allows for interoperability between passports issued by different countries.
However, in order to inspect a passport, a document verifier must be trusted by
the document owner’s CVCA, which requires cooperation between two countries.
Practically it turns out to be a problem.
Another serious problem is revoking certificates. In a standard situation it is
implemented using certificate revocation lists (CRL) and an online certificate status
protocol (OCSP). In the case of eID systems this may lead to technical problems:
• an eID has no memory available for storing CRLs,
• an eID has no direct access to the OCSP server,
• verification may turn out to be too slow from a practical point of view,
• an eID has no internal battery and therefore no internal clock. It can only store
the time last seen, so a terminal may authenticate itself with an outdated CRL.
The solution implemented in ePassports is to use short-term certificates for terminals. Thereby, a terminal that has to be revoked simply does not receive a new
certificate.
5.5 Challenges for eID Systems
In this section we focus on some fundamental issues that do not concern eIDs
directly, but nevertheless are crucial for their success in practice.
Deployment of eIDs Due to financial costs, the deployment of eIDs has to be
a continuous process, where the production capacities are used evenly over time.