DP-3T / documents

Decentralized Privacy-Preserving Proximity Tracing -- Documents
2.25k stars 180 forks source link

Deanonimization of reported users #100

Open vaudenay opened 4 years ago

vaudenay commented 4 years ago

Upon the request by my colleagues, I made this report public: https://eprint.iacr.org/2020/399

Enriched app could collect more data. Militia could share collected data.

a8x9 commented 4 years ago

Thanks a lot for making this report public.

I think my proposal in #66 would solve most of these problems, without needing an interactive protocol between each pair of users.

In summary: EphIDs are replaced with EC public keys, each user does an ECDH key exchange between the private key corresponding to their currently broadcasted public key and all observer public keys broadcasted by other users. As long as we assume that proximity contacts are reciprocal, users now have a shared secret which cannot be linked back to what they broadcast. In case of infection, they publish all these shared secrets.

It would not solve the Nerd attack where an attacker measuring signal strength could link different EphIDs to the same user. But if these IDs cannot be linked back to the data published in case of infection, it would greatly limit the privacy impact of this attack.

jasisz commented 4 years ago

An interesting read!

But to be fair some of the points seems to be solved by the updated design on DP-3T side (especially a second cuckoo filter proposition, but also update to the original one):

Others apply in the same way to basically any design based on Bluettoth, especially a centralized one:

vaudenay commented 4 years ago

I'm not sure Design 2 mitigates those attacks. Given the Cuckoo filter from the server, anyone can bruteforce all collected (EphID,t). If the smartphone can do it with the pairs it collected, this can be done at a wider scale (such as the #121 case) with a cluster. The only privacy advantage is that the user has a fine grained control on what he reveals.