Come viene scambiata la chiave simmetrica nell'handshake SSL / TLS?

Question

Come viene scambiata la chiave simmetrica nell'handshake SSL / TLS?

#1 da (4 voti)

5

Ho letto molto sull'handshake SSL / TLS tra un client e un server e molti articoli su di esso sono molto contraddittori.

Alcuni dicono che la chiave simmetrica che verrà utilizzata per comunicare tra le due parti viene trasmessa dal client al server (ofc, crittografata con la chiave pubblica del server) e il gioco è fatto.

Alcuni dicono che viene usato un algo DH e prima il client invia un segreto pre-master per aiutare a generare la chiave condivisa (perché è il criptato pre-master criptato in primo luogo, un attaccante non otterrà alcun segreto info).

La confusione è il flusso generale della generazione sulla chiave simmetrica condivisa. a) Il DH viene utilizzato (e in caso contrario, come viene generata la chiave simmetrica, il client la suggerisce, la invia tramite crittografia RSA e basta?)

E b) Se viene utilizzato il DH, chi inizia per primo? Ci deve essere qualcuno che per prima cosa suggerisce i numeri primi generali da utilizzare per generare il segreto, e quindi invia il loro calcolo (o è l'intero algo determinato in anticipo)?

http public-key-infrastructure tls certificates

posta daremkd 25.07.2016 - 12:20

fonte

1 risposta

Leggi altre domande sui tag http public-key-infrastructure tls certificates

A cosa si riferisce CRTM? Qual è la differenza tra elemento sicuro e smart card?

score 4 · Answer 1

Come già notato, ci sono due modi per scambiare le chiavi di sessione simmetriche: attraverso key encipherment o attraverso key agreement (che è basato sull'algoritmo Diffie-Hellman). Entrambi gli algoritmi non vengono utilizzati contemporaneamente. Ad esempio, il client Microsoft SChannel legge i bit dall'estensione KeyUsages del certificato del server (che è una stringa di bit) e, a seconda del bit impostato, viene utilizzato l'algoritmo di scambio delle chiavi.

Quando si utilizza la cifratura della chiave:

client e server scambiati suite di crittografia supportate e concordare un codice comune (supportato da entrambe le parti).
utilizza algoritmi e parametri selezionati per generare una chiave simmetrica e lo crittografa con la chiave pubblica del server (crittografia asimmetrica, RSA o ECC, ad esempio).
utilizza la sua chiave privata per decrittografare la chiave e questa chiave viene utilizzata per proteggere la sessione. Nessun DH è coinvolto qui.

Nel caso di Diffie-Hellman (accordo chiave), non c'è molta differenza su chi inizia, perché le parti condividono il numero primo comune p e il generatore numero g ed entrambe le parti DEVE concordare su questi valori. Questi numeri possono essere concordati in pubblico. Quindi, l'iniziatore dell'accordo è solo la sintassi del messaggio di un protocollo.

Successivamente si verifica il seguente processo (che è ben definito):

I client inviano la propria chiave pubblica DH al server.
Il server calcola la chiave della sessione segreta utilizzando le informazioni contenute nella sua chiave privata e nella chiave pubblica del client.
Il server invia la sua chiave pubblica DH al client.
Il client calcola la chiave segreta della sessione utilizzando le informazioni contenute nella sua chiave privata e nella chiave pubblica del server.
Ora entrambe le parti hanno la stessa chiave di sessione, che può essere utilizzata per crittografare e decodificare i dati. I passaggi necessari per questo sono mostrati nella seguente procedura.

L'algoritmo di scambio di chiavi DH dettagliato è descritto in RFC2631 .