Qual è la strategia di mitigazione per il furto di una chiave privata di una CA?

Una chiave privata CA rubata è davvero una brutta situazione. La risposta dipende dall'entità della violazione e dal contesto.

In primo luogo, potrebbe essere che la chiave privata CA non fosse esattamente rubata , ma semplicemente usata in modo improprio. Ad esempio, nel caso del evento Comodo , il compromesso era su Account dell'autorità di registrazione . L'AR è il componente che dice alla CA cosa inserire nei certificati; l'RA è la parte che mappa effettivamente le identità fisiche nel mondo fisico. In tal caso, la chiave CA non è stata rubata e, sebbene siano stati emessi certificati con contenuti errati, la CA aveva ancora una conoscenza affidabile di tutti i certificati emessi. Bastava quindi revocare i certificati falsi, non la CA. Questo è il buon caso, dove il danno è contenuto.

Se è stata utilizzata la chiave CA e non esiste un modo affidabile per avere un elenco completo dei certificati falsi, o se la chiave privata CA è stata effettivamente rubata ed è ora sotto il controllo dell'attaccante, allora il certificato corrispondente dovrà essere revocato Questo viene fatto non dalla CA stessa, ma dalla sua CA superiore.

Quindi, per riparare tutti i siti onesti che sono appena "scomparsi" attraverso tale revoca, è possibile installare una nuova CA ed emettere automaticamente nuovi certificati per tutti i precedenti client (questo presuppone che abbiamo ancora tutti gli "onesti" emessi certificati da qualche parte). È sufficiente copiare le identità e i nomi dal vecchio certificato a quello nuovo.

Per motivi aziendali, è possibile negoziare per ritardare la revoca della CA compromessa fino a quando la nuova CA e i nuovi certificati cliente sono stati creati e distribuiti. Tuttavia, non c'è molto margine per questo.

Un piano d'azione per questo è il monitoraggio e il controllo regolari eseguiti su tutte le richieste.

Un po 'di come funzionano le CA SSL (fonte: Fox-IT Post Breach of DigiNotar)

Current browsers perform an OCSP check as soon as the browser connects to an SSL protected website through the https-protocol3. The serial number of the certificate presented by the website a user visits is send to the issuing CA OCSP-responder. The OCSP-responder can only answer either with "good", "revoked‟ or "unknown". If a certificate serial number is presented to the OCSP-responder and no record of this serial is found, the normal OCSP-responder answer would be „good‟4. The OCSP-responder answer "revoked" is only returned when the serial is revoked by the CA.

TL; DR: se non viene trovato alcun serial = > Bene, se Seriale è revocato = > Revocato

Con un monitoraggio adeguato, questo potrebbe essere stato identificato a un intervallo molto più veloce e un piano di risposta agli incidenti potrebbe essere entrato in vigore per mostrare un certificato come revocato quando non è stato trovato all'interno del risponditore di CA OCSP.

Ed ecco cosa ha incluso il piano IR (fonte: ancora da Post Breach)

In order to prevent misuse of the unknown issued serials the OCSP-responder of DigiNotar has been set to answer "revoked" when presented any unknown certificate serial it has authority over. This was done on September 1st. The incident response sensor immediately informs if a serial number of a known fraudulently issued certificate is being misused. Also, all unknown serial number requests can be analysed and used in the investigation. All large number of requests to a single serial number is suspicious and will be detected.

Più o meno questo dice che hanno messo in atto il monitoraggio e il controllo che avrebbero dovuto essere in atto fin dall'inizio, e che sarebbe stato identificabile attraverso una soluzione SIEM su ciò che si è verificato o su ciò che stava accadendo.

Se vuoi leggere il tutto: link