Forscher knackt C2PA-Fotonachweise auf Android, Google behebt es nicht

Der Sicherheitsforscher David Buchanan veröffentlichte am 25. August 2026 einen Bericht. Darin heißt es, Android-Telefone könnten dazu gebracht werden, gefälschte Fotos zu signieren, als hätte eine echte Kamera sie aufgenommen. Das bricht genau das eine Versprechen, für das die Technik existiert. Google prüfte seine Ergebnisse, zahlte eine Bug-Bounty von 7.500 Dollar und schloss den Bericht mit dem Vermerk „Won't fix (infeasible)", also nicht behebbar.

Die Technik heißt C2PA, kurz für Coalition for Content Provenance and Authenticity. Sie hängt an ein Foto einen signierten Datensatz, ein Content Credential. Dieser gibt an, welches Gerät oder welche App das Bild erzeugt hat. Der Zweck ist, ein echtes Kamerafoto von einem Bild zu unterscheiden, das ein generatives KI-Modell erfunden hat. Buchanans Schlussfolgerung ist unmissverständlich: „C2PA auf der Android-Plattform ist kaputt, und zwar auf eine Weise, die sich realistisch nicht patchen lässt."

Was Google für seine Pixel-Umsetzung zugesagt hat

Google stellte Pixel 10 als erste Telefonreihe mit Content Credentials in jedem Foto vor. Der Beitrag ist auf den 10. September 2025 datiert und von Eric Lynch und Sherif Hanna. Laut dem Beitrag erreichte Pixel Camera „Assurance Level 2, die höchste Sicherheitsbewertung, die das C2PA Conformance Program derzeit definiert".

Googles Beitrag beschreibt eine Kette von Hardware-Prüfungen hinter dieser Bewertung. Android Key Attestation belegt, dass ein Signaturschlüssel in einem geschützten Chip erzeugt wurde. Der Sicherheitschip Titan M2 speichert den Schlüssel so, dass Software ihn nicht lesen kann. Remote Key Provisioning vergibt Zertifikate nur an das, was Google eine „Play Protect Certified version of Android" nennt. Eine Uhr im Chip Tensor G5 versieht Fotos auch ohne Netz mit einem Zeitstempel. Google nutzt zudem eine Strategie, die es „One-and-Done" nennt. Dabei signiert jeder Schlüssel genau ein Bild, sodass sich zwei Fotos nicht demselben Telefon zuordnen lassen.

Wo die Kette gerissen ist

Buchanan nahm sich den Attestierungsschritt vor, nicht die Schlüsselspeicherung. Sein Bericht sagt, Android Key Attestation und Google Play Integrity ließen sich beide aushebeln. Ein kompromittiertes Telefon kann Googles Server damit weiterhin von seiner Vertrauenswürdigkeit überzeugen und ein gültiges Signaturzertifikat abholen. Zwei getrennte Angriffe schafften das.

Der erste ist Software. Buchanan berichtet, ein Root-Exploit mit einem Klick, geführt als CVE-2026-43499, setze die Attestierungsprüfung außer Kraft. Das Telefon ist vollständig kompromittiert und gilt trotzdem als vertrauenswürdig. Der zweite Angriff ist Hardware-Fehlerinjektion: elektromagnetisches Glitching gegen den DRAM-Speicher des Telefons, damit der Chip sich in einem gewählten Moment falsch verhält. Buchanan berichtet, so das Hardware-Sicherheitsmodul StrongBox umgangen zu haben.

Getestetes Gerät	Gemeldete Methode
Pixel 8a	Software-Root-Exploit
Pixel 9a	Root-My-Pixel, Root mit einem Klick
Samsung A07	Umgehung der Attestierung
Amazon Fire TV Stick	Umgehung der Attestierung
Meta Quest 3S	Umgehung der Attestierung

Die Software-Lücke lässt sich patchen. Die Hardware-Lücke ist der Grund, warum Buchanan das Problem für dauerhaft hält. Das Glitchen eines Speicherchips ist ein physischer Angriff auf Silizium, das bereits in den Händen der Nutzer ist. Kein Software-Update ändert dieses Silizium. Das ist die Lücke hinter Googles Urteil „infeasible".

Man beachte, wo das Versagen liegt. Beide Angriffe richten sich auf die Prüfungen, die entscheiden, ob ein Telefon überhaupt ein Zertifikat verdient. Ein Telefon, das nicht qualifiziert sein sollte, kann einen legitimen Schlüssel erhalten. Danach kann es signieren, was es will.

Was das für Entwickler bedeutet

Behandeln Sie ein gültiges Content Credential als Hinweis über Software, nicht als Beweis über die Realität. Es sagt Ihnen, dass eine Signatur gegen eine Zertifikatskette geprüft wurde. Es sagt Ihnen nicht, dass eine Kamera auf eine echte Szene gerichtet war. Wenn Sie eine Prüfstrecke, ein Redaktionswerkzeug oder einen Marktplatz mit Upload-Kontrolle bauen: schreiben Sie keine Codepfade, die ein Bild automatisch freigeben, weil das Credential gültig war. Behalten Sie den manuellen Prüfschritt, den Sie streichen wollten.

Prüfen Sie, was Ihre Verifikationsbibliothek tatsächlich zurückgibt. Assurance Level 2 ist eine Aussage über die Konformität der aufnehmenden App, nicht über die Szene. Geben Sie die Stufe und das ausstellende Zertifikat in Ihren eigenen Logs und in der Oberfläche aus, statt alles auf einen Boolean zu reduzieren. Wer „Pixel Camera, Assurance Level 2" sehen kann, kann es abwägen. Wer nur ein grünes Häkchen sieht, kann es nicht.

Diese Asymmetrie sollte man einplanen. In der negativen Richtung ist C2PA weiterhin nützlich: ein fehlendes oder ungültiges Credential ist ein echtes Signal, dass etwas entfernt, bearbeitet oder generiert wurde. Ein vorhandenes und gültiges hat jetzt eine bekannte Obergrenze bei seiner Aussagekraft. Ordnen Sie Ihre Vertrauenssignale entsprechend. Behalten Sie mindestens eines, das nicht davon abhängt, dass das Gerät ehrlich ist, etwa eine Herkunft, die Sie beim Upload selbst erfasst haben.

Achten Sie schließlich genauso auf das Ergebnis der Offenlegung wie auf den Exploit. Google zahlte die Bounty und lehnte den Fix ab. Das ist eine ehrliche Antwort und kein Dementi. Es sagt Ihnen, dass das Bedrohungsmodell des Standards Hardware voraussetzte, die hält. Wenn in Ihrer Produkt-Roadmap „Verifikation mit Content Credentials" als Vertrauens-Meilenstein steht, muss diese Zeile vor dem Release umformuliert werden.