Messaging and Directory Server software used around the world in the Government, Military, Aviation and Commercial sectors.

isode.com / solutions / horizontal solutions /

Directory to support MRTD (Machine Readable Travel Documents)

Machine Readable Travel Documents (MRTD) and in particular passports and national identity cards are using increasingly sophisticated techniques to prevent forgery and to ensure document currency.

MRTDs will generally be issued by an agency, using a system under tight control. Document verification will take place in many places. Passports will be verified nationally and in other countries. Verification for functions other than border control will become increasingly important and useful (for example, a Bank may wish to perform validation of a Passport or other MRTD prior to opening a new account).

What Isode Provides

Isode provides all of the directory components needed in support of MRTD issuing and verification:

• M-Vault. A high performance secure directory server supporting LDAP and X.500.
• Strong authentication and signed operations using digital signatures.
• Support for certificates and other PKI related data, including GUI display and validation.
• Web and GUI tools for directory access and administration.
• Operational management capabilities, including GUI Consoles and SNMP (Simple Network Management Protocol).
• High performance secure directory synchronisation using Sodium Sync, enabling flexible sharing of data with external directories.

On this page you'll find information on how directories can be used to support MRTD security including the elements that comprise MRTD validation, smart cards, certificate and PKI, the role of directory in document issue, document verification and distribution information between 'issuing' and 'verifying' directory servers.

MRTD Validation

Modern MRTD validation has a number of elements:

• Direct document validity checks (e.g., to ensure that printed numbers have legal values).
• Document consistency checks (e.g., to ensure that printed information, including information in UV and other formats not human visible is consistent with information held on a smart card).
• Biometric checks between the document bearer and information in the document.
• Checks against external sources, for example to ensure that the MTRD was issued by a valid source and has not been revoked.

Directories can provide support for the last type of check by enabling the efficient and secure sharing of information around the world, as illustrated below:

The diagram shows how an issuer uses a directory to publish information that needs to be shared for validation, and this in turn is distributed to other directory servers that will be used by one or more systems performing MRTD validation. The rest of this page looks in more detail as to how this could be put together.

Smart Cards, Certificates & PKI

MRTD systems make use of PKI (Public Key Infrastructure and Certificates). Background information on PKI is given in the Isode white paper "A Short Tutorial on Distributed PKI". MRTDs will typically contain a smart card that is used to hold two things:

1. A Certificate issued to the holder of the smart card, and an associated private key.
2. Information that is used to verify the MRTD including:
   • Information about the user.
   • Repeat of information in printed format, including non-visible formats such as UV to enable constancy checks to be made.
   • Biometric information, such as photograph and finger print data, to enable biometric checks.

The validity of the information on the smart card may be checked in one of two ways.

• Passive Authentication This relies on the smart card being tamper proof, and that the information can be assumed valid, simply because it is on the smart card, and that the Certificate on the card is valid.
• Active authentication. The inspection system will interact with the smart card, which will digitally sign information with its private key that can be checked against the certificate. This will give much stronger validation, as the private key never leaves the card and so cannot be copied.

Consistency checks protect against simple forgery, and biometric checks using data from the smart card ensure that the MTRD was issued to the person presenting it. Smart card checks ensure information integrity, and validate that the certificate is associated with the MRTD.

The role of PKI is to securely validate the certificate, and to build a trust chain between the certificate on the MRTD and the inspection system. For a passport, the certificate will be issued by a national DSCA (Document Signing CA) which will in turn be certified by the single national CSCA (Country Signing CA). The inspection system will have a trust chain to the CSCAs in all countries that it wishes to validate passports for. Other MRTDs will build similar trust chains.

In addition to providing the trust path, PKI enables revocation of the certificate or parts of the trust path using CRLs (Certificate Revocation Lists).

Document Issue & Secure Directory

When an MRTD Issuer issues a document, it is important to retain information associated with the MTRD and its owner for a number of reasons:

• Audit, including as a reference record when issuing other MRTDs which may overlap or conflict.
• To retain records for easy update of the MRTD, including change of information or certificate update.
• To enable revocation of the MTRD.
• To provide information to systems performing or supporting MTRD validation.

A directory is a natural location to hold this information, as it provides high performance access using a standard schema. It provides an effective mechanism to share information with MRTD verifiers. This component may also be referred to as a "Certificate Distribution Centre" (CDC) or as an ICAO Public Key Directory (PKD). The above diagram shows how information is published to a directory at the same time as the document is issued.

This information is important and sensitive, and strong security features are important in the repository for this information. For digitally signed information, security is still important to prevent denial of service attacks. Further information is provided on our Secure Directory Solutions page.

In addition to this "per document" information, the MRTD Issuer will need to share and update information related to other authenticated entities and to the issuer itself. This information needs to be published and shared with MRTD verification systems.

Document Verification

Some aspects of MRTD verification are local issues. Some aspects of validation need access to data that is managed remotely (quite possibly in another country). Directory is a natural place to hold this information, as it enables simple and secure sharing of structured information using open standards.

The diagram above shows how an Inspection System will make use of access to the directory to obtain information to assist with the MRTD verification. Information in the directory may come from the issuer, or be held in the directory as a convenient mechanism to share information between Inspection systems.

Two types of information may be accessed:

1. Information in support of digital signature validation. In order to verify a digital signature, there is a need to perform "path discovery" which relates to the security trust chain, and then to check the validity of all elements of the path, ensuring that it conforms to security policy and that no elements are expired or revoked. Information on how the directory is used to support this functionality is described in the Isode white paper "Distributed Directory in support of large scale PKI".
2. Information related to the MRTD being verified. Additional information may be used in support of security checks, or to provide information that may be used after authentication, perhaps to determine authorization.

Extended Access Control

The model so far has shown how an inspection system will verify an MRTD. MRTD smart cards contain sensitive information, and it is desirable to restrict access to this, both for privacy reasons and to help prevent data copying and forgery. Extended Access Control is a mechanism where the smart card on the MRTD uses PKI to ensure that information is only provided to valid inspection systems.

Inspection systems have certificates issues by national DVCAs (Document Verification CAs). A DVCA’s certificate is issued by the national CVCA (Country Verification CA). The national CVCA will also validate all foreign DVCAs that it wishes to allow to validate its national passports. A passport’s smart card will hold its national CVCA as a trust anchor, so an inspection system can provide the passport with a complete trust chain.

It is important to protect against inspection systems being stolen. The passport smart card will have insufficient space to check (large) CRLs, so the approach taken is for Inspection Systems and DVCAs to have short lived certificates. This requires frequent certificate update and international certificate propagation in order to make this work.

Distributing Information in the Directory

LDAP and X.500 are the most important directory open standards. X.500 defines the information model and services for a directory, with a client/server protocols (DAP – Directory Access Protocol) and server/server protocols for chaining and replication. LDAP (Lightweight DAP) defines a protocol based on the X.500 information model and service. All X.500 directories support LDAP. LDAP is also used to access directories that do not support X.500 (either standalone servers, or using proprietary server/server protocols).

There are two basic approaches to handle distribution of information from the Issuer's directory server to the directory server used by the verifier. The first is to make them a part of a single distributed directory. If X.500 is followed, this interconnection is straightforward, and can be provided by a combination of techniques:

• Chaining. The verifying directory server will connect to the issuing directory server to read necessary information and return to the verifying system.
• Replication. To enhance performance, data can be replicated between the servers using X.500 DISP (Directory Information and Shadowing Protocol) that will securely and efficiently keep a local copy of the data up to date.

This is a robust and proven architecture, and recommended where it can be applied.

In many situations, issuer and verifier operate independently, and this level of tight co-ordination is impractical. Here it makes sense to transfer data over in a more ad hoc manner, using Directory Synchronization. More information on directory synchronization is provided in the Isode white paper Replicating and Synchronizing Data Between Directory Servers. Isode's Sodium Sync product enables this synchronization.