applicationContext = Production

The ContacTUM Contact Tracing App

In spring 2020, the ContacTUM Consortium together with ITO developed a privacy and efficacy improved DCTS concept following the decentraliced approach and including Private Set Intersection Cardinality and second order tracing. The DCTS app based on this concept is available for download on the ITO website. DCTS stands for Digital Contact Tracing System, for which  now the term Covid-19 Exposure Notification System is commonly used.

In the following, we describe the concept of the ContacTUM DCTS app aiming at general understandability and give information on other DCTS approaches. For more technical details, we refer to our DCTS publication. Information on the apps officially provided in different countries can be found here.

How the app works in the background

Ones the app is installed and Bluetooth Low Energy is activated, the app sends out Bluetooth signals at regular intervals.

Each signal contains

  • a randomized number produced by the app
  • the encrypted information on the day and time at the moment of the sending (timestamp)
  • information on the signal strength of the Bluetooth Low Energy signal

We call this signal Temporary Contact Number (TCN). Obviously, this signal is never the same, because of the encrypted time information. But also the randomized number changes after certain, fixed time intervals. The randomized number is produced by a key generated by the app. This key is also regularly renewed. Thus, from the TCN no conclusion about the identity of the user or his/her mobile phone can be drawn.

The signals, or TCNs, are received and stored by other mobile phones nearby that have also installed the app. At the same time, the app records and stores the TCNs of other phones in the close vicinity.

The intensity of a contact to another person can be assessed by the period of time one was in contact with another person (time stamps) and the distance at which one met (signal strength). The intensity of the contact can be used as a basis for the evaluation of the infection risk in case the person one met tests positive for the virus SARS-Cov-2.

After two or three weeks - the period depends on the virologists' assessment of the incubation period - the stored TCNs on the mobile phone are automatically deleted.

The app should be activated throughout the day while the user is at office or school, goes shopping or to the theater, and of course, the user should keep the phone always close to him or her.

If you got infected

If you have been tested positive for the virus, it would be a good practice to let the people you have recently met know that you are infected. This gives them the opportunity to quarantine, get tested and eventually prevent your contacts from passing the disease on. Informing your contacts is what the app can do for you, if you allow it. Mind that the app will not reveal your identity, the information is strictly anonymous. Your contacts only learn that they have met someone who has now been tested positive.

For informing your contacts, the app will upload your TCNs to the central server. To do so, you need the permission of a doctor or another medical authority. (This procedure is intended to prevent misuse, for example to prevent that someone who is not infected loads his TCNs onto the server.) The permission can be granted in various ways. In any case, only medical personnel have access or can grant access to the server to perform the upload of your "infected" TCNs.

Thus, if you agree, the TCNs you have sent out to other mobile phones will be uploaded to a central server where they are verified and encrypted before being made available. Your identity remains secret throughout the process.

How the app receives information about infected contacts

The signals, or TCNs, of infected persons are uploaded to a central server and stored. Each app regularly downloads the "infected" TCNs that are newly stored at the central server.

The app then automatically checks ones stored contact TCNs with the downloaded "infected" TCNs. A match between two TCNs means that you have had contact with an infected person. If the app detects such a match, you will be notified immediately. The app can also perform an infection risk assessment based on the intensity of the contact. The risk assessment can be included in the notification. As was said above, the TCN does not reveal the identity of the infected person. Thus, you don't know who our infected contact was, you only know that you had an "infected" contact and there is the a risk that you have contracted the virus.

It is important to note that the central server just serves the purpose of pushing "infected" TCNs to the apps. Centrally, no contact information are gathered or contact matches are made. Encounters with infected people are only noticed decentralized on the user's app and only revealed to the user. This is why the approach is called decentralized. It is designed such that it completely preserves the identity of the infected person and the privacy of the people in contact.

If you are notified of having an infectious contact

If you are informed by your app to have been in contact with an infected person, you should handle this information with all due responsibility. After all, you are the only person to know!

You should immediately quarantine and get tested as soon as possible to verify whether you have contracted the virus.

Privacy by design as a guiding principle

Our current proposal aims at fighting infectious diseases in an effective manner while safeguarding and realizing the citizens' rights, freedoms and legitimate interests. We focus on privacy and IT-security concerns. In the spirit of a privacy by design solution, we incorporated legal principles and requirements into the very design of our solution. While our first point of reference was the European Union's General Data Protection Regulation (GDPR) (Datenschutz-Grundverordnung), there exist similar and equivalent principles and requirements in many legal orders, including the Council of Europe’s Convention 108. These include:

  • lawfulness, fairness and transparency
  • purpose limitation
  • data minimisation
  • accuracy
  • storage limitation
  • integrity and confidentiality
  • accountability

While the concept laid out here addresses many principles and requirements, its actual implementation will contain further technical and organizational measures in order to mitigate risks and further issues. This is particularly true for data subjects rights like the right to rectification and the right to erasure. A further development of the application will also have to look into other issues like inclusion, fairness, transparency and effective governance of the application.

Having this in mind, we outline how data protection and privacy is secured by design in the ContacTUM DCTS app at each data generating and processing step:

Generating Temporary Contact Numbers (TCNs)

Once the app on the mobile phone is activated, the app generates a key, which it uses to generate a random number called. This Temporary Contact Number (TCN) does not contain any information about the identity of the user or the relating mobile phone or app. It is sent out as a Bluetooth signal that contains the TCN, the encrypted day and time of the sending and the Bluetooth signal strength. Without the key, the TCN cannot be assigned to a certain user or app. The phone advertises the TCN via Bluetooth at brief time intervals, such that other devices in the vicinity of the user can see the TCN. After a short while, a new TCN is generated and advertised. Also the key is renewed after some time. The app stores the advertised TCNs for a period of two or three weeks, depending on what is sensible concerning the infectious period of the virus. If there is no suspicion of infection with SARS-Cov-2 after hat period, the old TCNs are deleted. The TCNs are thus generated in a way that ensures that the identity of the user remains protected.

Storing TCNs of neighboring phones

In parallel to advertising the TCNs, the Bluetooth activated on the device continuously scans for other devices in its vicinity. When neighboring devices are detected, the app stores the observed TCNs. The intensity of the contact can be calculated using the timestamps and the received signal strength as a measure for the vicinity. Encountered TCNs are only stored for a time period of two or three weeks, after that the old TCNs are deleted. From the TCNs stored on the phone no conclusions can be drawn about the identity of the contact persons.

Uploading TCNs to the server

If a user is tested positive for the virus, the patient is encouraged by medical authorities to provide the TCNs advertised over a period of two or three weeks. The patient is informed about the data protection and privacy preserving measures in place. If the patient agrees, his or her advertised TCNs are uploaded to a server where they are verified and encrypted before being made available. Two scenarios are possible:

  • Scencario 1: The patient gets the permission by a medical authority to upload the generated TCNs, and keys to a server. This permission can be granted in various ways. The patient then proceeds to upload the keys. The server regenerates and verifies the patient’s TCNs with the provided keys. The verification prevents impersonation of other users. At the server, the keys are deleted after the verification process.

  • Scenario 2: The patient provides the keys used for TCN generation to the medical personnel, e.g. by showing a QR code with the keys to an authorized person. The medical personnel then verifies the TCNs by regenerating them and uploading the regenerated TCNs to the server following an authentication procedure (e.g. username and password of medical authority). The medical personnel deletes the keys after the upload.

Scenario 2 completely ensures the user's anonymity since the verification of the TCNs with the keys is not performed on the server and the TCN upload does not require to use mobile data or Wifi.

Handling TCNs on the server

The server collects newly uploaded TCNs for a predefined period of time, e.g. one hour, and shuffles their order to avoid the association of several TCNs to a single user. Then, the server stores the shuffled batch of TCNs to its main database. TCNs are stored for two or three weeks and are then automatically deleted.

Downloading TCNs from the server

In parallel to the continued advertisement of TCNs, the app checks regularly, e.g., once per hour, for new TCNs on the server. If new TCNs are present, the app retrieves information about them from the server. The patients’ TCNs are then matched against the encountered TCNs registered on the device of the user during a period of two/three weeks. This matching is done on the user’s phone. If the app detects a match, the user immediately receives that he or she has been in contact with an infected person.

We present two approaches on how to detect infectious encounters:

  • Direct download of TCNs: In order to check whether the user has been in contact with an infected person, they download all unchecked TCNs stored on the server and check for matches within their own list of observed TCNs. When encountering matches, the app can perform a risk assessment based on the intensity of the contact. The risk assessment can be included in the notification.
  • Checking for overlap of stored and infected TCNs: In this approach, the app is not downloading the infected TCNs, but just checking for the TCNs that are both in the set of contact TCNs and in the set of infected TCNs. This is done by so called Private Set Intersection, an encryption technique to compare encrypted versions of these sets in order to compute the intersection. Thus, neither party reveals anything to the counter-party except for the elements in the intersection. The technique is accompanied by a loss of information on the assessment of the infection risk. Getting around the issue could be done by e.g. introducing categories like high, medium, and low infection risk and sorting the encountered TCNs into these categories, depending on the contact intensity. Then the number of overlapping TCNs in each category can be checked, which provides a measure for the overall infection risk.

 

The underlying technology

Bluetooth Low Energy is a standard for making wireless connections over short distances by sending and receiving signals at the open 2.4 GHz radio frequencies. It should not be confused with the 'Classical' Bluetooth used for streaming e.g. audio to headphones. As the name indicates, applications based on Bluetooth Low Energy consume very little energy. Since BLE as a standard technology is present in practically every smartphone, it is suitable for the requirements of a Digital Contact Tracing Service realized on a mobile phone app. The Bluetooth Low Energy standard is maintained and marketed by the Bluetooth Special Interest Group (Bluetooth SIG).

Contact intensity estimation with Bluetooth Low Energy

According to the German Robert-Koch-Institute, people with a cumulative face-to-face contact for at least 15 minutes at a distance of 1.5 meter or less bear a higher infection risk (contact persons of category 1). For a Digital Contact Tracing Service, a technology is needed that can provide information on the duration of a contact to another person and the distance at which the person was met. Distance and duration together result in an estimate of the contact intensity which is a measure for the infection risk. Both values can be obtained by exploiting the Bluetooth Low Energy standard.

The duration of a contact can be measured very precisely using the timestamp information that is contained in the TCN signal, thus, when the app receives several identical TCNs, the duration equals the first timestamp minus the last timestamp.

The distance cannot be measured directly with Bluetooth Low Energy. But in principle, the information can be attained by comparing the information on the sender's signal strength with the received signal strength, or in the technical term: using the relative Received Signal Strength Indicator (RSSI). The distance should then be proportional to the attenuation of the signal: the weaker the RSSI compared to the transmitted signal, the greater the distance. However, there is a calibration and an ambient related issue:

  • The transmitted signals are not calibrated and can differ from device to device, resulting in distance errors. At the moment, experts assume that the error is of the order of roughly two meters. The ContacTUM collaboration is currently setting up experiments to determine the error systematically. 
  • The RSSI does not bear any information on where the mobile phone was kept: If the mobile phone is carried in a bag, a jacket, or a pocket, the signal gets attenuated and it looks as if the contact person was farther away than he or she actually was. The distance is underestimated in such cases. Also, walls and glass panes weaken the signal, the distances appear larger and the measurements may not be considered as a contact. At least, in this case the measurements are going in the right direction: People from whom we are separated by glass panes or walls pose no or very little risk of infection, depending on the size of the walls or panes. In any case, these ambient related issues should not be neglected.

As a result, obtaining the distance by using the Bluetooth Low Energy signal strengths will only give an approximation of the true distance. But it is assumed that together with the time information, a satisfactory assessment of the contact intensity and thus the infection risk can be achieved.

 

A DCTS that involves the processing of personal data must comply with the strict requirements of the EU's General Data Protection Regulation (GDPR) (Datenschutz-Grundverordnung DSGVO). This applies regardless whether the app is operated by a public authority or a private institution. Here we present a brief preliminary assessment of legal questions that arise in connection with a DCTS app (please note that this assessment is neither exhaustive nor final):

Is the GDPR applicable?

According to Art. 1, Sec. 1, the GDPR only applies to the processing of personal data.

Art. 4, Sec. 1 defines personal data as "any information relating to an identified or identifiable natural person ('data subject'); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person".

Recital (26) says: "Personal data which have undergone pseudonymisation, which could be attributed to a natural person by the use of additional information should be considered to be information on an identifiable natural person."

There is a strong indication that the GDPR is applicable, because it cannot be ruled out that individual pieces of information in the processing chain of the DCTS app will be personally identifiable by the use of additional information. This applies both to the advertised TCNs (which could in principle be attributed to a natural person by the use of the respective keys), the keys themselves, the – implicit – attribute “tested positive” as well as the determination of the “contact”. In addition, IP addresses as well as mac addresses are typically considered as information on an identifiable natural person. This personal data will be processed, i.e. stored, uploaded and matched, at various stages during the operation of the DCTS app.

Is the data processed lawfully?

Pursuant ot Art. 6 GDPR, any processing of personal data requires explicit authorization.

To the extent that health data are concerned (as would be the case with the - implicit - attribute "tested positive"), even stricter requirements must bet met under Art. 9 GDPR.

However, in parallel with Art 6, Sec. 1, Subsec. a, Art. 9 Sec. 2. Subsec. a GDPR provides a justification if the effective consent of all those affected is obtained.

As is laid out above, the DCTS app is conceived to function on a voluntary basis. In fact, the voluntary nature is a crucial factor for achieving widespread acceptance and trust among the population for any digital contact tracing system. It should be noted that some commentators have raised doubts whether a DCTS app can realistically be regarded as strictly voluntary because it may at least foster some form of indirect compulsion if the use of the DCTS app becomes a de-facto  condition for taking part in public and social life. Therefore, it is all the more important, that the non-use of the DCTS must not effectuate any weakening of an individual's legal position vis-à-vis the state.

This means that, in principle, the DCTS app’s processing of personal data may be justified through formal consent of each and every individual app user pursuant to Art. 6 Sec. 1 Subsec. a. GDPR, Art. 9 Sec. 2 Subsec. a. GDPR. However, it should be born in mind that the declaration consent must meet certain requirements set out in Art. 7 GDPR and additionally Art. 8 GDPR. These provisions stipulate that:

  • the declaration consent must be explicit
  • the declaration consent must be free of any kind of compulsion
  • sufficient, very comprehensible information is provided in an easy language that is appropriate for the addressee, based on which the addressee can form their decision ("informed consent")

Is the principle of proportionality observed?

In principle, the processing of personal data constitutes an encroachment on the fundamental right of informational self-determination. Even if this invasion can be justified (in this case: by consent, see above), it is nonetheless subject to the principle of proportionality. Thus, a legitimate purpose must be pursued through the use of the DCTS app and the means for achieving this must be suitable, necessary and appropriate. The principles of proportionality must be equally observed in the case of voluntary (i.e. consented) app use, especially since the boundaries of voluntariness and compulsion may be blurred in the case of "urgent recommendations" on the part of the federal government as well as state governments and affiliated public institutions.

The purpose of the app it identifying chains of contacts to contribute to slowing down the spread of the virus in order to avoid overburdening the healthcare system while easing exit and contact restrictions. In this way, a balance between health protection and restrictions on fundamental rights should be achieved. At present, we still live under considerable restrictions of our fundamental rights (freedom of occupation, property, freedom of assembly, freedom of movement, freedom of religion, etc.). The app is intended to help reduce these restrictions, but at the same time provide sufficient health protection. This is undoubtedly a legitimate, and from a fundamental rights point of view, even welcome purpose.

The means used is a warning and protection system based on a disclosure of the fact of positively tested contacts, in order to give the persons affected the opportunity to take protective measures for themselves and third parties. In principle, this means is suitable to fulfil the purpose. Because of the voluntary nature of the system, it is currently unclear whether the DCTS app will ultimately be successful. From a constitutional point of view, the principle of proportionality is only violated if a proposed means is “utterly unsuitable” (according to the German Federal Constitutional Court in its settled case law). Since it cannot be ruled out that the DCTS app will fulfil its purpose, it currently meets the suitability threshold. Nevertheless, further evaluating the efficiency of digital contact tracing by refining the statistic models is a key component of the ContacTUM group’s DCTS research efforts, not least in order to further inform the dynamic proportionality assessment.

The next step is to assess whether the concrete setup of the DCTS app is necessary to achieve its purpose. This would not be the case if there were milder means that would be equally suitable to fulfill the purpose. Such a milder means is not immediately apparent: Continuing the lockdown would make the app unnecessary, but would prolong the considerable restrictions on other fundamental rights and is therefore not a preferable alternative. Relaxing the current contact and exit restrictions without installing a digital contact tracing system seems equally risky, because it is to be feared that people are not sufficiently sensitive to necessary self-restrictions.

However, in terms of necessity, there may be a crucial distinction between the two fundamental approaches to digital contact tracing, i.e. centralized and a decentralized data reconciliation:

  • The decentralized approach (as chosen in the proposed DCTS app) could be viewed as a milder remedy compared to the centralized approach. This is because with central data reconciliation, all advertised TCNs would regularly be uploaded and stored together on the authenti- cation server, at least for a short time. Thus, the risk of re-identification of affected persons may be greater.

  • The decentralized approach seems more in line with the aforementioned principle of data minimization (Art. 5 Sec. 1 Sub- sec. c. GDPR) – which is, in essence, a materialization of the principle of proportionality. In the decentralized approach, only the positive cases are stored on the central server, while the actual data reconciliation takes place on the app on the end device. From the perspective of an app user, this aspect could increase the willingness to participate in a digital contact tracing system.

  • Although there are currently no plans combine the use of the DCTS app with compulsory protective measures, such as home quarantine or testing, some people may fear that the fact that they have tested positive could become known to third parties. In the decentralized approach, this fact would only be visible on the smartphone of the person concerned, i.e. it would be “in their hands”. From a necessity point of view, this could also speak in favour of the decentralized variant.

  • Achieving widespread acceptance and trust among the population is the key factor for any DCTS's success. Only if the potential users trust in the app’s privacy architecture, they will actually use and follow the app in their daily lives. Against this background, it is crucial to obtain the endorsement of trustworthy institutions like the data protection agencies.

Assuming that centralized and decentralized approaches to designing a DCTS are equally suitable to contribute to slowing down the spread of the virus, there are good arguments, that a decentralized approach is the preferable approach both form a proportionality and data minimization point of view.

Further requirements under GDPR

In addition, a range of procedural precautions must be observed in the process of developing the DCTS app. None of these requirements stand in the way of developing the DCTS app, need to be incorporated from the outset of the design process to guarantee a compliant and thus sustainable use. Among others, the precautions include in particular:

  • fulfilling certain information obligations (Art. 13 ff. GDPR), in particular with regard to the rights of the user, such as the right to information, the information, the right to invoke consent, the right to deletion, the right to correction
  • ensuring data protection through technology design and data protection-friendly default settings (Art. 25 GDPR)
  • ensuring IT security (Art. 32 GDPR)
  • providing proper information in case of a data breach (Art. 33 GDPR)
  • carry out data protection impact assessment (Art. 35 GDPR)

Here we evaluate possible attack scenarios. These attack scenarios are not theoretical. Reports from South Korea where the government was collecting and releasing private data to trace infected people's movement in order to find their contacts show that attacks and misuse are done against private individuals to invade their privacy. This emphasises the importance of an approach which collects minimal data and where such attacks are prevented by design. The attack scenarios described here are not exhaustive.

Revealing the identity of an infected person

Risk: The identity of an infected people could be revealed if someone installs an app and records the people passing by using a video camera.

Scenario: The attacker can install the app on a device and install the device somewhere together with a video camera. The camera records the people passing by and the device records the peoples’ advertised TCNs together with the time. After some days, one of the people who passed the device and the camera finds out that they have been infected and uploads their TCNs to the server. The attacker can now download them and compare them with the TCNs on their device. The app detects a match. Now the attacker can check the matching TCNs and access the time on the database. Then, the attacker checks the video feed at that time and can possibly identify the infected individuals.

Defense: The use of private set intersection cardinality protects further the identity of infected people. The attacker can still query the server multiple times to find out which of their contact TCNs was infected. Thus, a rate of queries needs to be limited to make these attacks more expensive. This type of linkage attack is in general possible with any proximity tracing app, which exchanges TCNs and notifies users. Any tech-savvy user can either use several devices, register their app mulitple times, modify the app and record the identities of other users. With PSI-cardinality and a rate limit, this attack becomes difficult and expensive.

Rebroadcasting of TCNs

Risk: People could get false notifications of exposures triggered by falsely broadcasted TCNs.

Scenario: An attacker can use received contact TCNs and rebroadcast them as their own. In case of an infected attacker, the users would not get any notification, because the wrong TCNs, not the attackers’ own TCNs, have been advertised.

Defense: Each TCN is concatenated with the time interval number. This time interval number is valid for ten minutes. If an attacker received a TCN from a neighbouring phone, they could rebroadcast this TCN to other users. In case this TCN is later marked as infected, only users who received this TCN from the attacker within the ten minute time interval will get a notification. The introduction of the time interval number reduces the validity of each TCN and thus puts a limit on this rebroadcasting attack. In the case of an infected attacker, the users would indeed never get notified of their possible exposure, since the attacker uploads their own TCNs. This would be the same if a person had their Bluetooth switched off, refused to upload their TCNs, or if they had not installed the app at all.

Uploading somebody else's TCN

Risk: People could get false notifications of exposure by TCNs falsely uploaded to the server as infected.

Scenario: An attacker tries to upload somebody else's TCNs in order to mark the as infectious.

Defense: When receiving TCNs, the key needed for TCN generation is not transmitted. Thus, if the user is asked to upload their pseudo random TCNs, they need to provide the key they used for generating these TCNs. The server or the medical personels directly generates the TCNs with the keys, such that the TCNs are verified and the attacker cannot simply exchange TCNs. The attacker could of course try to provide fake keys, in which case the uploaded TCNs would not lead to any encounter notification, because the TCNs were never broadcasted.

Forcing someone into self-quarantine

Risk: People could get false notifications of exposure by someone having reported themselves falsely as infected.

Scenario: An attacker can force someone into quarantine by getting into close proximity to the person and trying to self-report themselves as infected.

Defense: The server is not directly accessible for the user. A user can only connect to the server if they have been granted access by medical personnel (by e.g. a TAN or a QR code). Medical personnel only grant access if the user has tested positive for COVID-19. The only case where self reporting is possible, is if the user has been exposed to an infected user, got the notifica- tion and can prove to the server with a zero-knowledge proof that they know an infected TCN. This knowledge serves as authorization to the server and allows the user to upload their own keys for TCN generation. These can be marked as second order TCNs and enable second order tracing of contacts as described

Print