Limit fake contact event attacks by using shared hashed "handshake"

[gagarine]

To limit fake contact event attacks we can rely on shared information between the two devices Instead of storing EphID.

We can do it like that:

1. Generate a random id RiD1 every X hour
2. Broadcast this RiD1
3. When detecting another device RiD2 store an EventHash = CHF(Sort(RiD2,RiD1), date(Year,Month,Day). Where CHF is a cryptographic hash function such as SHA2 and Sort just sort the _RiDs so they are in a predictable order. We also add the current day so we create one event by day.
4. The other devices generate and store the same EventHash

In case of infection

1. Publish all recent EventHash
2. All devices check if they have this EventHash stored

Security problem
Someone can get my RiDx and broadcast it. But it will have to do that physically at ~2m of each person.

[jasisz]

Publishing something else than private key of infected person is generally a good idea, I believe that EphIDs of ones at risk should be published instead, as in #14
But I see couple of problems with what you propose:

1. Number of published items and size of it (even if we use Bloom filter or anything else) grows significantly.
2. Encounter is not always a symmetric event. I can imagine multiple scenarios in which I've seen your RiD, but you haven't seen mine and the other way around.
3. How does it limit fake contact events attacks? I can still spoof any number of made-up encounters only if I know some RiDs. I see no much benefit of doing it compared to publishing EphIDs of those infected person encountered.

[gagarine]

Thanks for #14.

1. Yes. Perhaps you can't download it all anymore. You square the amount of data I guess.
2. I think enforcing symmetry brings a benefit: That would limit large scale fake contact event attacks based on Bluetooth amplifier able to reach a much higher radius.
3. You can not prevent it. But this limit one kind of attack (2).

[kennypaterson]

Thanks for suggesting this. We have considered this design internally, and it is currently not in our proposal because of the increased bandwidth consumption that it would entail. We continue to hold it on our list of possible-but-not-adopted approaches.

[gagarine]

What kind of bandwidth consumption are we talking about?

Are we sure we need to download all the data for every client?