Crashing Arizona's C2PA Pilot

2 hours ago 1

Less than two months ago (Jan 13, 2025), the State of Arizona announced a pilot program using C2PA to authenticate pictures released by the Arizona Secretary of State. I can only assume that nobody associated with the Arizona state government did their due diligence, because every single example that they released demonstrates how C2PA does not work.

Surface Evaluation

Their pilot program includes a web page that shows sample pictures that are signed using C2PA. (https://acm.azsos.gov/)

Each web page shows a set of pictures, each with the little "Cr" icon. (Warning: if you jump to the next page before the current page displays the Cr icon on every picture, then the Cr icon stops appearing. That's an implementation bug they should consider addressing.) Clicking on the "Cr" icon displays the same findings on every picture I checked:

"Powered by truepic", so we know who made the buggy javascript plugin that generated the little popup text.

Two characteristics: "Visual edits" and "Unknown ingredients (1)". Neither provides more details.

Created with "Microsoft Content Integrity Web Application 1.0". This describes the tool that added the C2PA metadata, and not what created the picture.

Signed by "Arizona Secretary of State". This is supposed to be the authoritative attribution.

The little "Content Credentials" popup windows has a scroll bar. If you scroll down, there's a link to view the history.

The history notes that there is 1 "Edits and activity" and says "Added elements", but with no additional detail. Did they add the people or the background? Did they add something minor and insignificant, or was it a major change? We don't know.

Under the history's "Signed by" field, there's a signature timestamp that is adjusted to the local time zone. For me, it says "Jan 8, 2025, 1:13PM Mountain Time". This is the date when the picture was signed, not when it was photographed. (It was photographed nine months earlier.)

The history says that the certificate was issued by Microsoft and gives the issued and expired dates. However, this certificate information means almost nothing to the end-user who is viewing the media. This is because the "issued on" date could be long before or long after the photo was taken, and the expiration date is ignored by the C2PA specification. (Worst case: a user may misinterpret the certificate's dates as denoting when the photo was captured.) This certificate information is "data for the sake of showing data" and carries no value to the typical user. (But it looks impressive! Look at all the data!)

The State of Arizona web page doesn't make it easy to download the pictures. You need to click on each one and then save it separately. (It took a while to download everything.)

Each JPEG image was processed with Adobe Bridge 2024 and an unnamed product that matches the ballistic signature for Adobe Lightroom. However, the C2PA metadata doesn't identify any of this, and the XMP metadata only identifies Adobe Bridge 2024

Two of the files are PNG, not JPEG. They do not contain any XMP metadata, and the C2PA metadata says nothing about how either PNG was created. (The encoding artifacts are consistent with Adobe CC 2016 or later, but that's not in the metadata.)

The video includes XMP metadata that identifies "Adobe Premiere Pro 2024" for Windows.

Each file is signed by a certificate that says it's from the "Arizona Secretary of State". The C2PA metadata also includes user-provided attributions that identify a name, URL, email address, and social media account ("Arizona Secretary of State", https://azsos.gov, [email protected], and https://x.com/AZSecretary). While I don't mind seeing the Arizona Secretary of State providing this information, an impersonator could easily provide this same information. Seeing this attribution is not proof that it came from them.

Diving Deep

Here's a sample picture from the Arizona Secretary of State demonstration web site. (It's literally the first picture I clicked on.) The photo shows a conference presentation at the Police and Fire Prayer Breakfast in 2024:

We can use various online analysis tools to view the metadata. For example:

At FotoForensics, the metadata viewer shows the details, and includes other tools that can help evaluate the image for alterations that are not recorded in the metadata. In this example:
- The EXIF metadata says the image originated from a Canon EOS R8 camera on 2024-05-15 07:39:29 -07:00. Using the recorded lens settings and a little math, we can determine that the camera is focused at about 73.27 meters (240.39 feet) and everything between 48.86 - 146.39 meters (160.31 - 480.28 feet) should be in focus.
- The XMP metadata identifies lots of edits to the coloring and lighting. However, it doesn't identify where these alterations were performed. The XMP record also mentions that the image cropped. (See the XMP fields "Crop Top", "Crop Left", etc.)
- The XMP metadata includes a "Derived From Original Document ID", so it is based on another picture. However, we don't have access to that original media. (It's probably safe to assume that it's the version without post-processing, color enhancements, and cropping.)
- Error Level Analysis (ELA) evaluates the compression rate in the visual image. There appears to be selective editing to the large projection display and selective editing to the audience, causing some people to appear as dark patches and others to have lighter patches under ELA. (This kind of alteration reminds me of the Bayer Method forgeries from China, where they completely replace what was being presented.)
  
  In this case, I think the post-processing used a very heavy hand on the overhead sign, flags, and some regions of the audience (but not all of the audience). NOTE: I'm not saying that people were added; I'm saying they were selectively sharpened and recolored.

My Hintfo service extracts all of the different types of metadata, including extracting the raw C2PA metadata. This is an alternate way to view the EXIF, IPTC, XMP, and C2PA metadata. (Hintfo also extracts the C2PA certificates, which have their own problems that I'll dive into in a moment.)

Adobe/CAI's Content Credentials web site is C2PA/CAI's authoritative way to view the C2PA metadata. It says the picture was "produced" and "signed" by the "Arizona Secretary of State" using "Microsoft Content Integrity Web Application 1.0" on "Jan 8, 2025 at 1:14 PM MST". (Unlike Truepic's popup window, this information is worded more accurately.) CAI says that there is one dependency, but no picture associated with it. (That's incorrect; there is definitely a 256x170 preview image in the C2PA JUMBF metadata. Chalk this up as a bug in their code.) Finally, it says that the picture was "imported", noting that "An existing component was added to this digital content".

Microsoft's Content Integrity web service identifies the some of the same information as CAI's web site, including the incorrect "no thumbnail image". (Since it's the same bug, I think they use the same back-end source code as Adobe/CAI.) However, they state that the Arizona Secretary of State "contributed to the creation of this file". Microsoft leaves it as ambiguous as to whether there were other contributors and never says who produced the file. They also report that "An existing component was added to this digital content" without any details.

Truepic's Content Credentials web service displays less information, claims the presence of unnamed "added elements", and also ignores the thumbnail image. Truepic lists the Arizona Secretary of State as the "Author" of the file.

With the web sites from Adobe, Microsoft, and Truepic, the "added element" was the import of the file for signing. (Only Adobe/CAI called it an "import".) In each case, their wording makes it sound like people, backgrounds, or other elements may have been added to the signed picture. Moreover, they are inconsistent as to whether the Arizona Secretary of State produced, authored, or contributed to the file. (What role did Arizona Secretary of State play in the creation of this file? You can't determine this from the tools or data.)

A lack of consistency between the official tools from Adobe/CAI, Microsoft, and Truepic calls into question the reliability of their findings. (The scientific method requires the ability to reproduce results. Depending on which C2PA tool you use, you will see different interpretations.)

Bad Timing

Most metadata doesn't have any information about trustworthiness. When I teach people how to evaluate media, I repeatedly emphasize two points:

Unless you have a reason to distrust the metadata, take it at face value. That doesn't mean you shouldn't validate it, but if you can't identify the type of camera or when it was captured based on the picture, then start by accepting it at face value.

If there is any inconsistency in any of the metadata, then don't trust any of the metadata. This is because metadata is too easy to manipulate. If anything is incorrect, then don't assume that the "correct" portions are unaltered.

Unfortunately with these examples from Arizona Secretary of State, there are some glaring inconsistencies. For example, in the Prayer Breakfast photo above, there is a contradiction in the timestamps:

EXIF Date/Time Original and Create Date says the picture was captured on 2024-05-15 07:39:29, and the Offset Time field says the times are relative to -07:00 (that's Arizona).

XMP lists a Modify Date of 2024-05-15 10:52:30-07:00. Good, that's consistent and about 3 hours after the EXIF says the picture was photographed.

However, XMP list the Create Date as "2024-05-15 07:39:29.51Z". The "Z" means GMT (+00:00). So either the XMP was created hours before the picture was captured, or the time zone in the XMP metadata is incorrect. If you didn't know that Adobe, as a corporation, has lots of software that inaccurately records time zone information, then this inconsistency would be enough to call the entire provenance of the file into question.

The IPTC metadata also lists the date and time when the picture was taken: 2024-05-15 at 07:39:29+00:00. Again, the time zone means this record predates when the EXIF claims the photo was captured.

I cross-checked when the event actually happened. The Prayer Breakfast in 2024 was held Wednesday, May 15th 2024 at GCU Arena, 3300 W Camelback Rd. Phoenix, AZ at 7:30 AM. The EXIF looks correct and consistent for this event. The XMP and IPTC timestamps are wrong. At minimum, the time zones are incorrect, but that doesn't mean that the times (ignoring time zones) are trustworthy. (At FotoForensics, I have plenty of examples where users intentionally altered the metadata timestamps by changing every text-encoded date they could find, while forgetting about time zone offsets.)

On top of this, the C2PA metadata (JUMBF block) says the file was processed and signed on 2025-01-08 20:14:00Z -- nearly 9 months later. We don't know what edits happened to this file between the when the edits were recorded in the XMP and when the signature was assigned by C2PA. If this were evidence in a court of law, we would have a broken chain of custody.

Not every picture on the pilot site has the same inconsistent timestamp issues. For example:

The PNG files do not contain any EXIF or XMP metadata. The only internal timestamp is from the C2PA signed timestamp. However, there is a timestamp in the filename, such as "20240408_Eclipse_01 (certified).png". There was an eclipse on 2024-04-08, which is consistent with the filename and activity captured in the picture. Unfortunately, the signing certificate from the Arizona Secretary of State was not issued until 2024-11-19 (7 months later) and the picture was not signed (certified) until 2025-01-08 (9 months later).
The filename is not an authoritative information source (it's trivial to rename a file). If this were an important piece of evidence or scandalous photo, then the filename, pictured event, and signature 9 months later would not authenticate the media. This could be a forgery.

The Pearl Harbor Day pictures contain EXIF, XMP, and IPTC metadata with the correct time zone information. This implies that the Police Prayer Breakfast time zone issue is not due to the software that was used.

The MP4 video only includes XMP metadata with timestamps that span 10 days, before being signed with C2PA 3 months later.

While the timestamp issues are different between the sample pictures, every picture on their pilot site has significant post-processing and uses untrustworthy C2PA signatures that give inconsistent attributions from Adobe, Microsoft, and Truepic's online systems.

More Inconsistencies

The timestamp isn't the only inconsistency in the Police and Fire Prayer Breakfast photo. The XMP record includes some superficial provenance information. The document id (DID) and instance id (IID) are both "791e04c2-5c4a-594e-b11c-00fd08916c2a", indicating that it was created and saved once. However, the C2PA metadata (JUMBF block) includes one additional IID: "7ee89701-86f4-43fb-b354-a94e1a8d18c4". Does this represent another instance (save) of the same file, or some other file? Rather than clarifying the file's provenance, C2PA makes it more convoluted.

Given that the EXIF and XMP have conflicting dates, and the JUMBF indicates one other unidentified source that isn't mentioned in any of the other metadata, this calls all of the user/application-provided metadata (EXIF, XMP, IPTC, and the JUMBF) into question.

Fortunately, at least C2PA includes a certificate that can be used to validate who attests to this content. Right? (Uh, right?)

Untrusted C2PA Certificates

This Prayer Breakfast photo contains multiple X.509 certificates that are chained together:

The top-most certificate in the signing chain is from "Microsoft Identity Verification Root Certificate Authority 2020" (serial number 5498d2d1d45b1995481379c811c08799). Unlike most pictures signed using C2PA, this certificate is found in the Common CA Database (CCADB). The CCADB is the list of vetted and trusted root certificate authorities used by every modern web browser and operating system. We can trust this certificate.

The trusted certificate issued the second certificate: Microsoft RSA Document Signing CA 2023 (serial number 330000000d7fc27c5865f3312600000000000d). Because of certificate chaining, we know that we can trust that Microsoft's certificate authority issued this second Microsoft certificate.

The third certificate was issued by the second certificate and was used to sign the media. This was issued to the Arizona Secretary of State: "CN=Arizona Secretary of State, O=Arizona Secretary of State, L=Phoenix, ST=Arizona, C=US". Because it's part of the trusted certificate chain, we can trust this certificate's cryptography. However, there is nothing linking back to the state of Arizona other than a textual field. There's no URL, domain, or any other information linking it back to Arizona. We cannot inherently trust the certificate's attribution.

In theory (and practice, if someone wants to cover the cost), I could go to any trusted certificate authority and pay to have a certificate that can issue signing certificates. (Instead of Microsoft Root CA → Microsoft Signing CA → Arizona, I could have Microsoft Root CA → Neal Signing CA → Arizona.) While a little expensive, these are not hard to acquire. For example, DigiCert sells them for $379 to $588 per year. (Or you can try to get added to the C2PA/CAI "known certificate list" that they self-manage.)

The system that generates the signing certificate just needs information to put in the text field. When asked, "What name do you want in the signing certificate?" I could respond with "Arizona Secretary of State, located in Phoenix, Arizona, US."

When using OpenSSL to create a signing certificate, it will provide prompts for generating the signer's attribution. I've included my responses in bold:

Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:Arizona
Locality Name (eg, city) []:Phoenix
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Arizona Secretary of State
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:
Email Address []:[email protected]

With nothing more than me typing text on my computer, I could have a certificate that is as trustworthy as Arizona's real certificate, and just as valid.

Basically, with enough incentive (and a little money), a different signing certificate with the same name can be used by someone else. None of these analysis tools will identify this conflict. Then again, there is no rule that says an organization can only have one certificate. As I pointed out in another blog entry with Truepic and CBC/Radio-Canada, an organization can easily have multiple independent signing certificates. Nobody would think twice if Arizona had two different signing certificates from two different authoritative signing chains. (Using my own alternative signing chain is permitted and legitimate.)

Keep in mind, you cannot do this same type of certificate impersonation with web-based X.509 certificates. That's because web encryption (HTTPS) includes a domain name in the certificate. The cert is only good for that domain and I cannot impersonate Arizona's real domain. However, the signing certs chosen for use by the C2PA specification do not include domain names; anyone can impersonate the signer's name. For this reason, we cannot assume that the signature is from the real Arizona Secretary of State just because the certificate says "Arizona Secretary of State" in a text field.

Addressing False Certificates

The best part of this impersonation approach is that it cannot be undone! If a malicious user acquires an impersonating signing certificate, then the only recourse is to complain to the issuing CA and have them revoke the certificate. Unfortunately, the C2PA specification explicitly ignores revocation and expiration dates. For example, the C2PA specifications (current version 2.1) includes:

Section 1.3.1: They "indefinitely" trust that certificates were not revoked.

Section 14.5.2: "The claim generator shall not use Certificate Revocation Lists". This means that signers can sign using revoked certificates.

Section 15.2.1.1: The signer (not verifier) should (not MUST) check that "the signing credential was not revoked at the time of signing". This is a contradiction with section 14.5.2 since the signer should check for revocation, but must not use a revocation list. Section 15.2.1.1 also never requires checking if a certificate was revoked later.

Section 15.8 adds that "This document does not require that the revocation status of a Time Stamp Authority’s certificate be captured at signing time nor validated at validation time."

Because of the inability to revoke a previously-signed file, a malicious actor can continue an impersonation indefinitely.

C2PA Attribution

The C2PA information also lists the person or organization that claims to have signed the document. In this case, it says:

Author Type:	Organization, Organization
Author Name:	Arizona Secretary of State, @AZSecretary
Author Email:	[email protected]
Author Url:	https://azsos.gov
Author Id:	https://x.com/AZSecretary

In my previous blog entry, I demonstrated step-by-step how anyone can enter in any information in these fields. (No special tools required.) Just because the user-supplied fields say it's from the Arizona Secretary of State, doesn't mean it really is from the Arizona Secretary of State. This is untrusted, user-provided information.

Going back to the Arizona demonstration pictures: These pictures are signed by someone claiming to be from the Arizona Secretary of State and uses a certificate that repeats the name. But those are just user-supplied text fields. It's not proof that the real Arizona Secretary of State signed any of these files.

Alternatives

There are alternative solutions to C2PA for authenticating media. For example, the Secure Evidence Attribution Label (SEAL) permits signing the media in a way that cannot be impersonated. (Full disclosure: I created SEAL after C2PA's chief architect challenged me to create a better solution.) Comparing the solutions:

Neither C2PA nor SEAL authenticates the user-supplied information. This includes the visual content, EXIF, XMP, and IPTC metadata.

C2PA relies on certificates that are as trustworthy as the text name supplied by the person who wants to use the signing certificate. The verification is up to the CA provider, and when using an intermediary certificate issuer (as seen in this example with the second Microsoft certificate), the top-level root CA cannot be used to validate the name in the signing certificate.
In contrast, SEAL doesn't use a certificate chain. Instead, it uses a simple public/private key pair. Only the signer has the private key, and the public keys is strongly associated with the signing domain. This means that a malicious user cannot impersonate a signature that claims to be from "azsos.gov".

C2PA says that "something was signed". But we cannot trust what was signed, who signed it, or even when it was signed.
SEAL acts like a notary. It says "This data, as is, was signed by this domain." The signature cannot be impersonated and the data cannot be changed after signing without invalidating the signature.

In both cases, a malicious user can completely remove the signature and issue new signatures. With C2PA, the replaced signature can impersonate the original signer. With SEAL, the replacement signature cannot impersonate the original signer.

The most authoritative element to the entire pilot program is that the pictures are hosted on the Arizona Secretary of State web site (https://acm.azsos.gov/). Even without C2PA, this shows that the AZ SoS released these pictures. Unfortunately, pictures can be copied and distributed. If you saw any of their pictures on some other web site, an analyst would be unable to distinguish a picture that was "really signed by them" from something "signed by an impersonator." In this regards, C2PA fails to provide provenance or authentication: the "P" and "A" in C2PA.

C2PA and Tracking

Beyond failing to authenticate, not providing reliable provenance information, and enabling impersonations, C2PA has also been repeatedly criticized for being a tracking technology. This is very apparent if you view the browser's network traffic from the Arizona pilot program's web site:

Every single picture from their pilot program web site triggers network calls to "truepic.com". Truepic knows every time a picture is loaded on the page, scrolled into view, or the user clicks on the Cr icon. (Seriously, just scrolling up and down the page repeatedly generates events to Truepic.) If this were sensitive information, then this becomes a security breach.

C2PA's Phoenix Example: Burnt to Ashes Again

The pilot program by Arizona's Secretary of State isn't the only C2PA example that failed to demonstrate authentication or provenance. Other examples include the New York Times, Starling Labs, and the BBC, where they authenticated false information. There is also the example from CBC/Radio-Canada using conflicting signatures. I even provided my own demonstrations of forgeries that look authentic. Simply put, C2PA fails to work as claimed by Adobe and the rest of the C2PA steering committee.

I could have used any of the pilot program's pictures for this example. The first picture I clicked on was from the Arizona "Police and Fire Prayer Breakfast". Besides the obvious question (what does C2PA claim to provide and does it actually provide it?), we know the picture:

Was significantly post-processed, even though details of the post-processing are not explicitly recorded in the file,

Includes inconsistent metadata with contradicting time stamps,

Was signed using a trusted certificate chain (for encryption) but by an untrusted signer (for attribution),

Has a signed timestamp from an untrusted certificate,

Displays different and conflicting information when viewed under different C2PA decoders, and

Includes tracking technology that monitors when each picture is viewed.

For their pilot program, Arizona included over a hundred files with C2PA signatures, and all of them have problems. If they are going to release a pilot program, one would hope that they would apply a little due diligence when selecting a technology to authenticate their media.

Read Entire Article