En el protocolo de enlace SSL, tanto el cliente como el servidor generan sus respectivos números aleatorios. Luego, el cliente genera un secreto maestro previo y lo cifra con la clave pública del servidor. Sin embargo, ¿por qué el cliente no puede generar el secreto maestro previo y enviarlo al servidor? ¿Por qué necesitamos un cliente y un servidor al azar? ¿Es para contribuir a la entropía en el secreto maestro o para uniformidad con otros algoritmos de intercambio de claves como DH?
De Los primeros milisegundos de una conexión HTTPS : / p>
El secreto principal es una función del cliente y del servidor.
master_secret = PRF(pre_master_secret,
"master secret",
ClientHello.random + ServerHello.random)
Tanto el cliente como el servidor deben poder calcular el secreto maestro. Generar un secreto pre-maestro en el cliente y solo enviarlo al servidor significaría que el cliente nunca podrá descubrir el secreto maestro.
Esto significaría que toda la rutina de generación de claves se basó en los valores generados por el cliente. Si un atacante Man-In-The-Middle repitiera el saludo, se enviaría el mismo secreto pre-maestro y luego se usaría para la conexión. Hacer que el servidor genere un valor aleatorio ( ServerHello.random ) significará que el secreto MAC es diferente si se repite el ClientHello.random , y por lo tanto el MAC y las claves de cifrado serán diferentes, evitando que replay attack .
Útil al reanudar una sesión
En TLS, el secreto maestro se usa con bytes aleatorios del servidor y del cliente en una función PRF para calcular un bloque de clave.
key_block = PRF(SecurityParameters.master_secret,
"key expansion",
SecurityParameters.server_random +
SecurityParameters.client_random)
Luego, el bloque de teclas se divide para proporcionar seis teclas utilizadas para diferentes operaciones:
Al reanudar una sesión, se utiliza la misma clave maestra para generar el bloque de claves. Por lo tanto, el uso de bytes aleatorios de clientes y servidores garantiza que el bloqueo de claves será diferente en cada saludo de mano.
Es para contribuir a la entropía en el secreto maestro ...
Sí. Asegura que ambas partes contribuyan al secreto maestro.
El secreto principal es la semilla utilizada para derivar las claves subsiguientes que se usan para el cifrado y la autenticación en masa.
... o para uniformidad con otros algoritmos de intercambio de claves como DH?
No. Diffie-Hellman requiere que ambas partes contribuyan seleccionando un valor secreto aleatorio a (o b ), y luego enviando a la otra parte el A=G^a (o B=G^b ). El comportamiento contributivo se integra en Diffie-Hellman.
Hay otros esquemas de acuerdos clave. RSA es un esquema de transporte clave, pero no ofrece la oportunidad de que el servidor contribuya al secreto del premaster. Es decir, no hay ningún comportamiento contributivo inherente al transporte de claves RSA.
En el caso del transporte de clave RSA, la forma de garantizar que ambas partes contribuyan al secreto maestro es:
master_secret = Transform(premaster_secret + client_random + server_random)
Un problema práctico que resuelve el comportamiento contributivo es, imagine un dispositivo IoT que tiene un generador de números aleatorios roto o inútil. El comportamiento contributivo garantiza que el canal sea [principalmente] seguro incluso cuando el cliente carece de aleatoriedad.
Es parte del Handshaking. expone el secreto del premaster, pero solo al servidor y al cliente, no a nadie en el medio. Nadie, excepto el servidor, puede acceder al secreto generado por el cliente debido a que nadie, excepto el servidor, tiene la clave secreta para descifrar.
Aparentemente, a mi intérprete no se le asigna el nombre de @Raz para que sea mejor. (incorperado en mi awnser arriba)
no, el secreto del premaster se cifra con la clave pública del servidor. El cliente y los rescates del servidor se utilizan con él (y otras constantes) para generar la clave maestra. Que luego se utiliza para generar claves de sesiones. Es posible que desee leer las respuestas de Cómo funciona SSL para obtener más detalles sobre el protocolo de enlace