Dove conservare la chiave privata?

Supponiamo di voler crittografare alcune parti del mio software. Ad esempio, le credenziali per un database, ecc. Devo archiviare quei valori da qualche parte, ma farlo in chiaro dovrebbe rendere facile l'accesso non autorizzato a un utente malintenzionato.

Tuttavia, se crittografo del testo in chiaro, dove posso archiviare la chiave? Tutto ciò a cui il software ha accesso, un determinato attaccante avrebbe accesso, indipendentemente dal livello di offuscamento:

• Supponiamo che la chiave sia protetta dal modello di sicurezza del filesystem; ma per quanto riguarda i superutente (dannosi) o le piattaforme che non forniscono tale fedeltà?
• Oppure la chiave è codificata in file binari software, ma potrebbe sempre essere decompilata e che dire del software open source o del codice interpretato?
• Se la chiave viene generata, un tale algoritmo dovrebbe essere deterministico (presumibilmente) e quindi lo stesso problema si applica al seme.
• eccetera.

La crittografia è forte quanto l'anello più debole della sua catena e questo sembra piuttosto allentato! Presumendo che sia lo strumento giusto per il lavoro (umorizzami), allora come si possono proteggere in modo sicuro tali informazioni?

Per quanto riguarda lo strumento giusto per il lavoro: probabilmente, ad esempio nel caso dell'accesso al servizio (DB, server di autenticazione, ecc.), Si limiterebbe l'accesso a questo livello con un account di servizio, magari con un certo livello di servizio auditing, ecc. e quindi avere le credenziali in chiaro non è così preoccupante.

Per me, tuttavia, ciò sembra ancora inadeguato: non voglio che qualcuno cerchi in giro dove non dovrebbero essere!

Prima di tutto, non mi riferirei a me stesso come un 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 sarebbe uno in cui i server sono tutti spenti :)

Qualcuno che lavorava con me all'epoca descrisse la progettazione di un sistema sicuro in termini di innalzamento del livello di intrusione. Pertanto, ogni livello di protezione riduce l'opportunità di un attacco.

Ad esempio, anche se è possibile proteggere perfettamente la chiave privata, il sistema non è completamente sicuro. Tuttavia, l'uso corretto degli algoritmi di sicurezza e l'aggiornamento delle patch alzano il livello. Ma sì, un super computer abbastanza potente e dotato di tempo sufficiente può interrompere la crittografia. Sono sicuro che tutto ciò sia compreso, quindi risponderò alla domanda.

La domanda è chiara, quindi cercherò innanzitutto di affrontare ciascuno dei tuoi punti:

Supponiamo che la chiave sia protetta dal modello di sicurezza del filesystem; ma per quanto riguarda i superutente (dannosi) o le piattaforme che non forniscono tale fedeltà?

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

Oppure la chiave è codificata in file binari software, ma potrebbe sempre essere decompilata e che dire del software open source o del codice interpretato?

Sì, ho visto le chiavi codificate nei file binari. Ancora una volta, questo aumenta un po 'l'asticella. Qualcuno che attacca questo sistema (se è Java) deve capire che Java produce un codice byte (ecc.) E deve capire come decompilarlo, lo legge. Se stai usando un linguaggio che scrive direttamente nel codice macchina, puoi 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.

Se la chiave viene generata, un tale algoritmo dovrebbe essere deterministico (presumibilmente) e quindi lo stesso problema si applica al seme.

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

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

Quindi, la domanda è: quanto deve essere sicuro il tuo sistema (e, quindi, la chiave privata)? Quanto in alto, nel tuo sistema, è necessario alzare la barra?

Ora, se sei disposto a pagare, ci sono alcune persone là fuori che producono soluzioni a questo. Abbiamo finito per usare 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 qui è che (se configurato correttamente), la chiave non lascia mai l'HSM. Gli HSM costano molto . Ma in alcune aziende (diciamo per proteggere i dati delle carte di credito), il costo di una violazione è molto più elevato. Quindi, c'è un equilibrio.

Molti HSM utilizzano le carte chiave di manutenzione e amministrazione delle funzionalità. Un quorum di carte chiave (diciamo 5 su 9) deve essere fisicamente inserito nel server per cambiare una chiave. Quindi, questo aumenta il livello piuttosto elevato consentendo una violazione solo se un quorum di super utenti collude.

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

So che questo serve solo a rispondere alla domanda, ma spero che questo aiuti.

Quello che vuoi non può essere fatto.

Supponiamo che la chiave sia protetta dal modello di sicurezza del filesystem; ma per quanto riguarda i superutente (dannosi) o le piattaforme che non forniscono tale fedeltà?

Fondamentalmente vuoi protezione da persone che diventano maligne. Nel tuo modello, a un certo punto qualcuno avrà accesso alla chiave. E se quella persona fosse maliziosa? E se SEI dannoso? Vedi, il problema mentre dichiari è irrisolvibile se non dal fatto di non avere una chiave.

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

Questo è uno di quei problemi che non è possibile risolvere 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 stretta relazione "se vuoi davvero mantenere un segreto, non dirlo a nessuno!"

Un semplice esempio sono le credenziali del database, come hai menzionato. Ovviamente vuoi che il tuo client abbia accesso ad esso, ma non uno sconosciuto Internet casuale, quindi hai bisogno di un qualche tipo di sistema di identità / verifica / accesso. Ma la premessa principale di nascondere questo è un problema: se l'utente stesso deve possedere un segreto, ma non vuoi che sappiano qual è 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". Usa 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 dannoso, lo scenario peggiore dovrebbe essere che il client possa rovinare i propri dati. Questo è tutto. Il tuo database e sistema dovrebbero, al massimo, ora contenere voci spazzatura da quel client, esclusivamente per quel client, senza che nessun altro (incluso te) soffra dal caos.

Ci sono casi d'uso specifici in cui vuoi solo che il software distribuito faccia qualcosa ma non hai tutti al mondo in grado di connettersi e fare le stesse cose, ma per questo stai solo nascondendo segreti e l'unica buona ragione per farlo è solo quella di ridurre il mal di testa o l'attività del sistema. Se le tue informazioni nascoste diventano di conoscenza comune, è meglio che non siano un gioco da ragazzi, nel peggiore dei casi fastidioso.

Se ti trovi in ​​uno di quei casi d'uso ristretti, si tratta solo di offuscamento, che si basa solo sulla creatività. È molto simile a Code Golf, davvero - tranne che sei tu a creare il puzzle. Questo è tutto ciò che è davvero: un puzzle. E alla gente piace risolvere enigmi, quindi di nuovo, va bene quando qualcuno lo capisce.

Ma per la maggior parte delle cose nel mondo, è meglio operare senza preoccuparsi di dover mantenere un segreto per l'utente. Invece, la migliore pratica è quella di far entrare l'utente nel segreto, assumersi la responsabilità di proteggerlo (nome utente e password, ad esempio) e limitare il rischio di ciò che accade se il segreto viene divulgato o abusato.

Nei veri contesti crittografici / di sicurezza "gestione chiavi", la risposta di "dove archiviare la chiave privata" è "altrove!" La crittografia è una protezione 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 proteggerla non è in realtà una questione di sovrapposizione della crittografia, ma la protegge completamente dall'accesso. E se il Sistema deve accedervi, allora il Sistema stesso deve essere protetto - e non è possibile farlo sul computer di un client. Possono sempre eseguire una VM, scaricare la RAM, annusare il loro traffico di rete, installare un proxy o una NIC virtuale, decompilare gli eseguibili ... non essere coinvolti volontariamente in quella battaglia persa.

Ora, se hai bisogno di fare qualcosa come DRM, in cui la necessità di archiviare un segreto si basa effettivamente sul controllo dell'uso del software stesso, questa è un'altra situazione del tutto .

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

Uno dei sistemi che uso attualmente funziona in questo modo.

• Comincio con un modulo di accesso del servizio di autenticazione. Utilizza l'autenticazione a due fattori per assicurarsi che io sia quello che pretendo 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 criptati da questo certificato da intercettazioni. Cercare di rompere non è molto utile poiché scadrà.
• Il certificato scade rapidamente (tra diverse ore), ma non troppo rapidamente, quindi non è necessario fornire una password per ogni interazione.
• Il certificato può essere immediatamente revocato dall'altra parte.

Naturalmente il servizio protetto funziona da qualche parte fuori dalla mia portata. Potrebbe funzionare sul mio computer con un altro account (e possibilmente in un container), ma ho i privilegi di superutente e quindi posso provare a eludere le restrizioni.

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

Quindi è necessario isolare il servizio protetto dalla macchina accessibile dal client. Spostare il servizio protetto su una macchina accessibile solo via rete. Metti i tuoi clienti su macchine virtuali che impediscono loro di raggiungere il resto della macchina fisica su 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 crittografate che il sistema operativo ti offre: sia Windows, Linux che OSX hanno implementazioni di portachiavi.

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

Un altro modo potrebbe essere quello di avere l'account del database stesso come sistema di sicurezza. Non molto scalabile ...

Se ogni utente su un sistema ha il proprio account DB, e tali account sono stati predisposti in modo tale che l'applicazione non disponga dei diritti per creare account nel DB per conto di un utente, potresti avvicinarti abbastanza. Neanche una buona soluzione, quindi immagino che tu debba avere un accesso in lettura molto limitato ai file di configurazione e fidarti dei tuoi super-utenti.