C2PA’s Time Warp

Throughout my review of the C2PA specification and implementation, I’ve been focused on how easy it is to create forgeries that appear authentic. But why worry about forgeries when C2PA can’t even get ordinary uses correct?

Just consider the importance of the recorded timestamps. Accurate time records can resolve questions related to ordering and precedence, like “when did this happen?” and “who had it first?” Timestamps can address copyright assignment issues and are used with investigations to identify if something could or could not have happened.

At my FotoForensics service, I’ve seen an increase in pictures containing C2PA metadata. They have come from Adobe, Microsoft, OpenAI (and DALL-E), Stability AI (Stable Diffusion), Leica (camera company), and others. Unfortunately, with more images, I’m seeing more problems — including problems with timestamps.

I typically use my FotoForensics service for these analysis blog entries. However, this time I’m going to use my Hintfo service (hintfo.com) to show the metadata. I also want to emphasize that all of the examples in this blog entry were submitted by real people to the public FotoForensics service; I didn’t manufacture any of these pictures.

Out of Sync

I first noticed the problem with Microsoft’s AI-generated pictures. For example:

(Click on the picture to view the C2PA metadata at Hintfo.)

Adobe’s Content Credentials web site does not identify any issues with this picture. However, the internal metadata contains two interesting timestamps. I extracted them using Adobe’s c2patool. The first timestamp is part of the provenance: how, what, and when the picture was created:
“assertion_store”: {
“c2pa.actions”: {
“actions”: [
“action”: “c2pa.created”,
“description”: “AI Generated Image”,
“softwareAgent”: “Bing Image Creator”,
“when”: “2024-01-28T19:34:25Z”
This provenance information identifies an AI Generated Image. It was created by Microsoft’s Bing Image Creator on 2024-01-28 at 19:34:25 GMT.

The other timestamp identifies when the metadata was notarized by an external third-party signatory:
“signature”: {
“alg”: “ps256”,
“issuer”: “Microsoft Corporation”,
“time”: “2024-01-28T19:34:24+00:00”
The external third-party timestamp authority works like a notary. It authoritatively states that it saw a signature for this picture at a specific date and time. The picture had to have been created at or before this timestamp, but not later.

Adobe’s c2patool has a bug that conflates information from different X.509 certificates. The cryptographic signature over the entire file was issued by Microsoft, but the time from the timestamp authority response was issued by DigiCert (not Microsoft); DigiCert isn’t mentioned anywhere in the c2patool output. This bug gives the false impression that Microsoft notarized their own data. To be clear: Microsoft generated the file and it was notarized by DigiCert. Although attribution is a critical component to provenance, Adobe’s c2patool mixes up the information and omits a signatory’s identification, resulting in a misleading attribution. (This impacts Adobe’s c2patool and Adobe’s Content Credentials web site.)

Ignoring the attribution bug, we can combine these provenance and notary timestamps with the time when FotoForensics received the picture; FotoForensics defines the last possible modification time since the files are stored on my servers in a forensically sound manner:

2024-01-28 19:34:24 GMTx.509 Signed TimestampTrusted external timestamp from DigiCert2024-01-28 19:34:25 GMTJUMBF: AI image createdInternal C2PA metadata from Microsoft2024-02-01 10:33:29 GMTFotoForensics: ReceivedFile cannot be modified after this time

The problem, as denoted by the timeline, is that Bing Image Creator’s creation date is dated one second after it was notarized by the external third-party. There are a couple of ways this can happen:
The external signer could have supplied the wrong time. In this case, the external signer is DigiCert. DigiCert abides by the X.509 certificate standards and maintains a synchronized clock. If we have to trust anything in this example, then I trust the timestamp from DigiCert.

Microsoft intentionally post-dated their creation time. (Seems odd, but it’s an option.)

Microsoft’s server is not using a synchronized clock. As noted in RFC 3628 (sections 4.3, 6.2, 6.3, and 7.3.1d), clocks need to be accurately synchronized. There could be a teeny tiny amount of drift, but certainly not at the tenths-of-a-second scale.

Microsoft modified the file after it was notarized. This is the only option that we can immediately rule out. Changing Microsoft’s timestamp from “19:34:25” to “19:34:24” causes the cryptographic signature to fail. This becomes a detectable alteration. We can be certain that the signed file said “19:34:25” and not “19:34:24” in the provenance record.
Now, I know what you’re thinking. This might be a one-off case. The X.509 timestamp authority system permits clocks to drift by a tiny fraction of a second. With 0.00001 seconds drift, 24.99999 and 25.00000 seconds can be equivalent. With integer truncation, this could look like 24 vs 25 seconds. However, I’m seeing lots of pictures from Microsoft that contain this same “off by 1 second” error. Here are a few more examples:

The Lucy/dog picture is from Bing Image Generator, the apple picture is from Microsoft Designer, and the waffles are from Microsoft’s Azure DALL-E service. All of these files have the same “off by 1 second” error. In fact, the majority of pictures that I see from Microsoft have this same error. If I had to venture a guess, I’d say Microsoft’s clocks were out of sync by almost a full second.

Being inaccurate by 1 second usually isn’t a big deal. Except in this case, it demonstrates that we cannot trust the embedded C2PA timestamps created by Microsoft. Today it’s one second. It may increase over time to two seconds, three seconds, etc.

Out of Time

Many of the C2PA-enabled files that I encounter have other timestamps beyond the C2PA metadata. It’s problematic when the other timestamps in the file fail to align with the C2PA metadata. Does it mean that the external trusted authority signer is wrong, that the device requesting the signature is inaccurate, that the user’s clock is wrong, or that some other timestamp is incorrect? Or maybe a combination?

As an example, here’s a picture that was edited using Adobe’s Photoshop and includes an Adobe C2PA signature:

In this case, the picture includes XMP, IPTC, and EXIF timestamps. Putting them together into a timeline shows metadata alterations after the trusted notary timestamp:

2022-02-25 12:09:40 GMTEXIF: Date/Time Original
EXIF: Create Date
IPTC: Created Date/Time
IPTC: Digital Creation Date/Time
XMP: Create Date
XMP: Date Created2023-12-13 17:29:15 GMTXMP: History from Adobe Photoshop 25.2 (Windows)2023-12-13 18:22:00 GMTXMP: History from Adobe Photoshop 25.2 (Windows)2023-12-13 18:32:53 GMTx.509 Signed Timestamp by the authoritative third-party (DigiCert)2023-12-13 18:33:12 GMTEXIF: Modify Date
XMP: History (Adobe Photoshop 25.2 (Windows))
XMP: Modify Date
XMP: Metadata Date2023-12-14 03:32:15 GMTXMP: History from Adobe Photoshop Lightroom Classic 12.0 (Windows)2024-02-06 14:31:58 GMTFotoForensics: Received

With this picture:
Adobe’s C2PA implementation at Content Credentials doesn’t identify any problems. The picture and metadata seem legitimate.

The Adobe-generated signature covers the XMP data. Since the signature is valid, it implies that the XMP data was not altered after it was signed.

The authoritative external timestamp authority (DigiCert) provided a signed timestamp. The only other timeline entry after this signature should be when FotoForensics received the picture.

However, according to the EXIF and XMP metadata, the file was further altered without invalidating the cryptographic signatures or externally supplied timestamp. These modifications are timestamped minutes and hours after they could have happened.
There are a few ways this mismatched timeline can occur:
Option 1: Unauthenticated: As noted by IBM: “Authentication is the process of establishing the identity of a user or system and verifying that the identity is valid.” Validity is a critical step in determining authenticity. With this picture, it appears that the XMP metadata was postdated prior to signing by Adobe. This option means that Adobe will happily sign anything and there is no validation or authenticity. (Even though “authenticity” is the “A” in C2PA.)

Option 2: Tampered: This option assumes that the file was altered after it was signed and the cryptographic signatures were replaced. In my previous blog entry, I demonstrated how easy it is to replace these C2PA signatures and how the X.509 certificates can have forged attribution.

At Hintfo, I use the GnuTLS’s “certtool” to validate the certificates.

To view the certificate information, use: c2patool –certs file.jpg | certtool -i

To check the certificate information, use: c2patool –certs file.jpg | certtool –verify-profile=high –verify-chain

To verify the digital signatures, use: c2patool -d file.jpg

Although the digital signatures in this car picture appear valid, certtool reports a warning for Adobe’s certificate:
Not verified. The certificate is NOT trusted. The certificate issuer is unknown.
In contrast to Adobe, the certs from Microsoft, OpenAI, Stability AI, and Leica don’t have this problem. Because the certificate is unauthenticated, only Adobe can confirm if the public cert is really theirs. I’m not Adobe; I cannot validate their certificate.

I also can’t validate the DigiCert certificate because Adobe’s c2patool doesn’t extract this cert for external validation. It is technically feasible for someone to replace both Adobe’s and DigiCert’s certificates with forgeries.
Of these two options, I’m pretty certain it’s the first one: C2PA doesn’t authenticate and Adobe’s software can be used to sign anything.

With this car example, I don’t think this user was intentionally trying to create a forgery. But an “unintentional undetected alteration” actually makes the situation worse! An intentional forgery could be trivially accepted as legitimate.

It’s relatively easy to detect when the clock appears to be running fast, postdating times, and listing events after they could have happened. However, if the clocks were slow and backdating timestamps, then it might go unnoticed. In effect, we know that we can’t trust postdated timestamps. But even if it isn’t postdated, we cannot trust that a timestamp wasn’t backdated.

Time After Time

This red car picture is not a one-off special case. Here are other examples of mismatched timestamps that are signed by Adobe:

The timeline from this cheerleader picture shows that the EXIF and XMP were altered 48 seconds after it was cryptographically signed and notarized by DigiCert. Adobe’s Content Credentials doesn’t notice any problems.

This photo of lights was notarized by DigiCert over a minute before the last alteration. Again, Adobe’s Content Credentials doesn’t notice any problems.

This picture has XMP entries that postdate the DigiCert notarized signature by 3 hours. And again, Adobe’s Content Credentials finds no problems.

Unfortunately, I cannot include examples received at FotoForensics that show longer postdated intervals (some by days) because they are associated with personal information. These include fake identity cards, medical records, and legal documents. It appears that organized criminal groups are already taking advantage of this C2PA limitation by generating intentional forgeries with critical timestamp requirements.

Timing is Everything

Timestamps identify when files were created and updated. Inconsistent timestamps often indicate alterations or tampering. In previous blog entries, I demonstrated how metadata can be altered and signatures can be forged. In this blog entry, I’ve shown that we can’t even trust the timestamps provided by C2PA steering committee members. Microsoft uses unsynchronized clocks, so we can’t be sure when something was created, and Adobe will happily sign anything as if it were legitimate.

In my previous conversations with C2PA management, we got into serious discussions about what data can and cannot be trusted. One of the C2PA leaders lamented that “you have to trust something.” Even with a zero-trust model, you must trust your computer or the validation software. However, C2PA requires users to trust everything. There’s a big difference between trusting something and trusting everything. For example:

Trust AreaC2PA RequirementsForgeriesReal WorldMetadataC2PA trusts that the EXIF, IPTC, XMP, and other types of metadata accurately reflects the content.A forgery can easily supply false information without being detected. Adobe’s products can be trivially convinced to authentically sign false metadata as if it were legitimate.In real world examples, we have seen Microsoft provide false timestamps and Adobe generate valid cryptographic signatures for altered metadata.Prior claimsC2PA trusts that each new signer verified the previous claims. However, C2PA does not require validation before signing.Forgeries can alter metadata and “authentically” sign false claims. The signatures will be valid under C2PA.The altered metadata examples in this blog entry shows that Adobe will sign anything.Signing CertificatesC2PA trusts that the cryptographic certificate (cert) was issued by an authoritative source. However, validation is not required.A forgery can create a cert with false attribution. In my previous blog entry, I quoted where the C2PA specification explicitly permits revoked and expired certificates. I also demonstrated how to backdate an expired certificate.As noted by certtool, Adobe’s real certificates are not verifiable outside of Adobe.ToolsEvaluating C2PA metadata requires tools. We trust that the tools provided by C2PA work properly.The back-end C2PA library displays whatever information is in the C2PA metadata. Forged information in the C2PA metadata will be displayed as valid by c2patool and the Content Credentials web site.Both c2patool and Content Credentials omit provenance information that identifies the timestamp authority. Both systems also misassociate the third-party timestamp with the first-party data signature.TimestampsC2PA treats timestamps like any other kind of metadata; it trusts that the information is valid.A forgery can easily alter timestamps.In real world examples, we have seen misleading timestamps due to clock drift and other factors.

The entire architecture of C2PA is a house-of-cards based on ‘trust’. It does nothing to prevent malicious actors from falsely attributing an author to some media, claiming ownership over someone else’s media, or manufacturing fraudulent content for use as fake news, propaganda, or other nefarious purposes. At best, C2PA gives a false impression of authenticity that is based on the assumption that nobody has ill intent.

Ironically, the only part of C2PA that seems trustworthy is the third-party timestamp authority’s signed timestamp. (I trust that companies like DigiCert are notarizing the date correctly and I can test it by submitting my own signatures for signing.) Unfortunately, the C2PA specification says that using a timestamp authority is optional.

Recently Google and Meta pledged support for the C2PA specification. Google even became a steering committee member. I’ve previously spoken to employees associated with both companies. I don’t think this decision was because they believe in the technology. (Neither company has deployed C2PA’s solution yet.) Rather, I suspect that it was strictly a management decision based on peer pressure. I don’t expect their memberships to increase C2PA’s reliability and I doubt they can improve the C2PA solution without a complete bottom-to-top rewrite. The only real benefit right now is that they increase the scope of the class action lawsuit when someone eventually gets burned by C2PA. Now that’s great timing!