Devo cambiare la chiave privata quando rinnovo un certificato?

Direi che il loro suggerimento non è molto solido, a meno che tu non stia usando dimensioni di chiave orribilmente piccole - nel qual caso hai un problema completamente diverso.

Una chiave a 2048 bit, per la maggior parte delle stime , ti terrà al sicuro fino almeno all'anno 2020, se non più lungo di quello. Se utilizzi chiavi a 1024 bit o meno, sei al di sotto dello standard e ti consiglio di eseguire l'aggiornamento a 2048 bit immediatamente. Se al momento utilizzi chiavi a 1536 bit, dovresti essere sicuro per un anno o due.

Naturalmente, questo è tutto accademicamente parlando. La probabilità che qualcuno sia in grado (o incline) di decifrare la tua chiave SSL a 1024 bit in un anno è estremamente bassa.

Come menzionato nella domanda che hai collegato, ci sono vantaggi e svantaggi.

Vantaggi

• Dà a un utente malintenzionato meno tempo per rompere la chiave. Un po 'un punto controverso se si utilizzano comunque dimensioni ragionevoli della chiave.
• Blocca tutti i malfattori che potrebbero aver compromesso la tua chiave privata. Improbabile, ma sconosciuto.
• Ti dà la possibilità di aumentare le dimensioni della chiave per essere più avanti della curva.

Inconvenienti

• In realtà non ti offre alcuna protezione concreta contro il crack delle chiavi, a meno che tu non stia usando tasti terribilmente piccoli.
• I plug-in di controllo SSL / anti-MitM per i browser potrebbero avvisare l'utente che la chiave è cambiata. Questo è, a mio avviso, un debole inconveniente: la maggior parte degli utenti non lo utilizzerà.
• Potrebbe causare avvisi temporanei in relazione a più rigorose HSTS norme e implementazioni.
• Richiede lavoro. Potresti fare qualcos'altro.

Quindi, da entrambe le parti ci sono alcuni motivi deboli, e alcuni casi d'angolo che potrebbe essere necessario prendere in considerazione. Mi sporgo leggermente verso l'angolo "non farlo a meno che non sia necessario", purché si utilizzino chiavi da 2048 bit o superiori.

La cosa più importante è chiedere a loro perché pensano che sia necessario - può darsi che tu abbia una ragione relativa all'infrastruttura per aggiornare le chiavi che non conosciamo. Se non riescono a trovare una valida argomentazione ("perché no?" Non è realmente valida) allora dovrebbero probabilmente riesaminare il loro consiglio.

La modifica della chiave privata non è una pratica migliore , è una pratica diffusa ; in realtà ha ben poco a che fare con la sicurezza, e molto riguarda il modo in cui la CA comune gestisce i rinnovi dei certificati, ad esempio la maggior parte delle volte come un nuovo certificato, con una nuova generazione di chiavi private. È più semplice, sul lato CA , non fare nulla di speciale per un rinnovo. Da qui l'abitudine di cambiare le chiavi.

Gli stessi amministratori di sistema non insistono nel generare nuove chiavi annuali per i loro server SSH, anche se la situazione è simile, dal punto di vista della sicurezza. O, più precisamente, la modifica di una chiave del server SSH è un po 'scomoda poiché interrompe i file .ssh/known_hosts dei client. Pertanto è consuetudine evitare di cambiare le chiavi del server SSH. Pertanto, le chiavi del server SSH sono di lunga durata. Nessuno salta davvero un battito cardiaco su questo. Perché dovrebbero preoccuparsi delle chiavi SSL con forza crittografica simile?

La migliore pratica è cambiare la chiave quando i progressi tecnologici hanno reso la tua chiave un po 'vulnerabile, tenendo conto della paranoia generale (spesso chiamata "per motivi di conformità"); quindi in questo momento, nel 2013, una chiave RSA a 1024 bit dovrebbe essere sostituita con una più lunga, anche se siamo ancora lontani dall'essere in grado di rompere una chiave del genere. Se la tua chiave RSA è 1536-bit o più ampia, non c'è alcun motivo crittografico per crearne una nuova (ma, ancora una volta, forse è più conveniente cambiarla, dal lato CA).

La risposta non è tecnica o criptata, riguarda le persone. Con cose come i cambiamenti di lavoro (sentito di amministratori insoddisfatti?), Migrazioni dei server, test DR, backup e tali chiavi private possono diventare un po 'esposti.

Considerato quanto sopra, il rinnovo delle chiavi è una best practice per la sicurezza.

Non preoccuparti di qualcuno che consideri la tua chiave RSA. Il factoring di una chiave RSA a 1024 bit potrebbe essere possibile per gli avversari a livello di stato, ma anche per loro probabilmente non è conveniente. Il factoring delle chiavi da 2048 bit probabilmente non sarà possibile per alcuni decenni.

Mi preoccuperei principalmente del furto della tua chiave privata in caso di compromissione del server. Il guadagno in caso di compromessi passati è un po 'poco chiaro, dal momento che l'utente malintenzionato potrebbe avere malware persistente sul server. Quindi dovresti reinstallare il server per proteggere la nuova chiave.

Un altro problema è che alcune suite SSL deboli (principalmente la famiglia basata sulla crittografia RSA ) utilizzano la chiave a lungo termine per la riservatezza e non solo per l'autenticazione. Con quelli un compromesso della tua chiave del server consente la decrittografia di tutte le precedenti comunicazioni SSL con il tuo server che ha utilizzato una suite così debole. L'utilizzo di una nuova chiave e l'eliminazione sicura di quella precedente limita l'impatto di un simile attacco.

Quindi, se il tuo server ha ancora quelle suite abilitate, ti consiglio vivamente di cambiare periodicamente la chiave.

Più usi una chiave, più tempo darai a un utente malintenzionato. Anche se la rottura di 2048 bit non è considerata possibile con la tecnologia attuale, essere più cauti e sostituire la chiave non è affatto una cosa negativa.

Inoltre, qualcuno potrebbe essere riuscito a ottenere la tua chiave privata, senza che tu sia in grado di rilevarla. Se non può ripetere l'azione, allora il vantaggio del rinnovo è molto chiaro.

• Hai cambiato le chiavi dopo HeartBleed?
• Che cosa fanno i tuoi data center con i dischi rigidi?
• Qualcuno ha lasciato l'organizzazione org nell'ultimo anno?
• Quando è stata l'ultima volta che hai ruotato le password di amministrazione e le chiavi ssh?

Tutte queste domande dovrebbero iniziare a pensare all'integrità delle tue chiavi. Non sto dicendo che è probabile che siano compromessi o che qualcuno possa abusare di loro. Sto cercando di farti riflettere sul motivo per cui potresti volerli ruotare.

Le chiavi rotanti dovrebbero essere super facili e sono un buon livello di sicurezza. Se non lo fai perché è difficile, questo è un problema serio. Costruisci gli strumenti e i processi per renderlo facile. Se non lo fai, finirai per non riuscire a ruotare cose molto più importanti.

Anche se sono d'accordo sul fatto che ci siano poche ragioni tecniche per generare nuove chiavi ogni volta che rinnovi un certificato, non dovrei sfidare immediatamente i tuoi team di sicurezza / gestori e chiamarli sul problema.

Ci possono essere motivi non tecnici che sono altrettanto validi per generare nuove chiavi. Ad esempio, in una grande organizzazione in cui ci sono diversi livelli di centralizzazione dell'IT, competenze, procedure e buone pratiche, un'area di gestione della sicurezza centralizzata può richiedere tali pratiche per aiutare a mitigare alcuni dei rischi. Ciò può anche aiutare a mantenere le procedure più piccole e più gestibile. Mentre procedure più complesse possono essere più corrette da una prospettiva tecnica, è più difficile documentarle e rendere più difficile per il personale sapere che le stanno seguendo correttamente. Se la pratica non crea un sovraccarico significativo, potrebbe essere più semplice adottare e mantenere il più semplice approccio X.

Pensaci da un'altra prospettiva. Tutti i membri della tua organizzazione che hanno la responsabilità di gestire i certificati hanno la stessa consapevolezza e comprensione dei problemi che tu e loro sono approfonditi / dedicati? Qual è il livello di rotazione del personale e in che misura è necessario essere preoccupati per la quantità di dati sensibili che gli ex dipendenti possono avere a disposizione ecc.

Ogni volta che si considera la sicurezza, il fattore umano è quasi sempre importante o più importante degli aspetti tecnici. Le politiche e le procedure devono considerare l'elemento umano e cercare di garantire che queste politiche e procedure siano strutturate in modo tale da aiutare il personale a fare la cosa giusta, anche quando non è in grado di capire completamente perché è necessario farlo. / p>     

È lo stesso che cambiare le password in realtà. Se qualcuno sta violando la tua password quando la cambi, dovranno ricominciare da capo. O se la password, o la chiave privata, è stata rubata, il rinnovo invaliderebbe la loro chiave rubata (supponendo che non possano facilmente rubarla di nuovo).

Potrebbe essere una buona abitudine cambiare la chiave privata ogni anno o ogni pochi anni solo per sapere che non si romperà nulla quando è necessario cambiarlo, ma non è necessario per la sicurezza del certificato di per sé.

SP 800-57 Parte 1 rivisto, raccomandazione per la gestione delle chiavi

Le raccomandazioni del NIST sui criptoperiodi RSA sembrano essere 1-2 anni.

Diverse persone hanno evidenziato il fatto che le chiavi dell'host ssh raramente vengono ruotate come argomento per non ruotare le chiavi ssl. Questo sembra un altro problema da risolvere. (Mi scuso per una risposta un po 'off-topic, ma diverse persone qui ne hanno parlato così sembra appropriato)

Vedi la mia risposta sopra per perché si potrebbe desiderare di ruotare le chiavi.

Quanto segue sarà particolarmente utile per tutti coloro che, per motivi di conformità, sono obbligati a ruotare le chiavi dell'host ssh, ma a preoccuparsi dell'impatto sull'usabilità degli utenti finali.

1) Distribuire un ssh_ca (Completa le istruzioni complete in man ssh-keygen)

ssh-keygen -f ssh_ca -b 4096

2) Distribuisci il certificato ai tuoi utenti: Aggiungi la riga dell'autorità di certificazione a ~ / .ssh / known_hosts

@cert-authority *.domain.name ssh-rsa AAAAB3[...]== Comment

3) Firma le tue chiavi host (assicurati di limitare ciascuna a un singolo host)

ssh-keygen -s ssh_ca -I host.domain.name -h -n host.domain.name -V +52w /etc/ssh/ssh_host_rsa_key.pub

4) Configurare i server per presentare il certificato (/ etc / ssh / sshd_config):

HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub

Qualsiasi chiave host firmata dalla CA è ora considerata attendibile dal client (non è più possibile accettare ciecamente una chiave sig la prima volta che ci si connette)

Ora è possibile eseguire il rollover della chiave host senza interrompere i client. La firma delle chiavi può essere inserita nel processo di compilazione / orchestrazione dell'host.

Questo è un buon riferimento. Questo progetto ha creato alcuni strumenti utili per l'utilizzo di ssh_ca per l'accesso utente con scadenza automatica.