EIF is a file format for photographs that decisions get made from — insurance claims, lending inspections, evidence. The proof lives inside the container, covers a Merkle tree of image tiles, and identifies which regions changed rather than only that something did.
A 640×480 capture, sealed as 80 tiles of 64 pixels. Verification recomputes every tile against the sealed tree.
The instinctive answer to synthetic imagery is a classifier that spots it. Our first study built four physics-based forensic probes and ran them across a corpus of real and generated images. The best classifier we could produce reached 74% accuracy under leave-one-out cross-validation.
Not a number anyone can deny a claim with — and it degrades every time a generative model improves. Detection is a race against an adversary who is getting better faster than the defence. The negative result is published in full, because it is the argument for everything that follows.
Provenance asks a different question. Instead of is this fake?, which is statistical, it asks can this image prove where it came from? — which has a cryptographic answer.
An .eif file is a chunked binary container. One ECDSA P-256 signature covers the
attestation, the tile tree root and the image data concatenated under a domain tag, so the
three cannot be recombined across files.
When, what device, what software, what location — and the relying party's challenge.
A Merkle tree over image tiles, built per RFC 6962 with the tile index bound into each leaf.
One ES256 signature, stored fixed-width so there is exactly one valid encoding.
Append-only custody entries, each committing to the hash of the one before it.
The pixels, stored byte for byte.
Because the proof is the container rather than metadata beside it, there is no such thing as an EIF file with the provenance stripped. Remove it and what remains is an ordinary image with no claim to make.
A whole-image hash answers one question. A Merkle tree over tiles answers a second: a verifier recomputes each leaf from the image present in the file and compares it position by position against the leaves sealed at capture.
For a claims handler this is the difference between an unactionable verdict and a finding they can write down. Invalid tells them nothing. Tiles 34, 35, 44 and 45 differ — the region around the left headlight tells them where to look.
# edit an 80×60 region of a sealed capture, then verify
$ eif tamper-test claim-0041.eif --x 300 --y 200 --width 80 --height 60
L2 Cryptographic FAIL
- recomputed tile tree does not match the sealed root
Tamper localisation: 4 of 80 tiles altered
tile 34 (col 4, row 3) pixels [256,192]-[320,256]
tile 35 (col 5, row 3) pixels [320,192]-[384,256]
tile 44 (col 4, row 4) pixels [256,256]-[320,320]
tile 45 (col 5, row 4) pixels [320,256]-[384,320]The same structure supports selective disclosure. A single tile can be proved to belong to the sealed image with an inclusion proof of a few dozen hashes, so a reinsurer can confirm the region that matters without receiving the number plate, the faces, or the house front.
Evidence has to be checkable in a courtroom, in an adjuster's car, and in ten years' time, none of which guarantee a working connection to somebody's trust service. Levels are reported independently, because they fail for different reasons and a relying party acts differently on each.
| Level | Question it answers | Network |
|---|---|---|
| L1 Format | Is this a well-formed EIF file? | offline |
| L2 Cryptographic | Does the seal verify? If not, which tiles changed? | offline |
| L3 Temporal | Are the timestamps coherent and plausible? | offline |
| L4 Provenance | Is the chain of custody unbroken? | offline |
| L5 Device | Is the signing key resident in real hardware? | online |
A level that could not run reports not evaluated rather than passing quietly. A file with no hardware attestation is not invalid — it is lower assurance, and what that is worth is the relying party's decision, not the format's.
Generate a synthetic image, display it, photograph the screen with a genuine device. The capture is real. The attestation is honest. The content is fabricated. No provenance system that only records how a file was made can catch this, because nothing about the provenance is false.
EIF's answer is a challenge: the relying party issues a single-use nonce for a session, the capture pipeline binds it into the signed attestation, and the nonce is redeemed once on submission. The question shifts from was this a real capture? to was this a real capture inside a session I opened?
The attack now needs real-time execution on a provisioned device inside a window you control, instead of being performable offline and in bulk at no marginal cost.
It does not make recapture impossible. Against an organised operation it is a cost increase, not a barrier, and deployments facing that need controls above the format.
C2PA Content Credentials and JPEG Trust (ISO/IEC 21617) are the content provenance ecosystem. Between them they have thousands of member organisations, a conformance programme with hardware-backed assurance levels, signing built into shipping cameras and phones, and an ISO process. For content that has to travel across the open web, they are the answer, and EIF changes nothing about that.
EIF is a narrow profile for a different case: evidence capture where the relying party controls the application and needs two things general-purpose provenance does not target — knowing which region of a frame changed, and binding a capture to a transaction it opened.
Provenance must survive platform re-encoding, travel across the open web, or come from consumer camera hardware today.
You control the capture app, need region-level integrity, and need verification that works with no network and no vendor, years later.
The two compose. An EIF file can carry a C2PA manifest in its signed annotations, and a verifier can treat a valid Content Credential as one input among several.
A relying party who believes a control works when it does not is worse off than one who knows the gap exists. These are on the front page rather than in an appendix.
$ pip install eif-sdk
$ eif keygen --out signing-key.pem
$ eif capture damage.png --key signing-key.pem --challenge srv-nonce-7f3a
$ eif verify damage.eif --key signing-key.pub.pem
Verification result: VALID
Key pinning pass
L1 Format pass
L2 Cryptographic pass
L3 Temporal pass
L4 Provenance pass
L5 Device not evaluatedThe most useful contribution anyone can make is an independent implementation in another language — Kotlin and Swift above all, because mobile capture is where this needs to run. Build from the specification rather than the code, and validate against the eleven shared conformance vectors. If the specification is not enough to build from, that is a defect in the specification and the bug report is worth more than most patches.