spying on infected citizens

[ivanvisconti]

Issues #82 and #83 are about threats allowing to link RPIs and then to also associate the name of the citizen to them. RPIs can sniffed by passive (and therefore hard to detect) Bluetooth beacons installed by the government in key locations on the territory (see Paparazzi attack by Serge Vaudenay already discussed in issue #12). Therefore a complete database with names and GPS coordinates of infected citizens passing nearby key locations during the prior two weeks can be constructed by the government that can later on abuse of such data. Moreover the database could be available to external attackers that get somehow access to such systems.
Notice that the "infected" citizens are the ones that would be exposed to such secret surveillance, and they naturally are the ones that are more prone to discrimination. Hoes does the design of Immuni protect the infected citizens from the above risks of secret surveillance?

[FredBonux]

Infected people can choose to upload their codes or not. If you feel threatened by the state you can always choose not to use the app or to upload the codes. Also, storing (and collecting) all that codes just seems unrealistic as to become useful the target must be tested positive and choose to share the codes.

[GennAvi]

So the app can only work if infected users are not worried about their privacy

[ivanvisconti]

answering @FredBonux

Infected people can choose to upload their codes or not.

They should be aware of whether the upload is prone to secret surveillance or not; this is the point of the issue. Citizens are free to take a decision only when they are properly informed.

If you feel threatened by the state you can always choose not to use the app or to upload the codes.

Wrong. The point is that if you don't feel threatened by the state then the centralized solution is better since it's more effective in collecting data and gives more privacy protection against others. There is no point in adopting a decentralized solution and at the same time to trust the state.

Also, storing (and collecting) all that codes just seems unrealistic as to become useful the target must be tested positive and choose to share the codes.

I don't see what is unrealistic in getting sick, being tested positive, and sharing the code following a procedure that according to the marketing is not prone to deanonymization.

[FredBonux]

So the app can only work if infected users are not worried about their privacy

Nope, the app works on trust. Users will be always required to trust the application and the company behind it, and the same thing it's required in a society. You cannot control, check, and approve everything, you have to TRUST. In this case, you have to trust that the National Health workers, Sogei, Bending Spoons doesn't want to create a weapon that the state can use even against themselves.

[FredBonux]

@ivanvisconti

Infected citizen MUST stay at home, what kind of secret surveillance can the state do on infected people?

I don't see what is unrealistic in getting sick, being tested positive, and sharing the code following a procedure that according to the marketing is not prone to deanonymization.

The unrealistic part is when you talk about a state that can deploy that many devices required to track all the citizens, in secret. And also, it must collaborate with ISP or NHS workers in order to connect the codes with a single identity. Do you really think that is possible on such a large scale? without anyone knowing? It sounds a little bit like a conspiracy theory.

Final question, can you please better define the target of this attack? Because to be infected is a requirement, but why the state should want to track infected people that must stay at home?

[ivanvisconti]

@FredBonux you did not understand what I wrote in the issue. Check the text " passing nearby key locations during the prior two weeks ". The word "prior" refers to the already passed weeks. The fact that the infected citizen stays at home in the future is irrelevant. If you want to discuss about tracking infected citizens that might not stay at home you should open another issue. This one opened by me is about something else. Please do not add noise.

[FredBonux]

@ivanvisconti please answer also to the other open points. And define also "key locations". Please realize that there are easier ways to track target citizens, and also you should define the weight of the data that the state could retrieve from this attack. Not all the vulnerabilities are serious ones and need attention, a detailed analysis could help.

Think about this statement:

Hoes does the design of Immuni protect the infected citizens from the above risks of secret surveillance?

"Immuni" architecture is well described in this same repo, could you check how they could improve their architecture in order to tackle this attack instead of just opening issues?

[ivanvisconti]

I've answered enough questions to @FredBonux, and everyone can check the quality of the questions. I need to protect myself from DoS attacks, so I'll not continue and I'll wait for answers from the Immuni team.

[48656c6c6f20576f726c64]

@ivanvisconti ennesima domanda sullo standard Apple/Google, motivo per cui non riceverai mai una risposta, perché non è il team di Immuni che ha scritto lo standard, ma l'ha solo implementato. Se pensi che lo standard definito da Apple/Google abbia delle falle, ti consiglio di contattare direttamente loro.

[ivanvisconti]

@ivanvisconti ennesima domanda sullo standard Apple/Google, motivo per cui non riceverai mai una risposta, perché non è il team di Immuni che ha scritto lo standard, ma l'ha solo implementato. Se pensi che lo standard definito da Apple/Google abbia delle falle, ti consiglio di contattare direttamente loro.

questo è completamente sbagliato e fuorviante, usando Apple/Google si può fare molto meglio infatti sto discutendo anche di problematiche in aggiunta ai limiti dati dall'uso delle API, quindi di problemi introdotti squisitamente dal design di Immuni aggiuntivo a Apple/Google. @48656c6c6f20576f726c64 purtroppo anche in questo caso non capisci, ma questo non significa che debba valere per tutti. Grazie per il consiglio comunque, anche se non richiesto.

[48656c6c6f20576f726c64]

usando Apple/Google si può fare molto meglio

Sono tutto orecchie, illuminami. Per adesso ho solo letto tuoi commenti in cui affermi che lo standard Apple/Google abbia delle falle. Inoltre, quello a cui tu fai riferimento è ben noto ad Apple/Google, infatti se avessi letto la loro documentazione avresti trovato 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]

@48656c6c6f20576f726c64 le API di Apple/Google non impongono il modo con cui si invano i TEKs al server. La modalità con cui lo fa Immuni è una pura scelta del design di Immuni. Studia la documentazione.

[48656c6c6f20576f726c64]

@48656c6c6f20576f726c64 le API di Apple/Google non impongono il modo con cui si invano i TEKs al server. La modalità con cui lo fa Immuni è una pura scelta del design di Immuni. Studia la documentazione.

Se leggessi almeno i riferimenti che pubblichi ti accorgeresti che l'invio delle TEKs al server non è il problema, infatti l'attacco a cui fa riferimento non si basa su una falla del server o della comunicazione app-server, ma si basa sul fatto che da una TEK si può ricavare un RPI. Quindi, il problema di cui parli non dipende da una scelta fatta dal team di Immuni, ma semplicemente dallo standard Apple/Google.

[ivanvisconti]

@48656c6c6f20576f726c64 le API di Apple/Google non impongono il modo con cui si invano i TEKs al server. La modalità con cui lo fa Immuni è una pura scelta del design di Immuni. Studia la documentazione.

Se leggessi almeno i riferimenti che pubblichi ti accorgeresti che l'invio delle TEKs al server non è il problema, infatti l'attacco a cui fa riferimento non si basa su una falla del server o della comunicazione app-server, ma si basa sul fatto che da una TEK si può ricavare un RPI. Quindi, il problema di cui parli non dipende da una scelta fatta dal team di Immuni, ma semplicemente dallo standard Apple/Google.

No, sbagli, infatti usi il singolare per TEK e RPI.

[48656c6c6f20576f726c64]

@48656c6c6f20576f726c64 le API di Apple/Google non impongono il modo con cui si invano i TEKs al server. La modalità con cui lo fa Immuni è una pura scelta del design di Immuni. Studia la documentazione.

Se leggessi almeno i riferimenti che pubblichi ti accorgeresti che l'invio delle TEKs al server non è il problema, infatti l'attacco a cui fa riferimento non si basa su una falla del server o della comunicazione app-server, ma si basa sul fatto che da una TEK si può ricavare un RPI. Quindi, il problema di cui parli non dipende da una scelta fatta dal team di Immuni, ma semplicemente dallo standard Apple/Google.

No, sbagli, infatti usi il singolare per TEK e RPI.

@ivanvisconti, visto che hai dei problemi a capire quello che pubblichi, cerco di spiegartelo, così la prossima volta che parlerai di questo argomento con altri eviterai di fare la pessima figura che stai facendo qui. L'attacco da te indicato si basa su due principi: 1) I RPIs si ricavano dalle TEKs, come indicato nella documentazione ufficiale (https://blog.google/documents/69/Exposure_Notification_-_Cryptography_Specification_v1.2.1.pdf) e sono facilmente reperibili; 2) Le API di Apple/Google hanno bisogno delle TEKs per ricavare i RPIs, come indicato nella documentazione ufficiale (https://static.googleusercontent.com/media/www.google.com/en//covid19/exposurenotifications/pdfs/Android-Exposure-Notification-API-documentation-v1.3.2.pdf). Questi due punti sono pubblici, noti a tutti e sono sufficienti per applicare l'attacco da te indicato. Come puoi notare, questi due punti non hanno niente a che vedere con il metodo utilizzato per inviare le TEKs al server, né fanno riferimento a come vengono memorizzate lato server e sono entrambi definiti nello standard Apple/Google. Qui nessuno sta negando che sia possibile realizzare quell'attacco, il punto è che la vulnerabilità non dipende da nessuna scelta fatta dal team di Immuni (come tu fai intendere), ma dipende solo dallo standard Apple/Google. Capisco che non ti piaccia quello standard e che lo reputi inadeguato e con delle falle, ma non è questa la sede per parlare di quello. Ti rinnovo dunque l'invito a rivolgerti ad Apple/Google (exposure-notifications-feedback@google.com) per far presente questa tipologia di attacco e soprattutto la soluzione da te proposta (anche se in tutti i tuoi post non c'è traccia di questa). Facci sapere cosa ti rispondono, siamo tutti molto curiosi.

[ivanvisconti]

@48656c6c6f20576f726c64 sbagli, le API sono sganciate dalla modalità di invio dei TEKs al backend, quella è una scelta di Immuni.

[48656c6c6f20576f726c64]

@48656c6c6f20576f726c64 sbagli, le API sono sganciate dalla modalità di invio dei TEKs al backend, quella è una scelta di Immuni.

@ivanvisconti se rileggi attentamente il mio post, ti accorgerai che non ho mai messo in relazione le nuove API offerte da Apple/Google con le modalità di invio delle TEKs al server, quindi non so a cosa tu ti stia riferendo. Ti ripeto che l'invio delle TEKs al server è del tutto ininfluente. Sono sufficienti i soli due punti riportati per creare la vulnerabilità ed entrambi i punti dipendono dallo standard Apple/Google e non da Immuni. Comunque, visto che fai difficoltà a comprendere questo ragionamento, proviamo a fare il processo inverso. Proviamo ad analizzare la tua soluzione (che utilizza lo standard Apple/Google in modo corretto), così capiamo se il problema sta solo in Immuni o se sta nello standard Apple/Google.