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.