On April 2020, the PRIVATICS team designed the CNIL-approved ROBERT privacy preserving exposure notification protocol, used by the French StopCovid/TousAntiCovid national app, and available since June 2nd. The PRIVATICS team also designed the DESIRE protocol on May 2020, as an advanced solution.
We followed several key goals with ROBERT:
On April, PRIVATICS proposed a "centralized" approach that later became the foundation of StopCovid/TousAntiCovid. It means:
Being centralized is clearly a plus from an epidemiological viewpoint (real-time monitoring, real-time adjustment to conditions, better statistics), compared to a decentralized scheme like GAEN. This is in line with our Efficiency (Goal #1) and it remains the primary goal of any exposure notification system.
Being sovereign (Goal #2) is the only reasonable approach to keep control of citizen's health data, in a context where Alphabet enters the health insurance business. Being sovereign is also the only reasonable approach to keep control of the technology and minimize dependency on Google and Apple. For instance, CNIL insisted on May that the use of Google Re-Captcha service be removed, which has been done with StopCovid v1.1 en of June.
Being privacy friendly (Goal #3) is no option, and one of the lessons learned is the necessity to ask our CNIL Data Protection Agency as soon as possible. We did it for ROBERT specifications (April CNIL report), the App development (May CNIL report), and now for operational deployment (September CNIL report, and now every 3 months). Thanks to that, we can say ROBERT/StopCovid is GDRP compliant.
DESIRE relies on a radical paradigm shift: rather than using **public device** pseudonyms, it relies on **private encounter** pseudonyms, a 32-byte value that we call PET, for Private Encounter Token. A PET changes across time (every 15 min.) and devices, and is computed in a private manner by the users who met, and only them (e.g., Alice and Bob in the figure), using well-known, robust, Diffie-Hellman crypto.
This paradigm shift changes the situation quite a lot from the security and privacy viewpoints: an eavesdropper who passively listens to Bluetooth (more precisely BLE) traffic is left powerless, because he cannot compute the PET between Alice and Bob, and he'll never be in position to know that a given PET refers to this Alice/Bob encounter that day at that precise time, or to any other encounter, or even that this is a valid PET rather than a random value. A PET is secure by design! (note that in practice two 32-byte PETs are generated per encounter to avoid linkability, see [DESIRE-specs] for more details).
A benefit of DESIRE is that it enables either a centralized (like ROBERT), or decentralized (like GAEN) risk evaluation, or something in-between. And this deployment architectural choice does not impact interoperability: all DESIRE deployments fully interoperate, seamlessly. It means that each country can choose what to do, in a sovereign manner. For instance:
This property matches our fourth goal, be flexible (Goal #4). DESIRE is a unique solution that provides this kind of flexibility, without compromising interoperability. This is also a reason why we call it a "3rd way".
DESIRE is not just a paper work. Thanks to the experience gained with StopCovid development, Inria engineers developed a Kotlin Android smartphone app and a Python emulated server. This work enabled to validate most protocol, cryptographic, BLE considerations, both with the centralized and decentralized modes.
In our opinion, at least two major issues prevent GAEN from being GDPR compliant and mechanically disqualify GAEN.
As long her app just broadcasts pseudonyms, Alice does not risk so much, even if an eavesdropper captures one of them. That's a benefit of data minimization: information remains in Alice's smartphone. But the situation is just opposite if Alice is diagnosed COVID+ and agrees to upload her "diagnosed daily keys" to the national server. Since the database of all the "diagnosed keys" hosted by the national server is freely accessible over the Internet (there is no access control), the previous eavesdropper collects them, computes the associated pseudonyms (each daily key enables to derive all the pseudonyms of that day) and recognizes that of Alice. The eavesdropper knows her health status immediately and very easily!
It is clear that the eavesdropper does not use the official app nor the GAEN software component - they prevent such practices - but a dedicated app specialized in the BLE scan and the processing of GAEN traffic (e.g., derived from corona-sniffer).
This attack (also known as "paparazzi attack"):
Let us be clear: this is not a bug but an unsolved design flaw that:
"Unmasking users by eavesdropping EphIDsBasically, the Swiss Confederation explains that a user who suspects a risk of BLE scan should stop her exposure notification app. Since nobody knows whether or not a BLE scan may occur, it's similar to saying: "don't use the app or use it at your own risks". Of course this warning is hidden in a technical document and never mentioned in the high level web pages and documents for end-users;
[...] it is better to turn [the SwissCovid app] off at home, [...] or when at work if a risk of BLE collectors operated by the employer exists."
Swiss Confederation, "Replay Attacks", June 14th, 2020.
Issue #1 is known by specialists but not by end-users who are left in the illusion that GAEN perfectly protects their personal data. This is another major GDPR compliance issue, since:
We see that although data minimization (the "data remains on the user's phone" argument always put forward by the decentralization supporters) can help, it is not per se necessarily sufficient. In fact, data minimization is a tool and not a goal per se, and the above flaws come from this fundamental misunderstanding.
Yes, ROBERT and DESIRE solve or mitigate these problems :-)
ROBERT being centralized, the eavesdropper cannot access Alice health status with this type of BLE scan attack, since the health status is kept in the server. This is why we chose to be centralized, a choice that CNIL validated.
DESIRE -- in centralized or decentralized mode -- is by-design robust in front of such a passive attack, where the attacker only monitors BLE traffic: there cannot be any such privacy leak.
With DESIRE in decentralized mode, for the attack to succeed, the attacker must be active, sending BLE traffic in order to trigger an encounter with Alice. This is a different attacker model where the eavesdropper is more easily identifiable (he generates BLE traffic). This is one more reason why we believe that even DESIRE-decentralized is better than GAEN.
Anyway, we believe that decentralized schemes should be used in situations where the re-identification risk is less than that of a misuse of data by the data controller. Otherwise the centralized variant should be preferred. DESIRE flexibility makes it possible, without any impact on interoperability across countries. This is a huge step forward.
"In reality, both approaches [centralized and decentralized] have their advantages and disadvantages. Both! But the difference is that one of these approaches is subject to the law and the rule of law. The other approach is that of unregulated private companies whose wealth comes from surveillance capitalism. In fact, I applaud the French government and French elected officials who fought to impose the centralized approach in StopCovid."
Shoshana Zuboff, Prof. at the Harvard Business School.
PRIVATICS Inria team, France.