Carteira de identidade eletrônica eIDAS da Alemanha adota verificação de segurança do dispositivo baseada em contas Apple e Google

 (bmi.usercontent.opencode.de)
1 pontos por GN⁺ 24 일 전 | 1 comentários | Compartilhar no WhatsApp
  • A National EUDI Wallet da Alemanha mantém a integridade da autenticação de identidade eletrônica por meio de um sistema de gerenciamento de vulnerabilidades de dispositivos móveis (MDVM)
  • O MDVM detecta vulnerabilidades no sistema operacional e no armazenamento de chaves em hardware (HKS) e, quando o risco é alto, bloqueia o uso de chaves de autenticação
  • No Android, a integridade do dispositivo é verificada com Google Play Integrity API e KeyAttestation; no iOS, com Apple DeviceCheck·AppAttest
  • Devido a essa estrutura, ao usar funções de identidade eletrônica, procedimentos de verificação baseados em contas Apple ou Google passam a operar de forma obrigatória
  • Todo o sistema foi projetado com o objetivo de evitar clonagem e uso indevido de chaves por atacantes e manter a autenticação eID em alto nível de garantia

Conceito de gerenciamento de vulnerabilidades de dispositivos móveis (Mobile Device Vulnerability Management, MDVM)

  • O MDVM é um sistema da arquitetura da National EUDI Wallet da Alemanha que monitora continuamente vulnerabilidades de segurança no dispositivo do usuário e mantém a integridade dos meios de autenticação
  • Detecta vulnerabilidades conhecidas no HKS (armazenamento de chaves em hardware) e no sistema operacional (OS) e, quando o risco de ataque é elevado, bloqueia o uso de chaves RWSCA/RWSCD
  • Com isso, mantém um alto nível de garantia no processo de verificação de identidade eletrônica (eID) e evita clonagem e uso indevido de chaves por atacantes
  • O MDVM é composto por quatro funções: verificação do estado de segurança do dispositivo e do app, identificação da classe do dispositivo, verificação de vulnerabilidades e decisão de uso

Motivação

  • A Wallet Unit fornece meios de autenticação vinculados a vários meios de identidade (como PID) por meio de um par de chaves pública/privada
  • Ao emitir um PID, o WB (Wallet Backend) confirma junto à PP (Provider Party), via OpenID4VCI Key Attestation, que a chave é controlada por um meio de autenticação com um certo nível de resistência a ataques
  • De acordo com a ISO/IEC 18045 e o Regulamento da UE 2015/1502, a verificação de identidade eletrônica com alto nível de garantia exige meios de autenticação robustos
  • Os meios de autenticação fornecem duas garantias
    1. Proteção contra clonagem e adulteração do armazenamento de chaves
    2. Proteção contra ataques ao mecanismo de autenticação do usuário
  • A primeira garantia pode ser implementada com RWSCD baseado em HSM, sendo alcançada independentemente do dispositivo do usuário
  • A segunda garantia depende da segurança do dispositivo do usuário e é composta por um fator de posse (baseado em HKS) e um fator de conhecimento (como senha)
  • Em dispositivos móveis, é inviável realizar previamente análise de vulnerabilidades e certificação do HKS ou do OS, e diversas vulnerabilidades já foram relatadas no passado
  • Por isso, o sistema de monitoramento de vulnerabilidades em operação (MDVM) reduz a possibilidade de ataque e bloqueia o uso de chaves RWSCA/RWSCD em dispositivos com segurança insuficiente

Principais funções do MDVM

Função Descrição
Verificação do estado de segurança do dispositivo/app Verifica a integridade e autenticidade do dispositivo e do app Wallet, usando recursos de segurança da plataforma e RASP (Runtime Application Self-Protection)
Identificação da classe do dispositivo Identifica de forma verificada o modelo do dispositivo, versão do OS, nível de patch e informações do HKS
Verificação de vulnerabilidades por classe de dispositivo Consulta as informações mais recentes de vulnerabilidades do OS e do HKS
Decisão de uso do dispositivo/app Com base no estado de segurança e nas informações de vulnerabilidades, bloqueia a confirmação de OpenID4VCI Key Attestation e o uso da chave RWSCD em dispositivos com segurança insuficiente

Sinais coletados

  • Os sinais coletados são usados para resposta a ameaças, identificação da classe do dispositivo e verificação de plausibilidade (plausibility check)

  • Principais fontes de sinal: KeyAttestation, PlayIntegrity, DeviceCheck, RASP, LPADB, DCVDB

  • Visão geral

    Fonte do sinal Ameaças tratadas Sinergia Observações
    KeyAttestation rooting, bootloader desbloqueado, ROM customizada, adulteração de app, clonagem, emulação, ataques de replay etc. LPADB, RASP Usado como entrada do DCVDB
    PlayIntegrity adulteração de app, replay, rooting, ROM customizada, decisão de MDVM baseada no backend do Google, ferramentas de roubo de credenciais, ataques de overlay etc. KeyAttestation, RASP É necessário verificar o estado do bootloader
    iOS DeviceCheck replay, adulteração de certificado, ataque por proxy, adulteração de app RASP Garantia insuficiente de integridade do dispositivo
    LPADB ocultação de rooting com uso de chaves públicas de KeyAttestation KeyAttestation -
    DCVDB detecção de dispositivos inseguros com base em vulnerabilidades conhecidas KeyAttestation, RASP A precisão da identificação da classe do dispositivo é importante
    RASP detecção de hooking de app, debugging, rooting e emulação - Monitoramento contínuo da integridade durante a execução

Sinais do Android KeyAttestation

  • Identifica modelo do dispositivo, versão do OS, nível de patch e estado do bootloader por meio de informações de verificação em hardware baseadas em HKS
  • Principais itens de sinal
    • SecurityLevel: identifica o tipo de HKS (TrustedEnvironment, StrongBox)
    • attestationIdModel/Product/Device: identificação do modelo do dispositivo
    • osVersion / osPatchLevel: versão do OS e nível de patch de segurança
    • RootOfTrust: estado do bootloader e do Verified Boot
    • AttestationApplicationId: nome do pacote do app, versão e hash do certificado de assinatura
  • A lista de revogação de certificados de Key-Attestation do Google é atualizada lentamente, de modo que chaves vazadas publicamente ainda podem ser usadas
  • Em alguns dispositivos, certos campos de identificação podem estar ausentes, por isso os três campos devem ser avaliados em conjunto

Sinais de verdict do Android PlayIntegrity

  • Verifica a integridade do app e do dispositivo por meio da Google Play Integrity API
  • Principais itens de sinal
    • appRecognitionVerdict: se o app é original
    • deviceRecognitionVerdict: nível de confiança do dispositivo (ex.: MEETS_STRONG_INTEGRITY)
    • appLicensingVerdict: se foi instalado pela PlayStore
    • playProtectVerdict: avaliação de risco do Play Protect
  • MEETS_STRONG_INTEGRITY exige aplicação de patch de segurança nos últimos 12 meses
  • Para garantir a confiabilidade do sinal, é necessário verificar a assinatura e descriptografar
  • O método interno de avaliação do backend do Google não é público

Android RASP

  • A solução específica ainda não foi definida; está na fase de definição de requisitos funcionais
  • Funções de detecção
    • App Hooking/Debugging: detecção de manipulação dinâmica (Frida, Xposed etc.)
    • App Repackaging/Tampering: detecção de adulteração e reassinatura do app
    • UD Rooting/Emulation: detecção de rooting, virtualização e ambientes automatizados
  • O RASP fornece monitoramento de integridade durante a execução e mantém uma blocklist separada da lista de revogação do Google para evitar ataques baseados em chaves vazadas

iOS DCDeviceCheck.AppAttest Attestation

  • Estrutura de autenticação de app por meio do Secure Enclave e de servidores da Apple
  • Principais sinais
    • attestationObject: comprova que a chave App Attest foi gerada no Secure Enclave
    • credentialId: identificador da chave App Attest
    • RP ID: prefixo do App ID do app + Bundle ID
  • O indicador de risco da Apple (receipt metric) pode ser usado para detectar ataques por proxy, mas não há critérios claros, além de existir risco de exposição de dados pessoais devido à comunicação com servidores da Apple
  • No iOS, não é possível fornecer informações em hardware sobre modelo do dispositivo, versão do OS ou nível de patch; isso só pode ser verificado por consulta ao OS

iOS DCDeviceCheck.AppAttest Assertions

  • Estrutura de verificação baseada em assinatura gerada pela chave App Attest
  • Principais sinais
    • assertionObject: inclui a assinatura do desafio
    • keyId: identificador da chave App Attest
    • counter: número de assinaturas, que deve aumentar monotonicamente
  • Um aumento abrupto do valor do contador pode indicar ataque por proxy, enquanto uma redução pode indicar ataque de replay

iOS RASP

  • Exige funções de detecção semelhantes às do Android
    • App Hooking/Debugging, App Repackaging, App Tampering, UD Rooting, UD Emulation
  • O App Sandbox, Code Signing e a System Integrity Protection da Apple oferecem apenas proteção no momento da instalação e não têm funções para detectar rooting, hooking ou manipulação em tempo de execução
  • O RASP complementa isso com monitoramento de integridade durante a execução
  • Segundo a documentação da Apple, o App Attest afirma que “um app adulterado executado em um dispositivo legítimo não pode gerar uma assertion válida”

Conclusão

  • O MDVM avalia em tempo real o estado de segurança do dispositivo e bloqueia o uso de chaves de autenticação em ambientes com alta possibilidade de ataque, mantendo assim a confiabilidade do sistema de autenticação de identidade eletrônica
  • Tanto Android quanto iOS combinam recursos de segurança da plataforma com proteção dinâmica baseada em RASP para compor um sistema de verificação da integridade do dispositivo
  • Há dependência dos sistemas de verificação de backend do Google e da Apple, e os métodos internos de avaliação não divulgados permanecem como um fator potencial de incerteza

Leituras relacionadas

1 comentários

 
GN⁺ 24 일 전
Opiniões no Hacker News

  • A especificação eIDAS 2.0 não exige hardware específico
    É apenas uma estrutura para armazenar credenciais verificáveis e certificados assinados criptograficamente
    Parece mais uma preguiça da equipe de implementação alemã para contornar a cláusula de que “o usuário deve poder implementar um mecanismo para verificar a autenticidade da Wallet Unit”
    A documentação relacionada pode ser consultada em EUDI Architecture and Reference Framework

    • Pela implementação de referência, os mantenedores parecem não querer remover a dependência do Google
      O motivo não está claro, mas quando algo continua sem motivo aparente, no fim acaba havendo um motivo
      Veja o repositório no GitHub
    • Na seção 5.4, em Attestation Rulebooks e Attestation Schemes, as regras relacionadas estão especificadas

  • Como implementador alemão, de acordo com o regulamento de execução do eIDAS, é preciso usar um mecanismo de attestation
    Isso não funciona sem suporte do sistema operacional
    Sabemos que hoje estar limitado a Google/Android não é o ideal, e também há planos de suporte a outros sistemas, como o GrapheneOS
    No momento, isso é apenas uma questão de prioridade, não falta de percepção do problema

    • Depender de produtos de duas empresas americanas não é algo apenas “ruim”, e sim um problema grave
      Há muitos casos de contas bloqueadas, e uma dependência desse tipo seria melhor nem existir
    • Há também um elemento de ilegalidade do ponto de vista de acessibilidade e do espírito do eIDAS
      No fim, todos os cidadãos ficam subordinados aos termos da Google e da Apple, e se a conta for suspensa, o acesso ao serviço de eID se torna impossível
      Como existem alternativas tecnicamente viáveis, é sua responsabilidade encontrar esse tipo de solução
    • Como cidadão alemão, quero perguntar: por que seguir adiante sabendo que isso não vai funcionar para todos?
      Eu saí de um Android baseado em AOSP sem Google Play para o Ubuntu Touch, e no futuro pretendo migrar para o postmarketOS
    • É fácil demais perder acesso a uma conta Google. A recuperação também é impossível
      Considerando situações assim e os riscos geopolíticos, não dá para justificar a dependência de uma empresa específica
      Pela experiência de desenvolvedor, também há a lição de que “uma gambiarra temporária é a solução mais permanente”
    • Por que mudar para o modelo de Wallet algo que já havia sido resolvido no eIDAS 1 com Mobile-ID (baseado em SIM) ou Smart-ID (gestão de chaves no lado do servidor)?
      Não há motivo para depender dos backends de duas empresas americanas

  • O próprio attestation deveria ser abolido
    O app não deveria saber em que dispositivo está rodando
    Basta o usuário proteger seu próprio dispositivo, e o desenvolvedor apenas apresentar recomendações
    Deveria ser possível executar em qualquer ambiente: GrapheneOS, root, emulador, camada de compatibilidade Linux etc.

    • Exato, o dispositivo é meu, então devo poder usá-lo como quiser
      É desnecessário que o app verifique automaticamente se ele foi “certificado” por big techs americanas
    • O próprio conceito de confiança no dispositivo é ilusório
      Pela história dos consoles e celulares com root, nenhuma segurança é perfeita
      O ideal seria deixar como opção o usuário vincular sua identidade ao próprio dispositivo, se quiser
    • Claro, fazer root ou modificar é uma liberdade, mas é preciso arcar com as consequências
      Se o app não puder verificar a própria integridade, alguns recursos serão impossíveis do ponto de vista de segurança
      Assim como um documento físico tem restrições de formato e tamanho, certos limites são necessários
    • O pecado original da computação moderna é que os ‘elementos de segurança’ foram projetados para os fabricantes, não para o usuário
      O começo do problema foi não ter proibido legalmente esse tipo de elemento na época do NGSCB

  • E se você perder a conta Google/Apple?
    Se virar alvo de sanções, como um juiz do Tribunal Penal Internacional, o acesso ao eIDAS se torna impossível
    É uma realidade contraditória que a sociedade europeia continue presa a uma estrutura dependente de empresas americanas

    • Mesmo sem ser uma figura pública, um bloqueio automático de conta pode levar à exclusão social
      É perigoso que duas empresas estrangeiras tenham poder de vigilância e controle
    • Se “a capital da Europa fica em Washington”, talvez isso seja algo natural
    • Aí você também não vai poder usar o Waymo

  • É chocante que haja tão pouca oposição pública a esse tipo de política
    Como pai/mãe, entendo a necessidade de controlar o uso da internet pelas crianças,
    mas no fim o Estado está fazendo o que caberia aos pais e estamos perdendo liberdade e privacidade

    • A maioria das pessoas entende isso apenas de forma abstrata, em relação ao impacto na própria vida
      A menos que seja uma ameaça concreta como “o governo lê minhas mensagens no WhatsApp”, elas não reagem
    • Na Alemanha, a atenção se dispersa com questões desgastantes como o debate sobre limite de velocidade
      A classe política aproveita essa confusão para esconder os problemas essenciais
    • Na verdade, muitos pais são favoráveis a restringir o acesso online
      Querem que seus filhos sejam protegidos da exploração da atenção por grandes empresas
      Assim como há restrições de idade no mundo real, o online não precisa ser exceção
    • As pessoas ficam presas nas suas próprias bolhas de filtro e nem chegam a ouvir falar desses temas
      Pensando no futuro da democracia, isso é muito preocupante
    • A UE na prática funciona como uma plataforma de lobby
      O lobby cidadão é possível, mas exige custo e coordenação, então as grandes empresas acabam dominando
      Houve também recentemente um incidente em que a infraestrutura digital da UE foi comprometida por um grupo de hackers
      Artigo relacionado

  • Exigir hardware e software específicos é irracional
    Todos os cidadãos deveriam poder usar o computador que quiserem
    Autenticação com senha ou par de chaves já é suficiente, e, se quiser, pode-se adicionar TOTP ou chave de segurança
    Parece que esqueceram que existem computadores além do smartphone

    • A UE diz que vai criar um sistema de pagamentos independente de VISA e MasterCard, mas no fim há dependência da app store
      Sem conta Apple ou Google, nem o pagamento em euro digital será possível
      É surpreendente que políticos e bancos não consigam enxergar dois ou três passos à frente
    • A política da UE não caminha na direção de “avaliação autônoma de risco pelo usuário”,
      mas sim da ideia de que o provedor de serviço deve proteger o usuário
      Como resultado, a limitação das plataformas suportadas se torna inevitável
    • Dizer que “deveria rodar em qualquer computador” é irrealista
      Isso não significa, legalmente, que tenha de funcionar até em um Apple II

  • Pessoas sancionadas ou certos grupos não conseguem acessar a Play Store,
    então talvez nem consigam instalar o app do eIDAS

    • Se precisar de conta, então sim.
      Vendo casos recentes de remoção de contas de opositores políticos, talvez para algumas autoridades isso até seja conveniente
    • Mas a proteção da chave privada é o ponto central
      É necessário um dispositivo de segurança como um smart card, então um ambiente totalmente aberto é arriscado
      Entendo querer usar um “Android alternativo”, mas é preciso reconhecer que isso é um ambiente não seguro

  • Fico me perguntando quanto orçamento a UE vai desperdiçar com um sistema desses
    Não sei quem realmente precisa disso

  • Self Sovereign Identity (SSI) é a única solução verdadeira
    A identidade de uma pessoa não deveria ficar subordinada a nenhuma instituição ou empresa
    A identidade deveria ser apenas ‘eu mesmo’
    O que precisamos não é Google ID nem Apple ID, e sim uma identidade autossoberana

    • Mas “eu sou apenas eu” não é uma verificação de identidade viável no mundo real
      Você não pode dizer isso no bar no lugar de mostrar um documento
      Dentro do contrato social, uma verificação funcional de identidade é necessária
    • A UE já criou em 2019 o ESSIF (European Self-Sovereign Identity Framework)
      A infraestrutura existe há 7 anos, então também não dá para dizer apenas que o governo é incompetente

  • Parece que está na hora de um “incêndio digital do Reichstag”
    Dá vontade de perguntar quando a Alemanha vai parar com esse hábito de repetir a história