Quali garanzie garantisce la perfetta segretezza in avanti rispetto al compromesso di una chiave privata?

1

Con perfetta segretezza di inoltro, se un utente malintenzionato accede a una chiave privata del certificato, la mia comprensione è che tutto il traffico precedentemente crittografato utilizzando quella chiave privata rimane al sicuro dalla decrittografia.

Ma la perfetta segretezza in avanti fornisce garanzie riguardo al traffico futuro crittografato utilizzando la chiave privata compromessa? Il grado di vulnerabilità cambia con la rigenerazione periodica dei parametri Diffie-Hellman?

Naturalmente, la compromissione di una chiave privata del certificato esaspera una serie di attacchi MITM e deve essere sostituita il prima possibile, ma nei casi in cui il compromesso potrebbe non essere scoperto per qualche tempo, quale livello di segretezza viene fornito durante l'intervallo tra il compromesso e la sostituzione della chiave privata?

    
posta Daniel Kauffman 24.09.2015 - 22:41
fonte

1 risposta

5

Se le informazioni sono state crittografate direttamente sulla chiave compromessa, non è inoltrata.

La segretezza di inoltro generalmente funziona avendo le chiavi a lungo termine (quelle che hanno maggiori possibilità di essere compromesse) usate solo per l'autenticazione. Questi sono usati durante un protocollo di accordo chiave che genera un insieme di chiavi effimere che vengono effettivamente utilizzate per crittografare e decrittografare i dati. Queste chiavi effimere vengono quindi scartate dopo l'uso e ne vengono generate di nuove quando necessario.

In TLS, le suite di crittografia che forniscono la segretezza avanzata sono quelle con DHE o ECDHE nel nome. Ad esempio, TLS_RSA_WITH_AES_128_GCM_SHA256 non è inoltrato, mentre TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 è inoltrato. La differenza consiste nel modo in cui la chiave RSA del certificato viene utilizzata nella parte di scambio delle chiavi dell'handshake.

Nel non-forward secret TLS_RSA_WITH_AES_128_GCM_SHA256, il materiale di codifica è crittografato sulla chiave RSA. Se la chiave RSA viene successivamente compromessa, il materiale di codifica può essere decodificato e il traffico TLS viene esposto.

Nel forward secret TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, la chiave RSA viene utilizzata per autenticare lo scambio di chiavi Diffie-Hellman, da cui deriva il materiale di codifica. Anche se la chiave RSA viene rubata, il materiale di codifica per quella sessione è sicuro, perché la chiave privata RSA non è stata utilizzata per la crittografia del materiale di codifica.

Da questo, dovrebbe essere facile vedere che se una chiave RSA viene compromessa ma non rilevata, può ancora essere utilizzata per interrompere alcune sessioni future con la segretezza attivata abilitata. Un client si connetterebbe al MITM, si fida di esso perché ha la chiave giusta, e la chiave di sessione sarà effettivamente negoziata con il MITM, facendo trapelare presumibilmente informazioni private. Se il client si connette al server reale con la segretezza avanzata attivata, l'utente malintenzionato non ottiene nulla, perché non può ancora utilizzare la chiave RSA rubata per interrompere lo scambio di chiavi Diffie-Hellman. Se la riservatezza diretta è disattivata, le connessioni a un server con una chiave compromessa possono ancora essere snoopate dall'attaccante con accesso alla chiave RSA privata nello stesso modo in cui potrebbero decodificare le sessioni precedenti.

    
risposta data 24.09.2015 - 23:21
fonte

Leggi altre domande sui tag