Engineering ePassport Issuance and Identity Platforms.
An ePassport is a small system on a contactless chip and a much larger system in the issuing authority’s data centre. Both halves matter; this is the data-centre half.
The shape of an ePassport programme
An ePassport is a small system on a contactless chip and a much larger system in the issuing authority's data centre. The chip carries the Logical Data Structure (LDS) per ICAO 9303: the data page, the biometric containers, the signed Document Security Object (SOd) that binds them. The data centre carries the country signing infrastructure, the personalisation line, the enrolment workflow, the inspection-system reference, the audit trail. None of these are optional. None of them are trivial.
This post is for the engineer scoping an ePassport platform engagement — what the architecture has to cover, where the standards are load-bearing, and where the seams typically break.
The standards layer, briefly
The relevant standards are clustered tightly:
- ICAO 9303. Twelve parts covering data structures, chip authentication, terminal authentication, document signers, PKD, biometrics interchange, security mechanisms.
- ISO/IEC 14443. Contactless transport. The card's electrical and protocol surface.
- ISO/IEC 19794 / 39794. Biometric data interchange formats. What the LDS expects in the biometric containers.
- BSI TR-03110. EAC and chip-authentication mechanisms; mandatory in Schengen, optional elsewhere.
- Common Criteria PP-eMRTD. The protection profile the chip is evaluated against.
An ePassport implementation that is wrong at the standards layer is wrong everywhere. The chip will pass casual interop testing but fail at a border. Time spent on standards conformance is the cheapest time in the programme.
The PKI hierarchy
Three CA classes carry the trust:
- CSCA (Country Signing Certificate Authority). The root. One per country. Sub-decade key lifetimes. The most carefully ceremonied key in the programme.
- DSC (Document Signer Certificate). Issued by the CSCA. Sign the SOd of each personalised passport. Typical lifetimes are months, not years — intentionally short so the blast radius of a compromised DSC is bounded.
- CVCA / DV / IS (in EAC-enabled deployments). Country Verifying CA, Document Verifier, Inspection System certificates. Govern who can read sensitive biometrics.
Every CSCA publishes its DSCs through ICAO PKD; participating verifiers download them and walk the chain at the border. If the CSCA publishes incorrectly, the country's passports stop being verifiable abroad. PKD operations are not glamorous but they are a required line item.
The personalisation backbone
Personalisation is where the user-facing identity (data page, photo, biometric template) becomes a cryptographic artefact (the SOd-signed LDS on the chip). The flow:
- Enrolment captures the biographic and biometric data.
- Personalisation backend builds the LDS data groups: DG1 (MRZ), DG2 (face), DG3 (fingerprints, EAC-gated), and so on.
- Backend hashes each DG and assembles the SOd.
- SOd is signed by an active DSC. The DSC's certificate is appended.
- Personalisation line writes the LDS and the SOd to the chip over the contactless interface, applies the BAC/PACE access conditions, and locks the chip.
- The physical document is printed, the chip embedded, and the passport handed to the user.
Every step has a security implication. The hash in the SOd binds the biometric template to the signed envelope; tampering with DG2 invalidates the SOd. The DSC's signature binds the SOd to the issuing authority. The chip's access controls govern who can read DG3 at the border.
The enrolment frontend
Enrolment is where biometric quality, exception handling, and operator workflow get expressed. A well-designed frontend covers:
- Live capture of facial image (ICAO-compliant lighting, pose, expression).
- Live capture of fingerprints (where the policy collects them).
- Quality assessment with immediate operator feedback (re-capture before the user leaves the desk).
- Supervisor escalation for exceptions (amputated digits, congenital absence of a fingerprint, facial features that fail quality thresholds).
- Identity proofing workflow tied into the issuing authority's primary identity database (the source-of-truth lookup that prevents one person from enrolling under two names).
- Audit trail of every operator action, signed by the operator's credential.
An enrolment frontend designed without the desk operator's ergonomic in mind produces bad biometrics; bad biometrics produce false matches and false non-matches at the border. The frontend is, in practical terms, a quality-control surface, not a data-capture surface.
Inspection-system support
A passport that is not verifiable at the inspecting state's border is a passport that isn't a passport. Building a reference inspection system — the verifier that simulates what a border-control checkpoint will do — is part of the platform engineering scope. The reference inspection:
- Reads the chip over ISO/IEC 14443.
- Performs BAC/PACE access.
- Performs Active Authentication (or Chip Authentication, EAC profile) to prove the chip is genuine.
- Verifies the SOd signature against the embedded DSC.
- Walks the DSC chain to the CSCA via PKD or local trust store.
- Compares the data-page MRZ to DG1.
- (EAC) Performs Terminal Authentication and reads DG3.
Each step is a defined ICAO 9303 protocol. The reference inspection is also the right tool for issuance QA: every passport off the line gets a smoke-test verify before it leaves.
The seams that typically break
Three places where ePassport programmes typically trip:
- DSC rollover. New DSC issued, old DSC retired. The old DSC's certificate must remain in PKD for the validity of the longest-lived passport signed by it (typically 10 years). PKD operators that prune old DSCs prematurely produce passports that stop being verifiable abroad halfway through their lifetime.
- Biometric quality drift. The enrolment line accepts marginal biometrics for weeks before someone notices the rate of border match failures has gone up. Quality-control telemetry from the inspection-system reference back into the enrolment frontend closes this loop.
- EAC trust list. Inspection systems must be authorised by the issuing CVCA to read DG3. The trust list management at the CVCA is non-trivial — agreements between issuing and inspecting states, time-limited DV certificates, IS certificates per checkpoint. The cryptography is the easy part; the governance is the hard part.
The architecture of an engagement
An ePassport platform engagement is multi-phase by nature. A typical sequence:
- Architecture review: standards mapping, threat model, capability matrix.
- PKI build: CSCA / DSC ceremonies, signing-cycle automation, PKD integration.
- Backend build: LDS generation, SOd signing, audit log, operator API.
- Frontend build: enrolment + personalisation UX, operator training material.
- Inspection system: reference verifier, QA harness, drift detection.
- Handover: code, runbooks, ceremony scripts, audit-log specification.
From cutover onward, the operating authority runs the platform. The engineering partner stays available for incident response and version upgrades.
What the platform does not do
To be explicit: a platform engineering engagement does not include the political or regulatory work of becoming an ICAO-recognised issuing authority. That recognition is the operating authority's programme. The platform delivers the technical capability that supports the programme. The authority delivers the certification, the operating policy, the audit posture, the deployment, and the day-to-day issuance.
The same engagement does not include physical security of the personalisation site, the operator vetting workflow, or the document blank supply chain. Those are issuing-authority concerns. The platform integrates with all of them but does not replace any.
The bottom line
An ePassport programme is a system in two halves: a small chip running ICAO 9303 and a large data centre running the CSCA, DSCs, personalisation backend, enrolment frontend, PKD integration, and inspection-system reference. AmbiSecure's platform engineering service delivers the data-centre half, designed against the standards layer, integrated with the chip layer, and handed over to an operating authority that runs it under its own governance. The cryptography is well-defined; the engineering is the work.