Difference between revisions of "EPassport"
| Line 40: | Line 40: | ||
===CSCA certificates=== |
===CSCA certificates=== |
||
* see http://jmrtd.org/csca.shtml |
* see http://jmrtd.org/csca.shtml |
||
| − | * [http:// |
+ | * [http://www.icao.int/Security/mrtd/Pages/default.aspx ICAO PKD] |
* [https://pkddownloadsg.icao.int/ICAO/pkdLDIFDownload.jsp ICAO PKD LDIF download] |
* [https://pkddownloadsg.icao.int/ICAO/pkdLDIFDownload.jsp ICAO PKD LDIF download] |
||
Stupid script to see what are the country certificates there (there are also CRLs): |
Stupid script to see what are the country certificates there (there are also CRLs): |
||
Revision as of 13:53, 26 April 2012
ICAO standards
- ICAO MRTD
- ICAO9303-pt1-vol1.pdf
- ICAO9303-pt1-vol2.pdf
- ICAO9303-pt3.pdf
- Supplement to ICAO Doc 9303 - Release_7
- LDS 1.7
- Others:
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
New CSCA Master List LDIF is using another syntax.
It can be used e.g. with jmrtd after being imported into a LDAP server. Thanks to Nicola Murino for the tip.
Here is another ugly script to parse it (note that jmrtd code is also ugly ;-) )
#!/bin/bash
rm xx*
csplit pkdML.* '%CscaMasterListData%' '/^CscaMasterListData/' '{*}'
for i in xx*; do
cat $i |sed '1s/^.*:://;/:/,/qwerty/d' |openssl base64 -d > $i.raw
test $? -eq 0 && rm $i
done
for FILE in xx*.raw; do
# offset to the meat
off=$(eval echo $(openssl asn1parse -in $FILE -inform der -i |\
grep -A2 "d=4.*2\.23\.136\.1\.1\.2"|\
grep "HEX DUMP"|\
sed 's/^ *\([0-9]\+\).*hl=\([0-9]\+\).*/$((\1+\2))/'))
eval $(openssl asn1parse -in $FILE -inform der -i -offset $off|\
awk "/:d=1/{b=0}
/:d=1.*SET/{b=1}
/:d=2/&&b{print $1}"|\
sed 's/^ *\([0-9]\+\).*hl= *\([0-9]\+\).*l= *\([0-9]\+\).*/dd if=$FILE bs=1 skip=$((\1+$off)) count=$((\2+\3))|openssl x509 -inform der -out ${FILE%.raw}.$((\1+$off)).pem -outform pem;openssl x509 -in ${FILE%.raw}.$((\1+$off)).pem -inform pem -noout -text > ${FILE%.raw}.$((\1+$off)).txt;/')
done
Parsing pkdML.000016.ldif (2012-04-20) gave 190 certificates from 49 countries
$ grep -h Issuer: *txt|sort|uniq
Issuer: C=AT, O=GV, OU=BMI, CN=CSCA-AUSTRIA
Issuer: C=AU, O=GOV, OU=DFAT, OU=PTB, CN=Passport Country Signing Authority
Issuer: C=BE, O=Kingdom of Belgium, OU=Federal Public Service Foreign Affairs Belgium, CN=CSCAPKI_BE
Issuer: C=ca, O=gc, OU=pptc, CN=csca-canada
Issuer: C=CH, O=Admin, OU=Services, OU=Certification Authorities, CN=csca-switzerland-1
Issuer: C=CH, O=Admin, OU=Services, OU=Certification Authorities, CN=csca-switzerland-2
Issuer: C=CY, O=Republic of Cyprus, OU=Civil Registry and Migration Department, CN=CSCA-CYPRUS
Issuer: C=CZ, O=Czech Republic, OU=Ministry of Interior, CN=CSCA_CZ
Issuer: C=DE, O=bund, OU=bsi/serialNumber=001, CN=csca-germany
Issuer: C=DE, O=bund, OU=bsi/serialNumber=013, CN=csca-germany
Issuer: C=DE, O=bund, OU=bsi/serialNumber=100, CN=csca-germany
Issuer: C=DK, O=Danish National Police, OU=Danish National Police, CN=Passport CSCA-Denmark/serialNumber=1
Issuer: C=DK, O=Danish National Police, OU=Danish National Police, CN=Passport CSCA-Denmark/serialNumber=2
Issuer: C=DK, O=Kingdom of Denmark, CN=Country Signing CA
Issuer: C=EE, O=Estonia, OU=Citizenship and Migration Board/serialNumber=01-2007, CN=CSCA Estonia
Issuer: C=EE, O=Estonia, OU=Police and Border Guard Board/serialNumber=01-2009, CN=CSCA Estonia
Issuer: C=ES, O=DIRECCION GENERAL DE LA POLICIA, OU=PASAPORTE, CN=AC RAIZ PASAPORTE
Issuer: C=FI, O=Suomi Finland, OU=VRK, CN=Finland Country CA
Issuer: C=FI, O=Suomi Finland, OU=VRK, CN=Finland Country CA 2
Issuer: C=FR, O=Gouv, CN=CSCA-FRANCE
Issuer: C=gb, O=UKKPA, CN=Country Signing Authority
Issuer: C=HR, O=MUP RH, CN=CSCA-Croatia
Issuer: C=HU, O=GOV, OU=CRO, CN=CSCA-HUNGARY
Issuer: C=HU, O=GOV, OU=CRO, CN=CSCA-HUNGARY 2
Issuer: C=IE, O=Department of Foreign Affairs, OU=Passport Office, CN=CSCA Ireland
Issuer: C=IS, L=Reykjavik, O=Fjarmalaraduneyti, OU=Kt. 5501692829, OU=Country Signing CA, OU=Vottunarstefna https://www.thjodskra.is/repository/cps, CN=Ferdaskilriki - Island
Issuer: C=IT, O=MINISTERO DELL'INTERNO, OU=PE, CN=CERTIFICATION AUTHORITY
Issuer: C=IT, O=MINISTERO DELL'INTERNO, OU=PE, CN=CERTIFICATION AUTHORITY 01
Issuer: C=JP, O=Japanese Government, OU=The Ministry of Foreign Affairs, CN=e-passportCSCA
Issuer: C=KR, O=Government, OU=MOFAT, CN=CSCA
Issuer: C=LT, O=ADIC under MOI, CN=CSCA/serialNumber=001
Issuer: C=LT, O=ADIC under MoI, CN=CSCA/serialNumber=002
Issuer: C=LU, O=Grand-Duchy of Luxembourg Ministry of Foreign Affairs, CN=Grand-Duchy of Luxembourg Country Signing CA
Issuer: C=LV, O=National Security Authority, CN=CSCA Latvia/serialNumber=001
Issuer: C=LV, O=National Security Authority, CN=CSCA Latvia/serialNumber=002
Issuer: C=LV, O=National Security Authority, CN=CSCA Latvia/serialNumber=003
Issuer: C=MT, O=Government of Malta, CN=Malta Country Signing CA
Issuer: CN=AC Pasaporte, C=VE, L=Caracas, ST=Distrito Capital, O=Sistema Nacional de Certificacion Electronica, OU=SUSCERTE/emailAddress=acpass@suscerte.gob.ve
Issuer: CN=Certificate Authority Offline-1, OU=eDocuments and eID, O=Republic of Kazakhstan, C=KZ
Issuer: CN=CSCA Macedonia, OU=MOI, O=GOV, C=MK
Issuer: CN=CSCA NL, OU=Ministry of the Interior and Kingdom Relations, O=State of the Netherlands, C=NL
Issuer: CN=CSCA, OU=Electronic Passports, O=Ministry of Interior, C=BG
Issuer: CN=CSCAPKI_MC1, OU=Foreign Office of Monaco, O=Principality of Monaco, C=MC
Issuer: CN=CSCAPKI_MC2, OU=Foreign Office of Monaco, O=Principality of Monaco, C=MC
Issuer: CN=CSCA Serbia, OU=Ministry of Interior, O=Republic of Serbia, C=RS
Issuer: CN=CSCA Turkey, O=Turkey Gov, C=TR
Issuer: CN=ECN Documentos de Viagem, OU=ICAO MRTD PKI - CSCA, O=Republica Portuguesa - Portuguese Republic, C=PT
Issuer: CN=Hong Kong China Country Signing Certificate Authority, O=Hong Kong China, OU=Immigration Department, C=CN
Issuer: CN=Norwegian Passport Certificate Authority, OU=National Police Computing and Material Service, O=The Norwegian Police, C=NO
Issuer: C=NO, O=The Ministry of Justice and the Police, OU=PDMT, CN=CSCA_NO
Issuer: CN=Republica Portuguesa - ECN PEP Raiz, OU=ICAO MRTD PKI - Portuguese Republic CSCA, O=Republica Portuguesa - ECN PEP Raiz, C=PT
Issuer: CN=Swedish Country Signing CA, O=Rikspolisstyrelsen, C=SE
Issuer: C=NZ, O=Government of New Zealand, OU=Passports, OU=Identity Services Passport CA
Issuer: C=PL, O=ICAO CSCA, OU=MSWiA, CN=System Wydawania Paszport\xC3\xB3w z Danymi Biometrycznymi
Issuer: C=ro, O=DGP, CN=CSCA Romania
Issuer: C=RU, L=Moscow, O=STC Atlas, OU=SZD, CN=Ilya Leoshkevich/emailAddress=szd@stcnet.ru
Issuer: C=RU, ST=Russian Federation, L=Moscow, O=STC Atlas, OU=SZD, CN=CSCA-Russia/emailAddress=camail@stcnet.ru
Issuer: C=SG, O=Ministry of Home Affairs, OU=Singapore Passport CA
Issuer: C=SG, O=Ministry of Home Affairs, OU=Singapore Passport CA2
Issuer: C=si, O=state-institutions, OU=e-passport, CN=CSCA-Slovenia
Issuer: C=SK, L=Bratislava, O=NSA of the Slovak Republic, OU=Department of CAs Operation, CN=The Slovak CSCA
Issuer: C=TH, OU=Department of Consular Affairs, O=Ministry of Foreign Affairs, CN=Country Signing CA
Issuer: C=TW, O=Taiwan Government, OU=Ministry of Foreign Affairs, OU=Bureau of Consular Affairs, CN=CSCA
Issuer: C=US, O=U.S. Government, OU=Department of State, OU=MRTD, OU=Certification Authorities, OU=U.S. Department of State MRTD CA
Issuer: serialNumber=1, O=Hellenic Republic, CN=CSCA-HELLAS, OU=Hellenic Police, C=GR/emailAddress=csca@passport.gov.gr
Issuer: serialNumber=2, CN=CSCA NL, OU=Ministry of the Interior and Kingdom Relations, O=State of the Netherlands, C=NL
Issuer: serialNumber=2, CN=Norwegian Passport Certificate Authority, OU=National Police Computing and Material Service, O=The Norwegian Police, C=NO
Issuer: serialNumber=3, CN=CSCA NL, OU=Ministry of the Interior and Kingdom Relations, O=State of the Netherlands, C=NL
Issuer: serialNumber=3, O=Hellenic Republic, CN=CSCA-HELLAS, C=GR/emailAddress=csca@passport.gov.gr
This list is supposed to match the one given in the PKD Master List Content document (I counted 48 countries there...)
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
- The Evolution of Cryptographic Protocols in Electronic Passports, a good summary of the three ePassport generations (opt BAC, EAC, PACE)
- On Exploiting ePassport Vulnerabilities (about PKI)
- So what’s the issue with ePassport security?
- Hello, my name is ...
- E-passport security
- Fingerprinting passports via their non-standard error codes
- A Traceability Attack Against e-Passports
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
- Philips/NXP
- from press releases: 43 out of 51 countries including: Germany, US, France, Singapore, New Zealand, Austria
- Oberthur:
- from press releases: US, Philippines, Taiwan, Thailand, Belgium
- from their 2007 results Identity list for electronic IDs (maybe not epassports): US, France, Hungary, Italy, Spain, Poland, Monaco, Sweden, Andorra, Belgium, Lithuania, Congo, South Africa, Turkey, Morocco, India, Singapore, Taiwan, Thailand
- on their site: Bangladesh, Belgium, Bosnia, Costa Rica, Guinea Conakry, Haiti, Jordan, Kuwait, Lesotho, Nepal, Uruguay, Zambia
- Infineon
- Axalto/Gemplus/Gemalto/Setec
- Trüb AG
- from press releases: Czech Republic
- Sagem
- from press releases: Albania
- Giesecke & Devrient
- from press releases: Latvia, Macedonia, Austria
- De La Rue
- Bundesdruckerei
- from press releases: Germany, Luxembourg, Lithuania, Latvia, Venezuela
- home-made
- old list
- Probably more info in the Annual reports E-Passport of Keesing
PKI
- Entrust
- from press releases: U.S., U.K., Slovenia, Singapore, New Zealand, Taiwan, Finland
- Keynectis
- from press releases: france
Misc
- Protective sleeves & wallets shielding RFID stuff like ePassports
- News