Prova de hardware como facilitador exclusivo
(grapheneos.social)- Apple e Google estão ampliando o uso de comprovação baseada em hardware, incentivando a adoção por mais serviços e, no longo prazo, reforçando uma estrutura que exclui hardware e sistemas operacionais concorrentes não aprovados
- A Play Integrity API do Google e a App Attest API da Apple funcionam de forma semelhante; no Play Integrity,
strong integrityexige comprovação por hardware, e a direção é passar a exigir isso gradualmente também emdevice integrity - O Privacy Pass da Apple, o cancelado Web Environment Integrity do Google e o
reCAPTCHA Mobile Verificationlevam a exigência de comprovação para a web, podendo bloquear o acesso a serviços web caso a pessoa não tenha um dispositivo iOS ou Android certificado - A Play Integrity API bloqueia o GrapheneOS mesmo sendo mais seguro do que os alvos permitidos, e permite dispositivos sem patches de segurança há 10 anos, o que faz o objetivo de licenciamento do Google Mobile Services e exclusão da concorrência se destacar mais do que a justificativa de segurança
- À medida que serviços governamentais e bancários passam a exigir cada vez mais App Attest e Play Integrity, na prática isso impõe dispositivos Apple ou Android certificados pelo Google e pode afetar também o acesso web em ambientes como Windows, Linux desktop e FreeBSD
Exigências de comprovação se expandindo para a web
- O Privacy Pass da Apple leva a comprovação por hardware para a web para ajudar na aprovação de CAPTCHAs em hardware da própria empresa
- Na época, muita gente considerou isso inofensivo por acreditar que não haveria muitos sites bloqueando usuários sem hardware Apple
- Tanto Apple quanto Google têm grande probabilidade de levar comprovação por hardware mais ampla para a web
- Bancos e serviços governamentais exigem cada vez mais o uso de aplicativos móveis e podem usar comprovação dentro dos apps para impor dispositivos e sistemas operacionais aprovados pela Apple ou Google
- O Privacy Pass da Apple, o cancelado Web Environment Integrity do Google e o reCAPTCHA Mobile Verification estão levando esse movimento para a web
- A cobertura atual sobre o reCAPTCHA Mobile Verification não trata adequadamente de seu impacto e significado
- Essa abordagem, em certas situações, exige escanear um QR com um smartphone certificado para passar no reCAPTCHA, levando a exigência de comprovação por hardware também para Windows, Linux desktop, OpenBSD e outros
- Por controlar o reCAPTCHA, o Google está em posição de fazer com que seja necessário ter um dispositivo iOS ou Android certificado para usar uma enorme parte da web
- O Google define os requisitos de certificação do Android, incluindo a imposição de empacotar o Google Chrome
- O reCAPTCHA Mobile Verification atualmente funciona com o Google Play em sandbox do GrapheneOS, mas existe como meio para começar a usar isso também em sistemas sem comprovação por hardware
- Se essa exigência for aplicada, pessoas sem dispositivos iOS ou Android poderão ser bloqueadas mesmo sem outras condições
Play Integrity e a exclusão do GrapheneOS
- A Play Integrity API do Google proíbe o uso do GrapheneOS mesmo que ele seja muito mais seguro do que qualquer alvo permitido
- A Play Integrity API também bloqueia outras alternativas, e isso não é um problema restrito a sistemas operacionais baseados em AOSP
- Mesmo usando um sistema operacional móvel baseado em FreeBSD, não é possível evitar esse problema; apenas se é ainda mais excluído
- A Play Integrity API permite até dispositivos sem patches de segurança há 10 anos
- O nível
device integritypode ser contornado com spoofing, mas o Google consegue detectar e bloquear isso razoavelmente bem se começar a ser usado em larga escala - Para contornar o nível
strong integrity, são necessárias chaves vazadas de TEE ou SE - A Play Integrity API não é muito segura e, temporariamente, contorná-la não é algo especialmente difícil
- Existem frameworks para falsificar verificações de software, e também é possível comprar chaves vazadas para burlar a comprovação por hardware
- Ainda assim, os contornos estão ficando cada vez mais difíceis, e seu tempo de validade também está ficando mais curto
- O Play Integrity não oferece recursos de segurança úteis, mas funciona muito bem para excluir a concorrência
- Serviços que exigem Apple App Attest ou Google Play Integrity ajudam principalmente Apple e Google a manter um duopólio em dispositivos móveis
- O Play Integrity é mais importante porque o AOSP é open source
- O GrapheneOS pode ser verificado por comprovação por hardware, e o motivo de o Google bloqueá-lo no Play Integrity é que ele não licencia o Google Mobile Services nem segue regras anticompetitivas
- Essas regras já foram consideradas ilegais em lugares como a Coreia do Sul
- Serviços não deveriam proibir o uso de hardware e sistemas operacionais arbitrários
- Como o Google permite dispositivos sem patches há 10 anos, mas não permite um sistema operacional muito mais seguro, a justificativa de segurança é difícil de sustentar
- Isso serve para impor o monopólio por meio do licenciamento do GMS
Serviços governamentais, bancários e o papel da regulação
- Governos estão tornando cada vez mais obrigatório o uso de Apple App Attest e Google Play Integrity não só em seus próprios serviços, mas também em serviços comerciais
- A UE está liderando uma tendência de aplicar essas exigências a pagamentos digitais, verificação de identidade, verificação de idade e outros casos
- Muitos aplicativos governamentais da UE já contam com essas exigências
- Em vez de impedir as graves práticas anticompetitivas de Apple e Google, governos estão participando diretamente da exclusão da concorrência por meio de seus próprios serviços
- Exigir que as pessoas usem dispositivos Apple ou Android certificados pelo Google não é segurança, e sim restrição à concorrência
- O problema de passar a exigir um dispositivo iOS sem modificações ou Android com Google Mobile Services para acessar serviços bancários, governamentais ou passar em certos reCAPTCHAs não é um problema apenas do GrapheneOS
- O mesmo afeta Windows, Linux desktop, FreeBSD e outros
- Não é uma questão específica de Pixel, dispositivos Android ou sistemas operacionais baseados em AOSP, e pode afetar também o acesso web em desktop
APIs de comprovação no Android e Unified Attestation
- O Android fornece um sistema padrão de comprovação por hardware que dá suporte a sistemas operacionais alternativos ao permitir impressões digitais de chaves de boot verificadas
- A comprovação por hardware do Android usa principalmente a raiz de confiança do Google e o serviço de provisionamento remoto de chaves, mas a própria API dá suporte a raízes de confiança alternativas
- A comprovação por hardware do Android não deveria ser usada para excluir usuários que não utilizam um hardware ou sistema operacional específico
- Ainda assim, o fato de poder permitir raízes de confiança e sistemas operacionais arbitrários dá margem para que serviços aceitem mais alvos
- Se o objetivo do Google fosse segurança, ele poderia usar o mesmo sistema para permitir o GrapheneOS no Play Integrity
- O Unified Attestation é outro sistema anticompetitivo promovido por várias empresas europeias, que também acaba excluindo de forma semelhante usuários de hardware e software arbitrários
- O Unified Attestation não é uma solução e é muito pior do que a API de comprovação por hardware muito mais aberta do Android
- O Unified Attestation da Volla é inteiramente construído sobre a API de comprovação por hardware do Android
- O Unified Attestation da Volla existe para fazer com que uma autoridade central e os serviços controlem o que é permitido
2 comentários
Gosto tanto do Google que queria que existissem uns cinco🥰
Comentários do Hacker News
A EU Digital Identity Wallet (EUDI) exige atestação de hardware do Google ou da Apple, o que na prática prende toda a identidade digital da UE ao duopólio americano
É como falar de soberania digital enquanto se toma esse tipo de decisão, e passa a impressão de que proteger as crianças vem antes da soberania
https://gitlab.opencode.de/bmi/eudi-wallet/wallet-developmen...
Desde o início não entendo por que tomaram essa decisão
Parecia claramente uma resposta voltada a usuários comuns sem conhecimento técnico
Muita gente fala da importância da soberania e de se livrar da dependência dos EUA, então não entendo por que não há mais oposição; fico pensando se é simplesmente ignorância
Isso é ainda mais verdade em identificadores com foco em privacidade, e por isso a atestação do dispositivo se torna importante
Se não for possível verificar se o hardware impede a extração das chaves do usuário, não dá para garantir que a chave de identidade esteja realmente presa ao dispositivo
A pior parte é que criminosos motivados acabarão encontrando um jeito de extrair essas chaves e usá-las em fraudes, e o resultado será a destruição do open source e da computação aberta
Quem deve ser obrigado a apresentar identidade é uma questão à parte, e na maioria dos contextos exclusivamente online eu diria que a resposta é “não”, mas a solução em que o setor financeiro confia há décadas já existe
Exigir silício e software aprovados nem é o maior problema aqui
Eles não usam provas de conhecimento zero nem assinaturas cegas
Então, toda vez que você prova algo com o dispositivo, deixa um pacote de prova que pode ser usado para vincular aquela ação ao aparelho
Colocam uma estrutura intermediária para buscar IDs descartáveis a partir de um ID estático do dispositivo em um servidor intermediário, fingindo se importar com privacidade, mas como não sabemos o que esses servidores fazem, o mais seguro é assumir que registram tudo
Só o caminho de atestação remota já é assim; o caminho do DRM ID é pior. Não há uma alternativa minimamente significativa, então todos os servidores de licença podem acessar a identidade estática gravada no silício. E nem vale a pena falar do caminho via conta Google
Houve, sim, propostas para usar assinaturas cegas em atestação remota, mas isso não está sendo usado em nenhum lugar visível no momento: <https://en.wikipedia.org/wiki/Direct_Anonymous_Attestation>
Há algumas razões possíveis. A mais óbvia é que eles querem poder violar a privacidade quando quiserem, ou foram obrigados a ter essa capacidade
Outra razão é que, se não for possível vincular uma prova a um dispositivo específico, a mitigação de abuso se reduz praticamente a limitação de taxa, e isso pode não ser suficiente para eles. Um atacante pode montar uma fazenda de dispositivos e fazer com que cada aparelho forneça atestação remota a agentes maliciosos em troca de dinheiro por hora
Não vejo como um serviço pode manter o anonimato e ainda assim aplicar limitação de taxa
Se um serviço consegue contar que dois pedidos vieram da mesma entidade, então dois serviços também podem fingir ser o mesmo serviço, descobrir que os dois pedidos vieram da mesma entidade e correlacioná-los
Dizer coisas como “o problema não é a atestação de hardware, e sim não usar provas de conhecimento zero” é normalizar um novo comportamento
Não deveríamos fazer isso. Tanto faz se usam provas de conhecimento zero ou atestação de hardware com a tecnologia de segurança mais avançada: o problema é a própria atestação de hardware
O mesmo vale para verificação de idade. O problema não é que a verificação de idade é vulnerável a vazamentos de dados; o problema em si é a verificação de idade
Desde o anúncio do app eu já tinha quase certeza de que a estrutura seria algo assim
Também lembro de ter visto no fórum do Graphene uma discussão de que o DRM ID não só é preservado como permanece o mesmo entre perfis
Se for, o que serviria de incentivo ou pressão para levar à adoção
Este é um ótimo fio para mostrar por que essa tecnologia está se tornando um problema para qualquer coisa “aberta”
A ideia de “é só criarmos nossa própria web paralela” só funciona até que todos os serviços passem a ficar atrás de uma web em que é obrigatório ter um dispositivo móvel aprovado pelo Google ou pela Apple
O Google já me bloqueia completamente nisso
Quando clico nos quadrados para escolher os itens pedidos, ele entra em loop infinito; se tento usar a versão em áudio, bloqueia tudo dizendo que houve atividade suspeita
Então hoje em dia pedalo sozinho e nem renovei minha associação este ano
A última vez que tive uma experiência parecida foi quando o Facebook começou a virar o único caminho para participar de certos eventos. Na época também simplesmente aceitei a exclusão e gastei meu tempo e dinheiro em outra coisa
Já havia muitos negócios ou grupos sociais acessíveis apenas por trás de coisas como Facebook e WhatsApp
Isso parece muito uma distopia cyberpunk estranha. É como só poder enviar cartas e encomendas para pessoas inscritas no mesmo serviço de correio privado, ou só poder dirigir em estradas que tenham licenciamento cruzado com a marca do meu carro
Mesmo que fornecesse recursos de segurança, o dano colateral de transformar sistemas operacionais que não sejam do Google ou da Apple em cidadãos de segunda classe continuaria, e esse é o problema central
Para bancos ou interações com o governo talvez não seja realista, mas para muitos outros serviços talvez seja possível
Ainda assim, continua sendo necessário construir alguma coisa, e o custo se espalha por um número menor de pessoas; a vantagem de ter menos complexidade por não precisar criar tecnologia de anúncios talvez não compense
Mesmo assim, pode ser um problema do tipo bons ingredientes. Em hardware seria mais difícil
Parece uma pergunta idiota, mas estou falando sério
Em 1999, quando a Intel decidiu colocar um número de série legível por software na CPU, houve uma reação enorme, e no fim a decisão foi revertida
Depois disso, autoritários que insistiam em “segurança” e computação confiável continuaram empurrando TPM e tecnologias relacionadas, e também contribuíram para a ascensão dos ecossistemas murados móveis
A exigência de TPM no Windows 11 foi outro passo nessa direção. Foi chocante ver quanta propaganda houve aqui e em outros lugares dizendo que isso era uma coisa boa
Quando “segurança” é apresentada como justificativa, fica claro que muita gente aceita facilmente qualquer imposição. Espero que esse número esteja diminuindo
A guerra contra a computação de uso geral continua, e precisamos continuar lutando
Stallman, como sempre, estava certo. É hora de reler seu “Right to Read”. Se ainda não existe, um curta feito por IA também pode ser uma boa ideia
“Quem abre mão da liberdade em troca de segurança não merece nenhuma das duas”
IA é uma ferramenta totalmente centralizada e monopolista
Como dá para ver neste fio, em vez de impulso, indignação e reação auto-organizada contra esse tipo de problema, só há desespero do tipo “ninguém liga”, “não há nada que possamos fazer”
Desistir é a forma mais certa de perder
Os comentários aqui parecem ler o argumento como se a própria atestação fosse ruim, mas a tese real parece estar mais perto de dizer que deveria haver um caminho que incluísse explicitamente fornecedores que não fossem Apple e Google
O título passa a ideia de que Apple e Google são más e fazem isso para consolidar monopólios, enquanto a concorrente GrapheneOS está resistindo em favor das pessoas
Mas a última objeção parece ser que eles próprios também deveriam ter sido incluídos, e como dizem que foram rejeitados pela Play Integrity API do Google por motivos pouco claros e alegam que isso foi malicioso, também parecem reconhecer valor de segurança nisso
Para dados de identidade importantes, realmente é preciso prova de toda a cadeia de assinatura. É a única forma de evitar uma situação em que IA torna trivial criar identidades falsas para fraude
Patentes e direitos autorais foram a forma original de monopólio
A menos que um software seja open source, ele é monopolista por definição
É surpreendente que não haja mais ricos do HN patrocinando o GrapheneOS
O diagrama de Venn entre pessoas ricas e técnicas que se importam com isso parece ter uma sobreposição considerável, e o Graphene, apesar de todos os defeitos, está fazendo muito trabalho de base nessa área
Nossa civilização precisa desesperadamente de um jeito de modificar a microeletrônica moderna depois da fabricação, e isso deveria ser possível pelo menos em oficinas de reparo bem equipadas
Isso já era necessário desde ontem
Como alternativa, deveria ser ilegal vender dispositivos de computação de uso geral com qualquer tipo de bootloader inicial gravado na mask ROM da CPU ou do SoC
Ou seja, a primeira instrução executada pela CPU após o reset deveria vir de um meio de armazenamento fisicamente localizado fora do encapsulamento da CPU
Veja: https://pluralistic.net/2026/01/01/39c3/
Mesmo SoCs relativamente simples fazem muita coisa em uma boot ROM não documentada para ajudar no processo de reset antes de chegar ao vetor de reset da arquitetura
Também há muito valor em colocar rotinas de baixo nível de DFU em uma boot ROM que não possa ser apagada por engano
O silício do SoC poderia ser revisado para registrar cada instrução executada desde o acionamento até a instrução de transferência para o secure boot
Se ainda houver comandos auxiliares para consultar estado, verificar overflow e gerar assinaturas, o sistema operacional poderia montar sua própria atestação enquanto reporta implicitamente qualquer adulteração anterior ao boot
Basta tornar ilegal colocar material de chave codificado no bootloader e verificar com essa chave o código que ele carrega
É espantoso deixarmos o duopólio Google-Apple decidir quem pode ou não acessar serviços totalmente sem relação com eles
Imagine ser bloqueado dos serviços do Google por posições anti-Google e, por causa disso, não conseguir nem entrar na sua conta bancária
Realmente é preciso desmembrar a Alphabet
Para um tema tão sério, teria sido muito melhor um texto real, lógico e de uma página, em vez de um fio difícil de ler