CodeB Wallet · NFC · ICAO Doc 9303

Passport and ID card chips, checked by the server

CodeB Wallet reads the chip of a passport or ID card over NFC. The CodeB server runs every chip check itself; the phone only passes the chip’s encrypted messages through. So the result does not depend on trusting the phone: a modified app can interrupt a reading, but it cannot change the result.

NFC · ICAO Doc 9303 · PACE · Chip Authentication · Active Authentication · Passive Authentication · CSCA master list · CRLs

Works with the CodeB Wallet closed beta. Not certified.

In short

What
Reading and checking the chip of a passport or national ID card with the CodeB Wallet Android app, with all checks on the CodeB server.
Documents
Passports and ID cards with a chip under ICAO Doc 9303 (eMRTD), opened with the card access number (CAN) or the data from the machine-readable zone (MRZ).
Checks
Secure access (PACE, or BAC for older passports), Chip Authentication or Active Authentication, Passive Authentication against the issuing country’s signing certificates and revocation lists.
Result
Genuine, not verified or not genuine, with the reasons.
Evidence
One hash-chained record per reading, without names, birth dates, CAN or MRZ.
Design target
ETSI TS 119 461 v2.1.1 (extended level of identity proofing) and ARF 3.0. Not certified.

How a reading works

The server is the terminal. The phone is only the NFC antenna.

Open the link

A reading starts from a one-time link or QR code that opens CodeB Wallet. The link is valid for 10 minutes and works once.

Enter the access data

The six-digit CAN of an ID card, or the document number, date of birth and expiry date of a passport. They only open the chip.

Hold the document to the phone

The phone forwards the server’s chip commands and the chip’s answers. After the secure channel is set up, all of them are encrypted between chip and server.

The server checks

Secure access, chip authenticity, the signature over the data and the revocation status, all against the server’s own trust lists.

Result

The phone receives only the verdict and the reasons, never the personal data.

What the checks catch

Changed data

Passive Authentication: every data group must match the hash signed by the issuing country’s document signer, which must chain to a trusted country signing certificate (CSCA) of the same country and must not be revoked.

Cloned chips

Chip Authentication (or Active Authentication) proves that the chip holds its private key. A copy of the data on another chip fails.

A manipulated phone

The phone never sees the data in plain text during a server reading and cannot forge the chip’s answers: they are protected by keys only the chip and the server have.

Forged apps

Each reading is bound to a key in the phone’s secure hardware. The server checks the Android hardware key attestation (genuine app, locked and verified device) and the signature on every request.

Withheld data and downgrades

A chip that lists data in its security object but does not hand it over is rejected, and so is a passport read with the older BAC protocol although it announces the newer PACE.

Guessing and replay

Three wrong access codes end a reading session, sessions work once, and every challenge is fresh.

Privacy by design

  • The CAN and the MRZ data are used only to open the chip and are never stored or logged.
  • The raw chip files are dropped right after the checks; the data read stays in the server’s memory only for the reading session.
  • The phone gets the verdict, not the personal data.
  • Only the data groups the check needs are read; fingerprints and iris images are never requested.

Evidence without personal data

  • One record per reading: methods, algorithms, results, certificate and data hashes, timings.
  • Records are hash-chained, so a changed or removed record is detected.
  • The document number appears only as a keyed hash.

Public CSCA trust lists

The same trust material the server checks against is published unchanged for wallets and relying parties that run their own Passive Authentication. No sign-in, no redirect, with ETag caching.

Master list
https://phone.codeb.io/wallet/trust/csca-masterlist.ml — the German CSCA master list, byte for byte (CMS SignedData), refreshed weekly and replaced only after its signature, signer and issuing CSCA are checked.
Revocation lists
https://phone.codeb.io/wallet/trust/csca-crls.zip — the CRLs of the CSCAs in that list, refreshed daily; each is kept only if its CSCA signature verifies, and never replaced by an older one.
Status
https://phone.codeb.io/wallet-trust.ashx?status — dates, hashes and the countries with a stored CRL, as JSON.

Standards

  • ICAO Doc 9303 parts 10, 11 and 12 (eMRTD data, security mechanisms, PKI)
  • PACE with generic mapping and PACE-CAM, BAC, Secure Messaging (AES and 3DES)
  • ISO/IEC 7816-4 commands, ISO/IEC 14443 (NFC)
  • CMS (RFC 5652) and X.509 certificates and CRLs (RFC 5280)
  • ETSI TS 119 461 v2.1.1, extended level of identity proofing (design target, not certified)
  • EU Architecture and Reference Framework (ARF) 3.0
  • eIDAS 2.0, Regulation (EU) 2024/1183
  • Android hardware key attestation

Frequently asked questions

What does the passport and ID card chip check do?

CodeB Wallet reads the chip of a passport or national ID card over NFC. The CodeB server runs the ICAO Doc 9303 checks itself: secure access with the CAN or the MRZ data, Chip Authentication or Active Authentication against cloned chips, and Passive Authentication of the data against the issuing country's signing certificates. The result is genuine, not verified or not genuine.

Why does the server check the chip and not the phone?

The phone only passes the chip's messages through. After the secure channel to the chip is set up, these messages are encrypted and authenticated between the chip and the server, so a modified app can interrupt a reading but cannot change its result or invent data.

Which documents work?

Passports and ID cards with a chip that follow ICAO Doc 9303 (eMRTD), for example the German ID card with its six-digit CAN or a passport with the data from its machine-readable zone. The issuing country's signing certificate must be in the CSCA master list the server uses.

What do I need to enter?

For ID cards the six-digit card access number (CAN) printed on the card; for passports the document number, date of birth and date of expiry from the machine-readable zone. The server uses them only to open the chip and never stores them.

What do the results mean?

Genuine: the data is signed by a trusted issuing country, unchanged, not revoked, and the chip proved it is the original. Not verified: the data was read, but the issuer could not be fully confirmed, for example because no current revocation list of that country is available. Not genuine: a signature or chip check failed, or the chip held back data it lists.

Which personal data is kept?

The checks need the data only briefly. The evidence record of each reading contains hashes, algorithms, results and timings, but no name, date of birth, CAN or machine-readable zone; the document number is kept only as a keyed hash.

Can others use the CSCA trust lists?

Yes. The server publishes the CSCA master list and the countries' revocation lists unchanged at /wallet/trust/csca-masterlist.ml and /wallet/trust/csca-crls.zip, refreshed weekly and daily after their signatures are checked.

Is it certified?

No. It is designed to follow ETSI TS 119 461 v2.1.1 (extended level of identity proofing) and the EU Architecture and Reference Framework (ARF) 3.0, but it is not certified, and no level of assurance is claimed.

How can I try it?

CodeB Wallet is in closed beta. To become a tester, write to info@aloaha.com.

Checking identity documents in your onboarding?

Write to us about the chip check, the evidence record or the public trust lists. Testers for CodeB Wallet are welcome too.