diff options
author | Harald Welte <laforge@gnumonks.org> | 2015-10-25 21:00:20 +0100 |
---|---|---|
committer | Harald Welte <laforge@gnumonks.org> | 2015-10-25 21:00:20 +0100 |
commit | fca59bea770346cf1c1f9b0e00cb48a61b44a8f3 (patch) | |
tree | a2011270df48d3501892ac1a56015c8be57e8a7d /2005/rfid-lk2005/mrtd.xml |
import of old now defunct presentation slides svn repo
Diffstat (limited to '2005/rfid-lk2005/mrtd.xml')
-rw-r--r-- | 2005/rfid-lk2005/mrtd.xml | 257 |
1 files changed, 257 insertions, 0 deletions
diff --git a/2005/rfid-lk2005/mrtd.xml b/2005/rfid-lk2005/mrtd.xml new file mode 100644 index 0000000..4db57c3 --- /dev/null +++ b/2005/rfid-lk2005/mrtd.xml @@ -0,0 +1,257 @@ + + +<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 --> |