Corona Warning App

In 2020 many things are different. People work and study from home, wear face masks and are facing restrictions in their fundamental rights. These measures and restrictions were taken to bring the global pandemic under control. More than 800.000 people have died as a result of Covid-19 (SARS-CoV-2) (25.08.2020).

“Let’s build an app for it” is the simple answer for many things. Therefore, it is no surprise that a lot of people asked for an app to fight Covid-19. In Germany, the “Corona Warn App” was published on June 16, 2020 ^[2] . Controversial topics being discussed in the public were:

How does such an app work?
What are the benefits?
Will the number of false positives become too high?
How secure is it?
Does this restrict privacy?

Today, that the app is available for 2 months and has been downloaded more than 17.5 million times. This might be a good time to give answers to the questions above.

First, in this blog post an overview of the approach and the Corona Warn App in Germany is given. Thereafter, the findings from the development of the app until today are summarized and finally, the above-mentioned questions are discussed in the summary.

Approach

There are very different approaches in terms of official Covid19-Apps. For example, China’s Alipay Health Code app assigns a digital QR code to each user, which is colour-coded red, amber or green to indicate that person’s quarantine status and thus their permission to move around ^[3]. People who are quarantined in Hong Kong must wear an electronic bracelet, which shares their location with local authorities through an app ^[4]. Poland requires citizens to self-isolate for a period of 14 days after returning from overseas. During that period they must send geotagged “Selfies” to the police ^[5]. However, the most common approach, which is also used in Germany’s “Corona Warn App”, is to inform users when they have been in contact with infected persons. In order to detect these contacts, various techniques can be used to trace via smartphones. While in South Korea all available information such as location data or credit card transactions is used for this purpose, other countries like Israel used personal GPS-Data to identify contacts. Since such approaches are either not compatible with the EU General Data Protection Regulation (GDPR) ^[14] or precise enough, Bluetooth is used in Germany and many other countries (Italy, Singapore, France etc.) to trace contacts.

One crucial difference is, that distinguishing between a centralized and decentralized approach, which is shown in Figure 1. In a centralized approach (France, Singapore … ) the contact logs are stored centrally on a server, whereas the decentralized approach stores these contacts locally on the phone. After the PEPP-PT (Privacy-Preserving Proximity Tracing) approach was criticized in Germany due to data protection issues ^[6], DP-3T (Decentralized Privacy-Preserving Proximity Tracing) was implemented by the German government in cooperation with Telekom, SAP, Apple and Google.

Figure 1 ^[7]

Corona Warn App (Germany)

The German “Corona Warn App” was developed in cooperation between Telekom (Backend) and SAP (Frontend). In a Open-Source project the decentralized DP-3T approach and its protocols, as well as the TCN (Temporary Contact Numbers) protocol is used. As an interface works the Exposure Notification Framework (Apple/Google API), which is not Open-Source and entails that the app is based on the Privacy-Preserving Contact Tracing specifications ^[9]. Figure 2 shows the structure and interaction between Warn App, Backend and API.

Figure 2 ^[8]

Figure 3 shows how the contact tracing process works via Bluetooth Low Energy (BLE). Having installed the App, the individual phones act as beacons which are constantly broadcasting their own temporary identifier, while scanning for identifiers of other phones at the same time (Normal Operation). Those broadcasted identifiers are only temporary and changed every 15 minutes ^[9]. New identifiers are derived from a “Temporary Exposure Key” that changes on a daily basis as a cryptography-specification of the Apple/Google framework ^[10].
The collected identifiers of connected users are stored locally on each phone. If users have tested positive for SARS-CoV-2, they can choose on their own to provide a verification of their positive test to the app (Infection). Depending on the laboratory, it is possible that the test result will be sent directly to the smartphone. This should reduce the time of transmission in case of an infection. As a consequence, their keys of the last 14 days are uploaded to a server. On this server, all keys of people who have been tested positive are aggregated. The list of all identifiers are distributed on a confidential hosts to all mobile phones participating. By comparing the stored identifiers with the keys received from the server, it can be easily determined whether there was contact with an infected person and an risk ^[23] can be calculated by the app.

Figure 3 ^[7]

If you want to take a closer look at the individual components of the App, you can read the CWA documentation ^[2].

Findings

Now, after the app has been released for over 2 months, first answers to the above mentioned questions can be given.

Benefits

As described, the app has now been downloaded 17.5 million times. However, this does not mean that 17.5 million users are actively using the app (risk assessment in the app= active). However, the number of users is not sufficient to achieve a real benefit from the Corona Warn App. This shows the number of infected persons who have so far reported via the App and sent diagnosis keys. According to estimates (necessary because no official numbers are available), 504 diagnostic keys was shared in week 34.
If we consider the ratio of infected persons reported by the Robert Koch Institute (RKI) in week 34 (9561), the correlation is only 5.3% (shown in Figure 4). This means, that slightly more than 5% of infected persons used the app to share the diagnosis key. This also explains why the expected users of false positives has not yet occurred. There are simply too few users using the app or sharing their positive test results.

Figure 4 ^[11]

Reasons for this are mentioned in the paper Who does or does not use the “Corona-Warn-App” and why? ^[12]

According to this paper, data privacy concerns, doubts on the usefulness and insufficient technical equipment are the main reasons why people do not use the app. So let’s take a closer look at these critical points of the app.

Data Protection and Information Security

In the German paper “Datensicherheit von Corona-Apps nach der DSGVO”^[13], the security of the different approaches of Corona-Apps is analyzed with regard to the General Data Protection Regulation (GDPR) ^[14]. Article 25 (Data protection by design and by default) and Article 32 (Security of processing) of the GDPR are relevant for this and provide rules for achieving data protection and information security.

Data Protection

Since the Corona Warn App use pseudonymisation with identifiers and no plain text names or cell phone numbers are exchanged, the App complies with Article 25 of the GDPR. Of course, anonymization of the exchanged data would be even better, but then the purpose of the app is no longer realizable. Another possibilities to protect the data even better would be to generate the Temporary Exposure Key more often (actual daily) and send the identifiers in different parts. This Approach is also supported by DP-3T ^[7], but not by the Google/Apple API and is therefore not used in the German “Corona Warn App”.

Information Security

As usual in the context of information security, the Corona Warn App is evaluated according to Article 32 in terms of Confidentiality, Integrity and Availability (CIA).

Confidentiality measures protect information from unauthorized access and misuse. Third parties must not have easy access to the data. Since all identifiers are pseudonymous and publicly available, confidentiality in the communication between server and app is no problem here. This is an advantage over a centralized approach, where the server, which centrally stores all IDs, would have to be protected accordingly. The connections between app and servers , for example to transmit the test-result, are secured with TLS 1.3 and mutual authentication (TLS client certificate). However, the app’s data must also be encrypted on the smartphone, which the Corona Warn App does by using SQLCipher ^[15].

Integrity measures protect information from unauthorized alteration. This is also achieved by the techniques presented (cryptographic functions for IDs, TLS for server communication etc.) according to GDPR. However, there was technical gaps that attack integrity. These are described in “Technical Security”.

Availability measures protect timely and uninterrupted access to the system. Once again, the decentralized approach is an advantage, as it allows identifiers to communicate between smartphones even if the server fails. Contact Tracing therefore remains available even in case of server failure. A serious disadvantage here is the dependency on Google and Apple, which could disable the interface at any time ^[10].

Technical Security:

Technical security gaps are also described in the security overview of the CWA documentation, which means that many attacks have been fixed in the development process. Nevertheless the approach provides some gaps like Drain, Relay and Trolling attacks.

Power and Storage Drain Attacks ^[20]

The adversary attacks a nearby device by advertising a large volume of messages from a source. The device is forced to wake up to process each such message. If the message is invalid, the device discards it but has paid a power cost (Power drain attack). If the message is valid, the device stores the proximity identifier contained in the message (Storage drain attack).

Relay Attacks ^[20]

In a relay attack, the attacker uses two devices at two disparate locations and advertises from one device any message relayed from the other. If the relay attacks are allowed to be executed at scale, many victims will falsely believe they have been in contact with a diagnosed person. This will not only waste precious diagnosis resources but could also lead to a loss of trust in either the system or the diagnosis procedure.

Trolling Attacks ^[20]

Trolling attacks are possible if the attacker is a person who is diagnosed or expects to be diagnosed soon. The attacker attaches his or her mobile device to a carrier, such as a dog, a car or drone, to collect IDs to scare people and lead a loss of trust in the system, too.

All these attacks are gaps for the Apple/Google API and described in the paper “Security analysis of the covid-19 contact tracing specifications by apple inc. and google inc.” ^[20] . Due to the open source community, some of these attacks have already been discussed in the GitHub issues and thus fixed for the Corona Warn App.

Bugs and Problems

Further reasons why the Corona Warn App is not yet being used sufficiently are the recurring bugs of the App. First, the app is only published from IOS 13.5 or Android version 6.0. Even after the release some problems occurred which could have a negative impact on the user numbers. For example, after an IOS-Update, the app no longer works on Apple’s iPhones ^[17]or did not permanently synchronize for weeks on Samsung and Huawei smartphones ^[18]. In addition, it is currently only possible in 50% of German Corona Test-Laboratories to transmit the results directly to the app ^[19].

A list of many smaller bugs and problems that also appeared in the Corona Warn App can be found in the CWA Documentation Issues on GitHub.

Summary

Even 2 months after publication, not all the questions raised can be answered completely. Too few users are currently actively using the app to assess the benefits of the app. This makes it difficult to really analyze the number of false-positive messages. However, due to the decentralized DP-3T approach, the app can be assessed as data protection compliant and and a Privacy Impact Assessment has also been published ^[21]. However, there are technical gaps that could be closed (if not already done through the open source community). Furthermore, it can also be criticized that the Google/Apple API publishes documents, but is technically not Open-Source.
Nevertheless, the way the app was developed is quite positive. Interaction with industry, government, operating system developers and security experts like the Chaos Computer Club (CCC) should be maintained for future government IT projects. In addition, this IT projects should, if possible, also be developed Open-Source in the future. This brings many advantages, especially in the area of security.

Finally, social risks must also be considered. What happens if, for example, the employer prescribes the use of the app or restaurants may only be visited if the app can be shown? Then a voluntary app will quickly become a binding one. Moreover, it remains to be seen how the policy will behave if a high number of infections appear. First politicians want to enforce a duty of the app to prevent a second lockdown ^[22]. In my opinion the app has to remain voluntary and one should try to increase the number of users through advantages with the app (e.g. no manual entry in contact data collection). With more users a more meaningful evaluation of the benefits and functionality would be possible.