Un chercheur casse les certificats photo C2PA sur Android, Google ne corrigera pas

Le chercheur en sécurité David Buchanan a publié un rapport le 25 août 2026. Il y affirme que des téléphones Android peuvent être amenés à signer de fausses photos, comme si un véritable appareil les avait prises. Cela brise la seule promesse qui justifie l'existence de cette technologie. Google a examiné ses conclusions, versé une prime de 7 500 dollars et clos le rapport avec la mention « Won't fix (infeasible) », soit impossible à corriger.

La technologie s'appelle C2PA, pour Coalition for Content Provenance and Authenticity. Elle attache à une photo un enregistrement signé, appelé Content Credential. Cet enregistrement indique quel appareil ou quelle application a produit l'image. Le but est de distinguer une vraie photo d'appareil d'une image inventée par un modèle d'IA génératif. La conclusion de Buchanan est sans détour : « C2PA sur la plateforme Android est cassé, d'une manière qu'il n'est pas réaliste de corriger par un correctif. »

Ce que Google garantissait pour son implémentation Pixel

Google a présenté le Pixel 10 comme la première gamme de téléphones avec des Content Credentials dans chaque photo. La publication est datée du 10 septembre 2025 et signée Eric Lynch et Sherif Hanna. Selon ce texte, Pixel Camera a atteint « Assurance Level 2, la plus haute note de sécurité actuellement définie par le C2PA Conformance Program ».

La publication de Google décrit une chaîne de vérifications matérielles derrière cette note. Android Key Attestation prouve qu'une clé de signature a été créée à l'intérieur d'une puce protégée. La puce de sécurité Titan M2 stocke la clé de sorte qu'aucun logiciel ne puisse la lire. Remote Key Provisioning ne délivre des certificats qu'à ce que Google appelle une « Play Protect Certified version of Android ». Une horloge interne à la puce Tensor G5 horodate les photos même sans réseau. Google utilise aussi une approche qu'il nomme « One-and-Done ». Chaque clé signe exactement une image, si bien que deux photos ne peuvent pas être rattachées au même téléphone.

Là où la chaîne a cédé

Buchanan a visé l'étape d'attestation, non le stockage des clés. Son rapport indique qu'Android Key Attestation et Google Play Integrity peuvent tous deux être contournés. Un téléphone compromis peut donc encore convaincre les serveurs de Google qu'il est digne de confiance, et récupérer un certificat de signature valide. Deux attaques distinctes y sont parvenues.

La première est logicielle. Buchanan rapporte qu'un exploit de root en un clic, suivi sous la référence CVE-2026-43499, met hors service la vérification d'attestation. Le téléphone est entièrement compromis et passe malgré tout pour fiable. La seconde attaque est une injection de fautes matérielle : un glitch électromagnétique dirigé vers la mémoire DRAM du téléphone, pour faire mal fonctionner la puce à un instant choisi. Buchanan rapporte avoir contourné ainsi le module de sécurité matériel StrongBox.

Appareil testé	Méthode rapportée
Pixel 8a	exploit de root logiciel
Pixel 9a	Root-My-Pixel, root en un clic
Samsung A07	contournement de l'attestation
Amazon Fire TV Stick	contournement de l'attestation
Meta Quest 3S	contournement de l'attestation

La faille logicielle peut être corrigée. La faille matérielle explique pourquoi Buchanan juge le problème permanent. Glitcher une puce mémoire est une attaque physique sur du silicium déjà entre les mains du public. Aucune mise à jour logicielle ne change ce silicium. C'est l'écart derrière le verdict « infeasible » de Google.

Notons où se situe l'échec. Les deux attaques visent les vérifications qui décident si un téléphone mérite un certificat. Un téléphone qui ne devrait pas être éligible peut se voir délivrer une clé légitime. Ensuite, il peut signer ce qu'il veut.

Ce que cela signifie pour les développeurs

Traitez un Content Credential valide comme un indice sur le logiciel, pas comme une preuve sur la réalité. Il vous dit qu'une signature a été vérifiée face à une chaîne de certificats. Il ne vous dit pas qu'un appareil photo était braqué sur une scène réelle. Si vous construisez une chaîne de vérification, un outil de rédaction ou une place de marché qui contrôle les envois, n'écrivez pas de chemins de code qui approuvent automatiquement une image parce que le certificat est passé. Gardez l'étape de relecture manuelle que vous pensiez supprimer.

Vérifiez ce que votre bibliothèque de vérification renvoie réellement. Assurance Level 2 est une affirmation sur la conformité de l'application de prise de vue, pas sur la scène. Exposez le niveau et le certificat émetteur dans vos propres journaux et votre interface, plutôt que de tout réduire à un booléen. Un relecteur qui peut voir « Pixel Camera, Assurance Level 2 » peut le pondérer. Un relecteur qui ne voit qu'une coche verte ne peut pas.

Cette asymétrie mérite d'être anticipée. Dans le sens négatif, C2PA reste utile : un certificat absent ou invalide est un vrai signal que quelque chose a été retiré, modifié ou généré. Un certificat présent et valide a désormais un plafond connu quant à ce qu'il prouve. Classez vos signaux de confiance en conséquence. Gardez-en au moins un qui ne dépende pas de l'honnêteté de l'appareil, par exemple une provenance que vous enregistrez vous-même à l'envoi.

Enfin, observez le dénouement de la divulgation autant que l'exploit. Google a payé la prime et refusé le correctif. C'est une réponse honnête plutôt qu'un démenti. Cela vous indique que le modèle de menace de la norme supposait un matériel qui tient. Si votre feuille de route produit affiche « vérifier avec Content Credentials » comme jalon de confiance, cette ligne doit être reformulée avant la mise en production.