Cifratura simmetrica vs. a chiave pubblica in una VPN: cosa fa ciascuna

Le persone descrivono una VPN come „una che usa la cifratura a chiave pubblica“ e poi immaginano ogni pacchetto chiuso dal certificato del server. Questa immagine è sbagliata in un modo che conta quando si legge un file di configurazione o una cattura di pacchetti. La metà a chiave pubblica di una VPN serve a dimostrare chi è il peer e a concordare materiale segreto; la metà simmetrica è quella che protegge davvero il traffico, pacchetto dopo pacchetto, per tutta la durata della sessione.

Le due metà hanno durate, modi di guasto e cose pubblicabili in sicurezza diversi. Una volta separate, domande come „RSA 2048 è più debole di AES-128“ smettono di confondere, perché non sono mai state confrontabili.

Tre operazioni che vengono confuse

La crittografia a chiave pubblica è un ombrello su almeno tre operazioni distinte. Una firma dimostra che il titolare di una chiave privata ha approvato un determinato messaggio. L'accordo di chiavi consente a due peer di derivare un segreto condiviso da valori scambiati in pubblico. La cifratura a chiave pubblica nasconde i dati sotto la chiave pubblica di qualcuno, così che solo la chiave privata possa aprirli.

Le strette di mano VPN usano soprattutto le prime due. Un certificato non è una chiave di cifratura; è un'affermazione firmata che lega un nome a una chiave pubblica e consente all'altra parte di decidere se fidarsi della chiave appena ricevuta. Lo stabilimento delle chiavi di TLS 1.3, per esempio, si basa sull'accordo di chiavi (EC)DHE più le firme dei certificati, non sulla cifratura della sessione con la chiave pubblica del server.

Che cosa produce davvero la stretta di mano

In una stretta di mano moderna, ogni parte genera una coppia di chiavi effimera, scambia le metà pubbliche e calcola un segreto condiviso che non attraversa mai il cavo. Quel segreto passa poi per una funzione di derivazione delle chiavi per produrre chiavi separate per ciascuna direzione, oltre ai nonce e al materiale IV che serve al livello record. WireGuard lo fa con la sua costruzione basata su Noise; TLS 1.3 lo fa con HKDF sul transcript della stretta di mano.

La credenziale a lungo termine — certificato e chiave privata, o una chiave WireGuard statica — autentica quello scambio. Firma o si mescola nel transcript, così un estraneo non può completare la stretta di mano al posto del peer. Dopo di che, la credenziale non svolge lavoro per pacchetto. Se lo facesse, ogni pacchetto richiederebbe un'operazione con chiave privata, e un tunnel occupato sarebbe limitato dall'operazione più lenta dello stack.

Ne seguono due effetti collaterali. Primo, le chiavi di sessione sono nuove ogni volta, per questo un attaccante che in seguito ruba la chiave a lungo termine non può decifrare sessioni registrate prima, purché l'accordo fosse effimero. Secondo, una chiave di sessione divulgata compromette una sessione, non l'identità.

Perché i grandi volumi di dati usano chiavi simmetriche

I cifrari simmetrici gestiscono bene il volume: AES-GCM o ChaCha20-Poly1305 elaborano ogni pacchetto con una chiave già in memoria, autenticano l'intestazione e incrementano un contatore. Il lato ricevente controlla il nonce e il tag di autenticazione e scarta tutto ciò che fallisce o si ripete. È abbastanza economico da girare a velocità di linea su hardware comune, e la stessa costruzione dà riservatezza e integrità in una sola passata.

La costruzione è anche il luogo in cui vivono la maggior parte dei bug di implementazione. Un nonce ripetuto in GCM rompe riservatezza e autenticità insieme, per questo i protocolli derivano chiavi per direzione e mantengono un contatore o un'epoca espliciti. Se si legge una cattura di pacchetti e la lunghezza del testo cifrato corrisponde al testo in chiaro più un sovraccarico fisso, è lo strato simmetrico che lavora, non un'operazione a chiave pubblica per pacchetto.

Durate, rinnovo delle chiavi e segretezza in avanti

Le chiavi di sessione devono scadere. TLS 1.3 consente a un messaggio KeyUpdate di far ruotare le chiavi del traffico; WireGuard rinnova una sessione dopo un tempo o un numero di messaggi configurato e tiene brevemente la vecchia per i pacchetti in volo. OpenVPN rinegozia le chiavi del suo canale dati secondo una pianificazione, con reneg-sec che controlla l'intervallo.

Nessuna di queste rotazioni è uguale a rinnovare un certificato. Un certificato può essere valido un anno mentre le chiavi di sessione cambiano ogni pochi minuti, e un certificato può essere sostituito senza toccare le chiavi del tunnel in funzione. Quando pianificate una scadenza, chiedete quale oggetto state ruotando; la risposta decide se i client si riconnettono o semplicemente rinnovano le chiavi.

Leggere configurazioni e diagnostica senza mescolare oggetti

In pratica si sceglie un protocollo completo e le sue primitive supportate, non se ne assembla uno proprio. La chiave --tls-crypt di OpenVPN protegge il canale di controllo; il canale dati usa cifrari simmetrici negoziati. Le voci PrivateKey e PublicKey di WireGuard sono materiale di identità, mentre le sue chiavi di trasporto sono derivate internamente. Leggere quei campi come lo stesso tipo di segreto porta a errori come incollare una chiave pubblica dove ne va una privata.

Tenete il materiale pubblico separato da quello privato. Un certificato, una chiave pubblica WireGuard e un'impronta sono sicuri da condividere in un ticket. Una chiave privata, una chiave precondivisa e una chiave di sessione esportata non lo sono. Quando confrontate le forze, confrontate all'interno di un tipo: un identificatore di curva ellittica, una dimensione del modulo RSA e una dimensione della chiave AES misurano cose diverse sotto ipotesi diverse. La specifica TLS 1.3 è un riferimento utile su come si incastrano i due livelli, anche quando il tunnel non è TLS.