France’s Inria and Germany’s Fraunhofer detail their ROBERT contact-tracing protocol

Research institutes Inria and Fraunhofer have shared details on their contact-tracing protocol that could be used by the French and German governments in the coming weeks. It is named ROBERT for ROBust and privacy-presERving proximity Tracing protocol.

Inria and Fraunhofer are members of the Pan-European Privacy-Preserving Proximity Tracing (PEPP-PT) project. On Friday, PEPP-PT said that seven European governments were interested in developing national apps based on the standardized approach. So ROBERT could become an important inspiration for various contact-tracing apps around Europe.

The French and German research teams have chosen to share technical specifications on GitHub with various documents explaining their work so far. In addition to a full-fledged specification document, the group has written a high-level overview with frequently asked questions, an illustrated example and an interestingly-named document: “Proximity Tracing Applications: The misleading debate about centralised versus decentralised approaches.”

Inria’s CEO Bruno Sportisse also wrote an article on Inria’s website describing the thinking behind Inria’s (and Fraunhofer’s) work. In addition to explaining the concept of contact tracing, he says there’s no such thing as a decentralized contact-tracing protocol or a centralized contact-tracing protocol.

“None of the projects aim to implement a peer-to-peer network in which everything would rely on a supposedly ‘independent’ community […] of devices/smartphones that exchange information between them. The main reason why that’s not the case is that security vulnerabilities could have an impact with such an approach,” Sportisse wrote.

“All systems in the works include a common component (a server) and a decentralized component (a group of smartphones that can communicate between them using Bluetooth): all systems currently in the works are therefore both centralized […] and decentralized,” he continued.

And yet, centralization and decentralization have been at the heart of a debate between privacy researchers in Europe, with backers of the DP-3T initiative sometimes calling out PEPP-PT’s approach. DP-3T is another coalition of experts that claim to care more about privacy than PEPP-PT.

So let’s dive in to ROBERT and find out what Inria and Fraunhofer mean by a centralized-decentralized contact-tracing protocol.

Unpacking ROBERT

In the specification document, Inria and Fraunhofer define the big principles behind ROBERT.

Our scheme provides the following goals as detailed in [2]:

• Open participation. Participants are free to join or leave the system at any time.
• Simple and transparent. The system is simple to use and understand.
• Easy deployment. The scheme is easy to deploy and requires only minimal infrastructure.
• Anonymity. The smartphone App as well as the back-end server database do not collect or store any personal data.
• Federated infrastructure. The system must scale across countries, ideally worldwide. In order to preserve countries’ sovereignty, a trusted federation of infrastructures is necessary.

Those are all fair points, but based on the rest of the document, anonymity is not 100% guaranteed for all actors involved (the government, other app users, malicious users). The document itself describes why there could be some loopholes in the protocol:

The authority running the system, in turn, is “honest-but-curious”. Specifically, it will not deploy spying devices or will not modify the protocols and the messages. However, it might use collected information for other purposes such as to re-identify users or to infer their contact graphs. We assume the back-end system is secure, and regularly audited and controlled by external trusted and neutral authorities (such as Data Protection Authorities and National Cybersecurity Agencies).

That’s a big if.

Basically, the protocol is designed in such a way that it protects your privacy as long as you trust the government/the health ministry/whoever is in charge of running the central server. Based on that statement alone, it seems like the authority could log a ton of information about app users.

Generating a log of your proximity contacts

At its core, a contact-tracing app uses Bluetooth to build a comprehensive list of other app users who you’ve interacted with for more than a few seconds. A ROBERT-based contact-tracing app would make those matches on your device.

ROBERT uses ephemeral Bluetooth IDs that change every 15 minutes. For example, if you’re talking with someone for 10 minutes, you’re going to regularly send your ephemeral Bluetooth ID to the other person, and you’re going to receive the other person’s ephemeral Bluetooth ID. If nobody gets infected with COVID-19, those IDs remain on your device (and might even get purged after a while).

The app also collects additional information associated with ephemeral Bluetooth IDs. For instance, it collects the strength of the Bluetooth signal to evaluate the distance between the two persons.

All of this is fairly standard.

Uploading your contact list, not your own ephemeral identifiers

Approaches differ if somebody is confirmed to be infected with COVID-19. Under the ROBERT implementation, if a user is diagnosed COVID-positive and gives their consent to help the community of other app users, the app will upload the list of ephemeral Bluetooth IDs of other users that they’ve been interacting with over the past 14 days.

Again, the app doesn’t send the user’s own ephemeral Bluetooth IDs — it sends information about the circle of people gravitating around the infected user.

The server then has a list of potentially exposed users. It doesn’t necessarily mean they’ll be infected with COVID-19.

Computing a risk score on the server

So what does the server do with this list of potentially exposed users?

When you download a ROBERT-based contact-tracing app (such as France’s Stop Covid app that is in the works) and launch it for the first time, the server is notified. The server generates and sends a permanent ID and a list of ephemeral Bluetooth IDs. The server also keeps a list of all temporary IDs associated with permanent IDs.

In other words, the authority has a giant database of all permanent and ephemeral IDs associated with all app users. While the specifications say “the stored information are ‘anonymous’ and, by no mean, associated to a particular user,” it’s in no way anonymous. It’s pseudonymous.

When a user is diagnosed COVID-positive and accepts to share a list of the ephemeral Bluetooth IDs of people they’ve interacted with, the server logs all that information and increases the risk score of people they’ve interacted with.

Over time, multiple users who are confirmed to be infected with COVID-19 could flag different Bluetooth ephemeral IDs that belong to the same user. The server is going to increase the risk score of the permanent ID associated to that user.

Essentially, the authority will have a database of permanent IDs with each ID representing one person. There will be a risk score associated to each person. When the risk score reaches a certain threshold, the user is notified.

A weak defense of centralization

As you can see in my description of the ROBERT protocol, the project tries to minimize the attack surface by centralizing most computing on a server. It is designed to be resilient against malicious users as much as possible — it requires you to “register” your account by obtaining a permanent ID from a central server.

But this centralized implementation means that you’ll have to trust your government. In particular, you have to trust that:

• They’re not doing anything nefarious without telling you.
• They have developed a secure implementation of the ROBERT protocol.

For instance, what if a ROBERT-based app uploads your IP address when your app checks the risk score associated with your permanent ID? What if the government wants a little more data to examine the social graph of pseudonyms? Those could be huge privacy risks and the end user wouldn’t even be aware of the vulnerability. It is basically the opposite of “privacy by design.”

Instead, Inria and Fraunhofer throw the DP-3T implementation under the bus:

Other, qualified as ‘decentralised’, schemes broadcast to each App an aggregate information containing the pseudonyms of all the infected users. This information allow each App to decode the identifiers of infected users and verify if any of them are part of its contact list. Our scheme does not follow this principle because we believe that sending information about all infected users reveals too much information. In fact, it has been shown that this information can be easily used by malicious users to re-identify infected users at scale. We claim that infected user re-identification must absolutely be avoided since it could lead to stigmatisation. Instead, we chose to securely store this information on a central server.

Dismissing decentralized protocols in such a way is completely irresponsible. In both cases, it depends on the implementation. That’s why it’s going to be important to let developers audit the code that runs both on the smartphone and the server — whether the server is only a relay server or a central database. Otherwise, people are not going to trust contact-tracing apps and they will be useless.

Data on your device can be encrypted and inaccessible to other apps and malicious users. The government could even control a decryption key using a multi-signature authentication. This way, malicious users wouldn’t be able to decrypt data without interacting with the central server, and the central server wouldn’t be able to access user data.