I parametri Diffie-Hellman devono essere ricreati regolarmente?

In generale, no, non è necessario ricreare i parametri regolarmente.

Diffie-Hellam si rompe risolvendo il problema discreto logaritmo (tecnicamente, non ci sono prove che uno deve risolvere DL per interrompere DH, ma questo è ancora il metodo più conosciuto). Succede che se sei in grado di rompere un'istanza di DL, quindi puoi riutilizzare gran parte del lavoro per rompere altre istanze di DL, a patto che tutti usino lo stesso modulo (cioè lo stesso "DH parametri "). Nel caso del recente " attacco Logjam "questo è stato messo in uso: dal momento che alcuni client e server accettano di utilizzare un modulo debole (di 512 bit) e, inoltre, sembrano tutti usare il modulo stesso , gli attaccanti, dopo aver rotto Una volta DL (attraverso uno sforzo significativo), ora può fare lo stesso di nuovo per quel modulo specifico in quasi-tempo reale, che quindi rende MitM pratico.

L'iniziale "se" è grande, però. Normalmente, si useranno parametri DH sufficientemente grandi da impedire completamente lo sforzo iniziale di rottura del DL. Non vuoi che gli aggressori espandano un successo iniziale in un facile MitM, ma non vuoi che raggiungano il successo iniziale. L'utilizzo di un modulo a 2048 bit ti mette già abbastanza lontano nella zona "non può romperlo". Vedi questo sito per i dettagli. Inoltre, anche in uno scenario fantascientifico in cui la tua DH si rompe, saranno comunque i tuoi parametri, e lo sforzo di attacco non sarà applicabile ad altri server - il che significa che gli sforzi di rottura sul I parametri DH di altre persone non avranno alcun impatto su tu . Utilizzando i parametri generati, ottieni già la maggior parte della protezione. Infatti, anche con un modulo a 512 bit, l'utilizzo dei propri parametri anziché quelli "standard" offrirebbe già una notevole protezione, poiché mentre la rottura iniziale di un modulo a 512 bit è fattibile, rimane comunque una sostanziale sforzo che gli autori di attacchi non sono in grado di realizzare se sblocca solo l'accesso a un singolo server (il tuo).

Un altro modo per visualizzare questa domanda è considerare la chiave del server. In SSL / TLS con DHE, il client e il server eseguono uno scambio di chiavi Diffie-Hellman, ma il server firma anche ciò che invia (di solito con RSA). La chiave del server deve anche non essere rotta dagli autori di attacchi, poiché altrimenti l'autore dell'attacco potrebbe impersonare il server e, di nuovo, eseguire facilmente gli attacchi MitM. Pertanto, indipendentemente da ciò che fai con i parametri DH, devi comunque occuparti della tua chiave del server; in altre parole, non è utile rendere la parte DH più strong della parte della firma (RSA). Ciò si estende alla nozione di rinnovo delle chiavi: se ritieni di dover rinnovare la chiave RSA ogni tre anni (questo è un esempio), allora potrebbe voler rinnovare i parametri DH nello stesso orario. È inutile rinnovarlo più spesso. Allo stesso modo, poiché le chiavi DH e RSA sembrano offrire una resistenza simile per la stessa lunghezza, si vorrà utilizzare un modulo DH a 2048 bit se si utilizza anche una chiave RSA a 2048 bit.

Tecnicamente, il rinnovo delle chiavi è inutile, ma le persone tendono a credere che i rinnovi chiave garantiscano benefici di sicurezza supremi in qualche modo specificatamente definito, e ne sono piuttosto affezionati. Se ritieni che sia necessario rinnovare regolarmente la chiave RSA, in modo che tu possa dormire meglio la notte, allora fallo. Gli stessi motivi psicologici si applicano ai parametri DH, quindi se il rinnovo è la tua cosa, allora rinnova i parametri lo stesso giorno.

(Se vogliamo entrare in dettagli complicati, possiamo affermare che la chiave RSA del server è per un modello di sicurezza diverso dai parametri DH, poiché le firme servono per l'autenticazione immediata del server, mentre il DH deve resistere alla registrazione e ad ulteriori interruzioni, forse anni dopo, a seconda del tipo e del valore dei dati protetti. Tuttavia, una conversazione registrata passata è, per definizione, priva di rinnovamenti successivi, quindi questo argomento non si applica in definitiva alla domanda presente.)