Anonimato a due fasi

3

EDIT:

[N.B: ho completamente sostituito la domanda originale che non era una buona affermazione del problema (vedi i commenti) con uno più adatto.]

Ho dei record che contengono, tra le altre cose, la posizione degli utenti e il loro ID (è un grande flusso di dati). Devo fornire a una terza parte la posizione degli utenti. (Il flusso viene anche filtrato in base ad altri criteri nello stream e forse anche fuso con altre fonti di dati che contengono tutti gli ID utente, se è di qualsiasi interesse qui e ora.)

Non devo passare gli ID utente a terze parti.

I record di un output devono consentire alla terza parte di creare "percorsi" e / o mappe di posizione varianti temporali degli utenti in un periodo di tempo (ad esempio un giorno ma molto più di un'ora). A tal fine devono essere in grado di identificare i record che appartengono allo stesso utente. Quindi è necessario passare qualche chiave.

Una restrizione importante che costituisce il nucleo del problema:

Per la discussione, definisco "ID utente anonimo" un attributo derivato dagli attributi dei record di input in modo tale che sia (quasi) derivabile univocamente dall'ID utente (ad esempio, un ID utente salato con hash o un valore fisso mappatura casuale) e inserito nei record del flusso di output in modo che i record appartenenti allo stesso utente possano essere identificati.

Le normative legali e le regole interne sono tali che devo assicurarmi che l'"user ID anonimizzato" possa essere riprodotto per non più di un'ora. (Come esempio illustrativo: se dovessi usare un hash salato dell'ID utente come "ID utente anonimizzato", dovrei usare una nuova ora di sale.)

(Nota: come accennato in precedenza, la terza parte deve mappare a lungo le posizioni degli utenti. Non si preoccupano ancora dell'identità dell'utente, ma devono sapere che è sempre lo stesso utente.)

E le domande sono: c'è un modo per farlo? Se sì, come?

    
posta fastcatch 04.04.2016 - 13:17
fonte

1 risposta

0

Per riformulare: il tuo sistema ha utenti con ID assegnati. Riceverai periodicamente dati sulla posizione associati a questi ID utente in tempo reale.

Hai anche uno (o più) clienti che vogliono analizzare le posizioni degli utenti. Ogni cliente ha bisogno di ricevere token randomizzati che ogni mappa a un ID utente e i token possono fare riferimento a un ID specifico per un periodo non superiore a una durata massima, ad esempio 24 ore. Il cliente ha bisogno dei dati sulla posizione. Il client non ha mai bisogno dell'ID utente reale.

E hai una politica che ti impedisce di conservare internamente la posizione associata ai tuoi veri ID utente.

Ecco una possibile soluzione:

Per prima cosa, ottieni una chiave pubblica da ciascuno dei tuoi clienti. All'inizio di ogni giornata, ogni cliente genera un sale casuale e lo memorizza internamente nella RAM, mantenendolo segreto. Dopo aver ricevuto un nuovo ID utente e una coppia di posizioni, aggiungi il sale del cliente all'ID, quindi calcola l'hash. Dopo l'hashing, crittografare immediatamente l'hash con la chiave pubblica del client, applicando il riempimento casuale, quindi scartare immediatamente l'hash. L'hash salato crittografato è ora un token crittografato specifico del client. Conserva solo l'ID client, l'ID della chiave pubblica, il token crittografato e i dati sulla posizione; posizionare i dati nella coda dei messaggi appropriata. Ripeti il processo di tokenizzazione per ogni cliente che riceverà i dati; dopo aver tokenizzato l'ID utente per ognuno dei tuoi clienti, elimina l'ID utente reale. È quindi possibile inviare i token crittografati con i dati sulla posizione a ciascun client ricevente. Una volta al giorno, distruggi il sale sicuro di ciascun cliente e generane uno nuovo.

Distruggendo l'hash intermedio e l'ID utente, si rimuovono gli unici collegamenti che legano il record della posizione a un ID utente reale. Puoi controllare la capacità del cliente di correlare i record distruggendo il loro sale.

    
risposta data 06.04.2016 - 06:27
fonte

Leggi altre domande sui tag