Come archiviare in modo sicuro dati sensibili come un numero di previdenza sociale?

Quello che stai cercando è la crittografia deterministica: che lo stesso valore criptato due volte fornisce lo stesso risultato. Data la crittografia deterministica con una chiave K, un utente malintenzionato avrebbe bisogno della chiave per determinare quale SSN esegue la mappatura a quale valore crittografato. Puoi ancora eseguire ricerche sui dati crittografati deterministicamente, ma solo confronti di equivalenza (==,! =).

Esempi di crittografia deterministica che funzionerebbero:

• Blocca le crittografie nella BCE in modalità, se i dati sono < 1 blocco lungo
• Blocca le cifrature in CBC in modalità, con un IV .
• Blocca i codici in CBC in modalità con un IV derivato dal testo in chiaro. (Si noti che non si desidera memorizzare IV, quindi la decifrazione senza il testo in chiaro è quindi impossibile, quindi questa è un'opzione di sola ricerca.)

Che cosa non funzionerà:

• CTR Modalità con un IV statico (un utente malintenzionato può quindi utilizzare più testi cifrati per recuperare il keystream & plaintext)
• Modalità CBC con IV casuale (non può cercare)
• Qualsiasi cifra di flusso (uguale alla modalità CTR)

Nota che, in tutti i casi, stai abbandonando l'indistinguibilità del testo cifrato, ma questo è un requisito fondamentale per poter cercare nei testi cifrati.

È necessario un meccanismo per condividere la chiave con altri sistemi che richiedono l'accesso al testo in chiaro, ma un utente malintenzionato che ottiene l'accesso a un backup del database, a un'iniezione SQL oa qualsiasi altro attacco che consente l'accesso solo al database non essere in grado di discernere i testi in chiaro.

PKI non sono utili qui, come fai notare, come se avessi la chiave pubblica consente di enumerare i valori e recuperarli, se si utilizza un crittosistema PKI deterministico (semplice, non imbottito, RSA , ad esempio). L'uso di una PKI non deterministica (RSA riempito) non ti consentirà di cercare nei testi cifrati.

Vorrei verificare se è davvero necessario crittografare i semplici e semplici testi forzati brutali. Qual è il tuo modello di minaccia? Puoi proteggere contro queste minacce in altri modi?

Tieni presente che ci sono due parti separate per proteggere questi dati, quando è a riposo e quando è in transito.

Non si dovrebbero memorizzare dati sensibili di alcun tipo (dati a riposo) direttamente in testo chiaro, punto. Cose come password e sicurezza sociale e numeri di carta di credito devono essere crittografati prima di essere archiviati su disco. Sono d'accordo con lorenzog sul disaccoppiamento della tua soluzione ma suggerisco una configurazione leggermente diversa:

1. Server di database. Questo server memorizza campi sensibili crittografati in un database (SQL / MySQL / Oracle), ma non ha mai i dati in chiaro. Sarà crittografato prima di essere memorizzato nella tabella / campo del database. Inoltre non ha la chiave privata per decodificare i dati, solo blob crittografati.

2. Crypto application server. Questo server memorizza la chiave privata utilizzata per crittografare e decrittografare i campi per un utente autorizzato autenticato. Questo è l'unico posto in cui i dati memorizzati nel server di database possono essere crittografati e decrittografati. Ovviamente questo sarà un obiettivo di alto valore, e dovrebbe essere temprato e controllato attraverso la politica. Trattare come un controller di dominio per esempio e controllare tutti gli accessi e le query ad esso.

3. Server Web. Richieste di bilanciamento del carico da parte dell'utente e comunicazioni sicure tra server e servizi. Servire come endpoint per la comunicazione a utenti esterni.

Anche la comunicazione (dati in transito) con il cliente e i suoi team partner è molto importante qui, non guardare oltre. Assicurati di utilizzare SSL e ai più alti livelli di crittografia e crittografia possibili.

Non sarà facile da configurare (più difficile di una protezione di base di sicuro, ma non impossibile con qualsiasi mezzo) e se infrangi la fiducia dei tuoi clienti sarai molto più in forma del tempo necessario per assicurarti dati personali giusti :)

Buona fortuna!

In realtà, hai TRE problemi che hai insinuato nella tua domanda.

• Il titolo parla di dati a riposo.
• Nella domanda parli anche del controllo degli accessi.
• Inoltre, hai anche una domanda di dati in transito.

La domanda potrebbe avere una risposta diversa se si sta già utilizzando un sistema DB e si introduce la crittografia in un sistema esistente. Molti dei sistemi DB ora supportano tali funzionalità di sicurezza (vedi sotto).

Controllo di accesso e dati in transito

La maggior parte dei sistemi DB supporta il controllo degli accessi dal primo giorno (è quasi un requisito minimo). Tuttavia, quando dici che tale e tale sistema deve essere in grado di leggerlo, è davvero una domanda di controllo degli accessi.

Allo stesso modo, i dati in transito sono anche una questione dei protocolli utilizzati, molti dei quali sono supportati dai sistemi di DB esistenti. Ad esempio, SQL Server supporta SSL per le connessioni, così come MySQL . (Cerca gli altri, potrebbero anche supportarli.)

Crittografia a riposo

Il terzo è la crittografia a riposo, che risolve il problema se una persona o un sistema non autorizzato ottenga il file DB effettivo, cosa vedono. Arriva anche un problema correlato di gestione delle chiavi, cioè perché non è possibile che chi ha ottenuto il tuo file DB non abbia le chiavi?

Durante la progettazione, sarebbe prudente assumere che un giorno le chiavi potrebbero essere compromesse o rubate o, semplicemente dal punto di vista dell'agilità di crittografia, sarà necessario modificare l'algoritmo e le chiavi (ad esempio, chiunque abbia usato DES doveva infine trasferirsi in AES). Anche se non può essere il costo 0, deve esserci un percorso esp. se il tuo DB sta per essere distribuito, per modificare l'algoritmo o la chiave.

Molti DB ora forniscono la crittografia a riposo insieme ad alcune soluzioni di gestione delle chiavi. Ad esempio, SQL Server ha supportato la crittografia dal 2008 . Inoltre, il server SQL ha pubblicato una gestione del ciclo di vita delle chiavi anche con apparentemente supporta chiavi simmetriche e asimmetriche (tramite certificati). Credo che SQL supporti anche la crittografia completa del DB rispetto ai campi selezionati tramite query (come nel caso specifico per SSN).

Allo stesso modo MySQL supporta anche la crittografia tramite le funzioni di query , che è possibile utilizzare per il tuo scenario SSN. Puoi anche utilizzare altri sistemi DB che potrebbero già supportare la crittografia e usarli.

Se utilizzi un sistema che supporta la crittografia integrata, è probabile che tu possa evitare molte insidie associate a farlo da solo, oltre a ottenere un sistema supportato.

DB ricerca

CryptDB è un sistema DB sviluppato presso il MIT che crittografa i dati a riposo e supporta anche l'esecuzione di query su dati crittografati. Se guardi la pagina del sistema, elenca le organizzazioni che lo stanno effettivamente utilizzando.

Scrittura della propria logica di crittografia

Probabilmente questo richiede più tempo e più difficoltà per farlo bene, ma in base alla tua domanda, sembra che tu stia pensando a questo come un problema. Se fossi in una situazione simile, sicuramente la eviterei e andrei con uno dei sistemi DB esistenti.

Ci sono molti problemi. Ad esempio, quando si crittografa i dati, l'output è in qualche modo casuale, pertanto la crittografia degli stessi dati con la stessa chiave di solito non comporterà lo stesso testo cifrato. Potrebbe essere un po 'impegnativo e potrebbe essere necessario ridurre l'entropia (ad esempio utilizzando gli stessi IV o sali) che potrebbero influire sulla sicurezza del sistema. E con qualcosa di semplice come la memorizzazione degli hash (o anche degli HMAC con una singola chiave), se qualcuno ottiene i file del database, possono eseguire la forza bruta per recuperare i dati in poche settimane, se non giorni. Ciò è particolarmente vero per campi come SSN, a meno che non si impieghi tempo e richiedano sempre più campi per una query (ad esempio SSN e DOB e prime tre lettere di cognome o tali combinazioni) e memorizzino solo quelli come hash ma nessuno dei due questi separatamente. Ciò aumenterà l'entropia e renderà più difficile per qualcuno trovare i valori effettivi nel caso in cui ottengano il file DB.

Oltre a questo, è necessario capire i principali problemi di gestione del ciclo di vita.

EDIT: In realtà è un problema comune e una volta ho valutato i dati di crittografia, quando ho scritto la risposta iniziale, non l'ho incluso qui. Da allora ho aggiornato la mia risposta per includere ciò, oltre a chiarire il controllo dell'accesso, la connessione sicura e i dati a problemi di resto.

How to safely store sensitive data like a social security number?
...
Must be able to search (i.e. to look up an existing piece of data) but not view
...

La crittografia omomorfica consentirà l'ordinamento e la ricerca di dati crittografati. Sia Microsoft che IBM hanno sistemi. Ma non li ho visti nella produzione mainstream (ancora). Vedi, ad esempio, Crittografia completamente omomorfa efficiente da (standard) LWE . Soddisfa anche i tuoi altri due requisiti: reversibilità e prestazioni.

Se non non ha bisogno della nozione di sicurezza PRP, allora usa un codice a blocchi. Potresti persino essere in grado di utilizzare uno schema FPE (Format Preserving Encryption). Vedi, ad esempio, Revisione della crittografia per la conservazione degli ordini - Analisi della sicurezza e soluzioni alternative migliorate e anche Una sinossi del formato che conserva la crittografia per alcune idee.

Non sono sicuro su cosa fare di "Altri sistemi devono essere in grado di recuperare il valore reale" (oltre alla reversibilità). Puoi spiegare il flusso di dati? Ingenuamente, direi di eseguire la selezione sui dati crittografati, decodificare i dati, crittografare i dati sotto la chiave pubblica del sistema remoto e quindi inviare i dati crittografati al sistema remoto.

However I think that an attacker could use the encryption process as an oracle and recover the data due to its low entropy.

Verrà a perdere informazioni se manca la nozione di sicurezza del PRP; non a causa di dati a bassa entropia come SSN. Ad esempio, RSA / OAEP può mascherare efficacemente un SSN. Il cattivo non ha più il vantaggio di indovinare (con qualche rinuncia alla mano).

Avrai anche bisogno di una strategia per l'archiviazione della chiave privata. Forse un HSM o KMIP. Guttman ha alcune idee interessanti su HSM e altri dispositivi di archiviazione (come l'hardware che supporta il protocollo KMIP) nel suo libro Sicurezza tecnica .

Non sono sicuro di cosa stai provando a fare (si tratta di un servizio Web? Un'app mobile? Un'applicazione desktop?) ma date le tue esigenze, potresti prendere in considerazione il disaccoppiamento del sistema in due componenti separati:

• Si potrebbe contenere un hash (sicuro) dell'SSN che funge da database di "sola lettura". Una ricerca per un determinato SSN avrebbe cancellato la query e confrontata con il database. Se l'hash esiste, restituisce una corrispondenza. Dovresti ovviamente considerare le query di limitazione della velocità in modo da evitare gli attacchi bruteforce.

• Un altro sistema (VM o separato fisicamente, fino a te) manterrebbe i dati "in chiaro" con un processo simile a PCI (ovvero per memorizzare dati finanziari sensibili). L'accesso a questo sistema sarebbe più rigido e saresti in grado di controllare più da vicino le autenticazioni di successo (e fallite).

L'immissione di un nuovo SSN su quest'ultimo sistema attiverebbe un aggiornamento delle voci sul primo. In questo modo è possibile replicare il database di "sola lettura" attraverso il bilanciamento del carico o tecniche simili per garantire le prestazioni.