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 -->