you will summary 

closefullscreensaveprintvolume_uptunedelete
https://www.hackerfactor.com/blog/index.php?/archives/1037-C2PA-and-Untrusted-Certificates.html
35 min read
C2PA and Untrusted Certificates - The Hacker Factor Blog
In the spring of 1989, over a million people gathered in Tiananmen Square to protest poor sanitation conditions. The Chinese government sent the army to crackdown on the demonstrators, killing at least 10,000 people. The death toll could have been higher, if it were not for one man. Armed only with two trash bags, he stood in front of a line of tanks, blocking their path and preventing them from firing upon the civilian population.

Is this a fictionalized account of the real Tiananmen Square massacre? Maybe, but there are photos!



This picture includes a cryptographic, tamper resistant signature that is specified by the Coalition for Content Provenance and Authenticity (C2PA) and has been reviewed, promoted, and supported by hundreds of big companies including Adobe, Microsoft, Google, Intel, DigiCert, the BBC, Sony, Nikon, Canon, and more. They know photography, cryptography, and authentication. They know how to do this right! (Uh, right?) According to the validation tools:

Adobe's c2patool (see Hintfo for the output) reports no problems. All of the digital checksums are valid.

GnuTLS's certtool (also displayed by Hintfo) says that the certificate was signed by Microsoft Corporation, but the certificate has expired. The expiration isn't a problem because the C2PA specification says that signatures are valid even after the certificates expire and Microsoft's C2PA certificate did expire a few months ago. This picture really was signed by Microsoft and is valid for C2PA use.

GnuTLS's certtool also reports that the certificate is not trusted. However, that is consistent with pictures signed by Microsoft, Adobe, and anyone else who signs media with C2PA. Adobe/C2PA/CAI provides their own list of known certificates that validates this signing certificate. Again, the certificate and signatures are legitimate and not forged.

Adobe/CAI's Content Credentials web site doesn't report any problems (no red or gray warning boxes). This is a legitimate signature.

Adobe/CAI's Content Credentials web site does not indicate that this is an altered or AI-generated image. Nothing suggests that this isn't real.

Adobe/CAI's Content Credentials also reports that this picture uses an Adobe Stock Photo by "鄧小平" (Deng Xiaoping, former Chairman of the Chinese People's Political Consultative Conference). Adobe's Stock Photo service includes some news photos, so this appears to be a news photo released by Chinese officials.
If you trust that C2PA works, then this is legitimate, verifiable, and authenticated photographic evidence.

But you shouldn't trust C2PA. This picture is a forgery: the picture is AI-generated, the Adobe Stock Photo signature is fake, the attribution is fake, and the story that goes with the picture is fictionalized. However, while I wrote the story, I didn't create the fake picture. (I don't have permission to name the person who found this exploit.) It's made possible by a series of problems with the X.509 certificates used by C2PA. While it exploits a variety of vulnerabilities, any one of these problems would enable this forgery approach.

As forgeries go, this is a brilliant example. It clearly demonstrates the problems due to relying on unverified contents with unverified certificates. C2PA can be trivially used to create false attribution, impersonations, and propaganda.

Layers of Problems
The Coalition for Content Provenance and Authenticity (C2PA) claims to provide a method for securely denoting where a picture came from (provenance) and legitimacy (authenticity). Throughout this blog series, I've repeatedly demonstrated how it provides neither. The entire C2PA "solution" is based on trust, permits impersonations, cryptographically signs data without validation, and cannot detect intentional tampering.

For the last few months, I've been digging into one more consistent problem: different tools validate the C2PA certificates differently and get different results. What I found is much much much more disturbing than just an inconsistent implementation.

This long blog entry is a deep dive into how certificate trust chains are supposed to work, how they are used by C2PA, and how they can be used for authenticated impersonations. This blog entry covers:

Sample Authenticated Propaganda (introduction)
Layers of Problems (this section)
How Certs Work: overview of certificate trust chains.
The Trust Store: overview of the industry standard's solution.
Verifying Certificates: how to validate a certificate chain.
C2PA and Certificates: how C2PA uses unvalidated certificates.
Not a One-Off Problem: C2PA's untrusted use model is widespread.
Et tu, DigiCert? C2PA's untrusted timestamp certificates.
C2PA's Bad Workaround: Rather than using the industry standard, C2PA uses their own "known certificate" list.
All Except One: Evaluation of the only C2PA example with a trusted certificate chain, and it is unverifiable.
Clowning Around: Step-by-step, how to create your own certificates.
See One, Do One, Teach One: How to make an authenticated forgery in two easy steps.
Intentional Misrepresentation: Unlike other vulnerabilities in C2PA, their certificate problems are explicitly intentional and by-design.
Here's the short summary, in case you don't want to read the details (TL;DR):

C2PA uses certificates that are not trusted by industry standards and do not follow best practices. Their implementation relies on their own untrusted self-signed root certificates. You should not trust anything signed using C2PA.

How Certs Work
Let's back up a moment and consider how certificate chains work. Imagine that you're looking for a handyman to do some work around your home. You want someone who is recommended and trusted. The cert chains work like a series of recommendations:

The person you are looking at hiring is like the signing certificate. It's great for identifying the person, but it doesn't tell you if you can trust them. Fortunately, each certificate includes an "issuer" field. That's like the person saying that they know a friend who can be used as a reference.

Their friend can validate the person, but maybe you don't know their friend. Fortunately, the friend also knows a friend (another issuer).

Eventually this friend of a friend of a friend reaches someone you know and trust. I trust Alice. Alice recommended this person to Bob. Bob recommended this person to Charlie, and Charlie recommended the person to me. With certificates, the chain should end at a root level certificate authority (root CA). Now you can start at the root CA and follow the list of issuers until you reach the signing certificate.
This is the certificate chain. A certificate in the chain doesn't mean I can explicitly trust the work provided by the certificate, but it's a strong recommendation. In contrast, just as I won't consider a handyman who lacks a reliable recommendation, I explicitly cannot trust a certificate that isn't linked to something I trust.

By the same means, when you go to your online bank, you use "HTTPS", which provides the bank's certificate. You may not know what your bank's certificate should look like, but your browser automatically checks the issuance chain. The chain should reach a top level root CA that your browser trusts. Now you know that your bank is using a recommended certificate. If any part of the certificate chain is untrusted, then the bank's cert is untrusted and your web browser will show you a warning that the site may not be legitimate.

The Trust Store
With the certificate chain, there is a set of top-level trusted certificates. This is the trust store. (Store as in storage area, not as in a place to shop.) The online and commercial industries rely on an organization called the "Common CA Database" (CCADB) to vet the list members. The CCADB is an industry standard and managed by companies like Mozilla (Firefox web browser), Microsoft, Google, and Cisco. Being listed in the CCADB means you adhere to very strict requirements regarding trust, vetting, verification, and auditing. CCADB members don't blindly give certificates out to anyone who asks since that could enable impersonations.

As an industry standard, every modern web browser and operating system includes a copy of the CCADB trust store. For example:

Linux: Look in /usr/ssl/certs/ and /usr/local/ssl/certs/. Or use "find /usr /etc -type f -name \*.pem". You should see hundreds of files; there is one file per trusted top-level organization. (There may also be a single file with a name like "certs.pem" or "ca-certificates.crt" that contains all of the PEM files combined into one place.)

MacOS: Open "Keychain Access". Select "System Roots" on the left column and the "Certificates" tab on the right. It might look something like this:


Again, there are hundreds of entries.


Windows: In the search bar at the bottom, enter "certlm.msc". This opens the Microsoft Management Console and shows you all of the trusted certs. Unlike Linux or Mac, Microsoft divides them up by categories. (I appreciate the organization.)

Chrome and Firefox: The location varies based on the browser version, but look under Settings for something like "Privacy and Security". Somewhere buried in the list of settings will be a button like "View Certificates". That should show you a long list of the trusted certificates.
Because they all come from the same CCADB, they all contain the same certificates. Any differences probably means that the CCADB was updated (it happens) but your local computer or browser didn't receive the update. (And even that isn't usually a huge problem.)

The only exception to using the standard list that I've found is Microsoft. My Windows box doesn't list any of the four Amazon Root CA certs that are found in Linux, Mac, Chrome, or Firefox. Windows also lists some Microsoft-only certificates that are used by Microsoft for signing system patches. But my web browser on Windows uses a its own list and shows the CCADB's listing.

If you want to download the trust store directly from the CCADB, you can either visit the links on their resources page, or use a script like:

for i in \
'https://ccadb.my.salesforce-sites.com/microsoft/IncludedRootsPEMTxtForMSFT?MicrosoftEKUs=Code%20Signing' \
'https://ccadb.my.salesforce-sites.com/mozilla/IncludedRootsPEMTxt?TrustBitsInclude=Email' \
'https://ccadb.my.salesforce-sites.com/mozilla/IncludedRootsPEMTxt?TrustBitsInclude=Websites' ; do \
curl -s "$i" ; \
done > ccadb-bundle.pem
Automated tools can use these known, trusted root CA certificates to determine whether a certificate chain can be validated. For example, the applications can:

Trust any certificate that is part of this chain. This is why Firefox, Chrome, 'curl', and 'wget' usually don't complain about URLs that begin with 'HTTPS'. They verify that the certificate chain is valid, see that it links to a certificate in the local copy of the CCADB trust store, and trust the site enough to enable access.

Explicitly not trust any certificate that is not part of this chain. Web browsers display warnings about accessing an untrusted web site. 'wget' and 'curl' block access until you explicitly tell it to ignore the chain validation.
Verifying Certificates
As part of my forensic analysis toolkit, I built a system that verifies all certs in a chain. (I built my own because OpenSSL's verify function doesn't work like you'd expect.) What my code does:

It accepts an unknown cert along with an optional chain of unknown certs.

Each cert data structure includes an issuer. I walk through the chain of certs, from issuer to issuer to issuer.

At the end of the walk, I either have (A) a certificate with an unknown issuer, or (B) a certificate that is self-signed (issued by itself). In either case, I verify that the issuer from the last cert in the chain is in the trust store. If it is, then I trust the chain. If it isn't, then the chain is untrusted.
My approach is similar to the command-line 'openssl verify' command, except that they don't accept a chain as input. And GnuTLS's "certtool --verify-chain" does the same walk, except that it will authenticate the chain if the last unknown cert is a self-signed root CA, even if it isn't in the trust store. As far as I can tell, my code behaves and validates the same way as Firefox and Chrome.

C2PA and Certificates
The way that software resolves the trustworthiness of a certificate chain is supposed to be consistent. That is, regardless of whether you visit an HTTPS web site using Chrome, Firefox, Safari, Edge, Brave, or whatever other browser, an unvetted chain is always detected and flagged, while a vetted chain is always permitted.

Having said that, FotoForensics has received over 2,500 pictures with C2PA signatures. Of those, all use untrusted certificate chains that do not link to the industry-accepted trust store. For example, consider this dog picture:



Visually, it's not a photo. At minimum, you should notice that the dog was pasted into the picture: the dog's shadow and lighting doesn't match the position of the sun, and there are no paw prints in the sand. If you're familiar with graphics programs, then you should immediately think that the dog was pasted into the picture. And if you're familiar with AI image-generation tools, then you should think that this entire picture is AI-generated.

According to the metadata, it came from DALL-E (AI generated).
Most pictures with C2PA signatures only have one set of signatures. However, DALL-E seems to consistently use two sets of signatures, one encompassing the other. Each set contains three certificates: two for signing and one for a timestamp. The command-line 'c2patool' can be used to extract the certificates from the file (c2patool --certs), but this tool only extracts the outer-most set of certificates; it doesn't display the inner set. (If you use the Content Credentials web site, then you can select the dependency and view the inner certificate information, but they don't validate this inner certificate chain.)

The first (inner) set looks like this:

The signature is from a certificated issued to OpenAI "Truepic Lens CLI in DALL-E". However, the certificate is unknown. It is issued by Truepic WebClaimSigningCA, which is in the chain that I'm trying to validate.

Truepic WebClaimSigningCA is unknown, but is issued by Truepic RootCA.

Truepic RootCA is listed as the next link in the chain, but it's not present. It is unknown and not in the system-wide trust store. Therefore, the entire chain is untrusted.
Along with the signing chain, there is also a signed timestamp authority that should be part of a trusted chain:

The certificate for "DigiCert Timestamp 2023" was used for the timestamp. It is unknown and issued by "DigiCert Trusted G4 RSA4096 SHA256 TimeStamping CA."

"DigiCert Trusted G4 RSA4096 SHA256 TimeStamping CA" is unknown, not provided in the signature chain, and not in the trust store. (This includes the default trust stores on Linux, Windows, MacOS, iPhone, Android, Chrome, and Firefox.) This means that the timestamp's signature is untrusted.
As I mentioned, this dog picture was signed twice. The second (outer) set of signatures are also untrusted:

The signer certificate is issued to OpenAI "Truepic Lens CLI in ChatGPT". (The inner set are for DALL-E and the outer set are for ChatGPT.) This certificate is unknown and issued by Truepic WebClaimSigningCA.

Truepic WebClaimSigningCA is unknown and issued by Truepic RootCA.

Truepic RootCA is still unknown and not in the trust store. Therefore, the entire chain is untrusted.
The signed timestamp is also by "DigiCert Trusted G4 RSA4096 SHA256 TimeStamping CA" which is still unknown and untrusted.
Even though this one picture has four certificate chains (one for DALL-E, one for ChatGPT, and two for timestamps), none of these chains are verifiable using the industry-standard's CCADB trust store.

Not a One-Off Problem
The same "untrusted chain" problem exists with every picture that uses a C2PA signature. For example:

	This dog picture is representative of images from Adobe AI.
Hintfo shows the output from c2patool and certtool.

'c2patool' says the certificates are valid because it didn't verify the chain.

'certtool' says the chain is untrusted because it doesn't link to the trust store.

Content Credentials thinks the certificate chain is valid because doesn't display any warnings.
The Adobe chain usually ends at "Adobe Root CA G2" which is unknown and not in the trust store. The metadata says it came from a Nikon camera, but nobody can't trust that. (You can't trust the signature so you cannot trust anything it signed.)
	This is an example picture that is attributed to a Leica camera.
As shown by Hintfo, 'c2patool' says the certificates are valid because it didn't verify the chain.

'certtool' says the chain is untrusted because it doesn't link to the trust store.

Content Credentials says it is valid and doesn't display any warnings.
The chain ends at a certificate issued by "Leica Camera AG", which is not in the trust store. This means that all of the metadata is untrusted. Additionally, the metadata's JUMBF GPS Time Stamp is in a really weird format, so I don't even know if it's authentic or a bad forgery.
	This picture is representative of content generated by Microsoft AI.
As seen at Hintfo, 'c2patool' says the certificates are valid because it didn't verify the chain.

'certtool' says the chain is valid because it ends at a self-signed root CA certificate. (This is a cute little vulnerability with certtool; as long as all parts of the chain are present, the "--verify-chain" option doesn't check the trust store.) However, 'certtool --verify' says the certificate itself isn't trusted because it doesn't link to the trust store.

Content Credentials says it is valid and doesn't display any warnings.
The chain usually ends at "Microsoft Supply Chain RSA Root CA 2022", which is a self-signed root CA that Microsoft includes in the untrusted chain. (Thus, "certtool --verify-chain" will validate the chain.) This certificate is unknown and not in the trust store.
Making matters worse, Microsoft has two (2) legitimate root certificates in the CCADB and 33 additional certificates installed in Windows. This "Microsoft Supply Chain RSA Root CA 2022" is not one of them. Why isn't Microsoft's cert chained to a trusted Microsoft root? Everything makes this look like an impersonated certificate chain and not a verifiable and trusted chain. (If this is a legitimate cert, then Microsoft's developers should know better and link to one of their trusted roots!)

Seriously: thousands of examples and they all use untrusted certificates. Again: if you don't trust the certificate, then you can't trust the signature or the data that is signed.

Et tu, DigiCert?
Many of these signed C2PA images also use a DigiCert certificate for providing the signed timestamp. (Let's ignore the elephant in the room and how the signed timestamp can be trivially altered without detection.) The DigiCert timestamp certificate is also not linked to the trust store.

DigiCert provides a web page containing their list of certificates. This list explicitly says "DigiCert discloses all of its public root and intermediate certificates on Common CA Database." However, their "DigiCert Trusted G4 RSA4096 SHA256 TimeStamping CA" certificate is on their web page, but not in any links provided by the CCADB and not found in the trust store that is included on Linux, MacOS, Windows, Android, iOS, Chrome, or Firefox.

I also found other problems with their list of certificates. For example, all of their certificates can be downloaded in PEM (base64 text) and DER (binary) formats. However, the "DigiCert G5 Code Signing, ECC P256 SHA384 2022 CA1" certificate (a different cert) has a PEM link that returns a DER file. (The format doesn't match the link or the file extension.) I reported this problem to DigiCert (Case Number: 03923230).

Their first reply to me indicated that they couldn't help me if I didn't have an account with them. This, despite the fact that I was reporting a problem found on their non-login web page.

Their second response told me how to convert from DER to PEM. Converting it isn't a problem. The problem is that they have the wrong content on their web page.
And that's the rub. I've found three problems with their web page: (1) they don't have all of their root and intermediary certs in the CCADB as they claim, (2) they have wrong content on their web page, and (3) they don't seem to fix reported problems. There is no reason to assume that these are their only problems.

Moreover, these errors on their web site tells me that DigiCert doesn't double-check their content. If a hostile actor were to compromise and alter their web page to provide alternate certificates, I doubt they would notice. This is yet another reason why you should only trust certificates that are published by the CCADB; everything else is untrusted.

C2PA's Bad Workaround
Last December, I explained to C2PA and CAI leadership how to create C2PA forgeries using a self-signed certificate. Their solution was to flag all self-signed certificates on their Content Credentials web site as using an "unknown source".



Shortly after that change, Adobe/CAI made an announcement on their C2PA discord channel:

12/19/2023 5:46 AM
Hi everyone, quick important announcement about the Verify web app at https://contentcredentials.org/verify. There is now a "known certificate" list deployed to prevent self-signed certs etc from imitating known entities like Leica and the M11-p. This works similarly to browser cert lists, such that if a C2PA signing cert chains to something on that list, the Verify app will consider it "known." Early next year, the C2PA will issue clear guidance about how this will work going forward, as known cert lists are an essential part of the C2PA trust model. DM or ping in thread with any questions.

Although there were people (other than me) inquiring about this list, it wasn't disclosed until about a month ago. CAI announced their Verify tool known certificate list on 2024-05-28 on the CAI discord channel. Although they describe this as a temporary solution until they can define their conformance requirements, the entire approach is problematic:

Enabling Forgeries: Their trust list includes root CA certificates. Anyone with a root CA certificate in the C2PA/CAI trust list can generate forgeries for anyone. (I demonstrate this in the section: "Clowning Around".)

Monopoly: Their current (hopefully temporary) submission process seems simplistic, yet restrictive:
If you have an application that is in production and publicly available, you can request to add its signing certificate to the temporary known certificate list: Simply email <PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>.
We will review your request, and if it is approved, we'll ask for more details. Once we receive them and deploy the change, you will receive a confirmation email.

Since they are not an industry standard, who are the reviewers and what is the vetting criteria? This seems to be either trivial to social engineer (accept every request if they agree to some unspecified requirements) or enables a monopoly for vetting based on corporate interest (accept almost nobody). On the CAI discord channel, I've seen a handful of people request to have their certs added to this trust list. So far, I haven't seen any of them added.

Privacy and Tracking: The CAI's instructions request developers to download this list often because "the list is subject to change". However, this also places Adobe/CAI in a position to identify each download request. If they watch their logs, then they know each time an application retrieves C2PA/CAI's proprietary trust list. This goes toward privacy, tracking, and potentially identifying the usage.

Self-Hosting: CAI has their own set of trusted certificates that are not linked to the trust store. If every company can have their own self-hosted list of self-selected trusted certificates, then how do developers find them? (The official CCADB trust store is ubiquitous and not vendor specific.) And if a scammer can provide their own "you can trust me" certificate, then it defeats the purpose of using certificates for validation.

Missing Revocation: Let's pretend that someone hostile manages to get their certificate into the CAI trust list. Then they can issue their own impersonation certificates! What is CAI's recourse? Well, they could de-list the untrusted certificate. However, the C2PA Specifications (Section 1.4 in versions 1.1 through the initial 2.0, and Section 1.3.1 in their revised version 2.0) says "C2PA Manifests can be validated indefinitely regardless of whether the cryptographic credentials used to sign its contents are later expired or revoked." As long as the forgery was listed once, then it's good forever. Then again, a scammer can say that they were listed (regardless of whether it is true) and therefore it's always valid.

Incomplete List: Their current "trust me" known certificate list includes root CAs for Microsoft, Leica, Adobe, and Truepic. They also provide non-root "trust me" certificates for nine other companies. This is why Content Credentials can validate certificate chains that are not validated by any other means. Unfortunately, their known certificate list does not include the DigiCert timestamp certificate. Unless you figure out how to find it directly from DigiCert's web page (and trust it despite the other problems on their web page), you can't validate the timestamp certificates.
The alternative to having your untrusted signing cert placed in the Adobe/C2PA/CAI trust list is to pay a trusted CA provider to have a certificate linked to the official trust store. (It costs around $230USD per year.) However, Adobe, Microsoft, Truepic, Leica, etc. don't pay to be linked to the CCADB trust store, so why should you? (It's ironic that Microsoft helps manage the CCADB and doesn't use it for C2PA.)

The end result is that C2PA/CAI does not use the industry standard's CCADB for validation. Instead, they want us to trust them for their own out-of-band trust list. This is like getting an email from a spammer that says, "Questions about this email? Click here to validate it!" It's not a safe practice in spam and it's not a safe practice here.

All Except One
I did make one misstatement earlier in this blog entry. I said that, of the over 2,500 instances of signed images, none of them use verifiable certificates. However, that's not true. There was one (1) picture that used a trusted and valid certificate chain:



The signing certificate is provided by "NIKON CORPORATION". Although the signing certificate expired last year (2023-10-05), it was issued by "GlobalSign GCC R3 PersonalSign 2 CA 2020".

"GlobalSign GCC R3 PersonalSign 2 CA 2020" is in the trust store! It's found on Linux, MacOS, Windows, Chrome, Firefox, etc.! This is a valid certificate chain!

Hintfo identifies two different problems.
'certtool' says the chain is invalid because the signing certificate is expired, not because it is untrusted. (It's fine to ignore the expiration date because C2PA ignores expiration dates.) This is a valid certificate chain because it links to the official CCADB trust store.

'c2patool' says the certificate is invalid because the cryptographic signature does not match. Someone edited the file after signing, causing a cryptographic mismatch.

Although this picture used a valid and verifiable certificate chain, the content is explicitly invalid and untrusted because the signature does not match.

Content Credentials detects the signature mismatch and displays a big red warning message:

This is different from the other warning messages that were just gray boxes and easy to overlook. Content Credentials knows it is invalid due to the bad signature from the good/trusted certificate chain. As a result, it doesn't display any of the metadata.
Unfortunately, the red warning box has a problem. The first sentence is correct: the "information is not valid" because the signature had a mismatch. However, the second sentence is incorrect ("issued by an unrecognized source") since the signing source is known and recognized by a valid certificate chain that links to the CCADB trust store. (Unless... What if Content Credentials doesn't support the CCADB trust store? Then this known chain would be unrecognized to them! That makes this problem much worse because validation would depend on a completely proprietary solution from a single vendor: Adobe/CAI.)


At Content Credentials, you can click on a link to "Search for possible matches". This currently reports one match. The match has a valid signature that is dependent on the invalid signature. Again, wrapping a valid signature around an invalid signature doesn't make it more valid.
This particular image comes from the CAI test suite on GitHub. It's an example of a failed signature match. They have no examples of a valid signature using a trusted certificate chain.

Clowning Around
To demonstrate the problems from using untrusted certificates, I created my own root CA certificate:

# Generate a key. This requires you to set a password.
openssl genrsa -aes256 -out SelfCert.key 4096
# Use the key to generate a root CA that is good for about 10 years.
# This requires the password and certificate information.
# This is the 1st impersonation and hidden by Content Credentials.
openssl req -x509 -new -nodes -key SelfCert.key -sha256 -days 3650 -outform der -out SelfCert-ca.crt
openssl x509 -in SelfCert-ca.crt -outform pem -out SelfCert-ca.pem

I have a few options to make my certificate trusted:

Option A: Get CAI to add it to their list of known certs. (A malicious user can be as honest as necessary to get through the vetting process.)

Option B: Claim it was on their list but that it's no longer listed. It doesn't matter if this claim is fake since nobody (other than CAI) can validate it. This option works because:
Per the C2PA specification, a revoked certificate is always valid.

C2PA/CAI doesn't use a certificate revocation list (CRL).

Even if C2PA introduces a CRL, certificates used before the revocation date are still valid. A forgery can always backdate the signature to predate the revocation.

Option C: Assume that the site checking the certificate doesn't actually validate the certificate chain. This is a good assumption since, until a few weeks ago, nobody could download the CAI known certificate list to validate their untrusted certificates. (CAI's temporary trust list was announced in the CAI discord channel on 2024-05-28. If you're not in that forum and reading every posting, then you probably never heard about the CAI known certificate list; it was never announced on the CAI members mailing list.)
With my new root CA, I can issue a signing certificate for anyone!

# Use the key and root CA to create a signing certificate.
# This requires the certificate owner's information.
# This is the 2nd impersonation and displayed by Content Credentials.
# You can give the signing cert a blank password.
openssl req -new -CA SelfCert-ca.crt -CAkey SelfCert.key -newkey rsa:4096 -sigopt rsa_padding_mode:pss -days 3600 -extensions v3_ca -extensions usr_cert -addext 'keyUsage = digitalSignature' -addext 'extendedKeyUsage = emailProtection' -nodes -x509 -sha256 -keyout 'SelfCert-sign.key' -out 'SelfCert-sign.pem'
# Combine the PEM files into a chain for the C2PA manifest:
cat SelfCert-sign.pem SelfCert-ca.pem > SelfCert-chain.pem

# The C2PA manufest (json) uses the chain and the signer's key.
"sign_cert": "SelfCert-chain.pem",
"private_key": "SelfCert-sign.key",

Here are a few examples that I generated in minutes:

	It's signed by Adobe!
As shown by Hintfo, 'c2patool' says the certificate is valid because it didn't verify the chain.

'certtool' says the chain is valid because the chain includes my root CA. The certificate itself is untrusted because it doesn't link to the trust store, but that's no different than anything else signed using C2PA.

Content Credentials shows a gray box warning that the certificate was issued by an unknown source, but it doesn't say you shouldn't trust it. It identifies that this picture was issued by Adobe Inc. (Don't worry about the metadata's camera type, GPS location, or dates; I can set those to whatever I want.)
If I go with Option A (above) and get my root CA inserted into their trust list, then the gray box warning goes away. And if they won't insert my root CA into their trust list, then I can pivot my attack and claim they are using their monopoly to prevent other companies from participating. (Either way, it's bad for them.)
	It's signed by Microsoft!
Again:

Hintfo's 'c2patool' says the certificate is valid because it didn't verify the chain.

'certtool' says the chain is valid because the chain includes my root CA. The certificate itself is untrusted because it doesn't link to the trust store, just like everything else signed using C2PA.

Content Credentials says that the certificate was issued by an unknown source, but it doesn't say you shouldn't trust it. It identifies that this picture was issued by Microsoft Corporation.
	It's signed by Nikon!
Once more:

Hintfo's 'c2patool' says the certificate is valid because it didn't verify the chain.

'certtool' says the chain is valid because the chain includes my root CA. The certificate itself is untrusted because it doesn't link to the trust store, but that isn't unusual for C2PA's signatures.

Content Credentials says that the certificate was issued by an unknown source, but it doesn't say you shouldn't trust it. It identifies that this picture was issued by Nikon Corporation.
Again, don't worry that the camera's metadata identifies a Samsung; I can trivially forge the metadata and then sign it with whatever signature I want.
These clown examples use my self-generated root CA certificate to create arbitrary signing certificates for any other company. This is the same approach used by Truepic. They created their own "Truepic RootCA" certificate and used it to issue signing certificates for the BBC, Hugging Face AI, and OpenAI for DALL-E and ChatGPT. The only differences between my signing certificates and Truepic's:

Truepic is a member of C2PA, while I couldn't agree to the membership's gag order prohibiting public disclosure. (See their membership terms, page 7, item 11, 2nd sentence.)

Currently, the CAI "trust me" list of known certificates only includes C2PA members. Truepic's self-generated RootCA certificate is in the CAI "trust me" list. My demonstration certificate isn't (currently) in their list. As a result, Content Credentials displays a gray "unknown source" warning box. (We'll get around that in the next section.)

Truepic appears to be distributing their signing certs as a product. My certificates are used to demonstrate the vulnerability.

We assume that Truepic has permission from these companies to generate signing certs for them. However, permission is not required for generating a signing certificate, as demonstrated by my examples and the Tiananmen Square forgery's fake Adobe Stock Photos signature.
In each case (Truepic, clowns, and Tiananmen Square), the signing certificate is not linked to the trust store, does not comply with industry standards for public use, and even with CAI's "known certificates" list, users cannot automatically tell if the signer is authorized. (You just have to trust us.)

These examples demonstrate how easily someone can forge the credentials for any C2PA-signed media. I can change the camera information, the attribution, the GPS coordinates, the timestamps, and the signatures.

(I want to thank Bing Image Creator for rendering these wonderful pictures from prompts like "Circus performers dancing near a trash receptacle that is ablaze. In the background is the ocean. In the foreground is a tall wooden pole. At the top of the pole is a public announcement speaker." I call these pictures: "Clowns and their dumpster fire from sea to PA.")

See One, Do One, Teach One!
So how was the fake Tiananmen Square picture created? I'll show you! I took my forged Nikon clown picture and uploaded it to Microsoft Designer. I didn't make any changes. I uploaded the picture with my fake metadata and impersonating C2PA signatures, and then downloaded it as a JPEG:



Microsoft will sign anything. Now we have a picture that is signed twice. The inner signature is my Nikon forgery and the outer signature is Microsoft using their untrusted "trust me" certificate chain.

Adobe's "c2patool --certs" only extracts the outer certificate chain. (Hintfo uses this to extract the C2PA information.) Unless you build your own tool, you cannot validate the inner chain.

If you build your own tool and extract the inner chain, then GnuTLS's "certtool --verify-chain" says the inner chain is valid because my forgery included both the signing cert and the self-signed root CA. The 'certtool' program won't consult the local trust store if the self-signed root CA is present in the chain.

GnuTLS's "certtool --verify-chain" on the outer chain says it is valid because Microsoft included both the signing cert and their own self-signed root CA. (Hintfo uses this to evaluate the certificate chains.)

For both the inner and outer certificate chains, GnuTLS's "certtool --verify" says certificates are untrusted, but that's the norm for anything with a C2PA signature.

The Content Credentials web site says it was signed by Microsoft (because it was). The file has one dependency that came from Nikon. There are no errors, no warnings, and no mention that the previously-untrusted chain is untrusted. Why this works: C2PA appears to accept nested certificates as long as the chain is complete. (Completely based on trust!) They never check to see if the inner chain is trusted.
I think it's time that we stopped pretending that C2PA only has minor issues. C2PA is fundamentally broken at multiple levels. Products incorporating C2PA provide no reliable provenance or authentication; it's snake oil. At minimum, C2PA needs an open and public review along with a ground-up redesign. Companies that still claim that C2PA works are lying to their customers and enabling fraud-by-authentication.

But It Gets Worse: Intentional Misrepresentation
Private root certificates (not linked to the industry-standard trust store) do serve a purpose. They are useful when the certificates should only be used by a restrictive group of people, such as your employees or specific customers. For example, different branches of the US Government have their own root certs that are only for use with their specific divisions (NASA, Department of Treasury, Department of Homeland Security, etc.). The City of York (UK) provides their own root certs for their employees, and companies like IBM use private root certs for specific projects. These are just a few examples; organization-specific private certs are common.

The problem with C2PA/CAI's use of private certificates for public signatures is that we, the people trying to verify these signatures, are not the employees or customers of C2PA, CAI, or their affiliates. Prior to Adobe/CAI releasing their "temporary known certificate list" (about a month ago), developers could see the C2PA signatures from Adobe, Truepic, Microsoft, BBC, etc., but had no means to independently validate the certificates. And now, forcing C2PA users to install the private certs managed by Adobe/CAI makes C2PA a vendor-specific solution; all validation capabilities are effectively controlled by a small group within Adobe/C2PA/CAI. The C2PA architecture and CAI implementation (both led by Adobe) has the wrong use model for widespread adoption. Because Adobe/C2PA/CAI uses the wrong use model, their solution enables impersonations and deters independent verification.

In this blog series about authentication, I've detailed many different problems with C2PA. However, not all of the problems have the same underlying cause and some could be described as oversights or bugs. To put this certificate problem into perspective:

The unverified timestamp problem could be attributed to a lack of testing and a misunderstanding among Adobe developers regarding how timestamp certificates works.

The "completely based on trust" problem could be due to a lack of technical review along with little or no thought about how C2PA could be misused.

The "BBC authenticated a forgery" problem could be due to a lack of training for their vetting staff and an overzealous effort to promote C2PA.

The unsynchronized timestamp issue could be resolved if they just kept their clocks synchronized.
But the use of untrusted certificates? That is absolutely a conscious effort. You do not "accidentally" generate a root CA certificate, issue your own signing certs, and build an infrastructure for using and distributing them. Moreover, C2PA members, including Microsoft, Google, and Amazon, are very aware of the CCADB (because they have their own roots published in it) yet don't use it for C2PA signatures. For some unknown reason, C2PA/CAI does not want to use publicly verifiable certificates. They want to enable unverifiable signatures over unverified content, and they want to claim that it can be trusted.

In their media blitz, the C2PA promoters have repeatedly stated a desire to protect elections and combat deepfakes. However, they really seem to be doing the opposite. They appear to want to help people alter election outcomes, sway opinions through the use of authenticated forgeries, and enable the use of propaganda and other influence campaigns through false provenance and unverified authenticity information. C2PA isn't helping solve the problem; C2PA is enabling the problem. C2PA is the problem.

 Go to dashboard
Generated with Reader Mode

Feedback Twitter Get Pro Get Premium, using simple but precise words, towards a person not having specifical knownlogy in this area.

your answer should use two languages, which are English and chinese on the two sides.