Protocollo TLS, chiave di sessione per connessione protetta

2

In Wikipedia, come parte dell'handshaking tra un client e un server, il server invia una chiave di crittografia pubblica come parte del certificato digitale. Quindi il client utilizza lo scambio di chiavi Diffie-Hellman per generare in modo sicuro una chiave di sessione casuale e univoca per la crittografia e la decrittografia. Domande:

  1. la chiave pubblica inviata dal server è crittografata o chiara? Suppongo sia chiaro poiché è pubblico
  2. In che modo sono correlate la chiave di sessione e la chiave pubblica? Il client invia la chiave di sessione al server? chiave di sessione inviata: f (Random_gen_number, Public_key) dove f è una funzione di crittografia?
posta joseph cesana 04.06.2018 - 00:15
fonte

2 risposte

2

is the public key sent by server encrypted or clear? I assume it is clear since it is public

La chiave pubblica del server è contenuta in chiaro nel certificato del server che viene inviato in chiaro dal server, il che significa che anche la chiave pubblica viene inviata in modo implicito. Si noti che questo è il caso solo con l'autenticazione del server basata su certificato, che è il modo più comune per autenticare il server in TLS ma non l'unico. Altri modi per autenticare il server sono ad esempio le chiavi pre-condivise (PSK) in cui non sono coinvolte chiavi pubbliche.

How are the session key and public key related?

Il risultato dello scambio di chiavi è un segreto pre-master che viene poi utilizzato per derivare un master secret che viene poi utilizzato per derivare le chiavi di sessione, ovvero le chiavi per crittografare e proteggere (HMAC) i dati dell'applicazione.

Se lo scambio di chiavi Diffie-Hellman viene usato come dichiari, non esiste alcuna relazione tra la chiave pubblica e il segreto pre-master e quindi non tra la chiave pubblica e le chiavi di sessione. L'unico uso del certificato in questo caso è quello di autenticare il server e non svolge alcun ruolo nello scambio di chiavi. Lo scambio di chiavi Diffie-Hellman può anche essere utilizzato per gli handshake TLS in cui non è coinvolta alcuna chiave pubblica, ad esempio con l'autenticazione PSK.

Does the client sends session key to the server? session key sent: f(Random_gen_number, Public_key) where f is an encryption function?

Con lo scambio di chiavi Diffie-Hellman non c'è nulla di simile a questo. Con lo scambio di chiavi RSA il client crea invece il segreto pre-master completamente sul lato client (cioè non è il risultato di uno scambio di chiavi in cui entrambe le parti sono coinvolte, come nello scambio di chiavi DH) e lo invia al server crittografato con il chiave pubblica del server. Il server quindi decrittografa con la sua chiave privata (segreta) e quindi può estrarre il segreto pre-master. Il processo di derivare il segreto principale e le chiavi di sessione da questo è quindi lo stesso che con lo scambio di chiavi DH.

Questo processo di invio del segreto pre-master al server significa anche che la conoscenza della chiave privata del server consente di recuperare il segreto pre-master, derivare le chiavi di sessione e decrittografare tutto il traffico. Questo è vero anche per il traffico più vecchio se il traffico è stato catturato in un determinato momento e l'hacker o il servizio segreto ha avuto accesso alla chiave privata solo successivamente. Contrariamente a ciò, con lo scambio di chiavi DH non avviene alcuno scambio effettivo del segreto pre-master, ma è invece derivato da entrambi i lati. Avere accesso alla chiave privata del server non consentirà a un utente malintenzionato di decodificare il traffico sniffato, ovvero è necessario un attacco man-in-the-middle attivo e in tempo reale. Ecco perché lo scambio di chiavi DH è quello preferito oggi e l'unico supporto a partire da TLS 1.3.

    
risposta data 04.06.2018 - 07:18
fonte
0
  1. La chiave pubblica viene inviata in chiaro. Non può essere crittografato poiché il client e il server non sono ancora stati in grado di stabilire un segreto condiviso. Il segreto condiviso verrà generato come risultato dello scambio di chiavi. Maggiori informazioni sullo scambio di chiavi Diffie Hellman su Wikipedia

  2. Lo scambio di chiavi Diffie-Hellman si tradurrà in un segreto condiviso. Questo è usato per stabilire il segreto principale. Il master secret viene quindi utilizzato per generare chiavi di crittografia per la sessione. Ulteriori informazioni sul segreto principale e le chiavi di crittografia in RFC 5246.

(P.S. La chiave pubblica non deve essere presente nel certificato, Ephemeral Diffie-Hellman invia la chiave in un messaggio di scambio di chiavi.)

    
risposta data 04.06.2018 - 04:55
fonte

Leggi altre domande sui tag