Ataque de canal lateral EUCLEAK contra a série YubiKey 5

 (ninjalab.io)
1 pontos por GN⁺ 2024-09-04 | 1 comentários | Compartilhar no WhatsApp
  • Enquanto elementos seguros são usados como base de confiança para autenticação forte, o EUCLEAK é um ataque de canal lateral que extrai a chave secreta da implementação ECDSA da Infineon, demonstrado na YubiKey 5Ci
  • A vulnerabilidade central está na operação de inverso modular em tempo não constante da biblioteca criptográfica da Infineon, que passou por cerca de 80 avaliações de certificação Common Criteria de nível máximo ao longo de 14 anos
  • O atacante precisa de acesso físico ao elemento seguro, além de algumas medições eletromagnéticas locais e equipamentos caros, software personalizado e capacidade técnica, mas a medição em si leva apenas alguns minutos
  • O impacto atinge a série YubiKey 5 com firmware anterior à versão 5.7 e microcontroladores de segurança que executam a biblioteca criptográfica da Infineon, incluindo TPMs
  • No FIDO, a extração da chave secreta ECDSA permite a clonagem do dispositivo, mas para fins de defesa contra phishing, ainda é mais seguro usar produtos afetados do que não usar nenhum

Onde o ataque EUCLEAK mira

  • Um elemento seguro (secure element) é um pequeno microcontrolador que gera e armazena segredos e executa operações criptográficas, muitas vezes recebendo avaliações de segurança Common Criteria no nível mais alto
  • Tokens de hardware FIDO são um meio de autenticação forte usado para login em serviços web, e o protocolo FIDO usa ECDSA como primitiva criptográfica central
  • A série YubiKey 5 é um token de hardware FIDO amplamente usado e utiliza o Infineon SLE78 como elemento seguro
  • A NinjaLab analisou a implementação ECDSA da Infineon usando o Feitian A22, uma plataforma aberta JavaCard semelhante baseada no Infineon SLE78, e projetou um ataque real explorando a vulnerabilidade de canal lateral
    • O ataque foi demonstrado na YubiKey 5Ci
    • A vulnerabilidade também se estende a microcontroladores de segurança mais recentes, como Infineon Optiga Trust M e Infineon Optiga TPM
  • A causa da vulnerabilidade é o inverso modular em tempo não constante da biblioteca criptográfica da Infineon Technologies, e ela não foi descoberta durante 14 anos e cerca de 80 avaliações de certificação Common Criteria de nível máximo
  • A documentação técnica detalhada está disponível em Download the Writeup

Produtos afetados e condições do ataque

  • O atacante precisa de acesso físico ao elemento seguro e pode extrair a chave secreta ECDSA com algumas medições locais de canal lateral eletromagnético
    • No protocolo FIDO, isso permite a clonagem de dispositivos FIDO
    • O ataque exige equipamentos caros, software personalizado e capacidade técnica
  • Os produtos afetados são os seguintes
    • Todas as versões existentes de microcontroladores de segurança da Infineon com a biblioteca criptográfica da Infineon embarcada
    • Versões existentes de TPMs da Infineon
    • Todas as YubiKey série 5 com firmware anterior à versão 5.7
  • Esses microcontroladores de segurança são usados em diversos sistemas de segurança que dependem de ECDSA, como passaportes eletrônicos, carteiras de hardware de criptomoedas, smart cards e casas inteligentes, mas ainda não foi confirmado se o EUCLEAK se aplica na prática a esses produtos
  • O JavaCard Feitian A22 é um produto antigo usado na pesquisa e não é mais vendido
    • Os produtos atualmente vendidos na loja online da Feitian, baseados em microcontroladores de segurança da Infineon, usam a própria biblioteca criptográfica da Feitian e, até onde a NinjaLab sabe, não são afetados por esta pesquisa

Mitigação e informações oficiais

  • O firmware 5.7 da YubiKey mudou, na atualização de 6 de maio de 2024, da biblioteca criptográfica da Infineon para a nova biblioteca criptográfica da Yubico
    • Até onde a NinjaLab sabe, essa nova biblioteca não é afetada pelo EUCLEAK
  • A Infineon já possui um patch para a biblioteca criptográfica, mas, até onde a NinjaLab sabe, ele ainda não passou pela avaliação de certificação Common Criteria
  • O pedido de CVE foi recusado, e a MITRE está usando CVE-2024-45678 em seu lugar
    • O pedido de atualização da descrição está pendente
  • A posição oficial pode ser consultada nos seguintes documentos

Leituras relacionadas

1 comentários

 
GN⁺ 2024-09-04
Opiniões do Hacker News

  • Segundo a matéria da Ars Technica, o invasor precisa não só do nome de usuário e da senha, mas também de acesso físico à chave; além disso, para devolver o dispositivo depois de desmontá-lo, teria de montá-lo novamente, então está longe de ser um ataque trivial
    Passar um pouco de esmalte nas emendas do plástico poderia servir como um canário para indicar adulteração
    Ainda assim, isso também expõe uma fraqueza dos tokens FIDO. É preciso manter manualmente uma lista de onde eles foram registrados e, se o token for perdido ou roubado, revogá-lo manualmente em todos os locais em que foi cadastrado

    • Não é um problema exclusivo da YubiKey
      Segundo a NinjaLab, todos os microcontroladores seguros da Infineon que executam a biblioteca criptográfica da Infineon são vulneráveis a esse ataque em todas as versões existentes conhecidas
      Isso inclui chips de passaportes eletrônicos dos EUA, China, Índia, Brasil e vários países da Europa e da Ásia, áreas seguras de celulares Samsung e OnePlus, carteiras de hardware de criptomoedas como Ledger e Trezor, cartões SIM, TPMs de notebooks Lenovo, Dell e HP, e chips EMV de cartões de crédito e débito
    • Uso o KeePassXC como gerenciador de senhas e marco com uma tag cada conta que usa uma chave de hardware
      Assim, se a chave for perdida, roubada ou parar de funcionar, consigo extrair rapidamente a lista de sites dos quais ela precisa ser removida
      Sempre registro 2 chaves e as guardo em locais fisicamente separados, para que eu ainda consiga fazer login se perder uma delas
    • Concordo que esse ataque não é trivial, mas a YubiKey às vezes é usada em ambientes de risco muito alto
      Isso inclui não só acesso a ativos de criptomoedas, mas também situações mais graves, como empresas de defesa
      Nesses casos, o invasor tem muitos recursos e forte motivação, e é justamente para impedir esse tipo de ataque que se usa uma YubiKey
      Portanto, a chave ainda oferece autenticação resistente a phishing, mas algumas expectativas de segurança devem ser consideradas quebradas
    • Um invasor com recursos suficientes também poderia fabricar uma chave substituta com backdoor contendo a mesma chave ECDSA
    • Para uma pessoa física, a resposta pode ser limitar o uso desse dispositivo apenas a serviços essenciais e depender de boa higiene de senhas para o restante

  • A parte mais irritante é que não dá simplesmente para substituir a YubiKey
    Usando passkeys ou chaves não descobríveis, antes de descartar essa chave é preciso passar por cada conta, uma por uma, e trocá-la por uma nova chave que não seja vulnerável
    O fato de serem não descobríveis também é um problema, porque não lembro onde usei a YubiKey no passado
    A matéria da Ars [0] também fala de PIN, mas isso não é um recurso específico da YubiKey, e sim um recurso do FIDO
    [0]: https://arstechnica.com/security/2024/09/yubikeys-are-vulner...
    [1]: https://new.reddit.com/r/yubikey/comments/12bv4sv/fido_pin_s...

    • Por outro lado, por causa da autenticação em dois fatores, que é o principal uso das chaves FIDO não descobríveis, eu me preocupo mais em ficar bloqueado fora das contas
      Já passei por isso quando a alfândega dos EUA reteve meus eletrônicos, incluindo a YubiKey
      Depois, consegui recuperar muitas contas que aceitavam e-mail como segundo fator ou como meio final de autenticação, mas algumas, incluindo a AWS, não permitiram isso
      Muitos sites incentivam o cadastro de autenticação em dois fatores sem explicar claramente os métodos alternativos de autenticação e as consequências da perda de acesso
    • Eu acompanho isso no gerenciador de senhas
      Nas contas em que a YubiKey está cadastrada, adiciono a tag "YubiKey (FIDO)"
    • Sites que usam tokens WebAuthn residentes, como o GitHub, conseguem listar na chave os sites conhecidos
      Ainda assim, a experiência do usuário desse fluxo todo ainda não está no nível esperado
    • Sempre detestei o fato de não ser possível clonar ou fazer backup de uma YubiKey pessoal, e por isso evitei usá-la em todos os lugares
    • Ainda não vi um site que não exija configurar alguma outra forma de autenticação em dois fatores ao registrar um dispositivo FIDO
      No meu caso, mantenho também TOTP em um app

  • Quando li que “todas as YubiKey 5 Series com firmware anterior à versão 5.7 são afetadas”, achei que bastaria atualizar o firmware do token físico de hardware
    Mas consta que o firmware da YubiKey não pode ser atualizado
    https://support.yubico.com/hc/en-us/articles/360013708760-Yu...
    Então a Yubico vai oferecer substituição gratuita, certo? Tenho algumas dessas YubiKeys…

    • A YubiKey foi criada para bloquear phishing, e esse ataque exige acesso físico
      Ou seja, se você é valioso o suficiente para ser alvo direto no mundo real, talvez nem devesse usar uma YubiKey para começo de conversa
      Alguém poderia trocar sua chave reserva por outra, e você talvez não percebesse até ser tarde demais
    • Uso uma 5C Nano 5.4.3; não há substituição gratuita, apenas medidas de mitigação
      https://support.yubico.com/hc/en-us/articles/15705749884444-...
    • Na última vez que houve um bug em chips Infineon que quebrava a criptografia, os cidadãos da Estônia receberam novos cartões de identidade gratuitamente
      Já a minha YubiKey 4, lançada havia menos de dois meses, deixou de funcionar como smartcard PIV com atestado de hardware

  • “Por causa de um cálculo de inverso modular que não é em tempo constante” não é um canal lateral sutil, como uma emissão eletromagnética minúscula
    Se o tempo varia conforme dados secretos é algo próximo do primeiro item a verificar em uma auditoria de canais laterais
    Basta validar se todas as operações sempre usam o mesmo número de ciclos de clock, independentemente dos dados, e erros também devem ocorrer após um número fixo de ciclos de clock, independente dos dados
    Fico me perguntando como os auditores deixaram isso passar

    • Para ser preciso, parece mais próximo de um canal lateral eletromagnético desse tipo
      Se entendi bem o artigo, o que não é constante no tempo não é a execução do algoritmo em si, mas o duty cycle do canal lateral de RF observável externamente
      Se o tempo de execução fosse realmente não constante, no pior caso o ataque poderia ser feito só via USB, mas a implementação da Infineon não parece vulnerável a ataques puramente temporais
      O nonce blinding também foi implementado, mas o problema é que usaram uma máscara de multiplicação muito menor que o tamanho da curva elíptica, tornando possível a força bruta
    • É uma das primeiras coisas que se verifica em uma revisão de código ECDSA, então, para a Infineon, é um erro constrangedor
    • Concordo. Eu esperava um ataque realmente avançado, mas isso parece mais um ataque de timing padrão com uma sonda bacana acoplada
      Ainda assim, a sonda em si é bacana

  • Se alguém está disposto a obter acesso físico a uma YubiKey, basta trocá-la por uma chave com aparência e desgaste parecidos
    Assim a vítima acreditaria que a YubiKey quebrou, ou o atacante ganharia tempo suficiente para usar a YubiKey
    Por exemplo, eu tenho duas YubiKeys; se alguém invadisse minha casa e trocasse a chave reserva, eu não perceberia até precisar usá-la
    No fim, esse ataque só faz sentido quando o alvo é valioso o suficiente para ser visado diretamente, e um alvo assim provavelmente usaria algo um pouco mais seguro que uma YubiKey

    • Com ykman list, é possível conferir as informações de identificação da YubiKey, então é fácil ter um procedimento para verificar se a chave quebrou ou foi realmente trocada
      Se a exigência de segurança for alta, basta verificar periodicamente ou proteger separadamente a localização física da chave reserva
      Também fico curioso sobre qual autenticador de hardware seria mais seguro que uma YubiKey
    • Se você tem acesso, é realmente fácil danificar a chave e trocá-la por uma reserva funcional
    • Na prática, a YubiKey quase nunca será o elo mais fraco da cadeia
      O atacante pode mirar o dispositivo, interceptar as comunicações, executar um mandado contra o serviço que hospeda os dados ou se infiltrar nele discretamente

  • PDF explicativo do EUCLEAK: https://ninjalab.io/wp-content/uploads/2024/09/20240903_eucl...
    Post no blog da Yubico: https://www.yubico.com/support/security-advisories/ysa-2024-...

  • A pesquisa da NinjaLab é excelente
    Uma parte especialmente interessante do aviso da Yubico é que essa clonagem local também neutraliza a atestação (attestation) [1] do protocolo WebAuthn
    Será que o protocolo poderia ter sido projetado para resistir melhor a esse ataque de clonagem local?
    “Um atacante pode usar a chave de atestação recuperada para criar uma YubiKey falsa. Nesse caso, uma declaração de atestação FIDO válida é gerada durante o make credential, permitindo contornar os controles de preferência de modelo de autenticador de uma organização para as versões afetadas da YubiKey.”

    1. https://www.w3.org/TR/webauthn-2/#attestation
    • Se o atacante está em uma situação em que consegue clonar o segredo usado para assinar solicitações, uma vez que possui esse segredo, não parece haver como distinguir a cópia do dispositivo original
      Todo o modelo de segurança de um elemento seguro está em impedir a extração da chave; se isso se torna possível, não é melhor do que armazenar a chave em um arquivo no computador
      Claro, para obter a chave é preciso abrir fisicamente o dispositivo, então ainda é mais seguro do que armazená-la no computador, desde que ninguém realmente leve a chave
    • Infelizmente, na prática é difícil. A atestação quase sempre depende de algum hardware seguro protegendo um segredo certificado pelo emissor, autenticando-se perante a parte confiável e mantendo a confiança com segredos derivados e armazenados
      Se esse segredo de atestação puder ser extraído de alguma forma, não há como impedir que o atacante crie um autenticador falso que produza atestações fraudulentas sem deixar de parecer genuíno
      Em teoria, seria possível reduzir o impacto do vazamento de um único segredo de atestação usando atestação indireta ou chaves de atestação exclusivas por autenticador
      Isso seria diferente de usar uma chave de atestação compartilhada por centenas de milhares de autenticadores, como na YubiKey, mas ainda assim provavelmente seria apenas uma mitigação probabilística

  • O site da Yubico diz que a versão 5.7 ou superior não é afetada
    Em outro texto da Yubico [1], consta que um dos recursos do lançamento 5.7 foi a migração para uma biblioteca criptográfica própria da Yubico, que realiza as operações criptográficas subjacentes de RSA e ECC
    Espero que muita gente a tenha examinado. Não entendo muito bem por que alguém desejaria usar uma biblioteca criptográfica própria em uma era com tantas implementações públicas e privadas
    [1] https://www.yubico.com/blog/now-available-for-purchase-yubik...

    • Porque esta é a segunda vez que um problema de segurança acontece por causa de um fornecedor, e a anterior foi ainda mais grave
      Se toda a empresa se baseia em criptografia, faz sentido de verdade contratar criptógrafos aplicados suficientes e assumir o controle do próprio destino
    • Em plataformas embarcadas, bibliotecas existentes podem não ter sido portadas, ou a plataforma pode ser tão diferente que portar seria impraticável
      Pode haver outros motivos, e em código fechado as considerações econômicas também pesam bastante
      Especialmente se a migração for de uma implementação anterior de fornecedor, fechada e provavelmente fornecida com código-fonte, para uma implementação interna
    • Quando a 5.7 foi lançada?

  • A Infineon aprontou de novo. Isso já aconteceu 7 anos atrás: https://en.wikipedia.org/wiki/ROCA_vulnerability

  • “A Infineon já tem um patch para a biblioteca criptográfica, mas, até onde se sabe, ele ainda não passou pela avaliação de certificação Common Criteria”, diz o texto; sinceramente, isso não é nada importante

    • Separadamente do ataque em si, é um experimento interessante e vale ser divulgado, mas, na prática, mesmo para dispositivos nominalmente vulneráveis, o impacto no mundo real não parece grande