Requirements in PKITR   1  CSCA and DS facilities SHALL be secure facilities, well protected from any outside or unauthorized access through inherent design and hardware security facilities. 2  The CSCA SHALL issue a self-signed Country Signing CA Certificate (CCSCA). 3  It is RECOMMENDED that a State replace the CSCA Key every 3 to 5 years; 90 days notice must be given before replacing the Key and certificate. 4  It is RECOMMENDED that the CSCA Key pairs are generated and stored in a highly protected, off line CA infrastructure. 5  Each CCSCA MUST be distributed by strictly secure diplomatic means (out-of-band distribution), bilaterally to each Receiving State; it should also be confirmed using an out-of-band method. 6  Each CCSCA generated by each State MUST also be forwarded to ICAO. 7  The CSCA Private Key is used to sign each Document Signer Certificate (CDS). 8  It is RECOMMENDED that the DS Key pairs are generated and stored in a highly protected CA infrastructure. 9  Each CDS MUST be forwarded to ICAO and MAY be stored in the MRTD’s chip. 10  It is RECOMMENDED that the maximum period a DS Key is used to sign passport documents is three months. 11  States that generate large numbers of MRTDs MAY issue several DS Keys to be used concurrently. 12  The DS Private Key is used to sign each Document Security Object (SOD). 13  Each SOD generated by each State MUST be stored in the corresponding MRTD’s chip. 14  Revocation of a certificate MUST be communicated bilaterally to all other participating States and to the ICAO PKD within 48 hours. 15  Issuing States should distribute ‘routine’ CRLs bilaterally and to the ICAO PKD at least every 90 days. 16  States MUST support the same algorithm for use in their CSCA, DS and SOD, although different key sizes may be required (depending on the algorithm selected); the algorithm used SHALL be one of the algorithms specified in [PKITR]. 17  An issuing State MAY choose to protect its MRTDs against chip substitution by implementing an active authentication mechanism. 18  States MAY choose to implement a Basic Access Control mechanism to prevent skimming and encryption of the communication channel between the inspection system and the MRTD’s chip to prevent eavesdropping. 19  States MAY choose to store additional biometrics, in which case access SHOULD be more restricted. 20  States MAY employ Extended Access Control to control access to additional biometrics, if stored. 21  States MAY restrict access to additional biometrics, if stored, by using encryption. 22  All communication with the ICAO PKD SHALL be based on server side authenticated SSL. 23  Public keys SHALL be sent to the ICAO PKD as X.509 certificates signed using the CSCA Key.  Updates SHALL be performed using LDAP. 24  States SHOULD use existing bilaterally agreed diplomatic channels for the exchange of Certificates and CRLs; where such agreements do not exist they SHOULD be established. 25  It is RECOMMENDED that States establish multiple channels for the distribution of CRLs and confirm reception of CRLs, to protect against Denial of Service attacks. 26  It is RECOMMENDED that secure hardware devices are used for key generation, storage and (eventually) destruction, that have been certified to Common Criteria with EAL 4+ SOF-High against an appropriate Protection Profile. 27  It is RECOMMENDED that the CDS be included in the SOD, to protect against Denial of Service attacks.

Architecture

ICAO Requirements Overview

In their [PKITR] technical report, ICAO has specified some aspects of the implementation of a PKI to support the production of standard, interoperable ePassports.  However, some features are optional and many processes and procedures are not detailed but left for subsequent specification by implementing States.  This may lead to interoperability issues especially where components are being specified, implemented and/or operated by different bodies or organisations. 

At its most basic, [PKITR] is intended to enable receiving States to verify the authenticity and integrity of the data stored in the MRTD in the form specified in [LDSTR] using Contactless Integrated Circuits as specified in [BIOTRI].  The use of Public Key Cryptographic techniques ensures that signed data can be verified using a certificated public key.  ICAO does not specify the CA hierarchy within a State any further than identifying that there must be a Country Signing CA (CSCA) which signs Document Signer (DS) certificates.  There are, however, some requirements imposed on the operation of these facilities which need to be implemented and documented in the Certification Practice Statement (CPS).  The requirements in [PKITR] are not uniquely identified so they are summarised and enumerated on the following side bar for ease of reference in this article.

Figure 2.  ePassport Production System  (Source: Temporal S Ltd.)

Passport Production Systems

Any existing passport production system must already perform a number of significant steps in the process of producing a passport.  This is illustrated in Figure 1 below.

PKI Overview

With the introduction of the requirement for an MRTD offering access for Receiving States to the LDS on a contact-less IC chip, the production process must incorporate elements of a PKI to generate the SOD and subsequently verify it, as well as the facility to populate the LDS and to write data to the chip.  This is illustrated in Figure 2.

PKI Component Functionality

From Figure 2 it is clear that there are a number of components to the PKI that provide the required functionality.  These are further identified in Figure 3 and subsequently specified in the subsections that follow. 

Country Signing CA (CSCA)

The CSCA is operated by (or on behalf of) the Issuing State and must be a secure installation with offline key generation and storage facilities using a CC certified HSM [1,4,26].  It is used to generate a key pair every 3 to 5 years; it is used to generate the resulting self-signed CCSCA, which is distributed by bilaterally agreed diplomatic means to each Receiving State, as well as electronically to the ICAO PKD using LDAP protected by SSL [2,3,5,6,22,23,24].  It is also used to generate the CDS to certificate the signing keys used in the DS at least every three months (or more frequently, especially if multiple DS keys are in use concurrently) [7,10,11].  The CDS must also be delivered electronically to the ICAO PKD using LDAP protected by SSL [9,22,23,24].  The CSCA must also generate a CRL at least every 90 days, and within 48 hours of a certificate being revoked.  CRLs are to be distributed by multiple bilaterally agreed diplomatic means to each Receiving State, as well as electronically to the ICAO PKD using LDAP protected by SSL [14,15,22,23,24,25].

Production Interface

The Production Interface provides the means to enable communication and interaction between the CSCA and the MRTD production facility.  There may be multiple MRTD production facilities communicating with the State’s CSCA.  The Production Interface also ensures appropriate, timely and correct communication with the HSM.  The Production Interface will not only provide the interface between the MRTD production facility and the HSM/CSCA, it will also provide the interface to the management facility.

Hardware Security Module (HSM)

The HSM is a secure device that is designed to protect cryptographic keying material in use and in storage and should be Common Criteria (CC) certified.  The HSM is used to securely generate key pairs, store them and use them to perform signing operations for the Document Signer and verification operations for the Document Verifier [8,26].  It may also act as a repository of the appropriate certificates from the CSCA. 

The HSM can be implemented using off the shelf devices from various suppliers, some of which have been CC evaluated and certified to appropriate protection profiles.  Multiple HSMs would provide redundancy and load sharing and enable common resources to be used for document signing, verification and key generation/management.  Most HSMs are available as cards to be installed in a server, requiring a device per server and offering little or no redundancy.  HSM appliances are now available that can provide HSM services to multiple servers across a local area network and which can be used in multiple configurations to provide redundancy, offering a more scalable solution. 

Management

Management will enable the MRTD production facility’s requirements on the CSCA to be managed effectively.  Thus it will provide the means to ensure the timely generation of new key pairs for the DS, certificate requests for the resulting public keys to be sent to the CSCA and revocation requests of compromised certificates to be sent to the CSCA [8,10,11,14].

Document Signer (DS)

The DS is operated as a part of the MRTD production facility.  It is passed the LDS Data Groups by the production facility and, through the Management Interface uses the HSM to perform the signing operation, generates and returns the SOD including the CDS for the production system to store in the MRTD IC chip [8,12,13,27].

Document Verifier (DV)

The DV is operated as a part of the MRTD production facility.  It is passed the LDS Data Groups and the SOD read from an MRTD IC chip by the production QA facility and, through the Management Interface uses the HSM to perform the signature verification operation, generates and returns a response to the QA system to verify the data in the MRTD IC chip [8].

PKI Interfaces

Interface to ICAO PKD

The interface to the ICAO PKD is specified in [PKITR] as LDAP on communications channels protected by server side authenticated SSL.

Interface to Receiving States

This is specified in [PKITR] as existing bilateral diplomatic agreements between States, or newly established agreements where they don’t currently exist.  It is recommended that multiple channels be established to protect against Denial of Service attacks.

Production Interface

This interface will be dependent on the passport production system.

Interface to CSCA

The interface between the CSCA and the DS is not specified in the [PKITR] except in so far as the keys and certificates are identified and defined.  In some environments the CSCA may be implemented as an integral part of the system and the interface can be chosen to be the most appropriate means of moving cryptographic material between the CSCA and the HSMs, probably using PKCS#11 [PKCS].  More usually, however, the CSCA will be a separate, externally operated facility.  In that case, if it is a pre-existing facility, the interface is likely to be defined and enforced by the operating body.  If not the same mechanism can be specified as would be used internally.

Operational Environment

Certificate Policies

[PKITR] does not specify the certificate policies that should be employed for either the CCSCA or the CDS.  Given that the CCSCA is distributed to Receiving States to validate the CDS used in an individual MRTD, it is clear that a Receiving State needs to be able to have confidence in the validity and applicability of both the CCSCA and the CDS.  With no specified, over-arching certificate policies, it is up to each Issuing State to determine appropriate Certificate Policies, with the applicability being implied by usage.  At least initially it is unlikely that there will be a need for multiple Policies relating to the CDS, although there should be different policies for the CCSCA and the CDS.

Certification Practice Statement

[PKITR] does not specify a Certification Practice Statement (CPS) to which the CSCA should conform.  The requirements merely use vague terms to describe operational security, such as “secure facilities, well protected”[1] and “Highly protected”[4,8]; recommend some maximum periods for key validity [3,10]; specify supported signature and hashing algorithms and recommend minimum key lengths for each [16]; recommend erasing private keys in an “auditable and accountable manner”  It is not clear if there will be any process to ensure that CSCA facilities are being operated in accordance with a suitable CPS, nor how that suitability could be determined.  It is incumbent, therefore, on the operator of the CSCA to specify and adhere to a suitable CPS.  This would normally be the responsibility of the Issuing State, being separate from the MRTD production facilities, but in some limited implementations the CSCA may be operated in the same environment and specification of the CPS may therefore fall to the implementers.

Service Level Constraints

Operating a service that will conform to [PKITR] will require a level of management of the PKI components over and above the day-to-day mechanics of signing SODs.  The management, and indeed operation, of the PKI is not specified in [PKITR], although some constraints are specified or recommended and as a result a number of management functions can be deduced and parameters identified.

• CSCA key and CCSCA Generation -- Within the CSCA, a new key pair should be generated every 3 to 5 years with 90 days notice provided to Receiving States [3].  These keys are used to issue a self-signed certificate, which is distributed by diplomatic means bilaterally to each Receiving State and to ICAO [2,5,6].  The certificate should also be confirmed by a separate out of band method (not specified) [5].  There must, therefore, be a function to generate the prior notice and then schedule the generation of the new key pair as well as the issuance and diverse distribution of the concomitant certificate and backup of the key material. This will need to allow ad hoc initiation as well as enforcing initiation within the preset (parameterised) timescale.

• CSCA CDS Generation -- Within the CSCA, receipt of a certificate request from a DS will result in the generation of the certificate, its return to the requesting DS and the forwarding of the certificate to the ICAO PKD [7,9].  There must, therefore, be a function to respond to a certificate request, generating the required certificate and returning it to the requester, as well as distribution of the certificate to the ICAO PKD.  This will need to allow automated initiation as a result of receiving a request as well as enforcing initiation with a manually applied request.

• CSCA CRL Generation -- Within the CSCA, receipt of a certificate revocation request from a DS will result in the revocation of the certificate, an entry in the CRL and the forwarding of the CRL bilaterally to Receiving States and to the ICAO PKD within 48 hours [14].  There must, therefore, be a function to respond to a certificate revocation request, generating the required CRL entry and diverse distribution of the CRL.  This will need to allow automated initiation as a result of receiving a revocation request. Within the CSCA, if no CRL has been distributed for 90 days, then a CRL must be distributed bilaterally to Receiving States and to the ICAO PKD [15].  There must, therefore, be a function to enforce the diverse distribution of the CRL if it has not been distributed for 90 days.  This will need to allow automated initiation.

• DS Key Generation  Within the DS, a new key pair should be used at least every three months [10].  The key pair will be generated within the HSM and a certificate request composed and sent to the CSCA. If multiple DSs are in use they may each use a separate key or can all share the same key, if multiple HSMs are in use they may each use a separate key or can all share the same key [11].  Once expired, keys should be erased in an auditable and accountable manner.  There must, therefore, be a function to initiate the generation of a new key pair by an HSM, the generation of the concomitant certificate request and its dispatch to the CSCA, the receipt of the resultant certificate and its storage, the backup of the key material and distribution of the keys if they are being shared by multiple HSMs and the erasure of expired keys.  The method of distribution and sharing will be dependent on the particular mechanisms supported by the HSMs in use.  This function will need to allow ad hoc initiation as well as enforcing initiation within the preset (parameterised) timescale.

Security

[PKITR] does not specify security surrounding the CSCA or the DS in anything other than vague terms, such as “secure facilities, well protected”[1] and “highly protected”[4,8]. Included in the CPS should be the identification of the means by which the facilities are secured against breaches of confidentiality or integrity as well as denial of service attacks, considering physical measures such as faraday cages, procedural measures such as dual control, and logical measures such as key splitting for backups.

No specification is provided in [PKITR] for securing communications between the CSCA and the DS, although communications from the CSCA to the ICAO PKD are specified as being protected by SSL.  Where such communications are travelling outside of a single secure facility they should be protected at least by 128bit SSL or by the use of a VPN using AES or 3DES.

No specification is provided in [PKITR] for securing the communication between the DS and the HSM.  The Production Interface intercedes between the two and should provide at least an SSL protected interface.  Many HSMs support proprietary means of communicating, some network HSM appliances use SSL to protect communications; in either case this would be handled by the Production Interface.

Minimum key lengths are specified in [PKITR] for the algorithms used in signing operations.  Optional access control mechanisms are defined to increase the security of the MRTD itself in use.