you will summary 

C2PA and the CBC
Friday, 9 August 2024
Given all of the known and demonstrated problems with C2PA, I'm actually surprised that companies are continuing to promote, adopt, and deploy this already discredited signature system.

Last month, the International Press Telecommunications Council (IPTC) praised the work of their Media Provenance Committee for fully embracing C2PA. Keep in mind, this is the same group where I (1) presented on C2PA's limitations, and (2) gave a live demonstration (YouTube) that showed how to undetectably alter an authenticated file in under one minute using nothing more than hexedit. (It's been 3 months since that presentation, and all of those problems still exist.)

In the IPTC announcement, they mentioned that the committee is headed by Bruce MacCormack of CBC / Radio Canada and linked to an example article from CBC / Radio Canada. I wasn't aware of this media organization's example, so I took a closer look at it.

TL;DR: Not only does CBC / Radio Canada not authenticate the photo's provenance or authenticity, they introduce contradictions, demonstrate many of C2PA's problems, and illustrate the reasons that C2PA cannot be trusted.

The CBC / Radio Canada Demonstration
On May 6th, CBC published an article with a sample image that includes C2PA metadata: "India's Hindu nationalists are petitioning courts to tear down mosques and replace them with temples". (Keep in mind, I'm not interested in the content of the article. I'm only focused on the authenticity and provenance of the image.) While the article contains many photos, only the third one contains C2PA metadata:


(Screenshot from IPTC's report about CBC.)

The caption says "Tight security surrounds the Gvanvapi mosque in Varanasi and has ramped up during India's general election, in which Prime Minister Narendra Modi is running for a third term. (Salimah Shivji/CBC)". Below the caption is a link to "Learn more about this image". The link goes to the Adobe/CAI "Content Credentials" web site, which shows:
Content Credentials displays no flags or warnings. There is nothing to indicate anything altered or suspicious. While I've previously detailed a few ways around these alerts, let's start with the assumption that this is correct, at least until we identify something inconsistent.

The C2PA signature was issued by "CBC/Radio-Canada". If you already trust CBC, then there's no reason to doubt their signature. And if you don't trust CBC, then their "valid" signature doesn't add any additional confidence. (Personally, seeing that the picture is hosted on their web site gives me more confidence that they provided the picture than the C2PA signature.)

The source filename is supposed to be "mosque_signed.jpg". This is not a standard filename format from a digital camera or known application; this is a renamed file and we don't know who renamed it, when it was renamed, or why. Fortunately, the filename is only important when it includes something like a timestamp or denotes a specific device; renaming a file is typically not suspicious.

Content Credentials reports that the picture was produced by "Salimah Shivji/CBC".

The picture has a "capture date" of "Apr 20, 2024 at 9:18 PM MDT". Content Credentials shows the date in the local time zone and I'm in MDT (GMT-06:00). This is Apr 21, 2024 at 3:18 AM GMT, or Apr 21, 2024 at 8:48 AM at the Gvanvapi mosque (GMT+05:30).

And that's a problem.

According to Google Maps, the photographer is facing south, the day is overcast but the sunlight on the two towers in the background is coming from the west. That means it is afternoon and not morning. The reported timestamp is inconsistent with the photo.
There is no other informative metadata. No camera make/model, no lens settings, or any other information. (Something stripped out the source metadata.) Other than displaying the file's timestamp (which appears to be incorrect) and source filename (which was renamed by some unidentified person), the Content Credentials web site provides no additional information.

For this picture, the provenance is limited to the attribution ("Salimah Shivji/CBC") and association with CBC/Radio-Canada, which were already known from the article. In effect, the "learn more about" information provided by Content Credentials is redundant at best for CBC's example. (In the next sections of this blog entry, I'll show how CBC contradicts themselves and discredits what little information this C2PA record provides.)

Finding a Better Source
If you right click on the picture in the article, then you can find the direct URL to the image:
https://i.cbc.ca/1.7193657.1715193035!/fileImage/httpImage/image.jpg_gen/derivatives/original_1180/security-near-gvanvapi-mosque.jpg
Here's the image. If you click on it, you'll see the metadata at FotoForensics:



This version of the picture is 1180x663 pixels and contains no informative metadata. It doesn't even contain the C2PA metadata. Media outlets often strip out metadata and re-encode the file at a lower resolution in order to conserve bandwidth and speed up web page rendering. (Why bother sending a 4240x2384 image when the browser's going to scale it down to 620x348? Companies can lower the bandwidth, storage, and processing overhead by sending a smaller image instead.)

Also, notice how the dimensions match the information in the URL: the image is 1180 pixels wide and the URL says "/derivatives/original_1180/". This is probably triggering some real-time image processing that scales the image and strips out metadata.

Bigger!
The article's link that submits the picture to Content Credentials includes a different URL for this picture. According to the CBC's article, this is the "authenticated" version with the C2PA metadata:
https://i.cbc.ca/ais/ce31e387-15e3-400b-aa5f-0458953e3567/full/max/0/default.jpg&imbypass=true



This version of the picture is 4240x2384. While it lacks EXIF or other common metadata fields, it includes the C2PA metadata block. Using a combination of Adobe's "c2patool", GnuTLS's "certtool", ExifTool, and my own forensic tools, I can extract additional information from this file that is not available at the Content Credentials web site:
The C2PA data includes two X.509 certificates:

CBC/Radio-Canada, s/n 3F54755A4E3DAB8A1D8802F9A23081E53BAF35A2 (expires 2025-04-30 13:37:11 GMT)

Truepic, s/n 69FC90C4CC8950823A1EA85FD282FF28D5FD9390 (expires 2026-12-08 20:39:45 GMT)

The CBC certificate was issued by the Truepic cert. The Truepic cert is not in the global trust store and is therefore not trusted. (It is known by Adobe/CAI's non-standard trusted certificate list, but that has other problems.)

Buried inside the C2PA metadata is a JSON block that contains timestamp information:
[exif:DateTimeOriginal] => 2024-04-21T07:18:05Z
[exif:OffsetTimeOriginal] => -04:00
[exif:TimeZoneName] => America/New_York
This says that the photo was captured at a different time than reported by Content Credentials. (Content Credentials is off by four hours.) This is an implementation bug at the Content Credentials web site; they applied the time zone offset in order to compute GMT, even though the "DateTimeOriginal" was already in GMT (as denoted by the "Z" after the timestamp).

According to the actual metadata, the picture was captured at 07:18:05 GMT, which is 12:48:05 PM at the mosque in India. Now the time matches the sunlight coming from the west. However, we still don't know anything about the camera.
This larger version of the picture has a couple of other oddities, including:
The compression rate (ELA) shown at FotoForensics is really dark, suggesting multiple resaves.

Visually, there's something weird about the text on the signs in the middle of the photo. Here's a closeup of this region:



The white sign on top is blurry, but the orange sign below it is crisp and the awning next to the sign is crisp. There is a slight angle between the camera lens an each sign, causing a little change in the distance to the lens (on the order of a few centimeters). This is not a significant change in the distance. I can't explain how two items that are effectively at the same focal distance have different blurs. With this photo, there's also:

Another sign in the photo's lower-left corner (much further away from the camera).

Some fancy brickwork on the far left goes from the bottom to the top of the image.

Both of these elements are much further from the camera but not as blurry as the white sign. Perhaps a photographer can explain how the white sign could appear more blurry than everything around it without resorting to some kind of photo manipulation?
While we've answered the question about the inconsistent lighting vs time (Contents Credentials has a bug and is reporting the wrong time information), we now have new questions about the image's authenticity.

BIGGER!
The article's picture and Content Credentials analysis use two very different URLs to access the picture. Out of curiosity, I removed the re-encoding directives from the article's URL. I was hoping that it would return the original without the real-time re-encoding.
CBC used this URL:
https://i.cbc.ca/1.7193657.1715193035!/fileImage/httpImage/image.jpg_gen/derivatives/original_1180/security-near-gvanvapi-mosque.jpg

I changed it to this URL:
https://i.cbc.ca/1.7193657.1715193035!/fileImage/httpImage/security-near-gvanvapi-mosque.jpg
This modified URL returns an image that is 1280x720. However, it still lacks any informative metadata and is really low quality (dark ELA) from the post-processing.

The URL used by Content Credentials includes one other option: "imbypass=true". This suggests that it can be used to bypass the real-time image processing. So, I tried it:
https://i.cbc.ca/1.7193657.1715193035!/fileImage/httpImage/security-near-gvanvapi-mosque.jpg?imbypass=true

Keep in mind, non-technical users are probably never going to access this URL. (But content scanning bots, Google, and people looking for source images are likely to find it.) As it turns out, it's a valid URL for the picture!



Bingo! This is the full-sized image (4240x2384), complete with EXIF, MakerNotes, and other expected metadata fields. It also includes C2PA metadata!
Content Credentials says the file has a valid signature issued by CBC/Radio-Canada. There is no indication of alteration or other problems with this file.

The Content Credentials web site says the file is named "Gyanvapi mosque seen through security barriers_2024_05_08-01_53_13_PM_signed.jpg". (The web page truncates it to "Gyanvapi mosque seen through...", but you can see the full name if you hover your mouse over the text.) This is a different name from the authoritative image that lacks metadata. And yet, because it has metadata and a valid C2PA signature, it appears to be more authentic.

Content Credentials says the picture is from "May 8, 2024 at 11:53 AM MDT" (That's 2024-05-08 at 5:53 PM GMT, and 11:23 PM in India.) This comes from Truepic's X.509 timestamp authority.

Wait, that's a problem! Not only does this say that the picture was taken at night, it says it was taken over 2 weeks after the authentic C2PA credentials referenced in the article! This is not due to a bug at Content Credentials; the timestamp in the signed C2PA metadata differs by weeks. Moreover:

The CBC article is dated May 6th, so this picture was signed over a day after the article was published.

When you download a file from a web server, the server often provides the file's timestamp that denotes when it was placed on the server. This file was last modified on 2024-05-08 18:31:18 GMT. That's about 40 minutes after the file was signed (and three months before I accessed it). This supports the observation that it was created after the article was published.

These timestamps strongly suggest that CBC was testing different signing techniques before and after the article came out. These different signing techniques are no different than the methods used to create authenticated forgeries.

The EXIF metadata (shown by FotoForensics) says that the picture was photographed on 2024-04-21 at 16:48:05 +05:30. That's nearly 5 o'clock PM in India. This might match the lighting direction. (I'd expect longer shadows, but at least the sunlight is coming from the right direction.) However, it doesn't match the timestamp reported by CBC (off by 4 hours) or in the file's C2PA metadata (off by 2 weeks).

The EXIF metadata says it's from a SONY ILCE-7SM3 camera. This camera does support in-camera C2PA signing. However, this also has a problem!

There's a signed timestamp certificate that says the file was signed on 2024-05-08 17:53:13 GMT. This is the date reported by the Content Credentials web site. Assuming nobody intentionally altered this date (which is trivial to alter), this means it wasn't signed at the time it was photographed. (And I want to re-emphasize that I didn't create this picture; I found it on CBC's web site.)

The signed C2PA "Title" field includes a timestamp in the filename: "Gyanvapi mosque seen through security barriers_2024_05_08-01_53_13_PM_signed.jpg". This shows yet-another date: 2024-05-08 at 1:53:13 PM. If it was signed weeks earlier, then someone postdated the timestamps. More likely, the trusted C2PA signatures were added weeks after the photo was captured. (I have no explanation for the difference in hours. This was probably a manual signing effort to impersonate a trusted image.)

Given that the filename's timestamp and signed timestamp only differ by hours (four hours off), this suggests that someone is intentionally playing with the timestamps.

If the Sony ILCE-7SM3 permits signing a picture at an arbitrary time after it was photographed, then that enables fraud. A scammer could easily copy a new photo onto the device and use the camera to sign it as if it were authentic.

The alternative is that the Sony ILCE-7SM3 didn't sign this photo and something else signed it (weeks later).

Unfortunately, C2PA doesn't help us identify which case is correct (signed by camera, signed by something else, signed with altered timestamp, etc.) or even if none of these are correct. All we can be certain of is that there's an "official" authoritative signature that appears to have been added weeks after the photo was initially captured and over a day after the article was published.

The C2PA data includes two X.509 signing certificates:

CBC/Radio-Canada, s/n 25F29DB1D088F09218DC655224BEC8970E6955C1 (expires 2025-04-30 15:42:47 GMT). This is a different serial number and different expiration date compared to the authoritative cert provided by CBC's article.

Truepic, s/n 69FC90C4CC8950823A1EA85FD282FF28D5FD9390 (expires 2026-12-08 20:39:45 GMT). This certificate was also used for the other "authenticated" signature. So at least we can determine that this Truepic cert was used to issue both of the different CBC certificates.

Truepic's untrusted root cert appears to have issued two different signing certificates to CBC/Radio-Canada. One was used for the "authoritative" image that isn't authoritative, and the other was used for this camera "original" image that isn't original.

The EXIF metadata includes lens setting information, including aperture and focal length settings. According to this data, the camera is focused at 7.34 meters (24.08 feet). Everything between 4.90 - 14.60 meters (16.08 - 47.89 feet) should be in focus. Everything else should be blurry. The distant background should only be a little blurry. Again, nothing explains why that white sign is blurrier than the content around it. This also doesn't explain why the ELA is darker than expected for a camera-original photo.

The MakerNotes may have a few answers. This metadata identifies alterations, including manual changes to the Sharpness Range and Clarity.
This picture has more original-looking metadata than the "authoritative" version from the CBC article. It also has a CBC signature. However, it doesn't have consistent timestamps and the metadata contradicts the article's authoritative version and visual content.

If I exclude the C2PA metadata block (and its associated inconsistencies), then the rest of the metadata matches what I would expect from a Sony camera with in-camera post-processing. Even the JPEG encoding ballistics matches the SONY ILCE and ILME family of cameras; no other camera manufacturer uses these same encoding parameters. (FotoForensics has over 7 million pictures. There are about 200 instances of this specific JPEG encoding method and they all come from SONY cameras. This is a strong argument that the file without C2PA metadata is from the camera.)
Without C2PA, a forensic examiner will likely take the metadata at face value, see the consistent encoding ballistics, and conclude that this is likely a photo from the camera. (Even the blurry white sign may not be considered suspicious.)

With C2PA's metadata information, we have contradictions that bring everything about this picture into question.
C2PA doesn't help authenticate or establish provenance for this picture. Instead, it highlights inconsistencies and problems introduced by the C2PA data.

Clear as Mud
This picture seems to have a convoluted history:
The photo was taken (likely on 2024-04-21 16:48:05 in India, assuming we trust the EXIF timestamp).

The image was manually adjusted in-camera.

One version of this picture (containing "original" metadata) was signed using C2PA about 2 weeks after it was captured. However, the C2PA signature includes an inconsistent timestamp. From a technical standpoint, there is no difference between an accidental signature with the wrong timestamp and an intentional forgery with altered metadata.

A different variation of the picture (an "authoritative" derivative) was signed with C2PA using a different certificate. This version of the picture has no metadata. It was signed on an unknown date and the timestamp may have been backdated. Again, this is technically no different than a forgery.
On top of this, Adobe, CAI, and CBC seems to have confounded the authenticity problem by changing timestamps and screwing up the time zone offsets. I suspect that a non-technical user could never straighten out this Gordian knot. If this were a political photo, controversial picture, courtroom evidence, or part of some propaganda effort, then it gives plenty of room for conspiracies and doubt!
When was it taken? Either it was taken at the wrong time of the day or it was taken at night or it was taken in the afternoon or it was taken in the early evening. Or maybe, if they dig up that BIGGER image and use non-Adobe tools, then they might see the right time. But is it the right time? With all of these contradictions, we have nothing that authoritatively tells us when it was photographed.

Was it really photographed by Salimah Shivji/CBC? That name only appears in the "authentic" picture's C2PA metadata (which lacks EXIF and other metadata). It's not in the "original" version that includes camera metadata. This means that we have two different signed pictures with competing claims of ownership!

News outlets often permit limited alterations. However, localized alterations are usually forbidden. Was that white sign altered? Were other parts of the picture altered? We don't know what happened during that two week period. (And that's assuming we trust the signatures.) In any case, there is no notation in the C2PA metadata denoting any alterations or even saying that this came from a camera.

We have two different signing certificates associated with CBC / Radio-Canada. Is one of them real? Are both real? Was one revoked? (C2PA doesn't support revocation.) Could there be even more signing certs? Could CBC have certs that are not issued by Truepic? If a regular user saw yet-another CBC certificate, would they be able to tell if it was real or a forgery? C2PA does not enable any method to distinguish a real signature from an impersonation.
If you still believe that C2PA works, then look at this CBC example. We have two authoritative pictures from the same company (CBC / Radio-Canada) that have conflicting metadata, different signatures, different attributions, and inconsistent timestamps. The CBC's example image does not demonstrate authentication; it demonstrates how to make a forgery and add doubt into media reports since the contradictions have undermined any provable provenance.

Only Takes One
With CBC's "proof that C2PA works", we have two contradicting signed files that demonstrate how it doesn't work.

But let's pretend that we only have one signed picture (this picture or any other picture) that uses C2PA metadata from the CBC (or the BBC, New York Times, or other media outlet). Even if there are not glaring inconsistencies, can you be certain that the C2PA information is authoritative and includes accurate information? The answer is "no" because C2PA does not validate content, does not ensure that the signer is using the correct certificate, and does not deter forgeries. Having only one C2PA-signed file does not mean that the signature or signed contents must be legitimate.

C2PA is fundamentally broken. This is not a software bug; this is an architectural design flaw. C2PA trusts that the person inserting the metadata is honest and accurate. With the CBC, we have incorrect timestamps, contradicting metadata, and two different 'authenticated' signing certificates -- all from the same company! There's no need for me to manufacture a forgery to create distrust since the CBC has already done that.
Read more about Authentication, Forensics, FotoForensics, Image Analysis, Mass Media | Comments (3) | Direct Link, 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.