How Content Is Signed

Two levels of content authenticity — hardware and app — and why RootLens treats them differently.

Hardware-Level Signing

Some devices sign content directly at the sensor level using a dedicated secure chip. The private key is burned into silicon at the factory and never leaves the chip — not even the device's operating system can access it.

Camera Sensor

Converts light to digital data

→

Image Processing

Noise reduction, HDR stacking, etc.

→

Secure Chip

Signs the processed image with a key that cannot be extracted

→

C2PA Signature

Provenance data embedded in the image

Signing key is factory-bound and cannot be extracted from the chip

Device	Secure Chip	What It Proves
Google Pixel	Titan M2	Image came from this device's sensor, unmodified
Sony / Leica	Vendor secure element	Image came from this camera's sensor, unmodified

Trust basis: The device manufacturer binds a signing key to the secure chip at the factory and signs the device certificate with their own Root CA. The entire path from sensor to signature is controlled by the manufacturer's hardware.

What it rules out: Virtual cameras, screen capture injection. The manufacturer's hardware architecture protects the signing key and attests that the signature was produced on that specific device. The exact boundary of hardware protection varies by manufacturer.

App-Level Signing (RootLens)

RootLens provides C2PA signing for devices that lack hardware-level support. Instead of a factory-bound sensor-to-chip path, RootLens uses a combination of Platform Attestation and TEE key protection.

Camera API

Captures image data via OS camera API

→

TEE

Signs with a key inside the TEE. Even the OS cannot access it

→

C2PA Signature

Provenance data embedded in the image

Private key generated in TEE, never exported
Sensor-to-TEE path goes through the OS

RootLens builds trust through three mechanisms:

1. Platform Attestation

Before issuing a Device Certificate, the RootLens server verifies that the device is genuine and uncompromised:

Android: Key Attestation (proves the key was generated inside the TEE) + Play Integrity (proves the device is not rooted or running a debug build)
iOS: App Attest (proves the app is the genuine RootLens binary running on genuine Apple hardware), with clientDataHash = SHA-256(CSR) binding the attestation to the specific key

2. TEE Key Protection

The EC P-256 signing key is generated inside the device's TEE (Secure Enclave on iOS, StrongBox on Android). The private key never leaves the TEE — signing operations happen inside the chip.

3. Three-Layer PKI

The device's public key is certified through a three-layer certificate chain managed by RootLens:

Root CAAWS KMS, 20-year validity
- iOS Intermediate CAAWS KMS
  - Device Certificate 90-day, TEE public key
- Android Intermediate CAAWS KMS
  - Device Certificate 90-day, TEE public key

See the PKI Architecture page for the full certificate profile and issuance flow.

The Honest Trade-Off

Design Decision

RootLens's app-level signing cannot match the sensor-direct guarantee of hardware signing. The camera-to-TEE path goes through the OS, so a sophisticated OS-level attack (virtual camera injection) is theoretically possible — though Platform Attestation rejects rooted devices and debug builds. This trade-off is intentional. C2PA-capable hardware (Titan M2, Nikon Z9) is still rare. RootLens provides app-level authenticity proofs to bridge the gap until hardware signing becomes widespread. When it does, hardware-signed content can be published through RootLens with its stronger guarantee intact.

Comparison

Aspect	Hardware Signing	RootLens App Signing
Trust origin	Factory-bound secure chip	Platform Attestation + RootLens Root CA
Sensor-direct	Yes — OS cannot intercept	No — camera data passes through OS
Key protection	Secure chip	TEE (Secure Enclave / StrongBox)
Certificate chain	Manufacturer Root CA → Device	RootLens Root CA → ICA → Device (3-layer)
Cert extension	`cert-google`, `cert-sony`	`cert-rootlens`
Title Protocol pipeline	Same	Same
Public page display	"Shot on Google Pixel"	"Shot on RootLens"

Key Point

Phases 2 (TEE verification + cNFT minting) and 3 (browser verification) are identical for all content origins. The difference is only in Phase 1 — the trust basis of the original signature.

Provenance Graph (Editing)

RootLens supports editing content after capture (crop, mask, trim). When content is edited, the C2PA standard handles this by creating a new manifest that references the original manifest as an "ingredient." This forms a provenance graph — a chain of signatures that traces the content's full history from capture through each edit.

Scenario	C2PA Chain	Display
Hardware capture → publish	Hardware signature only	"Shot on Google Pixel"
Hardware capture → edit on RootLens → publish	Hardware signature → RootLens signature (edited)	"Shot on Google Pixel, Edited on RootLens"
RootLens capture → publish	RootLens signature only	"Shot on RootLens"
RootLens capture → edit → publish	RootLens signature (captured) → RootLens signature (edited)	"Shot on RootLens" (with edit history)

When you edit a photo in RootLens, the app takes the original file as an "ingredient" and creates a new C2PA manifest recording the edit. The original manufacturer's signature is preserved in the provenance graph, so the verification pipeline can trace the full history — from the original camera capture through each subsequent edit.

← PreviousTrust Model Next →Title Protocol TEE