ICAO 9303 ePassport / EU eID Specification

1. System Overview

• Standards: ICAO Doc 9303, ISO/IEC 14443 Type A/B, ISO/IEC 7816-4
• Encoding: BER-TLV, UTF-8 (Text), JPEG/JP2 (Images)
• Crypto: 3DES / AES (Secure Messaging), SHA-1/256/512 (Hashing), RSA/ECC (Sig/Auth)
• Protocol: ISO-DEP (Type A/B)
• Scope: ePassports (MRTD), EU National ID Cards (eID)

2. Application Identifiers (AID)

Application	AID (Hex)	Description
ePassport	A0 00 00 02 47 10 01	ICAO MRTD Application

3. APDU Command Reference

CLA: 00 (ISO) or 0C (Secure Messaging).

Command	INS	P1	P2	Data	Le	Description
SELECT	A4	04	0C	[AID]	-	Select Application
SELECT	A4	02	0C	[FID]	-	Select File (EF)
READ BIN	B0	OfsH	OfsL	-	Len	Read Binary Data
GET CHALLENGE	84	00	00	-	08	Request Random (BAC)
EXT AUTH	82	00	00	[Data]	-	Mutual Auth (BAC)

4. File Structure (LDS)

Logical Data Structure (LDS). Files are accessed by SELECT (by FID) then READ BINARY. Most DGs require Secure Messaging (BAC or PACE) to access.

FID	Short EF ID	Description
01 1E	EF.COM	Common Data (LDS Version, Unicode Version, Tag List)
01 1D	EF.SOD	Security Object (Signed Hashes of DGs)
01 01	EF.DG1	MRZ (Machine Readable Zone) Data
01 02	EF.DG2	Encoded Face Image
01 03	EF.DG3	Fingerprints (Requires EAC/EACv2)
01 04	EF.DG4	Iris (Requires EAC)
01 0B	EF.DG11	Additional Personal Details (Full Name, Addr, etc.)
01 0C	EF.DG12	Additional Document Details (Date of Issue, etc.)
01 0F	EF.DG15	Active Authentication Public Key Info

5. Security Protocols

5.1 Basic Access Control (BAC)

Used to derive session keys from MRZ (Document No + Birth Date + Expiry Date). Standard for many older passports.

Flow:

1. GET CHALLENGE: Card generates RND.ICC (8 bytes).
2. Key Derivation: Reader derives K_enc, K_mac from MRZ Info.
3. Mutual Auth: Reader sends Cmd_data (encrypted RND.IFD + RND.ICC + K_IFD).
4. Session: If successful, Secure Messaging is established (ISO 7816-4).
   • All subsequent commands (READ BINARY) are encrypted/MACed.

5.2 Password Authenticated Connection Establishment (PACE)

Stronger alternative to BAC, mandated for EU eIDs and newer passports. Uses CAN (Card Access Number) or MRZ as password to establish ECDH channel.

Features:

• Strong Session Keys (ECDH).
• Privacy (Chip ID not revealed until auth success).
• Fallback: Many cards support BAC as fallback if PACE is not available (though EU eIDs strictly prefer PACE).

6. Implementation Considerations

6.1 Protocol Selection & Fallback

To maximize compatibility across different generations of ePassports and eIDs:

• Default Strategy: Attempt PACE first (especially if CAN is provided).
• Fallback: If PACE fails with "Instruction not supported" (6D00) or general errors, and an MRZ is available, automatically fall back to BAC.
• Reasoning: Passports issued before ~2010 often only support BAC. Newer passports support both.

6.2 Reader Compatibility (Extended Length APDUs)

Many consumer-grade NFC readers (e.g., Sony PaSoRi RC-S380) have limited support for Extended Length APDUs (APDUs where Le or Lc > 255 bytes).

• Issue: Using extended Le (00 B0 P1 P2 00 00 00) may return "Wrong length" (6700) or "General Error" (6F00).
• Solution: Use Short Le (00 B0 P1 P2 00 requesting 256 bytes) and read in chunks.
• Chunking Logic:
  • Loop READ BINARY with increasing offsets.
  • Handle 6B00 (Offset out of range) as EOF.
  • Handle 6C00 (Wrong Length) by retrying with the exact length provided in the status word.

6.3 Data Extraction (DG Reading)

Once Secure Messaging (SM) is established:

1. Select the target EF (e.g., 01 01 for DG1).
2. Read the header (first 4-6 bytes) to determine the total TLV length.
3. Read the remainder in chunks (256 bytes or less) to avoid buffer issues on constrained readers.