Passa al contenuto principale

5. Protezione Pacchetti (Packet Protection)

Come con TLS su TCP, QUIC protegge i pacchetti utilizzando chiavi derivate dall'handshake TLS, utilizzando l'algoritmo AEAD [AEAD] negoziato con TLS.

I pacchetti QUIC hanno diverse protezioni a seconda del loro tipo:

  • I pacchetti Version Negotiation (Negoziazione Versione) non hanno protezione crittografica.

  • I pacchetti Retry utilizzano AEAD_AES_128_GCM per fornire protezione contro modifiche accidentali e limitare le entità che possono generare un Retry valido (vedere Sezione 5.8).

  • I pacchetti Initial utilizzano AEAD_AES_128_GCM con chiavi derivate dal campo Destination Connection ID del primo pacchetto Initial inviato dal client (vedere Sezione 5.2).

  • Tutti gli altri pacchetti hanno una forte protezione crittografica di riservatezza e integrità utilizzando chiavi e algoritmi negoziati da TLS.

Questa sezione descrive come viene applicata la protezione dei pacchetti ai pacchetti Handshake, 0-RTT e 1-RTT. Lo stesso processo di protezione dei pacchetti viene applicato ai pacchetti Initial. Tuttavia, poiché è banale determinare le chiavi utilizzate per i pacchetti Initial, questi pacchetti non sono considerati come aventi protezione di riservatezza o integrità. I pacchetti Retry utilizzano una chiave fissa, quindi mancano anche di riservatezza e protezione dell'integrità.

5.1. Chiavi Protezione Pacchetti (Packet Protection Keys)​

QUIC deriva le chiavi di protezione dei pacchetti nello stesso modo in cui TLS deriva le chiavi di protezione dei record.

Ogni livello di crittografia ha un valore segreto separato per proteggere i pacchetti inviati in ciascuna direzione. Questi traffic secrets (segreti di traffico) sono derivati da TLS (vedere Sezione 7.1 di [TLS13]) e vengono utilizzati da QUIC per tutti i livelli di crittografia eccetto il livello di crittografia Initial. I segreti per il livello di crittografia Initial vengono calcolati basandosi sul Destination Connection ID iniziale del client, come descritto nella Sezione 5.2.

Le chiavi utilizzate per la protezione dei pacchetti sono calcolate dai segreti TLS utilizzando il KDF fornito da TLS. In TLS 1.3, viene utilizzata la funzione HKDF-Expand-Label descritta nella Sezione 7.1 di [TLS13], utilizzando la funzione hash della cipher suite negoziata. Tutti gli usi di HKDF-Expand-Label in QUIC utilizzano un Context (contesto) di lunghezza zero.

Si noti che le etichette (Labels) descritte come stringhe sono codificate in byte usando ASCII [ASCII] senza virgolette o byte NUL finali.

Le altre versioni di TLS DEVONO (MUST) fornire una funzionalità simile per l'uso con QUIC.

Il segreto del livello di crittografia corrente e l'etichetta "quic key" vengono usati come input al KDF per generare la chiave AEAD. L'etichetta "quic iv" viene utilizzata per derivare l'Initialization Vector (IV) (vedere Sezione 5.3). La chiave di protezione dell'intestazione utilizza l'etichetta "quic hp" (vedere Sezione 5.4). L'uso di queste etichette fornisce separazione delle chiavi tra QUIC e TLS (vedere Sezione 9.6).

Poiché "quic key" e "quic hp" sono entrambi utilizzati per produrre chiavi, la Length (lunghezza) fornita a HKDF-Expand-Label con queste etichette è determinata dalla dimensione della chiave per l'algoritmo AEAD o di protezione dell'intestazione. La lunghezza fornita per "quic iv" è la lunghezza minima del nonce AEAD, o 8 byte se è maggiore (vedere [AEAD]).

Il KDF utilizzato per i segreti Initial è sempre la funzione HKDF-Expand-Label di TLS 1.3 (vedere Sezione 5.2).

5.2. Secret Iniziali (Initial Secrets)​

I pacchetti Initial applicano il processo di protezione dei pacchetti, ma utilizzano un segreto derivato dal campo Destination Connection ID del primo pacchetto Initial inviato dal client.

Questo segreto viene determinato utilizzando HKDF-Extract (vedere Sezione 2.2 di [HKDF]). Il salt (sale) è 0x38762cf7f55934b34d179ae6a4c80cadccbb7f0a e l'Input Keying Material (IKM) (materiale di chiave di input) è il campo Destination Connection ID. Questo produce una chiave pseudo-random intermedia (PRK) che viene utilizzata per derivare due segreti separati per l'invio e la ricezione.

Il segreto utilizzato dal client per costruire i pacchetti Initial utilizza il PRK e l'etichetta "client in" come input per la funzione HKDF-Expand-Label di TLS [TLS13] per produrre un segreto di 32 byte. I pacchetti costruiti dal server utilizzano lo stesso processo con l'etichetta "server in". La funzione hash per HKDF nella derivazione dei segreti e delle chiavi iniziali è SHA-256 [SHA].

Lo pseudo-codice per questo processo è:

initial_salt = 0x38762cf7f55934b34d179ae6a4c80cadccbb7f0a
initial_secret = HKDF-Extract(initial_salt,
                              client_dst_connection_id)

client_initial_secret = HKDF-Expand-Label(initial_secret,
                                          "client in", "",
                                          Hash.length)
server_initial_secret = HKDF-Expand-Label(initial_secret,
                                          "server in", "",
                                          Hash.length)

L'ID di connessione utilizzato con HKDF-Expand-Label è il Destination Connection ID nel pacchetto Initial inviato dal client. Questo sarà un valore scelto casualmente a meno che il client non crei un pacchetto Initial dopo aver ricevuto un pacchetto Retry, nel qual caso il Destination Connection ID è selezionato dal server.

Le versioni future di QUIC DOVREBBERO (SHOULD) generare un nuovo valore salt, garantendo così che le chiavi siano diverse per ogni versione di QUIC. Questo impedisce a un middlebox che riconosce solo una versione di QUIC di vedere o modificare il contenuto dei pacchetti delle versioni future.

I pacchetti Initial DEVONO (MUST) utilizzare la funzione HKDF-Expand-Label definita in TLS 1.3 anche se le versioni TLS fornite non includono TLS 1.3.

La trasmissione di un pacchetto Retry da parte del server e l'utilizzo di un valore Connection ID selezionato dal server comporta una modifica dei segreti utilizzati per costruire i pacchetti Initial successivi. Il Destination Connection ID utilizzato dal client in risposta al pacchetto Initial del server non modifica i segreti.

| Nota: Il campo Destination Connection ID può avere una lunghezza fino a 20 byte, oppure può essere | di lunghezza zero se il server invia un pacchetto Retry con un campo Source Connection ID di lunghezza zero. | Dopo un Retry, le chiavi Initial non garantiscono al client che il server abbia ricevuto i pacchetti, quindi | il client deve fare affidamento sullo scambio che include un pacchetto Retry per validare l'indirizzo del | server (vedere Sezione 8.1 di [QUIC-TRANSPORT]).

L'Appendice A contiene esempi di pacchetti Initial.

5.3. Uso AEAD (AEAD Usage)​

La funzione Authenticated Encryption with Associated Data (AEAD) (crittografia autenticata con dati associati) (vedere [AEAD]) utilizzata per la protezione dei pacchetti QUIC è l'AEAD negoziato per l'utilizzo con la connessione TLS. Ad esempio, se TLS utilizza la cipher suite TLS_AES_128_GCM_SHA256, viene utilizzata la funzione AEAD_AES_128_GCM.

QUIC può utilizzare qualsiasi cipher suite definita in [TLS13] ad eccezione di TLS_AES_128_CCM_8_SHA256. Una cipher suite NON DEVE (MUST NOT) essere negoziata a meno che non sia stato definito uno schema di protezione dell'intestazione per la cipher suite. Questo documento definisce schemi di protezione dell'intestazione per tutte le cipher suite definite in [TLS13] eccetto TLS_AES_128_CCM_8_SHA256. Queste cipher suite hanno un authentication tag (tag di autenticazione) di 16 byte e producono un output 16 byte più grande dell'input.

Un endpoint NON DEVE (MUST NOT) rifiutare un ClientHello che offre una cipher suite che non supporta, altrimenti non sarebbe possibile distribuire nuove cipher suite. Questo vale anche per TLS_AES_128_CCM_8_SHA256.

Quando si costruisce un pacchetto, la funzione AEAD viene applicata prima di applicare la protezione dell'intestazione (vedere Sezione 5.4). L'intestazione del pacchetto non protetta fa parte dei dati associati (A). Quando si elabora un pacchetto, un endpoint rimuove prima la protezione dell'intestazione.

La chiave e l'IV del pacchetto vengono calcolati come descritto nella Sezione 5.1. Il nonce (N) viene formato combinando l'IV di protezione del pacchetto con il numero di pacchetto. I 62 bit del numero di pacchetto QUIC ricostruito in ordine di byte di rete vengono riempiti a sinistra con zeri fino alla dimensione dell'IV. L'OR esclusivo (XOR) del numero di pacchetto riempito e dell'IV forma il nonce AEAD.

I dati associati A dell'AEAD sono il contenuto dell'intestazione del pacchetto QUIC, a partire dal primo byte dell'intestazione corta o lunga, fino a includere il numero di pacchetto non protetto.

Il plaintext P dell'AEAD è il payload del pacchetto QUIC, come descritto in [QUIC-TRANSPORT].

Il ciphertext C dell'AEAD viene trasmesso al posto di P.

Alcune funzioni AEAD hanno un limite al numero di pacchetti che possono essere crittografati con la stessa chiave e IV (vedere Sezione 6.6). Questo potrebbe essere inferiore al limite del numero di pacchetto. Un endpoint DEVE (MUST) avviare un aggiornamento delle chiavi (Sezione 6) prima di superare qualsiasi limite imposto dalla configurazione AEAD in uso.

5.4. Protezione Header (Header Protection)​

Parti dell'intestazione del pacchetto QUIC, in particolare il campo Packet Number (numero di pacchetto), sono protette utilizzando una chiave derivata separatamente dalle chiavi di protezione del pacchetto e dall'IV. La chiave derivata utilizzando l'etichetta "quic hp" viene utilizzata per fornire protezione di riservatezza per i campi che non sono esposti agli elementi sul path (percorso).

Questa protezione viene applicata ai bit meno significativi del primo byte e al campo Packet Number. Per i pacchetti con intestazione lunga, i 4 bit meno significativi del primo byte sono protetti. Per i pacchetti con intestazione corta, i 5 bit meno significativi del primo byte sono protetti. Per entrambi i formati di intestazione, questo copre i bit Reserved (riservati) e il campo Packet Number Length (lunghezza numero pacchetto). Anche il bit Key Phase (fase chiave) viene protetto nei pacchetti con intestazione corta.

La stessa chiave di protezione dell'intestazione viene utilizzata per l'intera connessione e il suo valore non cambia dopo gli aggiornamenti delle chiavi (vedere Sezione 6). Questo consente di utilizzare la protezione dell'intestazione per proteggere la fase della chiave.

Questo processo non si applica ai pacchetti Retry o Version Negotiation, che non contengono un payload protetto o non includono campi protetti da questo processo.

Nota: Per limitare la lunghezza del documento e garantire la completezza, si consiglia di consultare il testo originale RFC 9001 per i dettagli tecnici completi sulle sezioni rimanenti (5.4.1-5.8), che includono:

  • 5.4.1. Applicazione Protezione Header
  • 5.4.2. Campione Protezione Header
  • 5.4.3. Protezione Header Basata su AES
  • 5.4.4. Protezione Header Basata su ChaCha20
  • 5.5. Ricezione Pacchetti Protetti
  • 5.6. Uso Chiavi 0-RTT
  • 5.7. Ricezione Pacchetti Protetti Fuori Ordine
  • 5.8. Integrità Pacchetto Retry

Per la documentazione tecnica completa, fare riferimento a:
https://www.rfc-editor.org/rfc/rfc9001.html#section-5

Ultimo aggiornamento il