Misscalculation of storage and download amount? about documents HOT 11 CLOSED

Only one key is needed. We'll phrase it more explicitly in the next version.
If you look at the whitepaper (first revision), page 7, you can see that:

• The keys are hashed forward: for day t, sk_t = hash(sk_{t-1})
• The paragraph lower on the same page states:
  "Once the health authority triggers proximity tracing for an individual (Figure PT, step 1), the patient instructs their phone to send to the backend the key ​SK_​t corresponding to the first day in which the app user was considered to be infectious (Figure PT, step 2). Note that given the key ​SK​t​, everyone can compute all ephemeral identifiers ​EphID used by the infected patient starting from epoch ​t by repeating the process described in “EphID generation” above."

Thus, we send only the sk_t from, for example, 14 days ago; from this, the next day keys can be computed.

from documents.

The central system doesn't need to store the time period of every sk. It just need 14 partitions to store it.

Also, the white paper doesn't propose to download the 14 days every day. The device only need to download one day of data once a day. (I guess that if the app miss one, it can still download the one of the previous day).

from documents.

Does that mean that if one infected users SK_t is published and I received multiple EphIDs of that user, I knew those EphIDs would belong together? That makes the protocol susceptible to an attack where you place BLE sniffers in multiple places and can thus deanonymize infected users

from documents.

@cascremers that part is unfortunately really not so well described in the white paper. At least you can read over it very fast. Now the calculation of the amount of data makes more sense.

But on this point the system is also vulnerable. If a malicious client logs the EphID and timestamp or, as described in the paper, distributes beacons, the attacker can trace each EphID back to exactly one person. He only needs one EphID in the time period that is not anonymous and even gets a motion profile. This is the reason why we have rejected this approach for the time being.

How do you see this attack scenario?

from documents.

If you set up multiple BLE "Scanners" and log people at cash registers etc. and then join this data together, you could possibly recreate 2 Days of a Person that got infected from the Points you recorded. So theoretically (if no one is getting COVID19 again) every App user will only ever share 2 Days of ID's.

Note:
Same attack scenario is possible if you dont share your Key but notify all collected Ids within this period. The BLE "Scanners" would need to generate a ID "specially" for each victim and then map those if someone gets infected (-> hope that all notifications appear at the same time).

PS: I am assuming that the SK is from 2 Days prior to Notification is sent out.

from documents.

@kreativmonkey I thnik I also tackle both those issues in #14 and the #13

from documents.

@kreativmonkey Maybe you want to split out your second question to a new issue, since I think the original question has been resolved, am I correct? This would help people understand that the titular issue is resolved, and if your second question is still open, will help people to find it.

from documents.

These hash iteration designs are less future proof than a tree-like hash ratchet: TCNCoalition/TCN#40

We've some fixed depth d such that 2^d gives the epoch length. All clients select an initial sk_0 and then compute:

(sk_{2i}, sk_{2i+1} ← H_cek(cek_i).
ephid_i = sk_{2^d+i}

In such designs, the client can reveal whatever subtrees it likes, which correspond to consecutive ephids.

I doubt this buys much privacy so we should just handle all ephids separately as if they were separate true random numbers, and never reveal any sk_i to anyone, but doing the hashing this way buys flexibility.

from documents.

Hi all, thank you for your inputs. It seems the original question has been answered and the following discussions are treated in other issues (@burdges if this is not the case please correct me). I'll close the issue soon.

from documents.

Afaik, we never discussed the tree-like ratchet from TCNCoalition/TCN#40 anywhere else here, but that's not really the topic in this issue, so close this one. :)

As I said, I doubt hash ratchets fit this problem anyways because contact tracing just fails outright if you've too many ephids to upload separately, but.. If you want a hash ratchet, then you should consider the tree-like hash ratchet.

from documents.

The CEN protocol is very cool with respect to this, as you say the question mark is in the size of the upload.
Regarding the issue, we're trying to close some of them to avoid drowning, I'll do so and we'll reopen upon further input then :) thanks for your help & feedback!

from documents.