Indicizzazione dei dati crittografati per una ricerca efficiente

0

Ho implementato la crittografia per alcune colonne in un database. In alcuni casi potrebbe essere necessario cercare in queste colonne, sia per le corrispondenze esatte che per sottostringhe. Al momento, ci sono meno di 10000 righe da cercare (al massimo). Tuttavia questo probabilmente cambierà in futuro, quindi sto anticipando i problemi di efficienza.

I dati rimarranno crittografati nel database, ma quando recuperati dall'applicazione, possono essere decodificati. Ciò significa che il recupero non deve essere accurato al 100%, può recuperare più record di quelli effettivamente corrispondenti alla query e l'applicazione stessa può scartare i record non corrispondenti.

Con questo in mente ho trovato le seguenti soluzioni:

  • Per la corrispondenza esatta del testo, hash i dati crittografati e modulo questo con un numero relativamente basso (forse 2 ^ 16) e memorizza quel valore in una colonna aggiuntiva. Quando si esegue una query sul database, è necessario eseguire la stessa operazione sulla stringa di input e recuperare tutti i record con valore hash corrispondente.

  • Per trovare sottostringhe, cancellate ogni lettera e mod 32 il risultato. Quindi imposta il bit corrispondente in un numero intero. Eseguire la stessa operazione sulla stringa di query. Quindi è solo necessario recuperare i record in cui il risultato di un AND binario sulla query con il valore memorizzato è maggiore di 0. Questo potrebbe essere fatto usando ogni coppia di lettere, forse con un numero intero a 64 bit o più lungo per consentire più record da scartare.

La mia domanda è: una di queste tecniche avrà un impatto reale sulla sicurezza dei dati nelle colonne crittografate? Lo schema di crittografia è AES-256.

    
posta Slicedpan 06.11.2014 - 16:11
fonte

1 risposta

2

La capacità di restringere le ricerche tende ad essere in diretta opposizione con la riservatezza che si cerca attraverso la crittografia. Ad esempio, se memorizzi il tuo "hash a 16 bit" in una colonna aggiuntiva, allora quell'hash rivela 16 bit dei dati - 16 bit indiretti, ma 16 bit comunque. Un utente malintenzionato che vede il database potrebbe tentare di indovinare (forza bruta) il contenuto del record, ei 16 bit gli consentiranno di rilevare 65535/65536 ° di ipotesi errate: questo è un vantaggio sostanziale.

La capacità di eseguire ricerche di sottostringa è anche peggio, dal momento che rivela necessariamente informazioni che consentono all'attacco di forza bruta di procedere in fasi graduali (questo è in effetti lo stesso problema di autenticazione password parziale ).

Nel migliore dei casi, ciò che è possibile fare è implementare la crittografia deterministica , in modo tale che la crittografia di un valore di record specificato sempre produca lo stesso risultato crittografato. Questo fa trapelare un modicus di informazioni (se due record hanno gli stessi contenuti che mostreranno, nonostante il livello di crittografia); d'altra parte, consente ricerche esatte: crittografate il valore per cercare e usate l'indice sui valori crittografati. Le ricerche di sottostringhe, tuttavia, dovrebbero essere evitate a tutti i costi.

Penso che un metodo migliore sarebbe quello di rivisitare le tue ipotesi:

However this will probably change in the future so I am anticipating efficency problems.

Solitamente, i problemi di prestazioni non esistono fino a quando non sono stati effettivamente riscontrati (almeno in una piattaforma di test, se non in produzione) e debitamente misurati. Come Donald Knuth ha scritto una volta : l'ottimizzazione prematura è la radice di tutti i mali .

Anche se il problema di prestazioni previsto è reale e sai quanto costerà, potrebbero essere applicabili alcuni metodi alternativi. Ad esempio, è possibile leggere tutti i record nella RAM dell'applicazione, decrittografarli tutti e mantenerli nella RAM. Ciò consentirebbe ricerche molto veloci senza nemmeno andare al livello SQL. I server moderni hanno molta RAM. Ad esempio, i server che gestiscono i siti StackExchange (tutti) sono reputati sufficientemente potenziati nella RAM (poche centinaia di gigabyte) in modo che tutti i dati possano essere memorizzati nella cache e i server può eseguire tutti gli accessi in lettura alla velocità della RAM.

Se i tuoi record sono, per esempio, non più lunghi di 100 byte (ad esempio sono i nomi di alcune persone), puoi memorizzare 10 milioni di valore in un semplice gigabyte di RAM. Cos'è un gigabyte? Anche il tuo telefono ha più RAM di così.

    
risposta data 06.11.2014 - 16:35
fonte

Leggi altre domande sui tag