Curva elíptica Diffie-Hellman

Diffie-Hellman de curva elíptica ( ECDH ) é um protocolo para acordo de chaves que permite que duas partes, cada uma com um par de chaves público-privadas de curva elíptica, estabeleçam um segredo compartilhado em um canal inseguro. [1] [2] [3] Esse segredo compartilhado pode ser utilizado diretamente como chave ou como base para derivar outra chave. A chave, ou a chave derivada, pode ser empregada para criptografar comunicações subsequentes por meio de um algoritmo de cifra de chave simétrica. Essa abordagem é uma variante do protocolo Diffie-Hellman que utiliza criptografia de curva elíptica, que oferece maior segurança e eficiência em comparação com outros métodos de criptografia convencionais.

Protocolo de estabelecimento de chaves

editar

O exemplo a seguir ilustra como uma chave compartilhada é estabelecida. Suponha que Alice queira estabelecer uma chave compartilhada com Bob, mas o único canal disponível para eles pode ser interceptado por terceiros.

Inicialmente, Alice e Bob concordam em usar uma criptografia de chave pública baseada em curvas elípticas. Para isso, definem os parâmetros de domínio (ou seja,   no caso principal ou   no caso binário) devem ser acordados.

Além disso, cada parte deve ter um par de chaves adequado para criptografia de curva elíptica, consistindo em uma chave privada   (um inteiro selecionado aleatoriamente no intervalo   ) e uma chave pública representada por um ponto   (onde  ). Seja o par de chaves de Alice   e o par de chaves de Bob seja  . Cada parte deve compartilhar sua chave pública publicamente antes da execução do protocolo.

Alice calcula o ponto  . Bob calcula o ponto   . O segredo compartilhado é   (a coordenada x do ponto). A maioria dos protocolos padronizados baseados em ECDH derivam uma chave simétrica de   usando alguma função de derivação de chave baseada em hash (HKDF).

O segredo compartilhado calculado por ambas as partes é igual, já que   .

Observe que a única informação inicialmente revelada por Alice sobre sua chave é a chave pública. Portanto, nenhuma outra pessoa, exceto Alice, pode determinar sua chave privada (que Alice conhece, pois a selecionou), a menos que essa pessoa seja capaz de resolver o problema do logaritmo discreto da curva elíptica. Da mesma forma, a chave privada de Bob também é segura. Nenhuma outra pessoa além de Alice ou Bob pode calcular o segredo compartilhado, a menos que seja capaz de resolver o problema Diffie-Hellman de curva elíptica.

As chaves públicas podem ser classificadas em estáticas ou efêmeras (também conhecidas como ECDHE, onde 'E' final significa "efêmero"). As chaves públicas estáticas são estáveis e podem ser consideradas confiáveis quando acompanhadas de um certificado válido. Por outro lado, as chaves públicas efêmeras são temporárias e não necessariamente autenticadas. Portanto, se a autenticação for desejada, garantias adicionais de autenticidade devem ser obtidas por meio de outros meios confiáveis. A autenticação é necessária para prevenir ataques do tipo "man-in-the-middle", nos quais um terceiro mal-intencionado se posiciona entre as partes e intercepta ou modifica as comunicações.

Se uma das chaves públicas de Alice ou Bob for estática, os ataques do tipo "man-in-the-middle" serão frustrados, pois a chave pública estática fornece um ponto de referência confiável para autenticar a comunicação. No entanto, é importante ressaltar que as chaves públicas estáticas não oferecem sigilo de encaminhamento nem resiliência em caso de comprometimento da chave, entre outras propriedades de segurança avançadas.

Os detentores de chaves privadas estáticas devem validar a chave pública do outro participante e aplicar uma função de derivação de chave segura ao segredo compartilhado bruto do protocolo Diffie-Hellman, a fim de evitar o vazamento de informações sobre a chave privada estática. Para esquemas com outras propriedades de segurança, é recomendado consultar o esquema MQV (Menezes-Qu-Vanstone).

Se Alice escolher intencionalmente pontos de curva inválidos ao gerar sua chave e Bob não verificar os pontos de Alice, ela poderá coletar informações suficientes da chave de Bob para derivar sua chave privada. Várias bibliotecas de TLS foram identificadas como vulneráveis a esse tipo de ataque.[4]

Esse ataque é conhecido como "ataque de chave inválida" ou "ataque de ponto inválido". Ele explora a falha na verificação dos pontos gerados em uma curva elíptica durante o processo de geração de chaves criptográficas. Essas bibliotecas TLS afetadas não implementaram adequadamente as verificações necessárias para garantir que os pontos gerados estejam em conformidade com a curva elíptica específica sendo utilizada.

O segredo compartilhado é distribuído uniformemente em um subconjunto de   de tamanho   . Por esse motivo, o segredo não deve ser usado diretamente como chave simétrica, mas pode ser usado como entropia para uma função de derivação de chave.

Programas

editar
  • Curve25519 é um conjunto popular de parâmetros de curva elíptica e implementação de referência por Daniel J. Bernstein em C . Ligações e implementações alternativas também estão disponíveis.
  • O aplicativo de mensagens LINE usou o protocolo ECDH para sua criptografia de ponta a ponta "Letter Sealing" de todas as mensagens enviadas por meio do referido aplicativo desde outubro de 2015. [5]
  • O Signal Protocol usa ECDH para obter segurança pós-compromisso. Implementações deste protocolo são encontradas no Signal, WhatsApp, Facebook Messenger e Skype .

Ver também

editar

Referências

editar
  1. NIST, Special Publication 800-56A, Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography, March, 2006.
  2. Certicom Research, Standards for efficient cryptography, SEC 1: Elliptic Curve Cryptography, Version 2.0, May 21, 2009.
  3. NSA Suite B Cryptography, Suite B Implementers' Guide to NIST SP 800-56A Arquivado em 2016-03-06 no Wayback Machine, July 28, 2009.
  4. Tibor Jager; Jorg Schwenk; Juraj Somorovsky (4 de setembro de 2015). «Practical Invalid Curve Attacks on TLS-ECDH» (PDF). European Symposium on Research in Computer Security (ESORICS'15) 
  5. JI (13 outubro 2015). «New generation of safe messaging: "Letter Sealing"». LINE Engineers' Blog. LINE Corporation. Consultado em 5 fevereiro 2018 
  NODES
todo 1