Minerva: uma série de vulnerabilidades em implementações ECDSA / EdDSA

Minerva

Pesquisadores da Universidade de Masaryk revelaram informações importante sobre vulnerabilidades em vários euImplementações do algoritmo de geração de assinatura digital ECDSA / EdDSA, que permite recuperar o valor da chave privada com base na análise de vazamentos de informação em bits individuais que surgem ao aplicar métodos de análise através de canais de terceiros. As vulnerabilidades têm o codinome Minerva.

Os projetos mais famosos aquele afeto o método de ataque proposto é OpenJDK, OracleJDK (CVE-2019-2894) e a biblioteca libgcrypt (CVE-2019-13627) usado no GnuPG. Os problemas são também suscetível para bibliotecas MatrixSSL, Crypto ++, wolfCrypt, elíptico, jsrsasign, Python-ECDSA, ruby_ecdsa, fastecdsa e também alguns cartões inteligentes Athena IDProtect, TecSec Armored Card, SafeNet eToken 4300, Valid S / A IDflex V.

Além das vulnerabilidades mencionadas no momento, elas não são afetadas OpenSSL, Botan, mbedTLS e BoringSSL. Mozilla NSS, LibreSSL, Nettle, BearSSL, cryptlib, OpenSSL no modo FIPS. Criptografia do Microsoft .NET, kernel do Linux libkcapi, Sodium e GnuTLS ainda não foram testados.

Encontramos implementações que perdem o comprimento de bit do escalar durante a multiplicação escalar em ECC. Esse vazamento pode parecer minúsculo, pois o comprimento do bit tem uma quantidade muito pequena de informações presentes no escalar. No entanto, no caso de geração de assinatura ECDSA / EdDSA, filtrar o comprimento do bit nonce aleatório é suficiente para a recuperação completa da chave privada usada após observar algumas centenas a alguns milhares de assinaturas em mensagens conhecidas, devido a à aplicação de algumas técnicas.

Acreditamos que todas as placas anteriores foram afetadas porque compartilham um componente ECDSA comum (módulo FIPS 214), que é descrito como Athena OS2 ECDSA755 Component no Inside Secure AT90SC A1.0 (Firmware). Testamos a vulnerabilidade apenas no cartão Athena IDProtect com dados CPLC e ATR

O problema é causado pela capacidade de determinar valores de bits individuais durante a multiplicação por um escalar durante a negociação ECC. Métodos indiretos, como estimar o atraso na execução de cálculos, são usados ​​para extrair informações de bits.

Um ataque requer acesso sem privilégios ao host em que a assinatura digital é gerada (um ataque remoto não está excluído, mas é muito complicado e requer uma grande quantidade de dados para análise, portanto pode ser considerado improvável).

Apesar do pequeno tamanho do vazamento, para o ECDSA, definir mesmo alguns bits com informações sobre o vetor de inicialização (nonce) é suficiente para realizar um ataque para restaurar sequencialmente a chave privada completa.

De acordo com os autores do método, para uma recuperação de chave bem sucedida, a análise de várias centenas a vários milhares de assinaturas digitais geradas é suficiente para mensagens conhecidas do invasor. Por exemplo, para determinar a chave privada usada no cartão inteligente Athena IDProtect baseado no chip Inside Secure AT90SC, usando a curva elíptica secp256r1, 11 mil assinaturas digitais foram analisadas. O tempo total de ataque foi de 30 minutos.

Nosso código de ataque e prova de conceito são inspirados no método Brumley & Tuveri.

O problema já foi corrigido no libgcrypt 1.8.5 e wolfCrypt 4.1.0, outros projetos ainda não geraram atualizações. Também é possível rastrear a correção de vulnerabilidade no pacote libgcrypt em distribuições nestas páginas: Debian, Ubuntu, RHEL, Fedora, openSUSE / SUSE, FreeBSD, Arch.

Os pesquisadores também testaram outros cartões e bibliotecas, dos quais os seguintes não são vulneráveis:

  • OpenSSL 1.1.1d
  • BouncyCastle 1.58
  • BoringSSL 974f4dddf
  • libtomcrypt 1.18.2
  • Inicialização 2.11.0
  • Microsoft GNV
  • mbedTLS 2.16.0
  • Intel IPP-Cripto

Cartões

  • AQS ACOSJ 40K
  • Feitian A22CR
  • G&D SmartCafe 6.0
  • G&D SmartCafe 7.0
  • Infineon CJTOP 80K INF SLJ 52GLA080AL M8.4
  • JCard Universal Infineon SLE78
  • NXP JCOP31 v2.4.1
  • NXP JCOP CJ2A081
  • NXP JCOP v2.4.2 R2
  • NXP JCOP v2.4.2 R3
  • SIMOME TaiSYS Vault

Se quiser saber mais sobre o ataque usado e as vulnerabilidades detectadas, você pode fazer isso no link a seguir As ferramentas usadas para replicar o ataque estão disponíveis para download.


Deixe um comentário

Seu endereço de email não será publicado. Campos obrigatórios são marcados com *

*

*

  1. Responsável pelos dados: Miguel Ángel Gatón
  2. Finalidade dos dados: Controle de SPAM, gerenciamento de comentários.
  3. Legitimação: Seu consentimento
  4. Comunicação de dados: Os dados não serão comunicados a terceiros, exceto por obrigação legal.
  5. Armazenamento de dados: banco de dados hospedado pela Occentus Networks (UE)
  6. Direitos: A qualquer momento você pode limitar, recuperar e excluir suas informações.