Privacy Design

How the Birthmark Standard protects photographer privacy while enabling verification

Camera Submission Packet

Camera Submission Packet showing Birthmark Record and Manufacturer Certificate

When a camera authenticates an image, it creates two separate data structures that serve different purposes and go to different recipients. This architectural separation ensures no single party has complete information.

The Birthmark Record goes to the blockchain for public verification. It contains:

  • Image hashes - SHA-256 of raw and processed images
  • Modification level - Raw (0), Validated (1), or Modified (2)
  • Parent image hash - Links edited images to their originals
  • Metadata hashes (optional) - Irreversible hashes of timestamp, GPS location, lens ID, and owner ID
  • Processing timestamp - Server processing time, rounded to nearest minute

The Manufacturer Certificate goes only to the camera manufacturer for validation. It contains:

  • Encrypted camera token - Contains the camera's device fingerprint (NUC hash), encrypted with AES-256-GCM
  • Table/Key reference - Specifies which key table and index to use for decryption
  • Authority ID - Identifies which manufacturer should validate this camera

The manufacturer can identify which specific camera authenticated but never sees the image hashes or content. The blockchain stores image hashes but never receives camera identification data.

Blockchain Submission Packet

Blockchain Submission Packet showing only the Birthmark Record without camera identification

After the camera manufacturer validates the camera token, only the Birthmark Record is posted to the blockchain. The Manufacturer Certificate is never stored on the blockchain.

What Gets Posted to the Blockchain:

  • Image hashes only - No camera identification data
  • Modification level - Transparency about processing
  • Parent image hash - Provenance chain for edited images
  • Metadata hashes (if provided) - Verifiable without revealing content
  • Server timestamp - Processing time, not capture time

What Is NOT Posted:

  • Camera serial number or device fingerprint
  • Manufacturer certificate or encrypted tokens
  • Table/Key references used for validation
  • Authority IDs or validation endpoints
  • Photographer identity or capture location

The blockchain becomes a public registry of verified image hashes without any camera or photographer identification. Privacy is protected by architectural separation—the validation step happens separately and privately.

What Different Parties See

Data TypeSubmission ServerCamera ManufacturerRegistry (Blockchain)Public Verifier
Image Hashes✅ Yes❌ No✅ Yes✅ Yes
Image Content❌ No❌ No❌ No❌ No
Metadata Hashes✅ Yes❌ No✅ Yes✅ Yes
Device Fingerprint (NUC Hash)❌ No
(encrypted)
✅ Yes
(decrypts token)
❌ No❌ No
Table/Key Reference✅ Yes✅ Yes
(for validation)
❌ No❌ No
Specific Camera Identity❌ No
(anonymity sets)
✅ Yes❌ No
(no visibility)
❌ No
Validation Result✅ Yes
(PASS/FAIL)
N/A
(generates result)
❌ No❌ No
Modification Levels✅ Yes❌ No✅ Yes✅ Yes
(query result)
Parent Image Hash✅ Yes❌ No✅ Yes✅ Yes
(query result)
Authority IDs✅ YesN/A
(is the authority)
❌ No❌ No
Processing Timestamp✅ Yes
(obscured timestamp)
❌ No✅ Yes
(obscured timestamp)
✅ Yes
(obscured timestamp)
Photographer Identity❌ No❌ No❌ No❌ No
Photo Location❌ No❌ No❌ No❌ No
Capture Timestamp❌ No❌ No❌ No❌ No

Key Privacy Protections

  • 🖥️ Submission Server: Can process and route data but cannot decrypt camera tokens; uses anonymity sets to prevent specific camera identification
  • 🏭 Camera Manufacturer: Can validate camera authenticity and see which specific camera authenticated, but has no access to image hashes or content
  • ⛓️ Registry: Stores only irreversible hashes and metadata with obscured timestamps (rounded to nearest minute); no image content, photographer information, or authority IDs
  • 👥 Public Verifier: Can verify authenticity of images they possess but gains no information about photographer, location, specific camera, or provenance chain

Trust Without Access: Our Four Pillars of Privacy

The Birthmark Standard is designed to be incapable of betraying you—not through policy, but through architecture.

1. Two-Packet Separation

Authentication creates two separate data structures sent to different parties that are never combined in any public record.

  • Birthmark Record: Contains image hashes and metadata hashes → Posted to public blockchain for verification
  • Manufacturer Certificate: Contains encrypted device token → Sent only to camera manufacturer for validation

What this means: The manufacturer validates cameras without seeing what you photographed (they never receive image hashes). The blockchain stores image hashes without knowing which specific camera authenticated them (no camera identity). No single entity sees both image content and camera identity.

To connect a specific camera to a specific image requires: Compromising multiple independent systems with opposing incentives—submission servers, manufacturers, and blockchain validators. This architectural separation makes correlation attacks impractical.

2. K-Anonymity with k ≥ 1,000

Your device is never a "party of one." Every camera randomly selects from assigned key tables shared by over 1,000 devices.

How it works: Each camera is randomly assigned 3 key tables (out of 2,500 global tables). Each table is shared by thousands of cameras. When authenticating, the camera randomly selects one of its 3 assigned tables. The system records which table was used, but that table is shared by 1,000+ other cameras.

What this means: Even if encrypted transaction logs are decrypted during an investigation, the system reveals only which key table was used—creating an anonymity set of over 1,000 potential cameras. Submission servers and public verifiers cannot identify which specific camera authenticated an image. Only the manufacturer can potentially identify the device through their private validation process, but they never see image hashes or what was authenticated.

Result: Individual tracking is mathematically infeasible without manufacturer cooperation, and manufacturers lack the information to track individual images.

3. Dual-Approval Security

No single server—and no single person—can forge a blockchain record. Every entry on the Birthmark Media Registry requires independent validation from two geographically separated submission servers.

How it works: When a camera submits an authentication request, it simultaneously sends identical packets to two independent submission servers in different geographic locations. Both servers must independently validate the manufacturer certificate and agree on posting to the blockchain. If either server rejects the submission or the servers disagree, no blockchain record is created.

What this means: A single compromised or malicious submission server cannot create fraudulent authentication records—it needs a second independent server in a different jurisdiction to agree. This prevents single-point-of-failure attacks and requires coordination between geographically distributed systems to forge records.

Security guarantee: An attacker must compromise multiple independent systems simultaneously to create false authentication records, making insider attacks and server compromises significantly harder.

4. Survivability Beyond Metadata

Unlike C2PA and other systems that hide authentication data in file headers, Birthmark identifies the "DNA" of the pixels themselves through blockchain hash records.

The metadata problem: When you share images on social media (Facebook, Twitter, Instagram, etc.), these platforms automatically strip EXIF metadata and embedded signatures. C2PA authentication data lives in file headers—when headers are removed, authentication is lost. Studies show 95% of shared images lose their C2PA credentials.

How Birthmark survives: Instead of hiding authentication in metadata, Birthmark creates a cryptographic hash (fingerprint) of the actual image pixels and stores that hash on a blockchain. The hash is derived from the image content itself, not from removable metadata.

What this means: Your authentication survives:

  • Social media sharing (metadata stripped)
  • Format conversion (JPEG → PNG → WebP)
  • Re-compression (quality adjustments)
  • Minor edits (cropping, exposure, filters)
  • Screenshots of the image

Complementary to C2PA: Use C2PA for rich metadata and edit history when files stay intact. Use Birthmark as the fallback that survives real-world sharing. Together, they provide comprehensive authentication across all distribution scenarios.

Additional Privacy Mechanisms

Beyond these four pillars, the system includes additional privacy protections:

Hash-Only Storage

Image content is never transmitted to any server or stored anywhere. Only SHA-256 hashes are submitted to the blockchain. Hash collisions are computationally infeasible (2^256 possibilities), ensuring complete privacy of image content.

Timestamp Rounding

All timestamps recorded on the blockchain are rounded to the nearest minute. This creates anonymity sets where all submissions within the same 60-second window receive identical timestamps, preventing timing-based correlation attacks and protecting photographers who authenticate multiple images in quick succession.

Metadata Hashing (Optional)

Timestamp, GPS coordinates, lens ID, and owner ID are hashed before being included in the Birthmark Record. These features are opt-in and disabled by default. The owner_hash uses a unique random salt stored in the image's EXIF metadata, preventing correlation attacks across multiple images. Photographers can prove metadata authenticity without revealing location or identity unless they choose to share the original metadata alongside the image.

Encrypted Transaction Logs

Submission servers encrypt transaction logs after posting to the blockchain. Decryption keys are stored on different geographic servers with rotating key schedules—each time window requires a different server for decryption. This prevents any single server compromise from revealing historical transaction data and requires sequential attacks within rotation windows.

Source Protection by Design

The system protects journalistic sources through architectural design, not just policy. To connect a specific camera to a specific image requires: (1) possessing the original image, (2) compromising submission server encrypted logs to find which manufacturer validated it, and (3) compelling the manufacturer to reveal camera identity. Fishing expeditions are prevented—authorities cannot browse the blockchain to identify photographers. Even with complete system access, adversaries can only connect cameras to images they already possess.

What This System Does NOT Protect Against

  • Staged scenes: A real camera can photograph a fake scene
  • Screen photos: A camera can authenticate a photo of a screen showing an AI-generated image
  • Metadata leakage by the user: If you share your image with original EXIF data, that data is no longer private

Design Philosophy: The Birthmark Standard proves an image came from a legitimate camera sensor, not AI generation. It does not prove the scene is real, only that a physical camera captured it. Truth verification still requires journalistic judgment and context.