As the vaccination campaigns are globally gaining traction, also the need and interest toward digital solutions for proving your vaccination status has been growing. Also we have been developing our own secure prototype for a vaccination passport, with a special focus on its applicability to all types of users of all ages. Especially the integration to wearable devices like smart watches enables it to be used in a wide variety of scenarios where use of a smartphone may be cumbersome or undesired. Also accessibility to user groups that are not used to using a smartphone (e.g., elderly persons) is provided through this solution.
The Corona-Warn-App uses Google’s and Apple’s Exposure Notification Framework for contact tracing, which the two companies have implemented in iOS and Android. To ensure privacy, apps cannot access IDs sent and received for contact tracking. However, Google writes exactly these into a log file on Android that system apps can access. The problem has been reported to Google, but they have not fixed it within 60 days.
Read more about the threat we have been talking about for a long time in the very informative tweet by Serge Egelman.Click hereto read the tweet.
The project “Secure and Privacy Protecting Pandemic Tracking Platform” was co-financed by the European Union through the European Regional Development Fund.
The System Security Lab focuses on a wide range of topics in field of cybersecurity and privacy, especially on those topics that affect our citizens.
Since January 2020, we have been investigating the security and privacy aspects of the Contact Tracing apps worldwide and in particular the Corona-Warn-App (CWA) used in Germany. CWA is based on Google & Apple Exposure Notification interface (GAEN).
Daily number of infections reported to the RKI, including the fraction that was shared within the CWA. No data was published for december 24 and december 31, 2020
Our team has collected more data on the use of the CWA and the new field experiments again confirm security and privacy gaps. The experimental setup is relatively simple: commercially available and inexpensive ESP32 microcontrollers equipped with Bluetooth and Wi-Fi were converted by the students into so-called “sniffers”.
The battery-powered sensors were placed weatherproof in downtown Darmstadt, in traffic hubs, parks and supermarkets. For several weeks, the sensors collected various data: MAC addresses, and Rolling Proximity Identifiers, or RPIs, the random IDs sent by the Corona warning app via Bluetooth Low Energy. In addition, the corresponding times were collected.
More than theory – Tracking in “the wild”
More than 21,000 collected MAC addresses were used to obtain information about the Corona-Warn-App (CWA) “hotspots” in Darmstadt, as the heatmap shows.
Heatmap: “Hotspots” in Darmstadt
By analyzing the data generated at the points of interest, we demonstrate in the wild that tracking infected users (of the CWA) is possible and not only a theoretical attack. The installed sensors recorded all RPIs that passed by and provided them with the corresponding time stamp. During the experiment between mid-December 2020 and early March 2021, over 97,000 unique RPIs were collected.
Temporary Exposure Keys (TEK), the so-called daily keys generated by the smartphone every 24 hours, were also used to evaluate these unique RPIs. Using cryptographic algorithms and various calculations, starting from a total of 17 Temporary Exposure Keys (TEK) uploaded to the CWA server due to a positive test result, we could precisely assign some of the RPIs among the collected RPIs. Although this is a one-way cryptographic function, enough “sniffing” sensors, which additionally contain the location data, could be used to track infected CWA users. In addition, the collected data also allowed conclusions about the used end device and its operating system.
Linking RPIs – tracking a person’s movements
Another case study demonstrate that the Corona-Warn-App is also vulnerable “in the wild” to the “Little Thumb Attack” published in July 2020 for SwissCovid. The Swiss researchers have demonstrated that user of the SwissCovid app could be tracked if the MAC address and the RPI did not update at the same time, but with a time delay. These overlapping updates lead to so-called “Pebbles”, i.e. faulty Bluetooth messages that enable linking of the user RPIs over a certain period of time. Such “Pebbles” could be detected in our real-world scenario. It was possible to track a user through such a Pebble across two sensors. This was only possible because this vulnerability exists in the Exposure Notification of Google and Apple (called GAEN), although it should not exist.
If the MAC address and RPI change synchronously, it is not possible to link the data. Using so-called callbacks, i.e., via the operating system, the CWA is informed that the MAC address has changed, so that the RPI can also update. Based on the data recorded, it seems that this is implemented variously in different devices, so not all smartphones are affected to the same extent. While there is a callback in iOS operating systems, nine out of ten Android devices tested parallel in the lab had no such callback. Even though the Android devices tested in the lab could not generate complete “Pebbels”, parts of “Pebbels”, so called “Overlaps” were recorded.
Hardly any protection against security vulnerabilities
The results show that the previously theoretical research approaches to various security vulnerabilities of the CWA could be shown in the wild, using simple, commercially available and low-cost sensors. It was possible to track the movement profiles of infected users, e.g., in the supermarket, for a certain period of time. Despite many updates, Google and Apple have not managed to fix the vulnerabilities yet.
A research team from the Technical University of Darmstadt, the University of Marburg and the University of Würzburg has demonstrated and confirmed vulnerabilities related to data protection and security of the Google and Apple specification for contact tracing apps under real-world conditions. The German contact tracing app developed by Deutsche Telekom and SAP on behalf of the German government is based on this approach. Also the Swiss and Italian contact tracing apps utilise this tracing technology.
Through experiments in real-world scenarios, the research team showed that risks already known on a theoretical level can be exploited in real life using commonly used technical means. This attack allows an external attacker to create detailed movement profiles of persons infected with COVID-19 and, under certain circumstances, identify them. On the other hand, an attacker can also manipulate the collected contact tracing information through so-called relay attacks, which can impair the accuracy and reliability of the entire contact tracing system.
Contact tracing apps on mobile devices promise the possibility of significantly reducing the manual effort needed to identify contact chains of infected persons and increasing the coverage of contact tracing. One of the most well-known suggestions for contact tracing comes from a collaboration of the companies Google and Apple. It is expected that the two US companies will integrate this new approach as a standard functionality into their respective mobile operating systems, Android and iOS. Some countries, including Germany, have already chosen this approach in their national contact tracing app projects.
The starting point for the experiments of the IT security experts from the three universities were previously published reports on possible data protection and security risks of the so-called “Google Apple Protocol” (GAP). The research team tested whether the attacks described on a conceptual level could be carried out in practice. Their experiments showed that GAP is susceptible to user movement profiling and may therefore allow an attacker to de-anonymize infected persons. On the other hand, so-called relay or wormhole attacks are also possible in GAP, which means that attackers can generate incorrect contact tracing data and negatively impact the accuracy and correctness of the overall system. The research team implemented the attacks using commercially available inexpensive tools such as Bluetooth sniffers (as an app on smartphones or on Raspberry Pis), which can also be used in mobile environments. Since the implementation of the GAP approach is not yet available to the broader scientific community, the research team constructed the attacks based on previously published specifications. The results show that with the help of strategically placed sensors in a certain area, the movements of infected persons, simulated by test subjects in their experiments, could be reconstructed in detail. It was possible to identify sensitive places the test subjects visited as well as possible social relationships between them.
The vulnerability of GAP to so-called relay or wormhole attacks also reveals weaknesses. This attack enables an attacker to collect the Bluetooth IDs generated by contact tracing apps, and to pass them on to more distant locations without being noticed. Among other things, Bluetooth IDs were successfully transmitted between two cities 40 kilometres apart. This could allow an attacker to compromise the contact tracing system as a whole by falsely duplicating information about the presence of infected persons in many locations, which could result in a significant increase in false alarms about the potential contacts with infected persons. Overall, the research team sees urgent need for improvement in the approach proposed by Google and Apple for contact tracing apps. A detailed description of the experiments and their results can be found in the full study report.
The Australian Covidsafe contact tracing app has been in use for roughly a month but is now facing criticism according to this news article by The Guardian. The app is following a centralised tracing approach and collects extensive information about their users (for a comparison of tracing approaches in different countries, please see here).
The app was initially marketed by the Australian government as a key requirement for being able to lift social distancing measures. However, according to the article, only one case of successful contact tracing has been attributed to the Covidsafe app so far, in spite of millions of users downloading the app. The justification for performing extensive data collection of such a large user base and the associated significant risks to their privacy seems therefore insufficient in view of the actual benefits the app can provide. In general, tracing apps should be seen as an important complementary measure to increase the coverage of manual contact tracing, but not as the main solution.
Another aspect is that it is not sufficient that users just download the app. They must be willing to actively use it. If using the app is perceived as invading user privacy, many users will simply not use it. As the article discusses, changing the privacy solution of the app later on will be very difficult. It is therefore better to select a decentralised and anonymous tracing solution from the beginning on.
As discussed in the previous blog post, the tracing process should be based on distributed contact verification. In this context, the three most notable tracing concepts proposed so far are the API proposed by Apple and Google, the Swiss-led DP-3T project proposal, and TraceCORONA developed by the Technische Universität Darmstadt, which I represent.
Of these, Apple’s and Google’s proposal is the weakest in terms of privacy properties, as it requires infected individuals to publish all Bluetooth proximity identifiers they have used during the days they may have been infectious to all devices participating in the system. It is thus possible for all applications and entities involved in the system to potentially track the movements (and thus de-anonymise) any infected persons during these days.
The Swiss-led DP-3T project’s design 2 provides better protection for infected individuals, as the local identifiers used by the infected person are only revealed to the background system in this model. Therefore, other users of the system will not be able to misuse proximity identifiers of users for tracking their movements. However, in the DP-3T design 2, it is possible to track infected persons by (mis)using the data stored in the backend system, as all proximity identifiers revealed by infected persons are known to the backend system.
Unlike almost all other proposed tracing models, the TraceCORONA tracing model is not based on frequently changing pseudonymous proximity identifiers, but on strong cryptographic Encounter Tokens that are unique to each encounter between two users. The cryptographic features of encounter tokens are such that even having unauthorised access to information in the backend system, the Encounter Token cannot be associated with the proximity data that devices beacon out via Bluetooth and may be collected with Bluetooth sensors. For this reason, identification of a contact is only possible for the actual devices that were involved in the contact and tracking of infected users is thus not possible even using backend system information. A comparison of the features of TraceCORONA and a detailed comparison with other major tracing application models is available here.
The biggest risks associated with contact tracing apps are related to the potential misuse of the information they collect. Compared to many other types of applications, an app for contact tracking inevitably collects an exceptionally large amount of sensitive information about the contacts and relationships between individual users in great detail. In addition, for a mobile application to be effective for its intended purpose, as many citizens as possible should voluntarily install the app and actively use it. Due to this, the system related to the monitoring application will collect a lot of information about the mutual contacts of people – considerably more than any other system currently used by authorities! It is clear, therefore, that the implementation of the system and the monitoring application must be designed such that effective contact tracing can be achieved, while minimizing the exposure of privacy-sensitive user data.
Centralized tracing models, such as, e.g., The TraceTogether solution used in Singapore or the CovidSafe application used in Australia, as well as the PEPP-PT model developed in Germany, do not provide adequate privacy protection for their users in this regard.
These systems are based on an approach in which a centralized back-end system assigns a unique identifier (a pseudonym) to each user’s application, from which frequently-changing pseudonymous proximity identifiers are derived and broadcast over Bluetooth to other nearby devices. The weakness of this approach is that the backend system is able to associate all proximity identifiers of all users with the unique pseudonym of each user. This in turn enables comprehensive monitoring of all users of the system.
By recording proximity identifiers observed by Bluetooth sensors in a number of strategically placed observation points in a given area (e.g. in a particular city), it is possible to track the movements of individual users between observation points and thus collect very detailed movement profiles of individual users.
Although the system does not explicitly collect or record the true identities of individual users, movement profiles based on pseudonymous tracing data make it possible to identify a large fraction of users with high probability. This is mainly because movement profiles are very distinctive. For example, using only the locations of home (main location during the night) and the workplace (main location during the day) make it possible to identify a very large proportion of people unambiguously. Also other possibilities for de-anonymisation have been proposed: for example, it is conceivable that by placing a Bluetooth sensor close to a camera system with facial recognition ability, it is in principle possible to directly associate the proximity identifier beaconed over Bluetooth and thereby the pseudonym used by the system with an identifiable person and thus entirely de-anonymise the person in question.
For reasons mentioned above, contact tracing apps should be based on decentralized identification of contacts. In this model, the backend system does not have information about proximity identifiers of users and is therefore unable to associate them with individual users. Indeed, due to the fundamental problems with the centralized tracing model, the Federal Government of Germany decided to abandon the approach of the PEPP-PT consortium, which it initially supported, and has set clear criteria for the German Coronavirus surveillance application to be based on decentralized contact tracing.
