In my last blogpost, I promised to keep you updated on the Corona-Warn-App for Germany we are building together with Deutsche Telekom and about 25 partners including start-ups that provide input and expertise. Overall, we have made significant progress. I am happy to share that we have published the scoping document, architecture document, code of conduct, and the first source code of the app on GitHub. We will continuously update the site so that everyone can see the progress of this project, provide feedback or contribute to it. It’s all about an open, agile and transparent development process.
Let’s again start with the WHY: we are developing a Corona-Warn-App to
We want to achieve all of that while minimizing the amount of personal data being exposed at the same time.
Below, I am sharing some additional information with you on the technical foundation and processes of the Corona-Warn-App providing some more details about the app itself, the lab test result verification process and the runtime environment made available through the Open Telekom Cloud.
Figure 1: High-level Architecture Overview
Corona-Warn-App
The Corona-Warn-App will be developed natively for Apple’s iOS and Google’s Android operating system. For Apple devices, an operating system version of at least 13.5 is required for the system to work. For Android, the features will be integrated into the Google Play Services, which means that only this specific application needs to be updated for it to work. To build the app we are using the Exposure Notification Framework (ENF) made available by Apple and Google. It employs Bluetooth Low Energy (BLE) mechanics that let the individual phones act as beacons that are constantly broadcasting their own temporary identifier, while scanning for identifiers of other phones at the same time. To ensure full privacy and prevent any tracking of movement patterns of the users, those broadcasted identifiers are only temporary and are changed about every 15 minutes. New identifiers are derived from a key that changes on a daily basis through means of cryptography.
Figure 2: Interaction of App and Operating System
The collected identifiers of other users are stored locally on each phone within the ENF. If users have tested positive for SARS-CoV-2, they can choose to provide a verification of their positive test to the app by selecting the option to share their own pseudo keys. As a consequence, their keys of the last 14 days are uploaded to a server. On this server, all keys of people who have tested positive are aggregated. This list of all identifiers is then made available to all mobile phones that have installed the Corona-Warn-App. In order to scale to millions of phones, this aggregated data is delivered via a Content Delivery Network (CDN).
After downloading all positive keys to the mobile device, the ENF determines whether one of the identifiers that have been collected by the phone matches one of those of an infected person. And at that point, let me emphasize one very important aspect related to privacy and security here: People who have been exposed to someone who has been tested positive are not informed by a central instance, but their phones calculate the risk of an exposure locally. This information remains on the users’ phones and is not actively shared with anybody else. Let me make this very clear: No one can identify whom a person has met. No tracing information, behavioral profiles or similar patterns can be created centrally.
Lab Test Result Verification Process
In order to prevent misuse, users need to verify that they have been tested positive before being able to upload their keys. Through this integration, the positive test results are already verified and the diagnosis keys can be uploaded right after users have given their consent. If the labs do not support the direct electronic transmission of test results to the users' phones or if users have decided against the electronic transmission of their test results a manual verification is also possible.
Below I’ll briefly describe the step-by-step interaction flow for the planned verification process for the user.
In case the test returned a positive result, users are asked to upload their keys to allow others to find out that they were exposed. If the users agree, the app retrieves a short-lived token (TAN) from the Verification Server. The TAN is uploaded together with the diagnosis keys of up to the last 14 days to the Corona-Warn-App Server.
Runtime Open Telekom Cloud
To break the chain of infection efficiently, a high adoption rate of the app is necessary. Together with the German government, Deutsche Telekom and our partners, we hope for a high number of active users. The backend that provides the required bandwidth will be made available through the Open Telekom Cloud (OTC). The servers are located in Germany. This together with Telekom’s CDN will ensure that the estimated throughput and request numbers can be handled - also at peak times. And of course loaded with the reliable Magenta Security Services made in Germany.
I can’t mention it often enough that security and privacy are at the front and center of this project. Let me give you one example of how we incorporate privacy- and security-features in the backend: To avoid creating recognizable patterns, the app randomly submits requests to the backend, even if a user has not been tested positive. They can be easily ignored on the server side, but from an outside perspective, it looks exactly as if a user has uploaded a positive test result. This helps to preserve the privacy of users actually submitting their diagnosis keys due to positive test results. All data handled by the app serves exactly two purposes: To let a user know they have come into close contact with an infected user without revealing each other's identity and to retrieve test results. And this process is well protected adhering diligently to the standards of the GDPR.
I truly believe that by following an open, agile and transparent development process we gain peoples’ trust which leads to high adoption in return. We will all benefit from an app that will warn us in case we have been close to someone diagnosed with SARS-CoV-2. This way, we can break the infection chains as early as possible without having to give up our right to privacy and security. We will keep you updated on our progress over the next few weeks. You can also follow the project on GitHub to see the progress, provide feedback or contribute to it.
In the meantime, please continue to stay safe and healthy and take care of yourselves and others.
Let’s again start with the WHY: we are developing a Corona-Warn-App to
- minimize time from a person being tested positive (index case) to being informed about a positive test result. That way, the person tested positive is hopefully not infecting anyone anymore. We do that by digitalizing the process from doctor to lab and back to the patient
- minimize time to inform citizens who were close to the index case for a certain amount time
- maximize the reach of the notification to citizens an index case was close to (e.g. on the train, in a restaurant, or similar) but does not personally know
We want to achieve all of that while minimizing the amount of personal data being exposed at the same time.
Below, I am sharing some additional information with you on the technical foundation and processes of the Corona-Warn-App providing some more details about the app itself, the lab test result verification process and the runtime environment made available through the Open Telekom Cloud.
Figure 1: High-level Architecture Overview
Corona-Warn-App
The Corona-Warn-App will be developed natively for Apple’s iOS and Google’s Android operating system. For Apple devices, an operating system version of at least 13.5 is required for the system to work. For Android, the features will be integrated into the Google Play Services, which means that only this specific application needs to be updated for it to work. To build the app we are using the Exposure Notification Framework (ENF) made available by Apple and Google. It employs Bluetooth Low Energy (BLE) mechanics that let the individual phones act as beacons that are constantly broadcasting their own temporary identifier, while scanning for identifiers of other phones at the same time. To ensure full privacy and prevent any tracking of movement patterns of the users, those broadcasted identifiers are only temporary and are changed about every 15 minutes. New identifiers are derived from a key that changes on a daily basis through means of cryptography.
Figure 2: Interaction of App and Operating System
The collected identifiers of other users are stored locally on each phone within the ENF. If users have tested positive for SARS-CoV-2, they can choose to provide a verification of their positive test to the app by selecting the option to share their own pseudo keys. As a consequence, their keys of the last 14 days are uploaded to a server. On this server, all keys of people who have tested positive are aggregated. This list of all identifiers is then made available to all mobile phones that have installed the Corona-Warn-App. In order to scale to millions of phones, this aggregated data is delivered via a Content Delivery Network (CDN).
After downloading all positive keys to the mobile device, the ENF determines whether one of the identifiers that have been collected by the phone matches one of those of an infected person. And at that point, let me emphasize one very important aspect related to privacy and security here: People who have been exposed to someone who has been tested positive are not informed by a central instance, but their phones calculate the risk of an exposure locally. This information remains on the users’ phones and is not actively shared with anybody else. Let me make this very clear: No one can identify whom a person has met. No tracing information, behavioral profiles or similar patterns can be created centrally.
Lab Test Result Verification Process
In order to prevent misuse, users need to verify that they have been tested positive before being able to upload their keys. Through this integration, the positive test results are already verified and the diagnosis keys can be uploaded right after users have given their consent. If the labs do not support the direct electronic transmission of test results to the users' phones or if users have decided against the electronic transmission of their test results a manual verification is also possible.
Below I’ll briefly describe the step-by-step interaction flow for the planned verification process for the user.
- Step 1:When a test is conducted, users receive a custom QR code that contains a globally unique identifier (GUID). Users can then scan the QR code with the Corona-Warn-App. When the code is scanned, a web service call (REST) is placed against the verification server, linking the phone with the data from the QR code through a registration token. The token is generated on the server and stored on the phone.
- Step 2:The samples are transported to the lab together with a “Probenbegleitschein”, which has a machine-readable QR code on it, as well as multiple other barcodes such as lab ID, sample IDs.
- Step 3:As soon as the test result is available, the software running locally in the lab transmits the test result to the Laboratory Information System, together with the GUID from the QR code. The Laboratory Information System stores the hashed GUID and the test result together. It is made available to the verification server through a REST interface.
- Step 4:After signing up for notifications in step 1, the users’ phones regularly check on the verification server, which in turn checks with the Laboratory Information System, whether test results are available. Once they are, the user is informed. Only after opening the app, the result is displayed together with recommendations for further actions.
In case the test returned a positive result, users are asked to upload their keys to allow others to find out that they were exposed. If the users agree, the app retrieves a short-lived token (TAN) from the Verification Server. The TAN is uploaded together with the diagnosis keys of up to the last 14 days to the Corona-Warn-App Server.
Runtime Open Telekom Cloud
To break the chain of infection efficiently, a high adoption rate of the app is necessary. Together with the German government, Deutsche Telekom and our partners, we hope for a high number of active users. The backend that provides the required bandwidth will be made available through the Open Telekom Cloud (OTC). The servers are located in Germany. This together with Telekom’s CDN will ensure that the estimated throughput and request numbers can be handled - also at peak times. And of course loaded with the reliable Magenta Security Services made in Germany.
I can’t mention it often enough that security and privacy are at the front and center of this project. Let me give you one example of how we incorporate privacy- and security-features in the backend: To avoid creating recognizable patterns, the app randomly submits requests to the backend, even if a user has not been tested positive. They can be easily ignored on the server side, but from an outside perspective, it looks exactly as if a user has uploaded a positive test result. This helps to preserve the privacy of users actually submitting their diagnosis keys due to positive test results. All data handled by the app serves exactly two purposes: To let a user know they have come into close contact with an infected user without revealing each other's identity and to retrieve test results. And this process is well protected adhering diligently to the standards of the GDPR.
I truly believe that by following an open, agile and transparent development process we gain peoples’ trust which leads to high adoption in return. We will all benefit from an app that will warn us in case we have been close to someone diagnosed with SARS-CoV-2. This way, we can break the infection chains as early as possible without having to give up our right to privacy and security. We will keep you updated on our progress over the next few weeks. You can also follow the project on GitHub to see the progress, provide feedback or contribute to it.
In the meantime, please continue to stay safe and healthy and take care of yourselves and others.
- SAP Managed Tags:
1 Comment
