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 GMT	x.509 Signed Timestamp	Trusted external timestamp from DigiCert
2024-01-28 19:34:25 GMT	JUMBF: AI image created	Internal C2PA metadata from Microsoft
2024-02-01 10:33:29 GMT	FotoForensics: Received	File 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 GMT	EXIF: Date/Time Original EXIF: Create Date IPTC: Created Date/Time IPTC: Digital Creation Date/Time XMP: Create Date XMP: Date Created
2023-12-13 17:29:15 GMT	XMP: History from Adobe Photoshop 25.2 (Windows)
2023-12-13 18:22:00 GMT	XMP: History from Adobe Photoshop 25.2 (Windows)
2023-12-13 18:32:53 GMT	x.509 Signed Timestamp by the authoritative third-party (DigiCert)
2023-12-13 18:33:12 GMT	EXIF: Modify Date XMP: History (Adobe Photoshop 25.2 (Windows)) XMP: Modify Date XMP: Metadata Date
2023-12-14 03:32:15 GMT	XMP: History from Adobe Photoshop Lightroom Classic 12.0 (Windows)
2024-02-06 14:31:58 GMT	FotoForensics: Received

With this picture:

1. Adobe's C2PA implementation at Content Credentials doesn't identify any problems. The picture and metadata seem legitimate.
   
2. 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.
   
3. 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.
   
4. 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 C2P A .)
  
• 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 Area	C2PA Requirements	Forgeries	Real World
Metadata	C2PA 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 claims	C2PA 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 Certificates	C2PA 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.
Tools	Evaluating 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.
Timestamps	C2PA 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!

---

Značky: #Authentication, #FotoForensics, #Network, #Forensics, #Programming

Today, my FotoForensics service turns 12 years old! It has over 6,800,000 unique pictures. That's up about 800,000 from last year . The site's popularity has increased by about 12%, from being in the top 80,000 of internet destinations last year to about 70,000 right now. (By comparison, the top five internet destinations are currently Google, Facebook, Youtube, [surprisingly] Twitter, and Instagram. None of my services are that popular, yet.)

Unexpectedly Popular

I actually find the site's popularity kind of surprising, considering all of the wide-area bans. For example:

Banned: Tor
I've been actively blocking uploads from the Tor network since 2017 (7 years and counting). This is because over 90% of uploads from Tor violated my terms of service. Besides the IDs (for fraud) and bulk uploading, Tor users account for over 50% of the uploaded child porn (yuck). Initially, the bans were almost set manually, but I quickly added in automated rules. Today, the detection of Tor uploads is completely automated. While I see the "Tor blocked" messages in the logs, I don't give it a second thought.

Banned: Russia
Before being banned, Russia was almost abusive as Tor. Bulk uploading, porn, child porn, fake IDs, drug distribution photos, and much more . It wasn't any single user or group; it was wide-spread and endemic. When I'd catch them, I'd ban them. However, the Russian mentality when getting caught is to evade the ban and then increase in volume. By 2020, I'd had enough of this and issued a country-wide ban.

To put this ban into perspective, the public FotoForensics site does not permit uploads of ID, drivers licenses, passports, etc. I've been keeping metrics on these types of uploads:



Black and white means I've never received any ID pictures from that country. (E.g., You'll never see a Greenland passport because it's part of Denmark .) The volume per country goes from bright green (few sightings) to bright red (the most sightings). Even with zero uploads from Russia for the last 4 years, Russia still has more ID uploads than any other country. Russia was so prolific that four year after banning their uploads, Russia still has uploaded more IDs than the next three countries combined (China, Syria, and Indonesia).

Since putting the country-wide ban in place, I've received many unban requests from Russians, including:

• People claiming to be Russian law enforcement. As proof of their legitimacy, some provided photos of fake police IDs and fake police badges. Others gave fake names and addresses for police stations that don't exist. None of these requests appear to be real law enforcement.
  
• A few Russian service providers have asked to be unbanned. However, they were part of the original problem and have done nothing to mitigate the abuse that emanates from their networks. One was rather chatty and made it clear: they should not be held responsible for abuses from their customers, even if the problem comes from a majority of them.
  
• Two people claiming to be with Russian media asked to be unbanned. However, I couldn't authenticate either of them and they were coming from shared networks where people (let's assume other people and not them) were uploading prohibited content.

When banned, these users would occasionally switch to VPNs or proxy networks and continue their uploads. These abuses would be quickly caught and all uploads from the proxy network would be blocked. Today, it is very difficult for anyone in Russia to upload anything to FotoForensics. And if they find a way to upload and violate my terms of service (porn, IDs, etc.), then they get blocked fast.

Because of the country-wide ban, I've also received a lot of hate email from Russians. They call me a tool of the West, a 'liberal', or pro-Ukrainian propagandist. My thinking here is pretty simple: their country was banned for widespread abuses. Writing hostile messages to me don't alleviate the abuse.

Banned: China
I really went out of my way to not ban all of China, but eventually I had no other option.

• The first country-wide ban lasted a few days. The ban message even explicitly mentioned why there was a country-wide ban and included sample images. When the ban lifted, the abuses resumed a few days later.
  
• The second country-wide ban lasted a week. Again, it resumed when the ban lifted.
  
• The third country-wide ban lasted a month. But, again, it didn't stop the problem.
  
• China has been banned for a few months now, and the ban will last for one year.

Because Russians managed to get most free or inexpensive VPNs and proxy services banned, it's really hard for Chinese people to evade the ban.

Unlike Russia, the abuses from China are not from a majority of Chinese citizens. It seems to come from a handful of very prolific groups. However, because of how China has allocated their national internet service, I have no easy method to distinguish the prolific abusers from the non-abusive population. I had expected to see a drop in volume at FotoForensics when I banned China. Surprisingly, this didn't happen. Instead, I saw a 5% increase in uploads and these new uploads were not violating my terms of service! I suspect that people in China are talking to people outside of China, and that is driving more volume to my site.

You can't spell "pain" without "ai"

The public FotoForensics service is explicitly used for research. (It's mentioned 18 times in the FAQ .) When doing any kind of research, you need sample data. Most researchers go out and harvest content. This creates a bias due to their search criteria. With FotoForensics, I just wait for people to upload real-world examples. Of course, this does introduce a different bias: the service receives pictures when people question the legitimacy or are testing; it rarely receives unquestioned legitimate pictures.

This bias allows me to determine what people are most concerned about. And right now? It's AI. Whether the picture is completely AI generated or altered using AI systems, people have legitimate concerns. Here are some recent examples (click on the picture to view at FotoForensics):



This first picture appears to show a child soldier in Ukraine. However, the metadata was stripped out; we cannot identify the source. (Also, you might not notice that his limbs look unnatural.) In this case, Stability AI (the company behind Stable Diffusion) has been adding watermarks to some of their pictures. These show up as binary repeating dot sequences in the compression level (ELA):



I can easily detect this watermarking; this picture came from Stable Diffusion before the metadata was removed. However, I haven't figured out how to decode the watermark yet. (Help would be appreciated!) I wouldn't be surprised if it encoded a timestamp and/or account name.

Not every AI-generated image is as easy to detect as Stable Diffusion. Consider this picture, titled "Mea Sharim", which refers to an ultra-Orthodox Jewish neighborhood in Jerusalem:



At first glance, it appears to show an Orthodox man standing on a corner. However, the ELA identifies an AI-generated erasure:



The erased area is adjacent to the man and appears a little taller. The erased area also seems to have an erased shadow. With some of these "smart erase" tools, you can select an area and have the AI fill in the void. That appears to be the case here. While I can conclusively detect the altered area, I can only speculate about what was erased. I suspect that the visible man was facing another person. The artist selected the other person and his/her shadow and performed a smart erase.

Both of these pictures could easily be used for propaganda. Having metadata that identifies a vague statement about a digital alteration using AI means nothing when the metadata can be trivially removed and replaced.

What's New?

Usually I try to celebrate each new year at FotoForensics with a new feature release. For the last few months, I've been doing a lot of behind-the-scenes modifications. This year, rather than doing one big update, I plan to continue the rolling updates with more changes coming down the line. This includes addressing some of the AI-generated content later this year. (If you're on the commercial service , then you should be seeing some of the new detection systems right now in the metadata analyzer.)

After 12 years, I'm still making regular improvements to FotoForensics, and enjoying every minute of it. I'm very thankful to my friends, partners, various collaborators, and the public for 12 years of helpful feedback, assistance, and insights. This year, I especially want to thank my mental support group (including "I'm Bill not Bob", "I'm Bob not Bill", and Dave), my totally technical support group (Marc, Jim, Richard, LNM, Troy's evil cat, and everyone else), Joe, Joe, Joe, AXT, the Masters and their wandering slaves, Evil Neal , Loris, and The Boss. Their advice, support, assistance, and feedback has been invaluable. And most importantly, I want to thank the literally millions of people who have used FotoForensics and helped make it what it is today.

---

Značky: #Forensics, #FotoForensics, #Network

Whether it is carpentry, auto mechanics, electrical engineering, or computer science, you always hear the same saying: use the right tool for the right job. The wrong tool can make any solution difficult and could introduce new problems.

I've previously written about some of the big problems with the C2PA solution for recording provenance and authenticity in media. However, I recently came across a new problem based on their decision to use X.509 certificates and how they are used. Specifically: their certificates expire. This has some serious implications for authentication and legal cases that try to use C2PA metadata as evidence.

X.509 Background

Whether it's HTTPS or digital signatures, the terms "certificates", "X.509", and "x509" are often used interchangeably. While there are different types of digital certificates, most use the X.509 format. The name "X.509" refers to a section in the ITU standards. The different parts in the standard are called "Series". There are Series A, D, E, F, ... all the way to Z. (I don't know why they skipped B or C.) Series A covers their organization. Series H specifies audiovisual and multimedia systems. Series X covers data networks and related security. Within Series X, there are currently 1,819 different sections. "X.509" refers to Series X, section 509. The name identifies the section that standardizes the digital certificate format for public and private key management. In general, when someone writes about certificates, certs, X.509, or x509, it's all the same thing.

X.509 technology has been around since at least November 1988. That's when the first edition of the specification was released. It's not a perfect technology (they're on the ninth major revision right now), but it's good enough for many day-to-day uses.

I'm not going to claim that X.509 is simple. Public and private key cryptography is very technical and the X.509 file format is overly complicated. Years ago, I wrote my own X.509 parser, for both binary (DER) and encoded text (PEM) formats, and with support for individual certs and chains of certs. You really can't comprehend the full depth of complexity until you try to implement it your own parser. This is why almost everyone relies on someone else's existing library. The most popular library is OpenSSL .

At an overly-simplified view, each X.509 certificate contains (at minimum) a public key, and/or a private key, and/or a chain of parent keys. (A parent cert can be used to issue a child cert, creating a chain of certificates.) Data encrypted with the public key can only be decoded with the private key, and vice versa. Usually the private key is not distributed (kept private) while the public key is shared (made public).

X.509 Metadata

Buried inside the X.509 format are parameters that identify how the certificate can be used. Some certs are only for web sites (HTTPS), while others may only be for digitally signing documents.

Most certs also include information about the issuer and the issuee (the 'subject'). These are usually encoded text notations, such as:

• CN: Common Name
• OU: Organizational Unit
• O: Organization
• L: Locality (City or Region)
• ST: State or Province Name
• C: Country Name

So you might see a cert containing:

Subject: /CN=cai-prod/O=Adobe Inc./L=San Jose/ST=California/C=US/emailAddress=cai-ops@adobe.com

Issuer: /C=US/O=Adobe Systems Incorporated/OU=Adobe Trust Services/CN=Adobe Product Services G3

Depending on the X.509 parser, you might see these fields separated by spaces or converted to text (e.g., Country: US, Organization: Adobe Inc., etc.)

The reason I'm diving into X.509 is that C2PA uses these certs to digitally sign the information. As I previously demonstrated with my forgeries , you can't assume that the Subject or Issuer information represents the actual certificate holder. We trust that every issuing certificate provider, starting with the top-level CA provider, is trusted and reputable, filling in the information using validated and authenticated credentials. However, that's not always the case.

• 2011: Fraudulent certs were issued by real CA provider for Google, Microsoft, Yahoo, and Skype
  
• 2012: The trusted and reputable CA provider "TURKTRUST" issued unauthorized certs for Google, Microsoft, and others. (Even though the problem was identified, it was nearly a year later before TURKTRUST was revoked as an untrusted and disreputable CA provider.)
  
• 2013: Google and Microsoft again discovered that fraudulent certs were issued by a real CA provider for some of their domains.
  
• 2015: A trusted and reputable CA provider in China was caught issuing unauthorized certificates for Google. As crypto-expert Bruce Schneier wrote , "Yet another example of why the CA model is so broken."

This is far from every instance. It doesn't happen often, but news reports every 1-2 years is enough to recognize that threat is very realistic. Moreover, if the company (like Leica) isn't as big as Google or Microsoft, then they might not notice the forged certificate.

X.509 Dates

Inside each cert should also be a few dates that identify when the certificate is valid:

• Not Before : A cert may be created at any time, but is not valid until after a specific date. Often (but not always), this is the date when the certificate was generated.
  
• Not After : Certs typically have an expiration date. After that date, the cert is no longer valid. With LetsEncrypt, certificates are only good for 3 months at a time. (LetsEncrypt provides a helper script that automatically renews the cert so administrators don't forget.) Other certificate authorities (CA servers) may issue multi-year certificates. The trusted CA providers (top of the cert chain) often have certs that are issued for a decade or longer.

With C2PA, every cert that I've seen (both real and forged) include these dates. Similarly, unless it is a self-signed certificate, every web server has these dates. In your desktop browser, you can visit any web site and click on the little lock in the address bar to view the site's certificate information. It will list the issuer, subject, and valid date ranges.

Expired Certs and Signing

On rare occasions, you might encounter web sites where the certificate has expired. The web browser detects the bad server certificate and displays an error message:


For a web site:

• If you don't know what's going on, then the error message stops you from visiting a site that uses an invalid/expired certificate.
  
• The temporary workaround is to ignore the expired date, use the certificate anyway, and visit the web site. (NEVER do this if the web site requires any kind of login.)
  
• The long-term solution requires the web administrator to update the certs for the site.

But what about digital signatures, such as those issued with DocuSign or C2PA? In these cases, the public certificate is included with the signature. Since the public cert is widely distributed, they can't just reach out across the internet and update all of them.

An invalid certificate must never be used to create a new signature, but it can be used to validate an existing signature. As noted by GlobalTrust (a trusted certificate authority), there are a few situations to consider when evaluating the time range of a cert used for a digital signature:

Case #1: Post-date : This occurs when the current time is before the Not Before date. (You almost never encounter this.) In this case, we can prove that an invalid certificate was used to sign the data. The signature must be interpreted as invalid, even if the certificate can be used to confirm the signature. (An invalid certificate cannot be used to create a valid signature.)

Case #2: Active : If the current date falls between the Not Before and Not After dates, then the certificate's time range is valid. If the signature checks out, then the signature is valid.

Case #3: Expired : This is where things get a little complicated. As noted by GlobalTrust, "Expired certificates can no longer produce valid signatures -- however, signatures set before expiry remain valid later. Software that issues an error here does not work in accordance with the standard."

This means two things:

1. You are not supposed to use an expired certificate to sign something after it has expired. An expired certificate is invalid for signing, and any new signatures must be treated as invalid.
   
2. If you have an expired certificate that can validate a signature, then the signature is valid.

If (like most of the world) you use OpenSSL to generate a digital signature, then OpenSSL checks the dates. The library refuses to sign anything using an expired certificate. And since Adobe's c2patool uses OpenSSL, it also can't sign the C2PA metadata using an expired certificate.

Except... There's a nifty Linux command-line tool called "faketime". ( sudo apt install faketime ) This program hijacks any system calls to the time() or clock() functions and returns a fake time to the calling application. To backdate the clock by 2 years for a single application, you might use:

faketime -f -2y date # display the date, but it's backdated 2 years
faketime -f -2y openssl ... # force openssl to sign something as if it were 2 years ago
faketime -f -2y c2patool ... # force c2patool to sign using an expired certificate

This way, you can generate a signature that appears valid using an expired certificate. After the expiration date, the backdated signature will appear valid because it can be verified by an expired certificate. (Doh!)

(Using faketime is much easier than taking your computer offline, rolling back the system clock, and then signing the data.)

This means that a malicious user with an expired certificate can always backdate a signature. So really, we need to change Case #3 to make it more specific:

Case #3: Expired and Previously Verified : If the cert is currently expired and you, or someone you trust, previously verified the signature when it wasn't expired, then the signature is still valid.

Case #4: Expired and Not Previously Verified (by someone you trust) : What if you just received the document and the validating certificate is already expired? In this case, you can't tell if someone backdated the signature using something like 'faketime'.

Even if you trust the signing authority, or even if other certificate issuers in the chain are still valid, that doesn't mean that someone didn't backdate the expired certificate for signing. In this case, you cannot trust the signature and it must be treated as invalid .

Hello, Adobe

The reason I'm bringing up all of this: Adobe's certificate that they used for signing C2PA metadata expired on 2024-02-01 23:59:59 GMT. At FotoForensics, I have over a hundred examples of files with C2PA metadata that are now expired. I also have copies of a few dozen pictures from Microsoft that are about to expire (Not After 2024-03-31 18:15:27 GMT) and a few examples from other vendors that expire later this year.

• In theory, the signer can always authenticate their own signature. Even after it expires, Adobe can authenticate Adobe, Microsoft can authenticate Microsoft, etc. This is because Adobe can claim that only Adobe had access to the cert and nobody at Adobe backdated the signature. (Same for Microsoft and other companies.)
  
• If the signer is trusted, such as DocuSign (used for signing legal documents), then we can trust that it was previously validated. (This is Case #3 and we can trust the signature.)

But what about the rest of us? I'm not Adobe, Microsoft, Leica, etc. Maybe I don't trust all of the employees at these companies. (I shouldn't be require to trust them.) Consider this picture (click to view it at FotoForensics or Adobe's Content Credentials ):

• If you only trust the C2PA signature, then you have an expired certificate that validates the signature. Adobe's Content Credentials doesn't mention that the certificate is expired.
  
• If you look at the timestamps, it claims that it was signed by Adobe on 16-Jan-2024; 16 days before the certificate expired. This means you had about two weeks to validate it before it expired. That's not very long.
  
• If you look at the metadata, you can see that it was heavily altered. Taking the metadata at face value identifies a Nikon D810 camera, Adobe Lightroom 7.1.2 for Windows, and Photoshop 25.3 for Windows. The edits happened over a two-year time span. (That's two year between creation and the digital signing with C2PA's authenticity and provenance information.) You can also identify a lot of different alterations, including adjustments to the texture, shadows, lighting, spot healing, etc. (And all of that is just from the metadata!)

This picture is far from a "camera original".

I know a few companies that have said that they want to just relying on the C2PA validation step to determine if a picture is altered. If the C2PA signature is valid, then they assume the picture is valid. But in this case, the non-C2PA metadata clearly identifies alterations. Moreover, the C2PA signature is only able to be validated using an expired certificate. We trust that it was not backdated, but given all of the other edits, is that trust misplaced?

Keep in mind, this specific example is using Adobe. However, many other companies are considering adopting the C2PA specification. Even if you trust Adobe, do you really trust every other company, organization, and creator out there?

New Certs

According to the sightings at FotoForensics, Adobe updated their certificate days before it expired. The new certificate says Not Before 2024-01-11 00:00:00 GMT and Not After 2025-01-10 23:59:59 GMT. That means it's good for one year.

However, even though Adobe's new cert has a Not Before date of 2024-01-11, it wasn't rolled out until 2024-01-23. It took 12 days before FotoForensics had its first sighting of Adobe's new cert. Most companies generate their new cert and immediately deploy it. I'm not sure why Adobe sat on it for 12 days.

In the example picture above, the metadata says it was last modified and cryptographically signed on 2024-01-17, which is 6 days after the new cert was created. If I didn't suspect that Adobe did a slow release of their new certificate, then I'd probably be wondering why it was signed using the old cert after the new cert was available.

The problem of expiring certs will also be problematic when cameras, such as Leica , Canon , and Nikon , begin incorporating C2PA technology. Here are some of the issues:

• Standalone cameras often have clocks that are unset or off by minutes or hours. (Do you want to capture that spontaneous photo, or set the clock first?) Unlike cellphone cameras, many DSLR cameras don't set the time automatically and lose time when the batteries are removed or replaced. If the clock isn't right, then the cert may not be valid for signing.
  
• If the cert is expired, then the camera owner can always backdate the time on the device. This permits claiming that a new photo is old and backing up the claim with a C2PA signature. Even if you trust Canon's cert, you cannot extend that trust to the camera's owner.
  
• The few standalone camera certs I've seen so far have only been valid for a year. That means you will need to update the firmware on your camera at least annually in order to get the new certs. I don't know any photographers who regularly check for firmware updates. New firmware also increases the risk of an update failing and bricking the camera or changing functionality that you previously enjoyed. (When doing a firmware update, vendors rarely change "just one thing".)
  
• Many DSLR cameras lose vendor support after 1-2 years. ( Canon is one of the few brands that offers 5 years for most cameras and 10 years on a few others.) Your new, really expensive camera may not receive new certs after a while. Then what do you do? (The answer? Stop using that camera for taking signed photos!)

Expired and Revoked

There's one other irony about C2PA's use of certificates. In their specification ( Section 1.4: Trust ), they explicitly wrote:

C2PA Manifests can be validated indefinitely regardless of whether the cryptographic credentials used to sign its contents are later expired or revoked.

This means that the C2PA decision makers probably never considered the case of an expired certificate being backdated. Making matters worse, C2PA explicitly says that revoked certificates are acceptable . This contradicts the widely accepted usage of certificates. As noted by IBM :

When x.509 certificates are issued, they are assigned a validity period that defines a start and end (expiration) date and time for the certificate. Certificates are considered valid if used during the validity period. If the certificate is deemed to be no longer trustable prior to its expiration date, it can be revoked by the issuing Certificate Authority (CA). The process of revoking the certificate is known as certificate revocation. There are a number of reasons why certificates are revoked. Some common reasons for revocation are:

• Encryption keys of the certificate have been compromised.
• Errors within an issued certificate.
• Change in usage of the certificate.
• Certificate owner is no longer deemed trusted.

In other words, if a C2PA signature is signed using an explicitly untrusted certificate, then (Section 1.4) the signature should still be considered "valid". This is a direct conflict with the X.509 standard.

C2PA's Section 16.4: Validate the Credential Revocation Information , includes a slight contradiction and correction, but doesn't improve the situation:

When a signer’s credential is revoked, this does not invalidate manifests that were signed before the time of revocation.

It might take a while for a compromised certificate to become revoked. According to C2PA, all signatures made by a known-bad-but-not-yet-revoked certificate are valid. (Ouch! And my coworker just remarked: "It's not like an election can occur in the intervening time. Oh wait, did I say the bad part out loud?")

If you are generating a forgery and have a revoked certificate, you can always backdate the signature to a time before the revocation date. According to C2PA, the signature must be accepted as valid.

With X.509 certs and web sites, revocation is very rare. However, this needs to change if these certs are embedded into devices for authoritative signatures. Some of the new cameras are embedding C2PA certificates for signing. If your camera is lost, stolen, or resold, then you need to make sure the certificate is revoked.

Legal Implications

[Disclaimer: I am not an attorney and this is not legal advice.]

The C2PA specification lists many use cases . Their examples include gathering data for open source intelligence (OSINT) and "providing evidence". Intelligence gathering and evidence usage typically come down to legal purposes. (Ironically, during a video chat discussion that I had with C2PA and CAI leadership last December, they mentioned that they had not consulted with any experts about how C2PA would be used for legal cases.)

I've occasionally been involved in legal cases as a subject matter expert or unnamed technical consultant. From what I've seen, legal cases often drag on for years. Whether it's an ugly divorce, child custody battle, or burglary charge, they are never resolved in months. (All of those TV crime shows and legal dramas, where they go from crime to arrest to trial in days? Yeah, that kind of expedited timeline is fiction.) I sometimes see cases where evidence was collected but went untouched for years. I've also seen a lot of mishandled evidence. What most people don't realize, is that usually a named party in the lawsuit produces the evidence; it's not collected through law enforcement or a trusted investigator. Also, it's usually not handled properly so there are plenty of opportunities for evidence tampering. (As a subject matter expert, I enjoy catching people who have tampered with evidence.)

So, consider a hypothetical case that is based on photographic evidence with C2PA signatures:

• The files were collected, but the signatures were never checked.
  
• Due to issues with evidence handling, we can't even be certain when they were digitally signed, how they were handled, or how they were collected. There is plenty of opportunity for evidence tampering.
  
• By the time someone does check the files, the certificates have expired. They may have expired prior to being documented as evidence.

This is the "Case #4" situation: expired and not validated by a trusted party. Now it's up to the attorneys to decide what to do with an expired digital signature. If it supports their case, they may ignore the expiration date and use it anyway. If it doesn't support their client's position, then they might get the evidence thrown out or flagged as tampered, spoiled , altered, or fabricated. C2PA's bad decision to use X.509 certificates with short expiration windows helps with any " motion to suppress ", " suppression of evidence ", or " exclusion of evidence ."

Without C2PA, we have to rely on good old forensics for tamper detection. With these methods, it doesn't matter when the evidence was collected or who collected it as long as there is no indication of tampering. C2PA adds in a new way to reject otherwise legitimate evidence.

The same concerns apply to photojournalism. If a picture turns up with an expired certificate, does that mean it is just an old photo? Or could it be fabricated and backdated so that it appears to have a valid signature from an expired certificate?

There are many ways to do cryptography and many different frameworks for managing public and private keys. The use of X.509 certificates with short expiration dates, and the acceptance of revoked certificates, just appears to be more bad decisions by C2PA. The real problem here isn't the use of X.509 -- that's just a case of using the wrong tool for the job. Instead, the bigger problem is leaving the signing mechanism in the hands of the user. If the user has malicious intent, then they can use C2PA to sign any metadata (real or forged) as if it were real and they can easily backdate (or post-date) any signature.

---

Značky: #FotoForensics, #Authentication, #Programming, #Network, #Politics, #Forensics

Each January, I try to clean up around the office. This includes getting old papers off my desk and emptying my email box. Similarly, I'm reviewing my long-running research projects. Between FotoForensics and my honeypots, my servers are constantly running a wide range of research projects:

• Some of these research projects have been short-lived. For example, I was seeing a bunch of images with an unknown EXIF tag identified as "0x9999". Using the public service's data, I gathered a bunch of pictures with the same EXIF 0x9999 tag and realized that the field contained JSON information from Xiaomi smartphones. I informed the developers of ExifTool, and as of ExifTool 12.72 , ExifTool decodes the field.
  
• I often use the data I collect for regression testing. Whenever any of my dependencies releases a new version, or when I make a significant code change, I run a month's worth of pictures (or more) through the code to see how the output changes. This allows me to account for any unexpected issues, either in my code or in the dependency. (And more than once, these large-scale tests have identified new bugs. We've been able to address these before any public release.)
  
• I have some long running research projects where I have been collecting data for years. These allow me to identify long-term trends, significant short-term changes, and how manufacturers adopt new standards over time.

This week, I turned off one of my longest running projects: X-Wap-Profile. It tracks a web browser header that used to be popular, but seems obsolete today.

What's this X-Wap-Profile stuff?

Each time your web browser sends a request to the web server, it sends a large number of HTTP header fields. These fields describe the browser, client OS, and other client settings. Consider this HTTP client header:

POST /upload-file.php HTTP/1.1
Host: fotoforensics.com
Connection: keep-alive
Content-Length: 257624
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Origin: https://fotoforensics.com
X-Wap-Profile: http://wap1.huawei.com/uaprof/HUAWEI_RIO-UL00_UAProfile.xml
User-Agent: Mozilla/5.0 (Linux; Android 5.1; HUAWEI RIO-UL00 Build/HUAWEIRIO-UL00) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/39.0.0.0 Mobile Safari/537.36
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary91du4bKYR6ZB05sH
Accept-Encoding: gzip, deflate
Accept-Language: es-ES,en-US;q=0.8
X-Requested-With: com.android.browser

This HTTP client header includes a lot of information:

• The user was uploading a file to FotoForensics (POST /upload-file.php, content-length 257,624 bytes).
  
• The client's device was configured for Spanish from Spain (language es-ES ) and English from the United States (en-US). The "en-US" is default for virtually all web browsers. If the server supports internationalization, then it should try to respond in Spanish. Otherwise, it should default to American English.
  
• The client supports two types of compression: gzip and deflate. The server can compress the response using either algorithm.
  
• The "User-Agent" identifies an older Android device (Android 5.1) on a Huawei Rio smartphone.
  
• The user is using the default android browser (com.android.browser). In this case, it's Mobile Chrome version 39.

And then there's the X-Wap-Profile. This is part of the User Agent Profile ( uaprof ) specification from the Wireless Application Protocol Forum (WAP). This standard dates back to October 2001.

This HTTP header is supposed to specify a URL that provides more detailed device information. The URL should return a well-defined XML file with details like the screen size (this Huawei's resolution is 1920x1080), native audio, video, and image format support (amr, aac, wav, midi, jpeg, png, H.264, etc.), and much more. Some device profiles identify the amount of memory or CPU model. Others identify the OS version, software versions, and whether they can be upgraded.

While this data provides details about the device, none of this information is personal to the user; this isn't a privacy issue. However, I can totally see how a malicious server could use this information to customize a hostile response to a vulnerable client. I mean, the uaprof data often includes protocols and version numbers; I'm sure there are known vulnerabilities for most unpatched systems. (I'm surprised I haven't heard of this attack vector being exploited by anyone.)

Applied User-Agent Profiles

In theory, the web server can request the X-Wap-Profile data and optimize the response for the client. At FotoForensics, I've been collecting this X-Wap-Profile data for years. If I know the device's make and model, then I can immediately look up the CPU, RAM, screen size, and more. Originally I had been hoping to use it to identify more information about the client and optimize what I could easily present. (Why bother trying to send them a 1024x800 image when the device has an 800x600 display?)

While the theory sounds good, in practice, servers usually ignore the uaprof data. My server collected it but never used it for customizing responses. I don't know any servers or services that actually used this data.

Why does everyone ignore it?

• Using this data requires retrieving it from a URL. However, different servers use different timeouts. Some may not respond immediately or may take a long time before failing. These delays make real-time retrieval impractical, especially if the user is waiting on the response. Any delays will result in a bad user experience. And remember: users won't know that your server reply is delayed because of a slow dependency; they'll just notice that your system is slow.
  
• Although the XML format is well-defined , many URLs returned poorly formatted XML, non-standard XML values, or other formats like HTML or JSON. This becomes a parsing nightmare for the server. For example, "http://phone.hisense.com/khfw/rjxz/201208/P020120809608224982262.xml" used to be a valid URL. (It doesn't work anymore.) To properly view this file, you needed to render the HTML web page (with JavaScript enabled) and then copy the rendered text into the XML profile.
  
• Many vendors are inconsistent. For example, Sony Ericsson used different vendor names in different uaprof files: "SONYERICSSON", "Sony Ericsson Mobile Communications", "Sony Mobile Communications", "SonyEricsson", "Sony Ericsson Mobile Communications AB", and "Ericsson Mobile Communications AB". Asus used "ASUSTeK COMPUTER INC." and "ASUS", and Lenovo alternated between "Lenovo Mobile", "LenovoMobile", and "Lenovo". The number of vendors that were consistent is significantly less than the number that changed their names arbitrarily.
  
• A few vendors think this data should be "proprietary". For example, the LG LS990 (http://device.sprintpcs.com/LG/LS990-Chameleon/LS990ZV4.rdf, back when it was online) had a comment field that said, "Elements that are not required have been omitted from this template." The uaprof file listed the screen size as "0x0" and the CPU as "NotDisclosed". I find this secrecy ironic since LG made these specs public on their web site. (The LS990 uses a 2560x1440 display and a Qualcomm Snapdragon 801 Quad-Core Processor.)
  
• Often, the URL never existed. For example, as far as I can tell, "http://support.acer.com/UAprofile/Acer_A510_JZO54K_Profile.xml" and "http://www.sonyericsson.com/UAProf/T68R401.xml" were never valid URLs, even when the device was new.
  
• Some vendors never bothered to participate. (Yes, I'm talking about Apple.)
  
• Even if the URL was valid, some URLs returned information for the wrong device. This appeared to happen when the manufacturer just copied over another device's profile and forgot to update the data for the new device.
  
• If you didn't retrieve the uaprof data when the device was new, then the URL would eventually go away. (This is one of the big reason I had been collecting them for years.) In the last year, nearly every uaprof URL that I've seen has been offline. Even ones that used to work no longer work. (It's rare to find one that still works today.)
  
• Most uaprof URLs use hostnames, but some contain hard-coded IP addresses. This is particularly the case for vendors in China and Japan. With hostnames, the vendor can move the site to different network addresses and the URL will still work. But with hard-coded addresses, it means that the vendor must never change the network address, upgrade to IPv6, or alter their network architecture. Not surprisingly, most of these URLs with hard-coded IP addresses fail.
  
• And speaking of URLs... I saw a few instances of the same device using different URLs. Since the URL should be hard-coded, this detail grabbed my attention. I ended up finding a few users who had traveled between countries like India and China, Australia and China, or Russia and China. I knew each was the exact same devices because the picture's metadata included the device's unique serial number. When they were in their home country (India, Australia, etc.), I would see the expected X-Wap-Profile URL. (The URL is hard-coded and set by the web browser.) But when they went to China, the URL would change. Sometimes the URL would work and sometimes it didn't. It appears that the Great Firewall of China was changing the X-Wap-Profile URLs in real-time during the web request. (And switching my server to HTTPS did not deter these alterations. It appears that China was intercepting and altering HTTPS traffic.)

While lots of devices used to support these X-Wap-Profile URLs for identifying additional device profiles, that really isn't the case today. The only time I see these URLs now is when someone uses a really old smartphone. Newer smartphones don't include the X-Wap-Profile header.

Archiving the Old

I'm certainly not the only person who was collecting these URLs. Open Mobile Alliance has a long list of X-Wap-Profile URLs. (While they are marked as 'valid', almost all are no longer online.) There's also a SourceForge project with a list of URLs (again, most are no longer online).

For my own research, I had a script that was watching every incoming HTTP header and harvesting any new X-Wap-Profile URLs. After 12 years, this script had collected 10,702 unique uaprof URLs, with the last one being retrieved on 20-June-2023: http://www-ccpp.tcl-ta.com/files/8050D_HD.xml . It isn't that I had stopped collecting them after last June. Rather, the script hadn't seen any new ones in over six months.

I don't know if the Wireless Application Protocol Forum or Open Mobile Alliance (the groups behind this specification) are defunct, or if mobile device vendors just decided to stop supporting this specification. In either case, it's no longer being used. For now, I'm not going to delete what I've collected, but I am going to archive it and disable the collection script. Maybe there will be a purpose for this data someday in the future.

While this uaprof collection script never took many resources, there's no reason to continue running it when it's not collecting anything. I think a lot of the internet is on auto-pilot, with old scripts that are running even though nobody is looking at the results. This month, I'm trying to do my part by removing obsolete processes.

---

Značky: #FotoForensics, #Network, #Forensics, #Programming

As someone with insomnia, I typically sleep 3-6 hours a night. About once every 2 weeks, I might sleep 7-8 hours, but that's really unusual. My college roommates couldn't understand how I could function on so little sleep. It isn't a medical issue. (I don't wake up needing the bathroom and I don't wake up tired.) I wake up fully rested. Insomnia is just one of those things that runs in my family; one of my parental units often sleeps only a few hours a night.

For years, I tried to find ways to make my sleep more regular. (If I'm going to sleep 5 hours, then let's make it consistently 5 hours.) I finally found a great solution: naps. For the last few years, I've been taking naps once a day, usually in the middle of the afternoon. Just 15-30 minutes is great for recharging myself. And best of all, my nighttime sleeping is now consistently at 6 hours. It doesn't matter when I go to bed. I will wake up 6 hours later without any kind of alarm. (It's almost to the minute.)

The problem with naps is that I would lay down and my brain would be buzzing with ideas. I couldn't turn it off and wouldn't easily fall asleep. Fortunately, I found a solution that works for me: brown noise.

The Color of Noise

Many years ago, my late friend Nurse (Brad Smith) gave a fascinating talk about Weaponizing Lady Gaga . Basically, different sounds can directly influence your brain. If you were to include these psychosonic frequencies in a concert, you could make the crowd peaceful, irritated, revved up, or more susceptible to suggestions. (And yes, some commercials embed these frequencies to influence buyers. I'm not going to link to them, but you might see a medication commercial that's supposed to make you feel better while they play a calming psychosonic frequency. You'll associate 'calm' and 'feeling better' with the medication.)

A simple version of this concept is basic background static. You can buy noise machines that make sounds like rain or ocean waves. The actual type of noise is often named after colors and are based on specific noise frequency distribution properties.

• White noise has a uniform frequency spectrum. It's great at drowning out low volume background noise. If your office has a bothersome ventilation fan or buzz from fluorescent lighting, then some very low volume white noise can drown it out.
  
  
• Green noise focuses on the middle frequency ranges; fewer high and low notes. It often has a calming effect on people. (Hospital waiting rooms and police holding cells should play it at a very low volume. Playing it just above the hearing threshold is very effective. Blasting it loudly doesn't make people calmer.)
  
• Pink noise has a linear distribution, with more lower frequencies than high frequencies. This often sounds like a heavy rain. Some people report that this really helps them sleep.
  
  
• Brown noise (also called brownian noise) uses a really steep frequency distribution. Lots of low frequencies and almost no high frequencies. If pink noise kind of helps you sleep, then brown noise will knock you out cold.
  

Build Your Own Sleep Machine

While I knew about these different noise patterns, I never really gave them much thought. Until one day I noticed something. My better half and I sometimes watch streaming TV together. During the ad breaks, there would be an ad for a table-top pink noise and brown noise generator. I couldn't help but notice that every time it played a few seconds of brown noise in the commercial, she would yawn.

Of course, I'm not the type of person who would shell out money to buy a brown noise speaker system. Instead, I used the Linux audio program "sox" to generate about 15 minutes of brown noise as a music file.

My first attempt just sounded like static to me. So I did a little tweaking with the sox audio filters.

My second attempt gave me a very distinct calming sensation. So I did a few more adjustments.

I knew the third attempt worked because I woke up 30 minutes later, still sitting at the keyboard. Totally well rested. The mp3 had ended 15 minutes before I woke up.

I added this song to my "favorites" playlist and now I use it every time I take a nap. Seriously:

1. Lay down in a semi-dark room and hit play on "Brown".
   
2. Try not to think for just two minutes. (For me, turning off all of the thoughts in my head is like trying to hold my breath. I can't do it for very long.) Don't quietly repeat to yourself "don't think". Don't think about the next things you need to do. Don't listen for the settling of the house, or anything else. Just focus on the brown noise.

For me, I'm typically out cold after 1-3 minutes. The mp3 lasts for 15 minutes. I usually end up napping for 15-30 minutes, but occasionally for an entire hour. The sleep duration definitely varies per person. Test it on yourself when you have a quiet afternoon. Maybe set an alarm if you don't want to sleep too long.

I even use this when traveling by plane. Right after the flight attendant gives the safety presentation, I put on the headphones and hit play . I'm usually asleep before liftoff and I wake up after we reach cruising altitude.

Try it!

I've packaged up the mp3 files as an 'album' and uploaded it to my music server. On the album, I have 15 minutes of white, green, and brown noise. I also have some chicken sounds on the album because those help you snap out of it when the song ends.

---

Značky: #Network, #Programming, #Forensics

Every year I try to focus on a theme. For example:

• In 2017, it was Cyber Goat . I had this crazy idea that a small company might be able to make large organizations move. (It was an incredible success.)
  
• In 2019, I focused on a couple of themes : fraud and detection, practical ways to deter bots, and how to setup a basic honeypot.
  
• In 2020, I heavily focused on Tor . Sadly, there was nothing I could do to make them address some of their huge security holes. It's been over 4 years and they have not addressed any of the issues. (Then again, some of these have been known problems for decades and the Tor Project just ignores them, even when there are viable solutions. Seriously: don't use Tor if you need real online anonymity.)

This year, I've been heavily focused on automation. I don't have unlimited resources or personnel, so I want to make the most of what I've got.

Automation for security and administration tasks isn't a new concept. Everyone does it to some degree. Firewalls are configured and deployed, cron jobs automate backups, etc.

My crazy twist applies this concept to tasks that are usually not automated. I've been developing and using automated security solutions for over 30 years. This year, I publicly disclosed many of the solutions that I use. For example:

• In No Apps , I mentioned how I use test images to identify the underlying graphics libraries that applications use. Some libraries change images during their rendering process, and others have known vulnerabilities. This quick semi-automated test allows me to learn more about the software that I use.
  
• I covered how I use fail2ban and strict mail server rules to mitigate junk mail and spam. On any typical day, my email box only receives 2-4 spam messages. The remaining hundreds of emails are caught by the mail server's filter rules. I configured it once and occasionally (maybe 30 minutes every few months) make little adjustments. For the most part, it's fully automated and I don't have to think about it.
  
• I mentioned the various honeypots I use and some of the findings . I am automatically alerted when a change in attack volume happens, and I can tell if it's specific to a single server or just a change in the background noise level.
  
  Knowing the background level is really important. I'm less concerned if everyone sees the same attacks. Directed attacks get my attention. I also use it for business intelligence ; I often know what exploits the attackers are looking for before any official announcement.
  
• Based on my work with honeypots, I released a four-part series on No-NOC Networking . This series describes some simple solutions to dramatically reduce the number of scans and attacks that your typical online service receives. And best of all: these can be implemented without any full-time system administrators or network operations center (NOC). These changes require no extra costs for better security.
  
• Along with descriptions of my honeypots, I also released Nuzzle as an open source packet sniffer that can be used as an IDS/IPS system. Many of my own servers use Nuzzle. Between Nuzzle and some simple kernel configurations, you can easily see a 99% drop in the number of attacks. (That's not "stopping 99% of attacks", that's "99% fewer attacks that need to be stopped.")
  
• Besides software automation, I did a lot of hardware hacking by making some simple internet-of-things (IoT) devices. These ranged from a basic temperature sensor (for montioring my server cabinet) to different approaches for checking on the health of elderly friends . I even automated the tracking of my AirTag .
  
• Through the use of automated detectors, I was able to rapidly detect and block uploads when a new kind of prohibited content went viral.

All of this simplifies my system management needs. Rather than spending a lot of time and money on yet another partial solution, I use my limited resources more effectively. Fewer network attacks, less spam, and better ways to monitor the things that I think are important.

Bad Automation

I typically view automation as a good thing. I often tell my peers: if it can be automated, then it should be automated. However, sometimes automation isn't beneficial. A good automated system should be reliable and accurate. Unfortunately, some recently deployed automated solutions are neither.

The growing and unchecked use of AI is a really good example here. Whether it's AI-generated art or AI-written text , I'm seeing more misuse and problems than benefits. Personally, I think the punishments for using unchecked AI text, like ChatGPT, for official reports should be more severe than public criticism and the occasional sanction .

There are also problems with how these AI systems are being trained. Since deep networks can often memorize the training data, the AI generated results may appear as copyright infringement. Personally, I'm eagerly waiting to hear the outcome of Getty's lawsuit against Stability AI for stealing pictures for training and generating minor variants as uncited "AI generated imagery". And the New York Times recently sued OpenAI and Microsoft for the unauthorized use of copyrighted news articles.

While I use many different types of automated systems (including lots of different kinds of AI), it takes effort to create good automated rules. Bad automatons lead to bad user experiences . (Just ask the Etsy forums about bad automated blocking rules, and the US Post Office really needs to consult with a human-computer interaction (HCI) expert about usability for their automated kiosks.)

And then there's C2PA. I don't think I'm done writing about them . I rarely use snake oil to describe any kind of fake security solution or bad automated evaluation system, but this time I think it is well deserved.

Next year?

Long-time readers of my blog will know that I am often rough, brutally honest, and hyper-focus on the negative aspects. In 2023, I tried to write more uplifting and less cranky blog entries. (Other than C2PA or my criticisms about AI, I think I did pretty well compared to previous years. And with AI and C2PA, I do like the concepts, but I take issue with the execution and how they generate more problems than they attempt to solve.)

In 2024, I'm going to try to have a little more fun with this blog. I'm hoping to write more about things that make me happy (which usually includes projects that have worked out better than expected). For example, rather than focusing on how deep network AI causes problem, I might try to experiment with some good uses for it. When it comes to authenticity and provenance, the C2PA management challenged me to come up with something better. I think I've got a partial solution that works; when I get time to write it up and create a working example, I'm certain to blog about it. (A working partial solution is definitely an improvement when compared to the defective solution from C2PA.) And who knows what else I'll do? Some of the best projects have been those surprises along the way.

---

Značky: #Privacy, #Network, #Security, #Forensics, #[Other]

A month ago, I wrote a very detailed and critical review of the Coalition for Content Provenance and Authenticity (C2PA) specification for validating media metadata. My basic conclusion was that C2PA introduces more problems than it tries to solve and it didn't solve any problems.

Although a few people have left comments on the blog, I have had a near daily stream of new contacts writing in. Some are curious developers, while others are people tasked with evaluating or implementing C2PA. The comments have come from small organizations, Fortune-500 companies, and even other CAI and C2PA members. (Since some of them mentioned not having permission to publicly comment, I'm treating them all as anonymous sources.)

Despite having different areas of interest, they all seem to ask variations of the same basic questions. (It's so frequent, that I've often been cut-and-pasting text into replies.) In this blog entry, I'm going to cover the most common questions:

1. Are there any updates?
2. How bad is C2PA's trust model?
3. Isn't C2PA's tamper detection good enough?
4. Is C2PA really worse than other types of metadata?
5. What's the worst-case scenario?

For people interested in problem solving with forensic tools, I have a challenge in the 5th item.

Question 1: Are there any updates?

There have been a couple of updates to C2PA since my blog came out. Some appear to be unrelated to me, and some are directly related.

• C2PA released version 1.4 of their specifications. Unfortunately, it doesn't address any of the problems with the trust model. (Since this happened a few days after my blog, it's an unrelated update.)
  
• Some of the bugs submitted to various C2PA github projects suddenly became actively addressed by the C2PA/CAI developers. (Including some submitted by me.) While this is progress, none have been fixed yet. In most cases, the bugs seem to have been copied from the public github locations to Adobe's private bug management system. (This means that C2PA development is really only happening inside Adobe.) Unfortunately, none of these bugs address C2PA's trust model.
  
• Last week I had a productive discussion with people representing C2PA and CAI. I'm not going to disclose the discussion topics, except to say that there were some things we agreed on, and many things we did not agree on.
  
  Excluding myself and my colleague, everyone on the call was an Adobe employee. In my previous blog , I mentioned that CAI acts like a façade to support C2PA. Between all of the key people being at Adobe and all development going through Adobe, I'm now getting the distinct impression that CAI and C2PA are both really just "all Adobe all the time." It does not appear to be the wider community that C2PA and CAI describe.
  
• A few days after the conference call, Adobe made a change to CAI's Content Credentials web site. Now self-signed certificates (and some of the older non-test certificates) are flagged as untrustworthy: "This Content Credential was issued by an unknown source."
  
  
  The only way around this requires paying money to a certificate authority for a "signing certificate". (At DigiCert, this costs $289 for one year.) Switching to a fee-based requirement dramatically reduces the desirability for smaller companies and individual developers to adopt C2PA. And yet, adding in a fee requirement does nothing to deter fraud. (Fraud is a multi-billion dollar per year industry. The criminals can afford to pay a little for "authentication".)
  
  As an aside, "HTTPS" adoption had a similar pay-to-play limitation until Let's Encrypt began offering free certificates. Today, HTTPS is the norm because it's free. Unfortunately, those free certificates are for web domains only and not for cryptographic signatures .

Question 2: How bad is C2PA's trust model?

My previous evaluation identified different ways to create forgeries, but it only superficially covered the trust model.

Back in the old days of network security, we relied on "trust", but "trust" was rapidly shown to be vulnerable and insecure. "Trust" doesn't work very well as a security mechanism; it's not even "better than nothing" security. "Trust" is used for legal justification after the fact. We trust that someone won't ignore the "No Soliciting" sign by your door. The sign doesn't stop dishonest solicitors. Rather, it establishes intent for any legal consequences that happen later.

In networking, "trust" was replaced with " trust but verify ", which is better than nothing. Today, network security is moving from "trust but verify" to " zero trust ".

C2PA is based heavily on the "trust" and not "trust but verify". (And definitely not "zero trust".) With C2PA:

• We trust that the metadata accurately reflects the content. (Provenance, origin, handling, etc.) This explicitly means trusting in the honesty of the person inserting the metadata.
  
• We trust that each new signer verified the previous claims.
  
• We trust that a signer didn't alter the previous claims.
  
• We trust that the cryptographic certificate (cert) was issued by an authoritative source.
  
• We trust that the metadata and cert represents an authoritative source. While the cert allows us to validate how it was issued ("trust but verify"), it doesn't validate who it was issued to or how it is used.
  
• We trust the validation tools to perform a proper validation.
  
• We trust that any bad actors who violate any of these trusts will be noticed before causing any significant damage. ( Who will notice it? We trust that there is someone who notices, somewhere to report it, and someone who can do something about it. And we trust that this will happen quickly, even though it always takes years to revoke a pernicious certificate authority .)

All of this trust is great for keeping honest people honest. However, it does nothing to deter malicious actors.

C2PA is literally based on the honor system. However, the honor system is the definition of having no security infrastructure. (We don't need security because we trust everyone to act honorably.)

Question 3: Isn't C2PA's tamper detection good enough?

Putting strong cryptography around unverified data does not make the data suddenly trustworthy. (It's lipstick on a pig !)

Other than the cryptographic signature, all of C2PA's metadata can be altered without detection. (Yes, C2PA also uses a hash, like sha256, as a secondary check, but it's trivial to recompute the hashes after making any alterations.) The cryptographic signature ensures that the data hasn't changed after signing. C2PA calls this tamper evident , while other C2PA members describe it as being tamper resistant or tamper proof . Regardless of the terminology, there are four possible scenarios for their tamper detection: unsigned, invalid, valid, and missing.

• Case 1: Unsigned data
  This cases occurs when the C2PA metadata exists but there is no cryptographic signature. As I've mentioned, everything can be easily forged. Even though the C2PA metadata exists, you cannot explicitly trust it since you don't know who might have changed it.
  
  The C2PA specification permits including files as a component of another file. This unsigned case can easily happen when incorporating media that lacks C2PA metadata. In my previous blog entry , I pointed out that CAI's example with the flowery hair contains a component without a signature.
  
  
  
  
  What this means: If there is no cryptographic signature, then we cannot trust the data. We must use other, non-C2PA methods to perform any validation.
  
• Case 2: Invalid signature or checksum
  When the C2PA metadata has an invalid checksum or signature, it explicitly means something was changed. However, you don't know what was changed, when it happened, or who did it.
  
  Keep in mind, this does not mean that there is intentional fraud or a malicious activity. Alterations could be innocent or unintentional. For example, importing a JPEG into the Windows Photo Gallery ( discontinued but still widely used) automatically updates the metadata. This update causes a change, making the C2PA signature invalid. The same kind of unintentional alteration can also happen when attaching a picture to an outgoing email. (As opposed to importing a picture into the iPhone Photo Library, which simply strips out C2PA metadata.)
  
  If the signature is invalid, then C2PA says we cannot trust the data. However, the important aspects of the data may not have changed and may still be trustworthy. We must use other, non-C2PA methods to determine the cause and perform any validation.
  
• Case 3: Valid signature and checksums
  There are two different ways that a file can contain valid signatures and checksums:
  
  (A) While we don't know if we can trust the data, we know we can trust that it wasn't changed after being signed.
  or
  (B) The data was changed after being signed and any invalid signatures were replaced, making it valid again. In this case, the data and signatures are untrusted.
  
  In both cases (A and B), the signatures and checksums are valid and we cannot trust the data. Moreover, we can't distinguish unaltered (A) from intentionally altered (B). Since we cannot use C2PA for trust or tamper detection, we must use other, non-C2PA methods to perform any validation.
  
• Case 4: No C2PA metadata
  This is currently the most common case. Does it mean that the picture never included C2PA metadata, or that the metadata was removed (stripped)?
  
  CAI's Content Credentials service addresses this problem by performing a similar picture search (perceptual search). Most of the time, they find nothing. However, even if they do find a visually similar file that contains C2PA metadata, it doesn't mean the data in the search result is trustworthy or authentic. (See Cases 1-3.)

In every case:

• The data is untrusted.
• Intentional tampering cannot be detected.
• The data must be validated through other, non-C2PA means.

What does C2PA provide? Nothing except computational busywork. C2PA's complexity and use of buzzwords like "cryptography" and "tamper evident" makes it appear impressive, but it currently provides nothing of value.

Question 4: Is C2PA really worse than other types of metadata?

Given that C2PA does not validate, why do we need yet another standard for storing the exact same information?

The metadata information provided by C2PA is typically present in other metadata fields: EXIF, IPTC, XMP, etc. However, C2PA provides the same information in an overly complicated manner, requiring 5 megs of libraries and four different complex formats to process. In contrast, EXIF and IPTC are simple formats, easy to implement, require few resources, and come in very small libraries. Even XMP (Adobe's XML-based format that sucks due to a lack of consistency) is a better choice than C2PA's JUMBF/CBOR/JSON/XML.

A few people have written to me with comments like, "C2PA has the same long-term integrity issue as other metadata" or "Isn't C2PA as trustworthy as anything else?"

My reply is a simple "No." C2PA is much worse:

1. Regular metadata doesn't claim to be tamper-evident.
   
2. Regular metadata doesn't use cryptographic signatures.
   
3. Regular metadata doesn't have the backing of tech companies like Adobe, Microsoft, and Intel that give the false impression of legitimacy.

Other types of metadata (EXIF, IPTC, etc.) can be altered and should be validated though other means. C2PA gives the false impression that you don't need to validate the information because the cryptographic signatures appear valid.

Even the converse is problematic. Because the metadata can be altered without malicious intent (see the previous Case 2), an invalid C2PA signature does not mean the visual content, GPS, timestamps, or other metadata is invalid or altered. Everything else could be legitimate even with an invalid C2PA signature.

Unlike other types of metadata, C2PA's cryptographic signatures act as a red herring . Regardless of whether the signature is valid, invalid, or missing, forensic investigators should ignore C2PA's signatures since they tell nothing about the data's validity, authenticity, and provenance.

Question 5: What's the worst-case scenario?

This is the most common question I've received. I usually just explain the problem. But for a few people, I've manufactured examples of the worst-case scenario for the questioner to evaluate. In each of these instances, I used the questioner's own personal information to really drive home the point.

Since lots of people are reading this blog entry, I'm going to use Shantanu Narayen as the fictional example of the worst-case scenario. Narayen is the current chair and CEO of Adobe; his personal information in this example comes from his Wikipedia page. (I'm not doxing him.)

In my opinion, the worst-case scenario is when the data is used to frame someone for a serious crime, like child pornography. Here's the completely fictitious scenario:

Last month, Shantanu Narayen got into an online argument with a very vindictive person. The vindictive person acquired a bunch of child pornography and used C2PA to attribute the pictures to Narayen. The pictures were then distributed around the internet.

It doesn't take long for the pictures to be reported to the National Center for Missing and Exploited Children (NCMEC). NCMEC sees the attribution to Narayen and immediately passes the information to the FBI and California's Internet Crimes Against Children (ICAC) task force. A short while later, the police knock on Narayen's door.

I'm not going to include a real picture of child porn for this demonstration of a fictional situation. (That would be gross, illegal, and irrelevant to this example.) Instead, I used a teddy bear picture (because it's "bearly legal").

For this evaluation, ignore the visual portion and assume the picture shows illegal activity. Here's one of those forged pictures!


Now, you get to play the role of the investigator: Prove Narayen didn't do it.

You'll probably want to:

• Download the image. (Save it as 'bearlylegal.jpeg'.) To make sure it wasn't modified between my server and your evaluation, the file is 306,924 bytes and the SHA1 checksum is 04857686607b05b9fe3efef11fa6a11cd68e51df.
  
• Evaluate it using whatever metadata viewers you have available.
  
  
  • If you don't have a starting place, then you can use my own online forensic services, like FotoForensics and Hintfo . But don't feel like you need to use my tools.
    
  • From the command line, try exiftool or exiv2 .
    
  • Most graphical applications have built-in metadata viewers, including Mac's Preview, Windows file properties ("Details" tab), Gimp, and Photoshop. (Just be careful to not hit 'save' or make any changes to the file's metadata.)
  
  
• Use Adobe's command-line c2patool to evaluate the C2PA metadata. With c2patool, you can view what sections are valid and the x.509 certificate contents:
  c2patool -d bearlylegal.jpeg
c2patool --certs bearlylegal.jpeg | openssl x509 -text | less
  
• View it at Adobe/CAI's Content Credentials online service. While this web service currently isn't as informative as the command-line c2patool, it does provide information about the file's C2PA metadata.

If you try solving this problem, either with software or as a conceptual exercise, I'd love to hear your results! I hope people include information like:

• What's your background? Inquisitive amateur, student, software engineer, law enforcement, legal, professional investigator, or something else?
• What tools did you use?
• What were some of your observations?
• What other issues should we consider?
• Do you think you could prove innocence or reasonable doubt?
• Let's turn the problem around: If you were working for the prosecution, do you think you could get a conviction?

I look forward to hearing how people did!

[Spoiler Alert]

* If you want to evaluate this problem on your own, come back to this section later.

Worst-Case Results

Given all of these findings, there are a few other things to consider:

• Law enforcement, attorneys, and the courts are not very technical. If the file's metadata says it's his name and it has a valid signature, then it's valid until proven otherwise. Remember: digital signatures are legal signatures in a court of law; they are accepted as real until you can prove tampering. (And saying "I didn't do that" doesn't prove tampering.)
  
• Narayen can say "that's not my picture!" While Leica may be able to verify that the cert isn't legitimate, Leica is in Germany and Narayen is in the United States. That makes serving a subpoena really difficult. In general, law enforcement (and everyone else who isn't Leica) cannot verify this. Also, Leica is a big company and can have multiple certs. Maybe they just don't remember creating this one or maybe it was part of a limited beta test.
  
• C2PA's trust model assumes that a forged certificate will be eventually noticed. However, Narayen doesn't have months or years to wait for the forged certificate to be reused with some other victim. And that's assuming it is reused; it doesn't have to ever be reused.
  
• You can try to explain that the cert only validates that the data existed and hasn't been changed since signing. But the courts see the words "authentication" and "provenance" and "certified" and "verified" and "validated". The evidence clearly says it is attributed to Narayen.
  
• You might see flaws in the authenticated forgery. The prosecution will claim that the flaws are evidence that Narayen tried and failed to hide his identity. (As many people in the legal system have said, " We don't catch the smart ones. ")
  
• While the C2PA tools don't identify any problems, you might notice problems if you use other tools. In that case, why even bother with C2PA? But that's a rhetorical question and the answer carries no weight in court. The fact is, the metadata identifies Narayen and the cryptographic signature for authentication and provenance says the metadata can be trusted.
  
• Worse: even if the signature appears fake, it doesn't mean Narayen didn't do it. Remember: there is other metadata besides C2PA's metadata that names Narayen. There are also multiple pictures naming him, and not just one photo.
  
• This is a very technical topic. Really technical explanations and jargon will quickly confuse the courtroom. Remember: The judge still thinks a FAX machine is a secure data transmission system and most jury members don't know the difference between "Google" and "the Internet". Assuming you can identify how it was forged, communicating it to the judge and jury is an uphill battle. (Creating a forgery in a live demo would be great here. However, while live demos are common in TV crime shows, they almost never happen in real life. Also, live demos can go horribly wrong, as demonstrated by the OJ Simpson trial's "if the glove fits" fiasco. No sane attorney would permit you to perform a live demo.)
  
• Even if you, as the expert, can explain how it was forged, your testimony will just appear to be you trying to discredit the certified authenticated provenance information. Remember: C2PA claims to be tamper-evident. But in this case, everything checks out so there is no evidence of tampering.
  
• Most people can't afford, don't have access, and/or don't know an expert witness who can determine if the C2PA metadata is legitimate. As the CEO of Adobe, using his own employees as experts carries little or no weight. (Any expert from Adobe is clearly biased since Narayen can fire them at any time.) Law enforcement and the courts will assume: If it says it's from Narayen and the tamper-evident C2PA says there is no evidence of tampering, then it's from Narayen.
  
• Let's pretend that you can identify the forgery, demonstrate that C2PA does not work, and communicate it clearly to the court. It's now your word against every technical expert at Microsoft, Intel, Sony, Arm, DigiCert, and a dozen other big tech companies. Who has more credibility? Hundreds of highly paid security and cryptography professionals or you? And remember: these big companies have their reputations on the line. They have a financial incentive to not be proven wrong

As an online service provider, I've interacted closely with NCMEC and ICACs for over a decade, and with attorneys and law enforcement for even longer. I can tell you that the prosecution won't spend much effort here. The cops will knock on his door. Narayen won't be able to convince the courts how it happened, and he'll either be found guilty or his attorney will convince him to take a plea deal.

Narayen's only option in this fictional scenario is to demonstrate that C2PA does not verify the metadata, the metadata can be altered, anyone can sign anything, and C2PA doesn't provide validated provenance and authenticity -- even though it's in the name: C2 PA . I'm not a lawyer, but I think this option also could show that every company currently selling products that feature C2PA are actively engaged in fraud since they know what they are selling doesn't work.

Either C2PA doesn't work and Narayen walks free, or C2PA works and this forgery sends him to jail. That's the worst case scenario, and it's very realistic.

Truth or Consequences

If this fictional child porn example seems too extreme, then the same application of fake C2PA metadata works with propaganda from wars (Ukraine, Gaza, etc.), insurance fraud, medical fraud, fake passport photos, defective merchandise claims at Amazon and Etsy, altered photojournalism, photo contests, political influences, etc. At FotoForensics, I'm already seeing known fraud groups developing test pictures with C2PA metadata. (If C2PA was more widely adopted, I'm certain that some of these groups would deploy their forgeries right now.)

To reiterate:

• Without C2PA: Analysis tools can often identify forgeries, including altered metadata.
  
• With C2PA: Identifying forgeries becomes much harder. You have to convince the audience that valid, verifiable, tamper-evident 'authentication and provenance' that uses a cryptographic signature, and was created with the backing of big tech companies like Adobe, Microsoft, Intel, etc., is wrong.

Rather than eliminating or identifying fraud, C2PA enables a new type of fraud: forgeries that are authenticated by trust and associated with some of the biggest names on the tech landscape.

A solution for assigning authentication and provenance would go a long way toward mitigating fraud and misrepresentation. Unfortunately, the current C2PA specification is not a viable solution: it fails to authenticate, is trivial to forge, and cannot detect simple intentional tampering methods. It is my sincerest hope that the C2PA and CAI leadership tries to re-engage with the wider tech community and opens discussions for possible options, rather than making sudden unilateral decisions and deploying ad hoc patches (like requiring pay-to-play) that neither address the basic problems nor encourage widespread adoption.

---

Značky: #Forensics, #Network, #Security, #FotoForensics, #Programming

I usually follow a simple mantra: if it can be automated then it should be automated. However, while automation may seem like a great solution, it introduces a new set of perils. Unexpected critical points, untested conditions, and unforeseen failures can lead to new problems.

At FotoForensics , Hintfo , and my other services, I use a lot of automation. I have tools that detect and respond to network attacks, terms of use violations, server monitoring, and basic system management. However, I never just deploy an automation and walk away. I never just assume that it works.

When I release new automated solutions, I usually spend as much time testing, monitoring, and adjusting the new system as I do developing it. Sometimes new problems are identified quickly and are easy to resolve. Some issues take a while to surface, and some have no easy solutions. A few times, I've had automated scripts fail so badly during the initial testing that they had to go back to the drawing board or were treated as a failure and a good learning experience.

Unfortunately, my overly-cautious approach to software deployment seems to be the exception and not the norm. Often, companies deploy automated solutions without any deep review.

What's for dinner?

At our local grocery store, they removed more than half of the checkout aisles and replaced them with self-checkout kiosks. The space required by 3 manual checkout counters can fit six kiosks. In addition, one employee can (frantically) manage all six kiosks rather than one employee per counter. When I visit the grocery store, they usually have 10 of 16 kiosks open with little or no wait. (They open the other six during the busy periods.) And while they still have eight counters available, usually only 1 or 2 are open for the people who don't want to use the self-checkout kiosks.

On the positive side:

• Automation seems to reduce lines at the grocery store. I rarely have to wait for the kiosk. In contrast, grocery stores that don't have automated kiosks usually has long lines even when the store doesn't seem very crowded.
  
• Around here, every store has a "Help wanted" sign. Automation allows the store to operate with fewer employees.
  
• I'm not advocating the replacement of employees with machines. However, the existing employees can be moved to other essential tasks, like restocking shelves and helping customers.

Unfortunately, there is a down side to checkout counter automation:

• Saving money on employees does not translate into lower prices. Because there is less human oversight, it's easier to steal from these automated kiosks. Why pay extra for that "organic" apple when you can choose the lower-cost generic (inorganic?) apple from the kiosk's menu? Or maybe scan one box of Mac and Cheese but put two in the self-bagging area? I suspect that the increase in theft is part of the reason that prices have increased even through employee-related expenses has decreased.
  
• These machines are not always easy to use and customers often need assistance. At my grocery store, self-scanning coupons is usually more miss than hit.

Some stores are starting to re-evaluate their automated self-checkout systems. A few are even removing them altogether.

The problem isn't that the kiosks don't work. Rather, while automation solves some problems, it creates opportunities for new problems.

Neither snow nor rain nor heat nor gloom of night

The grocery store kiosks usually work well. They are mostly easy to use. (Even with coupon scanning problems and the occasional double-scan, I'd give them very high marks.) However, not all kiosk are designed well.

For example, every few years, my bank installs a new ATM machine. Sometimes the machine interfaces are really easy to use, while other versions are confusing and take twice as long to use. You can tell when the ATM interface is bad because more people go into the bank for assistance.

And then there's the US Post Office. It's the holiday season and the Post Office has long lines of people waiting to mail gifts and packages. Our Post Office has a couple of automated self-service kiosk (SSK) machines, but almost nobody is using them. These SSKs have no waiting line and are located right next to the long line of people who are waiting for assistance. (You can't miss these machines!)

It isn't that the SSKs are down or out-of-order. Rather, the user interfaces are designed so incredibly poorly, that people would rather spend 45 minutes waiting in line for human assistance. The few people using these SSKs seem to fall into one of three categories:

• They spent a lot of time earlier learning how to use them, so they know what selections to use.
  
• They think they might battle the confusing interface faster than waiting in the long line. (Sometimes this gamble pays off, sometimes it doesn't.), or
  
• They have a friend holding their place in line, just in case they can't figure out how to use the SSK. (Seriously. You often hear someone say "can you hold my place in line for a moment?" before trying their luck at an SSK.)

Then again, if you succeed in using the Post Office's SSK, you might get asked by a few strangers to help them, too.

Et tu, Etsy?

Etsy is an online marketplace for handmade goods and is the epitome of automation gone wrong. For example, earlier this year , Etsy's rolled out a filter to remove any Etsy listings that also appeared on the Chinese (cheap / knock-off goods) site called Temu. The problem is that some Temu accounts appear to steal images and product descriptions from Etsy. As a result, legitimate Etsy sellers are having their handmade products delisted. In some cases, Etsy even shuts down the legitimate Etsy shop. A few examples from the Etsy forums:

• " Etsy removed my handmade ceramic listing ": A user has repeatedly had their handmade bottles removed. Keep in mind, the bottles look handmade, are signed by the seller, and there are videos showing how she makes the bottles. Another Etsy seller responded:
  

  I had a listing removed two months ago and after opening a support request with videos showing my process I was able to get it reinstated after two weeks of waiting. However, the exact same listing was removed again last week for the same reason so even if you prove you’re handmaking the item, they may still remove it in the future. I’m hoping if they reinstate a listing it doesn’t still count as a strike against your shop since it seems this will continue to happen (in my experience)

  
  
• " China has stole my product and photos! I can't get Etsy to help. ": A seller laments that their product photos are being stolen by knock-off sellers from China.
  
• " Etsy destroyed my store. They are responsible for their own downfall. ": Again, legitimate handmade items were delisted by Etsy because knock-off sellers copied her photos.
  
• " I need some help with handmade policy violation - at wits end ": The seller uses an engraver and uv printer and is having custom items removed. One of the replies identified the likely cause: "The bots are taking over, so they may not be sophisticated enough to distinguish between similar silver tone keychains over a pure white background with similar text/sayings, etc."

A few Etsy users have posted advice for getting products or account reinstated, but your success at any of these tips is really hit-or-miss.

Etsy's Amber Alert

This isn't the only automation and filtering problem at Etsy. Back in 2016, a child died after choking on amber teething beads that had been purchased on Etsy.

I'm not going to dive into this loss of a child or even the merits of the court case. Rather, my focus is on Etsy's reaction: they banned products that included the word "amber". The initial ban appears to have been automated and does not pay attention to the context. "Amber color?" Nope. "Amber is my first name?" Nope. This forum discussion really describes the problem well (my bold for emphasis):

Listings deactivated for using the word amber to describe glass bead colour
by TheBeckoningCat Post Crafter ‎05-14-2022 10:36 AM

Received a deactivation notice from Etsy regarding the word "amber" appearing in my description. I cannot get thru to Support by any means. In my description of the bracelet, I mentioned that the Swarovski squares were of an "amber color". Swarovski, to my knowledge, does not offer any crystals made from amber. I have since changed the description to "honey brown color". Perhaps in the future, when your "bot" or algorithm comes up with results for people selling "amber" a human actually review them to determine whether actual amber is being sold. I just did a simple search for the word "amber" and came up with over 132,000 results, just in the US alone. The people who are selling Amber Heard T-shirts will have to revise their listings as Johnny Depp's ex-wife.

---

Reply by BlackberryDesigns Conversation Maker ‎05-14-2022 11:50 AM

I would get rid of the word Swarovski , also. I got hit on that one from my website. Apparently since making the shift and removing their crystals for sale to the artists, they are doubling down on their brand name and do not want it associated with us little guys.

---

Reply by JDTotesnDolls Community Maker ‎03-14-2022 04:17 PM

The bot is designed to look for the word amber and not to make decisions on whether or not it is a color or an actual bead.

Contact Etsy and ask them to manually review the listings and with the removal of the word, they may okay a relist,

Unfortunately, Etsy's use of the ban-hammer seems inconsistent at best . The Etsy bots appear to use poorly defined rules that are applied irregularly and enforced occasionally, resulting in confusion among their sellers. Adding to the problem, the only real solution is to talk to a human in their support group, and that seems like a Herculean task.

The problems related to bad bots and automated filtering is more than just an inconvenience for users. Some Etsy sellers have reported that scammers are using Etsy's poor filtering services as a front for blackmailing sellers. For example:

( I'm the bot in charge of security ) HELP
by KummLeather Inspiration Seeker ‎09-15-2023 04:49 PM

hello, I received such a message, does anyone have information about this?

"Hello, my name is Jackson, I'm the bot in charge of security. You have received a complaint that you are a scammer, in order that your account was not blocked send me your name and surname, as well as your e-mail.
You will need to be verified today, in the worst case your account will be blocked.
Send me your first name, last name and e-mail!!!!!"

---

Etsy support bot
by Bellayall Inspiration Seeker 09-15-2023 03:56 PM

I just received a message from someone claiming to be an Etsy support bot. He said that the product I shared was reported and asked for my name, surname and email address.I'm new to Etsy and didn't know it was a scam so I gave her what he wanted and then he blocked me. Is this a problem please help

"Is this a problem"? Yes. Yes it is.

Choke Points

A heavy dependency on automation also creates central points of failure in critical systems. Earlier this year, a failed update by the FAA caused thousands of flight cancellations across a wide range of airlines. A few months later, Southwest had their own software failure that caused them to cancel thousands of flights.

Keep in mind, these were not cyber attacks. These were just system failures in critical systems. These single points of failure were associated with the automation of their day-to-day operations. This is why a single computer outage can stop both automated and manual operations.

Ideally, critical services should have failover backups. Ideally, the operators should have tested for these scenarios and had viable workarounds. However, automation often results in unidentified choke points and a lack of immediate options.

This limitation is not restricted to critical infrastructures. Our local library has had a few instances where the self-checkout book kiosks have gone offline. One librarian said the kiosk outage was related to their new weekly backup system. Fortunately, they do have a workaround: They put up "out of order" signs and manually handle checkouts at the front desks.

Welcoming Our New Robot Overlords

Unfortunately, I'm seeing more instances of people relying on automation without testing. I'd cite specific instances of people mistakenly relying on ChatGPT, but there were too many references to choose from! Here's a few examples:

• Legal : An attorney used ChatGPT without checking the results. It made up fake citations. The attorney ended up getting sanctioned by the court.
  
• Legal : A different attorney was suspended after using ChatGPT and not noticing that it was citing fake cases.
  
• Legal : Another attorney was fired after using ChatGPT.
  
• Medical : Researchers found that ChatGPT was usually wrong when responding to a medical question. (It was correct 10 out of 39 times.)
  
• Summarization : When asked to generate automated summaries, ChatGPT often makes up results.
  
• Factuality : Poynter reported that, when fact-checking results, ChatGPT sometimes reached accurate conclusions, but "struggled to give consistent answers, and sometimes was just plain wrong."

Just because a solution is deployed, doesn't always mean it's a perfect solution.

A few companies have managed to get automation to work quite well. For example, I recently needed to return an item to Amazon. I went down to my local Whole Foods (where Amazon has a kiosk) and was able to effortlessly follow the instructions to return the item. (The hardest part was opening the cellophane bag that they provided.)

I also drove through Kansas this summer. Part of the trip included a tollway. I had affixed the free tollway pass to my car a month earlier. As a result, I managed to bypass the long line of cars at the tollbooth and I never came to a stop. This was easy and much less expensive than paying at the booth.

It seems to me that the success of the automation really comes down to the company's focus. Companies that are consumer-focused, like Amazon, the Kansas tollway, and the grocery store, have fewer usability problems but introduce new potential venues for fraud. In contrast, profit and process-oriented automated, like Etsy and the Post Office, seem to generate more problems than they attempt solve.

---

Značky: #Forensics, #Programming, #AI, #Network

I recently presented a short version of my " No-NOC Networking " talk to a room full of managers C-level executives, policy makers, and technical evangelists. These are not the people in a network operation center (NOC), but it did include people who manage the people in the NOCs. For this presentation, I lowered the technical level to someone who hasn't taken a basic networking class in years. The talk was very positively received.

Most of the questions were exactly as I expected, like "Where can I get your software?" and "What were those Linux commands to turn off scanner responses?" (The answer to both is at the Nuzzle web site). But there were also a few people who had the same kind of unexpected request: Where can I learn more?

They weren't asking about learning more ways to deter network attackers. Rather, they were asking about where they could learn more about security in general. A few people confided that they weren't sure if they were too old to learn.

Full stop: You are never too old to learn about security. Whether you are looking for a late-in-life occupational change or just a new hobby, you can always learn this as a new skill.

Where to Start?

I often hear people talking about starting with a certification, like CISSP , CEH (certified ethical hacker), or some of the SANS courses. However, I think that's like diving into the deep end of the pool. (As an aside: this isn't a recommendation for any of these certifications. As someone who tracks down cyber bad guys for a living, I've seen more unethical behavior from people with CEH credentials than any other group!)

Before you get too deep or start paying for some kind of education, start by finding out what you like. There isn't just one kind of "computer security". What's your interest? Here's a short sample of different cyber areas:

• Cryptography (great for math and puzzle people)
• Network security
• Policy
• Reverse-engineering
• Social engineering
• Red team (offense)
• Blue team (defense)
• Hardware and IoT (internet of things)
• Software (fuzzing is fun!)
• Physical security, including lock-picking
• Anonymity and privacy
• AI and counter-AI (yes, there's a security element)

This is far from everything. Most of these categories include forensics (detection) and anti-forensics (avoiding detection).

Don't know which one to choose? Try them all and find what you like! (Personally, I like the weird stuff, like file format forensics and packet-level network forensics. But I've also worked with everything else in this list.)

Groupies

Besides trying to learn on your own, there are tons of conferences . Most weeks have multiple conferences worldwide. While conferences usually require paid admission, a few are free or even online.

There are also tons of meet-up groups. Many of these groups are part of larger organizations. For example:

• The Open Worldwide Application Security Project (OWASP) started with a focus on web-security best practices. However, it has evolved. Today, it mostly focuses on policies and processes for securing generalized applications. The organization has individual satellite chapters that hold monthly meetings all over the world.
  
• DEF CON is a huge hacker conference that is held once a year. However, it has spawned lots of smaller " DEF CON groups " that meet monthly. Most are identified by their telephone area code. For example, Denver is area code 303, so their local DEF CON group is " DC303 ". Unlike OWASP, the DC groups usually have topics that span the entire spectrum -- software, hardware, social engineering, etc. Often, they include live demonstrations and how-to information. Some of these groups meet in person, while others are online.
  
  If you're new to DC groups and you don't like one topic, then wait a minute and there will be a different topic. The only warning: the content can be extremely detailed and discussions may quickly go over your head.

Most of these groups are friendly, helpful, and welcoming to new people. Also, most of them look down on using technology for evil, malicious, or illegal purposes. You're not going to learn how to compromise your ex's Facebook account or how to steal money from an online transaction.

Can't find a local group? Try using Meetup . Search for your city and the "Technology" category. In Fort Collins (where I am), we have "Women Who Code", "Fort Collins Internet Professionals" (FCIP), Northern Colorado Hackers (NoCo Hackers), a couple of Python developer groups, web developer groups, and more. And keep in mind, Fort Collins isn't a "big city"; big cities have even more groups. Unless you're out in the middle of nowhere (sorry, Casper, Wyoming ), there's probably something nearby.

Hands On

Beyond groups, many organizations offer various games where you can try tools, techniques, and methods in a controlled and safe environment. (I liken it to how cats sharpen their claws.) The games often include different skill levels, from newborn novice to guru expert. In my opinion, the real-world problems are nowhere near as difficult as the harder games.

So how can you find these games?

If you ask in any of the social groups (OWASP, DC, etc.) then someone is bound to provide some suggestions. But even without group participation, there are lots of 'capture the flag' (CTF) opportunities out there. These include challenges and puzzles that award points for completion. Some are meant for individuals, while others permit teams. (Often, teams are looking for new members. It's usually easy to find a team that will take on a new person.) Some of the better-known CTFs include:

• CTF101 : The challenges include forensics, cryptography, and more.
  
• PicoCTF (login required) and Hacker101 CTF (login required) includes practice levels, challenges, and competitions.
  
• The National Cyber League and Try Hack Me both provide more formal learning environments.

If you really enjoy these CTF games, then there are competitive teams. Many of the larger conferences have CTF contests with prizes for the winners.

Personally, I find game play to be a great way to teach and test knowledge. At my FotoForensics service, I include a few ' Challenges ' (Tutorials → Training → Challenges) where people can try to evaluate pictures in a controlled environment.

New Tricks for Old Dogs

Just as there are different security focuses, there are also different ways to learn. Regardless of whether you prefer self-paced, hands-on, one-on-one, or a classroom environment, there are plenty of options. After you find your interest and get a taste of the technologies, then you can start focusing on formal certifications and professional education... or you can be an informed amateur.

Most companies, universities, and news outlets focus on cybersecurity as a career . (OMG! 650,000 cyber jobs are now vacant !) However, it doesn't have to be a career. These topics have benefits even in small amounts. With a little practice, you will start noticing fraud and scams, identifying poor security practices, and distinguishing the real threats from hype. The fundamentals used to include reading, writing, and arithmetic. Then it expanded to some computer literacy. Today, a little computer security knowledge is becoming a fundamental requirement. It's time to start learning!

---

Značky: #Forensics, #Programming, #Security, #Conferences, #Network