Un investigador rompe las credenciales de foto C2PA en Android y Google no lo corregirá
4 min de lectura
En cifras
- $7,500
- bounty Google paid for the report
- 90+
- days of coordinated disclosure before publication
- 5
- devices whose attestation was bypassed
El investigador de seguridad David Buchanan publicó un informe el 25 de agosto de 2026. Allí afirma que se puede hacer que teléfonos Android firmen fotos falsas como si las hubiera tomado una cámara real. Eso rompe la única promesa que justifica la existencia de esta tecnología. Google revisó sus hallazgos, pagó una recompensa de 7.500 dólares y cerró el informe con la nota «Won't fix (infeasible)», es decir, no viable de corregir.
La tecnología se llama C2PA, sigla de Coalition for Content Provenance and Authenticity. Adjunta a una foto un registro firmado, llamado Content Credential. Ese registro indica qué dispositivo o aplicación produjo la imagen. El objetivo es distinguir una foto real de cámara de una imagen inventada por un modelo de IA generativa. La conclusión de Buchanan es tajante: «C2PA en la plataforma Android está roto, de una forma que no se puede parchear de manera realista».
Qué garantizaba Google en su implementación de Pixel
Google presentó el Pixel 10 como la primera línea de teléfonos con Content Credentials en cada foto. La publicación está fechada el 10 de septiembre de 2025 y firmada por Eric Lynch y Sherif Hanna. Según el texto, Pixel Camera alcanzó «Assurance Level 2, la calificación de seguridad más alta definida actualmente por el C2PA Conformance Program».
La publicación de Google describe una cadena de comprobaciones de hardware detrás de esa calificación. Android Key Attestation prueba que una clave de firma se creó dentro de un chip protegido. El chip de seguridad Titan M2 almacena la clave de modo que el software no pueda leerla. Remote Key Provisioning entrega certificados solo a lo que Google llama una «Play Protect Certified version of Android». Un reloj dentro del chip Tensor G5 pone marca de tiempo a las fotos incluso sin red. Google también usa una estrategia que llama «One-and-Done». Cada clave firma exactamente una imagen, así que dos fotos no pueden vincularse al mismo teléfono.
Dónde se rompió la cadena
Buchanan apuntó al paso de atestación, no al almacenamiento de claves. Su informe dice que Android Key Attestation y Google Play Integrity pueden sortearse ambos. Por tanto, un teléfono comprometido todavía puede convencer a los servidores de Google de que es de fiar y obtener un certificado de firma válido. Lo lograron dos ataques distintos.
El primero es de software. Buchanan informa que un exploit de root en un clic, registrado como CVE-2026-43499, desactiva la comprobación de atestación. El teléfono está completamente comprometido y aun así pasa por fiable. El segundo ataque es inyección de fallos por hardware: un glitch electromagnético dirigido a la memoria DRAM del teléfono, para que el chip funcione mal en un momento elegido. Buchanan informa que así sorteó el módulo de seguridad por hardware StrongBox.
| Dispositivo probado | Método informado |
|---|---|
| Pixel 8a | exploit de root por software |
| Pixel 9a | Root-My-Pixel, root en un clic |
| Samsung A07 | evasión de la atestación |
| Amazon Fire TV Stick | evasión de la atestación |
| Meta Quest 3S | evasión de la atestación |
El agujero de software se puede parchear. El de hardware es la razón por la que Buchanan considera el problema permanente. Hacer glitching a un chip de memoria es un ataque físico sobre silicio que ya está en manos de la gente. Ninguna actualización de software cambia ese silicio. Ahí está la brecha detrás del veredicto «infeasible» de Google.
Conviene ver dónde está el fallo. Ambos ataques apuntan a las comprobaciones que deciden si un teléfono merece un certificado. Un teléfono que no debería calificar puede recibir una clave legítima. Después puede firmar lo que quiera.
Qué significa esto para los desarrolladores
Trate un Content Credential válido como indicio sobre el software, no como prueba sobre la realidad. Le dice que una firma se verificó contra una cadena de certificados. No le dice que una cámara apuntara a una escena real. Si está construyendo una tubería de verificación, una herramienta de redacción o un mercado que revisa subidas, no escriba rutas de código que aprueben una imagen en automático porque la credencial pasó. Conserve el paso de revisión manual que pensaba eliminar.
Compruebe qué devuelve realmente su biblioteca de verificación. Assurance Level 2 es una afirmación sobre la conformidad de la aplicación de captura, no sobre la escena. Muestre el nivel y el certificado emisor en sus propios registros y en su interfaz, en lugar de reducir todo a un booleano. Un revisor que puede ver «Pixel Camera, Assurance Level 2» puede ponderarlo. Un revisor que solo ve una marca verde no puede.
Vale la pena planificar en torno a esta asimetría. En sentido negativo, C2PA sigue siendo útil: una credencial ausente o inválida es una señal real de que algo se quitó, se editó o se generó. Una credencial presente y válida tiene ahora un techo conocido en lo que prueba. Ordene sus señales de confianza en consecuencia. Conserve al menos una que no dependa de la honestidad del dispositivo, por ejemplo una procedencia que usted mismo registre al subir el archivo.
Por último, observe el desenlace de la divulgación tanto como el exploit. Google pagó la recompensa y rechazó la corrección. Es una respuesta honesta y no un desmentido. Le dice que el modelo de amenaza del estándar suponía un hardware que aguanta. Si su hoja de ruta de producto tiene escrito «verificar con Content Credentials» como hito de confianza, esa línea necesita reescribirse antes de lanzarse.