dp-3t / reference_implementation Goto Github PK

Very nice code!

Epoch length is 15min.
Contact threshold is 2min.
(I assume the beacon frequency is 1-10Hz so very frequent compared to the above.)

If there is a contact during (4min - 2epsilon) starting at (end_of_epoch - 2min + epsilon), then this contact will not be registered because the EphID rotates and each EphID is met during less than 2min.

If we want to report for sure contacts longer than 2min, we should set the threshold to 1min.

The stored duration of an EphID contact is in seconds. It is between 2min and 15min. It may be underestimated by 2min.

Considering the 'unlinkable' design reference implementation does not provide a trusted and deterministic implementation of a cuckoo filter

I'm opening this issue to ask for any pointers anyone here may have about reliable C implementations, possibly linked to academic papers.

On Github there are a couple repos worth looking:

• https://github.com/efficient/cuckoofilter (C++)
• https://github.com/begeekmyfriend/CuckooFilter (C)

Anything else? do we need to code one from scratch?

Once #12 has been fixed (see PR #13), the reference implementation (and the specification from the white paper) suffers from a different attack when phones' clocks are not perfectly synchronized.

An attacker can then trigger a false positive in a target phone's victim by broadcasting some EphID he has computed himself from infected SKs. This timing of the different actions is really important, which makes it hard to carry it out. But I guess an attacker could retry until this works. I don't know exactly how to assess the practical implication of this attack.

Details are in the PoC you can find there: https://github.com/LCBH/reference_implementation/blob/PoC_desynch/testAttack.py
Just type python3 testAttack.py with LoCostDP3T.py in the same folder. Here is the output that should be self-explanatory:

Current time: 2020-04-01 00:00:01.
Day 0: Alice, Bob, and Isidor do not have contact. Isidor SK: [ce5fd1a1...]. Current Isidor's date: [2020-04-01 00:00:01].
   + New day for Isidor
   + New day for Alice
Day 1: Alice, Bob, and Isidor do not have contact. Isidor SK: [568d5efa...]. Current Isidor's date: [2020-04-02 00:00:01].
   + New day for Isidor
   + New day for Alice
Day 2: Alice, Bob, and Isidor do not have contact. Isidor SK: [00bb2c63...]. Current Isidor's date: [2020-04-03 00:00:01].
   + New day for Isidor
   + New day for Alice
Day 3: Alice, Bob, and Isidor do not have contact. Isidor SK: [6150c529...]. Current Isidor's date: [2020-04-04 00:00:01].
   + New day for Isidor
   + New day for Alice

Day 4: Isidor is tested positive and publish SK_t[day-2]=[00bb2c63...] with infectious time=[2020-04-03 00:00:01]. Current SK is [9a30016a...]. So far, not a single entity has received an EphID. Current Isidor's date: [2020-04-05 00:00:01].

 --> Step 1. Attacker fetches Isidor's infected SK_t at time [2020-04-05 00:00:01] and compute a valid EphID corresponding to time [2020-04-04 23:59:59].
     Fake EphID: [c293f5fc...] for SK=[6150c529...].

 --> Step 2. Alice's internal clock is 2 minutes ahead of time [2020-04-04 23:57:49] and receives the fake EphID multiple times.

 --> Step 3. After a while (next day, but it does not really matter), Alice checks if she is at risk. She is not but DP-3T concludes that she is:
   + New day for Isidor
   + New day for Alice
At risk, observed c293f5fcdacb77c3b8e62a4f4003a225 on day (2020-04-05)-1 day(s) for 126 seconds

It seems that a more conservative choice of the time window for which EphIDs have to be computed could be necessary (in the specification). The current check consider a fixed window (instead of a moving window), which makes it discontinuous, hence the attack.

receive_scans takes a mutable default argument beacons. Any changes to mutable default arguments persist, thus might result in unintended side-effects. See more here. receive_scans does not mutate the beacons list, but the problem can appear due to code of a user of the class.

Additionally, now == None comparison is not recommended. However, this could cause a problem only if now variable is of custom class.

The broadcast key in this repo has a capital B on the front, and the one in the app has a lower case b:

https://github.com/DP-3T/reference_implementation/blob/master/LowCostDP3T.py#L29
https://github.com/DP-3T/dp3t-sdk-android/blob/develop/dp3t-sdk/sdk/src/main/java/org/dpppt/android/sdk/internal/crypto/CryptoModule.java#L44

Hi,

I know this is just an example and will probably not be used in the future, but anyway I point out what I suppose are two typos in the code of example_run.py:

I think that in line 57 it should be [alice_ephID] instead of [bob_ephID]

Likewise in lines 75,76,78,79 I suppose Bob and Isidor should only receive the ephimeral ID's of each other and not the whole list beacons, am I right?
(As far as I understand the protocol, I guess Isidor does not get the beacon Alice sent to Bob before, even though Isidor is meeting Bob)

Unable to run example_run.py

Because of

This is for a good understanding of both algorithms ans make easy to compare
A Python code is needed.

ThankYou

Here a small list of things that would be nice:

• unit testing to make sure the edge-cases are correctly done (see #1)
• example data for people implementing libraries
• definition of the client/server API