linkability risks

[ivanvisconti]

How does Immuni prevent that RPIs generated and sent by the smartphone of the infected citizen (in the two weeks before uploading TEKs) are not linked by the backend?

[48656c6c6f20576f726c64]

@ivanvisconti la domanda è incomprensibile. Prova a riscriverla in italiano e magari c'è la possibilità che qualcuno la capisca e ti risponda.

[ivanvisconti]

Va bene ora ripropongo la questione in italiano usando un linguaggio informale per renderle l'issue comprensibile anche a chi non conosce i termini standard usati in ambito scientifico.

Come sappiamo, la procedura di upload prevista da immuni prevede che i TEKs che sono memorizzati nello smartphone vengano inviati al server SOGEI. Ricordiamo che i TEKs sono delle chiavi segrete generate dallo smartphone. Sulla base di tali chiavi lo smartphone ha inviato nei giorni precedenti, a chiunque si trovasse in prossimità, delle stringhe di 16 byte chiamate RPIs (invio effettuato via broadcast BLE). Gli RPIs sono degli pseudonimi derivati deterministicamente dai TEKs. Chiunque con i TEKs può ricalcolare tutti gli RPIs. L'intento di utilizzare gli RPIs che cambiano continuamente (credo ogni 15 minuti circa) è di offrire una proprietà di "unlinkability", ossia evitare che uno stesso smartphone sia tracciabile per lunghi periodi di tempo. Quindi vedendo due RPI dovrebbe essere computazionalmente difficile stabilire se derivano dallo stesso smartphone oppure da due smartphone differenti. Detto questo, il problema che pongo con questo issue è il seguente. Mi sembra di capire dalla documentazione della progettazione di Immuni che i TEKs sono inviati tutti insieme al server SOGEI durante la fase di upload che segue la validazione dell'OTP. Se questo è vero, allora chiaramente il server (e chiunque sia dietro ad esso in base a come viene gestito il server, come ad esempio AKAMAI, azienda straniere, spie, tecnici... c'è da sperare che AKAMAI/aziende straniere non siano coinvolte nella fase di upload, cmq il problema resta limpido su chi ha le mani sul server che riceve l'upload) ovviamente deduce correttamente che gli RPIs appartengono allo stesso cittadino. Di conseguenza, la proprietà di unlinkability è completamente violata. Chiedo quindi al team di Immuni, quale tecnica stiano utilizzando per garantire l'unlinkability visto che dalla documentazione non si evince.

[gbonfiglio]

L'intento di utilizzare gli RPIs che cambiano continuamente (credo ogni 15 minuti circa) è di offrire una proprietà di "unlinkability", ossia evitare che uno stesso smartphone sia tracciabile per lunghi periodi di tempo.

Nella visione originale DP-3T la separazione tra TEK e RPI serve ad evitare che un osservatore esterno, sniffando un RPI possa derivare quelli successivi e quindi sapere cosa tracciare.

Dai TEK (che vengono caricato in caso di contagio confermato) si possono derivare tutti gli RPI ed è facile pensare che questo sia fatto per motivi di semplicità computazionale / per evitare di dover scaricare milioni di chiavi ogni giorno.

Mi sembra di capire dalla documentazione della progettazione di Immuni che gli RPIs sono inviati tutti insieme al server SOGEI durante la fase di upload che segue la validazione dell'OTP.

Da dove deduci questo? E soprattutto, se vengono caricati i TEK come da procedura, tutti gli RPI sono automaticamente deducibili, quindi a) che senso avrebbe caricarli e b) non capisco dove sta il problema, a TEK caricato il backend già ha un modo per derivare tutti quei dati.

[ivanvisconti]

L'intento di utilizzare gli RPIs che cambiano continuamente (credo ogni 15 minuti circa) è di offrire una proprietà di "unlinkability", ossia evitare che uno stesso smartphone sia tracciabile per lunghi periodi di tempo.

Nella visione originale DP-3T la separazione tra TEK e RPI serve ad evitare che un osservatore esterno, sniffando un RPI possa derivare quelli successivi e quindi sapere cosa tracciare.

Il decentralizzato rispetto al centralizzato ha l'obiettivo di preservare privacy rispetto al server in quanto se consideriamo come avversari solo gli esterni allora il centralizzato funziona molto meglio. Quindi non sono d'accordo sulla frase che hai scritto e non capisco nemmeno cosa c'entri DP-3T con Immuni, il governo ha chiesto di progettare Immuni a Bending Spoons, altrimenti si rivolgeva a DP-3T, e parlavamo dei flaw nel design di DP-3T.

Dai TEK (che vengono caricato in caso di contagio confermato) si possono derivare tutti gli RPI ed è facile pensare che questo sia fatto per motivi di semplicità computazionale / per evitare di dover scaricare milioni di chiavi ogni giorno.

Mi sembra di capire dalla documentazione della progettazione di Immuni che gli RPIs sono inviati tutti insieme al server SOGEI durante la fase di upload che segue la validazione dell'OTP.

Da dove deduci questo? E soprattutto, se vengono caricati i TEK come da procedura, tutti gli RPI sono automaticamente deducibili, quindi a) che senso avrebbe caricarli e b) non capisco dove sta il problema, a TEK caricato il backend già ha un modo per derivare tutti quei dati.

I TEKs sono inviati insieme da cui si derivano gli RPIs (ho corretto il commento precedente in quanto avevo scritto direttamente RPIs, mentre invece l'invio è indiretto).

[48656c6c6f20576f726c64]

@ivanvisconti tutto quello che scrivi è corretto, ma continuo a non comprendere perché fai queste domande al team che ha realizzato Immuni quando quello di cui parli è lo standard definito da Apple/Google e dovresti chiedere dunque a loro come hanno pensato di mitigare situazioni simili e non al team di Immuni.

[ivanvisconti]

@48656c6c6f20576f726c64 d'accordo non lo capisci, sono confidente che il team di immuni lo capisca.

[48656c6c6f20576f726c64]

@ivanvisconti il tuo feedback tecnico è sullo standard Apple/Google, non su Immuni e questo è il repository di Immuni, non di Apple/Google. Se pensi che il tuo feedback tecnico sia valido, ti consiglio di farlo presente nel repository corretto: https://github.com/google/exposure-notifications-server

Issues and Questions You can open a GitHub Issue. Please be sure to include as much detail as you can to help aid in addressing your concern. If you wish to reach out privately, you can send an e-mail exposure-notifications-feedback@google.com.

[ivanvisconti]

@48656c6c6f20576f726c64 per fare tale affermazioni dovresti avere evidenza del fatto che l'issue che pongo sia inevitabile usando Apple/Google. Se ne hai inoltra pure, sarebbe utile alla discussione.

[48656c6c6f20576f726c64]

@ivanvisconti ti sarebbe bastato leggere la documentazione ufficiale. Qui puoi trovare l'evidenza: https://blog.google/documents/69/Exposure_Notification_-_Cryptography_Specification_v1.2.1.pdf. Come puoi notare, al fondo del documento c'è la sezione Privacy Considerations:

"A Temporary Exposure Key is required to correlate between a user’s Rolling Proximity Identifiers. This reduces the risk of privacy loss from broadcasting the identifiers."

Come vedi, hanno ultilizzato la parola "reduces" e non la parola "eliminates".

[ivanvisconti]

@ivanvisconti ti sarebbe bastato leggere la documentazione ufficiale. Qui puoi trovare l'evidenza: https://blog.google/documents/69/Exposure_Notification_-_Cryptography_Specification_v1.2.1.pdf. Come puoi notare, al fondo del documento c'è la sezione Privacy Considerations:

"A Temporary Exposure Key is required to correlate between a user’s Rolling Proximity Identifiers. This reduces the risk of privacy loss from broadcasting the identifiers."

Come vedi, hanno ultilizzato la parola "reduces" e non la parola "eliminates".

No, sbagli, come vedi l'issue che ho aperto parla di TEKs, nota il plurale.

[Zekromaster]

@ivanvisconti il tuo feedback tecnico è sullo standard Apple/Google, non su Immuni e questo è il repository di Immuni, non di Apple/Google

Lo standard da utilizzare è una scelta di design soggetta allo stesso scrutinio di qualsiasi altra scelta di design. La decisione di utilizzare uno standard non sicuro è stata comunque operata dal team di Immuni, che non può semplicemente, com'è solito in Italia, scaricare la responsabilità su una terza parte che non è certo opererà per mitigare la vulnerabilità.

Si tratta di un servizio critico, riversare completamente l'onere della sicurezza su un privato terzo privo di qualsiasi responsabilità civile e obbligo di fronte alla cittadinanza è disonesto e non fa altro che mettere in pericolo gli utenti stessi del servizio.

[48656c6c6f20576f726c64]

@ivanvisconti il tuo feedback tecnico è sullo standard Apple/Google, non su Immuni e questo è il repository di Immuni, non di Apple/Google

Lo standard da utilizzare è una scelta di design soggetta allo stesso scrutinio di qualsiasi altra scelta di design. La decisione di utilizzare uno standard non sicuro è stata comunque operata dal team di Immuni, che non può semplicemente, com'è solito in Italia, scaricare la responsabilità su una terza parte che non è certo opererà per mitigare la vulnerabilità.

Si tratta di un servizio critico, riversare completamente l'onere della sicurezza su un privato terzo privo di qualsiasi responsabilità civile e obbligo di fronte alla cittadinanza è disonesto e non fa altro che mettere in pericolo gli utenti stessi del servizio.

Se questo è il pensiero, allora questa issue è completamente inutile. Bisognerebbe aprire una issue sulla scelta dello standard Apple/Google in generale, basata su queste considerazioni. Sono sicuro che in quella issue saprete presentare una soluzione migliore senza utilizzare le nuove API Apple/Google e non vediamo l'ora di analizzarla, perché proprio come dici tu, in Italia spesso chi non fa nulla e non ha idee è semplicemente frustrato e passa il proprio tempo a criticare chi fa qualcosa. Sicuri che tu non sia uno di quelli, siamo impazienti di leggere la tua nuova issue, con relativa proposta di soluzione.