C2PA-camera's overleven het contact met de realiteit niet

Je hebt misschien gehoord dat C2PA een technologie is die ons wonderbaarlijk genoeg zal redden van wijdverspreide AI-vervalsingen, door camera's de beelden die ze vastleggen cryptografisch te laten ondertekenen. Hoera voor de cryptografie!

Helaas gaat dat niet werken. Er speelt veel mee, dus ik zal zo snel mogelijk ter zake komen:

• C2PA-camera-apps op het Android-platform vertrouwen op Key Attestation en/of Google Play Integrity om te voorkomen dat gebruikers de app aanpassen om willekeurige bestanden te ondertekenen (in tegenstelling tot data van de beeldsensor van het apparaat).
• Het kunnen ondertekenen van willekeurige bestanden doorbreekt het vertrouwensmodel van C2PA.
• Root privilege escalation (LPE) exploits doorbreken het beveiligingsmodel van Android's Key Attestation, en evenzo Play Integrity.
• Android-apparaten kunnen worden geroot via goedkope hardware fault injection-aanvallen.
• Hardware-kwetsbaarheden in bestaande apparaten kunnen niet worden gepatcht (hier zit nuance in, die ik later bespreek).

Kortom: C2PA op het Android-platform is kapot, op een manier die realistisch gezien niet gepatcht kan worden. Niets van het bovenstaande is een "0day"; het is minstens 90 dagen geleden gemeld bij de relevante partijen (hoewel iedereen met een beetje gezond verstand dit had kunnen voorzien).

Maar dat is niet alles. Mede dankzij LLM's komen root-LPE's sneller op de markt dan Google patches kan uitbrengen. Op het moment van schrijven bestaan er one-click root exploits in het wild voor volledig gepatchte Google Pixel-apparaten (via CVE-2026-43499). Hiermee kan iedereen C2PA-vervalsingen produceren zonder dat daar hardware-aanvallen voor nodig zijn. Later in dit artikel leg ik uit hoe dit werkt.

Ik focus me hier op Android. Ik laat Google maar uitleggen waarom: de Pixel Camera-app behaalde Assurance Level 2, de hoogste beveiligingsscore die momenteel is gedefinieerd door het C2PA Conformance Program. Assurance Level 2 voor een mobiele app is momenteel alleen mogelijk op het Android-platform.

Ik val dus de "sterkste" implementatie aan, puur om een punt te maken. Als bewijs kan ik wijzen naar AI-gegenereerde beelden die volgens C2PA echte, onbewerkte foto's zijn, rechtstreeks uit de Pixel Camera-app, of YouTube-video's waarvan de infobox beweert dat ze "met een camera zijn opgenomen", terwijl dat niet het geval is.

Apple is naar verluidt bezig met een eigen oplossing voor media provenance, maar die bestaat nog niet. Ik vermoed dat hun verticale integratie hen een significant voordeel zal geven, wat de aanvalsmogelijkheden zou kunnen verschuiven naar het optische domein (zoals het maken van foto's van schermen).

Hoe doorbreekt root LPE de "hardware-backed" key attestation?

Attestatie bevestigt slechts bepaalde zaken, waaronder:

• Of de bootloader is vergrendeld.
• Of de AVB-sleutels die van de fabrikant zijn.
• Of het apparaat de nieuwste beveiligingsupdate draait.

De "normale" manier om een Android-apparaat te rooten is het ontgrendelen van de bootloader en het flashen van een aangepast firmware-image, wat een fabrieksreset van het apparaat forceert. Attestatie zal dan aangeven dat de bootloader is ontgrendeld, waarna Google weigert C2PA-sleutels aan het apparaat toe te kennen.

Echter, als je een apparaat root via een exploit, heeft het attestatiemechanisme geen betrouwbare manier om dit op te merken. De bootloader is nog steeds vergrendeld, de AVB-sleutels zijn ongewijzigd en het apparaat draait nog steeds de beveiligingsupdate waarmee het initieel is opgestart. De servers van Google zullen daarom gewoon sleutels toekennen aan een gecompromitteerd apparaat.

De C2PA-sleutels worden nog steeds beschermd door hardwarebeveiliging binnen StrongBox (in Titan M2 op nieuwere Pixel-apparaten). Dit voorkomt dat een aanvaller de sleutels fysiek uit het apparaat haalt, zelfs met root-rechten. Een aanvaller heeft de ruwe sleutelmateriaal echter niet nodig. Met root-rechten kunnen ze StrongBox simpelweg vragen om deze sleutels te gebruiken om willekeurige data te ondertekenen, waardoor C2PA-vervalsingen kunnen worden gemaakt.

De theorie achter het ontwerp is dat bekende software-LPE's gepatcht zouden moeten worden, waarna de Relying Party (de entiteit die het attestatierapport verifieert) kan eisen dat gebruikers updates installeren. Maar CVE-2026-43499 bewijst dat tijdige patches niet altijd beschikbaar zijn. Daarnaast blijven er twee problemen over:

1. Elke redelijk gefinancierde entiteit (van overheden tot forensische bedrijven) kan een voorraad private exploits opbouwen.
2. Er bestaan goedkope hardware-exploits, ongeacht het patch-niveau.

Hoe heb ik de demo-beelden en video's ondertekend?

Aanvankelijk gebruikte ik een hardware-aanval, voortbouwend op mijn eerdere onderzoek: "Can You Get Root With Only a Cigarette Lighter?". Omdat software-only exploits veel gemakkelijker zijn, bewaar ik de volledige hardware-details voor een andere keer; hardware-exploits kunnen immers grotendeels niet worden gepatcht.

Voor wie mijn bevindingen wil reproduceren, raad ik de Root My Pixel-tool aan. Na het verkrijgen van root is de rest van de aanval puur een kwestie van "leidingwerk". Ik heb hiervoor een tool gemaakt: keystork. keystork heeft een client/server-architectuur, waardoor client-code willekeurige operaties kan uitvoeren tegen de KeyStore API terwijl het zich voordoet als elke geïnstalleerde app.

Hier is een PoC-script om willekeurige afbeeldingen te ondertekenen via de Pixel Camera-app: https://gist.github.com/DavidBuchanan314/fa0ffdaaaa31594e6a511118c1cea1e1118c1cea1e0

Kunnen hardware-aanvallen worden beperkt?

In theorie ja, in de praktijk eigenlijk niet. Mijn initiële strategie (het flippen van bits in PTE's) werkt nog steeds op Pixel-apparaten. Het werkt echter niet op Samsung-apparaten.

Samsung maakt gebruik van "RKP" (Real-time Kernel Protection), waarbij een EL2-hypervisor extra bescherming biedt aan bepaalde geheugenregio's. Hoewel ik nog steeds bits in PTE's kan flippen via glitching, staat EL2 me niet toe deze te overschrijven, wat essentieel was voor mijn exploit.

Op hardwareniveau bestaan er oplossingen die extern DRAM als volledig onbetrouwbaar behandelen, zoals Intel MEE en Apple's SEP Memory Protection Engine. Deze zijn echter niet performant genoeg om de volledige Android-linuxkernel binnen te draaien.

Om C2PA op Android echt te repareren, zou de gehele softwarestack opnieuw moeten worden ontworpen. De volledige image-processing pipeline, inclusief alle AI-functies, zou in een secure enclave met sterke hardwarematige geheugenbescherming moeten draaien. Ik vermoed dat Google dit niet gaat doen, wat waarschijnlijk de reden is dat ze mijn rapport sloten met de status: "Won't fix (infeasible)". Het is immers zinloos om zoveel architecturale wijzigingen door te voeren als je nog steeds geen "foto van een scherm"-aanvallen kunt stoppen.

Ondanks de WONTFIX-resolutie gaf Google me een bounty van $7500. Ze gaven aan dat hardware-glitching en side-channel aanvallen formeel buiten hun bug bounty-programma vallen, maar dat mijn bevindingen waardevol waren. Dit is een belangrijk punt: de meest voor de hand liggende C2PA-aanvalsvector valt buiten het bereik van Google's VRP, waardoor het VRP de Android C2PA-implementaties niet effectief beschermt.

Hoe groot is de impact?

Hoewel ik me richtte op de Pixel Camera-app, zijn er diverse andere "C2PA Camera"-apps op Android. Alle apps die ik heb onderzocht, vertrouwen op Key Attestation of Play Integrity. Ze zijn allemaal op dezelfde manier kwetsbaar. Dit betekent dat je niet eens een Pixel-apparaat nodig hebt; je kunt het goedkoopste en meest kwetsbare apparaat in het Android-ecosysteem kiezen om je exploit op uit te voeren.

Een volledige lijst van "conforme" C2PA-implementaties is beschikbaar. Alle implementaties die AndroidKeyAttestation of GooglePlayIntegrity in hun lijst met attestatiemethoden hebben staan, zijn waarschijnlijk kwetsbaar.

Naast C2PA heb ik mijn hardware-glitching strategie gebruikt om diverse andere Android-apparaten te rooten, waaronder een Amazon Fire TV stick en een Meta Quest 3s VR-headset. Opvallend is dat Meta de CVE-2026-43499 LPE op Quest-headsets al begin van de maand heeft gepatcht om valsspelen in VR-games te voorkomen, terwijl Google nog geen patch heeft uitgebracht voor hun eigen Pixel-vlaggeschip.

Dankwoord

Ik wil Dr. Neal Krawetz van Hacker Factor bedanken, die al jaren aan de bel trekt over C2PA. Ook dank aan de Provenance and Authenticity Standards Assessment Working Group (PASAWG), die evenzeer onderzoek doen naar de effectiviteit van C2PA.

Laatste opmerking

Tijdens het voorbereiden van mijn PoC stuitte ik op een kwetsbaarheid voor het lekken van private sleutels. Ik heb dit twee dagen geleden gemeld aan Google en zij lijken het gisteren te hebben gepatcht. Hoewel Google deze specifieke sleutel nu waarschijnlijk heeft ingetrokken, controleren de meeste C2PA-verificatietools niet op intrekking (revocation). Ik ben er zeker van dat ze dat ook snel zullen oplossen.