¿Cómo se genera el secreto de Premaster en TLS?

Question

¿Cómo se genera el secreto de Premaster en TLS?

#1 de Tom Leek (8 votos)
#2 de harshc (4 votos)

4

Creo que utiliza una combinación de los valores aleatorios enviados en los mensajes de saludo. Desde RFC 2246: (TLSv1.0)

 RSA encrypted premaster secret message

   Meaning of this message:
       If RSA is being used for key agreement and authentication, the
       client generates a 48-byte premaster secret, encrypts it using
       the public key from the server's certificate or the temporary RSA
       key provided in a server key exchange message, and sends the
       result in an encrypted premaster secret message. This structure
       is a variant of the client key exchange message, not a message in
       itself.

   Structure of this message:
       struct {
           ProtocolVersion client_version;
           opaque random[46];
       } PreMasterSecret;

       client_version
           The latest (newest) version supported by the client. This is
           used to detect version roll-back attacks. Upon receiving the
           premaster secret, the server should check that this value
           matches the value transmitted by the client in the client
           hello message.

       random
           46 securely-generated random bytes.

¿Cómo coincidirá con el valor que el cliente envió anteriormente? ¿Puede alguien por favor explicar esto? ¡Gracias! ¿Hay alguna API para calcular este valor?

encryption tls rsa client-side

pregunta previouslyactualname 25.07.2014 - 22:00

fuente

2 respuestas

4

TLS admite múltiples esquemas de intercambio de claves y, por lo tanto, puede haber diferentes maneras de derivar un secreto maestro previo. TLS puede usar el intercambio de claves basado en RSA que se ha explicado bastante bien en el comentario anterior, también puede usar DH, DHE, ECDH, ECDHE (diffie-hellman, diffie-hellman con claves efímeras, curva elíptica diffie-hellman y ecdh con claves efímeras respectivamente).

En la familia de algoritmos DH, el secreto del premaster se genera a partir de dos grupos de valores:

Primitivas públicas elegidas por el servidor
Claves privadas del remitente y el receptor

El servidor comparte las primitivas públicas que el cliente usa junto con su clave privada para generar un secreto maestro previo. En el caso de Diffie Hellman es algo como esto:

Primitivas públicas :

p - a large prime 

g - primitive root modulo p

Claves privadas:

a - client's private key

b - server's private key

Intercambio de claves:

Server to Client  :  {g, p, (g^b mod p)}

Client Calculates :  (g^b mod p)^a = g^ab mod p

Client to Server  :  (g^a mod p)

Server Calculates :  (g^a mod p)^b = g^ab mod p

Si ve con cuidado, tanto el servidor como el cliente ahora tienen una clave común (g ^ ab mod p) que pueden usar como un secreto maestro previo.

Este secreto maestro previo se puede enviar a un HKDF para extraer varias claves seguras criptográficamente. Estas claves se pueden utilizar como claves de cifrado de sesión, claves hmac (o IV basadas en el cifrado de cifrado).

Elliptic Curve DH en lugar de usar primitivas como p y g, utiliza curvas elípticas llamadas.

Para tu otra pregunta,

¿Hay alguna API para calcular este valor?

Si te refieres a un valor aleatorio criptográficamente seguro, entonces sí, python tiene os.urandom (n)

que se puede usar para generar un n cifrado de bytes. valor aleatorio seguro.

respondido por el harshc 03.10.2016 - 03:38

fuente

Lea otras preguntas en las etiquetas encryption tls rsa client-side

¿Qué intentan lograr los atacantes cuando atacan programas locales, como los desbordamientos de búfer? Servidor situado en dos redes físicas: mala idea o no

score 8 · Accepted Answer

El cliente genera el secreto del premaster de 48 bytes al concatenar la versión del protocolo (2 bytes) y algunos bytes que el cliente genera aleatoriamente (46 bytes). Se supone que el cliente obtiene estos 46 bytes de un PRNG criptográficamente seguro ; en la práctica, esto significa usar el PRNG ofrecido por el sistema operativo ( /dev/urandom , CryptGenRandom() ...).

El cliente luego encripta el secreto del maestro de 48 bytes con la clave pública RSA del servidor (que el servidor envió previamente al cliente, en el mensaje Certificate ). El resultado cifrado es lo que el cliente envía al servidor como el mensaje ClientKeyExchange . En virtud de que RSA es, bueno, un algoritmo de cifrado asimétrico sólido, lo que el servidor descifra es igual a lo que el cliente cifró.

El servidor descifra el contenido del mensaje ClientKeyExchange usando su clave RSA privada. En ese momento, tanto el cliente como el servidor conocen el secreto premaster. Luego proceden a usarlo para calcular el secreto maestro (utilizando los mensajes client_random y server_random , intercambiados previamente en los mensajes ClientHello y ServerHello , y mezclando todo con el PRF). Desde el secreto maestro, volverán a utilizar algunas mezclas PRF para obtener las claves de cifrado reales para los datos subsiguientes.