From fca59bea770346cf1c1f9b0e00cb48a61b44a8f3 Mon Sep 17 00:00:00 2001 From: Harald Welte Date: Sun, 25 Oct 2015 21:00:20 +0100 Subject: import of old now defunct presentation slides svn repo --- 2005/rfid-lk2005/mrtd.xml | 257 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 257 insertions(+) create mode 100644 2005/rfid-lk2005/mrtd.xml (limited to '2005/rfid-lk2005/mrtd.xml') 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 @@ + + +
+ePassports - Electronic Passports + +
+Introduction + +Electronic passports that are deployed arond the world (including Germany) will +be based on RFID technology. + + +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. + + +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. + + +For those readers who are not familiar with smart card technology: ISO 7816-4 +(tries to) specify interindustry commands for interchange with ID cards. + + +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. + + +The ICAO recommends a minimum memory size of 32kBytes. However, it recommends +as much memory as possible, and indicates 512kBytes as a target. + + +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. + +
+ +
+Organization of Data + + +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. + + + +The most important data groups are: + + + +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. + + +DG2 (mandatory) contains the JPEG2000 encoded facial image and corresponding biometric data + + +DG3 (optional) contains biometric fingerprint data - not in German passports + + +DG4 (optional) contains biometric iris data - not in German passports + + + +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. + + +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. + + +Each data group is cryptographically signed. The signature is stored in EF.SOD +(Security Object Data). + +
+ +
+Security Features + +
+Randomization of unique serial number + +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. + +
+ +
+Passive Authentication (mandatory) + +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. + +
+ +
+Active Authentication (optional) + +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. + +
+ +
+Basic Access Control (optional, implemented in Geman ePassports) + +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. + +
+ +
+Extended Access Control (optional) + +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. + +
+ +
+ +
+The Public Key Hierarchy + +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: + + +All keys are issued in the familiar form of X.509 certificates. + + +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. + + +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. + + +Issuing countries have to provide certificate revocation lists (CRLs) at least +every 90 days, but not more often than every 48 hours + + +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. + + +Country signing CA certificates will be provided bilaterally between countries. + + +
+ +
+Crypto Algorithms + +The ICAO MRTD specification allows RSA, DSA and Elliptic Curve DSA with various +minimal key lengths: + + + + + +AlgorithmActive AuthDocument SignerCountry Signing CA + + + + RSA102420483072 + + + DSA1024/1602048/2243072/256 + + + ECDSA160224256 + + + + + +
+ +
+Security threats + +
+Small Keyspace of basic access control + +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. + + +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. + + +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. + + +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. + +
+ +
+Grandmaster Chess Attack + +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. + +
+ + +
+ +
-- cgit v1.2.3