Provenance 105: Cryptography

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, trust in C2PA is built on 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. The signature can then 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. The PKI also maintains a list of private keys that have been lost, stolen, or otherwise compromised.

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

Putting it all together, we can make the following proof:

#C2PA Conformance

To protect trust in the C2PA ecosystem, there is 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:

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 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. If a photo was taken on a C2PA-compliant phone and later edited by a C2PA-compliant app, how can we trust that the edits the app claims were made match the edits actually made to the photo?

There are a number of avenues; the most secure is the zero-knowledge proof (ZKP). These cryptographic objects are designed to prove things without revealing any information. VerITAS is one such ZKP that works on content, verifying image transformations without revealing the original content or edit parameters.

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: encryption, access keys, certificates, and the like are all industry standard provided a small fee is paid, and as a security-minded company Trufo is of course on top of these protections.

Two primary concerns remain: 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. 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.