Nell'handshake SSL sia il client che il server generano i rispettivi numeri casuali. Il client genera quindi un pre segreto master e lo crittografa con la chiave pubblica del server. Tuttavia, perché il client non può solo generare il pre master secret e inviarlo al server? Perché abbiamo bisogno di un client e un server casuali? Contribuisce all'entropia nel master secret, o per uniformità con altri algoritmi di scambio chiave come DH?
Da I primi pochi millisecondi di una connessione HTTPS :
Il master secret è una funzione dei randoms client e server.
master_secret = PRF(pre_master_secret,
"master secret",
ClientHello.random + ServerHello.random)
Sia il client che il server devono poter calcolare il master secret. Generare un segreto pre-master sul client e solo inviarlo al server significherebbe che il client non riesce mai a trovare il master secret.
Ciò significherebbe che l'intera routine di generazione delle chiavi era basata su valori generati dal client. Se un aggressore di Man-In-The-Middle ha ripetuto la stretta di mano, lo stesso segreto pre-master sarebbe stato inviato e quindi utilizzato per la connessione. Avere il server generare un valore casuale ( ServerHello.random ) significherà che il segreto MAC è diverso se viene ripetuto ClientHello.random , e quindi le chiavi MAC e di crittografia saranno diverse, impedendo qualsiasi attacco di rimbalzo .
Utile per riprendere una sessione
In TLS, il master secret viene utilizzato con byte casuali client e server in una funzione PRF per calcolare un blocco chiave.
key_block = PRF(SecurityParameters.master_secret,
"key expansion",
SecurityParameters.server_random +
SecurityParameters.client_random)
Quindi il blocco chiave viene diviso per fornire sei chiavi utilizzate per diverse operazioni:
Quando si riprende una sessione, viene utilizzata la stessa chiave master per generare il blocco chiave. Quindi l'uso di byte casuali client e server assicura che il blocco chiave sia diverso in ogni handshake.
Is it to contribute to the entropy in the master secret...
Sì. Assicura che entrambe le parti contribuiscano al segreto principale.
Il segreto principale è il seme utilizzato per derivare le chiavi successive utilizzate per la crittografia e l'autenticazione in blocco.
... or for uniformity with other key exchange algorithms such as DH?
No. Diffie-Hellman richiede ad entrambe le parti di contribuire selezionando un valore segreto casuale a (o b ), quindi inviando l'altra parte A=G^a (o B=G^b ). Il comportamento dei contributori è inserito in Diffie-Hellman.
Esistono altri schemi di accordi chiave. RSA è uno schema di trasporto chiave, ma non offre l'opportunità al server di contribuire al segreto premaster. Cioè, non esiste un comportamento contributivo inerente al trasporto di chiavi RSA.
Nel caso del trasporto di chiavi RSA, il modo per garantire che entrambe le parti contribuiscano al segreto principale è:
master_secret = Transform(premaster_secret + client_random + server_random)
Un problema pratico che il comportamento contributivo risolve è, immagina un dispositivo IoT che ha un generatore di numeri casuali rotto o inutile. Il comportamento contributivo garantisce che il canale sia [soprattutto] sicuro anche quando il client non ha casualità.
Fa parte del Handshaking. espone il segreto premaster ma solo al server e al client non a nessuno in mezzo. Nessuno tranne il server può accedere al segreto generato dal client a causa di nessuno, tranne il server che ha la chiave segreta per decifrare con.
A quanto pare il mio albeggiatore manca di citare @Raz qui per renderlo un abile bestseller. (incorperato nella mia testata sopra)
no the premaster secret is encrypted with the server's public key. The client and server ransoms are used with it (and other constants) to generate the Master key. Which is then used to generate sessions keys. Might want to read the answers for How Does SSL work for more details on the handshake