Se una connessione crittografata può essere compromessa quando la chiave privata di un server è stollen, perché i server non generano semplicemente una nuova chiave privata per ogni sessione unica. Sembra che eliminerebbe un punto di vulnerabilità se fosse appena generato come necessario.
Suppongo che abbia qualcosa a che fare con la verifica delle catene di autorità, o delle prestazioni, o qualcosa del genere, ma mi stavo chiedendo se qualcuno sa per certo perché non è fatto in quel modo?
Quando ti connetti a un server ci sono due tipi di crittografia in gioco.
Innanzitutto, esiste una coppia di chiavi pubblica-privata associata alla crittografia asimmetrica che viene utilizzata per convalidare la tua identità. In genere (nel caso di visitare siti Web HTTPS), si crea una coppia di chiavi di lunga durata (una pubblica e una privata), si invia la parte della chiave pubblica e si identificano le informazioni su un'autorità di certificazione (CA) attendibile, prova la propria identità al certificato la soddisfazione dell'autorità (ad esempio, verifica che controlli il dominio per cui è stato rilasciato il certificato) e l'autorità di certificazione firmi il certificato per te. Ora pubblichi il tuo certificato firmato da CA pubblicamente sul tuo sito web. Chiunque si connetta al sito Web per la prima volta, il cui browser / sistema operativo si fida già della CA che ha firmato il certificato, può verificare l'identità del sito Web a cui ci si connette emettendo delle contestazioni al certificato firmato da una CA che è possibile rispondere solo se controlla la chiave privata del sito web. Nota che il certificato viene utilizzato solo per l'autenticazione dell'identità (facendo affidamento sulla catena di fiducia con l'autorità di certificazione) all'inizio di una conversazione.
Per trasmettere effettivamente i dati, non si utilizza la crittografia asimmetrica poiché la crittografia asimmetrica è lenta e crittografa solo i messaggi brevi. La crittografia simmetrica è molto più veloce e funziona bene per crittografare rapidamente messaggi di grandi dimensioni arbitrariamente. Per la parte di crittografia simmetrica, si utilizzano i protocolli di scambio di chiavi come DHE per consentire a entrambi i server di negoziare una chiave simmetrica condivisa che verrà utilizzata per crittografare e decrittografare i messaggi e il protocollo di scambio delle chiavi può negoziare una chiave simmetrica casuale senza effettivamente inviare la chiave simmetrica condivisa attraverso la rete.
Per un esempio di un protocollo di scambio di chiavi che non invia la chiave completa in rete per Alice per inviare un messaggio a Bob, prima entrambi concordano su un generatore di due numeri ( g ) e modulo ( N e ognuno sceglie un numero casuale segreto a e b (Alice genera a e Bob genera b ; nota Alice non impara mai b e Bob non impara mai a ). Quindi Bob invia un messaggio ad Alice contenente Kb = g^b mod N . Alice calcola la chiave segreta condivisa K = g^(ab) mod N calcolando K = Kb^a mod N . Alice usa la chiave segreta K per crittografare simmetricamente il suo messaggio e inviarlo a Bob insieme a Ka = g^a mod N che Bob dovrà decifrare. Se una rete che intercetta Eve ascolta i propri messaggi, vedono g , N , g^a mod N , g^b mod N e il messaggio crittografato, ma non hanno un metodo noto e percorribile per calcolare K senza conoscere ulteriormente a o b . Questo scambio di chiavi tuttavia è ancora vulnerabile alla manomissione attiva, in cui Alice potrebbe provare a inviare un messaggio a Bob, ma invece Eva finge di essere Bob. Questo è il motivo per cui oltre a inoltrare la segretezza all'inizio della conversazione è necessario che Alice e Bob si identifichino a vicenda (operazione che viene eseguita abitualmente utilizzando i certificati longevi firmati dalle CA).
La segretezza avanzata ti suggerisce di non riutilizzare le chiavi simmetriche casuali, ma di rinegoziarle con ogni messaggio scambiato.
Leggi altre domande sui tag key-management tls