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
Content.
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.
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
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:
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.
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.
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. 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.
The "number of activations" is estimated based on the number of requests to the server to retrieve the parameters. In the source code, we can see that the app is configured to make such query every 6 hours. FOPH should have no means to figure out if two different queries come from the same app (otherwise, it would be a violation of the design principles). Hence, the "number of daily activations" could simply be the total number of queries divided by a correcting factor. Someone who activates his app only 6 hours in a day would count for less than someone who lets it work 24h/24. Hence, the figures provided by FOPH can only give a trend but the figure itself may not be significant.
We further stress that this number 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. If, during a given period, we have a total of r reports of diagnosed users for c positive diagnoses, u active SwissCovid users for a population of p inhabitants, assuming ideal uniform distributions, the probability that an infecting contact, which occurred between a contagious-to-be-diagnosed person and an inhabitant, is spotted by SwissCovid is
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. Those cases may be estimated this way. We can thus wonder how many notifications did the 30 reported cases created. There is no official figure available. We can suspect it is very low. The July 8 RTS television broadcast said that FOPH was thinking of how to measure effectiveness but abstained from providing any figure. Incidentaly, the radius for contact detection were increased two days before, as explained in the following article.
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.
Here are a few attacks which are easy to mount. Welcome to the brave new world!
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.
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.
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.
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.
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. Even the "number of activations" is unreliable. 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. 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 12, 2020.
