EPassport

From YobiWiki
Revision as of 13:03, 20 June 2013 by <bdi>PhilippeTeuwen</bdi> (talk | contribs) (→‎Tools)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

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

To understand the ICAO PKD concept, a must-read is the document A Primer on the Public Key Directory.pdf

Stupid script to see what are the Document Signer (DS) certificates contained in the first LDIF (there are also CRLs):
Put the script and the pkd.nnnnnnn.ldif file in an empty directory and run the script without argument. 

#!/bin/bash

rm xx*
csplit pkd.*.ldif '%userCertif%' '/^userCertif/' '{*}'
for i in xx*; do
    cat $i |sed '1s/^.*:://;/:/,/qwerty/d' |openssl base64 -d > $i.cer
    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

Parsing pkd.000595.ldif (2013-01-22) gave 2797 DS certificates signed by 14 countries: 

$ grep -h Issuer: *txt|sed 's/.*\(C=..\).*/\1/'|tr a-z A-Z |sort|uniq|wc -l
14

$ grep -h Issuer: *txt|sort|uniq
       Issuer: C=AU, O=GOV, OU=DFAT, OU=PTB, CN=Passport Country Signing Authority
       Issuer: C=ca, O=gc, OU=pptc, CN=csca-canada
       Issuer: C=CA, O=gc, OU=pptc, CN=csca-canada
       Issuer: C=CH, O=Admin, OU=Services, OU=Certification Authorities, CN=csca-switzerland-2
       Issuer: C=CN, O=Chinese Government, OU=Ministry of Foreign Affairs, OU=China Passport CA, CN=China Passport Country Signing Certificate
       Issuer: C=CN, O=Hong Kong China, OU=Immigration Department, CN=Hong Kong China Country Signing Certificate Authority
       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=gb, O=UKKPA, CN=Country Signing Authority
       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: CN=China Passport Country Signing Certificate (Macao), O=Macao SAR, OU=Identification Services Bureau, C=CN
       Issuer: C=NG, ST=FCT, L=Abuja, O=MSC Trustgate.com, OU=Federal Government of Nigeria, CN=Nigeria Country Signer 0705/emailAddress=ffatusin@imagetech.com.ng
       Issuer: CN=Hong Kong China Country Signing Certificate Authority, O=Hong Kong China, OU=Immigration Department, C=CN
       Issuer: C=NZ, O=Government of New Zealand, OU=Passports, OU=Identity Services Passport CA
       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=SG, O=Ministry of Home Affairs, OU=Singapore Trial Passport CA
       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: C=ZZ, O=United Nations, OU=Certification Authorities, CN=United Nations CSCA


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 ;-) )
Put the script and the pkdML.nnnnnnn.ldif file in an empty directory and run the script without argument, it will extract and convert all CSCA found. There can be duplicates as several CSCA-ML may contain the same CSCAs. 

#!/bin/bash

rm xx*
echo "Splitting CscaMasterListData elements out of LDIF at offsets:"
csplit pkdML.* '%CscaMasterListData%' '/^CscaMasterListData/' '{*}'
echo "base64-decoding CscaMasterListData elements"
for i in xx*; do
    cat $i |sed '1s/^.*:://;/:/,/qwerty/d' |openssl base64 -d > $i.cer
    test $? -eq 0 && rm $i
done
for FILE in xx*.cer; do
    REF=${FILE%.cer}
    PAYLOAD=$REF.data.cer
    echo "Verifying and extracting payload $PAYLOAD out of CscaMasterListData file $FILE:"
    openssl cms -in $FILE -inform der -noverify -verify -out $PAYLOAD
    echo "Extracting all certificates from payload $PAYLOAD"
    eval $(openssl asn1parse -in $PAYLOAD -inform der -i|\
           awk "/:d=1/{b=0}
                /:d=1.*SET/{b=1}
                /:d=2/&&b{print}"|\
           sed 's/^ *\([0-9]\+\).*hl= *\([0-9]\+\).*l= *\([0-9]\+\).*/\
                  dd if=$PAYLOAD bs=1 skip=\1 count=$((\2+\3)) 2>\/dev\/null > $REF.\1.cer;\
                  openssl x509 -in $REF.\1.cer -inform der -out $REF.\1.pem -outform pem;\
                  openssl x509 -in $REF.\1.pem -inform pem -noout -text > $REF.\1.txt;/')
done
rm xx??.cer xx??.data.cer
echo "Renaming cert files with corresponding country suffix"
for FILE in xx*.pem; do
    REF=${FILE%.pem}
    C=$(openssl x509 -in $FILE -issuer -noout |sed "s#.*/C=\([^/]\+\).*#\1#")
    mv $REF.pem $REF.$C.pem
    mv $REF.txt $REF.$C.txt
    mv $REF.cer $REF.$C.cer
done
echo "Done"

Parsing pkdML.000023.ldif (2012-11-19) gave 3 ML signed by AU, CH & DE and containing all together certificates from 53 countries 

$ grep -h Issuer: *txt|sed 's/.*\(C=..\).*/\1/'|tr a-z A-Z |sort|uniq|wc -l
53

$ grep -h Issuer: *txt|sort|uniq
       Issuer: C=AE, O=MOI, OU=EPASS, CN=UAE CSCA 01
       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=CN, O=Chinese Government, OU=Ministry of Foreign Affairs, OU=China Passport CA, CN=China Passport Country Signing Certificate
       Issuer: C=CN, O=Hong Kong China, OU=Immigration Department, CN=Hong Kong China Country Signing Certificate Authority
       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=ES, O=DIRECCION GENERAL DE LA POLICIA/serialNumber=2, CN=CSCA SPAIN
       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=KS, O=GV, OU=MIA, CN=CSCA-KOSOVO
       Issuer: C=LI, O=LIECHTENSTEIN, OU=Auslaender- und Passamt, CN=CSCA-LIECHTENSTEIN
       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=China Passport Country Signing Certificate (Macao), O=Macao SAR, OU=Identification Services Bureau, C=CN
       Issuer: CN=Country Signing CA Lithuania, C=LTU/serialNumber=001
       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=CSCAPKI_MC3, 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 002, OU=ICAO MRTD PKI - CSCA, O=Republica Portuguesa - Portuguese Republic, C=PT
       Issuer: CN=ECN Documentos de Viagem, OU=ICAO MRTD PKI - CSCA, O=Republica Portuguesa - Portuguese Republic, C=PT
       Issuer: CN=Grand-Duchy of Luxembourg Country Signing CA, O=Grand-Duchy of Luxembourg Ministry of Foreign Affairs, C=LU
       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: C=NO, O=The Ministry of Justice, 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=TG, O=GT, OU=DGDN, OU=CA
       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: OU=SEGSTAT, CN=CERTIFICATION AUTHORITY, O=HSVATICAN, C=VA
       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

Last time I checked, list pkdML.000016.ldif was matching the one given in the PKD Master List Content document but the doc seems not updated since.

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

If you extracted all CSCA certificates in a single directory from the ldif as explained above, you can also use it as a CA directory. Prepare the hash links by running within the directory: 

c_rehash .

Then use openssl as following: 

$ openssl smime -verify -in EF_SOD.PEM -inform pem -CApath /path/to/pkdML.000023.ldif/certs/ > EF_SOD.data
Verification successful

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

openPACE

cryptolib

Specific countries

Manufacturers

Chip/Book

PKI

Misc

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