Looking to implement C2PA? Trufo provides tooling to take care of everything from certificates and timestamping to watermarking and fingerprinting. Learn More

The Role of Cryptography

secure keys and trust models

v2025.10.30

The foundation of the "prove" in provenance comes from a careful mix of cryptography and public trust models. For the general public, this comes in the form of the private key and issued certificate that C2PA signing requires.

Keys and Certificates

Much like HTTPS, the trust in C2PA is built on top of public-key cryptography. There are two main ingredients: the digital signature and the public key infrastructure (PKI).

The digital signature uses a public-private key pair. A message is signed by the private key, creating a signature of a fixed length. Then, the signature can be verified against the message using the public key. The verification guarantees (because math) that the message came from someone with the private key without revealing any information about the private key, so as long as the private key is kept secret, we know the message came from that someone.

The PKI then answers: who is that someone? After all, we can only trust the message as much as we trust that someone. This is where certificates come in. Each certificate contains a chain of digital signatures, each of which says "this is the identity of the below public key," with a trusted "root" identity securing the end of the chain. Furthermore, the PKI also maintains a list of private keys that have been lost, stolen, or otherwise compromised.

Lastly, oftentimes the message itself is not signed directly, but a cryptographic hash of the message is signed instead. This is because signing long messages is computationally expensive. This works because the cryptographic hash again guarantees (because math) the content of the original message.

Cryptography diagram showing public-private key pairs and certificate chains

Putting it altogether, we can make the following proof:

Proof diagram showing how cryptographic signatures verify content authenticity

C2PA Conformance

In order to protect trust in the C2PA ecosystem, there are a set of conformance guidelines that all publishers of trusted content should follow. This includes:

• Secure private keys, which should be generated and stored on a hardware security module (HSM).

• Obtaining a trusted certificate, issued by a trusted issuing certificate authority (ICA) after identity verification.

• Time-stamping C2PA metadata, which typically requires a network call to a trusted time-stamping authority (TSA).

The first two are similar to HTTPS; the time-stamping is required because unlike web traffic, the verification of signed content does not necessarily happen immediately after signing. Overall, the cryptographic components come together in C2PA metadata as follows:

C2PA conformance diagram showing certificate authority structure

Trufo's CA division operates a root CA for C2PA, under which are both ICAs and TSAs. As of the official launch, there are five root CAs, of which only two (SSL.com and Trufo) provide certificates for enterprise implementations; the other three (Google, Xiaomi, Vivo) focus on phones (e.g. Pixel 10).

The recommended algorithms used for the three cryptographic components are:

• SHA-256 (cryptographic hash)

• EdDSA P-256 (digital signature)

• X.509 (certificate)

Other algorithms are allowed (some of which are stronger, such as Ed25519), but may not be widely supported across devices and platforms.

CAWG conformance is still in development.

The Trufo CA is able to help enterprises attain conformant status and implement best practices.

Zero-Knowledge Proofs

In the C2PA trust model, trust is limited by the signers in the provenance chain. For example, if a photo was taken on a C2PA-compliant phone, and then later edited by a C2PA-compliant app, then how can we trust that the edits the app claims were made are representative of the edits that were made to the photo?

There are a number of approach avenues; the most secure one are zero-knowledge proofs (ZKP). These cryptographic objects are designed to prove things without revealing any information. VerITAS is one such ZKP that works on content.

VerITAS: Verifying Image Transformations at Scale

A cryptographic approach using zero-knowledge proofs to verify image edits without revealing the original content or edit parameters.

Read the VerITAS paper →

This means the app is able to not just claim but actually prove what edits were made. While this technology is new, Trufo has begun pilot tests.

Security in the Cloud

Given the need for cloud-based provenance recording and retrieval, the security of network calls and data storage is very important. As with most cloud infrastructure now, there are few vulnerabilities. Things like encryption, access keys, certificates, etc. are all industry standard now provided a small fee is paid, and as a security-minded company Trufo is of course on top of these protections.

There are two primary remaining concerns: social engineering and data privacy. Most attacks happen when credentials are stolen, and although multi-factor authentication (MFA) is a significant deterrent, simple attacks like phishing can still be quite potent. As for data privacy, Trufo's difference hash (DH) and ZKP technologies enable the authentication of altered content without needing to store the original copy.

For added security, public ledgers (on blockchains) can be used in lieu of centralized databases. In particular, public ledgers are immutable: once recorded, the information cannot be changed. On the flip side, centralized databases are faster and much more flexible, and modern encrypted databases are no less secure than public ledgers for most applications.