Difference between revisions of "EPassport"

From YobiWiki
Jump to navigation Jump to search
Line 54: Line 54:
 
done
  
done
 
</source>
  
</source>
  +
  +
CSCA Master List LDIF can be used e.g. with jmrtd after being imported into a LDAP server. Thanks to Nicola Murino for the tip.
  +
 
==Verifying a passport==
  
==Verifying a passport==
 
===Passive Authentication===
  
===Passive Authentication===

Revision as of 00:13, 13 December 2011

ICAO standards

Certificates

Overview

  • CSCA certificate (Country Signing CA certificate)
    • is typically valid for their period of intended use + period of validity of the issued passports + 3 months (e.g. 5+10+0.25) and renewed after their period of intended use (e.g. 5 years).
    • is used to verify the DS certificate
  • DS certificate (Document Signer certificate)
    • is typically valid for the period of validity of the passport itself + 3 months and renewed after their period of intended use (3 months). (e.g. 10+0.25)
    • is used to verify the integrity of the EF_DG* files of the passport through their hashes signed in EF_SOD
    • is optionally present in the EF_SOD file of the passport (mandated by US-VISIT & by EU I think)
  • SOD (Document Security Object)
    • RFC3369 CMS Signed Data Structure, signed by the Document Signer (DS).
    • Carries the hashed LDS Data Groups.
    • Stored in the MRTD’s chip.
    • MAY carry the Document Signer Certificate
  • AA (Active Authentication) keys
    • private key stored in the chip
    • public key available in EF_DG15, whom hash key is signed in SOD by DS

As per epassport2008 there are several certificates for the full EAC solution: 

Element                              File name
CSCA certificate - name              NN_CSCA.der (.der, .cer)
DS certificate                       NN_DS (.der, .cer) preferably included in the ePassport chip
CVCA certificate                     NN_CVCA.cvcert (minimal validity at least 2 month)
CVCA private key under PKCS#8 format NN_CVCA.pkcs8
DV certificate                       NN_DVCA.cvcert (effective date like CVCA certificate)
IS certificate                       NN_IS.cvcert (effective date like CVCA certificate)
IS private key under PKCS#8 format   NN_IS.pkcs8

CSCA certificates

Stupid script to see what are the country certificates there (there are also CRLs): 

#!/bin/bash 

rm xx*
csplit pkd.000033.ldif '%userCertif%' '/^userCertif/' '{*}'
for i in xx*; do
    cat $i |sed '1s/^.*:://;/:/,/qwerty/d' |openssl base64 -d|openssl x509 -inform der -out $i.pem -outform pem
    cat $i |sed '1s/^.*:://;/:/,/qwerty/d' |openssl base64 -d|openssl x509 -inform der -text -noout > $i.txt
    test $? -eq 0 && rm $i
done

CSCA Master List LDIF can be used e.g. with jmrtd after being imported into a LDAP server. Thanks to Nicola Murino for the tip.

Verifying a passport

Passive Authentication

Example to verify a French passport:

Get France CSCA certificate: hum you should get country certificates from a trusted source ;-) 

$ wget -O - http://jmrtd.org/csca/fr.cer |openssl x509 -inform  der -outform pem -out fr.PEM

EF_SOD certificate should have been extracted by RFIDIOt, if not:

EF_SOD is a signed payload, encapsulated into a "response message template format 2" (DER type 77) so we need to decapsulate this extra layer first. 

$ tail -c+5 EF_SOD.BIN > EF_SOD.DER
$ openssl pkcs7 -in EF_SOD.DER -inform DER -out EF_SOD.PEM -outform PEM

The first operation removes blindly the first 4 bytes, which should be good enough for most cases, when EF_SOD.DER has a size between 256 and 65535 bytes. If it fails for you, you can look manually for the signed PKCS7 payload and extract it: 

$ openssl asn1parse -in EF_SOD.BIN -inform DER -i|grep -B1 pkcs7-signedData
   4:d=1  hl=4 l=1742 cons:  SEQUENCE         
   8:d=2  hl=2 l=   9 prim:   OBJECT            :pkcs7-signedData

So in this example we need (4+1742) bytes from offset 4, either via dd or: 

$ openssl asn1parse -in EF_SOD.BIN -inform DER -out EF_SOD.BIN2 -noout  -offset 4 -length 1746

Verify DS certificate stored in the passport with country CSCA certificate: 

$ openssl pkcs7 -in EF_SOD.PEM -print_certs -outform PEM |openssl verify -CAfile fr.PEM
stdin: OK

Verify SOD is well signed by DS 

$ openssl smime -verify -in EF_SOD.PEM -inform pem -noverify > EF_SOD.data
Verification successful

Note that the 2 previous steps can be combined in one: 

$ openssl smime -verify -in EF_SOD.PEM -inform pem -CAfile fr.PEM > EF_SOD.data
Verification successful

So if you don't have your country's CSCA certificate, you can only do the -verify -noverify step.

In case that step fails with an error message similar to: 

Verification failure
10280:error:2107C080:PKCS7 routines:PKCS7_get0_signers:signer certificate not found:pk7_smime.c:378:

then see next section how to deal with such faulty SOD.

Verify files hashes are those signed in SOD
EF_SOD.data is ASN1 you can parse to retrieve the SHA1 of the DG* files, e.g.:

$ openssl asn1parse -in EF_SOD.data -inform DER -i 

   0:d=0  hl=3 l= 150 cons: SEQUENCE          
   3:d=1  hl=2 l=   1 prim:  INTEGER           :00
   6:d=1  hl=2 l=   7 cons:  SEQUENCE          
   8:d=2  hl=2 l=   5 prim:   OBJECT            :sha1
  15:d=1  hl=3 l= 135 cons:  SEQUENCE          
  18:d=2  hl=2 l=  25 cons:   SEQUENCE          
  20:d=3  hl=2 l=   1 prim:    INTEGER           :01
  23:d=3  hl=2 l=  20 prim:    OCTET STRING      [HEX DUMP]:D560D2D999F12923D92DBB1E5EE55232B4A4C1B1
  45:d=2  hl=2 l=  25 cons:   SEQUENCE          
  47:d=3  hl=2 l=   1 prim:    INTEGER           :02
  50:d=3  hl=2 l=  20 prim:    OCTET STRING      [HEX DUMP]:637018B2449BE126CE9D4B6CAE98D92198829B6D
  72:d=2  hl=2 l=  25 cons:   SEQUENCE          
  74:d=3  hl=2 l=   1 prim:    INTEGER           :0B
  77:d=3  hl=2 l=  20 prim:    OCTET STRING      [HEX DUMP]:E9F3127A90D7A8C6237018DA294299C3EE61E03C
  99:d=2  hl=2 l=  25 cons:   SEQUENCE          
 101:d=3  hl=2 l=   1 prim:    INTEGER           :0C
 104:d=3  hl=2 l=  20 prim:    OCTET STRING      [HEX DUMP]:9C878F2D2B1E22BD876E65F092FF76F2E5719D87
 126:d=2  hl=2 l=  25 cons:   SEQUENCE          
 128:d=3  hl=2 l=   1 prim:    INTEGER           :0D
 131:d=3  hl=2 l=  20 prim:    OCTET STRING      [HEX DUMP]:43B89A69B60BEFE5B51752B896951C21F3601B60

and compare them with 

$ sha1sum EF_DG1.BIN 
d560d2d999f12923d92dbb1e5ee55232b4a4c1b1  EF_DG1.BIN
$ sha1sum EF_DG2.BIN 
637018b2449be126ce9d4b6cae98d92198829b6d  EF_DG2.BIN
$ sha1sum EF_DG11.BIN 
e9f3127a90d7a8c6237018da294299c3ee61e03c  EF_DG11.BIN
$ sha1sum EF_DG12.BIN 
9c878f2d2b1e22bd876e65f092ff76f2e5719d87  EF_DG12.BIN
$ sha1sum EF_DG13.BIN 
43b89a69b60befe5b51752b896951c21f3601b60  EF_DG13.BIN

To be perfect, we should also check CSCA and DS against CRLs supposedly available at ICAO PKD.

Passive Authentication: signer certificate not found

If you got an error such as: 

$ openssl smime -verify -in EF_SOD.PEM -inform pem -noverify > EF_SOD.data
Verification failure
10280:error:2107C080:PKCS7 routines:PKCS7_get0_signers:signer certificate not found:pk7_smime.c:378:

it might be that the PKCS7 structure is inconsistent and identity of the signature issuer is not literally the same as the identity of the embedded certificate issuer.

You can see it with the following command, where smime verify failed for Italian passport and succeeded for Belgian passport: 

$ openssl cms -cmsout -in italian/EF_SOD.PEM -inform PEM -noout -print|grep issuer:
         issuer: C=IT, O=MINISTERO DELL'INTERNO, OU=PE, CN=CERTIFICATION AUTHORITY
         issuer: CN=CERTIFICATION AUTHORITY, OU=PE, O=MINISTERO DELL'INTERNO, C=IT
$ openssl cms -cmsout -in belgian/EF_SOD.PEM -inform PEM -noout -print|grep issuer:
         issuer: C=BE, O=Kingdom of Belgium, OU=Federal Public Service Foreign Affairs Belgium, CN=CSCAPKI_BE
         issuer: C=BE, O=Kingdom of Belgium, OU=Federal Public Service Foreign Affairs Belgium, CN=CSCAPKI_BE

According to section 7 of RFC 5280, this is indeed wrong (thanks Nicola Murino):

"Two distinguished names DN1 and DN2 match if they have the same number of RDNs, for each RDN in DN1 there is a matching RDN in DN2, and the matching RDNs appear in the same order in both DNs"


We can try to fix it manually: 

$ openssl asn1parse -inform DER -in EF_SOD.BIN -i

=> look about the 2 containers holding the 2 non-matching issuer names, in our case those are: 

 164:d=7  hl=2 l=  93 cons:        SEQUENCE         
 166:d=8  hl=2 l=  11 cons:         SET              
 168:d=9  hl=2 l=   9 cons:          SEQUENCE         
 170:d=10 hl=2 l=   3 prim:           OBJECT            :countryName
 175:d=10 hl=2 l=   2 prim:           PRINTABLESTRING   :IT
 179:d=8  hl=2 l=  31 cons:         SET              
 181:d=9  hl=2 l=  29 cons:          SEQUENCE         
 183:d=10 hl=2 l=   3 prim:           OBJECT            :organizationName
 188:d=10 hl=2 l=  22 prim:           PRINTABLESTRING   :MINISTERO DELL'INTERNO
 212:d=8  hl=2 l=  11 cons:         SET              
 214:d=9  hl=2 l=   9 cons:          SEQUENCE         
 216:d=10 hl=2 l=   3 prim:           OBJECT            :organizationalUnitName
 221:d=10 hl=2 l=   2 prim:           PRINTABLESTRING   :PE
 225:d=8  hl=2 l=  32 cons:         SET              
 227:d=9  hl=2 l=  30 cons:          SEQUENCE         
 229:d=10 hl=2 l=   3 prim:           OBJECT            :commonName
 234:d=10 hl=2 l=  23 prim:           PRINTABLESTRING   :CERTIFICATION AUTHORITY

and 

1304:d=7  hl=2 l=  93 cons:        SEQUENCE         
1306:d=8  hl=2 l=  32 cons:         SET              
1308:d=9  hl=2 l=  30 cons:          SEQUENCE         
1310:d=10 hl=2 l=   3 prim:           OBJECT            :commonName
1315:d=10 hl=2 l=  23 prim:           PRINTABLESTRING   :CERTIFICATION AUTHORITY
1340:d=8  hl=2 l=  11 cons:         SET              
1342:d=9  hl=2 l=   9 cons:          SEQUENCE         
1344:d=10 hl=2 l=   3 prim:           OBJECT            :organizationalUnitName
1349:d=10 hl=2 l=   2 prim:           PRINTABLESTRING   :PE
1353:d=8  hl=2 l=  31 cons:         SET              
1355:d=9  hl=2 l=  29 cons:          SEQUENCE         
1357:d=10 hl=2 l=   3 prim:           OBJECT            :organizationName
1362:d=10 hl=2 l=  22 prim:           PRINTABLESTRING   :MINISTERO DELL'INTERNO
1386:d=8  hl=2 l=  11 cons:         SET              
1388:d=9  hl=2 l=   9 cons:          SEQUENCE         
1390:d=10 hl=2 l=   3 prim:           OBJECT            :countryName
1395:d=10 hl=2 l=   2 prim:           PRINTABLESTRING   :IT

So we will copy the issuer name from the certificate (the second one) into the signer block.
Which means copying from offset 1304 the 95 bytes (hl=2 + l=93) to offset 164.
If both blocks don't have the same size initially, it won't work!! 

$ cp EF_SOD.BIN EF_SOD.BIN.fix
$ dd if=EF_SOD.BIN.fix of=EF_SOD.BIN.fix bs=1 seek=164 skip=1304 count=$((93+2)) conv=notrunc

Now trying on the new EF_SOD.BIN.fix file: 

$ tail -c+5 EF_SOD.BIN.fix > EF_SOD.DER.fix
$ openssl pkcs7 -in EF_SOD.DER.fix -inform DER -out EF_SOD.PEM.fix -outform PEM
$ openssl smime -verify -in EF_SOD.PEM.fix -inform pem -noverify > EF_SOD.data.fix
Verification successful

If it still fails, you can also try manually to get the SOD payload: 

$ openssl asn1parse -inform DER -in EF_SOD.BIN|grep -m1 OCTET|awk -F: '{print $4}'|xxd -r -p > EF_SOD.data

Active Authentication

Note that for this specific French passport, AA doesn't seem to be possible, no DG15!

A4.2. Active Authentication Mechanism
Active Authentication is performed using the ISO7816 INTERNAL AUTHENTICATE '88' command. The input is a nonce (RND.IFD) that MUST be 8 bytes. The ICC computes a signature, when an integer factorization based mechanism is used, according to ISO9796-2 Digital Signature scheme 1 ([R17], ISO/IEC 9796-2, Information Technology – Security Techniques – Digital Signature Schemes giving message recovery – Part 2: Integer factorisation based mechanisms, 2002.). cf D1.3.1.2
M MUST consist of M1 and M2, where M1 MUST be a nonce of length c – 4 bits and M2 is RND.IFD.
The trailer option 1 MUST be used in case of SHA-1, if not SHA-1 then option 2 MUST be used.
The result of the signature computation MUST be signature 3 without the non-recoverable message part M2.

Extracting the public key of the passport: 

$ tail -c+4 EF_DG15.BIN |openssl rsa -pubin -inform der -text -out EF_DG15.PEM -outform pem

You can realise an AA challenge and collect the response e.g. in AA1.BIN
Here is an example without BAC, for illustration: 

cla=00 ins=88 p1=00 p2=00 lc=08 data=0001020304050607(=M2)

Extracting the recoverable part of the message from the signature: 

$ openssl rsautl -inkey EF_DG15.PEM -pubin -keyform PEM -in AA1.BIN -raw -verify -out AA1.data

The message should have the format '0x6A' || M1 || H(M1||M2) || '0xBC' if SHA-1 is used
Trailer could also be 2 bytes, one identifying the hash algo and the last one being '0xCC'
Header is 0b01|1(partial recovery)|0000(padding)|1=61 => xor 'B' = 6A
To verify the hash, compare its copy with your own calculation: 

$ dd if=AA1.data bs=1 skip=1 count=106 2>/dev/null |xxd -p|sed '4a0001020304050607'|xxd -p -r|sha1sum
5dc9eee4a0428414eaba0b920d15b064ba054104  -
$ dd if=AA1.data bs=1 skip=107 count=20 2>/dev/null |xxd -p
5dc9eee4a0428414eaba0b920d15b064ba054104

See also Belgian_ePassport#Active_Authentication

Security of the ePassport infrastructure

Papers

Tools

See also below.
eCl0wn and mrpkey (RFIDIOt) can clone data of a chip but they cannot clone the secret counterparts of elements linked to AA or EAC therefore they're stripping such elements (e.g. EF.DG15) from EF.COM.
However as stated by ICAO in its supplement to Doc 9303, rel7, R1-p1_v2_sIV_0006: Authenticity, integrity and completeness of the LDS data should be verified using the Document Security Object and not the EF.COM, as a matter of good inspection system design.

US Passport Card

Don't mix US Passport Book (ICAO) with the US Passport Card (see also wikipedia), valid when entering the United States from Canada, Mexico, the Caribbean and Bermuda at land border crossings or sea ports-of-entry and skimmed much more easily. Won’t this chip violate Americans’ privacy? There will be no personal information written on the electronic chip itself. The chip will have only a unique number pointing to a stored record contained in secure government databases.[...] In addition, to mitigate any possibility that the card could be tracked, it will be issued with a protective sleeve that will prevent the card from being read when not in use.

In the news:

Tools

OpenMRTD

library

JMRTD

Java host API & Javacard applet to build your own epassport infrastructure

RFIDIOt

See RFID#RFIDIOt

eCL0WN

Applet for Nokia NFC phone

vonJeek emulator

ePassport viewer by UCL

Specific countries

Manufacturers

Chip/Book

PKI

Misc

Retrieved from "https://wiki.yobi.be/index.php?title=EPassport&oldid=7374"