Google's Anti-Deepfake Chip Just Signed an AI Frog as Real

TL;DR

On 25 August, security researcher David Buchanan published a working recipe for making an AI-generated image carry a valid C2PA signature that says it came straight out of a Google Pixel camera, unedited. He did not pick a soft target. He went at Pixel Camera, which Google says is the only mobile app to reach Assurance Level 2, "the highest security rating currently defined by the C2PA Conformance Program." Google closed his report with the status "Won't fix (infeasible)" and paid him a $7,500 bounty anyway.

The signing key was never the weak part

C2PA Content Credentials work by having the capture device cryptographically sign the pixels it recorded. If the signature verifies against a trusted camera certificate, the theory goes, the image is real. The whole model collapses the moment someone can sign a file that did not come from the image sensor.

Google's defense against that is not one thing but two: Android Key Attestation and Play Integrity, backed by StrongBox key storage inside the Titan M2 chip. Google describes Titan M2 as Common Criteria PP.0084 AVA_VAN.5 certified, "strongly resistant to extracting or tampering with the cryptographic keys stored in it."

That claim is true, and irrelevant. Buchanan never extracted a key. In his words: "an attacker does not need the raw key material! As root, they can ask StrongBox to use these keys to sign whatever data they like."

Think of StrongBox as a vault you genuinely cannot crack, bolted to the floor of a house whose front door now opens with a one-click exploit. The key never leaves the vault. It does not have to. Root walks into the room and asks the vault to sign whatever it slides under the slot.

Rooted, while the bootloader reports all clear

The reason attestation does not catch this is a gap in what it measures. Attestation checks whether the bootloader is locked, whether the AVB keys are the vendor's, and whether the device is on the current security patch. Unlock the bootloader and flash a modified image and every one of those flags trips, and Google refuses to provision C2PA keys.

Root the device through a privilege-escalation exploit instead and none of them move. The bootloader is still locked, the AVB keys are untouched, and the device is running the same build it booted with. It is a burglar coming through a window while the deadbolt stays engaged, and the alarm panel cheerfully reports the front door secure. Google's servers hand over C2PA keys to a fully compromised phone.

Buchanan says one-click root exploits for fully patched Pixel devices are already in the wild via CVE-2026-43499, a use-after-free in the Linux kernel's rtmutex code rated CVSS 3.1 7.8 and published on 21 May 2026. He reproduced the attack on a Pixel 8a and 9a using the public Root My Pixel tool, then wrote keystork, a client/server bridge that performs arbitrary KeyStore operations while impersonating any installed app. The rest, he notes, "is just plumbing." He shipped a sign-any-image proof-of-concept script against Pixel Camera.

His demos are still up: an AI-generated frog that the official Content Credentials verifier reads as an unedited Pixel photo, and a YouTube video whose infobox claimed it was captured with a camera. Google's response to the second one, per his edit note timestamped 2026-08-25T19:12:16Z, was to manually delete the "Captured with a camera" section from that video's description. Hand-editing a caption is not a cryptographic countermeasure.

The half no patch reaches

Software exploits get patched eventually. Buchanan's original path in did not depend on them. It grew out of his earlier work rooting Android devices with low-cost hardware fault injection against external DRAM, an attack that does not care about your patch level.

There is genuine nuance here, and he gives it: his bit-flipping technique against page table entries stopped working on a Samsung device after an update enabled Samsung's Real-time Kernel Protection, which uses an EL2 hypervisor to guard certain memory regions. He can still flip the bits and cannot overwrite the mapping. He has alternate strategies planned and has not shipped them.

The structural point survives that caveat. Fully mitigating bus-faulting attacks means treating external DRAM as untrusted, which needs something like Intel's memory encryption engine or Apple's SEP Memory Protection Engine. Neither is fast enough to run a whole Android kernel inside. Fixing this properly would mean moving the entire image pipeline, AI processing included, into a secure enclave with hardware memory protection. Nobody is going to do that, and if they did it would still not stop someone photographing a screen.

How much of the ecosystem sits on this

We pulled the C2PA conformance list to size the blast radius. It holds 174 conformant product records. Twenty of them, covering 15 distinct products from 9 organizations, cite Android Key Attestation or Play Integrity as an attestation method. That set includes Pixel Camera, Google Photos, Pixel Studio, Pixel Recorder, Google Messages, YouTube, YouTube Create, Proofmode for Android, and several independent "prove this photo is real" apps.

The concentration at the top tier is worse. Only seven records in the entire list reach Assurance Level 2. Five of those seven depend on Android attestation, spread across three products: Pixel Camera (three separate records), GreenCheckmark for Android, and VWFNDR MBL Android. The remaining two are EZDRM's DynamicSigner, which attests via AWS Nitro Enclaves and Azure, and Qualcomm's Snapdragon 8 Elite Gen 5.

Non-Pixel apps are worse off than Pixel itself, not better. If your app trusts Play Integrity on any Android device, an attacker picks the cheapest, most exploitable handset in the ecosystem and runs the attack there.

Won't fix, and the bounty explains why

Google's rejection reason is the most useful artifact in the whole disclosure. Hardware glitching and side-channel attacks are formally out of scope for the Vulnerability Reward Program, and the team said so while paying out anyway: "our security team found your findings valuable, and the data you provided will help us improve future iterations of the product."

Buchanan draws the obvious conclusion. If the most direct attack on Android C2PA is out of scope for the bug bounty, the bounty does not protect Android C2PA. He also notes the reporting was done over 90 days ago and none of it is a zero-day, and that while poking at his proof-of-concept he stumbled into a separate private key disclosure bug, reported it, and watched Google patch it within a day. Most C2PA verification tools, he adds, do not check certificate revocation.

What this changes if you build with provenance

• A valid C2PA signature is now evidence of a signing key, not evidence of a camera. Treat "Content Credentials verified" as one weak signal in a stack, never as proof of capture.
• Check revocation. If your verifier does not fetch and honor revocation state, a leaked or abused certificate stays green in your UI indefinitely.
• Assurance Level is a procurement label, not a threat model. Level 2 tells you which attestation method a vendor claimed, and both dominant methods on mobile now have public bypasses.
• Absence of provenance still means nothing. The failure mode that matters most is the inverse: teaching users that unsigned means fake, when almost all real media is unsigned.

The uncomfortable part is that none of this was a surprise to the people who study it. Dr. Neal Krawetz of Hacker Factor has been publishing on C2PA's weaknesses for years, and the Provenance and Authenticity Standards Assessment Working Group exists specifically to evaluate whether these schemes hold up. The standard shipped into flagship phones anyway.

Key Takeaways

• C2PA signing on Android is forgeable by anyone with root, because StrongBox protects key material but not key use, and Buchanan published the tooling to do it.
• Attestation cannot see exploit-based root: the bootloader stays locked, AVB keys stay clean, and Google's servers provision C2PA keys to a compromised device.
• The target was Pixel Camera at Assurance Level 2, the highest tier the C2PA Conformance Program defines and, per Google, only achievable on Android.
• Of 174 conformant records, 20 cite Android Key Attestation or Play Integrity; 5 of the 7 Level 2 records depend on them.
• Google marked the report "Won't fix (infeasible)" and paid $7,500, confirming that the most direct attack path is outside its bug bounty's scope.
• Hardware fault injection against DRAM works regardless of patch level, so the software half is a treadmill and the hardware half is permanent on current devices.

Sources: C2PA Cameras Do Not Survive Contact With Reality (David Buchanan), Google Security Blog on Pixel C2PA Content Credentials, C2PA conforming products list, NVD: CVE-2026-43499, keystork, C2PA