Contact Tracing App DP3T - These are the Risks of the Swiss Solution

Contact Tracing App DP3T

These are the Risks of the Swiss Solution

Marc Ruef
by Marc Ruef
time to read: 7 minutes

Keypoints

These Risks emanate from the Switzerland Contact Tracing App

  • In order to contain the corona crisis, various countries want to use so-called contact tracing apps
  • These are used to record contacts via smartphones
  • The DP3T solution from ETH and EPFL is based on a decentralized approach as far as possible in order to respect the security concerns of users
  • This article summarizes the remaining risks

In the course of the Corona crisis, various countries are trying to trace and break the infection chains with the help of so-called Contact Tracing Apps. In Switzerland, the framework DP3T, which is being developed by ETH Zurich and EPFL Lausanne, is available. This article shows the possibilities and risks of the solution.

The approaches used by DP3T obviously aim to provide maximum security and privacy for the end users. The transparency lived through the project is exemplary, both the documentation and a sample implementation are available on GitHub. Thus, different security procedures are used to ensure a secure and as anonymous as possible use. These are used sensibly and show a high awareness of the risks that need to be addressed. In contrast to many other frameworks and products, the focus here is very much on the needs of the end user. The Swiss solution is therefore a step ahead of products from other countries and manufacturers.

The following is a summary of the major active risks of DP3T that have been identified during the review of the documentation and source code. The document Privacy and Security Attacks on Digital Proximity Tracing Systems published by the project addresses some additional attack possibilities. The references in parentheses in this text refer to this document.

Increased Attack Surface of the Smartphone by App

The installation of any additional software naturally increases the attack surface of a device. A flawed implementation can cause attackers to misuse the apps in their own context or even break out of context.

It is therefore important that the implementation is subjected to careful security checks (concept review, source code analysis, penetration test).

Analysis of Communication to Backend Servers

A person can declare himself as “infected” via his device after a diagnosis has been made in cooperation with his doctor. This information is sent to a centralized backend server. Communication is also established with this server on a regular basis to download the inventory of current infections.

Someone who is able to read this communication – this includes primarily providers and server operators – can request statistical evaluations of these communications (NR 1, NR 2). By analyzing meta-data, for example, it may be possible to identify contacts via IP address ranges and geolocation. And fingerprinting can be used to track individual users. The more data available, the better the detection of identities and relationships can be achieved. In this case, one must therefore trust that no such evaluation takes place.

With DP3T we are talking about a primarily decentralized approach, since the storage and evaluation of contact relationships is done exclusively on the end devices. Only the IDs and infections are stored on the centralized server. This is the decisive advantage of the framework.

Increase of Attacks on Bluetooth

The app requires the activation of Bluetooth LE. This also increases the attack surface of the device. Vulnerabilities such as CVE-2020-0022 (Android), CVE-2020-9770 (iOS) and CVE-2019-9506 (different platforms) demonstrate that the issue is to be considered.

It is foreseeable that Bluetooth and the respective implementations will thus come into the focus of various attackers. An increase in research and publication of vulnerabilities as well as attacks and exploits in this area can be expected.

Through the general manipulation of basic Bluetooth communications, contacts can also be prevented (Jamming, GR 4) or faked (Extending, GR 1, GR 2).

Identifiability thanks to Bluetooth by Third Parties

Activating Bluetooth may also make the device identifiable for other purposes (GR 5, GR 6). For example, targeted proximity marketing can be implemented. Users who want to counteract this specifically would have to give up using the app with Bluetooth.

Own Implementation to increase Identifiability

An attacker could implement his own implementation of the smartphone app, in which after each contact with another device, this is stored in a separate account (IR 1, GR 3). Additionally, other identification features such as time, GPS position, name of nearby hotspots, etc. can be created.

If a known device is then marked as “infected”, it is easier to draw conclusions about which device it was and where the contact took place, thanks to the own and minimized correlation.

The implementation of such an attack requires an increased level of technical understanding and criminal energy. In addition, the possibility of evaluation remains limited, since ultimately only those users can be de-anonymized that could be created in a personal contact. A broad de-anonymization, especially of persons outside of personal contact, is not possible.

Limitations through Decentralization

The introduction of decentralization addresses the security concerns of the end users. At the same time, however, it is associated with restrictions for centralized evaluation.

The Federal Council and the FOPH (Federal Office of Public Health) are thus prevented from better understanding trends in a geographical context. For example, it is not possible to say exactly whether dangerous hotspots are developing in certain places in Switzerland, thus giving up a useful strategic tool.

Conclusion

The design and implementation of the framework makes great efforts to minimize the weaknesses and risks. The simple declaration as decentralized solution may be correct for the evaluation of personal contact relationships. Nevertheless, a central database server is used to provide the end devices with the current data of verified infections.

To claim in general that the framework solves all problems regarding security and privacy is naive. Certain residual risks remain. Whether and to what extent a participant wants to use this app must therefore be weighed up personally.

About the Author

Marc Ruef

Marc Ruef has been working in information security since the late 1990s. He is well-known for his many publications and books. The last one called The Art of Penetration Testing is discussing security testing in detail. He is a lecturer at several faculties, like ETH, HWZ, HSLU and IKF. (ORCID 0000-0002-1328-6357)

Links

You are looking for an interview partner?

Our experts will get in contact with you!

×
Specific Criticism of CVSS4

Specific Criticism of CVSS4

Marc Ruef

scip Cybersecurity Forecast

scip Cybersecurity Forecast

Marc Ruef

Voice Authentication

Voice Authentication

Marc Ruef

Bug Bounty

Bug Bounty

Marc Ruef

You want more?

Further articles available here

You need support in such a project?

Our experts will get in contact with you!

You want more?

Further articles available here