Open LCBH opened 4 years ago
Good point! I don't think this is fixed in the rewritten implementation, although we tried to be much more careful with how batches of keys are released, this boundary condition is still present.
I believe the fix would be to delay releasing a batch of keys by a few minutes. So they keys that are valid up to 16:00h would be released at 16:10h for example. Then even if Alice's clock is 10 minutes slow, she will receive all adversarially broadcasted EphIDs after 16:00h and will therefore not consider them.
Does this work?
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
withLoCostDP3T.py
in the same folder. Here is the output that should be self-explanatory: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.