Apretón de manos de TLS 1.2: ¿Cómo está firmada la clave pública de ECDHE por el servidor?

1

Estoy tratando con una situación en la que se elige una opción de cifrado, como ECDHE-ECDSA-AES128-SHA , para establecer una conexión TLS. En este caso, se requiere que un servidor, al enviar el mensaje ServerKeyExchange al cliente, firme la clave del infierno hellman efímero (EC) usando su clave privada ECDSA (asociada con el certificado de clave pública). La clave pública primero se procesa antes de que se pueda realizar una operación de firma de ECDSA.

Mi pregunta: ¿cómo se determina el algoritmo de hash durante el apretón de manos?

RFC 4492 que describe la aplicación de ECC a TLS 1.2 tiene el siguiente texto para indicar cómo se determina este algoritmo:

  

"“ Todos los cálculos de ECDSA DEBEN realizarse según ANSI X9.62 [7]   o sus sucesores. Los datos para ser firmados / verificados están en hash, y el
  el resultado se ejecuta directamente a través del algoritmo de ECDSA sin
adicional   hashing La función hash predeterminada es SHA-1 [10] , y sha_size   (ver Secciones 5.4 y 5.8) es 20. Sin embargo, un hash alternativo   función, como una de las nuevas funciones hash SHA especificadas en   FIPS 180-2 [10], puede usarse en su lugar si el certificado que contiene   La clave pública de la CE requiere explícitamente el uso de otro hash   función. ( El mecanismo para especificar el hash requerido   La función no se ha estandarizado , pero esta disposición   anticipa dicha estandarización y evita la necesidad de actualizar   este documento en respuesta. Los futuros PKIX RFC pueden elegir, para   ejemplo, para especificar la función hash que se utilizará con una clave pública   en el campo de parámetros de subjectPublicKeyInfo.) "

Sin embargo, si uno hace referencia a los requisitos de NIST Suite-B para TLS 1.2 (RFC 5430), queda claro en el uso de SHA256 y SHA384 para el nivel de seguridad deseado (ya que SHA1 está en desuso por NIST).

Entonces, en el protocolo de enlace TLS, ¿cómo se especifica el uso de SHA256 en el procedimiento de firma anterior?

Gracias,

Hari Tadepalli

    
pregunta user13311 23.01.2015 - 18:16
fuente

1 respuesta

4

RFC 4492 especifica ECC para TLS1.0 y TLS1.1. No cubre TLS1.2 porque se escribió antes de TLS1.2; observe que 4492 es menor que 5246. RFC 5246 TLS1.2 cambia la estructura de firmas para todos los algoritmos de firma, incluido ECDSA, y también agrega una extensión Hello para negociar los algoritmos de firma compatibles (incluido el hash) de manera más flexible.

RFC 5246 A.7 Cambios en RFC 4492

  

RFC 4492 [TLSECC] agrega conjuntos de cifrado de curva elíptica a TLS. Este
  documento cambia algunas de las estructuras utilizadas en ese documento. Este
  La sección detalla los cambios necesarios para los implementadores de ambos RFC.   4492 y TLS 1.2. Implementadores de TLS 1.2 que no están implementando
  RFC 4492 no necesita leer esta sección.

     

Este documento agrega un campo "signature_algorithm" a digitalally-
  Elemento firmado para identificar la firma y el resumen.
  Algoritmos utilizados para crear una firma. Este cambio se aplica a
  firmas digitales formadas usando ECDSA también, lo que permite a ECDSA
  firmas que se utilizarán con algoritmos de resumen distintos de SHA-1,
  siempre que dicho uso sea compatible con el certificado y cualquier   restricciones impuestas por futuras revisiones de [PKIX].

     

Como se describe en las Secciones 7.4.2 y 7.4.6, las restricciones en el
  Los algoritmos de firma utilizados para firmar certificados ya no están vinculados a
  el conjunto de cifrado (cuando lo utiliza el servidor) o el servidor   ClientCertificateType (cuando lo utiliza el cliente). Así, el
  restricciones en el algoritmo utilizado para firmar certificados especificados en
  Las secciones 2 y 3 de RFC 4492 también están relajadas. Como en este documento,
  las restricciones en las claves en el certificado de entidad final permanecen.

En particular RFC 5246 4.7 Atributos criptográficos

  

Un elemento firmado digitalmente se codifica como una estructura firmada digitalmente:

  struct {
     SignatureAndHashAlgorithm algorithm;
     opaque signature<0..2^16-1>;
  } DigitallySigned;
     

El campo de algoritmo especifica el algoritmo utilizado (ver Sección
     7.4.1.4.1 para la definición de este campo). Tenga en cuenta que el
     La introducción del campo del algoritmo es un cambio de la versión anterior.      versiones .... RSA .... DSA ....

Puntos adicionales:

  • el servidor firma su clave pública ECDHE y la curva (que en la práctica, especialmente para Suite B, se denomina forma en lugar de explícito, por lo tanto bastante pequeño) (edite, gracias a David) , así como también los nonces, con al menos el cliente nonce demostrando frescura

  • Los requisitos de la Suite B están establecidos por NSA, no por NIST. IIRC Suite B requiere SHA256 y SHA384 antes NIST "en desuso" SHA1.

  • RFC 5430 fue obsoleto por RFC 6460 que requiere TLS1.2 y GCM, así como ECDHE-ECDSA.

respondido por el dave_thompson_085 24.01.2015 - 11:19
fuente

Lea otras preguntas en las etiquetas