mystenlabs/ed25519-unsafe-libsLista de bibliotecas de assinatura ed25519 inseguras
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
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.
