DP3TCryptoModule.checkContacts is not conform to the specification and exposes users to malicious false positives about dp3t-sdk-ios HOT 9 CLOSED

Adding some findings to this issue:

The problem lays wih the fact that when a SecretKey is published to the server, it is then public.
Some malicious user could then forge EphIDs for that day, impersonating the infectious person during the rest of the day and potentially create a lot of false positives.

To cover this particular case, the Whitepaper states (page 11):

Each smartphone uses this pair to reconstruct the list of EphIDs of an infected
person for each day t’ and checks if it has observed any of these EphIDs on day t’ in the
past (i.e., before the corresponding key SKt was published)

To comply to the above, I beleive the code in:

should first compute midnight UTC (start of the day) for the bucketDate and then iterate from the onset Date up to (but not equal) bucketDate midnight UTC.

from dp3t-sdk-ios.

Looks like a design issue: DP-3T/documents#182

from dp3t-sdk-ios.

Actually the implementation is more fine grained than a full day as described in the whitepaper.
Newly released Secret Keys are published on a 2 (configurable?) hours batch window.
This information is carried via the BucketDate/knownCase.batchTimestamp when fetched by the device application.

Commit 4e18a17#diff-74ac763fc3f0d793c601660e3bcd6041 has added an explicit check to consider only the contacts seen up to the publication time.

Which should clear the above mentioned threat

from dp3t-sdk-ios.

Thanks for pointing this commit out. Unfortunately, I don't think the commit solves the issue. Based on the new contacts list considered for a match:

it seems that the same attack works if the "injection" of the forged EphID happens in the same time window as the one corresponding to the batch of the infected SK key (you said "2 (configurable?) hours").

from dp3t-sdk-ios.

My observations are the following:

• The device store contacts with a fine grained timestamp
• The server publishes Infectious key on a 2 hours batch basis (aka bucket)
• When a Secret Key is sent to the server, the server makes it available to the world in the next bucket
• The device compare contacts up to the time the SecretKey was made available to the world

So if one forged EphIDs with that newly published Secret Key, and broadcast it around, it should be filtered out by the receiving device

from dp3t-sdk-ios.

Let's make some examples.

• at "2020-05-11 02:00" the server publishes the secret key in the "2020-05-11 00:00" bucket
• malicious app generates and distributes EphIDs for the "2020-05-11 02:00-04:00" period
• at "2020-05-11 04:00" all apps will start matching local EphIDs for the "2020-05-11 02:00-04:00" period to EphId generated from the secret keys in the "2020-05-11 00:00" bucket
• since the condition is bucketDate >= contact.date, getDate("2020-05-11 00:00") is equal to getDate("2020-05-11 02:00-04:00"), so the contact alert is shown

from dp3t-sdk-ios.

A secret key will get published at the end of the bucket period. So if you publish your key at 02:00 the key will appear at 04:00 and not at 00:00.

from dp3t-sdk-ios.

@stmitt Does it matter? It appears at the same day. The code only checks the day, not the time. There's still plenty of time from the 04:00 till the 23:59 when malicious actor can distribute fraudulent EthIDs

from dp3t-sdk-ios.

We recently undertook a massive refactoring to integrate Apple's official ExposureNotification framework in favour of our custom Bluetooth and Key-generation implementation. Going forward, we will only support the official Apple framework that handles all bluetooth communication. Please update to the latest SDK version and subscribe to the notifications so you keep up to date with the latest changes.

from dp3t-sdk-ios.