C2PA

The structure of C2PA metadata in a file with multiple Manifests generated when the picture was recorded, edited and published

The procedures proposed by the C2PA provide for the storage of additional information (metadata) regarding the provenance of files. Unlike known standards for metadata such as Exif or IPTC, this data is secured against forgery. Manipulation of the metadata and the actual content of a file is still possible, but can be detected with a high degree of certainty due to the use of cryptographic methods. The content and structure of the metadata are defined in the C2PA standard specifications.[5] The storage of C2PA metadata is optional.[6]

Part of the stored metadata can be, for example, the name of the hardware and software used for storage, such as a camera, smartphone, camera app, or editing program. Further contents can include the location and time of a recording, a list of performed editing steps as well as information about authors and publishers of a file. The integration of data blocks of established formats such as Exif and IPTC is also part of the standard. In addition, a digital fingerprint (hash code) of the file's payload (photo, text...) is stored. For visual payloads, there is an option to store a reduced representation of the content (thumbnail).

The presence of C2PA metadata is indicated by a visual element that can be shown on top or near a picture

C2PA-compliant websites or other systems displaying content with C2PA metadata use specific visual elements to indicate the presence of C2PA-compliant provenance information.[7] In most cases, these indicators are placed on top or beneath the corresponding information element, e.g. a picture or video. Upon interaction (e.g. mouse click, touch) with that indicator, standard-compliant applications or websites display basic information about the content's provenance within the visual context of the content, e.g. as a popup window. From here, a link may lead to a more extensive display of information. Dependent on the amount of C2PA metadata present, this display will not only include the youngest iteration of the available data but allow to explore earlier versions of edited files, too. In this case, a comparison between different versions of the visual content within a media file can also be possible. Like this, interested users can thoroughly examine the provenance of a file and assess its trustworthiness.

The C2PA specification refers to the visual indicator element as "L1 indicator". The indicator can consist of only a graphical icon with the lowercase letter "i" or of that icon with accompanying text, such as "Content Credentials". The element displayed after interaction with the L1 indicator is called "L2 provenance summary". The visual element displaying the L2 summary may be very concise in a first step, such as only showing the name of the last signing entity (e.g., name of a hardware manufacturer or publisher) and the date of the signature. The L2 summary may also offer an interface to expand the element and display more detailed information like location data or a brief editing history. The element used for an extensive display of C2PA metadata is called "L3". L3 is accessed via a link element within L2. This link can open another, in-application display element or be connected with another website specialized for in-depth display of all or most of C2PA data present in the content. An implementation example for L3 is available on the CAI website.[8] Here users can inspect the metadata of sample pictures as well as upload own files with C2PA metadata.

As of August 2022, there are only few examples for C2PA-compliant content available, some of them listed on the CAI website.[9]

A central task of C2PA-compliant systems is to secure content and metadata against unnoticed tampering. For this purpose, the C2PA specification relies on the use of hashes and digital signatures. Only certified signatures may be used.[10] The certificate associated with a signature must conform to the standard defined in X.509.[11] For hashing, the C2PA recommends SHA2-256.[12]

The basic element of C2PA data structures are so-called "Assertions".[13] Assertions contain statements about the file content, e.g. about processing steps that have been performed. The hash value of the file's payload is also stored in an assertion. This hash value is particularly important for subsequent checks. Assertions can contain larger data structures as well, for example a preview image of the content or complete Exif and IPTC blocks.

A list of links to all assertions is stored in a data structure called "Claim".[14] This is also where the software stores the hash values calculated for all assertions. To protect the claim and the hashes stored in the claim from tampering, the storing system generates a digital signature for the claim. This signature contains an encrypted hash value for the content of the claim. The encryption is performed with the private, secret key of the entity responsible for the storing system. Examples for such entities are camera manufacturers or developers of image editing software.

The signature of the claim, the claim itself, and the entire assertion store are part of a higher-level structure called "Manifest."[15] Since the manifest only serves as a framework for data structures that are already cryptographically protected, it is not subjected to its own cryptographic treatment.

If the respective file format allows for, the metadata is stored directly in the file. If this is not possible, as with plain text files for example, the data is stored in a sidecar file.[16] The C2PA metadata stored for a file can be extended with additional information, for example, as part of subsequent editing. The removal of information, for example to protect depicted persons, is also provided for.[17] The cryptographic integrity of C2PA data is maintained even after such edits, as long as C2PA-compliant tools are used, since new hashes and signatures are generated for each edit.

The signature assigned to a claim contains its encrypted hash value. This hash value is required to check the content of the claim for possible manipulations. To decrypt the hash, the checking system needs the public key of the entity responsible for storing the file. This key can be accessed via the likewise cryptographically protected certificate linked to the signature of the claim. The certificate also serves as proof of identity for its owner, since the issuer of the certificate has verified that entity's identity before storing it in the certificate.

After decrypting the hash value contained in the claim signature, the claim of the currently examined file can be checked for integrity. To do this, the checking system calculates the hash value of the examined claim and compares it with the hash value previously extracted and decrypted from the signature. If both hashes match, this is strong evidence that the content of claim has not been manipulated. On this basis, the checking system can also trust the hashes of the assertions stored in the claim. In the next step of the examination, the hashes of the assertions in the checked file are therefore recalculated and compared with the hashes in the claim. If there is a match, the data stored in the assertions may be considered unchanged.

Another check is performed on the hash value of the actual file contents stored in a separate assertion. For this purpose, the checking system calculates the corresponding hash value of the file just examined. If this new hash value is identical to the hash stored in the assertion, this is strong evidence that the file contents have also remained unchanged.

The cryptographic integrity of a C2PA-compliant file does not provide evidence that it contains an authentic representation of reality. Instead of the scene captured by the lens, a C2PA-compliant camera or camera app could store and cryptographically sign a freely invented, e.g., AI-generated, image. Similarly, any C2PA-compliant system can freely invent or arbitrarily falsify any metadata that is to be stored and then properly sign that data. The result would be a file that fully complies with the technical specifications of the standard. A C2PA-compliant check would show that the hashes stored in the signatures match the contents of the file and therefore declare the file valid in terms of the C2PA standard.

Statements as to whether a stored content adequately reflects reality are not possible within the scope of the C2PA standard. This also applies to systems that read out and sign image data using specially secured hardware.[18] Despite the associated, far greater certainty of true-to-life images, manipulations cannot be completely ruled out with such systems either.

The system proposed by C2PA allows only two trustworthy statements for files with cryptographically intact metadata:

• The C2PA metadata associated with a file was in fact generated and signed by the entity or entities named in the certificate(s) used for signing, or from a system the entity authorized. In other words: The entities named in the certificate are in fact responsible for the content of the C2PA metadata and for the file's payload, e.g. a photo or video.
• The file content (for example, the pixels of a photo) and all C2PA-compliant signed metadata have not been modified since signing.

On this basis, viewers or users of a file can decide as to whether they want to trust the content signed by the certificate holder.

• Anyone who trusts the certificate holder to keep his private key perfectly secret can also trust its signature and therefore assume that the corresponding file was actually generated by the certificate holder or a system authorized by the certificate holder.
• Anyone who also trusts the certificate holder to process or publish information correctly and unaltered to the best of his knowledge can extend this trust to the correctness of the information contained in the file.

In June 2022, the CAI released two software development kits (SDK) and a command line tool to facilitate the development of C2PA-compliant applications.[19][20][21] A JavaScript SDK offers functions for the display and verification of C2PA metadata. A Rust SDK addresses the programming of general C2PA-compliant applications with functions to read, display, verify and write C2PA metadata. The command line tool offers functions to read, verify, display and write C2PA metadata. The SDKs and the command line tool are made available on GitHub under the MIT license and Apache license.

Version 1.0 of the C2PA standard specification was published in January 2022.[22] Products that support this standard exist in very small numbers as of August 2022. Adobe Photoshop supports C2PA-compliant storage of editing steps and other metadata as part of an experimental implementation. Adobe Stock, a commercial platform for photos, graphics, and videos, adds some C2PA-compliant data to files offered there. Cameras or camera apps that can store C2PA-compliant metadata are not yet available. Internet sites that offer content with C2PA metadata currently exist only as part of experimental test projects.

As of August 2022, the C2PA "Steering Committee Members" are: Adobe, arm, the BBC, intel, Microsoft, Sony, Truepic and Twitter. Listed as "General Members" are: Ateme, Identity.com, Numbers Co., Nikon, RIAA, The Society Library, and Witness. In addition, the C2PA website lists 22 "Contributor Members".