immuni-documentation
immuni-documentation copied to clipboard
immuni-app
deanonimization risks
How does Immuni prevent that the ISP used by the smartphone together with SOGEI (or anyway the institution that controls the backend) easily deanonymize the TEKs uploaded by an infected citizen?
I guess you are trying to say that SOGEI could log the IP submitting some TEKs and by asking the ISP they would be able to track that down to an individual, correct?
I guess you are trying to say that SOGEI could log the IP submitting some TEKs and by asking the ISP they would be able to track that down to an individual, correct?
Correct; the server receiving the upload colluding with the ISP can deanonymize very easily. Nocite that this is a deanonymization attack in addition to the one discussed in issue #27.
This is how the Internet works, you cannot be fully anonymous, even after multiple jump through proxies there will be entities that know your identity.
This is how the Internet works, you cannot be fully anonymous, even after multiple jump through proxies there will be entities that know your identity.
Nobody asked full anonymity or an attempt to overcome impossibility results. We are asking to give proper information and to specify what they mean when claiming that citizens can use the app without the risk of being deanonymized. Moreover in between what Immuni does and full anonymity there could be options and I don't see a reason to ignore them.
Nobody asked full anonymity or an attempt to overcome impossibility results.
and then
...without the risk of being deanonymized.
That's actually the thing, there will always be the risk of being deanonymized. The point should be, what is the probability that all the ISPs and SOGEI and the people from the National Health System collaborate together? and without the knowledge of the public?
it could still be able to link the upload session to the person who was authorised to upload it after having been tested positive.
This is simply wrong, there are well studied cryptographic primitives to tackle this problem by providing anonymous tokens. They are named blind signatures and they are very studied, efficient and known from the eighties. Don't invent impossibility results.
and after all of that they would be able to get 14 days of contacts - not even movements
This is also wrong, you should re-read the previous issues and convince yourself of this.
Moreover in between what Immuni does and full anonymity there could be options and I don't see a reason to ignore them.
Like?
Once the Immuni team confirms that the existence of the problem without any mitigation, then we can discuss about a proper mitigation. An issue does not necessarily come with a fix. Already making clear that there is a problem is significant enough. We could perhaps start asking them to make a FAQ about all possible risks and this FAQ might also be an option accessible from the app so that citizens can be aware of the problems.
I don't see any easy way out here.
You can't mitigate it? ok, good to know.
We could perhaps start asking them to make a FAQ about all possible risks and this FAQ might also be an option accessible from the app so that citizens can be aware of the problems.
That is not the definition of FAQ.
An issue does not necessarily come with a fix. Already making clear that there is a problem is significant enough.
You are using issues just to ask questions, this is not the correct place to do that. If you don't want to discuss solutions or trying to find one, just send an email.
That is not the definition of FAQ.
Definitely +1. This issue is based on the assumption of multiple bad actors being involved in the workflow. To be clear, it's the same kind of bad actors that could hypothetically do anything on a system.
I don't think it's something likely to happen, and there's no point in making the general public freak out by disclosing all the barely-possible, theoretical only attacks. When you step on a plane the crew doesn't welcome you with "Hey, good morning and remember you could die here.".
Remember one of the assumptions in this issue is that you have a bad actor on the backend side. No anonymous token can exist if we assume that who's creating it is also logging the link with your name somewhere.
This is also wrong, I don't think this is the place where I have to fix your misconceptions about what is possible or not using cryptographic primitives. You can read the literature on blind signatures and perhaps understand why you are wrong.
This is issue #82, there are 81 previous issues - would you be so kind to point out what's wrong and which issue explains that?
Issue 12 for example, you can also read subsequent issue 84.
I can work on finding solution and indeed I've done it 2 weeks ago already, see issue #27. I'm still waiting for an answer from the immuni team. I can probably also help here, but first I need the immuni team to confirm that they have this limitation, otherwise there is no point in proposing fixes. I'm not willing to do online teaching about privacy-enhancing cryptography on github (I've limited free time to help others). I recommend you to attend a good Cybersecurity class focusing on that topic.
No one has asked you to teach stuff on GitHub! If you open an issue it means that you want to collaborate within the development of an application. GitHub is not a Q&A platform. You already have all the information that you need to know how the "Immuni" system works, why do you need to waste BS/Sogei/AGID time to answers these questions? Please stop wasting your precious time opening Q&A issues. Do You want answers? Then send an email to "Ministero dell'Innovazione".
Yes, see issue #27. I've proposed a fix. After two weeks there is no feedback from the immuni team. Here I've opened an issue because there is apparently a deanonimization problem but Immuni seems to claim that privacy is preserved. Moreover they do not claim explicitly that there is no privacy in case of such collusion. So I'm asking them how they protect privacy in light of the collusion described in the issue. Depending on the fact that they have or have not a solution and on the pros and cons of their solution (if any) then I can propose proper improvements. At least there will be a direction where to look for. Proposing improvements in all possible directions is a waste of time in general and in particular if they keep being silent as done with issue #27.
As I said, this is not a Q&A platform, the "ISP issue" is already pointed out in #18. So this issue is an unnecessary duplicate.
@FredBonux you have asked questions in this discussion and in other discussions (clearly showing that you did not read well enough the text of the issue). If you want to systematically downplay the issues opened on the design of Immuni you can of course do it. Just I'm not going to devote my precious time to answer to your questions. I advice a class on privacy-enhancing cryptography so that you learn on your own that questions like "what is the probability that all the ISPs and SOGEI and the people from the National Health System collaborate together? and without the knowledge of the public?" are computationally indistinguishable from noise.
I advice a class on privacy-enhancing cryptography so that you learn on your own...
The beauty of an open and civil discussion. Thank you, professor.
PS.: If you don't want to discuss or to answer questions about your issue, GitHub is not for you. A direct email would be more appropriate.
Usually mobile devices haven't a public IP but are behind a NAT
Correct, that's why my issue points out a collusion between ISP (i.e., mobile network operator) and SOGEI server. This makes a gap with issue #18. This is not a duplicate.
Hi @ivanvisconti and thank you for your contribution! Could you please elaborate on how it would work in practice and how it would prevent an IP address metadata leak which is the subject of this discussion? From our understanding of the blind signature suggestions, users would need to be given a message from an Authority and send the message to a signer which may be colluding as well in leaking such metadata. We believe that mixnets or onion routing (TOR) are not currently an option for our mobile app, nor the creation of (hard-to-prove) non-colluding proxies to shelter the IP address. Thanks!
@immuniopensource first of all thank you for answering. Thank you also for admitting that deanonymization is possible in case ISP and SOGEI collude. You should perhaps explicitly mention such risks instead of generically announcing that user privacy is guaranteed. Some citizens are really interested in making sure that their anonymity is preserved, see for instance issue #106 therefore it would be useful to improve the upload procedure. A first suggestion that comes to my mind to reduce such deanonymization risks is the following. Once the OTP has been validated by the health operator, the app should not send the TEKs, but instead it should obtain a blind signature of the TEKs (let's keep for now on the side the possibility of having 1 blind signature for each TEK). The user has now completed the procedure with the assistance of the health operator and can leave the medical lab. The server has no idea about which TEKs have been signed but for sure whoever obtained the signature had a right to get one. Now the user can calmly reach his own favourite and trustworthy internet connection, connect to the WIFI network and with some randomized delay will upload the signed TEKs. Notice that now deanonymization is far more complicated as it would require to corrupt new entities and this is prone to scandals. Technically you should have an option in the app where the user can opt for self-anonymization. When this option is selected then the OTP procedure is performed to get the blind signature and only after that a button "upload TEKs from safe zone" appears. Otherwise the standard procedure without blind signature is executed. Keeping untouched the standard procedure helps in avoiding that naive users get confused.