Tracing infected citizens

[vincenzoiovino]

Hi,

Are you aware of the Paparazzi attack?
See these papers:
https://eprint.iacr.org/2020/399.pdf
https://eprint.iacr.org/2020/493.pdf
https://eprint.iacr.org/2020/531.pdf
and also this recent presentation: https://youtu.be/XVXKLOWxw7c?t=4664
These attacks have been practically implemented and simulated: https://github.com/oseiskar/corona-sniffer
Any attacker with very low capabilities (that is, just placing bluetooth passive sniffers that are very cheap, small and undetectable) can trace infected users and draw on a map all their movements.
This is an high risk for the citizens' privacy as well as for the National security since a foreign country can perform surveillance of targeted people very easily.

Do you have some countermeasures to this attack?
Did you inform the authorities that your system is subject to this attack?

Many more attacks do exist, the documentation has no discussion about them.
Indeed, the documentation is really scarce and "How it works" does not describe technical details, this is not professional, we hope you can give us a White Paper with an analysis.

[agos]

from the linked repository: "any 3rd party who can install a large fleet of BLE-sniffing devices" is not "any attacker with very low capabilities". Can you also clarify how a foreign country could perform surveillance of targeted people "very easily"?

[vodkina]

@agos a labeled BLE sniffing device cost less than 40€ on amazon, and you can find similar tools at discounted price, and it is very very easy to use, so "any attacker with very low capabilities" is totally correct.

[agos]

@vodkina I would argue 16.000 euros (40x400, following the numbers of the example repository) are outside the budget of less determined attackers, but even if we don't count the price as an obstacle the logistics of deploying, powering, and sending/retrieving data to such a fleet surely put this beyond the capabilities of "any attacker". Not saying the underlaying vulnerability is not to be addressed or that this kind of attack cannot happen (especially since OP mentioned state sponsored attacks, as unlikely as they might be), only commenting that this is not within the possibilities of "any attacker with very low capabilities"

[GennAvi]

Note that even in a centralized systems in which the identifiers are generated by a single server, who therefore knows the identifiers of all the users, the owner of the server still needs to detect those identifiers over the territory in order to have an actual tracing of users'movements.
So if this is deemed as not acceptable, I wonder why enabling tracing to everyone with enough resources (even if he does not collude with the server), is acceptable.
Is that because the tracing is limited in time? (This is only a mitigation and having multiple secret keys does not solve the attack wrt a malicious server, especially when using a naive authorization mechanism ).
Is it because only infected users are exposed?
I thought that minorities are the ones to protect. I don't think the privacy of infected users is less important only because they are (hopefully) a small fraction of the population, do you?
Finally, a practical example of easy deployability is this: consider a big corporation which owns many properties (e.g. restaurants, shops, supermarkets). They could easily deploy this attack without being detected thus tracing customers, or even passing-by users, without their consent.

[Shamar]

I guess there are thousands of such kind of potential attackers in Italy.

For example, any criminal organization that already does extortion like pizzo could easily invest 16.000€ to deploy such devices into large cities. Being able to identify infects, their relatives and their contacts could be incredibly valuable for them, enabling several kind of extortion.

So this kind of attacks is not "unlikely" at all.

[agos]

@GennAvi I appreciate your reframing of the scale of the problem from "any attacker with very low capabilities" to "big corporations".

Please don't mischaracterise my comments. I don't think that tracing everyone or affected people is acceptable. My comments were about the ease with which such attacks could be implemented in reality, because I felt characterising it as very easy is incorrect. I'll repeat: I'm not saying the underlaying vulnerability is not to be addressed or that this kind of attack cannot happen, just that it won't be "any attacker".

Returning to the issue at hand, I feel this should be better directed at the DP-3T project (see, for example, this issue, and this issue regarding collusion with HA) or at Apple / Google security programs, as I feel that there is very little chance that there will be possible solutions at app level, given that apps are thin wrappers around the proximity tracing SDKs.

[GennAvi]

I did not reframe anything, it was just another example. For me it is terrifying but some people are ok with it, it's a matter of taste. I think that providing other practical examples is pretty useless, you can imagine smaller scale attacks, coalitions of people coordinating to perform this attack and so on. Security by alleged difficulty is very bad...
The point is that so much information is leaked in a non detectable way and this is not unavoidable. Regarding the fact that the team wants to rely on the Gapple API, I can understand the technical problems involved (mac address and so on).
But who better than a team which is in charge to develop the official governmental app can put pressure on Google/Apple to ask for something better? It is not mandatory to passively accept this imposition, all the teams accross the nations could cooperate and ask for something better, they have leverage. Myself as a regular individual instead, not that much.

[vincenzoiovino]

@vodkina I would argue 16.000 euros (40x400, following the numbers of the example repository) are outside the budget of less determined attackers, but even if we don't count the price as an obstacle the logistics of deploying, powering, and sending/retrieving data to such a fleet surely put this beyond the capabilities of "any attacker". Not saying the underlaying vulnerability is not to be addressed or that this kind of attack cannot happen (especially since OP mentioned state sponsored attacks, as unlikely as they might be), only commenting that this is not within the possibilities of "any attacker with very low capabilities"

40 euro is a very high price :-) There are phones with BLE for 50 dollars, would it mean that almost all the cost of such phones come from BLE chipset? Unbelieavable. I would give later a more precise cost of how much a BLE passive device costs. I have for example a BL token that I paid in a Chinese shop 6€, I am not sure whether it is also BLE but I guess BLE is part of BL >4.0 (?).

[vincenzoiovino]

@GennAvi I appreciate your reframing of the scale of the problem from "any attacker with very low capabilities" to "big corporations".

Please don't mischaracterise my comments. I don't think that tracing everyone or affected people is acceptable. My comments were about the ease with which such attacks could be implemented in reality, because I felt characterising it as very easy is incorrect. I'll repeat: I'm not saying the underlaying vulnerability is not to be addressed or that this kind of attack cannot happen, just that it won't be "any attacker".

Returning to the issue at hand, I feel this should be better directed at the DP-3T project (see, for example, this issue, and this issue regarding collusion with HA) or at Apple / Google security programs, as I feel that there is very little chance that there will be possible solutions at app level, given that apps are thin wrappers around the proximity tracing SDKs.

I do not agree. The tracing capabilities is function of the economic capability.There are for instance about 30 metro stations in Rome (Line A?).
A teenager can afford the cost of placing a BLE sniffer near the main entrance of each metro station.
The point is that:
1 each device has a very low cost (I will attempt to give more precise costs later or in next days).
2. They are small and go undetected (you can pose for instance in a vase...).
3. the software for handling them is very simple and is ALREADY available

[vincenzoiovino]

Hello,
With the help of a friend of mine knowledgeable in the field I attempted to make an analysis of the cost of producing a passive BLE sniffer. Sorry if it is imprecise, you can help us to do a better analysis.

There are commercially available BLE chips at low cost.
I mention one in particular: ESP32 WROOM which is certified BLE 5.0:
https://www.espressif.com/en/news/BLE_5.0_Certification

The chip is already complete with a built-in BLE antenna that can both transmit and receive (in our case it will be used simply for listening) and it is also endowed with an MCU on board, even programmable with Arduino!
Building a complete sniffing system with this device is quite simple and not expensive at all.
Here there is a link to the costs of the above BLE chipset:
https://www.mouser.it/ProductDetail/Espressif-Systems/ESP32-WROOM-32?qs=chTDxNqvsyltcwz%2FUUJDtQ==&gclid=Cj0KCQjw-_j1BRDkARIsAJcfmTEbUTzn4DM7jHoq8pcjbprFKYnKZNT4QU2npjkCd48817YsAvhbqG8aAqI7EALw_wcB

The price is 3€ (THREE EURO) per single chip (notice that the website seems only to ship in units of 500 but the cost per single chip is 3 euro!!!). You can likley find better prices elsewhere.

There are also others kind of devices like this one with an arm cpu on board that costs 1,31€ (ONE EURO) each if shipped in units of 4000:
https://www.mouser.it/ProductDetail/Nordic-Semiconductor/nRF52810-QCAA-R?qs=sGAEpiMZZMve4%2FbfQkoj%252BCQPD4Du2PUca%2FjG%252BiVk5To%3D

One of these simple chips has to be combined with an RTC (real time clock) chip whose cost ranges from 0.60 euros cents to 3 euros (to associate listened beacons with a time).
Finally you have to add an SD storage that has a very low cost (you need high storage only if you are lazy and you can go to download the listened beacons not very frequently).
Everything would have the size of a KEYCHAIN.
The system would be fully programmable with the use of a PC and a development kit (here on GITHUB there are bunches of working examples and libraries in this regard).

The above costs are a very generous UPPER BOUND since the above chips have also many other features that are not needed.
So producing a BLE sniffer to trace infected users in Immuni app should have a very low production cost.
Sorry if the above analysis is inaccurate.

[blaispe]

Hello,
With the help of a friend of mine knowledgeable in the field I attempted to make an analysis of the cost of producing a passive BLE sniffer. Sorry if it is imprecise, you can help us to do a better analysis.

There are commercially available BLE chips at low cost.
I mention one in particular: ESP32 WROOM which is certified BLE 5.0:
https://www.espressif.com/en/news/BLE_5.0_Certification

The chip is already complete with a built-in BLE antenna that can both transmit and receive (in our case it will be used simply for listening) and it is also endowed with an MCU on board, even programmable with Arduino!
Building a complete sniffing system with this device is quite simple and not expensive at all.
Here there is a link to the costs of the above BLE chipset:
https://www.mouser.it/ProductDetail/Espressif-Systems/ESP32-WROOM-32?qs=chTDxNqvsyltcwz%2FUUJDtQ==&gclid=Cj0KCQjw-_j1BRDkARIsAJcfmTEbUTzn4DM7jHoq8pcjbprFKYnKZNT4QU2npjkCd48817YsAvhbqG8aAqI7EALw_wcB

The price is 3€ (THREE EURO) per single chip (notice that the website seems only to ship in units of 500 but the cost per single chip is 3 euro!!!). You can likley find better prices elsewhere.

There are also others kind of devices like this one with an arm cpu on board that costs 1,31€ (ONE EURO) each if shipped in units of 4000:
https://www.mouser.it/ProductDetail/Nordic-Semiconductor/nRF52810-QCAA-R?qs=sGAEpiMZZMve4%2FbfQkoj%252BCQPD4Du2PUca%2FjG%252BiVk5To%3D

One of these simple chips has to be combined with an RTC (real time clock) chip whose cost ranges from 0.60 euros cents to 3 euros (to associate listened beacons with a time).
Finally you have to add an SD storage that has a very low cost (you need high storage only if you are lazy and you can go to download the listened beacons not very frequently).
Everything would have the size of a KEYCHAIN.
The system would be fully programmable with the use of a PC and a development kit (here on GITHUB there are bunches of working examples and libraries in this regard).

The above costs are a very generous UPPER BOUND since the above chips have also many other features that are not needed.
So producing a BLE sniffer to trace infected users in Immuni app should have a very low production cost.
Sorry if the above analysis is inaccurate.

I do agree with the analysis. I am able to assemble in my lab such a low cost device. Contact me in private if you need 🙂
Regards

[francescotonini]

I think it is crucial to address those concerns. It would be a good idea to discuss it directly with the DP-3T project, since Immuni and all other apps that will use the A/G framework are just "customers" of those API.

[GennAvi]

Attempts to address these concern reaching out DP3T team have failed many times. Even when the attempts were made by respected scientists who have been producing high-impact research for years. It is clear that for them there isn't anything beyond DP3T itself. They have systematically downplayed these risks of which they are aware of from at least 6 weeks.
For many it is just okay to leave room to these attacks. Even some professors are claiming to the media that everything is just fine and that there are no concerns.
I am putting my two cents on who is in charge of deploying the applications. They have the opportunity to understand how real and big are these risks and use their leverage to push A/G for more flexibility in the API so they can start building a more privacy-aware solution by cooperating with the community. Bending Spoons team members put a great responsability over their shoulders and I appreciate it. The company will be always linked to this application and I know this is a great burden.
So take time to thouroughly think about all the issues that appeared and will appear here.

[ivanvisconti]

@GennAvi I appreciate your reframing of the scale of the problem from "any attacker with very low capabilities" to "big corporations".

Please don't mischaracterise my comments. I don't think that tracing everyone or affected people is acceptable. My comments were about the ease with which such attacks could be implemented in reality, because I felt characterising it as very easy is incorrect. I'll repeat: I'm not saying the underlaying vulnerability is not to be addressed or that this kind of attack cannot happen, just that it won't be "any attacker".

Returning to the issue at hand, I feel this should be better directed at the DP-3T project (see, for example, this issue, and this issue regarding collusion with HA) or at Apple / Google security programs, as I feel that there is very little chance that there will be possible solutions at app level, given that apps are thin wrappers around the proximity tracing SDKs.

@agos when Immuni applied to the call of the ministry there was no Apple-Google API yet, and still Immuni was claiming to be a privacy-preserving solution to contact tracing. So why are you now saying that the privacy limitations of Immuni are a consequence of Apple-Google API? Why doesn't Immuni realize the system that they had in mind originally? I don't want to be polemic, I'm really interested in understanding more about the process, to then appreciate more your answer that seems to push responsibility of the privacy issues towards Apple and Google. Thanks.

[48656c6c6f20576f726c64]

@vincenzoiovino , Immuni non si occupa della comunicazione Bluetooth. Tutta quella parte, come scritto ovunque e ribadito più volte, è completamente gestita dalle API di Apple/Google. Le specifiche Bluetooth di Apple/Google sono pubbliche (https://blog.google/documents/70/Exposure_Notification_-_Bluetooth_Specification_v1.2.2.pdf), quindi non capisco il senso della tua domanda qui. Se non hai compreso le specifiche Bluetooth di Apple/Google dovresti chiedere a loro, non a chi ha realizzato Immuni.

[ivanvisconti]

@48656c6c6f20576f726c64 quando Immuni ha inviato la proposta dell'app le API non esistevano, rimandare quindi genericamente il problema alle API è una risposta insufficiente.

[48656c6c6f20576f726c64]

@ivanvisconti questo non è un comitato per decidere quale framework utilizzare (quello è stato già fatto e l'argomento è chiuso), siamo qui per valutare come il team di Immuni abbia implementato lo standard Apple/Google, quindi cerchiamo di mantere il focus su quello in modo da offrire feedback utili.

[Shamar]

siamo qui per valutare come il team di Immuni abbia implementato lo standard Apple/Google

Sei molto confuso @48656c6c6f20576f726c64: il team di Immuni non ha implementato lo standard Apple/Google. Semplicemente perché lo hanno già implementato Apple e Google.

Se il tuo scopo qui è "offrire feedback utili", forse dovresti studiare un minimo la materia.

[48656c6c6f20576f726c64]

@Shamar probabilmente non conosci la differenza tra la parola "definire" e la parola "implementare". Prima di studiare la materia forse dovresti studiare l'italiano.