C2PA Explained -- How Content Credentials Work Under the Hood

Every C2PA content credential is a stack of cryptographic promises. At the bottom is a set of assertions -- structured claims about who created an image, when, and with what tool. In the middle is a claim that bundles those assertions and binds them to the image's pixel data. At the top is a digital signature, backed by an X.509 certificate chain, that makes the entire package tamper-evident. This stack -- assertion, claim, claim signature -- is packaged into a JUMBF container and embedded directly in the image file. Understanding how these layers fit together is essential for anyone who creates, publishes, or analyzes AI-generated images. This article walks through the full C2PA architecture from the inside out.

The C2PA Architecture: Assertions, Claims, and Signatures

The C2PA specification (version 2.0, published in 2024) defines a four-layer architecture for content provenance:

Layer 1 -- Assertions: An assertion is a single, typed statement about the content. Each assertion has a label (a URN-style identifier), a data payload, and an optional cryptographic hash. Assertions are the atomic units of provenance. Examples include:

• c2pa.actions -- records the actions performed on the content (creation, editing, filtering)
• c2pa.creation_info -- records the tool, version, and timestamp of content creation
• c2pa.ai.generative -- specifically marks content as AI-generated
• c2pa.thumbnail -- embeds a reference thumbnail of the content at this provenance step
• c2pa.hash.data -- binds the assertion set to specific pixel data

Assertions are encoded in CBOR (Concise Binary Object Representation), a binary data format defined in RFC 8949. CBOR was chosen over JSON for three reasons: it is more compact (typically 30-50% smaller), it supports binary data natively (no base64 encoding overhead), and it has deterministic encoding rules that ensure the same logical data always produces the same binary representation -- critical for cryptographic hashing.

Layer 2 -- The Claim: A claim is a collection of assertions, grouped together and bound to a specific piece of content. The claim includes:

• A list of assertion references (by label and hash)
• A hash of the underlying content (the "hard binding")
• A reference to the previous claim in the provenance chain (if any)
• The claim generator -- the software or service that created this claim

The claim is also encoded in CBOR. Its hash is computed over the deterministic CBOR encoding, ensuring that any change to any assertion -- even a single bit -- produces a completely different claim hash.

Layer 3 -- The Claim Signature: The claim signature is an X.509-based digital signature over the claim's CBOR encoding. The signature is generated using the private key of the claim generator, and it can be verified using the corresponding public key, which is embedded in an X.509 certificate included in the manifest.

Layer 4 -- The JUMBF Container: The entire package -- assertions, claim, claim signature, certificates, and timestamps -- is packaged into a JUMBF (JPEG Universal Metadata Box Format) container, which is then embedded in the image file.

CBOR Encoding: The Binary Language of C2PA

CBOR (Concise Binary Object Representation) is the data serialization format used throughout C2PA. Understanding CBOR is essential for understanding how C2PA stores and protects provenance data.

CBOR encodes data as a sequence of major-type tagged items. The major type is encoded in the top 3 bits of the first byte, and the additional information (value length or value itself) is encoded in the bottom 5 bits. The major types are:

• Type 0: Unsigned integer
• Type 1: Negative integer
• Type 2: Byte string
• Type 3: Text string (UTF-8)
• Type 4: Array (ordered sequence of items)
• Type 5: Map (key-value pairs)
• Type 6: Tagged item (semantic annotation)
• Type 7: Simple values and floating-point numbers

For C2PA, the most relevant types are maps (type 5), text strings (type 3), byte strings (type 2), and unsigned integers (type 0). A typical C2PA assertion is encoded as a CBOR map with text-string keys, where values can be text strings, integers, nested maps, or byte strings.

Deterministic encoding is critical for C2PA. The specification requires that all CBOR be encoded in "deterministic" form, which means:

• Maps and arrays must be sorted by key (shortest-length first, then lexicographic)
• Integers must use the shortest possible encoding
• Text strings must use the shortest possible length encoding
• No optional padding or whitespace

This determinism ensures that the same logical data always produces the same binary output, which is necessary for cryptographic hash verification. If two different CBOR encoders produced different binary representations of the same data, the hash verification would fail -- even though the data is semantically identical.

X.509 Certificate Chains and Trust Models

C2PA uses X.509 certificate chains to establish trust in content credentials. When a C2PA-compliant tool signs a claim, it uses a private key associated with an X.509 certificate. That certificate is issued by a Certificate Authority (CA) that is part of the C2PA trust list -- a curated list of CAs authorized to issue C2PA signing certificates.

The certificate chain in a C2PA manifest typically has three levels:

Root CA Certificate: The top-level CA in the C2PA trust list. As of 2026, the C2PA trust list includes CAs operated by Adobe, Microsoft, Google, and several industry bodies. The root CA certificates are embedded in C2PA validation software.

Intermediate CA Certificate: An intermediate certificate issued by the root CA. This allows the root CA to delegate signing authority without exposing its root private key. C2PA requires that intermediate certificates include specific Extended Key Usage (EKU) extensions indicating they are authorized to issue C2PA signing certificates.

End-Entity (Leaf) Certificate: The certificate issued to the specific claim generator (e.g., "OpenAI Media Service API" or "Adobe Photoshop 26.0"). This certificate includes the public key used to verify the claim signature. It also includes the organization name, which is displayed to users as the "signed by" entity.

When a C2PA validator processes a manifest, it verifies the entire chain: it checks that the end-entity certificate was issued by an intermediate CA, that the intermediate was issued by a root CA, and that the root CA is on the C2PA trust list. It also checks that none of the certificates have been revoked (via OCSP or CRL checks) and that they are within their validity period.

Timestamp Authorities and Temporal Integrity

C2PA incorporates trusted timestamps to establish when a manifest was created. This prevents backdating attacks where someone creates a manifest with a falsified creation date.

C2PA uses RFC 3161 Time Stamp Tokens (TSTs) generated by a trusted Timestamp Authority (TSA). The TSA signs a hash of the claim data along with the current time, producing a token that cryptographically proves the claim existed at a specific moment.

The timestamp token is embedded in the C2PA manifest as a c2pa.timestamp assertion. During validation, the verifier checks:

1. That the TSA is a trusted authority (included in the C2PA TSA trust list)
2. That the TSA signature is valid
3. That the timestamp is within the certificate's validity period
4. That the hashed claim data matches the actual claim data in the manifest

The C2PA specification requires that manifests include a timestamp token from a TSA on the C2PA trust list. As of 2026, approved TSAs include DigiCert, Sectigo, and GlobalSign. The TSA trust list is maintained by the C2PA steering committee and is updated quarterly.

Binding to the Image: Hard and Soft Bindings

A critical aspect of C2PA is how provenance data is bound to the actual pixel content of the image. C2PA defines two binding mechanisms:

Hard Binding (Required): A hard binding is a cryptographic hash of the image's pixel data. C2PA supports multiple hash algorithms, but as of version 2.0, the recommended algorithm is SHA-256 for the primary binding and SHA-384 for the claim signature hash. The hash is computed over the raw pixel data in the image's native encoding (before any file-level compression). This means that even a single-pixel change to the image will produce a different hash, causing the binding verification to fail.

Soft Binding (Optional): A soft binding is an identifier that can be used to search for the content across databases without requiring exact pixel matches. C2PA supports soft bindings using perceptual hashes (p-hash), digital watermarks (such as those from Digimarc or the newly developed Adobe Content Authenticity Initiative watermark), and embedded identifiers. Soft bindings are useful for tracking content across transformations -- for example, if someone crops, resizes, or re-encodes an image, the perceptual hash may still match even though the pixel data has changed.

The binding process works as follows:

1. The claim generator computes a hash of the image pixel data (hard binding)
2. The hard binding hash is included in the claim as a c2pa.hash.data assertion
3. The claim is signed, binding the signature to the specific pixel content
4. During validation, the verifier recomputes the pixel hash and compares it to the hash in the manifest

This mechanism makes it computationally infeasible to transfer a C2PA provenance chain from one image to another. The signatures would not verify because the pixel hashes would not match.

JUMBF Container Format: How C2PA Lives Inside Your Image

The JUMBF (JPEG Universal Metadata Box Format) container is the outer packaging that holds the C2PA manifest inside an image file. JUMBF is defined in ISO 19566 and provides a hierarchical box structure for embedding arbitrary metadata in image files.

A JUMBF container consists of a sequence of boxes, each with a 4-byte length prefix, a 4-byte type identifier, and a payload. The C2PA specification defines the following box hierarchy:

• JUMBF Superbox: The top-level container. In JPEG files, this is embedded in an APP11 marker segment. In PNG files, it is stored in a caBX ancillary chunk. In WebP files, it is stored in a c2pa chunk.
  • C2PA Manifest Store Box: Contains one or more manifests.
    • C2PA Manifest Box: Contains a single manifest (assertions + claim + signature + certificates + timestamps).
      • Assertion Store Box: Contains all assertions for this manifest.
      • Claim Box: Contains the claim CBOR data.
      • Claim Signature Box: Contains the digital signature and signature algorithm identifier.
      • Certificate Box: Contains the X.509 certificate chain.
      • Timestamp Box: Contains the RFC 3161 timestamp token.

The box structure is self-describing -- each box's length is known, so a parser can skip boxes it does not understand. This forward-compatibility design allows the C2PA specification to add new box types in future versions without breaking existing parsers.

How Different Image Formats Embed C2PA

C2PA uses different embedding strategies depending on the image format:

JPEG: C2PA data is embedded in APP11 marker segments, which follow the SOI (Start of Image) marker and precede the image data. Multiple APP11 segments may be used for large manifests. The APP11 segment includes a JUMBF signature (0x6A756D62 -- "jumb" in ASCII) to identify it as a C2PA container.

PNG: C2PA data is stored in caBX ancillary chunks. The chunk naming follows PNG conventions: lowercase first letter indicates an ancillary chunk, and uppercase second letter indicates a public chunk. The caBX chunk contains the complete JUMBF container.

WebP: C2PA data is stored in a dedicated c2pa chunk within the RIFF container structure. WebP's chunk-based architecture maps naturally to JUMBF boxes, making the integration relatively clean.

TIFF/HEIF: C2PA data can be stored using TIFF/EP tags or within HEIF metadata boxes, following the respective format specifications.

The total size impact of C2PA metadata varies significantly. A simple single-manifest image from a C2PA-compliant camera might add 3-5 KB. A complex multi-manifest image from an AI generator with full provenance chains, thumbnails, and certificate chains can add 20-50 KB. In rare cases with long editing histories and multiple signers, the overhead can exceed 100 KB.

FAQ

Can C2PA provenance be forged?

Forging C2PA provenance requires obtaining a valid signing certificate from a C2PA-trusted Certificate Authority. This means either compromising an existing certificate holder (stealing their private key) or fraudulently obtaining a certificate from a trusted CA. Both are difficult but not impossible. The C2PA threat model acknowledges this and includes certificate revocation, short certificate lifetimes, and audit logging as mitigation measures. However, a manifest signed with a legitimately obtained but later-revoked certificate would still pass validation in offline environments where revocation checks cannot be performed.

What happens if I edit a C2PA-signed image in a non-C2PA tool?

If you edit a C2PA-signed image in a tool that does not support C2PA (such as an older version of Photoshop, GIMP, or a basic image editor), the C2PA manifest will typically be preserved in the output file -- but the hard binding hash will no longer match the modified pixel data. When a C2PA validator later checks the image, it will report that the provenance chain is broken: the manifest exists, but it no longer matches the image content. This is by design -- it alerts the validator that the image has been modified since the last provenance step.

How does C2PA handle privacy concerns?

C2PA 2.0 introduced privacy controls that allow claim generators to selectively redact sensitive assertions while preserving the overall provenance chain. A "redacted manifest" can remove personally identifying information (such as precise GPS coordinates or device serial numbers) while keeping the cryptographic chain intact. However, the effectiveness of these controls depends on the claim generator implementing them correctly. In practice, most AI image generators include the full assertion set without redaction, which means sensitive data like generation prompts and device identifiers are embedded in every C2PA-signed image.

---

C2PA content credentials represent the most sophisticated metadata system ever applied to digital images -- but they are still metadata, stored inside the file, and removable. RemoveAI Image strips C2PA JUMBF containers along with EXIF tags, XMP blocks, IPTC data, and GPS coordinates from JPEG, PNG, WebP, and TIFF files. All processing happens locally in your browser with zero server uploads. Take control of your image provenance today.