TLS - DHE_DSS: ¿Cómo sabe el cliente la clave pública del servidor DSS?

Question

TLS - DHE_DSS: ¿Cómo sabe el cliente la clave pública del servidor DSS?

#1 de dave_thompson_085 (0 votos)

1

Me pregunto dónde se comunicará al cliente la clave de servidor pública g ^ x para la autenticación DSS cuando se usa un conjunto de cifrado DHE_DSS en TLS 1.2. Precisamente:

Un certificado DSS contiene parámetros criptográficos (p_1, q_1, g_1). Estos valores son conocidos para el servidor (mediante la instalación del certificado) y para el cliente mediante el mensaje del certificado.

Para el algoritmo DHE, el servidor elige parámetros criptográficos (p_2, g_2, y_2 = g_2 ^ s). Para la autenticación DSS de estos parámetros, el servidor elige un valor aleatorio x, aplica el algoritmo de firma DSA y envía los datos autenticados a través del mensaje de intercambio de claves del servidor al cliente.

Para verificar los datos recibidos, el cliente necesita la clave pública DSS del servidor g_1 ^ x. Por lo que puedo ver en la especificación TLS 1.2 (RFC5246), esta clave pública DSS no forma parte del mensaje de intercambio de claves del servidor. Entonces:

Pregunta: ¿Cómo obtiene el cliente g_1 ^ x?

Comentario: En enlace mi g_1 ^ x es y = g ^ x en el Sección "Claves por usuario". Y el mensaje m en la página wiki consta aquí de los parámetros DHE (p_2, g_2, y_2).

tls diffie-hellman dsa

pregunta user120513 04.11.2017 - 17:20

fuente

1 respuesta

Lea otras preguntas en las etiquetas tls diffie-hellman dsa

Prácticas de seguridad para sondear de forma segura las API de terceros autenticadas en nombre de los clientes Asegurando una API REST multiusuario B2B (servidor a servidor) [cerrado]

score 0 · Accepted Answer

Expandido del comentario para el cierre, aunque francamente esto me parece más bien como el viejo personaje, "¿quién está enterrado en la tumba de Grant?"

TLDR: la clave pública (estática) está en el certificado de clave pública

SSL / TLS utiliza certificados X.509 para las claves públicas estáticas, o para ser exactos: SSL referenciado X.509v3, un estándar entonces recientemente publicado por lo que entonces era CCITT y desde entonces se ha convertido en UIT-T; los RFC para TLS hacen referencia a PKIX, que es un subconjunto (formalmente un perfil) de X.509v3 definido por una serie de RFC actualmente encabezados por rfc5280 .

Un certificado X.509 / PKIX contiene información sobre la clave pública del sujeto en una estructura de datos prosaicamente denominada SubjectPublicKeyInfo definida en 5280 sección 4.1 4.1.1.2 y 4.1.2.7 como:

   SubjectPublicKeyInfo  ::=  SEQUENCE  {
        algorithm            AlgorithmIdentifier,
        subjectPublicKey     BIT STRING  }

   AlgorithmIdentifier  ::=  SEQUENCE  {
        algorithm               OBJECT IDENTIFIER,
        parameters              ANY DEFINED BY algorithm OPTIONAL  }

que admite una variedad de algoritmos al especificar el algoritmo en sí y los parámetros dependientes del algoritmo, así como la clave pública dependiente del algoritmo "ajustada" dentro de una BIT STRING.

SPKI (como yo lo llamo) se especifica en detalle para varios algoritmos, incluido DSA (llamado de forma imprecisa DSS en el conjunto de cifrado SSL / TLS y nombres de intercambio de claves) en rfc3279 sección 2.3.2 . La parte de 'algoritmo' consiste en el OID (Identificador de objeto) para DSA, y parámetros que consisten normalmente en p, q, g como una SECUENCIA ASN.1 de INTEGERs - con una opción para omitir estos parámetros de un certificado si son 'heredados' del certificado de CA del emisor (una opción que nunca he visto usada). La parte 'subjectPublicKey' es simplemente el valor y (= g ^ x mod p) como un INTEGER ASN.1 en la envoltura BIT STRING.

La firma DSA (bajo la clave privada que coincide con la publicación en el certificado) en los valores DHE (p, g, y) en el mensaje ServerKeyExchange utiliza un valor 'aleatorio' convencionalmente anotado k (no x) para producir un par de enteros r, s que se transmiten (en ASN.1) en ese mismo mensaje ServerKeyExchange. (Técnicamente, k no necesita ser aleatorio siempre y cuando no se repita para datos diferentes; consulte rfc6979 para una alternativa determinista).