eMRTD data quirks
This is a list of quirks I spotted on eMRTDs that I'm posting to try and help out anyone else who is trying to parse them. It's a list I will continue updating, probably.
As I've spotted these while implementing hf emrtd
set of commands on Proxmark3, they're all fixed there.
Last updated: 2025-01-30
Authentication protocol
- Really old Belgian passports don't enforce any authentication.
- German Personalausweises, even those issued before 2018, enforce PACE. Those issued before August 2021 do not contain the chip inside logo.
- German Aufenhaltstitels, even those issued before 2018, enforce PACE. They do have the chip inside icon, and had them while enforcing PACE all the way back to 2015.
MRZ and EF_DG1 (TD3 – Passport Size)
- For the optional field, some countries use a number even if it is empty (all
<
), and some use<
. (CH etc) - Germany uses
D
for country code (D<<
on MRZ) instead ofDEU
. This is the only instance where a country code deviates from ISO 3166-1 alpha-3. (This is also documented on ICAO 9303 p3 Edition 7 and German Passport Act Law.)
Note: ICAO 9303 p3 Edition 8 does not properly reflect this, and this is likely a drafting error. I have contacted ICAO about this.
MRZ and EF_DG1 (TD1 – ID Size)
- Old (2017) Turkish IDs use German-style ascii-ification while new ones (2018 and after) don't. (2017:
OEZDIL
, 2018 and after:OZDIL
) - Turkish IDs have one preceding
<
before the ID number on optional field (<1234568902<<<
). - Germany uses
D
for country code (D<<
on MRZ) instead ofDEU
. This is the only instance where a country code deviates from ISO 3166-1 alpha-3. (This is also documented on ICAO 9303 p3 and German Passport Act Law.)
Document type codes
First two characters of MRZ are for document type. No one can decide what exactly they want to use, especially for residence permits. Here's what I found for residence permits based on going through PRADO for EU+EEA+Schengen members. I will go through IDs and Passports at some point, but I don't expect them to differ much (except Italy, because why not).
P
= Passport,I
= ID,IP
= Passport CardC<
= ID (Italy)ID
= ID, but sometimes Residence Permit (Belgium, Denmark, Poland 2014)AD
= Residence Permit (Croatia)AR
= Residence Permit (Germany, Austria, Lithuania 2022, Slovenia, Switzerland)CR
= Residence Permit (Italy, Sweden EU-related)IB
= Residence Permit, Document Certifying Permanent Residence (Poland 2021)IW
= Residence Permit, Certificate Of Registration Of Stay (Poland 2021)IK
= Residence Permit, Permanent Residence Card (Poland 2021)IE
= Residence Permit (Poland 2014, Norway Family Members)IO
= Residence Permit (Poland 2014)IF
= Residence Permit, Residence Card (Poland 2014+2021)IZ
= Residence Permit (Poland 2014)IR
= Residence Permit (France, Belgium, Cyprus, Czechia, Spain, Finland, Greece, Hungary, Ireland, Lithuania 2012, Luxembourg, Latvia, Malta, Poland 2011+2020, Portugal, Romania, Slovakia, Sweden, Norway, Estonia 2020)IT
= Residence Permit (Lithuania 2020, Poland 2014)RP
= Residence Permit (Estonia 2011)RT
= Residence Permit (Iceland)
EF_DG11
- Belgian (and french?) passports have some tags with len=0, specifically on localized names (
5F 0E
h) and alternative names (5F 0F
h underA0
h). - Hungarian passports have non-localized names (
5F 0F
h) on EF_DG11. - Turkish IDs and Passports (pre and post NVI) have full dates of birth (
5F 2B
h) as ASCII. - Belgian and French passports have full dates of birth (
5F 2B
h) as bytes.
EF_DG12
- Turkish IDs and Passports (pre and post NVI) have issuance dates (
5F 26
h) as ASCII (Example:20201231
or50 48 50 48 49 50 51 49
h). - Belgian and French passports have issuance dates (
5F 26
h) as bytes (Example:20 20 12 31
h).
EF_SOD
- Turkish IDs and Passports don't include
05 00
h at the end of hash algorithm (on descriptors such as06 09 60 86 48 01 65 03 04 02 01 05 00
h for SHA256), while some do. - USA Passports use
80
h for field length of the main EF_SOD sequence, declaring the size as having an indefinite length as per BER. - Different countries have different times between the document issuance date and certificate start date, between the document expiry date and the certificate end date. Netherlands seems to be 3 and 6 days respectively for Netherlands, and 45 and 45 days respectively for Turkey.
EF_CardAccess
BSI TR-03110-3 says on section A.1.1.7.: “The string urlCardInfo SHALL define the location that provides the most recent CardInfo file [5] for the respective ICC type and version”.
This in turn relates to BSI TR-03112-4 (section 4) and CEN/TS 15480-4. It's to improve interoperability among EU IDs.
On German eIDs and electronic residence permits (probably German Unionsbürger eIDs too), this is set to http://bsi.bund.de/cif/npa.xml, which is 404 at the time of writing (2025), I have contacted BSI about this.