258 lines
8.9 KiB
XML
258 lines
8.9 KiB
XML
|
|
|
|
<section>
|
|
<title>ePassports - Electronic Passports</title>
|
|
|
|
<section>
|
|
<title>Introduction</title>
|
|
<para>
|
|
Electronic passports that are deployed arond the world (including Germany) will
|
|
be based on RFID technology.
|
|
</para>
|
|
<para>
|
|
Technically speaking, ePassports are ICAO[1] compliant MRTD[2]'s. ICAO is an
|
|
international body that already specifies the current OCR readable lines on
|
|
travel documents. The ICAO MRTD specifications are publicly available from the
|
|
ICAO homepage.
|
|
</para>
|
|
<para>
|
|
From a technical point of view, ePassports are ISO 14443-1,2,3,4 compliant
|
|
contactless smart cards. On top of 14443-4 transport layer protocol, APDU's
|
|
according to ISO 7816-4 are exchanged.
|
|
</para>
|
|
<para>
|
|
For those readers who are not familiar with smart card technology: ISO 7816-4
|
|
(tries to) specify interindustry commands for interchange with ID cards.
|
|
</para>
|
|
<para>
|
|
The ISO 7816-4 smartcard provides a filesystem based interface to the
|
|
information stored on the ePassport. The Application software issues
|
|
high-level commands such as "SELECT FILE", "READ BINARY" to the MRTD.
|
|
</para>
|
|
<para>
|
|
The ICAO recommends a minimum memory size of 32kBytes. However, it recommends
|
|
as much memory as possible, and indicates 512kBytes as a target.
|
|
</para>
|
|
<para>
|
|
As of now, the MRTD chip has to operate in a write once, read many fashion.
|
|
After the document is issued, it must not be allowed to change any data.
|
|
Future standards may include the possibility to store electronic visa data.
|
|
</para>
|
|
</section>
|
|
|
|
<section>
|
|
<title>Organization of Data</title>
|
|
|
|
<para>
|
|
Data on the ePassport is organized according to a specification called LDS
|
|
(logical data structure). LDS specifies a number of DG's (Data Groups), as
|
|
well as the encoding of the data.
|
|
</para>
|
|
|
|
<para>
|
|
The most important data groups are:
|
|
</para>
|
|
|
|
<para>
|
|
DG1 is mandatory and contains the same data as printed on the cover page like
|
|
name, date of birth, expiration date, document number, nationality, etc.
|
|
</para>
|
|
<para>
|
|
DG2 (mandatory) contains the JPEG2000 encoded facial image and corresponding biometric data
|
|
</para>
|
|
<para>
|
|
DG3 (optional) contains biometric fingerprint data - not in German passports
|
|
</para>
|
|
<para>
|
|
DG4 (optional) contains biometric iris data - not in German passports
|
|
</para>
|
|
|
|
<para>
|
|
ICAO requires data in DG1 and DG2 to be stored unencrypted, since it only
|
|
resembles the data that is human-readable on the printed pages of the passport.
|
|
Additional biometric data such as iris and/or fingerprint information may be
|
|
stored in an encrypted format. As of now, this is up to the issuing country.
|
|
Any form of encryption is outside the ICAO MRTD specifications and will thus not
|
|
work interoperable on an international level.
|
|
</para>
|
|
<para>
|
|
All biometric information stored within LDS is further encoded according to
|
|
CBEFF (Common Biometric Exchange File Format, NISTIR 6529-A), a common file
|
|
format that facilitates exchange and interoperablity of biometric data.
|
|
</para>
|
|
<para>
|
|
Each data group is cryptographically signed. The signature is stored in EF.SOD
|
|
(Security Object Data).
|
|
</para>
|
|
</section>
|
|
|
|
<section>
|
|
<title>Security Features</title>
|
|
|
|
<section>
|
|
<title>Randomization of unique serial number</title>
|
|
<para>
|
|
All ISO14443 compatible RFID chips disclose a unique serial number during the
|
|
anticollision procedure. This poses the potential threat of pseudonymised
|
|
tracking. The German BSI therefore requires this randomization of the
|
|
serial number.
|
|
</para>
|
|
</section>
|
|
|
|
<section>
|
|
<title>Passive Authentication (mandatory)</title>
|
|
<para>
|
|
Passive authentication performs verification of the EF.SOD signature(s). This
|
|
assures that the content of the data groups is signed by the issuing country.
|
|
However, passive authentication does not prevent copying of a MRTD.
|
|
</para>
|
|
</section>
|
|
|
|
<section>
|
|
<title>Active Authentication (optional)</title>
|
|
<para>
|
|
Ative authentication can be employed to verify that the chip has not been
|
|
substituted. It is based on a challenge response protocol.
|
|
The MRTD chip contains an active authentication public key Pair (KPrAA and
|
|
KPuAA). A hash representation of KPuAA is stored in EF.SOD and therefore
|
|
authenticated by the issuing country certifiate. KPrAA is stored in on-chip
|
|
secure memory.
|
|
</para>
|
|
</section>
|
|
|
|
<section>
|
|
<title>Basic Access Control (optional, implemented in Geman ePassports)</title>
|
|
<para>
|
|
Basic access control denies access to the MRTD chip until the inspection system
|
|
proves that it is authorized to access the chip. This proof of authorization
|
|
is done by deriving a pair of keys (Kmac and Kenc) from the OCR-read machine
|
|
readable zone (MRZ). BAC can therfore prevent unauthorized "harvesting" of
|
|
passport data without being noticed by the passport holder. BAC also mandates
|
|
that any communication following-up to BAC has to be encrypted via ISO 7816-7/8
|
|
secure messaging (SM). This transport level security can be somewhat compared
|
|
to running TLS on top of a TCP session.
|
|
</para>
|
|
</section>
|
|
|
|
<section>
|
|
<title>Extended Access Control (optional)</title>
|
|
<para>
|
|
Extended Access Control prevents unauthorized access to additional biometrics.
|
|
It is similar to Basic Access Control, but requires separate keys and key
|
|
management. There is no ICAO MRTD standard on how it is implemented or used,
|
|
and therefore subject to the issuing state.
|
|
</para>
|
|
</section>
|
|
|
|
</section> <!-- security architecture -->
|
|
|
|
<section>
|
|
<title>The Public Key Hierarchy</title>
|
|
<para>
|
|
The PKI hierarchy is obviously nothing that directly affects the passport
|
|
itself. However, it is integral to the security of the system, so this paper provides a quick overview:
|
|
</para>
|
|
<para>
|
|
All keys are issued in the familiar form of X.509 certificates.
|
|
</para>
|
|
<para>
|
|
Each issuing state operatesits own "Country Singing CA". There is no
|
|
supernational Root CA. This is neccessary, since every country decides on its
|
|
own if it recognizes a particular other country. This also means that every
|
|
reader ("inspection system") has to store the Document Signer Certificate of
|
|
every recognized issuing country.
|
|
</para>
|
|
<para>
|
|
The individual ePassports are signed using Document Signer Keys. The Document
|
|
Signer Keys are in turn signed by the Country Signing CA. Document Signer keys
|
|
have limited lifetime, and it is recommended that issuing countries delete the
|
|
private key after the last passport for that key has been issued.
|
|
</para>
|
|
<para>
|
|
Issuing countries have to provide certificate revocation lists (CRLs) at least
|
|
every 90 days, but not more often than every 48 hours
|
|
</para>
|
|
<para>
|
|
The ICAO operates a "public key directry" which will be set up as X.500
|
|
directory, updates are performed over LDAP. All communication with the PKD is
|
|
SSL authenticated. The PKD stores Document Signer Certificates, but not
|
|
Country signing CA certificates. ICAO verifies signatures of all incoming
|
|
Certificates and CRL's before making them available. The PKD has public read
|
|
access on the internet.
|
|
</para>
|
|
<para>
|
|
Country signing CA certificates will be provided bilaterally between countries.
|
|
</para>
|
|
|
|
</section>
|
|
|
|
<section>
|
|
<title>Crypto Algorithms</title>
|
|
<para>
|
|
The ICAO MRTD specification allows RSA, DSA and Elliptic Curve DSA with various
|
|
minimal key lengths:
|
|
</para>
|
|
|
|
<informaltable border="1" width="90%">
|
|
<tgroup cols="4">
|
|
<thead>
|
|
<row><entry>Algorithm</entry><entry>Active Auth</entry><entry>Document Signer</entry><entry>Country Signing CA</entry></row>
|
|
</thead>
|
|
<tbody>
|
|
<row>
|
|
<entry>RSA</entry><entry>1024</entry><entry>2048</entry><entry>3072</entry>
|
|
</row>
|
|
<row>
|
|
<entry>DSA</entry><entry>1024/160</entry><entry>2048/224</entry><entry>3072/256</entry>
|
|
</row>
|
|
<row>
|
|
<entry>ECDSA</entry><entry>160</entry><entry>224</entry><entry>256</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable>
|
|
|
|
</section>
|
|
|
|
<section>
|
|
<title>Security threats</title>
|
|
|
|
<section>
|
|
<title>Small Keyspace of basic access control</title>
|
|
<para>
|
|
The entropy of the MRZ data used to derive Kenc and Kmac for basic access
|
|
control is very limited. The nine digit document number is concatenated with
|
|
the date of birth and the expiration date of the document.
|
|
</para>
|
|
<para>
|
|
Since ICAO MRTD specifications recommend ePassports not to be valid for more
|
|
than five years, the expiration date can only be one out of (365*5 = 1325)
|
|
values.
|
|
</para>
|
|
<para>
|
|
The date of birth can realistically assume only values between 18 and 90 years
|
|
old (365*72 = 26280). Also, in case of a specific person, the range of the DOB
|
|
can often be estimated to a certain range.
|
|
</para>
|
|
<para>
|
|
Document Numbers are issued sequentially in some countries, and can therefore
|
|
be reduced to certain ranges. In Germany, the first four digits specify the
|
|
issuing department, and the following five digits increment sequentially.
|
|
</para>
|
|
</section>
|
|
|
|
<section>
|
|
<title>Grandmaster Chess Attack</title>
|
|
<para>
|
|
The Active Authentication mechanism is meant to prevemt chip substitution (e.g.
|
|
carbon copying). However, it cannot prevent a "grandmaster chess attack",
|
|
where the inspection system talks to a "proxy" chip that would temporarily
|
|
communicate with the original MRTD.
|
|
</para>
|
|
</section>
|
|
|
|
|
|
</section> <!-- security -->
|
|
|
|
</section> <!-- passports -->
|