Passa al contenuto principale

2. Algoritmi di scambio chiavi

Questo documento definisce tre nuovi algoritmi di scambio chiavi basati su ECC per TLS. Tutti utilizzano Ephemeral ECDH (ECDHE) per calcolare il segreto pre-master TLS, e differiscono solo nel meccanismo (se presente) utilizzato per autenticarli. La derivazione del segreto master TLS dal segreto pre-master e la successiva generazione di chiavi di cifratura/MAC bulk e vettori di inizializzazione è indipendente dall'algoritmo di scambio chiavi e non è influenzata dall'introduzione di ECC.

La Tabella 1 riassume i nuovi algoritmi di scambio chiavi. Tutti questi algoritmi di scambio chiavi forniscono forward secrecy se e solo se vengono generate e utilizzate nuove chiavi effimere, e anche distrutte dopo l'uso.

AlgoritmoDescrizione
ECDHE_ECDSAECDH effimero con firme ECDSA o EdDSA.
ECDHE_RSAECDH effimero con firme RSA.
ECDH_anonECDH effimero anonimo, nessuna firma.

Tabella 1: Algoritmi di scambio chiavi ECC

Questi scambi di chiavi sono analoghi rispettivamente a DHE_DSS, DHE_RSA e DH_anon.

Con ECDHE_RSA, un server può riutilizzare il suo certificato RSA esistente e conformarsi facilmente alle preferenze della curva ellittica di un client vincolato (vedere Sezione 4). Tuttavia, il costo computazionale sostenuto da un server è più elevato per ECDHE_RSA rispetto allo scambio chiavi RSA tradizionale, che non fornisce forward secrecy.

L'algoritmo di scambio chiavi anonimo non fornisce autenticazione del server o del client. Come altri scambi di chiavi TLS anonimi, è soggetto ad attacchi man-in-the-middle. Le applicazioni che utilizzano TLS con questo algoritmo DOVREBBERO (SHOULD) fornire autenticazione con altri mezzi.

          Client                                        Server
          ------                                        ------
          ClientHello          -------->
                                                   ServerHello
                                                  Certificate*
                                            ServerKeyExchange*
                                          CertificateRequest*+
                               <--------       ServerHelloDone
          Certificate*+
          ClientKeyExchange
          CertificateVerify*+
          [ChangeCipherSpec]
          Finished             -------->
                                            [ChangeCipherSpec]
                               <--------              Finished
          Dati Applicativi     <------->      Dati Applicativi

               * messaggio non inviato in determinate condizioni
               + messaggio non inviato a meno che non sia desiderata
                 l'autenticazione del client

Figura 1: Flusso di messaggi in un handshake TLS 1.2 completo

La Figura 1 mostra tutti i messaggi coinvolti nel protocollo di stabilimento della chiave TLS (alias handshake completo). L'aggiunta di ECC ha un impatto diretto solo su ClientHello, ServerHello, messaggio Certificate del server, ServerKeyExchange, ClientKeyExchange, CertificateRequest, messaggio Certificate del client e CertificateVerify. Successivamente, descriviamo gli algoritmi di scambio chiavi ECC in maggiore dettaglio in termini di contenuto ed elaborazione di questi messaggi. Per facilitare l'esposizione, rimandiamo la discussione sull'autenticazione del client e sui messaggi associati (identificati da un '+' nella Figura 1) alla Sezione 3 e sulle estensioni opzionali specifiche per ECC (che hanno un impatto sui messaggi Hello) alla Sezione 4.

2.1. ECDHE_ECDSA​

In ECDHE_ECDSA, il certificato del server DEVE (MUST) contenere una chiave pubblica in grado di eseguire ECDSA o EdDSA.

Il server invia la sua chiave pubblica ECDH effimera e una specifica della curva corrispondente nel messaggio ServerKeyExchange. Questi parametri DEVONO (MUST) essere firmati con ECDSA o EdDSA utilizzando la chiave privata corrispondente alla chiave pubblica nel certificato del server.

Il client genera una coppia di chiavi ECDH sulla stessa curva della chiave ECDH effimera del server e invia la sua chiave pubblica nel messaggio ClientKeyExchange.

Sia il client che il server eseguono un'operazione ECDH (vedere Sezione 5.10) e utilizzano il segreto condiviso risultante come segreto pre-master.

2.2. ECDHE_RSA​

Questo algoritmo di scambio chiavi è lo stesso di ECDHE_ECDSA, tranne che il certificato del server DEVE (MUST) contenere una chiave pubblica RSA autorizzata per la firma e la firma nel messaggio ServerKeyExchange deve essere calcolata con la chiave privata RSA corrispondente.

2.3. ECDH_anon​

NOTA: Sebbene il nome inizi con "ECDH_" (senza E), la chiave utilizzata in ECDH_anon è effimera proprio come le chiavi in ECDHE_RSA e ECDHE_ECDSA. La denominazione segue l'esempio di DH_anon, dove anche la chiave è effimera ma il nome non lo riflette.

In ECDH_anon, i messaggi Certificate del server, CertificateRequest, Certificate del client e CertificateVerify NON DEVONO (MUST NOT) essere inviati.

Il server DEVE (MUST) inviare una chiave pubblica ECDH effimera e una specifica della curva corrispondente nel messaggio ServerKeyExchange. Questi parametri NON DEVONO (MUST NOT) essere firmati.

Il client genera una coppia di chiavi ECDH sulla stessa curva della chiave ECDH effimera del server e invia la sua chiave pubblica nel messaggio ClientKeyExchange.

Sia il client che il server eseguono un'operazione ECDH e utilizzano il segreto condiviso risultante come segreto pre-master. Tutti i calcoli ECDH vengono eseguiti come specificato nella Sezione 5.10.

2.4. Algoritmi nelle catene di certificati​

Questa specifica non impone restrizioni sugli schemi di firma utilizzati in qualsiasi punto della catena di certificati. La versione precedente di questo documento richiedeva che le firme corrispondessero, ma questa restrizione, derivante dalle versioni TLS precedenti, viene qui eliminata proprio come nell'RFC 5246.

Ultimo aggiornamento il