União Europeia exige hardware para verificação de idade e gera crise no open source

O projeto open-source de verificação de idade financiado pela União Europeia tornou-se o centro de um acalorado debate tecnológico após um mantenedor confirmar que a atestação vinculada a hardware (hardware-bound attestation) é um requisito arquitetural obrigatório do sistema. A revelação foi feita no repositório oficial do aplicativo para Android hospedado no GitHub, despertando apreensão imediata entre desenvolvedores sobre a incompatibilidade da solução com ecossistemas abertos, como distribuições Linux, ROMs customizadas do sistema operacional da Google e compilações independentes do código-fonte público.

Decisão gera impasse técnico

A solução foi projetada sob o financiamento da União Europeia para resolver um problema crítico de privacidade no ambiente digital: permitir que qualquer cidadão comprove ter atingido uma idade mínima necessária sem que precise expor seu nome completo, data exata de nascimento ou o número do documento oficial de identidade. Para impedir que as credenciais emitidas sejam clonadas, copiadas ou reutilizadas por clientes de software modificados, o projeto exige que as chaves criptográficas do usuário fiquem armazenadas diretamente dentro de hardware protegido, como o Android TEE (Trusted Execution Environment), o chip StrongBox ou o ecossistema Secure Enclave da Apple.

No entanto, a escolha de vincular o funcionamento da solução ao hardware físico gerou críticas contundentes por parte da comunidade de desenvolvedores no GitHub. Os opositores argumentam que essa abordagem coloca em risco a soberania e a abertura do projeto, ao torná-lo dependente de um grupo restrito de fabricantes de dispositivos, sistemas operacionais comerciais e provedores de atestação homologados. Essa decisão, segundo analistas do setor, impõe barreiras técnicas quase intransponíveis para a execução do software em plataformas livres.

A resposta no GitHub

A polêmica ganhou força quando um usuário questionou formalmente a arquitetura no repositório do GitHub, sustentando que atrelar credenciais digitais a ambientes de hardware específicos prejudica de forma irreversível o suporte a sistemas computacionais abertos. A resposta de um dos mantenedores do projeto foi taxativa quanto às diretrizes estabelecidas pela equipe:

blockquote>"Hardware-bound attestation is a requirement of this project, not an implementation detail we can simply drop."

Apesar da posição irredutível sobre a obrigatoriedade da ancoragem em hardware, os mantenedores do projeto no GitHub convidaram a comunidade a enviar propostas arquiteturais alternativas que atendam aos mesmos critérios de segurança. Além disso, a equipe informou que publicará em breve uma análise de segurança dedicada (security review) acompanhada do modelo de ameaças (threat model) oficial do projeto. O documento deverá esclarecer as razões técnicas que motivaram a escolha do hardware-bound attestation e determinar se outras raízes de confiança (roots of trust) menos restritivas poderão ser aceitas em implementações futuras.

Mecanismos de segurança e hardware

Na prática, o mecanismo de hardware-bound attestation opera estabelecendo um canal direto de confiança entre o coprocessador criptográfico do dispositivo e os servidores de validação. No ecossistema Android, ao utilizar o Android TEE ou o circuito StrongBox, o aplicativo solicita a geração de um par de chaves assimétricas que é gravado em uma zona fisicamente isolada do processador principal. No iOS, o ecossistema Secure Enclave desempenha o mesmo papel de isolamento. O servidor remoto da verificação de idade recebe uma prova criptográfica assinada pela própria fabricante do hardware, atestando que a chave privada nunca foi exposta à memória RAM principal e não pode ser exportada por nenhum processo do sistema operacional.

Essa blindagem criptográfica previne ataques de replicação e clonagem do Proof of Age (prova de idade), impedindo que um usuário extraia a chave privada de seu celular e a instale em outro dispositivo ou em um emulador. No entanto, o custo técnico dessa proteção é a exclusão sistemática de qualquer plataforma computacional que não possua um ecossistema de atestação suportado ou que utilize um sistema operacional onde o acesso às chaves do enclave seja bloqueado por políticas de segurança do fabricante.

O risco para distribuições abertas

A maior preocupação manifestada pelos desenvolvedores de software livre diz respeito ao impacto da medida em ROMs customizadas do Android, como o LineageOS, o GrapheneOS e o CalyxOS, bem como em distribuições comunitárias. Embora o código-fonte do aplicativo de verificação de idade da União Europeia seja público, a exigência de atestação em hardware cria uma contradição prática: a aplicação pode ser totalmente auditada e modificada, mas a versão compilada pelo próprio usuário não conseguirá obter o selo de confiança exigido pelo servidor para validar a identidade do cidadão.

Para que o Android TEE forneça um certificado de atestação aceito pelos servidores centrais, o dispositivo geralmente precisa passar por verificações de integridade da cadeia de inicialização (secure boot). Quando um usuário instala uma ROM alternativa e desbloqueia o bootloader do aparelho, as chaves de fábrica emitidas por empresas como Google, Samsung ou Qualcomm são revogadas para fins de atestação de alta segurança. Como resultado, o sistema interpreta o dispositivo como potencialmente comprometido e recusa o fornecimento da prova criptográfica do Proof of Age.

Integridade e verificações avançadas

A especificação técnica oficial do projeto europeu determina que os aplicativos de verificação de idade façam uso obrigatório do hardware criptográfico nativo sempre que este estiver fisicamente presente no aparelho. Todavia, a especificação de referência introduz uma nuance importante ao separar o armazenamento de chaves respaldado por hardware das verificações de integridade mais agressivas. Recursos como detecção de acesso superusuário (root), a API Google Play Integrity no Android e o Apple App Attest no iOS não são exigidos universalmente pelo código de referência, ficando a cargo de cada entidade implantadora (deployer) a decisão de ativá-los ou não em cada país da Europa.

Essa separação conceitual é fundamental porque o simples uso do StrongBox ou do Secure Enclave para armazenar chaves criptográficas não exige obrigatoriamente que um servidor remoto aprove a compilação exata do sistema operacional ou o binário específico do aplicativo. Contudo, a ambiguidade na fala dos mantenedores deixa em aberto quão rígidas serão as implantações finais de produção nos estados-membros da União Europeia, mantendo os desenvolvedores apreensivos sobre o risco de bloqueio total de sistemas operacionais modificados.

Governança da Comissão Europeia

Além dos desafios da camada de hardware, o projeto enfrenta uma severa limitação no âmbito da governança institucional. De acordo com as diretrizes da arquitetura, os provedores do serviço Proof of Age só emitirão credenciais válidas para aplicativos que constem expressamente em uma lista oficial de conformidade mantida e gerida pela Comissão Europeia. Essa regra altera profundamente a dinâmica de distribuição de softwares livres no continente.

Sob esse modelo de governança, o ato de publicar o código-fonte em um repositório como o GitHub deixa de ser suficiente para garantir a liberdade de uso do software. Mesmo que um desenvolvedor independente audite e compile exatamente o mesmo código fornecido pela União Europeia, o aplicativo gerado não constará na lista de permissões da Comissão Europeia. Consequentemente, os servidores de emissão de credenciais recusarão o atendimento a essa versão comunitária, restringindo o uso prático apenas às compilações distribuídas pelas lojas oficiais de aplicativos.

A experiência no ecossistema Linux

No que diz respeito aos usuários de sistemas de mesa rodando Linux, a arquitetura do projeto não estabelece um banimento direto ou uma proibição explícita. A especificação prevê que uma pessoa utilizando uma distribuição Linux em seu computador desktop possa navegar até um site de serviços que exija verificação de idade e concluir o procedimento escaneando um QR code projetado no monitor. Para isso, contudo, o usuário obrigatoriamente precisará utilizar uma carteira digital instalada em um dispositivo móvel compatível com os requisitos de hardware.

A grande limitação reside no fato de que o projeto da União Europeia não contempla o desenvolvimento de uma carteira digital nativa para a plataforma Linux. Além disso, sistemas operacionais móveis alternativos orientados à privacidade — a exemplo do postmarketOS, Ubuntu Touch, Sailfish OS e PureOS — dificilmente conseguirão atender às condições estritas de confiança exigidas pelo Android TEE ou pelo Secure Enclave. Isso cria um cenário de dependência inescapável em relação aos ecossistemas móveis dominados pelo Google e pela Apple.

Comparativo com o cenário brasileiro

A controvérsia em torno do projeto europeu ressoa diretamente nas discussões técnicas sobre identidade digital no mercado brasileiro. No Brasil, ecossistemas como a plataforma gov.br e a implantação da Carteira de Identidade Nacional (CIN) enfrentam desafios semelhantes de arquitetura. O Governo Federal brasileiro também busca implementar validações criptográficas e autenticações rigorosas em dispositivos móveis para evitar fraudes em benefícios sociais, emissão de documentos e serviços de saúde pública.

A decisão da União Europeia em priorizar o hardware-bound attestation expõe um dilema global que atinge diretamente os desenvolvedores e gestores de tecnologia no Brasil. Ao condicionar a validação da identidade a enclaves seguros como o StrongBox da Google e o Secure Enclave da Apple, governos em todo o mundo acabam transferindo o poder de decisão sobre a integridade dos sistemas públicos para duas corporações multinacionais. No contexto da América Latina, essa dependência tecnológica reacende debates cruciais sobre a inclusão digital e a soberania do software público.

O dilema ético e arquitetural

O desfecho dessa controvérsia arquitetural na Europa dependerá da publicação do relatório de segurança (security review) e do modelo de ameaças (threat model) prometidos pela equipe do projeto no GitHub. A comunidade tecnológica aguarda a divulgação desses documentos para compreender se a União Europeia apresentará justificativas matemáticas e de segurança irrefutáveis para a obrigatoriedade da vinculação ao hardware, ou se considerará a inclusão de raízes de confiança alternativas (alternative roots of trust) que permitam a conformidade de sistemas de código aberto.

Até a publicação dessas análises oficiais, a pergunta central formulada pela comunidade de software livre permanece sem resposta definitiva: é possível que um sistema de identidade digital financiado com recursos públicos e classificado como open-source permaneça verdadeiramente aberto quando o acesso real do cidadão depende não apenas do código-fonte disponível, mas também de hardware homologado, aplicativos pré-aprovados pela Comissão Europeia e ecossistemas operacionais sob o controle de Big Techs?