È sicuro usare l'HMAC di una cosa come sale per un altro HMAC?

Naviga le tue risposte
4

Problema

Sto cercando di spiegare lo scenario completo nei prossimi paragrafi. Penso che sia importante per ottenere un contesto in cui viene posta la domanda, quindi ti prego di sopportare me, anche se è un muro di testo.

Al momento sono incaricato di anonimizzare i dati in modo sicuro. L'idea è di usare HMAC(<string to anonymize>, key) per rendere anonimi i dati in modo che non possano essere invertiti. Ad esempio se hai un ID cliente ( CUST299128218 ) questo sarebbe HMAC-ed usando SECRET come chiave a 543a36dd07fe4a3fa4a2db202546eaaccaef71f871ebafe11de3b54784ba266e . Dal momento che vogliamo eseguire analisi sui dati resi anonimi, è importante che lo stesso ID cliente produca sempre lo stesso digest HMAC. Quindi non possiamo gettare via la chiave segreta poiché abbiamo bisogno di anonimizzare i dati futuri con la stessa chiave.

Ovviamente la chiave deve essere archiviata in un posto sicuro in modo che non venga eliminata. Altrimenti qualcuno che conosce un ID cliente potrebbe facilmente trovare quel cliente specifico nei dati resi anonimi. Per vari motivi tecnici / organizzativi non è possibile utilizzare un modulo di sicurezza hardware per la memorizzazione della chiave. Quindi ho dato un'occhiata al Vault di HashiCorp, che sembra essere una buona idea per questo in quanto fornisce un'API REST dove puoi dargli un testo in chiaro e restituisce l'HMAC di questo testo in chiaro utilizzando un archivio precedentemente memorizzato chiave. La chiave non lascia mai il Vault, che è molto meglio che avere la chiave memorizzata in alcune proprietà di configurazione del software di anonimizzazione.

Tuttavia stiamo parlando di grandi quantità di set di dati per essere resi anonimi (alcune centinaia di migliaia fino a pochi milioni al giorno) ed è prevedibile che chiamino l'API Vault per ogni set di dati (possibilmente più volte se più articoli devono essere resi anonimi) si tradurrà in un tonnellata di spese generali che potrebbe sovraccaricare l'infrastruttura che abbiamo a disposizione per questo.

Soluzione proposta

Quindi ho avuto questa idea: cosa succede se ho usato una stringa fissa (ad esempio 'customer_id_secret_bootstrap' ) e ho permesso a Vault di creare un HMAC su questo utilizzando la chiave segreta. Quindi uso questo HMAC come chiave segreta per l'HMAC attuale sui dati da anonimizzare. In termini funzionali: 

temp_key = CALL_VAULT('customer_id_secret_bootstrap')
anonymized_text = HMAC( <plaintext>, temp_key)

In questo modo ho potuto effettuare una sola chiamata a Vault e mantenere la chiave temporanea in memoria. Dovrei sempre recuperare la stessa chiave temporanea da Vault (poiché si tratta di un HMAC), ma la chiave originale (che è usata per derivare la chiave temporanea) non lascia mai il vault e quando il programma si chiude, la chiave temporanea non può essere ricreata senza accedere al Vault. In questo modo, assicurerei la sicurezza della chiave senza avere un milione di chiamate al Vault.

Domanda

Ora sapendo che non sono un esperto di sicurezza di gran lunga, questa potrebbe essere una pessima idea per ragioni sconosciute a me. Pertanto mi piacerebbe eseguire questo con voi esperti qui - potete dirmi se questa è una buona o cattiva idea e se è una cattiva idea potresti suggerire un approccio alternativo che assicurerebbe la sicurezza della chiave e sarà scalabile?

Aggiornamento / Modifica

Come molte risposte sottolineano che non è sufficiente per sostituire gli ID in quanto vi sono altri campi che possono essere utilizzati per correlare le informazioni a un piccolo gruppo di persone o anche a una singola persona (ad es. i timestamp sono grandiosi per questo). Ci occupiamo anche di questo rimuovendo o sostituendo tali informazioni per garantire che ciò non possa accadere (abbiamo una lista di controllo molto lunga per quanto riguarda tali cose che si basa su standard di anonimizzazione). Non volevo inserire questi dettagli qui perché la domanda è già molto prolissa.

    
posta Jan Thomä 02.11.2017 - 12:08
fonte

2 risposte

1

Poiché sottolinea Luc , probabilmente lo stai già facendo meglio della maggior parte delle persone. Ti meriti credito per la cura della privacy dei tuoi clienti!

Quindi abbiamo tre diversi sistemi qui, in ordine di sicurezza:

  1. Basta usare una chiave segreta memorizzata in alcune configurazioni.
  2. Il tuo sistema - utilizzando un vault in combinazione con una chiave memorizzata nella configurazione.
  3. Uso solo di un deposito.

Il problema con # 1 è ovvio. Qualsiasi utente malintenzionato che ha accesso al tuo sistema può rubare la chiave e quindi usarla per forzare bruschi valori di hash sul proprio computer. Quello è cattivo.

Con # 2 si ottiene un po 'più di sicurezza. Qualcuno deve entrare nel tuo sistema e rubare CALL_VAULT('customer_id_secret_bootstrap') . Questo è più difficile, perché devono afferrarlo dalla memoria di lavoro e non dal disco. Inoltre è disponibile solo quando il sistema è in esecuzione. Quindi non accadrà casualmente sui backup, ecc. Ma un attaccante che ottiene il segreto può usarlo sul proprio sistema per forzare gli HMAC della forza bruta offline.

Questo è il punto in cui # 3 è più strong. Un utente malintenzionato che ottiene l'accesso al tuo sistema non può rubare nulla, perché la chiave non lascerà il vault. L'attaccante può provare a decifrare gli hash degli ID cliente sul tuo sistema chiamando il vault, ma non possono semplicemente rubare tutti gli hash e provare a craccarli nella privacy della propria casa.

Quindi, mentre # 3 è più sicuro del # 2, spetta a te giudicare se la sicurezza aggiuntiva vale il prezzo (in prestazioni ridotte, ecc.). Ciò dipende dal modello di minaccia e dall'importanza della sicurezza di queste informazioni.

    
risposta data 02.11.2017 - 13:59
fonte
1

Lasciami elencare le ipotesi / situazione:

  • Hai un grande database con ID cliente e altri campi per ogni cliente.
  • Vuoi anonimizzare questo per eseguire analisi. L'organizzazione continuerà a conoscere l'ID cliente originale (non si elimina l'ID originale in modo permanente), ma la persona che esegue l'analisi non lo farà.
  • Anche altri campi per il cliente dovranno essere resi anonimi.
  • Ti stai chiedendo se puoi semplicemente utilizzare l'ID cliente anonimizzato come chiave per HMAC degli altri campi.

La risposta è no, questo non sarebbe sicuro. La persona che fa un'analisi conosce l'ID cliente anonimo e può usarlo solo quando impone brute-forzare altri campi.

Un'altra opzione è creare semplicemente una chiave casuale per ogni cliente e archiviarla nel database con i dati del cliente. Ciò significa che non è necessario un "vault" o un modulo di sicurezza hardware: basta leggere alcuni byte da /dev/urandom e memorizzarlo con i dati del cliente. Quindi utilizzalo come chiave per rendere anonimi altri campi.

Immagino che il database sarà simile a questo: 

+---------+------------+------------+-------------------+
| ID      | Name       | Money      | Anonymization key |
+---------+------------+------------+-------------------+
| CUST999 | Jon Jonson | 3.14159265 | b2aZSo2D9erqwanrf |
+---------+------------+------------+-------------------+

Quindi per rendere anonimi: 

customer = database.read();
anon = new Customer();
anon.ID = anonymize(customer.ID, customer.AnonymizationKey)
anon.Name = anonymize(customer.Name, customer.AnonymizationKey)
anon.Money = customer.Money //Assuming you don't want to anonymize every field.
print(anon)

La funzione anonymize(data, key) potrebbe essere un HMAC come hai suggerito. Tuttavia, penso Il commento di Stephane è veramente buono: menzionano l'uso di un hash lento per prevenire la forzatura bruta. È possibile utilizzare un algoritmo di memorizzazione della password (Bcrypt, Scrypt, Argon2 o PBKDF2, in nessun ordine particolare) per rendere le cose più sicure. Dal momento che parli di molti dischi, però, potrei immaginare che ciò non sia possibile (o solo con fattori a basso costo), ma puoi esaminarlo.

A proposito, molte persone cercano semplicemente di cancellare l'ID cliente (ad esempio un numero di telefono) in modo che il reparto marketing possa dire con la faccia seria che è anonimo, anche se è banalmente forzato. Questo è già meglio, dal momento che coinvolge una chiave segreta. E per di più, stai pensando a misure appropriate per tenere davvero segreta quella chiave. +1 per quello!

    
risposta data 02.11.2017 - 12:51
fonte

Leggi altre domande sui tag

Cercando di eseguire il tunneling di una shell inversa da una rete interna Come faccio a utilizzare la cartella locale di google drive con la sincronizzazione automatica proteggendomi dal ransomware?