The Dark Side of SwissCovid

The Dark Side of SwissCovid

"Je ne comprends pas ce truc."
(Ueli Maurer - member of the Swiss Federal Council - 4.7.2020)
(impossible to translate)

We followed the evolution of SwissCovid and did our own analysis on it. Lots of consensual opinions have already been expressed. We wish here to present an alternative viewpoint about SwissCovid. Our position on SwissCovid is that

• communication about possible vulnerabilities are either hidden or avoided by arguing that experts have looked at it and concluded risks were acceptable;
• the legal frame is insufficient to protect people against deployment of a non-transparent system - the law was bypassed 5 days after adoption.

The privacy-by-design and transparency claims are smoke screens. Although it is important that we all protect ourselves and others with such tools, we should not deceive ourselves with unsatisfied promises.

Content.

• Prologue: how the scientific debate happened.
• Own Analysis: our test report and its fate.
• Apple & Google: how two giants took control.
• How it Works: what SwissCovid is outsourcing.
• Effectiveness: how to measure effectiveness.
• Possible Attacks: threats which were known from the beginning and still there.
• So What?: conclusion.

Disclaimer: We are strong advocate of transparency and objectivity in scientific communication. We reckon that the pandemic has made tools such as proximity tracing (sadly) unavoidable. We respect the political decision to deploy it. The political decision took the way of a voluntary acceptance, which requires trust to be effective. We do not believe in a conspiracy. We have no doubt all involved people, organizations, and companies are in good wills and did their restless best to fight the pandemic. At the same time, we know that the road to hell is paved with good intentions. It has been claimed many times that data is anonymous, that there is no threat, that the app is transparent because of being open source by law, that people should not be scared, that fear is irrational, that communication is monopolized by conspiracy theories. By trying to communicate over-simplified information and giving paternalistic advises for adopting SwissCovid, SwissCovid has failed to be transparent. By failing in providing fair information, by adopting an opaque proprietary solution, and by bypassing the law, we feel that trust is broken. We believe that showing all these facts is helping to support transparency. We do not think open information would affect the acceptance by people because contact tracing is a necessity. People who support SwissCovid will continue to support and skeptical people will be confirmed in their skepticism. We think people deserve to know facts.

Prologue

SwissCovid is based on the DP3T project. DP3T was announced on April 1, 2020 (as part of the bigger project PEPP-PT). Our early analysis of DP3T was published on April 8:

Serge Vaudenay. Analysis of DP3T - Between Scylla and Charybdis. IACR-EPRINT 2020.

It is worth saying that this report was originally meant to be read by the designers of DP3T only, but that they suggested to make it public. This is why it is available there.

In early April, a fight occurred between developers of centralized and decentralized systems, within the PEPP-PT project, with the conquest of countries for the adoption of one or the other system in background. DP3T, which was developing a decentralized system, split from PEPP-PT and won the battle. We reckon that

• centralized systems can cause major security and privacy risks;
• decentralized systems are motivated by privacy concerns.

However, arguments against centralized systems have been overly exaggerated and the ones in favor of decentralized systems have been oversold to a level that we found unethical (at least, against the objectivity rules of scientific communication). We do not think that one approach protects privacy better than the other. Furthermore, other ways have not been investigated enough.

Since all these was also clear for policy makers, we can wonder why decentralized systems succeeded to conquer most of European countries. This is most likely due to the heavy support of Apple and Google. It is known (with the previous experience of Singapore) that access to Bluetooth can drain the battery of the phone quite a lot. Apple and Google announced that they would provide an optimized access to Bluetooth to decentralized contact tracing apps only but would keep on restricting it to other applications.

Our study about centralized versus decentralized systems, as well as directions for a 3rd way, was published on May 6, 2020:

Serge Vaudenay. Centralized or Decentralized? The Contact Tracing Dilemma. IACR-EPRINT 2020.

In parallel, we worked with colleagues from France to explain in an as non-technical manner as possible, the risks which eventually come with any automated contact tracing. Our article is available in French (English version available from the link) on April 21, 2020:

Xavier Bonnetain, Anne Canteaut, Véronique Cortier, Pierrick Gaudry, Lucca Hirschi, Steve Kremer, Stéphanie Lacour, Matthieu Lequesne, Gaëtan Leurent, Léo Perrin, André Schrottenloher, Emmanuel Thomé, Serge Vaudenay, Christophe Vuillot. Le traçage anonyme, dangereux oxymore.

Own Analysis

Before the deployment of SwissCovid, there has been a test phase for a pilot version. As tester of the pilot version, we were required to report on our findings. We posted our report on June 5, 2020. However, the report was held under a responsible disclosure clause until June 16, during which the law on SwissCovid was discussed and approved. Meanwhile, our report has been heavily criticized, although we could not even publish it. The link below tells the story of our report and describes the compliance issue. It also gives links to the documents.

Serge Vaudenay, Martin Vuagnoux. Own Analysis of SwissCovid

In summary, our report shows that

• a big part of contact tracing is outsourced to the Apple-Google implementation;
• the Apple-Google implementation has no public source code (at least until July 21);
• Amazon is implementing part of the server infrastructure;
• the available information is unclear, incomplete, or incorrect;
• some previously identified attacks are still feasible.

Our compliance analysis concludes that

• the switch from the pre-standard version to the Apple-Google-based one made SwissCovid not compliant with the law;
• the implementation of DP3T has bypassed the law;
• the law was shown to be powerless to protect people from using a non-transparent contact tracing system.

Apple & Google

Our main concern about SwissCovid is that the app is outsourcing nearly all its tasks to the Apple-Google implementation called GAEN (as for Google Apple Exposure Notification) and that GAEN is out of public or national control: there is no source code nor any way to verify how it works. As discussed in the above document, this is not compliant with the spirit of the law. We tried to reconstruct the chronology which ended up in this state of affair:

• April 10: Google and Apple announced that the would join their force to provide an optimized access to Bluetooth with an interface. It would be only for applications opting for decentralized systems.
• April: GAEN specifications v1.2 are published. It became clear that the "interface" would be much more than an interface to Bluetooth. It would rather be an implementation and variant of the the entire DP3T protocol except the server part. It was also clear to people that the source code would not be released.
• May 13: the Federal Council issues an ordinance for the pilot test which defines the "components" of the system. This ordinance never mentions the interface GAEN. It enumerates the tasks that the app must complete (Art.10) (which are actually the tasks which are achieved by GAEN). It is quite clear at this time that either the ordinance was prepared for the pre-standard version (which does not use GAEN at all) or that it made a mistake by mixing the app and GAEN together: they are mixed up for the tasks but they are separated for the source code disclosure.
• May 20: the "message" of the Federal Council defines the basis of the legal frame, including LEp Art.60a al.5 let.e saying that for transparency and trust, the source code and specifications of all components are public.
• June 5: our analysis report describes the problem of source code disclosure and legal contradictions.
  Defenses sometimes argued that GAEN is part of the Bluetooth communication interface of the phone, which is not usually subject to source code disclosure. Defenses sometimes argued that GAEN is part of the operating system of the phone, which is not usually subject to source code disclosure. We challenge that both are incorrect. We can have an Android phone with Bluetooth working but no GAEN. Furthermore, the pre-standard verson of SwissCovid is working on it. GAEN is actually part of the "Google Play Services" which is like a separate app. It can be removed. Hence, contact tracing is not implemented in SwissCovid but rather in another app.
• June 19: the law is adopted, requiring all components to have a public source code. It was added that the system should be verifiable from the source code.
• June 24: a new ordinance from the Federal Council repeats the list of components which excludes GAEN. However, GAEN appears in the ordinance as a "help" to the app. The list of the tasks of the app is still listed but nearly all are fully outsourced to GAEN without control. It is explicitely mentioned that GAEN is not subject to source code disclosure. As a result, SwissCovid which does nothing is fully transparent but GAEN which implements contact tracing escapes from the transparency requirement.
• July 21: Apple and Google released a source code for GAEN. For Apple, this is a sample code (i.e. not necessarily the used one). For Google, this is a partial code. In any case, we cannot run it.

Meanwhile, there are bugs in GAEN. They are not easy to find because of no source code. For instance, rolling the ephemeral identifiers and the visible random addresses they look to come from is supposed to be done synchronously. However, we noticed it is not: there is always one broadcast with the new address and the old identifier. This leads to the easy Little Thumb attack to link identifiers. We also noticed that, in some phones, the Bluetooth stack crashes silently and SwissCovid is sending identifiers but collecting none. The user would wrongly believe to be protected by the app.

What Google and Apple do with the data collected by Bluetooth is also out of control. Finally, the resulting difference between centralized and decentralized systems is that, on the former case, data is stored in a central server which is maintained by local authorities, while in the latter case, data is stored in a distributed server (the GAEN memory of the phones) which is maintained by Apple and Google. In the former case, trust is based on a democratic system. In the latter case, trust is based on a commercial system.

France had a controvery about StopCovid - the French app which relies on a centralized system - storing more information than what is necessary. Contact tracing indeed aims at storing only contacts which last long enough and at a close distance (in Switzerland: less than 1.5m during 15 minutes). It was shown that StopCovid was actually sending all contacts (either brief or distant ones) to the central server. A similar controversy could occur in Switzerland: GAEN actually stores all contacts. They are stored locally on the phone, in this distributed decentralized server. However, since there is no control about what Apple and Google are doing with those stored contacts, the same controversy is possible. Apparently, this problem was fixed in France. It is unlikely it will be in Switzerland as it depends on GAEN.

Apple and Google could further abuse their dominant position to have their parallel contact tracing system, in order to identify people who had any contact (long or not, at distance or not) with a targetted category of people. This category would not necessarily be the category of diagnosed people. For instance, it could be the category of people who used a given commercial product. Identifying the contacts of users of a product could be a good target for advertisement. If maliciously used, GAEN could become a gold mine for Apple and Google.

How it Works

The app and GAEN. SwissCovid devices permanently broadcast an ephemeral identifier which changes every 10-12 minutes. Every ephemeral identifier is derived from a daily key which is selected at random. Given the ephemeral identifier, we cannot recover the key. However, given the key, we can recover all identifiers of the day. GAEN is

• selecting the daily key,
• keeping it in memory,
• broadcasting ephemeral identifiers,
• collecting ephemeral identifiers sent by other phones.

We will see below that GAEN plays two more roles.

If a user is diagnosed, his app gets the daily keys of the last few days from GAEN and uploads them on a public server.

This server can be observed by anyone. Apps regularly download the reported daily keys and give them to GAEN. GAEN checks if those daily keys derive one of the collected ephemeral identifiers, to check if a diagnosed user was in contact. GAEN reports the contacts with diagnosed users with information about the date, the duration, and the distance to the app. The app decides to raise a notification or not.

SwissCovid Principle:

(1) phones (GAEN) generate daily keys, derive and exchange ephemeral identifiers; (2) Alice gets diagnosed; (3) Alice's app gets the keys making identifiers she used from GAEN and reports to the server; (4) Bob's app downloads the reported keys, GAEN compares with the collected identifiers, and reports matchings to the app; (5) Bob's app decides to raise a notification.

To estimate the distance of a contact, phones compare the power of the Bluetooth signal when being sent and when being received. However, the power of the sending signal is encrypted (using the daily key) inside the Bluetooth message. Consequently, it is not visible by the receiving phone until it obtains the daily key of the sender (because he was diagnosed and reported). Hence, it is only at the time of the comparison that the distance can be estimated.

Similarly, the ephemeral identifiers are rolling every 10-12 minutes. Normally, a receiver cannot link two identifiers until it receives the daily key which derived them. Hence, the duration of a contact (and that it was at least 15-minute long) can only be determined at the time of the comparison.

The server. The "server" is actually an infrastructure of several servers within a network. The app regularly downloads reports from the server and also the configuration parameters to be used to calculate the at-risk notification. Both types of downloads are supposed to be done by millions of devices every day. To provide the download service reliably, SwissCovid uses a Content Delivery Network (CDN) which is provided by Amazon. When we try to download from anywhere in the world, it is a local Amazon server which responds. The content is obtained from the servers of Swiss Federal offices and signed by them so that Amazon cannot tamper with the content.

The "server" also includes another site where to upload daily keys after diagnosis. As this operation is (hopefully) rare, there is no need for a third party service for this operation. Essentially, a diagnosed user is in contact with the public health authorities which give them an access code, called covidcode, of 12 decimal digits. With this 12 decimal digit, the app gets from another server another code (namely, a JWT code) which allows the app to upload the daily keys on the server.

One problem is that the network sees all requests to the server made by the app and can possibly identify the phone. One trick to protect privacy is to make "fake" queries once a while at random. Queries are encrypted, so the network cannot see if they are fake or real.

What the app is doing. We can list the roles of the app below.

• Let the user turn on and off contact tracing and instruct GAEN about it.
• Update the parameters for notification from the server.
• Collect the reported keys on the server and pass them to GAEN.
• If GAEN spots contacts, inspect the duration, distance, and time of spotted contacts and decides, based on the parameters, to notify the user or not.
• If the user enters a covidcode, query the covidcode server to verify it and get a JWT code.
• Get from GAEN the list of recent daily keys, let the user remove some, and submit them together with the JWT code to the upload server.
• Once a while, send fake queries to the covidcode server and to the upload server.

Except for the decision to notify, the app is not processing any data. It is only passing information between the GAEN, the servers, and the user.

Effectiveness

The effectiveness of SwissCovid can be analyzed with several factors. First of all, FOPH reports to FSO an estimate for the number of "SwissCovid activations" per day as well as the number of entered covidcodes and a number of downloads. Second, we can compare the number of reported keys to the server and the official number of diagnosed cases in Switzerland. The site below is comparing the data we obtain from several countries which use GAEN-based contact tracing.

• Number of activations, entered covidcodes, and downloads by FSO.
• Number of reported keys by the TACT project

We should keep in mind that a diagnosed user typically reports keys for the previous few days. We should also be careful that FOPH was inserting 10 fake keys every day to "exercise" the software until July 17.

The estimate for the "number of activations" was changed on July 23. Before July 23, it was estimated based on the number of requests to the server to retrieve the configuration parameters. In the source code, we can see that the app is configured to make such query every 6 hours. FOPH has no means to figure out if two different queries come from the same app (otherwise, it would be a violation of the design principles). Actually, the queries are not directly visible by FOPH as FOPH is outsourcing the reception and treatment of those queries to Amazon. Hence, the "number of daily activations" was simply the total number of queries (provided by Amazon) divided by 4 (because always running apps makes queries 4 times per day). However, this rather indicates an average number of queries. For instance, 1 million of activations could be an average number between 500'000 nightly activations and 1.5 million daily activations. Someone who was activating his app for only one minute every 6 hours was counted as a full activation although someone who was activating his app only when useful (e.g. when taking public transport or at the restaurant) was counted as a fraction of activation. However, the second user was clearly making an effective use of the app compared to the first who does not use it at all. Hence, the figures provided by FOPH was probably underestimating the effective number of active users.

Since July 23, the "number of activations" is estimated based on the number of fake reports that the app submits at random (to hide from the network when it is really submitting a report). In the source code, we can see that the next fake report is scheduled after a random duration which follows an exponential probability distribution with an average of 5 days. Hence, FOPH essentially divides the daily number of received fake reports by 5. This is a probabilistic estimate which has a standard deviation of about 5000 (5 times the square root of the number of apps which is about one million). Hence, this number is rounded with a 10'000 precision. With this method, an app which is activated a few seconds every day is fully counted (as its scheduled fake report may be sent during these few seconds and another fake report can be scheduled). Hence, the "number of activations" reliably estimates the number of apps which have been activated at least once during the day.

We however stress that this number of activations is based on the received queries but nothing proves that they were made by a SwissCovid app. Indeed, anyone could buy several millions of malicious queries from a botnet on the darknet to maliciously inflate this number. (This would be illegal.)

Another interesting measure of effectiveness is based on the number of reports from diagnosed users. This corresponds to the number of entered covidcodes. If, during a given period, we have a total of r reports of diagnosed users for c positive diagnoses, we can deduce the probability ^r⁄_c for a random diagnosed person to be a willing-to-report SwissCovid user. We represent below the obtained ratio by using the official figures.

The goal of SwissCovid is to notify a (possibly contaminated) person who encountered close enough and long enough (in an epidemiologically relevant sense) a (possibly contagious) person who was diagnosed. When this event happens, the probability that SwissCovid succeeds to notify the possibly contaminated person is the probability that all what follows occurred:

1. the contaminating person uses SwissCovid and is willing to report using SwissCovid after diagnosis;
2. the contaminated person is an active SwissCovid user;
3. both had their SwissCovid active when they encountered;
4. SwissCovid succeeded to notice their encounter.

We take the most favorable case assuming that the last two conditions always occur. (The last one will be discussed hereafter.) We assume that both participants are uniformly distributed and independent. The first condition occurs with the probability ^r⁄_c from the plot. The second condition occurs with probability ^u⁄_p, where u is the number of active SwissCovid users and p is the total population. Hence, the probability that SwissCovid spots this infecting contact can be approximated to

e=^r.u⁄_c.p

This approximation assumes ideal probability distributions. On July 14, FSO announced r=72 entered covidcodes between July 6 and July 12. We can see that this period corresponds to c=599 cases. We can approximate u=1'000'000 and p=8'000'000. Hence, we obtain e=1.5%. This is probably the order of magnitude of the probability for SwissCovid to spot an infecting contact. The computation is however very imprecise due to the assumptions.

The next interesting question is whether SwissCovid, which spots an infecting contact, is able to alert infected people before a human-based contact tracing does. Indeed, in between the time the infecting person is diagnosed, the time he reports (he has 24h for that), and the time the infected person's app downloads the new report (which can take a few more hours), the traditional contact tracing may be done. Most likely, SwissCovid is only effective when the contaminated person is completely unknown by the contaminating person, e.g. in the case they encountered in public transportation or they were seated close to each other in a restaurant.

FOPH could also communicate the number of issued covidcodes (which may be larger than the number of entered ones if people decline to report after diagnosis). The SwissCovid design makes it impossible for FOPH to determine how many at-risk notifications were raised and how many of them led to a diagnosis case. The protocol will not reveal this. However, users receiving a notification may call a hotline, as recommended by the app. Statistics through the hotline could thus be feasible.

Regarding the ability of SwissCovid to capture close-enough and long-enough encounters, we can just observe that it is a controversial topic. Lots of tests were made during the design of SwissCovid. We have not seen any result about it. However, some independent project observed on June 26 that capturing those encounters does not work in a tram.

Douglas J. Leith, Stephen Farrell. Measurement-Based Evaluation Of Google/Apple Exposure Notification API For Proximity Detection In A Light-Rail Tram. Preprint arXiv:2006.08543 [cs.NI], 2020.

Like other results in this field, this result has not been confirmed or denied by peers. However, we can see that the radius for contact detection in SwissCovid was increased on July 6, as explained in the following article.

Paul-Olivier Dehaye. SwissCovid élargit son filet. (In French.)

Increasing this distance has no impact on the previous computation which assumed that encounters are always captured. However, it may increase the number of false at-risk notifications which we do not know, and henceforth the number of quarantines.

Possible Attacks

Several types of attacks against SwissCovid are possible. It is important for users to understand them. Indeed, SwissCovid is recognized as a medical device. Hence, the aware consent of users is fundamental. In normal medicine, awareness is guaranteed by providing the medicine together with objective information about possible side effects or observed risks. Having a clear and objective communication about the risks for taking SwissCovid can only strengthen trust.

Some attacks are easy to be done by anyone. Some of them are clearly illegal and people must not try them. For other attacks, which are based on collecting data, the legality is not clear at all because we are not sure the collected data are considered as personal data or not. Thus, we suggest not to try them.

Surveillance

Using a Bluetooth receiver (for instance, a phone), anyone can collect the ephemeral identifiers which are broadcasted around by phones. SwissCovid is not allowed to store the geolocalisation but other apps are not forbidden. Collecting identifier-time-location records allows to build a surveillance system. It can be enriched with the reported keys that anyone can collect from the server.

Here are a few attacks which are easy to mount. Welcome to the brave new world!

• BLE contact tracing sniffer PoC: build your own Bluetooth surveillance system and see where diagnosed people have been! (Please read the disclaimer on the link.)
  The following paper shows how to improve this techniques.
  Lars Baumgärtner, Alexandra Dmitrienko, Bernd Freisleben, Alexander Gruler, Jonas Höchst, Joshua Kühlberg, Mira Mezini, Markus Miettinen, Anel Muhamedagic, Thien Duc Nguyen, Alvar Penning, Dermot Frederik Pustelnik, Filipp Roos, Ahmad-Reza Sadeghi, Michael Schwarz, Christian Uhl. Mind the GAP: Security & Privacy Risks of Contact Tracing Apps. Preprint arXiv:2006.05914 [cs.CR], 2020.
  
  This type of surveillance can be enriched by using techniques to link rolling ephemeral identifiers. Linking consecutive ones is easy, and can also be made trivial using the Little Thumb bug from GAEN. (The name Little Thumb comes from the fairytale of Charles Perrault, in which a little boy marks a trail with white pebbles to be able to find his way back. Here, we use the asynchronous identifier/address changes to link them.) [Details to be added.]
• Stop Covid Detector 3000: on the principle of Pokemon Go, this app makes you hunt active SwissCovid users like pokemons; the next step would be to share the data to build a decentralized surveillance system. You can see if the person in front of you uses SwissCovid. (Note: it is forbidden by law to discriminate based on this information. However, people are already trying to twist this law too.)
  
  
  Credit: Bénédicte @ Vigousse
• RaMBLE: following the same principle, you can collect SwissCovid devices and even draw them on a map. Just filter them with the service identifier 0xfd6f of contact tracing.
• BitsaboutMe: given that the information you collect is yours, you can use this app to share or sell it together with other information belonging to you. You can share or sell the information that you have seen which beacon at which place at which moment. This makes a distributed surveillance system.

Those attacks are clear privacy threats to people. Users concerned about these should set/unset SwissCovid tracing responsibly.

Legal issues. We believe such attacks should be illegal. However, what they only collect is the ephemeral identifiers which are broadcasted over the air. (Own location and time belongs to whoever wants to store it.) If such data is not considered as personal data, such attack may be perfectly legal, which we find absurd.

The notion of personal information is actually a key issue here, because of the law on data protection. On the FOPH website we can read "The phone does not send any personal or location data to a central storage location or server". On another page we can read "The CDN only gives users access to information that cannot be used to obtain personal information (i.e. anonymous keys)". SwissCovid beams via Bluetooth some ephemeral identifiers which are derived (and can be recomputed) from keys. Diagnosed people post their keys on a publicly available server. Clearly, the position of SwissCovid promoters is that keys are anonymous. Anonymous information is not considered as personal information, thus not subject to regulation. If keys are anonymous, the identifiers which can be recomputed from them is anonymous too. Consequently, it is legal to make keys transit through a CDN, possibly abroad, without any regulation constraint. However, ephemeral identifiers become anonymous too hence no personal information. Therefore, they can be collected by anyone without regulation.

Instead, we believe that information which is exchanged via Bluetooth between phones and the one which is posted on the server are pseudonyms in the sense of the European regulation GDPR. They are not anonymous. Following GDPR, pseudonyms are private information. Hence, they should be subject to regulation on data protection. However, such recognition may have consequences on how the data stored on the server be regulated, and even on how phones collect ephemeral identifiers.

Extension with (other) personal data. We can of course improve the previous attacks by collecting more (personal) data. For instance, the Bluetooth surveillance can be enriched with a video-surveillance system so that ephemeral identifiers would link to a recorded video. If a reported key happens to generate an identifier which was collected, we can see the holder on the video, even though the contact was very brief and at distance.

An organization which identifies people can at the same time collect an ephemeral identifier and later one recognize if this person has become sick. This can be made at the reception of a hotel, at the cashier of a shop for people using a loyalty card, or at the entrance of a company for visitors or employee. Essentially, diagnosed people can be identified if they have even be seen by such surveillance system.

The basic attack was called the paparazzi attack in our April 8 report on DP3T. Essentially, a paparazzi can capture from far away one ephemeral identifier of a celebrity and regularly check on the server if this celebrity reported as diagnosed. Such information can be sold to tabloids. In a variant of this attack, a paparazzi can check which politicians are using SwissCovid and report. As acceptance of SwissCovid is becoming a political act, this could be a valuable information.

False-Alarm Injection

The ephemeral identifier of a person which is going to be diagnosed can be captured (even from far away) and maliciously be replayed somewhere else to simulate a risky encounter. This is likely to create a (false) at-risk notification. This way, we can get rid of some people by making them go to quarantine. According to specifications, an ephemeral identifier is supposed to be sent at some approximate time but the reception accepts it 2h before and 2h after. So, there is a lot of time to replay it.

In the (imaginary) lazy student attack, a student runs this attack on their classmates to send the entire class in quarantine and have an exam cancelled. Presumably, we can turn an event or an organization down in the same way.

In another type of attack, a group of people could use a malicious app which mimics the Bluetooth ephemeral identifier broadcasting but synchronize all devices on the same keys. The effect is that all those people would be considered as a single person. They can try to broadcast with high intensity to make a wide neighborhood think of a close encounter. If one person of the group is diagnosed, this can create a very high number of false at-risk notifications. This is a kind of terrorist attack which sends a huge number of people to quarantine.

Those attacks could exploit a problem in the GAEN implementation (namely, that the encrypted metadata in the Bluetooth signal is malleable). They could even be done from abroad, to escape from legal jurisdiction, by using sponsored add-ons in benign apps, as described in the following paper.

Paul-Olivier Dehaye, Joel Reardon. SwissCovid: a Critical Analysis of Risk Assessment by Swiss Authorities. Preprint arXiv:2006.10719 [cs.CR], 2020.

Finally, a more drastic attack could be to corrupt a diagnosed user to buy his covidcode, then meet the persons we want to send to quarantine, then use the covidcode to report our keys. A covidcode can be used only once, but it remains valid during 24 hours. Interestingly, a much easier attack was possible during the first three weeks of SwissCovid. FOPH was adding on the server 10 fake keys per day for maintenance reasons. However, the validity period of those keys was posterior to the date of insertion. Consequently, a malicious person could download them and use them during their validity period to simulate the broadcast of a diagnosed person. This problem was announced to be corrected on July 20.

So What?

Our concerns are about broken promises. SwissCovid was aimed to be transparent with open source but is not. SwissCovid was aimed to be privacy-preserving but is not. Nevertheless, official communication sticks to it.

Is it important enough to shut down SwissCovid? Certainly not. There are many other important factors which motivate adopting SwissCovid. For instance, the following report, issued from Armasuisse, considers the efficiency of the system for contact tracing, the battery usage, and the adoption likelihood in addition to security and privacy.

Franck Legendre, Mathias Humbert, Alain Mermoud, Vincent Lenders. CONTACT TRACING - An Overview of Technologies and Cyber Risks. Preprint arXiv:2007.02806 [cs.CR], 2020.

This report compares various technologies and adopts a scoring scheme which is subjective. It concludes that the technology with the best average score is the one from SwissCovid. We can see however that the second best (with almost equal average score) is the technology which has the most terrible score for privacy protection. This illustrates that privacy may be a not-so-important factor.

We can wonder if the debate about privacy took the right direction. Of course, in countries with governments having too much power, privacy is a concern. But SwissCovid is deployed in Switzerland. In Switzerland, the SwissCovid approach on privacy consists of making sure that FOPH has no way to see who met whom or who activated SwissCovid from the data they collect. However, the health authority has legal means to investigate on contacts between people when it is needed. We can wonder if protecting against a possibly intrusive FOPH is making sense. At the same time, SwissCovid prevents FOPH from having fine grained access to epidemiological data or statistics. FOPH cannot see how many alerts SwissCovid raises and has little ways to measure the usefulness of the system. It does not say how SwissCovid is activated. Even worse: this architecture which is protecting against a corrupted FOPH is creating privacy issues which can come from any third party. In our April 8 report we already claimed that this dogmatic approach of decentralization was creating more privacy threats than it was solving.

SwissCovid was developed and deployed in a rush, with the pressure of the pandemic. It is remarkable that SwissCovid was fully deployed so fast, but SwissCovid could have been much better with more time. Regarding GAEN, we are faced with fait accompli. The deal with Apple and Google could have been more careful. Those companies could have released a real interface giving access to Bluetooth instead of implementing the protocol by themselves. They could have released their source code too. (We reckon that some partial source code was released on July 21, which seems to move in the right direction.) SwissCovid could also have developed an app without GAEN as other countries did, but with battery issues. Other solutions in the protocol could have been investigated too. We listed several possible options in our May 6 report. For instance, there are ways to keep a decentralized flavor and to fix some privacy issues at the same time.

At the moment, there is no other option than SwissCovid. For the next pandemic, we believe that more research should start now.

Last update: July 23, 2020.