Come generare un numero di identificazione anonimo (anche per l'amministratore di sistema) da un numero di identificazione non anonimo

0

Premessa: mi viene chiesto di sviluppare un sistema che tracci i dati sensibili. I dati sono raccolti da un operatore intermedio (chiamiamolo IO) su un terminale di ufficio. L'utente finale (UE) si presenterà all'ufficio, si identificherà tramite un documento di identità, l'operatore acquisirà le informazioni e lo invierà al sistema. Su richiesta, dato l'ID non anonimo, l'IO può consultare la cronologia di tutte le informazioni acquisite per tale ID.

Obiettivo: memorizzare i dati su un server centralizzato in modo completamente anonimo usando un ID anonimo come alias dell'ID reale. Voglio rendere duro anche agli operatori tecnici del server per recuperare l'ID originale.

La mia soluzione sin da ora: come primo passo verso la soluzione ho pensato di generare un hash salato a partire dalla password inserita dall'IO, e utilizzare questo sale per l'hashing dell'ID non anonimo, quindi inviare al server l'ID hash invece del vero ID (esiste la possibilità di una collisione hash, ma, nel mio scenario, è un rischio accettabile).

Il problema è che ogni volta che l'IO cambierà la password, perderà l'accesso alla cronologia di tutti gli ID inseriti (lo stesso ID non anonimo verrà tradotto come x prima della modifica della password e dopo y).

Un miglioramento dovrebbe essere che il sistema genererà un salt sulla macchina IO al primo tentativo di login, crypt usando la password IO e memorizzandola sul server. Il sale verrà recuperato ad ogni accesso futuro, decrittografato sulla macchina IO e utilizzato per generare l'ID. Se l'utente modificherà la sua password invierà, durante la normale procedura di modifica della password anche l'hash crittografato con la nuova password. Se l'utente ha dimenticato la password, verrà avviata la procedura per generarne una nuova e IO perderà l'accesso alla cronologia (ciò è accettabile data la natura sensibile di questi dati, sarà responsabilità dell'IO archiviare la sua password nel modo più sicuro possibile).

Al momento vedo impeccabile questa procedura, sul lato server, ogni volta che un nuovo hash crittografato verrà inviato al server, l'operatore tecnico avrà accesso a una sequenza di hash crittografati, sanno che questo è lo stesso numero crittografato con password diverse, questa sarà un'informazione utile che aiuterà a rompere il sale. Come posso proteggermi da questo? Ci sono altri punti deboli?

Ma c'è di più: la soluzione perfetta consentirà a 2 o più IO di raccogliere i dati per lo stesso ID non anonimo e di memorizzarli sul server con lo stesso ID anonimo che non consente all'operatore del server di recuperare l'ID originale.

C'è un modo per raggiungere questo risultato?

Grazie

PS: come osservato in una delle risposte, una delle sfide di questo progetto è che gli ID anonimi non sono molto limitati (dell'ordine di miliardi) e possono essere facilmente enumerati.

    
posta Fabio Persi 09.11.2017 - 17:40
fonte

2 risposte

1

Dipende da alcune cose:

  • Quanto è grande lo spazio dei tasti di input
  • Quanto sono sicuri i sistemi che elaboreranno questi dati
  • Quanti soldi hai da spendere

La dimensione dello spazio per le chiavi - l'ID originale - è importante perché un ampio spazio per le chiavi può consentire di utilizzare un semplice algoritmo. Ad esempio, se vuoi rendere anonimi gli indirizzi email, basterà un semplice hash SHA-X, perché gli indirizzi email sono lunghi e hanno un numero effettivamente infinito di valori possibili.

D'altro canto, se si desidera rendere anonimi i numeri di previdenza sociale degli Stati Uniti, l'hash non sarà sufficiente, perché è banale enumerare tutti i valori possibili.

Quindi puoi aggiungere un salt, che aumenta la dimensione dei valori di input. Ma come hai notato, non puoi lasciare che il sale cambi per lo stesso ID o perdi la capacità di tracciare quell'ID nel tempo. Ma poi devi gestire il sale che appartiene a ciascun ID, in modo che possa essere riapplicato di volta in volta.

Ecco un'idea di pessima : inserisci un codice hard nella tua applicazione e usa lo stesso sale per ogni ID. Ciò garantirà l'anonimato solo fino a quando nessuno è in grado di scoprire il sale. Una volta che lo fanno, ovviamente, possono facilmente enumerare tutti i valori hash.

Ma punta a una soluzione migliore: esternalizzare l'hashing, a un sistema che non controlli. Dovresti inviare l'ID effettivo a questo sistema esterno e ti restituirebbe un valore hash. Se i tuoi sistemi sono compromessi, non aiuta l'aggressore; dovrebbero anche compromettere il servizio di hash.

Il che mi porta all'implementazione standard: un modulo di sicurezza hardware . Questo modulo si collega al computer e fornisce l'operazione di hashing. Un utente malintenzionato dovrebbe accedere fisicamente al modulo e sono progettati per impedire l'accesso fisico.

Lo svantaggio è che sono costosi e richiedono di gestire fisicamente (e proteggere!) le macchine che li utilizzano. Ma se vuoi delle garanzie, è lì che finirai.

    
risposta data 09.11.2017 - 19:49
fonte
0

Se il tuo keypace di input è troppo piccolo, non c'è nulla che tu possa fare per forzarlo bruto. Tutto ciò che puoi sperare è renderlo più difficile. La mia inclinazione sarebbe quella di fare qualcosa come rendere l'ID anonimo semplicemente un bcrypt hashing dell'ID non anonimo ma con un fattore di lavoro molto elevato: scegli un numero che faccia dire 10 secondi di lavoro.

Inoltre, ci sono altre informazioni nel record non anonimo che non è in quello anonimo? Dì, forse, una data di nascita? Questo non può cambiare, anche se è lontanamente possibile che venga rilevato e corretto un errore. L'aggiunta di questo aumenterebbe notevolmente lo spazio delle chiavi.

    
risposta data 10.11.2017 - 04:48
fonte

Leggi altre domande sui tag