1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
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 -->
|