ed25519-unsafe-libs

Ataque de Oráculo à Função de Assinatura com Chave Pública Dupla no Ed25519

Uma lista de bibliotecas de assinatura ed25519 potencialmente inseguras que permitem uma API pública onde a chave secreta e a chave pública podem ser fornecidas independentemente como entradas da função de assinatura. O uso indevido dessas APIs públicas pode resultar na exposição da chave privada.

A maioria dos repositórios em nossa análise está listada em IANIX :: Things that use Ed25519.

Número de bibliotecas afetadas: 45
Número de bibliotecas que corrigiram o problema após o anúncio: 8
última atualização: 4 de maio de 2023

Implementações de Prova de Conceito que demonstram este exploit potencial:

• Rust: ed25519-chalkias-exploit
• Python: Ed25519 Vulnerability in Python, Buchanan, William J (2022). Ed25519 Vulnerability in Python (Recovering Private Key). Asecuritysite.com.

Palestras:

• Palestra convidada no Crypto Reading Club do Instituto Nacional de Padrões e Tecnologia (NIST) dos EUA: slides - Taming the Many EdDSAs (páginas 28-39), Konstantinos Chalkias, François Garillot, Valeria Nikolaenko (2023). Taming the Many EdDSAs & Ed25519 Signing Attacks.

Cobertura deste ataque em notícias e redes sociais

• NIST Crypto Reading Club "Taming the Many EdDSAs" (8 de março de 2023)
• The Daily Swig "Dozens of cryptography libraries vulnerable to private key theft" (28 de junho de 2022)
• Risky Biz News "New crypto vulnerability: Tens of cryptography libraries have misimplemented the Ed25519 digital signature algorithm" (28 de junho de 2022)
• SafeHeron blogpost "Analysis on Ed25519 Use Risks: Your Wallet Private Key Can Be Stolen" (17 de junho de 2022)
• kryptera.se "Vulnerability in most ed25519 libraries" (em sueco) (29 de junho de 2022)
• Difesa e Sicurezza & Yoroi "Librerie crittografiche ed25519 potenzialmente non sicure" (em italiano) (1 de julho e 29 de junho de 2022)
• Medium post by Prof Bill Buchanan OBE "Ed25519 is Great, But ..." (1 de julho de 2022)
• Reddit r/crypto (melhor post do mês - 18 de junho de 2022)
• Reddit r/cryptography (17 de junho de 2022)
• Tweets interessantes:
  • tweet 1 (por Kostas Kryptos - "As 26 bibliotecas vulneráveis originais")
  • tweet 2 (por Kostas Kryptos - "Consequências das 40 bibliotecas vulneráveis")
  • (por Catalin Cimpanu - "40 bibliotecas criptográficas são afetadas pela mesma implementação incorreta do Ed25519")

Qual é o problema?

Observe que, normalmente e de acordo com a rfc8032 relacionada, as assinaturas EdDSA são determinísticas e, portanto, para a mesma mensagem de entrada a ser assinada, é retornada uma saída de assinatura única que inclui dois elementos: um ponto da curva R e um escalar S.

Um detalhe algorítmico é que a chave pública do signatário está envolvida apenas no cálculo determinístico da parte S da assinatura, mas não no valor R. Isso implica que, se um adversário puder, de alguma forma, usar a função de assinatura como um Oráculo (que espera chaves públicas arbitrárias como entradas), então é possível que, para a mesma mensagem, se obtenham duas assinaturas que compartilham o mesmo R e diferem apenas na parte S. Infelizmente, quando isso acontece, é possível extrair facilmente a chave privada; esta publicação no StackOverflow explica por que isso é viável.

Dito isso, APIs públicas NÃO devem permitir um par de chaves privada/pública desacoplado como entrada de assinatura. Para contornar isso, muitas implementações armazenam a chave pública juntamente com a chave privada (ou seed) e consideram todo o par de chaves como o segredo OU sempre rederivam a chave pública dentro da função de assinatura. Infelizmente, um grande número de bibliotecas existentes não resolve esse problema, permitindo chaves públicas arbitrárias como entradas sem verificar se a chave pública de entrada corresponde à chave privada de entrada.

É claro que isso não significa que todas as aplicações com dependências dessas bibliotecas estão sujeitas a ataques de exposição de chave; na verdade, a maioria provavelmente está segura, pois normalmente não expõe publicamente a API afetada aos seus usuários e acopla seu par de chaves pública/privada imediatamente antes da invocação do sign. Por outro lado, mesmo quando essas APIs não são expostas, há aplicações com diferentes estratégias de modelo de ameaça de TCB sobre como as chaves privadas e públicas são gerenciadas e armazenadas. Dito isso, para prevenir este ataque, os desenvolvedores também devem aplicar um protocolo de proteção de integridade para as chaves públicas.

Aqui, listamos algumas bibliotecas afetadas juntamente com as referências de código relacionadas.

Fig 1. Um exemplo de uso indevido da API na crate ed25519-dalek do Rust.

Bibliotecas afetadas

• C: OpenGNB
  https://github.com/gnbdev/opengnb/blob/master/libs/ed25519/sign.c#L7

• C: GNU Nettle
  https://github.com/gnutls/nettle/blob/fe7ae87d1b837e82f7c7968b068bca7d853a4cec/ed25519-sha512-sign.c#L43

• ASM/C: iroha-ed25519 (Hyperledger Project)
  https://github.com/hyperledger/iroha-ed25519/blob/main/lib/ed25519/ref10/ed25519.c#L27 e https://github.com/hyperledger/iroha-ed25519/blob/main/lib/ed25519/amd64-64-24k-pic/ed25519.c#L30

• C: ed25519-donna (Andrew Moon)
  https://github.com/floodyberry/ed25519-donna/blob/master/ed25519.c#L59

• C: ed25519 (Orson Peters)
  https://github.com/orlp/ed25519/blob/master/src/sign.c#L7

• C: libbrine (Kevin Smith)
  https://github.com/kevsmith/libbrine/blob/master/src/ed25519/sign.c#L7

• C++: Ed25519 (ArduinoLibs)
  https://rweather.github.io/arduinolibs/classEd25519.html#a36ecf67b4c5d2d39a31888f56af1f8a5

• C#: ed25519 (Hans Wolff)
  https://github.com/hanswolff/ed25519/blob/master/Ed25519/Ed25519.cs#L146

• C#: Ed25519 (CryptoManiac)
  https://github.com/CryptoManiac/Ed25519/blob/972829ac688847895d5105f19ca1e5777131b421/Chaos.NaCl/Internal/Ed25519Ref10/keypair.cs#L7

• Dart: ed25519_dart (Oleksii Semeshchuk)
  https://github.com/semolex/ed25519_dart/blob/master/lib/src/ed25519_dart_base.dart#L200

Bibliotecas corrigidas

• C: Trezor firmware
  Corrigido neste PR: https://github.com/trezor/trezor-firmware/pull/2349 (Correção incorporada em 27 de junho de 2022)

• Java: ed25519-elisabeth (Jack Grigg)
  Corrigido neste commit: https://github.com/cryptography-cafe/ed25519-elisabeth/commit/49545ce47d550fed807522dff86546c812ccbbac (Correção incorporada em 19 de junho de 2022)

• C: Harbour (Viktor Szakats)
  Corrigido neste commit: https://github.com/vszakats/hb/commit/bae610b63d35c6c1793d94a3bf9467c3b1eded18 (Correção incorporada em 30 de junho de 2022)

• Rust/Wasm: polkadot-js/wasm
  Corrigido neste PR: https://github.com/polkadot-js/wasm/pull/381/files (Correção incorporada em 3 de julho de 2022)

• C: horse25519 (Yawning Angel)
  Corrigido neste PR: https://github.com/Yawning/horse25519/pull/3 (Correção incorporada em 15 de agosto de 2022)

• Erlang: erlang-libdecaf
  Corrigido neste commit: https://github.com/potatosalad/erlang-libdecaf/commit/16ba07ea122660e95f6cfa9107e28ed58bada713. Lógica tratada nesta issue: ed25519-unsafe-libs/issues/7 (Correção incorporada em 28 de agosto de 2022)

• Rust: ed25519-dalek (Isis Agora Lovecruft)
  Corrigido neste PR: https://github.com/dalek-cryptography/ed25519-dalek/pull/205 (Correção incorporada em 22 de outubro de 2022)

• C: Monocypher (Loup Vaillant)
  Corrigido neste commit: https://github.com/LoupVaillant/Monocypher/commit/da7b5407d20329f21a53ea993f516fb55e2f5e26 (Correção incorporada em 27 de fevereiro de 2023)

Falsos positivos (provavelmente seguras)

Bibliotecas originalmente reportadas como vulneráveis, mas removidas da lista com base no feedback da comunidade.

• Go: threshold-ed25519 — Assinaturas limiar usando Ed25519
  https://gitlab.com/unit410/threshold-ed25519/-/blob/main/pkg/ed25519.go#L161 -> ver relatório https://github.com/MystenLabs/ed25519-unsafe-libs/pull/9 (reportado em 27 de outubro de 2022 por nitronit)