Pesquisador quebra as credenciais de foto C2PA no Android e Google não vai corrigir

O pesquisador de segurança David Buchanan publicou um relatório em 25 de agosto de 2026. Nele afirma que telefones Android podem ser levados a assinar fotos falsas como se uma câmera real as tivesse tirado. Isso rompe a única promessa que justifica a existência dessa tecnologia. O Google revisou suas conclusões, pagou uma recompensa de 7.500 dólares e encerrou o relatório com a marcação «Won't fix (infeasible)», ou seja, inviável de corrigir.

A tecnologia se chama C2PA, sigla de Coalition for Content Provenance and Authenticity. Ela anexa a uma foto um registro assinado, chamado Content Credential. Esse registro informa qual dispositivo ou aplicativo produziu a imagem. O objetivo é distinguir uma foto real de câmera de uma imagem inventada por um modelo de IA generativa. A conclusão de Buchanan é direta: «C2PA na plataforma Android está quebrado, de um jeito que não é realista corrigir com patch».

O que o Google garantia na sua implementação no Pixel

O Google apresentou o Pixel 10 como a primeira linha de telefones com Content Credentials em cada foto. A publicação é datada de 10 de setembro de 2025 e assinada por Eric Lynch e Sherif Hanna. Segundo o texto, o Pixel Camera atingiu «Assurance Level 2, a maior classificação de segurança atualmente definida pelo C2PA Conformance Program».

A publicação do Google descreve uma cadeia de verificações de hardware por trás dessa classificação. O Android Key Attestation prova que uma chave de assinatura foi criada dentro de um chip protegido. O chip de segurança Titan M2 guarda a chave de modo que o software não consiga lê-la. O Remote Key Provisioning entrega certificados apenas ao que o Google chama de «Play Protect Certified version of Android». Um relógio dentro do chip Tensor G5 coloca marca de tempo nas fotos mesmo sem rede. O Google usa ainda uma estratégia que chama de «One-and-Done». Cada chave assina exatamente uma imagem, então duas fotos não podem ser ligadas ao mesmo telefone.

Onde a cadeia se rompeu

Buchanan mirou a etapa de atestação, não o armazenamento das chaves. O relatório dele diz que o Android Key Attestation e o Google Play Integrity podem ser contornados, os dois. Portanto, um telefone comprometido ainda consegue convencer os servidores do Google de que é confiável e obter um certificado de assinatura válido. Dois ataques distintos conseguiram isso.

O primeiro é de software. Buchanan relata que um exploit de root em um clique, registrado como CVE-2026-43499, desativa a verificação de atestação. O telefone está totalmente comprometido e mesmo assim passa como confiável. O segundo ataque é injeção de falhas por hardware: um glitch eletromagnético dirigido à memória DRAM do telefone, para fazer o chip errar num momento escolhido. Buchanan relata ter contornado assim o módulo de segurança por hardware StrongBox.

Dispositivo testado	Método relatado
Pixel 8a	exploit de root por software
Pixel 9a	Root-My-Pixel, root em um clique
Samsung A07	contorno da atestação
Amazon Fire TV Stick	contorno da atestação
Meta Quest 3S	contorno da atestação

O furo de software pode ser corrigido. O de hardware é a razão pela qual Buchanan considera o problema permanente. Fazer glitching num chip de memória é um ataque físico sobre silício que já está nas mãos das pessoas. Nenhuma atualização de software muda esse silício. Essa é a lacuna por trás do veredicto «infeasible» do Google.

Vale notar onde está a falha. Os dois ataques miram as verificações que decidem se um telefone merece um certificado. Um telefone que não deveria se qualificar pode receber uma chave legítima. Depois disso, pode assinar o que quiser.

O que isso significa para desenvolvedores

Trate um Content Credential válido como indício sobre software, não como prova sobre a realidade. Ele diz que uma assinatura foi verificada contra uma cadeia de certificados. Ele não diz que uma câmera estava apontada para uma cena real. Se você está construindo uma esteira de verificação, uma ferramenta de redação ou um marketplace que confere envios, não escreva caminhos de código que aprovem uma imagem automaticamente porque a credencial passou. Mantenha a etapa de revisão manual que você pretendia remover.

Verifique o que sua biblioteca de verificação realmente devolve. Assurance Level 2 é uma afirmação sobre a conformidade do aplicativo de captura, não sobre a cena. Exiba o nível e o certificado emissor nos seus próprios registros e na sua interface, em vez de reduzir tudo a um booleano. Um revisor que consegue ver «Pixel Camera, Assurance Level 2» pode ponderar. Um revisor que só vê um sinal verde não pode.

Essa assimetria merece ser planejada. No sentido negativo, o C2PA continua útil: uma credencial ausente ou inválida é um sinal real de que algo foi removido, editado ou gerado. Uma credencial presente e válida agora tem um teto conhecido no que prova. Ordene seus sinais de confiança de acordo. E mantenha pelo menos um que não dependa da honestidade do aparelho, como uma procedência que você mesmo registra no momento do envio.

Por fim, observe o desfecho da divulgação tanto quanto o exploit. O Google pagou a recompensa e recusou a correção. É uma resposta honesta, não um desmentido. E indica que o modelo de ameaça do padrão pressupunha um hardware que resiste. Se o seu roteiro de produto tem «verificar com Content Credentials» escrito como marco de confiança, essa linha precisa ser reescrita antes de ir ao ar.