Belgian ePassport
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
- 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.