How It Works - The Birthmark Standard Foundation

From camera to registry

Your photo stays with you. Only a fingerprint of the file leaves the camera. The registry holds that fingerprint, how the photo was processed and roughly when, and holds no copy of the image.

Take. A registered camera computes a fingerprint of the photo. The photo itself is never sent.
Send. Only the fingerprint goes to the registry. The camera's proof of registration travels separately, so no single system sees both who took a photo and what it shows.
Record. The registry keeps a small record: the fingerprint, a verdict on how the image was processed, and a coarsened time. It holds no copy of the image, no name and no location.

Checking a photo

Anyone with the file can check it. The registry offers no reverse lookup, so you need the file to find its record.

Illustration of checking a photo. Drop in a file and get one of three results. No record found does not prove the photo is fake, only that the chain of custody is broken.

Three possible results:

Registered original. Came from a registered camera. Shows roughly when it was registered.
Registered, edited. Edited in certified software. Shows how, and links to the fingerprint of the original.
No record found. This is not proof the photo is fake, only that the chain of custody is broken. The file may be re-saved or edited outside certified software, or come from a manufacturer that does not take part.

Editing a photo

Certified Media Processing Software creates a new record linked to the original. These records carry a weaker guarantee than original captures, because they depend on the software developer's judgment. Any change outside certified software, including recompression or a screenshot, produces no record.

Edit in certified software and the registry gets a new record linked to your original. Use any other tool, or re-save or screenshot the file, and the edited file has no record. Your original keeps its own.

Technical detail

One picture, two messages. Who can see what. What it would take to break it.

One Picture, Two Messages

The Birthmark Protocol splits the job of authenticating a photo across independently operated parts. Each one holds only what its own task requires.

1. The camera fingerprints the file

When the camera saves a photo, it computes a SHA-256 hash of the whole file: the image's fingerprint. It then builds two separate messages. The content message carries the fingerprint. The credential message carries the camera's credential, encrypted so that only its manufacturer can read it. The two are tied together only by a one-way hash that includes a secret random number, so neither message can be traced to the other. The image itself is never sent anywhere.

2. The messages travel separately

Each message travels through its own relays, run by different operators. Only the first relay on each path sees the camera's network address, and it can't read the message or tell which kind it is. Every message is held for a random time and padded to a common size, so messages can't be matched up by timing or size.

3. The manufacturer checks the camera

The credential message goes to a server that forwards the credential to the camera's manufacturer. The manufacturer confirms the camera is registered and signs a verdict, but it receives the link to the content only in encrypted form, under a key it never holds. It learns which camera is checking in, never what it photographed.

4. Independent checkpoints confirm the approval

Three independent gatekeepers each check the manufacturer's approval and post it to their own board. Two content servers, run by different operators, each receive the content message directly from the camera and wait until two of the three boards confirm a matching approval.

5. The registry writes the record

The Birthmark Media Registry writes a record only when both content servers submit matching entries. A record for an original capture is 42 bytes: the fingerprint, a one-byte verdict describing how the image was processed, and a coarsened posting time. It names no camera, manufacturer, photographer or server. Because of the deliberate delays, a record appears minutes after capture, not instantly.

6. Anyone can check

Anyone holding a copy of the file can compute its fingerprint and look it up. No account or subscription is needed. The registry answers whether the file came from a registered device. It deliberately offers no reverse lookup, so it can't be searched to find out who took a picture.

Who Can See What

What each part of the system can read for one photo, even if an attacker takes full control of it. No single component holds both something that identifies the camera and the image fingerprint.

Data	First Relay	Manufacturer	Credential Server and Gatekeepers	Content Servers	Registry and Public
Camera's network address	✅ Yes	❌ No	❌ No	❌ No	❌ No
Which camera	❌ No	✅ Yes	❌ No (encrypted)	❌ No	❌ No
Image fingerprint	❌ No	❌ No	❌ No	✅ Yes	✅ Yes
The image itself	❌ No	❌ No	❌ No	❌ No	❌ No
Photographer, location, capture time	❌ No	❌ No	❌ No	❌ No	❌ No

The credential server also learns which group of devices a photo comes from (usually one manufacturer's), so a manufacturer with few registered devices offers a smaller crowd to hide in.

What It Would Take to Break It

Linking a camera to a picture

We tested each part of the system by giving an attacker all of its keys and everything it sees. Twelve security properties are machine-checked across eleven ProVerif models. Linking a camera to a picture would take compromising the manufacturer together with the credential server, or the manufacturer together with a gatekeeper. These are run by organizations required to share no ownership, jurisdiction, administration, logs or keys, and the consortium's independence rules and audits exist to keep it that way.

Even then, the system holds no images, so every attempt to link a camera to a picture has to start from a specific image already in hand. No one can browse the registry to list photographers.

Forging a record

A record needs the manufacturer's signed approval, confirmation on two of three independent boards, and matching entries from two content servers run by different operators. Proofs show that one compromised content server can't write or alter a record, and that even two of the three gatekeepers together can't force a record the manufacturer never approved.