Come vengono private le chiavi private?

97

Può sembrare una domanda stupida, ma seriamente, come sono private le chiavi private?

Se sei qualcuno come Google hai un numero enorme di server a cui il pubblico può stabilire connessioni sicure.

La chiave privata *.google.com è richiesta per stabilire ognuna di queste connessioni.

I server stanno presumibilmente raggiungendo la fine della loro vita per tutto il tempo e vengono eliminati (portando al potenziale rischio di perdite a quel punto di qualsiasi cosa su di loro).

I data center moderni richiedono un numero molto ridotto di persone, ma aziende come Google sono così grandi che c'è ancora un numero significativo di persone con accesso fisico ai server.

Questi server si trovano dietro firewall ed eseguono sistemi operativi altamente protetti, ma sia i router che i sistemi operativi possono subire exploit zero-day.

Quindi è abbastanza ovvio che le chiavi private non possono essere archiviate su base server o su immagini OS recuperate all'avvio (anche se crittografate) o su smart card per server.

Presumibilmente le aziende non ne discutono apertamente ma ci sono delle buone visioni su come funzionano le cose?

C'è qualche bunker indurito da qualche parte dove viene gestito solo l'elemento chiave asimmetrico iniziale di stabilire ogni connessione?

Presumibilmente, in realtà, hai bisogno di tali bunker per data center, suppongo che tu non voglia perdere un intero data center a causa della perdita del link a un sito di gestione chiavi remote.

Anche la duplicazione della chiave nei data center sembra molto rischiosa considerando il valore di una chiave come quella per *.google.com .

Mi manca qualcosa che rende la gestione delle chiavi come questa non così difficile come sembra a qualcuno che prova a pensarci da capo?

    
posta George Hawkins 08.04.2015 - 12:48
fonte

2 risposte

82

In primo luogo, spesso la crittografia viene terminata al perimetro dall'infrastruttura dedicata allo scarico della decrittografia SSL. Rende molto più facile da gestire quando hai solo un livello elevato di sicurezza delle chiavi per un piccolo gruppo (proporzionalmente) di server dedicato al ruolo. Il resto dei normali server delle applicazioni può funzionare normalmente senza preoccuparsi di gestire queste chiavi.

In secondo luogo, le loro chiavi sarebbero quasi certamente memorizzate tramite un Modulo di sicurezza hardware (HSM). Questi sono dispositivi hardware dedicati con un processore progettato per mantenere la sicurezza ed essere efficienti nell'effettuare la crittografia.

Infine, Google ha il suo certificato CA intermedio che può utilizzare per firmare i propri certificati foglia. Ciò consente loro di utilizzare certificati con scadenza molto più breve del normale, il che riduce in qualche modo il rischio di compromissione di una chiave. La chiave CA effettiva può essere tenuta chiusa in un bunker con aria aperta e accessibile solo quando è necessario firmare un certificato foglia a breve termine.

Ricordando anche che una CA non ha bisogno della chiave privata foglia per firmare un certificato, potrebbe generare una chiave privata che non lascia mai un HSM onsite in un data center remoto, quindi inviare la chiave pubblica / CSR alla CA per essere firmato Potrebbero anche generare una chiave privata univoca per ogni singolo dispositivo HSM, in questo modo una chiave non deve mai lasciare il dispositivo che l'ha generata.

Ad esempio, ecco una schermata di stampa di un certificato Google corrente:

Noteraicheilcertificatoèvalidosoloper3mesi,cheèsignificativamentepiùbrevedimoltialtri.

Modifica:Googledescriveinrealtàlesuenormeindettaglio qui .

In the Google PKI, a Subscriber is an individual or an organization capable of using, and authorized to use, the Private Key that corresponds to the Public Key listed in a Certificate

...

The Google Internet Authority servers are located inside of a locked cabinet or cage area in a locked server room. Access to the server room is controlled by badge readers. The private keys for the Google Internet Authority are stored in hardware security modules that are FIPS 140­-2 Level 2 that are physically tamper­-evident and tamper-­resistant.

...

Subscriber Key Pairs are generated (i) by the Subscriber by software supplied by their device/operating system, or (ii) by an authorized member of Google’s Information Security Team.

...

Subscribers provide their public key to Google for certification through a PKCS#10 Certificate Signing Request. The preferred transfer method for sending this information is HTTP over Secure Sockets Layer (SSL).

Fondamentalmente è esattamente come funziona una normale CA, eccetto che è condotta internamente all'interno di Google.

    
risposta data 08.04.2015 - 13:48
fonte
-2

La risposta breve è "Sono molto molto cauti" dove "sono le chiavi private".

Penso che potresti essere frainteso o ignorare una parte fondamentale di come funzionano questi tipi di chiavi: quando firmi qualcosa, è un'operazione matematica unidirezionale che "dimostra" che è stata firmata da una particolare entità. (Tecnicamente, qualcuno con accesso a tale chiave e conoscenza di eventuali password / chiavi utilizzate per crittografarlo inizialmente).

I server con cui ci si connette non memorizzano le chiavi private, hanno "cose" (di solito certs in questo caso) che, essendo firmate, possono essere create solo da qualcuno con la chiave privata. Nello stesso modo in cui ricevere una email firmata da PGP non ti consente di fingere di essere il mittente, un server Web non autorizzato non rischia di (direttamente) la perdita di alcuna chiave.

Tutto ciò presuppone la perfetta implementazione di tutte le fasi del processo senza difetti sfruttabili nel codice implementato o gli algoritmi matematici sottostanti, ovviamente. O qualcuno con una grande chiave inglese e l'accesso alle persone interessate. ( link )

    
risposta data 14.04.2015 - 18:02
fonte

Leggi altre domande sui tag