These Risks emanate from the Switzerland Contact Tracing App
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.
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).
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.
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).
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.
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.
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.
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.
Our experts will get in contact with you!
Our experts will get in contact with you!
Further articles available here