Attestation in the C2PA Framework

This document is organized as follows.

This specification assumes a working understanding of the C2PA architecture and data structures: in particular, Claims, Assertions, Claim Signatures and how these data objects are packaged into C2PA manifests. This specification also assumes some understanding of attestation technologies.

RATS, or Remote Attestation Procedures, is an IETF specification for a Trust Broker that seeks to improve interoperability between differing attestation systems (https://datatracker.ietf.org/doc/html/rfc9334). In RATS, the trusted service is called The Verifier, and acts as a trusted intermediary between The Attester (the device or service that creates a C2PA asset) and the Relying Party that seeks to make a trust assessment about a program or environment.

C2PA specifications use the terms Validator and Verifier for relying parties. To avoid confusion, this specification uses the term Trust Broker to indicate a RATS Verifier or similar service such as Google’s PlayIntegrity.

Trust Brokers are an important building block for enabling an open ecosystem of attestation-enabled asset creators and attestation-aware relying parties. Trust Brokers must be aware of a diverse set of platform types, applications, operating systems, and security policies. But if their policy requirement are met, then they can translate the raw-attestations into much simpler claims for C2PA validators (e.g., "Trusted Camera App running on Android 11.")

The expectation is that RATS-style Trust Brokers will simplify adoption of attestation technologies by open ecosystems. However, at the time of writing, the RATS ecosystem is still in its infancy. Because of this, current specification supports both raw attestation evidence (e.g., "quotes") as well as RATS-style "verdicts."

Sophisticated and easy to use media editing tools as well as synthetic image generation technologies are widely available. The existence of these tools degrades the probative value of all digital imagery.

Attestation can be used to distinguish imagery captured by a trusted camera and imagery created or manipulated by other applications and services. While no system is foolproof and immune from security threats, for some scenarios an attestation can markedly increase the likelihood that an image is of a real scene.

For example, a Trusted Camera application can use attestation to

Android Play Integrity is a Google service for obtaining such attestations.

Machine learning models are increasingly responsible for security-critical tasks. Training sets, models, and inferences will all benefit from C2PA-style provenance signals and protection. In some cases, ML models execute in environments with poor or unknown security characteristics. In these cases, attestations can be added to demonstrate that a model or inference was trained or run in a secure environment.

For example, consider an ML-based image recognition model. The model performs recognition tasks and then outputs a C2PA-signed version of the asset with manifest metadata that identifies the type and location of the recognized objects.

If the image-recognition model can prove that it is running in a secure environment, then its outputs will be more trustworthy than the same model running in an open environment with poor security characteristics. This type of evidence can be included in C2PA manifests using the attestation technology defined in this specification.

The current (1.3) version of the C2PA specification supports the creation and validation of Implicit Attestation Claim Signatures without changes:

IA-keys and certificates are generally associated with devices, as opposed to people or organizations. If required, Claim Creators may use the CreativeWork assertion to encode a person or organization that was involved in creating a Claim. Alternatively, the conventional Claim Signature (associated with the person or organization) can be retained, and the Implicit Attestation can be encoded in an assertion, as described in Section 7.5.

This specification provides guidance but no normative requirements for the issuance and lifetime management of Implicit Attestation keys. Implementers should consult platform-specific documentation for detailed protocol descriptions.

Devices that support attestation provide cryptographic building blocks that can be used in protocols to prove the identity of the device and running software to relying parties. One common cryptographic primitive is usually called Quote. Quotes are digital signatures over user-supplied data and platform/quote-engine-supplied data that describes the running program and the security properties of the environment in which it is executing.

Quotes (and related primitives) can be used to create Explicit Attestations (Explicit Attestation) but can also be used in a protocol to provision or certify an Implicit Attestation key. A commonly used protocol fragment is that an application creates a key-pair and “Quotes” the resulting public key. The public key and quote is sent to a trusted service that decodes the quote to check that the device is known or in good-standing, and that the program measurements conveyed in the quote are in policy. If the checks succeed, the service creates a certificate for the newly created Implicit Attestation public key.

(Note that this description is simplified: implementers should consult platform documentation for recommended provisioning protocols for Implicit Attestation keys.)

Once provisioned, the Claim Creator uses the corresponding private key to sign the serialized Claim (this chapter) or sign a serialize Partial Claim (Section 7.5).

The certificate for the implicit attestation claim signing key should comply with the requirements in the main C2PA specification. Optionally, the certificate may contain additional fields that convey additional information about the application or security posture of the device to which it was provisioned.

Most platforms that provide attestation capabilities also provide security primitives to allow a system to protect stored keys and other data so that the data is only accessible to the attesting application, or other applications explicitly authorized by the attesting application. This operation is commonly called sealing.

Implementers should consult platform documentation for usage and the expected strength of protection. If suitable sealing primitives are not available, applications should not persist IA-keys: instead they should re-provision on every app-startup (or use Explicit Attestation).

Summarizing the previous sections in the form of a timeline, the following steps are required when provisioning and using a key for Implicit Attestation.

Claims signed using Implicit Attestation Keys are validated identically to Claims signed using keys associated with people or organizations. I.e. the validation procedure is exactly as described in the main C2PA specification, although a different set of Trust Roots may be required or desired.

Claim Signatures are calculated over the serialization of a Claim, and the Claim itself is cryptographically linked to its embedded Assertions. Two types of Assertion are important here: Assertions that contain metadata, and Assertions that bind a Claim to an Asset with a hash or hashes of an Asset or Asset fragment (a "hard binding"). By signing the Claim, the Claim Creator vouches for both the asset (via the binding Assertion) and the metadata.

Similar bindings exists for the explicit attestation signature: i.e., the attestation vouches for the Asset and the metadata. Note that most or all scenarios benefit from binding to the Asset (e.g., for the Trusted Camera Application, “this image was captured by this program running on this device.”) Some scenarios will benefit from binding to metadata assertions (e.g., for a Trusted Camera Application “the GPS coordinates obtained from the radio when this image was captured” or for the ML scenario, “the following objects were recognized in the image.”) However, note that attestation will not improve trust for all types of assertion data: for example, user-input is hearsay as far as the attesting application is concerned.

The approach in this specification is that the attestation is over the serialization of the entire Claim – i.e., the same data structure that the Claim Generator signs (with one exception, which is described below). As noted above, not all Assertions/metadata gain security benefit from the attestation, but signing all assertions provides the most flexibility for future scenarios. For future advanced use cases, the specification defines a field that an attestation generator can use to indicate which assertions are meaningfully “attested.” However, the use and interpretation of this field is beyond the current scope of C2PA.

Explicit attestations are similar to Claim Signatures and could be encoded in a manifest similarly. However, there is also an additional security requirement noted earlier: i.e., that the Claim Signer should also sign the attestation result.

A natural way of encoding the attestation so that it is signed by the Claim Signer is to embed it as an assertion in the Claim. However with this method, then the attestation will naturally be signed in the same way as any other Assertion. However, naïve attempts at implementing this method will fail, as it introduces a circular dependency: the Claim cannot be finalized before the attestation is created, but the attestation requires a finalized Claim in order to calculate the Claim hash.

The specification break this dependency by specifying that the attestation is created over the hash of the serialized claim but omitting the attestation assertion (which has not been created yet.) Once the attestation has been created, it is embedded in the Manifest and Claim identically to any other assertion and will subsequently be signed by the Claim Creator. The Claim with one or more attestation assertions elided is called a Partial Claim.

This architecture is attractive because normal Claim creation and Claim Validation are unaffected. It is also attractive because an attestation-enhanced claim can be processed by an attestation-unaware validator without changes (the attestation assertion can be treated like any other third-party or unrecognized assertion.)

The (simplified) logical work flow for creating a manifest with and without an attestation is illustrated below.

The above figure shows simplified steps for creating a C2PA Manifest containing an Attestation Assertion. In the no-attestation case, Assertions are created and stored in the Assertion Store. Next, a Claim is then prepared, with the assertions array set to the location and hash of the referenced assertions. The Claim is then serialized, hashed, and signed by the Claim Generator, yielding the Claim Signature. The Assertion Store, Claim, and Claim Signature are then packaged as a C2PA manifest (not shown.)

To support explicit attestations, the additional steps in the shaded box are required. As before, an Assertion Store is populated with the desired assertions, but it is referred to as a Partial Claim because one additional Assertion will be added before the Claim is finalized. The Partial Claim is then serialized and the Partial-Claim’s hash (which is generated using the same methodology as a standard Claim) is then attested using the appropriate platform attestation service. Next, the Attestation is packaged as an Attestation Assertion and added to the Assertion Store to create a finalized Assertion Store. Finally, the complete Claim (with the embedded Attestation Assertion) is signed by the Claim Generator.

This architecture requires that attestation-aware validators perform additional steps: Specifically, validators must internally modify the Claim to remove any attestation assertions to produce a Partial Claim that can then be used to validate the bindings in the attestation assertion. This tradeoff is considered to be acceptable: the rewriting cost is borne by the creators and consumers of attestations, but the creation and validation workflow for non-attestation-aware entities is unchanged.

Additional details are included in the normative parts of the specification below.

The diagram below is a more detailed version of dependencies using Partial Claims

The above figure shows cryptographic dependencies for the asset, Partial Claim, and Claim.

As before, an arrow from A to B indicates that A cannot be changed without invalidating B and hence the manifest. Practically, this means that the attestation and Claim Signature can both be stripped and replaced, but neither can be changed independently.

This specification supports more than one attestation for a Claim – for example, there may be one attestation for code running in an enclave, and a second for the overall platform (the “rich OS.”)

If more than one attestation is required then they are ordered and each subsequent attestation is over the Partial Claim containing the prior attestations. For example, if two attestations are required, the first attestation to be added will be over the Partial Claim with no attestation assertions. The first attestation assertion is then added to the Claim, and the resulting data structure becomes the user data input (partial Claim) for the second attestation. Of course, the second attestation assertion is then added, and the resulting finalized Claim is signed by the Claim Creator.

The cryptographic dependencies are illustrated below. The manifest is built from the top to the bottom. An arrow from A to B indicates that B has a cryptographic dependence on A.

The above figure shows cryptographic dependencies for a manifest with two explicit attestations.

Attesters that wish to include multiple attestations are free to decide the order that they are created and embedded, but since later attestations include earlier attestations, the validation order must be the same as the creation order. To ensure that that this occurs, this specification requires that attestations are embedded in the assertions array in the order that they are created.

Chapter 6 describes Implicit Attestation in detail, but briefly, an Implicit Attestation is a simple signature (i.e., not a "quote") using a key that is only accessible to authorized applications running on authorized devices. If the key can only be used by trusted applications, then the presence of a well-formed Claim Signature implies that the trusted app signed the Claim.

Section 6.1 describes how Implicit Attestations can be encoded as Claim Signatures. This is simple and straightforward, but C2PA does not support multiple Claim Signatures in a Manifest so may not be suitable when the Claim Creator needs to convey both the (organization- or human-) Claim Signer and the application+device on which the Manifest was created.

To remedy this, the specification also allows Implicit Attestations to be encoded in Attestation Assertions, in exactly the same way that Explicit Attestations are supported. When using this option, rather than using a quote-style signature, the signature is created using an Implicit Attestation key: e.g., a key that is associated with a trusted application running on a trusted device.

Attestation Assertions for Implicit Attestations are distinguished using the type field. Implicit Attestations use the attestation type c2pa.embedded-implicit and the actual signature is embedded in the attestation-info-map.att-result field. Details are provided in Appendix A.

These are the detailed steps for creating an embedding an Attestation into a Claim. In the 1.3 version of the C2PA specification, these steps should be performed immediately prior to “11.3.2.4. Signing a Claim”. Following the steps listed here, the Claim should be signed as described in the main specification.

At this point, the final claim has been created, and processing can continue according to “11.3.2.4. Signing a Claim” using the claim-map with all embedded Attestation Assertions.

Note that this generic flow does not specify how an attestation is encoded into attestation-results. This is scheme-specific and is described in Appendix A.

This section describes how Claims containing explicit attestations should be validated. This section also describes how non-attestation aware validators should behave: this text will be replicated in the main C2PA technical specification.

A variety of hardware-based attestation technologies are available. Most platforms offer just one choice, although some platforms have two. For example, many platforms contain a TPM that can attest the "rich OS", and some contain an additional attestation root for reporting the software running in a protected enclave.

System architects may consider the following factors when choosing an attestation technology:

Explicit Attestations are created at the time of Claim Creation and are bundled in the manifest. Explicit attestations supplement a conventional Claim Signature and are bound to it so that neither the attestation or the Claim Signature can be independently stripped or replaced.

Implicit Attestation is a Signature with a key that was provisioned for the Claim Creator using attestation primitives, but reflects some past security configuration for the platform or Claim Creator.

System architects may consider the following factors when choosing between Implicit and Explicit attestations:

RATS (Remote Attestation Procedures) is a suite of technologies and protocols that allow a third-party verifier to translate a diverse set of "raw" attestations into simpler and easier-to-understand trust assessments. I.e., RATS will generally relieve the Claim Validator of the need to understand the details of the attestation technology and acceptable attestation measurements used by the Claim Creator.

This is generally a good thing, but it comes at the cost of:

Note that RATS also defines protocols for "key attestation." These techniques can be used to enroll keys for Implicit Attestation.

This specification supports Claim-Signer implicit attestation, where the signature with the IA-key is the Claim Signature, and Embedded Implicit Attestation, where the IA-key signature is embedded in an attestation assertion and the resulting Claim is signed with a separate Claim Signature.

Embedded Implicit attestation is favoured when Claim Creators wish to create manifests that are associated with both a person/organization and the identity of the an application or device.

Implementation complexity and cost for Claim Signer Implicit Attestation is similar to normal Claim Creations: it just differs in the type of key used sign the Claim.

Explicit attestation requires additional steps, with implications for both Claim Creation time and memory usage. Explicit attestation requires that a Partial Claim be constructed, attested, and bundled/embedded as an assertion. (This may be repeated if more than one attestation is required.) Once the final Claim is available, it is signed as usual.

The Claim Creator must protect the Claim as it passes from a Partial Claim to a finalized Claim with a Claim Signature. Obviously, this is easiest if the Partial Claim can be held in Claim-Creator-private RAM. If this is not possible, then the Claim Creator may use cryptography or suitably protected external storage during processing.

Implicit Attestations are processed identically to normal Claims.

Embedded Explicit Attestations are processed by non-attestation aware Claim Validators in the normal way, but they will ignore the attestation assertion.

Embedded Explicit Attestations processed by attestation-aware Claim Validators require additional steps. The Claim Signature will be validated, as usual, but then the the Partial Claim must be created and the attestation must be evaluated. This requires additional data structure manipulation, an additional signature verification, and and additional checks that the attestation measurements are within policy.

When a C2PA Manifest uses a c2pa.hash.data assertion for the hard binding to the media, there is an interdependency between the hard binding assertion and the attestation assertion. This interdependency can be summarized by highlighting two key steps in the process:

The contents of the c2pa.attestation assertion depends on the contents of the c2pa.hash.data assertion, which depends on the size of the c2pa.attestation assertion. The solution to the problem is to use padding. For example, the pad and pad2 fields of the attestation-info-map can be used to add padding to the c2pa.attestation assertion before finalizing the exclusions field of the c2pa.hash.data. A procedure for accomplishing this is described in Section 11.4 of the C2PA specification.

In Section 8.3.1.3, the C2PA specification describes a method for adding salt to assertions before constructing the Claim. Since this salt is part of the JUMBF structure, and not part of the assertion data, some implementations might not store this salt in internal (deserialized) structures, and might just generate it as part of the serialization to JUMBF process.

In such implementations, it is possible that the salt value could change between the process of serializing the JUMBF structure for the Partial Claim, vs. serializing the JUMBF structure for the full Claim that will be signed by the C2PA Signature. If the salt changes between these two steps, then the Claim’s hashes for each assertion will also change, and the c2pa.attestation assertion will fail verification.

It is important that the assertion salt values (if any) do not change between generation of the Partial Claim and the full Claim.

Android Key Attestation provides a way to determine if an asymmetric key pair is hardware-backed, what the properties of the key are, and what constraints are applied to its usage. See the following Android references for details:

Intel SGX Attestation provides evidence that the application is running on an Intel SGX enabled platform, inside of a properly instantiated enclave, on a system with a known security configuration.

The high-level flow of an Intel SGX ECDSA attestation is:

Intel does not define a specific protocol for communications between the Intel SGX workload and the relying party. How the two systems establish their secure communications channel and exchange information is up to the solution provider.

IETF RATS (Remote Attestation Procedures) defines a suite of protocols that enable attesters (devices/applications) to perform an attestation exchange with a RATS Verifier (a Trust Broker) and receive an attestation result/verdict in a RATS compliant format. In this revision of the document, the RATS Passport based topology is followed and the received attestation verdict (known as the Passport) is encoded as a C2PA attestation assertion, which is then embedded in a Manifest.

The remainder of the sub-sections describe how the desired attestation can be obtained and interpreted from a device complying with the ARM Platform Security Architecture (PSA) which supports the IETF RATS based attestation protocol. Additional architectures will be defined in the future.

The Attestation Evidence is a set of signed platform-specific claims that is generated from the ARM PSA device. The Attestation Evidence is a specific profile of an Entity Attestation Token (EAT) documented here. The RATS trust broker which performs the Attestation Verification and provides the Attestation Verdict is built on Open Source componentry called Veraison