Dove conservare la chiave privata?

Prima di tutto, non mi riferirei a me stesso come esperto di sicurezza, ma sono stato nella posizione di dover rispondere a questa domanda. Quello che ho scoperto mi ha sorpreso un po ': Non esiste un sistema completamente sicuro . Bene, immagino che un sistema completamente sicuro sia quello in cui i server sono tutti spenti:)

Qualcuno che ha lavorato con me al momento ha descritto la progettazione di un sistema sicuro in termini di innalzamento della barra agli intrusi. Quindi, ogni livello di protezione diminuisce l'opportunità di un attacco.

Ad esempio, anche se si riuscisse perfettamente a proteggere la chiave privata, il sistema non è completamente sicuro. Ma, usando correttamente gli algoritmi di sicurezza e aggiornandosi con le patch si alza la barra. Ma sì, un super computer abbastanza potente e dato abbastanza tempo può rompere la crittografia. Sono sicuro che tutto questo è compreso, quindi tornerò alla domanda.

La domanda è chiara, quindi proverò prima ad affrontare ognuno dei tuoi punti:

Say the key is protected by the filesystem's security model; but what about (malicious) superusers, or platforms that don't provide such fidelity?

Sì, se utilizzi qualcosa come Chiave di Windows Memorizza o una chiave privata TLS crittografata con password che sei esposto agli utenti che hanno la password (o accesso) alle chiavi private. Ma, penso che sarete d'accordo sul fatto che alzi il tiro. Gli ACL del file system (se implementati correttamente) forniscono un livello di protezione piuttosto buono. E tu sei nella posizione di controllare e conoscere personalmente i tuoi super utenti.

Or the key is hardcoded into software binaries, but it could always be decompiled and what about open source software or interpreted code?

Sì, ho visto chiavi hardcoded nei binari. Di nuovo, questo fa alzare un po 'la barra. Qualcuno che attacca questo sistema (se è Java) deve capire che Java produce codice byte (ecc.) E deve capire come decompilare lo si legge. Se si sta utilizzando una lingua che scrive direttamente su codice macchina, è possibile vedere che questo aumenta la barra un po 'più in alto. Non è una soluzione di sicurezza ideale, ma potrebbe fornire un certo livello di protezione.

If the key is generated, such an algorithm would need to be deterministic (presumably) and then the same problem applies to the seed.

Sì, in sostanza, l'algoritmo diventa la chiave privata per la creazione della chiave privata. Quindi, ora dovrebbe essere protetto.

Quindi, penso che tu abbia identificato un problema principale con qualsiasi politica di sicurezza, gestione delle chiavi . Avere una politica di gestione delle chiavi in atto è fondamentale per fornire un sistema sicuro. E, è un argomento piuttosto ampio .

Quindi, la domanda è: quanto è sicuro il tuo sistema (e, quindi, la chiave privata)? Quanto è elevato il livello nel tuo sistema?

Ora, se sei disposto a pagare, ci sono alcune persone là fuori che producono soluzioni a questo. Abbiamo finito per utilizzare un HSM (Hardware Security Module) . È fondamentalmente un server a prova di manomissione che contiene una chiave nell'hardware. Questa chiave può quindi essere utilizzata per creare altre chiavi utilizzate per la crittografia. L'idea è che (se configurato correttamente), la chiave non lascia mai l'HSM. Gli HSM costano molto . Ma in alcune aziende (proteggendo i dati della carta di credito), il costo di una violazione è molto più alto. Quindi, c'è un equilibrio.

Molti HSM utilizzano le key card da manutenzione e amministrazione delle funzionalità. Un quorum di key card (5 su 9 diciamo) deve essere fisicamente inserito nel server per poter cambiare una chiave. Quindi, questo aumenta la battuta piuttosto in alto consentendo solo una violazione se un quorum di super utenti collude.

Potrebbero esserci soluzioni software che offrono funzionalità simili a un HSM ma non sono a conoscenza di cosa siano.

So che questo è solo un modo per rispondere alla domanda, ma spero che questo aiuti.

Quello che vuoi non può essere fatto.

Say the key is protected by the filesystem's security model; but what about (malicious) superusers, or platforms that don't provide such fidelity?

In pratica, vuoi proteggere le persone che diventano malintenzionate. Nel tuo modello, a un certo punto qualcuno avrà accesso alla chiave. Cosa succede se quella persona è maliziosa? Cosa succede se sei malizioso? Vedi, il problema, come affermi, è irrisolvibile se non non hai affatto un tasto.

Quindi non lavorare con le credenziali del database ma con altri meccanismi di autenticazione. Ma non importa quale, qualcuno a un certo punto ha bisogno di accedere ai dati e che qualcuno può essere dannoso.

Questo è uno di quei problemi che non possono essere veramente risolti allo stesso livello in cui è stato creato. Dovremo fare un passo indietro verso alcune filosofie fondamentali e seguire la cascata nella speranza di una soluzione.

La prima filosofia è "non fidarti mai del cliente" e la relazione strettamente correlata "se vuoi davvero mantenere un segreto, non dirlo a nessuno!"

Un semplice esempio sono le credenziali del database, come hai detto. Ovviamente vuoi che il tuo cliente abbia accesso ad esso, ma non qualsiasi Internet Stranger casuale, quindi hai bisogno di una sorta di sistema di identificazione / verifica / login. Ma la premessa principale di nascondere questo è un problema: se l'utente stesso deve possedere un segreto, ma non vuoi che sappiano cos'è quel segreto, tutto ciò che puoi fare è nasconderlo o renderlo difficile da aprire " il pacchetto segreto ". Ma possono ancora scoprirlo, quindi è meglio avere un piano di backup!

La soluzione più semplice è "non farlo". Utilizzare le credenziali dell'account dell'utente per consentire l'accesso a livello di client al database per il software e il gioco è fatto. Se il client diventa malevolo, lo scenario peggiore dovrebbe essere che il client possa rovinare i propri dati. Questo è tutto. Il tuo database e il tuo sistema dovrebbero, al massimo, ora contenere le voci spazzatura da quel client, solo per quel cliente, senza nessun altro (incluso te) che soffre il caos.

Ci sono casi d'uso specifici in cui vuoi solo fare software implementato ma non avere tutti nel mondo in grado di connettersi e fare le stesse cose, ma per questo stai solo nascondendo i segreti e l'unica buona ragione per farlo è solo per ridurre il mal di testa o l'attività del sistema. Se le tue informazioni nascoste diventano di dominio pubblico, è meglio non essere un rompicapo, ma nel peggiore dei casi fastidioso.

Se ti trovi in uno di questi casi di utilizzo limitati, si tratta solo di offuscamento, che è tutto merito della creatività. È molto simile al Code Golf, davvero - tranne che tu sei quello che crea il puzzle. Questo è tutto ciò che è veramente - un puzzle. E alla gente piace risolvere i puzzle, quindi, ancora una volta, è meglio che sia ok quando qualcuno lo capisce.

Ma per la maggior parte delle cose nel mondo, è meglio operare senza preoccuparsi di dover mantenere un segreto dell'utente. Al contrario, la pratica migliore è quella di lasciare all'utente il segreto, renderlo responsabile di proteggerlo (nome utente e password, ad esempio) e limitare il rischio al ribasso di ciò che accade se il segreto esce o viene abusato.

Nei veri contesti crittografici / di sicurezza di "gestione delle chiavi", la risposta di "dove archiviare la chiave privata" è "da qualche altra parte!" La crittografia è protezione da punto a punto e la crittografia a chiave pubblica-privata è progettata per proteggere le informazioni in transito nel tempo e nello spazio. La chiave privata è intrinsecamente vulnerabile e la sua protezione non è in realtà una questione di crittografia che si sovrappone, ma la protegge dall'accesso completo. E se il sistema deve accedervi, allora il sistema stesso deve essere protetto - e non è possibile farlo sul computer di un cliente. Possono sempre eseguire una VM, eseguire il dump della RAM, annusare il traffico di rete, installare un proxy o una NIC virtuale, decompilare gli eseguibili ... non essere volontariamente coinvolti in questa battaglia.

Ora se hai bisogno di fare qualcosa come DRM, in cui la necessità di memorizzare un segreto è in realtà basata sul controllo dell'uso del software stesso, questa è un'altra situazione completamente .

TLDR: non mantenere segreti dall'utente, mantenere i segreti con l'utente.

Nella mia mente, l'unico modo per tenerlo completamente al sicuro è quello di avere la chiave / password crittografata con una passphrase da sbloccare. In questo modo la passphrase deve essere data per ogni avvio o utilizzo del segreto. Non troppo utile.

Un altro modo potrebbe essere che il sistema di sicurezza sia l'account del database stesso. Non molto scalabile ...

Se ciascun utente di un sistema ha il proprio account DB e tali account sono stati premiati in modo tale che l'applicazione non abbia i diritti per creare account in DB per conto di un utente, si potrebbe arrivare piuttosto vicino. Non è una buona soluzione, quindi suppongo che devi avere un accesso di lettura molto limitato sui file di configurazione e fidarti dei tuoi super utenti.

Uno dei sistemi che uso attualmente funziona in questo modo.

• Inizio con un modulo di accesso del servizio di autenticazione. Utilizza l'autenticazione a due fattori per assicurarmi che io sia chi ritengo di essere.
• Ricevo un certificato SSL temporaneo che posso utilizzare per accedere al servizio protetto. Il servizio tiene traccia dei certificati che accetta.
• I miei scambi sono crittografati da questo certificato da intercettazioni. Provare a craccarlo non è molto utile dato che scade.
• Il certificato scade rapidamente (in diverse ore), ma non troppo rapidamente, in modo da non dover fornire una password per ogni interazione.
• Il certificato può essere revocato istantaneamente dall'altra parte.

Ovviamente il servizio protetto funziona da qualche parte fuori dalla mia portata. Potrebbe essere eseguito sulla mia macchina con un account diverso (e possibilmente in un contenitore), ma ho i privilegi di superutente e potrei quindi tentare di eludere le restrizioni.

Fondamentalmente se si dispone di un superutente malintenzionato, tutte le scommesse sono disattivate. E tu dovresti assumere la presenza di un superutente malintenzionato nel tuo modello di minaccia.

Quindi è necessario isolare il servizio protetto dal computer accessibile dal client. Spostare il servizio protetto su una macchina accessibile solo tramite rete. Metti i tuoi clienti su macchine virtuali che impediscono loro di raggiungere il resto della macchina fisica in cui viene eseguito il servizio protetto.

Se il tuo servizio protetto non è così prezioso da essere in grado di comandare tali misure, vai con qualsiasi archivio di chiavi crittografato che il sistema operativo ti offre: Windows, Linux e OSX hanno implementazioni di portachiavi.