Difference with Apple/Google solution

[vaudenay]

I received questions about comparing DP3T with the Apple/Google solution (accessed on April 11, 2020). I'm posting it here.

The difference is with the key hierarchy. We have the following mapping: SK_0 <-> tracing_key (tk) SK_t <-> daily_tracing_key/diagnosis_key (dtk) EphID_i <-> rolling_proximity_identifier (rpi) The difference is how the keys depend on each other.

Difference about the tk-to-dtk (SK-to-SK) derivation:

In DP3T: The next dtk is the hash of the previous one. The tk is erased from memory. Once a user is diagnosed, tk is renewed. Advantage: in a coercion attack, we cannot go in the far past. Only the last 14 days. Drawback: a diagnosis key for day t can derive the diagnosis key for the next days until the diagnosed user renewed his tk.

In Apple/Google: Each dtk is derived from tk. Advantage: users can selectively reveal diagnosis keys. Drawback: coercion discloses tk, hence all dtk.

Difference about the dtk-to-rpi (SK-to-EphID) derivation:

In DP3T: The rpi are random permutations of keys derived from dtk. The receiving app keeps the rpi with the current coarse time (or hash of it). Advantage: more privacy due to no precise time storage. Drawback: replay attacks are easier due to longer validity period.

In Apple/Google: The rpi is derived from dtk and time. The receiving app keeps the rpi with the current time. Reception time can be verified at matching: Here is a quote: "Additional validation can be used to confirm that the advertising happened in a time window comparable to the one expected based on the TimeIntervalNumber." https://covid19-static.cdn-apple.com/applications/covid19/current/static/contact-tracing/pdf/ContactTracing-CryptographySpecification.pdf Advantage: (if done) replay attacks are somehow mitigated. Drawback: less privacy (like the nerd attack).

Note: Replay attacks with a narrow validity period can still be done at a wider scale by corrupting the clock of the receiving device. Usually, the clock is based on unreliable information given by the network. (See issue #99.)

[eknoes]

I just tried to get a better overview of both protocols and started to write a small side-by-side comparison, maybe it helps: https://eknoes.de/posts/covid19-apple-google-dp3t-comparison/

[kugelfish42]

Is there something in either design 1 or 2 that humanity would be gravely missing out on if the Apple/Google proposal were to become the de-facto industry standard for the low-level Bluetooth based contact tracing protocol?

[vaudenay]

I would say design 2's way to generate dtk (seed_t) is superior, in terms of privacy than in Apple/Google. In coercion attacks, reveling tk is terrible. Could it be what humanity desperately need?

Conversely, the binding of rpi to time is bringing something in Apple/Google (for #99).

IMHO the cuckoo filter is barely doing anything for privacy and security.

[vaudenay]

One tribune against Apple/Google app (which should apply to DP3T too): https://blog.xot.nl/2020/04/11/stop-the-apple-and-google-contact-tracing-platform-or-be-ready-to-ditch-your-smartphone/

[mvalla]

Remember Apple and Google do not need to enable contact tracing to know where we are and who we meet. They already know because already at operating system level have GPS locations tracing updated centrally, to personalize browsing, maps, intelligent assistants etc. Of course people can opt-out from GPS locations tracing; similarly people will be able to opt-out from Google+Apple contact tracing.

[gardners]

This actually speaks to the untrustable of modern complex systems. If we want trustable privacy-preserving mobile devices, we need a substantial rethink, e.g., as we discussed at 36C3 and CCC Camp:

https://media.ccc.de/v/36c3-10800-creating_resilient_and_sustainable_mobile_phones

https://media.ccc.de/v/Camp2019-10378-fully_open_fully_sovereign_mobile_devices

I'm not claiming that our approach is the best or only solution, and there are a few other projects looking at angles of this problem, e.g.,

https://betrusted.io/

But whatever the solution space looks like, need to think about how to change the hardware domain to be more privacy preserving. Responding to one existential threat to hard-won democratic freedoms should not create others.

Paul.

On Sun, 12 Apr 2020 at 04:35, M Valla notifications@github.com wrote:

Remember Apple and Google do not need to enable contact tracing to know where we are and who we meet. They already know because already at operating system level have GPS locations recorded centrally all the time, to promise browsing, intelligent assistants etc.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/DP-3T/documents/issues/128#issuecomment-612492210, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFCOT27BBM45G3NIUN4CVTRMC5RDANCNFSM4MF5AQSA .

[kugelfish42]

The Apple/Google solution would be strong tail-wind and endorsement for the distributed contract tracing approach. All the work, analysis and discussions here seem to indicate that Bluetooth proximity based contact tracing is at best flawed - technically and from a privacy & security point of view. We would probably not entertain endorsing something like this in less desperate times. The all important meta-question is whether the benefits will outweigh the costs and whether this is near the optimal trade-off we can come up with?

In their whitepaper (https://bluetrace.io/static/bluetrace_whitepaper-938063656596c104632def383eb33b3c.pdf), the Bluetrace team (who presumably has some actual operational experience with BT supported contact tracing) makes a pretty strong case on why contact tracing should remain centralized and human-in-the-loop, where technology should only be one piece in the puzzle of the investigative work. It might be that effective contact tracing is inherently privacy invasive - like a colonoscopy or an interrogation by the criminal police. In this case, the key to protecting privacy as much as possible would be in the operational processes, the governance and oversight of the authorities tasked with conducting it.

Or in other words, are we dismissing more centralized approaches too quickly?

[timoll]

I think it is possible to keep the decentralised system while getting a human contact tracer into the loop. However, the timestamps would need to be more accurate. A human contact tracer could assign a risk score for all rpis based on the memory of the infected person.

The app would need to save not only close contacts, but also a bit less close contact should that rpi be considered higher risk.

Adoption is key. Even if the decentralized version is a bit less effective, it can make up for it with higher participation.

[ijansch]

The original comparison in this issue is outdated since GACT’s 1.1 version, which mentions “Temporary Exposure Keys (previously known as Daily Tracing Keys) are now randomly generated and no longer derived.”