Difference between revisions of "Belgian ePassport"

From YobiWiki
Jump to navigation Jump to search
m (Reverted edits by GrillSkate (talk) to last revision by PhilippeTeuwen)
 
(42 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
Back to [[Belgian eGov]]
 
Back to [[Belgian eGov]]
  +
<br>See also the general [[ePassport]] page
==RFID-enabled Passports==
 
 
==Characteristics==
* [http://www.icao.int/mrtd/download/technical.cfm ICAO MRTD]
 
===Readers===
 
* http://wiring.org.co/learning/examples/rfid_reading.html ?
 
===Hacks===
 
* http://www.acbm.com/inedits/rfid.html
 
* http://www.schneier.com/blog/archives/2006/06/build_your_own.html
 
===Tools===
 
====[http://openmrtd.org/ OpenMRTD]====
 
library
 
====[http://jmrtd.org/ JMRTD]====
 
Java host API & Javacard applet to build your own epassport infrastructure
 
====[http://www.rfidiot.org/ RFIDIOt]====
 
apt-get install python-pyscard
 
$ ./mrpkey.py -L
 
PCSC devices:
 
No: 0 OMNIKEY CardMan 5x21 00 00
 
No: 1 OMNIKEY CardMan 5x21 00 01
 
$ ./mrpkey.py -r 1 CHECK
 
mrpkey v0.1n (using RFIDIOt v0.1s)
 
Reader: PCSC OMNIKEY CardMan 5x21 00 01
 
Device is a Machine Readable Document
 
$ ./mrpkey.py -r 1 "EXnnnnnn<cBELyymmddcSyymmddc<<<<<<<<<<<<<<cc"
 
To fix reader number, edit RFIDIOtconfig.py
 
<br>In MRZ passport number is coded with 9 chars. Belgian uses only 8 chars so some passport readers need a document number padded with char "<" ("EXnnnnnn<")
 
 
To use mrpkey under Windows you need:
 
* [http://www.python.org/download/ python]
 
* [http://sourceforge.net/projects/pyscard/ pyscard]
 
* [http://sourceforge.net/projects/pyserial/ pyserial]
 
* [http://sourceforge.net/project/showfiles.php?group_id=78018 pywin32]
 
* [http://www.voidspace.org.uk/python/modules.shtml#pycrypto pycrypto]
 
* [http://www.pythonware.com/products/pil/ python imaging library]
 
====[http://www.dexlab.nl/ eCL0WN]====
 
Applet for Nokia NFC phone
 
 
==Belgian ePassports==
 
===Characteristics===
 
 
* [https://www.checkdoc.be/CheckDoc/index.jsp?currenPage=checkdocument.jsp&choice=checkSecurity&iconDB=02&specific_document=1115&checksecurity_level=2&id_menu=0012 Current versions demo]
 
* [https://www.checkdoc.be/CheckDoc/index.jsp?currenPage=checkdocument.jsp&choice=checkSecurity&iconDB=02&specific_document=1115&checksecurity_level=2&id_menu=0012 Current versions demo]
 
* Uses Opentrust PKI (former IDX-PKI from idealx)
 
* Uses Opentrust PKI (former IDX-PKI from idealx)
  +
* Price:
===Security of Belgian ePassports===
 
  +
** 30€ droit de chancellerie
  +
** taxes communales (Ixelles=26€, Leuven=11€?,...)
  +
** 41€ frais de confection
  +
** Much more expensive if urgent or 64 pages (~250€)
  +
* maker? at least [http://www.lecho.be/actualite/entreprises_technologie/Le_Belge_Zetes_met_plus_que_jamais_le_cap_sur_l'Afrique.6813096-587.art?searchselect=srch_bonds not Zetes] (contradictory info [http://www.vnunet.fr/fr/vnunet/news/2007/06/13/carte-d-identit-lectronique here])<br>''Mais nous ne fabriquons pas le passeport belge, c’est vrai. C’est un contrat qui a été attribué avant que nous ne soyons actifs sur ce segment. S’il y a un appel d’offres, j’imagine que nous y répondrons.''
 
===chip===
  +
* [http://www.intellectuk.org/component/docman/doc_download/414-oberthur-card-systems-to-provide-e-passport-to-the-kingdom-of-belgium Oberthur press release in 2005 (pdf)]
  +
* ATR 3B 8E 80 01 80 91 E1 31 C0 64 77 E3 03 00 83 82 90 00 6C
  +
* ATR 3B 8E 80 01 80 91 91 31 C0 64 77 E3 03 00 83 82 90 00 1C (as mentioned in pcsc-lite smartcard_list.txt)
  +
* ATR 3B 88 80 01 00 00 01 07 01 72 90 00 EC (on a recent passport 01/2009 EH431xxx)
  +
* Belgium is one rare country to also include the owner handwritten signature, in EF_DG7
  +
* Non-compliances?
  +
** Requires option 0x0C whenever you select the application or a file (important for non-BAC passports), usually other passports implement 7816-4 a bit better and accept the standard select_file but apparently Belgium just implemented the example of LDS just as it was presented, no more)
  +
** non-BAC passports have a bug in EF_DG11, in full name of holder (tag 5F0E): null length followed by "A0 06 02 01 01"
  +
** newer passports have a bug in EF_DG12, using tag 5F85 instead of 5F55 for the document issuance timestamp (5F85 is in LDS1.7, 5F55 is in ISO standard)
  +
** newest passports (with polycarbonate transparent sheet) don't have the bug anymore in EF_DG12, skipping simply document issuance timestamp
  +
* Reading the DS certificate in EF_SOD (output truncated):
  +
openssl pkcs7 -text -print_certs -in EF_SOD.PEM
  +
Authority:
  +
Issuer: C=BE, O=Kingdom of Belgium, OU=Federal Public Service Foreign Affairs Belgium, CN=CSCAPKI_BE
  +
Subject: C=BE, O=Kingdom of Belgium, OU=Federal Public Service Foreign Affairs Belgium, CN=DSPKI_BE
  +
X509v3 extensions:
  +
X509v3 Authority Key Identifier:.
  +
keyid:00:84:19:14:B2:CE:7E:0A:DE:3A:26:F9:FD:DD:1F:F4:01:42:A8:0E
  +
  +
==Active Authentication==
  +
See first [[EPassport#Active_Authentication]]
  +
  +
It appears that:
  +
* first generation passports support AA without BAC (as there is no BAC)
  +
* second generation passports don't support AA without BAC
  +
* third generation passports support AA without BAC, which is more surprising!
  +
This doesn't really conflict with the ICAO standard, according to the specs:
  +
<br><i>Doc 9030 IV-13: "An MRTD chip that supports Basic Access Control SHALL respond to unauthenticated *read attempts* (including selection of(protected) files in the LDS) with "Security status not satisfied" (0x6982)"</i>
  +
<br>So nothing said about AA & ISO7816-4 INTERNAL AUTHENTICATION command.
  +
<br>But '''if''' BAC is '''applied''' then all consecutive commands must be encrypted:
  +
<br>Supplement to Doc9303 rev7: R1-p1_v2_sIV_0027
  +
<i>The Active Authentication uses the Internal Authentication command, Does this command should be send to the ICC with Secure Messaging? If Basic Access Control is applied, yes.</i>
  +
<br>See also that one telling that allowing unsecure e.g. SELECT before applying BAC is ok but implementation dependent:
  +
<br>R4-p1_v2_sIV_0046
  +
<i>Verify if it is possible to successfully perform unsecured SELECT on BAC protected e-Passports
  +
[...] It is however recognized that certain ICC operating systems support an unsecured SELECT before the BAC secure messaging is established. Therefore, when no secure channel is established, both 6982 and 9000 should be expected as ICAO compliant responses to an unsecured SELECT.[...]</i>
  +
  +
We cannot use this to fingerprint passports as the challenge reply is also based on a nounce generated by the passport itself.
  +
  +
But we still have one interesting property:
  +
<br>Normally with BAC, to identify a passport with BAC support we've no other choice than knowing the passport MRZ (thus we already identified it), brute-forcing the MRZ, which can take quite a while, or using a dictionary of known MRZ (imagine a rogue country collecting them at border)
  +
<br>Here we can send an AA challenge of our choice (can be kind of timestamp) and get the reply.
  +
<br>As such we cannot do anything interesting yet but later, offline, we can prove we saw that passport at that place at that time if we have access to the EF_DG15 at any time before or after this event.
  +
<br>It's just a matter of verifying the signatures of a collection of timestamped AA replies against a collection of passport public keys and achieve some linkability.
  +
 
==Security of Belgian ePassports==
 
* http://www.theregister.co.uk/2007/06/10/belgian_epassport_flaws/
 
* http://www.theregister.co.uk/2007/06/10/belgian_epassport_flaws/
 
* http://www.dice.ucl.ac.be/crypto/passport/index.html
 
* http://www.dice.ucl.ac.be/crypto/passport/index.html
  +
==Next steps==
  +
* http://www.rtbf.be/info/economie/les-nouveaux-passeports-biometriques-couteront-16-millions-deuros-140526

Latest revision as of 19:16, 16 April 2013

Back to Belgian eGov
See also the general ePassport page

Characteristics

  • Current versions demo
  • Uses Opentrust PKI (former IDX-PKI from idealx)
  • Price:
    • 30€ droit de chancellerie
    • taxes communales (Ixelles=26€, Leuven=11€?,...)
    • 41€ frais de confection
    • Much more expensive if urgent or 64 pages (~250€)
  • maker? at least not Zetes (contradictory info here)
    Mais nous ne fabriquons pas le passeport belge, c’est vrai. C’est un contrat qui a été attribué avant que nous ne soyons actifs sur ce segment. S’il y a un appel d’offres, j’imagine que nous y répondrons.

chip

  • Oberthur press release in 2005 (pdf)
  • ATR 3B 8E 80 01 80 91 E1 31 C0 64 77 E3 03 00 83 82 90 00 6C
  • ATR 3B 8E 80 01 80 91 91 31 C0 64 77 E3 03 00 83 82 90 00 1C (as mentioned in pcsc-lite smartcard_list.txt)
  • ATR 3B 88 80 01 00 00 01 07 01 72 90 00 EC (on a recent passport 01/2009 EH431xxx)
  • Belgium is one rare country to also include the owner handwritten signature, in EF_DG7
  • Non-compliances?
    • Requires option 0x0C whenever you select the application or a file (important for non-BAC passports), usually other passports implement 7816-4 a bit better and accept the standard select_file but apparently Belgium just implemented the example of LDS just as it was presented, no more)
    • non-BAC passports have a bug in EF_DG11, in full name of holder (tag 5F0E): null length followed by "A0 06 02 01 01"
    • newer passports have a bug in EF_DG12, using tag 5F85 instead of 5F55 for the document issuance timestamp (5F85 is in LDS1.7, 5F55 is in ISO standard)
    • newest passports (with polycarbonate transparent sheet) don't have the bug anymore in EF_DG12, skipping simply document issuance timestamp
  • Reading the DS certificate in EF_SOD (output truncated):
openssl pkcs7 -text -print_certs -in EF_SOD.PEM
Authority:
       Issuer: C=BE, O=Kingdom of Belgium, OU=Federal Public Service Foreign Affairs Belgium, CN=CSCAPKI_BE
       Subject: C=BE, O=Kingdom of Belgium, OU=Federal Public Service Foreign Affairs Belgium, CN=DSPKI_BE
       X509v3 extensions:
           X509v3 Authority Key Identifier:.
               keyid:00:84:19:14:B2:CE:7E:0A:DE:3A:26:F9:FD:DD:1F:F4:01:42:A8:0E

Active Authentication

See first EPassport#Active_Authentication

It appears that:

  • first generation passports support AA without BAC (as there is no BAC)
  • second generation passports don't support AA without BAC
  • third generation passports support AA without BAC, which is more surprising!

This doesn't really conflict with the ICAO standard, according to the specs:
Doc 9030 IV-13: "An MRTD chip that supports Basic Access Control SHALL respond to unauthenticated *read attempts* (including selection of(protected) files in the LDS) with "Security status not satisfied" (0x6982)"
So nothing said about AA & ISO7816-4 INTERNAL AUTHENTICATION command.
But if BAC is applied then all consecutive commands must be encrypted:
Supplement to Doc9303 rev7: R1-p1_v2_sIV_0027 The Active Authentication uses the Internal Authentication command, Does this command should be send to the ICC with Secure Messaging? If Basic Access Control is applied, yes.
See also that one telling that allowing unsecure e.g. SELECT before applying BAC is ok but implementation dependent:
R4-p1_v2_sIV_0046 Verify if it is possible to successfully perform unsecured SELECT on BAC protected e-Passports [...] It is however recognized that certain ICC operating systems support an unsecured SELECT before the BAC secure messaging is established. Therefore, when no secure channel is established, both 6982 and 9000 should be expected as ICAO compliant responses to an unsecured SELECT.[...]

We cannot use this to fingerprint passports as the challenge reply is also based on a nounce generated by the passport itself.

But we still have one interesting property:
Normally with BAC, to identify a passport with BAC support we've no other choice than knowing the passport MRZ (thus we already identified it), brute-forcing the MRZ, which can take quite a while, or using a dictionary of known MRZ (imagine a rogue country collecting them at border)
Here we can send an AA challenge of our choice (can be kind of timestamp) and get the reply.
As such we cannot do anything interesting yet but later, offline, we can prove we saw that passport at that place at that time if we have access to the EF_DG15 at any time before or after this event.
It's just a matter of verifying the signatures of a collection of timestamped AA replies against a collection of passport public keys and achieve some linkability.

Security of Belgian ePassports

Next steps