Come viene garantita la sicurezza della chiave privata RSA del server?

Per una sicurezza ottimale, la chiave privata deve essere conservata in un HSM (o Smart Card che implementa un HSM minimo). È difficile estrarre la chiave privata da quella, soprattutto da remoto, tranne che per un bug o una backdoor nella configurazione o nell'implementazione dell'HSM. Questo perché tutti gli algoritmi di buona firma (o crittografia) hanno la proprietà che non importa quante firme (o decrittografie) si ottengano, è impossibile dedurre la chiave privata o un equivalente funzionale completo di quello.

L'HSM è anche prezioso perché è valutato per la sicurezza, anche contro gli attacchi dei canali laterali come il tempismo, intrinsecamente invulnerabili agli altri (come perdite da una VM a un'altra a causa di bug del supervisore o stati della cache della CPU fisica). In genere un HSM viene fornito con mezzi per imporre ruoli di amministratore / operatore; inserire l'HSM (tipicamente, di default) in modalità sicura (non operativa); azzerare dati sensibili su alcuni attacchi; eseguire backup crittografati di chiavi; a volte, le operazioni di registro. Inoltre, alcuni HSM forniscono un notevole incremento delle prestazioni rispetto alle soluzioni solo software.

Tuttavia, un utente malintenzionato che ottiene l'accesso come root a un host con HSM mentre è operativo, può potenzialmente creare firme o decrittografie (l'HSM rende solo necessario che l'hacker abbia poche competenze specializzate in HSM). Pertanto, un'intrusione persistente non rilevata su una macchina che utilizza un HSM è quasi altrettanto buona per un utente malintenzionato quanto ottenere la chiave privata; e nella maggior parte dei casi di firma, la revoca della chiave privata è necessaria se un utente malintenzionato ha anche accesso temporaneo ad esso, quindi il fatto che la chiave privata non possa essere estratta è moot.

Nell'autenticazione della chiave pubblica SSH, ci sono due coppie di chiavi coinvolte.

• La prima coppia viene gestita da ciascun utente che sta provando ad autenticare il server . La chiave privata per ciascun utente viene mantenuta sulla workstation personale dell'utente o su un altro sistema client , non sul server a cui viene effettuata la connessione. Inoltre, la chiave pubblica di ciascun utente viene mantenuta nel file "authorized_keys" di quell'utente e non in un repository centrale. Quindi non esiste un equivalente del file password / shadow esistente sul server che un utente malintenzionato possa rubare.
• La seconda coppia è gestita dal server stesso, ed è lì per autenticare il server per l'utente . Mentre la chiave privata di questa coppia viene gestita sul server, è irrilevante poiché non fornisce l'autenticazione dell'utente sul server. Piuttosto, è un ulteriore passo che garantisce (se configurato correttamente) che l'utente sta effettuando una connessione allo stesso server a cui si è connesso per ultimo con quel nome o indirizzo (oppure se molti campanelli d'allarme si spengono e il client SSH può rifiutarsi di connettersi ).

Messo insieme, questo significa che un utente malintenzionato dovrebbe hackerare in ogni sistema client per ottenere l'accesso al server per quell'utente, piuttosto che accedere direttamente al server. È molto più lavoro che hackerare il lato server.

Tuttavia, significa che ora il sistema client deve essere fortificato contro gli attacchi, in particolare per un utente di alto valore (come un amministratore di sistema con accesso privilegiato su un server una volta autenticato) che detiene letteralmente i tasti al regno ;-) sul client / workstation. Questo è mitigato nella maggior parte dei casi richiedendo che la chiave privata sul client sia crittografata con una passphrase, che è fattibile solo dove l'utente in questione è una persona individuale e non un account meccanizzato o "bot".

Esistono anche sistemi "hardened" o "locked-down" in cui è impossibile rimuovere le chiavi dal server - i tasti devono essere generati & memorizzato altrove, e il server consente solo una piccola whitelist di programmi per usarli dopo averli importati.

Anche se si ottiene la chiave, dovrebbero anche essere protetti da password e ottenere tale password sarebbe difficile da indovinare / bruteforce se fatto correttamente.

Probabilmente si verificano perdite di chiavi private del server. Ma non ricevono tanta pubblicità.

Quando un database delle password è trapelato, molti siti decidono di obbligare gli utenti a cambiare la loro password. Ovviamente questo genera più pubblicità che se il sito sostituisce in silenzio la loro chiave segreta senza costringere gli utenti a cambiare la loro password. A seconda del punto di vista, questo può avere senso o meno. Esistono certamente degli scenari in cui una chiave privata trapelata renderebbe molto più importante per gli utenti cambiare la propria password rispetto a un database di password trapelato.

Esistono alcuni motivi per cui è più probabile che una perdita di un database delle password si verifichi che la perdita di una chiave privata.

Prima di tutto SSL può essere terminato su hardware separato dall'applicazione reale. È più probabile che sia presente una vulnerabilità nell'applicazione rispetto all'implementazione SSL, a causa del fatto che l'applicazione è spesso più complicata del protocollo SSL e poiché l'applicazione non è stata rivista con attenzione.

Se viene rilevata una debolezza nell'applicazione, ma SSL viene terminato su un altro computer, allora tale debolezza non darà accesso alla chiave privata. Inoltre, anche se si trovava sullo stesso computer, in alcune distribuzioni la chiave privata è collocata in un hardware sicuro in modo che anche l'implementazione SSL non abbia accesso completo alla chiave segreta.

Inoltre, i database delle password possono perdere a causa delle vulnerabilità di SQL injection, ma questi non danno accesso alle chiavi segrete SSL.

Se la chiave segreta è trapelata, l'amministratore può contattare la CA per revocare il certificato. In linea di principio ciò fermerà la minaccia posta dalla perdita.

Tuttavia, non appena la chiave segreta è trapelata, potrebbe essere abusata in attacchi mitm. Un tale attacco mitm potrebbe consentire all'utente malintenzionato di accedere alle password in chiaro. Ciò rende la password ottenuta in questo modo più facile da sfruttare rispetto a quella di un database di password trapelato, perché chiunque abbia solo un po 'di indizio avrà le password hash prima di memorizzarle.

D'altra parte usare la forza bruta su un database di password trapelate è probabile che rivelerà almeno alcune password di testo in chiaro, e quelle possono essere abusate senza la necessità di montare un attacco mitm in primo luogo.

Quindi ci sono motivi per richiedere agli utenti di cambiare la loro password in entrambi i casi, quale dei due incidenti sarebbe il peggiore dipende da molti altri fattori tra cui la forza della password. Una password sicura rimarrà protetta anche in caso di un database delle password trapelate (a meno che il database delle password non sia crittografato), ma se un mitm-attack viene eseguito utilizzando una chiave privata trapelata, la forza della password non fa differenza.