BAC vs PACE (ePassport Access)

BAC vs PACE: ePassport Access Control Protocols

BAC (Basic Access Control) and PACE (Password Authenticated Connection Establishment) are the two generations of access control protocols that govern how an inspection system — a border crossing terminal, e-gate, or passport reader — establishes a secure channel with an ePassport chip before reading its biometric data. Both protocols exist to prevent unauthorized skimming of the ePassport contactless chip, but they differ fundamentally in cryptographic strength, eavesdropping resistance, and brute-force vulnerability.

Overview

BACBACApplicationePassport security using MRZ data.Click to view → (Basic Access Control) was the first ICAO-mandated access control mechanism, introduced in ICAO 9303ICAO 9303ComplianceICAO standard for ePassport chip data and security protocols.Click to view → (5th edition) and widely deployed from 2004 onwards. BAC derives a session key from the Machine Readable Zone (MRZ) — the human-readable text at the bottom of the biographical data page. An inspection system optically scans the MRZ, derives two 3DES3DESCryptographyLegacy triple-DES symmetric cipher in payment smart cards.Click to view → keys from the document number, birth date, and expiry date, and uses those keys to authenticate to the chip and establish an encrypted session. Only a system that has optically read the MRZ can derive the correct keys, which prevents passive RF eavesdropping from a distance.

PACEPACEApplicationStrong ePassport authentication protocol.Click to view → (Password Authenticated Connection Establishment) was standardized by BSI (German Federal Office for Information Security) and adopted by ICAO as the mandatory replacement for BAC in new ePassportePassportApplicationPassport with embedded contactless chip.Click to view → issuance from 2015 onwards. PACE is a password-authenticated key agreement protocol in which the password is the MRZ (or a Card Access Number, CAN, for specific use cases). Rather than directly using MRZ-derived material as a symmetric key, PACE runs a Diffie-Hellman key agreement where the password acts as the authentication factor. The resulting session key provides forward secrecy and eliminates several cryptographic weaknesses present in BAC.

Key Differences

• Cryptographic primitive: BAC uses 3DES with MRZ-derived static keys; PACE uses Diffie-Hellman (ECDH or DH) with AESAESCryptographyNIST symmetric block cipher for smart card encryption.Click to view → session keys
• Forward secrecy: BAC provides none — any recorded session can be decrypted if MRZ is later exposed; PACE provides forward secrecy through ephemeral DH keys
• Brute-force resistance: BAC is vulnerable because the MRZ key space is limited (date fields restrict entropy); PACE adds a mapping step that defeats precomputation attacks
• Eavesdropping resistance: BAC is weak — an attacker who eavesdrops on one session plus obtains the MRZ can decrypt it; PACE is cryptographically sound against passive eavesdroppers even with MRZ knowledge
• Chip authentication integration: BAC requires Chip Authentication (CA) as a separate subsequent protocol; PACE integrates more cleanly with CA in the ICAO 9303 protocol stack
• Standardization: BAC is ICAO 9303 legacy; PACE is ICAO 9303 Part 11 mandatory for Doc 9303-compliant new issuance

Technical Comparison

The MRZ Entropy Problem in BAC

BAC's fundamental weakness stems from the entropy of the MRZ fields used as key material. The document number, date of birth, and expiry date together provide a key space far smaller than a true 112-bit 3DES key. Date of birth for a typical adult population concentrates in roughly 30 years (10,950 possible values). Expiry dates span only 10 years (3,650 values). Combined with document number formats that follow predictable national patterns, the effective entropy can be under 50 bits — making exhaustive search feasible with modest compute.

PACE eliminates this problem through a generic mapping or integrated mapping step that transforms the password into a domain-specific generator for the DH group. Even if two passports share identical MRZ entropy, their PACE sessions are computationally independent, and an attacker who records a session cannot recover the session key without running a full PAKE attack.

Use Cases

BAC is encountered in: - Passports issued before 2015 by most countries (hundreds of millions of documents still in circulation) - Inspection systems that must maintain backward compatibility with pre-PACE ePassports - Legacy e-gates where reader firmware has not been updated to PACE - Academic study of ePassport security vulnerabilities (BAC weaknesses are well-documented in literature)

PACE is used in: - All new ePassport issuance from ICAO member states post-2015 - German Personalausweis (national ID card), which implemented PACE before passports - EU Residence Permits and EU Driving Licences (PACE mandatory under EU Regulation 2019/1157) - Modern e-gate infrastructure (automated border control) at airports globally - eIDeIDIdentityNational ID with embedded chip.Click to view → documents where CAN-based supervision is needed (inspection officer enters CAN before reading)

When to Choose Each

Implement PACE support in any new inspection system or ePassport reader. PACE is the current ICAO standard, and new ePassports being issued today are PACE-only or PACE-primary. An inspection system that does not support PACE will fail to read an increasing proportion of documents as BAC-only passports expire and are replaced.

Maintain BAC support as a fallback for legacy document compatibility. The installed base of BAC-only passports will remain large until approximately 2030–2032 (10-year passport validity cycles), so production inspection systems must implement both protocols and negotiate based on the chip's Card Access File (EF.CardAccess).

Use CAN with PACE in supervised inspection scenarios — when an officer must control access to a document's chip before it is machine-read. CAN prevents unattended PACE authentication from a distance, restoring the human-oversight model for sensitive eID applications.

Conclusion

BAC served its purpose in launching the global ePassport ecosystem but carries cryptographic debt that makes it unsuitable for new deployments. PACE represents a properly designed PAKE protocol that maintains the "optical read before electronic read" security model while eliminating 3DES, static key derivation, and the MRZ entropy limitations. For any engineer implementing ePassport inspection software today, PACE is the primary path and BAC is the backward-compatibility fallback — not a design choice between equals.