The Birthmark Standard Foundation

Technical Architecture

Deep dive into the cryptographic foundations, system components, and privacy guarantees of the Birthmark Standard.

System Overview

Core Problem Solved

Existing solutions like C2PA embed authentication metadata directly in image files. When images are converted, cropped, or shared on social media, this metadata is stripped—making authentication useless for 95% of real-world image distribution. The Birthmark Standard stores authentication records on an independent blockchain, surviving all forms of metadata loss.

Architecture Principles

  • Hardware Root of Trust: Camera sensor NUC (Non-Uniformity Correction) maps provide unforgeable device fingerprints at the atomic level
  • Privacy by Design: Manufacturers validate camera authenticity without seeing image content, timestamps, or location
  • Decentralized Verification: Coalition of aligned organizations operates blockchain, preventing single-point-of-failure
  • Metadata Independence: Authentication survives format conversion and platform stripping
  • Open Infrastructure: All specifications published as prior art, preventing monopolization

Component Architecture

1. Camera Authentication (Hardware Layer)

Function: Generate cryptographic proof that specific camera hardware captured specific image data

Two Parallel Processes:

Process A: Image Hashing

Sensor Array → Raw Bayer Data ↓ [Parallel Split via DMA] ↓ ┌───────────────┴───────────────┐ ↓ ↓ Secure Element ISP (SHA-256 hash of raw data) (Process to JPEG) ↓ ↓ Raw Image Hash Processed Image ↓ ↓ [Hash processed image] Camera Memory ↓ (User's photo) Processed Image Hash

Process B: Camera Token Generation

NUC Hash (stored in Secure Element) ↓ [Randomly select key from 3 assigned tables] ↓ [Encrypt NUC hash with selected key] ↓ Camera Token: - Encrypted NUC hash - Authentication tag - Nonce

Key Innovation: Raw sensor data is hashed before Image Signal Processor (ISP) manipulation. This occurs in parallel with normal image processing via DMA, causing zero user-facing delay.

NUC Hash Permanence: The NUC hash used for camera validation is captured once during manufacturing and stored permanently in the Secure Element. This is separate from the camera's live NUC calibration used for image correction.

2. Submission Server (Entry Layer)

Function: Receive authentication submissions from cameras and editing software, validate through manufacturer/developer authorities, post to Birthmark Media Registry

Camera Submissions (GPS Disabled - Default):

{ "submission_type": "camera", "image_hashes": [ {"image_hash": "raw_hash", "modification_level": 0, "parent_image_hash": null}, {"image_hash": "processed_hash", "modification_level": 1, "parent_image_hash": "raw_hash"} ], "manufacturer_cert": { "authority_id": "CANON_001", "validation_endpoint": "https://mfg.birthmarkstandard.org/validate", "camera_token": { "ciphertext": "encrypted_nuc_hash_hex", "auth_tag": "aes_gcm_authentication_tag", "nonce": "random_96_bit_value" }, "key_reference": { "table_id": 847, "key_index": 234 } }, "timestamp": 1699564800 }

Validation Flow:

  • Receive submission from camera/software
  • Route to appropriate authority (manufacturer for cameras, developer for software)
  • Authority returns PASS/FAIL without seeing image hash
  • If PASS, queue submission for blockchain posting
  • Post individual image hashes directly to Birthmark Media Registry

Technology Stack: Python FastAPI (async), PostgreSQL (submission records), Redis (queue management)

3. Simulated Manufacturer Authority (SMA)

Function: Reference implementation of manufacturer validation server that verifies camera tokens without seeing image content

What SMA Does:

  • Receives manufacturer certificate containing encrypted NUC hash + key reference
  • Extracts key table ID and index from certificate
  • Looks up decryption key from global key database
  • Decrypts NUC hash from camera token
  • Compares against production database of legitimate cameras
  • Returns PASS/FAIL (never reveals which camera or any other information)

Privacy Guarantees:

  • SMA never sees image hashes, timestamps, or GPS data
  • SMA knows only "one of my cameras took a photo"
  • Cannot track individual photographers or correlate images

4. Birthmark Media Registry (Verification Layer)

Architecture: Consortium blockchain operated by the Media Validation Network—a coalition of journalism, fact-checking, and press freedom organizations. Individual image hashes are stored directly on-chain.

Why Consortium Blockchain:

Storing individual hashes directly and distributing trust across mission-aligned organizations solves data availability problems. If any single Submission Server disappears, the Registry remains fully functional and queryable.

Technical Implementation:

  • Cosmos SDK with Proof of Authority consensus
  • 10 initial validator nodes (Foundation-operated until sold)
  • Block time: ~5 seconds
  • Storage: Individual image hash records
  • Query: Direct verification without intermediary

Registry Record Structure:

{ "image_hash": "sha256_hex_64_chars", "submission_type": "camera" | "software", "modification_level": 0 | 1 | 2, "modification_display": "Validated Raw" | "Validated" | "Modified", "parent_image_hash": "sha256_hex_64_chars" | null, "authority_id": "CANON_001" | "ADOBE_LIGHTROOM", "submission_server_id": "server_public_key", "timestamp": 1699564800, "block_number": 12345 }

System Flow Diagrams

1. Creating the Image Hash

Camera-Side Authentication

At the moment of image capture, a secure chip in the camera creates an unforgeable digital signature before the image is even processed.

  • Raw image hashing: A hash is created from the raw image data before any processing like white balance or compression
  • Processed image hashing: A second hash is created from the processed image that you actually save
  • Timestamp and metadata: The camera records when the photo was taken and optionally a hash of the GPS coordinates
  • Parallel processing: Authentication happens in the background while your photo is being captured—no delays or extra steps

Result: A bundle containing both image hashes, timestamp, and optional location hash—ready to be sent to the aggregation server for validation and blockchain recording.

Diagram showing parallel hashing workflow: camera captures image, creates raw and processed hashes simultaneously, sends to Birthmark Media Registry for validation and blockchain recording

Click to view full size

2. Validating Camera Authenticity

Diagram showing privacy-preserving camera validation: camera encrypts calibration file with key table, submission server forwards certificate to manufacturer, manufacturer validates and returns PASS/FAIL without seeing image hashes

Click to view full size - Shows separation of concerns: manufacturer validates camera, never sees image content

Privacy-Preserving Validation

The manufacturer confirms that images come from real cameras without being able to see what photographers are capturing or track individual cameras.

  • Encrypted camera identifiers: Each camera's unique sensor identifier is encrypted using randomly assigned keys, so only the manufacturer can verify it
  • Separation of concerns: Manufacturers receive the encrypted camera ID but never see image hashes, timestamps, or locations
  • Anonymity sets: About 12,000 cameras share each encryption key, preventing tracking of individual cameras
  • Binary response: Manufacturer returns only PASS (legitimate camera) or FAIL (unknown/forged)—nothing else

3. Verifying Images on Blockchain

Immutable Public Verification

Anyone can verify an image's authenticity by checking the blockchain record—no corporate gatekeepers or subscription services required.

  • Direct hash storage: Full SHA-256 image hashes are stored directly on-chain on the custom Birthmark blockchain, eliminating the need for complex cryptographic proofs
  • Institutional validators: The blockchain is operated by trusted institutions (universities, archives, journalism organizations) running validator nodes
  • Zero gas fees: No transaction costs—institutions donate hosting as a public service for truth in media
  • Public verification API: Open protocol allows anyone to build verification tools without asking permission
Diagram showing user verification workflow: select image, hash it locally in web browser, send hash to Birthmark Blockchain, receive match result with timestamp and metadata

Click to view full size - User verification happens client-side

Privacy Architecture

What Different Parties See

Camera Manufacturer (via Authority)

✓ "One of my cameras authenticated a photo"

✗ Which specific camera (table/index shared by thousands)

✗ Image content or hash

✗ When photo was taken

✗ Where photo was taken

✗ Which Submission Server received it

Submission Server

✓ Image hash (to submit to Registry)

✓ Camera certificate table/index (not camera identity)

✓ Manufacturer validation result (PASS/FAIL)

✗ Which specific camera (table shared by ~12,000 cameras)

✗ NUC hash (encrypted, cannot decrypt without key)

✗ Image content

Coalition Blockchain Nodes

✓ Image hashes (SHA-256, not reversible)

✓ Modification levels

✓ Authority IDs

✓ Timestamps (when Submission Server processed, not capture time)

✗ Image content

✗ Specific camera identity or photographer identity

Public Verifier

✓ "This hash was authenticated by this manufacturer on this date"

✗ Who took the photo

✗ Where specifically (only if GPS-enabled version exists and they have that image)

✗ Which specific camera unit

Privacy Mechanisms

  • Key Table Anonymity: Camera randomly selects from 3 tables shared by ~12,000 devices
  • Transaction Spacing: Camera token table/index combinations are not reused until at least 3,000 intervening transactions
  • Hash-Only Storage: Image content never transmitted or stored
  • GPS Opt-In: Location and capture time hashing disabled by default, user must explicitly enable
  • Separated Concerns: No single entity has complete information
  • Timestamp Obfuscation: Registry timestamps reflect Submission Server processing time, not photo capture time

Source Protection: Certificate references stored in the Registry require manufacturer cooperation to trace to specific devices, and even then require possession of the original image to identify relevant records. This architecture prevents fishing expeditions and protects source confidentiality by design.

Cryptographic Standards

Algorithms & Specifications

  • Image Hashing: SHA-256 (industry standard, 256-bit output)
  • NUC Hash Encryption: AES-256-GCM (authenticated encryption)
  • Key Derivation: HKDF-SHA256 (derives table keys from master keys)
  • Digital Signatures: ECDSA secp256k1 (blockchain transaction signing)

Performance Targets

  • Camera Authentication Overhead: <100ms (parallel with ISP)
  • Submission Server Processing: <200ms per request
  • Blockchain Confirmation: ~5 seconds (Cosmos SDK block time)
  • Verification Query: <500ms response time

Scalability Estimates

  • Target Volume: 1 million images/day at scale
  • Blockchain Storage: ~150 bytes per image record
  • Node Storage Growth: ~55 GB/year at 1M images/day
  • Network Bandwidth: Minimal (small transaction data)

Security Model

Threat Mitigations

Threat: Submission Server Compromise

Risk: Server manipulates submissions or goes offline

Mitigation: All data on Registry, server is stateless relay. Spin up new server, continues from blockchain state. Multiple servers can operate simultaneously.

Threat: Node Operator Collusion

Protection: Supermajority (67%) needed for malicious action—would need 7 of 10 journalism organizations to collude. Coalition Members have reputational stake in integrity. Media producers excluded, reducing conflict of interest.

Threat: Government Subversion

Protection: Legal compulsion triggers removal, not compliance. Government can only remove nodes, not control them. Network continues operating with remaining nodes. Organizations become less valuable targets.

Threat: Camera Token Forgery

Protection: NUC maps physically unforgeable (atomic-scale manufacturing variance). Attack cost: $100K-1M per camera (destructive hardware analysis). Manufacturer validates against production records.

What the System Does NOT Protect Against

  • Staged scenes (real camera, fake scene)
  • Images taken of screens (camera authenticates the screen, not original)
  • Side-channel information leakage (careful with GPS, timestamps)
  • Social engineering of coalition members
  • Legal compulsion to reveal information (triggers removal instead)

Integration with Existing Standards

Relationship to C2PA

Complementary, Not Competitive:

  • C2PA: Rich metadata, existing tool ecosystem, but lost when metadata stripped
  • Birthmark: Blockchain fail-safe that survives metadata loss
  • Together: Comprehensive authentication covering all distribution scenarios

Key Differentiator:

  • C2PA validates "something with certificate signed this"
  • Birthmark validates "this specific physical camera sensor captured this"
  • C2PA vulnerable to firmware exploits (Nikon Z6 III incident)
  • Birthmark requires physical sensor access to forge

"Implement Birthmark alongside C2PA for comprehensive authentication. C2PA handles rich metadata and existing workflows. Birthmark handles the 95% of images that lose metadata through social media sharing."