When a system claims something is valid — a passport chip, a model's win in a competitive evaluation — how do you actually confirm that, rather than just accept the claim?
Two research threads this year kept circling the same underlying question. Below are notes on both, at the level of architecture and findings rather than implementation. The first is shipped and open source; the second is mid-development.
An electronic passport (eMRTD) under ICAO Doc 9303 isn't verified by one check — it's a stack of them, each answering a different question:
PA is the one that interests me most, because it's the only step that doesn't terminate at the chip. It terminates at a certificate chain: the chip's data was signed by a Document Signer certificate, which was in turn signed by that country's CSCA (Country Signing Certificate Authority). If you don't have a correct, current copy of the world's CSCA certificates, PA can fail in two different and equally bad ways — it can reject a genuine document because you're missing the issuing country's root, or it can silently accept a forged one because nothing in your trust store was positioned to catch it. Either failure mode is invisible from the outside; the verifier just reports "pass" or "fail" with no indication of which kind of wrong it might be.
That's the gap csca-masterlist-tools exists to close on the tooling side. It's an open-source (MIT) parser for the national CSCA Master List format used under ICAO 9303 — built against the German BSI's published Master List, which bundles the CSCA certificates of every participating country into a single signed CMS/PKCS#7 structure. The parser extracts and validates the chain for each entry, exports a clean PEM bundle plus a TSV manifest for downstream tooling, and falls back to OpenSSL for the small number of certificates that fail strict ASN.1 parsers — older CSCAs occasionally have field encodings that technically violate the spec but that real-world verifiers still have to handle, because rejecting them outright means rejecting genuine passports from that country. The current run against the BSI list extracts 581 CSCA certificates across 112 countries.
The other half of this work is diagnosing what happens when this stack fails in practice, not just in theory. Working across both a commercial mobile SDK and open-source validators, I've been cataloguing the concrete failure modes behind the generic AA_Failed / CA_Failed error codes these tools surface — because "authentication failed" is not actionable on its own, and the same error code covers everything from "this document is genuinely forged" to "your trust store is out of date" to "the chip's antenna had a bad read." Distinguishing those cases is what a real verifier — as opposed to a demo — has to get right.
That research is also what sits behind ICAO ePassport Inspector, an iOS app I built and shipped (support & privacy site) that runs the full check — MRZ OCR, a BAC/PACE secure channel over CoreNFC, and Passive Authentication against ICAO PKD Master List trust anchors — entirely on-device, with no server calls. The verification logic that reads and writes to the chip itself is not open source; the trust-anchor tooling that makes the verification meaningful is.
IAEL (profile — implementation not yet public) is a red/blue-team research harness for AI models, currently in Phase 2. The starting complaint it's trying to answer: in most adversarial-AI writeups, "our model won" is a claim the same team that built the model is also the one reporting. That's not a technical flaw, exactly, but it means the result can't really be audited by anyone outside the project.
The architecture: two attacker models compete head-to-head against a shared vulnerable target environment. The winner of that match has its weights frozen and becomes the new baseline — the "champion." A separate defender model then has to survive repeated attacks from that frozen champion specifically, and it only improves by actually being hit and adapting, not by self-assessment. Champions accumulate this way, each one having actually beaten the previous lineage rather than being declared the winner by whoever ran the experiment.
The part I care most about architecturally is that the win/loss determination isn't made by either competing model, and isn't self-reported by the research pipeline either — it's made by a separate evaluation harness, and every run is anchored with cryptographic evidence: event root hashes, environment state diffs, and locally signed, frozen manifests for the winning run. The intent is that the champion lineage is something a third party could, in principle, audit and confirm, rather than something they have to take on trust from a README.
IAEL is still mid-development and running locally against open-weight models; I'm not open-sourcing the implementation yet, but I'm glad to go deeper on the architecture and the evaluation-harness design with anyone working on adversarial ML evaluation or automated red-teaming.
Both projects are really about the same discipline: don't assume a trust chain holds — build the thing that lets you actually check. For passports, that means having the real CSCA data and knowing precisely how verification fails, not just that it did. For adversarial AI evaluation, that means making the "winner" a claim a third party could re-derive, not a claim the winning team gets to make about itself.
If you're working in document security, applied PKI, or AI safety evaluation and want to compare notes, my inbox is open.
— Eginn