Merge pull request #1 from corona-warn-app/master

Merging back

.gitignore

@@ -0,0 +1 @@
+.DS_STORE

README.md

@@ -1,11 +1,28 @@
-# Corona-Warn-App
+<p align="center">
+ <a href="https://www.coronawarn.app/en/"><img src="https://raw.githubusercontent.com/corona-warn-app/cwa-documentation/master/images/CWA_title.png" width="400"></a>
+</p>
+
+<hr />
+<p align="center">
+    <a href="#about-this-project">About this Project</a> • 
+    <a href="#who-we-are">Who We Are</a> •
+    <a href="#credits">Credits</a> •
+    <a href="#data-privacy">Data Privacy</a> •
+    <a href="#code-of-conduct">Code of Conduct</a> •
+    <a href="#working-language">Working Language</a> •
+    <a href="#our-documentation">Our Documentation</a> •
+    <a href="#licensing">Licensing</a> •
+    <a href="#how-to-contribute">How to Contribute</a> •
+    <a href="https://www.coronawarn.app/en/">Web Site</a>
+</p>
+<hr />
 
 NOTE: This README is also available [in German](translations/README.de.md). Thank you for understanding that the German version might not always be up-to-date with the English one.
 
 HINWEIS: Diese README ist ebenfalls [auf Deutsch](translations/README.de.md) verfügbar. Bitte haben Sie Verständnis, dass die deutsche Version nicht immer auf dem gleichen Stand wie die englische Version ist.
 
 ## About this Project
-We are developing the official COVID-19 exposure notification app for Germany, called "Corona-Warn-App". This project has the goal to develop an app based on technology with a decentralized approach -  heavily inspired by the [DP-3T](https://github.com/DP-3T/documents) (Decentralized Privacy-Preserving Proximity Tracing) and [TCN](https://tcn-coalition.org/) protocols and based on the [Privacy-Preserving Contact Tracing specifications](https://www.apple.com/covid19/contacttracing/) by Apple and Google. Like DP-3T and the TCN Protocol, the apps and backend infrastructure will be entirely open source - licensed under the [Apache 2.0 license](LICENSE)! The apps (for iOS and Android) will collect pseudonymous data from nearby mobile phones using Bluetooth technology. The data will be stored locally on each device preventing access and control over data by authorities or anyone else. We will meet the applicable data protection standards and guarantee a high level of IT security. By doing so, we are addressing people's privacy concerns and thereby aiming to increase the adoption of the app.
+We are developing the official COVID-19 exposure notification app for Germany, called "<a href="https://www.coronawarn.app/en/">Corona-Warn-App</a>". This project has the goal to develop an app based on technology with a decentralized approach -  heavily inspired by the [DP-3T](https://github.com/DP-3T/documents) (Decentralized Privacy-Preserving Proximity Tracing) and [TCN](https://tcn-coalition.org/) protocols and based on the [Privacy-Preserving Contact Tracing specifications](https://www.apple.com/covid19/contacttracing/) by Apple and Google. Like DP-3T and the TCN Protocol, the apps and backend infrastructure will be entirely open source - licensed under the [Apache 2.0 license](LICENSE)! The apps (for iOS and Android) will collect pseudonymous data from nearby mobile phones using Bluetooth technology. The data will be stored locally on each device preventing access and control over data by authorities or anyone else. We will meet the applicable data protection standards and guarantee a high level of IT security. By doing so, we are addressing people's privacy concerns and thereby aiming to increase the adoption of the app.
 
 ## Who We Are
 
@@ -34,16 +51,21 @@ This repository contains the developer documentation and related content.
 ### Project Scope
 The project scope has been agreed on jointly by Deutsche Telekom AG and SAP SE as contractors and the German Federal Government and the Robert-Koch-Institut as clients. The project scope might change over time as new requirements need to be included or existing ones change. We appreciate feedback to all elements of this project scope document. However, additional features or any other content changes beyond fixes to grammatical issues or typos need to be aligned on by these partners before they can be included in the document. Thank you for your understanding!
 - [Corona-Warn-App - Scoping Document](scoping_document.md)
+- [Corona-Warn-App - User Interface Screens](ui_screens.md)
 
 ### Technical Documentation
 The technical documents are intended for a technical audience and represent the most recent state of the architecture. The solution architecture and concepts might change over time as external dependencies (e.g. the framework provided by Apple/Google) are still changing and new requirements need to be included or existing ones change. We appreciate feedback to all elements of these technical documents. 
+
 * [Corona-Warn-App - Solution Architecture](solution_architecture.md)
+* [Corona-Warn-App Server Architecture](https://github.com/corona-warn-app/cwa-server/blob/master/docs/architecture-overview.md)
+* [Corona-Warn-App Verification Server Software Design](https://github.com/corona-warn-app/cwa-verification-server/blob/master/docs/architecture-overview.md)
+* [Corona-Warn-App Verification Portal Server Software Design](https://github.com/corona-warn-app/cwa-verification-portal/blob/master/docs/architecture-overview.md)
+* [Corona-Warn-App Test Result Server Software Design](https://github.com/corona-warn-app/cwa-testresult-server/blob/master/docs/architecture-overview.md)
+* [Corona-Warn-App Mobile Client (Android) Architecture](https://github.com/corona-warn-app/cwa-app-android/blob/master/docs/architecture-overview.md)
+* [Corona-Warn-App Mobile Client (iOS) Architecture](https://github.com/corona-warn-app/cwa-app-ios/blob/development/docs/architecture-overview.md)
+* [Criteria for the Evaluation of Contact Tracing Apps](pruefsteine.md)
 
 To be published:
-* Corona-Warn-App - Mobile Architecture for iOS and Android
-* Corona-Warn-App - Server Architecture
-* Verification Server Architecture
-* Portal Server Architecture
 * System Operation
 * Technical Security Concept
 * Data Privacy Concept
@@ -61,6 +83,8 @@ You may obtain a copy of the License at https://www.apache.org/licenses/LICENSE-
 
 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the [LICENSE](./LICENSE) for the specific language governing permissions and limitations under the License.
 
+The "Corona-Warn-App" logo is a registered trademark of The Press and Information Office of the Federal Government. For more information please see [bundesregierung.de](https://www.bundesregierung.de/breg-en/federal-government/federal-press-office).
+
 ## How to Contribute
 
 Please see our [CONTRIBUTING.md](CONTRIBUTING.md) for details on how to contribute, our team setup, the project structure and additional details which you need to know to work with us.

glossary.md

@@ -16,6 +16,7 @@ This overview provides a description for all acronyms and special terms which ar
 | CWA | The [Corona-Warn-App](https://github.com/corona-warn-app/cwa-documentation), the official COVID-19 exposure notification app for Germany. |
 | Diagnosis Key(s) | The subset of Temporary Exposure Keys uploaded when the device owner is diagnosed as positive for the coronavirus. See also the [Exposure Notification Bluetooth Specification](https://covid19-static.cdn-apple.com/applications/covid19/current/static/contact-tracing/pdf/ExposureNotification-BluetoothSpecificationv1.2.pdf) | 
 | DP-3T | [Decentralized Privacy-Preserving Proximity Tracing](https://github.com/DP-3T/documents), another approach to an exposure notification app, mainly driven by institutions from Switzerland. |
+| ENA | Acronym for "Exposure Notification App", used as internal identifier for the Corona-Warn-App in certain locations. |
 | FAQ | Frequently Asked Questions |
 | GUID | Acronym for "[Globally Unique Identifier](https://en.wikipedia.org/wiki/Universally_unique_identifier)". |
 | IfSG | The [German Prevention and Control Act of infectious diseases among humans](https://www.gesetze-im-internet.de/ifsg/index.html), acronym for "Infektionsschutzgesetz", long term: "Gesetz zur Verhütung und Bekämpfung von Infektionskrankheiten beim Menschen". | 
@@ -29,7 +30,7 @@ This overview provides a description for all acronyms and special terms which ar
 | RPI | Acronym for "[Rolling Proximity Identifier](https://covid19-static.cdn-apple.com/applications/covid19/current/static/contact-tracing/pdf/ExposureNotification-BluetoothSpecificationv1.2.pdf)". A privacy preserving identifier derived from the Temporary Exposure Key and sent in the broadcast of the Bluetooth payload. The identifier changes about every 15 minutes to prevent wireless tracking of the device. |
 | SARS-CoV-2 | [Severe acute respiratory syndrome coronavirus 2](https://en.wikipedia.org/wiki/Severe_acute_respiratory_syndrome_coronavirus_2) (SARS-CoV-2) is the strain of coronavirus that causes coronavirus disease 2019 (COVID-19), a respiratory illness. It is colloquially known as coronavirus. |
 | TAN | Acronym for "[Transaction Authentication Number](https://en.wikipedia.org/wiki/Transaction_authentication_number)". Needed to ensure that a device is allowed to do the upload of the diagnosis keys. TANs are not visible to users. See our [solution architecture document](solution_architecture.md) for details. |
-| TAM | Acronym for "[Technical Architecture Modeling](http://www.fmc-modeling.org/fmc-and-tam)", a modeling language mainly used at SAP to descibe software architectures.
+| TAM | Acronym for "[Technical Architecture Modeling](http://www.fmc-modeling.org/fmc-and-tam)", a modeling language mainly used at SAP to describe software architectures.
 | TCN | The [TCN Coalition](https://tcn-coalition.org/) is a global community of people to support exposure notification apps during the COVID-19 pandemic. |
 | TEK | Acronym for "[Temporary Exposure Key](https://covid19-static.cdn-apple.com/applications/covid19/current/static/contact-tracing/pdf/ExposureNotification-BluetoothSpecificationv1.2.pdf)". A key that’s generated every 24 hours for privacy consideration. |
 | teleTAN | Authorizes the upload of diagnosis keys from the app to the Corona-Warn-App Server if the test has returned a positive result and if the device wasn't linked using the QR Code. If the authorization is successful, the server will issue a registration token. See our [solution architecture document](solution_architecture.md) for details. |

pruefsteine.md

@@ -0,0 +1,73 @@
+# Criteria for the Evaluation of Contact Tracing Apps
+
+The Chaos Computer Club (CCC) proposed minimum privacy [requirements](https://www.ccc.de/en/updates/2020/contact-tracing-requirements) that should be considered when designing and evaluating contact tracing apps.
+
+The CCC is a well-reputed European hacker collective dealing with ["technical and societal issues, such as surveillance, privacy, freedom of information, hacktivism, data security, and many other interesting things around technology and hacking issues."](https://www.ccc.de/en)
+
+This document describes the compliance of the [current architecture](https://github.com/corona-warn-app/cwa-documentation/blob/master/solution_architecture.md) of the Corona-Warn-App with the *technical* criteria as outlined in the CCC's contact tracing requirements. For *political* and *epidemiological* criteria, we refer to the German Ministry of Health or the Robert-Koch-Institute, respectively.
+
+We are confident that the concept of the Corona-Warn-App is compliant with the CCC's technical requirements. We invite all members of the public to assess the ongoing implementation and discuss any issues or concerns [directly in the development repositories](https://github.com/corona-warn-app) in an open and transparent manner.
+
+## No Central Entity to Trust
+
+The Corona-Warn-App server does not store or process any confidential information requiring trust or secrecy. Due to the decentralized approach, the server does not hold any secret information. All the information that is stored on the server is publicly available.
+
+Based on this publicly available data and the information that is securely stored on the end device, the app itself, and not a cloud service, decides whether to inform a user about a potential exposure event. This information never leaves the device.
+
+The information about individual potential exposure events is not stored in the app itself, but handled securely by the underlying exposure notification framework. This framework stores information about visible rolling proximity identifiers (RPI) that were in close proximity over a defined time interval. This information is stored directly on the device.
+
+Even if the central Corona-Warn-App server is compromised, this information cannot be linked back to devices without having access to the device in the first place. Even then, the app itself cannot access the RPIs. Access to the diagnosis keys is only possible with the user's consent and only for a short period of time. Information that links diagnosis keys and connection metadata is removed before processing this data. Furthermore, identifying metadata, such as the IP address, is removed before diagnosis keys are processed by the backend server to further reduce the risk of rogue individuals connecting this information.
+
+## Data Economy/Minimization
+
+As mandated by the General Data Protection Regulation (GDPR), [data minimization](https://www.privacy-regulation.eu/en/article-5-principles-relating-to-processing-of-personal-data-GDPR.htm) is a paramount principle in the implementation of the Corona-Warn-App.
+
+Data collection is limited to the minimum data required for the app to function. Users only provide the following input: 
+
+ * Permission to use the Exposure Notification framework
+ * QR Code scan during testing
+ * TeleTAN in case of hotline-based result verification
+ * Consent to upload daily diagnosis keys
+ 
+Location data is not and cannot be collected by apps using the Exposure Notification framework:
+
+* [Section 3.3 Exposure Notification APIs Addendum](https://developer.apple.com/contact/request/download/Exposure_Notification_Addendum.pdf)
+* [Section 3.c Google COVID-19 Exposure Notifications Service Additional Terms](https://blog.google/documents/72/Exposure_Notifications_Service_Additional_Terms.pdf). 
+
+The diagnosis keys are only stored centrally for the epidemiologically relevant period of 14 days and are removed automatically after that period. 
+
+## Anonymity
+
+Users remain anonymous within the Corona-Warn-App system as long as their temporary exposure keys (TEK) solely remain on their device.
+
+The rolling proximity identifiers (RPI) that are observed by other devices can only be verified via the uploaded TEKs. RPIs also change frequently, i.e. in 10-20 min intervals, based on the TEK and the TEK changes daily. This means that even if the list of RPIs for a given day is available, it would still not be possible to identify a person that is sitting next to you every day in public transport.
+
+Theoretically, it would be possible to follow a user, collect the user's RPIs, connect them with person-identifying data, and then check if the person is ever marked as infected. Yet, in practice, this attack vector to deanonymize a user requires a high amount of effort just to gain little additional information compared to the one already gathered while following the user.
+
+Once temporary exposure keys are uploaded to the server (in case of a positive test result), anonymity turns into pseudonymity. With the uploaded diagnosis keys available, it becomes possible to attribute all RPIs of a given day to a single diagnosis key. Attributing this diagnosis key to distinct users or their device's International Mobile Equipment Identity (IMEI) is, however, still not possible without having direct access to the secret storage of the device.
+
+Users only have to identify themselves when they obtain the permission to upload diagnosis keys via teleTAN. But this happens just for verification reasons and should not provide identifying information beyond the one already known to health authorities. To further increase anonymity, users can make the call using a different device than the device they use for exposure detection.
+
+## No Creation of Central Movement or Contact Profiles
+
+Movement or contact data is not collected centrally. 
+
+Neither location data, nor the rolling proximity identifiers that are part of potential exposure events are ever stored centrally. At any given point in time, the system is only aware that diagnosis keys belong to individuals that have tested positive, not whom they met, where they met, or when they met. 
+
+To use the app for exposure detection, no identification is required. An identification is only necessary for the results retrieval and diagnosis key transmission functions. Linking the app to social media profiles is not and will not be implemented in this project.
+
+## Unlinkability
+
+The Corona-Warn-App and the underlying Exposure Notification framework take necessary cryptographic and technical means to prevent linking of user identity and the keys and identifiers visible in the system.
+
+Temporary Exposure Keys (TEK) are newly generated every day only on the user's device. From these TEKs, rolling proximity identifiers (RPI) are generated in 10 to 20 minute intervals. Without TEKs being uploaded and, thus, becoming diagnosis keys, RPIs cannot be linked to a certain user. If diagnosis keys have been uploaded, linking becomes only possible between diagnosis key and RPI and not directly to a user.
+
+As a rare edge case, diagnosis keys could be attributed to a single person in case this person is the only one reporting positive for a prolonged period of time. By only publishing diagnosis keys once a certain threshold of submissions is reached over a period of time, this risk is mitigated. Also, diagnosis key upload is limited for the last 14 days prior to the positive test results and no linking of exposure events beyond the epidemiological relevant timeframe is possible.
+
+## Unobservability of Communication
+
+The Corona-Warn-App takes state of the art measures to make individual messages and communication patterns unobservable to malicious entities.
+
+Well-established encryption mechanisms such as HTTP over TLS (HTTPS) ensure that messages are not readable for outside viewers. Metadata is removed before processing payload in diagnosis key submissions and can therefore not be linked to them on a database level. To further reduce the possibility of man-in-the-middle attacks, certificate pinning shall ensure that trusted communication only happens between the Corona-Warn-App and the server.
+
+Besides shielding individual messages that are transmitted by the system, also communication patterns  need to be disguised. Consider, for example, that polling for test results and submitting diagnosis keys would only happen in case of a real infection. In this case, observing network traffic would be sufficient to know that users took a SARS-CoV-2 test and had a positive result. This attack surface is mitigated by random fake messages that are indistinguishable from valid ones. This way, key submission and the retrieval of test results are indistinguishable from the system's background noise, creating plausible deniability for users even if network traffic is observed. 

scoping_document.md

@@ -74,7 +74,7 @@ The usage phase is subdivided into four further areas, in which app users have d
 
 4. **Infection case**
 
-   If an app user tests positive for infection, they can voluntarily publish the pseudonymized warn ID saved in their app. That way, other app users can use their smartphone to find out whether they were in contact with the infected user.
+   If an app user tests positive for infection, they can voluntarily publish the pseudonymized warn IDs saved in their app. That way, other app users can use their smartphone to find out whether they were in contact with the infected user.
 
 #### Uninstallation phase
 An app user can uninstall the app at any time, and completely delete all the data stored in it.

solution_architecture.md

@@ -29,24 +29,28 @@ Assuming a close association of a mobile phone and its user, we equate the devic
 
 ## INTRODUCTION
 
-To reduce the spread of [COVID-19](https://www.ecdc.europa.eu/en/covid-19-pandemic) it is necessary to inform people about their close proximity to positively tested individuals. So far, health departments and citizens identified these in personal dialogues based on people’s memory, which led to a high number of unknown connections, e.g. when using public transport. 
+To reduce the spread of [COVID-19](https://www.ecdc.europa.eu/en/covid-19-pandemic) it is necessary to inform people about their close proximity to positively tested individuals. So far, health departments and affected individuals identified these in personal dialogues based on people’s memory, which led to a high number of unknown connections, e.g. when using public transport. 
 
 ![Figure 1: High-level architecture overview](images/solution_architecture/figure_1.svg "Figure 1: High-level architecture overview")
 
-With the Corona-Warn-App (see [scoping document](https://github.com/corona-warn-app/cwa-documentation/blob/master/scoping_document.md )), shown centrally in *Figure 1*, individuals are enabled to trace their personal exposure risk through the means of their mobile phones. The application makes use of a new API made available by Apple and Google, called [Exposure Notification Framework](https://www.apple.com/covid19/contacttracing). It employs [Bluetooth Low Energy (BLE)](https://en.wikipedia.org/wiki/Bluetooth_Low_Energy) mechanics that let the individual phones act as beacons (constantly broadcasting a temporary identifier (called Rolling Proximity Identifier – RPI) to be remembered by), while scanning for identifiers of other phones at the same time (shown on the right side of *Figure 1*). 
+With the Corona-Warn-App (see [scoping document](https://github.com/corona-warn-app/cwa-documentation/blob/master/scoping_document.md )), shown centrally in *Figure 1*, individuals are enabled to trace their personal exposure risk through the means of their mobile phones. The application makes use of a new framework made available by Apple and Google, called [Exposure Notification Framework](https://www.apple.com/covid19/contacttracing). It employs [Bluetooth Low Energy (BLE)](https://en.wikipedia.org/wiki/Bluetooth_Low_Energy) mechanics that let the individual phones act as beacons (constantly broadcasting a temporary identifier (called Rolling Proximity Identifier – RPI) to be remembered by), while scanning for identifiers of other phones at the same time (shown on the right side of *Figure 1*). 
 Identifiers are ID numbers sent out by the phones. To ensure privacy and prevent tracking of movement patterns of the app user, those broadcasted identifiers are only temporary and  change constantly. New identifiers are derived from a Temporary Exposure Key (TEK) that substitutes daily at midnight (UTC) through means of cryptography, which will be explained in more detail in *Figure 10*. When the TEKs are linked to a positive test, they remain technically the same, but are called Diagnosis Keys.
 
-The collected identifiers of other users, as well as the own keys (which can later be used to derive the identifiers) are stored locally on the phone within the secure storage of the framework provided by Apple and Google. This secure storage cannot be accessed directly by the application, but only through the interfaces provided by the Exposure Notification Framework. Some of those interfaces are subjected to [rate limiting](https://developer.apple.com/documentation/exposurenotification/enmanager/3586331-detectexposures), in order to prevent misuse. In case users were tested positively for SARS-CoV-2, they can update their status in the app by providing a verification of their test and select an option to send their recent keys of up to 14 days. Once the keys have been uploaded to the Corona-Warn-App backend server, all keys of positively tested people are aggregated. This list of keys is then made available to all mobile phones with the app installed. Additionally, configuration parameters for the framework are available for download, so that adjustments to the calulation of the risk score can be taken (see the section regarding *Risk Scores*).
-Once the keys and the exposure detection configuration have been downloaded, the data is handed over to the Exposure Notification API, which analyzes whether one of the identifiers collected by the phone matches to those of an infected person. Additionally, meta data that has been broadcasted together with the identifiers (e.g. sending power), can now be decrypted and used. Based on the collected data a risk score for each individual exposure as well as for the overall situation is calculated for every single user within the Exposure Notification framework by Apple and Google. Exposures are defined as an aggregation of all encounters of an individual on a single calendar day (UTC timezone). For privacy reasons it is not possible to track encounters with other individuals across multiple days.
+The collected identifiers of other users, as well as the own keys (which can later be used to derive the identifiers) are stored locally on the phone within the secure storage of the framework provided by Apple and Google. This secure storage cannot be accessed directly by the application, but only through the interfaces provided by the Exposure Notification Framework. Some of those interfaces are subjected to [rate limiting](https://developer.apple.com/documentation/exposurenotification/enmanager/3586331-detectexposures), in order to prevent misuse. In case users were tested positively for SARS-CoV-2, they can update their status in the app by providing a verification of their test and select an option to send their recent keys of up to 14 days. Once the keys have been uploaded to the Corona-Warn-App backend server, all keys of positively tested people are aggregated. This list of keys is then made available to all mobile phones with the app installed. Additionally, configuration parameters for the framework are available for download, so that adjustments to the calculation of the risk score can be taken (see the section regarding *Risk Scores*).
+Once the keys and the exposure detection configuration have been downloaded, the data is handed over to the Exposure Notification framework, which analyzes whether one of the identifiers collected by the phone matches to those of an infected person. Additionally, meta data that has been broadcasted together with the identifiers (e.g. transmit power), can now be decrypted and used. Based on the collected data a risk score for each individual exposure as well as for the overall situation is calculated for every single user within the Exposure Notification framework by Apple and Google. Exposures are defined as an aggregation of all encounters with another person on a single calendar day (UTC timezone). For privacy reasons it is not possible to track encounters with other individuals across multiple days.
 
 It is important to notice at this point, that the people that have been exposed to a positively tested person are **not informed by a central instance**, but the risk of an exposure is calculated locally on their phones. The information about the exposure remains on the user’s phone and is not shared.
 
-The app pursues two objectives: First, supporting individuals in finding out whether they have been exposed to a person that has later been tested positively, and second receiving results of a SARS-CoV-2 test on their phone through an online system. This helps to reduce the period until necessary precautions (e.g. contact reduction and testing) can be taken. In order to prevent misuse, users need to verify that they have been tested positively before being able to upload their keys. Through this integrated approach, the verification needed for the upload of the diagnosis keys does not require any action from the users. They only have to confirm to the app and the Exposure Notification Framework that they are willing to share their diagnosis keys. Manual verification is also possible, if the lab that performed the testing does not support the direct electronic transmission of test results to the users' phone or if users have decided against the electronic transmission of their test results. 
+The app pursues two objectives: First, supporting individuals in finding out whether they have been exposed to a person that has later been tested positively, and second receiving results of a SARS-CoV-2 test on their phone through an online system. This helps to reduce the period until necessary precautions (e.g. contact reduction and testing) can be taken.
+In order to prevent misuse, users need to provide proof that they have been tested positive before being able to upload their keys. Through this integrated approach, the verification needed for the upload of the diagnosis keys does not require any further action from the users. 
+They only have to confirm to the app and the Exposure Notification Framework that they are willing to share their diagnosis keys. Manual verification is also possible, if the lab that performed the testing does not support the direct electronic transmission of test results to the users' phone or if users have decided against the electronic transmission of their test results. 
 
 ### Retrieval of lab results and verification process
 
-Reporting positive tests to the app is crucial for others to get informed about a relevant exposure and potential infection. On the other hand, a verification before the uploaded of diagnosis keys is required in order to prevent misuse. 
-There are two main approaches for this verification: The first option is to use the integrated functionality of the Corona-Warn-App to retrieve the results of a SARS-CoV-2 test. Through this integration, the positive test result is already verified and the diagnosis keys can be uploaded right after users have given their consent. The second option is to receive a human-readable token (e.g. a number or a combination of words) and provide this as verification to the app. This token is called teleTAN.
+Reporting positive tests to the app is crucial for others to get informed about a relevant exposure and potential infection. However, a verification before the upload of any diagnosis keys is required in order to prevent misuse. 
+There are two ways for receiving this verification: 
+1. Use of the integrated functionality of the Corona-Warn-App to retrieve the results of a SARS-CoV-2 test from a verification server (see Figure 2, Step 4a). Through this integration, the positive test result is already verified, and the diagnosis keys can be uploaded right after users have given their consent. 
+2. Use of a human-readable token (e.g. a number or a combination of words) and provide this as verification to the app. This token is called teleTAN (see Figure 2, Step 4b).
 
 ![Figure 2: Interaction flow for verification process](images/solution_architecture/figure_2.svg "Figure 2: Interaction flow for verification process")
 
@@ -56,17 +60,17 @@ This preexisting process for the processing of lab results includes that the doc
 
 The flow for using the app is as follows, referencing the steps from *Figure 2*:
 
-- **Step 1:** Citizens are using the Corona-Warn-App (i.e. broadcasting and collecting RPIs)
+- **Step 1:** Users of the Corona-Warn-App (i.e. broadcasting and collecting RPIs)
 	- (1) When a test is conducted, they receive an information flyer with a custom QR code. The code is either created on-site or is already available as a stack of pre-printed QR codes. The QR code contains a globally unique identifier (GUID).
 	- (2) Optionally, they can scan the QR code with the Corona-Warn-App (*Figure 3*, step 1) – if users decide against using the test retrieval functionality of the Corona-Warn-App, they still receive their test results through the regular channels explained before.
 	- (3) When the code is scanned, a web service call (REST) is placed against the Verification Server (*Figure 3*, step 2), linking the phone with the data from the QR code through a registration token, which is generated on the server  (*Figure 3*, step 3) and stored on the phone  (*Figure 3*, step 4).
 - **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 (lab ID, sample IDs).
-- **Step 3:** As soon as the test result is available (i.e. the samples have been processed), the software running locally in the lab (lab client) transmits the test result to the Laboratory Information System, together with the GUID from the QR code. The Laboratory Information System hashes the GUID and the test result. It is made available to the Verification Server through a REST interface.
-- **Step 4a:** After signing up for notifications in step 1, the user’s phone regularly check on the Verification Server whether test results are available (polling, figure 3, steps 5-8). This way, no external push servers need to be used. If results are available, the user is informed about the availability of information and only after opening the app, the result is displayed, together with recommandations for further actions (see scoping document for more details).
-- 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 (see also *Figure 3*, steps 6-8). The TAN is uploaded together with the diagnosis keys of up to the last 14 days to the Corona-Warn-App Server (*Figure 3*, step 12).
-- The Corona-Warn-App Server uses the TAN to verify the authenticity (*Figure 3*, steps 13-15) of the submission with the Verification Server.
-	- The TAN is consumed by the Verification Server and becomes invalid (*Figure 3*, step 14)
-	- If the Corona-Warn-App Server receives a positive confirmation, the uploaded diagnosis keys are stored in the database (*Figure 3*, step 16). 
+- **Step 3:** As soon as the test result is available (i.e. the samples have been processed), the software running locally in the lab (lab client) transmits the test result to the Laboratory Information System, together with the GUID from the QR code. The Laboratory Information System hashes the GUID and posts it together with the test result to the Test Result Server through a REST interface (*Figure 3*, step A), which in turn makes it available to the verification server.
+- **Step 4a:** After signing up for notifications in step 1, the user’s phone regularly checks the Verification Server for available test results (polling, figure 3, steps 5-8). This way, no external push servers need to be used. If results are available, the user is informed about the availability of information and only after opening the app, the result is displayed, together with recommendations for further actions (see scoping document for more details).
+- 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 (see also *Figure 3*, steps 9-13). As then Verification Server does not persist the test result, it is fetched from the Test Result Server once more (*Figure 3*, steps 10-11). The TAN is uploaded together with the diagnosis keys of up to the last 14 days to the Corona-Warn-App Server (*Figure 3*, step 14).
+- The Corona-Warn-App Server uses the TAN to verify the authenticity (*Figure 3*, steps 15-17) of the submission with the Verification Server.
+	- The TAN is consumed by the Verification Server and becomes invalid (*Figure 3*, step 16)
+	- If the Corona-Warn-App Server receives a positive confirmation, the uploaded diagnosis keys are stored in the database (*Figure 3*, step 18). 
 	- The TAN is never persisted on the Corona-Warn-App Server.
 	- In case of a failing request, the device receives corresponding feedback to make the user aware that the data needs to be re-submitted.
 
@@ -74,7 +78,7 @@ The flow for using the app is as follows, referencing the steps from *Figure 2*:
 
 Note regarding *Figure 3* and *Figure 4*: The white boxes with rounded corners represent data storage. The HTTP method POST is used instead of GET for added security, so data (e.g. the registration token or the TAN) can be transferred in the body.
 
-As mentioned before, users might have decided against retrieving test results electronically or the electronic process might not be supported by the lab. Within step 3 of *Figure 2*, it is shown, that in these cases the health authority (“Gesundheitsamt”) reach out to the patient directly. Also during this conversation the teleTAN can be provided to the patient, which can be used to authorize the upload of diagnosis keys from the app to the Corona-Warn-App Server (step 4b of *Figure 2*). This process is also visualized in *Figure 4*. Whenever patients are contacted regarding positive test results, they can choose to receive a teleTAN. The teleTan is retrieved from the web interface (*Figure 4*, step 1) of the portal service by a public health officer. This service in turn is requesting it from the Verification Server (2-3). The teleTAN is then issued to the officer (4-5), who transfers it to the patient (6). Once the patient has entered the teleTAN into the app (7), it uses the teleTAN to retrieve a registration token from the Verification Server (8-10). Once the user has confirmed the upload of the Diagnosis Keys, the application requests a TAN from the server, using the registration token (11-13). This TAN is needed by the server to ensure that the device is allowed to do the upload. These TANs are not visible to the user. After uploading the TAN and the diagnosis keys to the Corona-Warn-App Server (14), the Corona-Warn-App Server can verify the authenticity of the TAN with the Verification Server (15-16) and upon receiving a confirmation, store the diagnosis keys in the database (17).
+As mentioned before, users might have decided against retrieving test results electronically or the electronic process might not be supported by the lab. Within step 3 of *Figure 2*, it is shown, that in these cases the health authority (“Gesundheitsamt”) reaches out to the patient directly. Also during this conversation, the teleTAN can be provided to the patient, which can be used to authorize the upload of diagnosis keys from the app to the Corona-Warn-App Server (step 4b of *Figure 2*). This process is also visualized in *Figure 4*. Whenever patients are contacted regarding positive test results, they can choose to receive a teleTAN. The teleTan is retrieved from the web interface (*Figure 4*, step 1) of the portal service by a public health officer. This service in turn is requesting it from the Verification Server (2-3). The teleTAN is then issued to the officer (4-5), who transfers it to the patient (6). Once the patient has entered the teleTAN into the app (7), it uses the teleTAN to retrieve a registration token from the Verification Server (8-10). Once the user has confirmed the upload of the Diagnosis Keys, the application requests a TAN from the server, using the registration token (11-13). This TAN is needed by the server to ensure that the device is allowed to do the upload. These TANs are not visible to the user. After uploading the TAN and the diagnosis keys to the Corona-Warn-App Server (14), the Corona-Warn-App Server can verify the authenticity of the TAN with the Verification Server (15-16) and upon receiving a confirmation, store the diagnosis keys in the database (17).
 
 ![Figure 4: Verification process for teleTAN received via phone](images/solution_architecture/figure_4.svg "Figure 4: Verification process for teleTAN received via phone")
 
@@ -100,10 +104,10 @@ As of now, two uploads are required from the same phone (past diagnosis keys and
 
 The Corona-Warn-App Server needs to fulfill the following tasks:
 - Accept upload requests from clients
-	- Verify association with a positive test through the Verification Server and the associated workflow.(explained in the chapter “Retrieval of lab results and verification process”, shown in the center of the left side of *Figure 6*)
+	- Verify association with a positive test through the Verification Server and the associated workflow (explained in the chapter “Retrieval of lab results and verification process”, shown in the center of the left side of *Figure 6*).
 	- Accept uploaded diagnosis keys and store them (optional) together with the corresponding transmission risk level parameter (integer value of 1-8) into the database. Note that the transport of metadata (e.g. IP) of the incoming connections for the upload of diagnosis keys is removed in a dedicated actor, labelled “Transport Metadata Removal” in *Figure 6*.
 - Provide [configuration parameters](#data-format) to the mobile applications
-	- Weights for the risk score categories
+	- Threshold values for [attenuation buckets](#attenuation-buckets)
 	- Risk scores for defined values
 	- Threshold values for risk categories and alerts
 - On a regular schedule (e.g. hourly)
@@ -111,7 +115,7 @@ The Corona-Warn-App Server needs to fulfill the following tasks:
 	- Store chunks as static files (in protocol buffers, compatible with format specified by Apple/Google)
 	- Transfer files to a storage service (shown at the bottom of *Figure 6*), which acts as a source for the Content Delivery Network (CDN)
 
-Those tasks are visualized in *Figure 7*. Each of swim lanes (vertical sections of the diagram) on the left side (Phone 1, Phone 2, Phone n) represent one device with the Corona-Warn-App installed. The user of Phone 1 has taken a SARS-CoV-2 test (which comes back positive later). The users of Phone 1 and Phone n only use the functionality to trace potential exposure.
+Those tasks are visualized in *Figure 7*. Each of swim lanes (vertical sections of the diagram) on the left side (Phone 1, Phone 2, Phone n) represent one device with the Corona-Warn-App installed. The user of Phone 1 has taken a SARS-CoV-2 test (which comes back positive later). The users of Phone 2 and Phone n only use the functionality to trace potential exposure.
 The Corona-Warn-App Server represents the outside picture of the individual service working in the backend. For a better understanding, the database has been visualized separately.
 
 ![Figure 7: Interaction of the mobile application(s) with the backend servers and CDN](images/solution_architecture/figure_7.svg "Figure 7: Interaction of the mobile application(s) with the backend servers and CDN")
@@ -120,7 +124,9 @@ It is to note that even if a user has not been tested positive, the app randomly
 
 If diagnosis keys need to be uploaded on subsequent days of the submission of a positive test result, also that behavior should be represented within the random (dummy) submissions.
 
-The possibility to identify temporary exposure keys belonging together (i.e. to the same user) is given, as they are posted together – resulting in them being in a sequential order in the database. To prevent this, the aggregated files will shuffled, e.g. by using an ORDER BY RANDOM on the database side while fetching the data for the corresponding file. Alternatively, returning them in the lexicographic order of the RPIs (which are random) is a valid option as well. 
+The possibility to identify temporary exposure keys belonging together (i.e. to the same user) is given, as they are posted together – resulting in them being in a sequential order in the database.
+To prevent this, the aggregated files will be shuffled, e.g. by using an ORDER BY RANDOM on the database side while fetching the data for the corresponding file.
+Alternatively, returning them in the lexicographic order of the RPIs (which are random) is a valid option as well. The latter might be more efficient for compressing the data afterwards.
 
 The configuration parameters mentioned above allow the health authorities to dynamically adjust the behavior of the mobile applications to the current epidemiological situation. For example, the risk score thresholds for the risk levels can be adjusted, as well as how the individual data from exposure events influence the overall score.
  
@@ -134,7 +140,8 @@ The server will make the following information available through a RESTful inter
 - available items through index endpoints (not all implemented in first iteration)
 - the newly added Diagnosis Keys (Temporary Exposure Keys) for the time frame
 - configuration parameters
-	- 36 parameters for configuring the risk score of the Apple/Google Exposure Notification Framework
+	- 32 parameters for configuring the risk score of the Apple/Google Exposure Notification Framework
+	- [Attenuation bucket](#attenuation-buckets) thresholds
 	- Risk score threshold to issue a warning
 	- Risk score ranges for individual risk levels
 
@@ -154,13 +161,13 @@ Further details of the API are explained in the documentation of the Corona-Warn
 
 ### Data retention
 
-The data on the all involved servers will only be retained as long as required. Diagnosis Keys will be removed from Corona-Warn-App Server once they refer to a period more than 14 days ago. TANs on the Verification Server will be removed as soon as they have been used. The hashed GUID on the Verification Server needs to be retained as long as the GUID can be used to retrieve test results from the Laboratory Information System, as otherwise a second upload privilege (i.e. a registration token) could be fetched with the same GUID.
+The data on the all involved servers will only be retained as long as required. Diagnosis Keys will be removed from Corona-Warn-App Server once they refer to a period more than 14 days ago. TANs on the Verification Server will be removed as soon as they have been used. The hashed GUID on the Verification Server needs to be retained as long as the GUID can be used to retrieve test results from the test result server, as otherwise a second upload privilege (i.e. a registration token) could be fetched with the same GUID.
 
 ## MOBILE APPLICATIONS
 
 The functional scope of the mobile applications is defined in the corresponding [scoping document](https://github.com/corona-warn-app/cwa-documentation/blob/master/scoping_document.md). The applications will be developed natively for Apple’s iOS and Google’s Android operating system. They will make use of the respective interfaces for the exposure notification (i.e. broadcasting and scanning for Bluetooth advertisement packages, see *Figure 9*). For Apple devices (starting from _<to be determined>_) an OS version of at least 13.5 will be required for the system to work, as the framework is integrated into the operating system.
 
-For Android, the features will be integrated into the [Google Play Services](https://9to5google.com/2020/04/13/android-contact-tracing-google-play-services/), which means that only this specific application needs to be updated for it to work. Devices starting with Android _<to be determined>_ and integrated BLE chips will be supported.
+For Android, the features will be integrated into the [Google Play Services](https://9to5google.com/2020/04/13/android-contact-tracing-google-play-services/), which means that only this specific application needs to be updated for it to work. Devices starting with Android 6.0 (API version 23) and integrated BLE chips will be [supported](https://static.googleusercontent.com/media/www.google.com/de//covid19/exposurenotifications/pdfs/Android-Exposure-Notification-API-documentation-v1.3.2.pdf).
 
 ![Figure 9: Architecture overview of the mobile application (focused on API usage/BLE communication)](images/solution_architecture/figure_9.svg "Figure 9: Architecture overview of the mobile application (focused on API usage/BLE communication)")
 
@@ -174,12 +181,21 @@ The encapsulation especially applies to the part where matches are calculated, a
 
 [Information provided from the framework API to the app per exposure](https://covid19-static.cdn-apple.com/applications/covid19/current/static/contact-tracing/pdf/ExposureNotification-FrameworkDocumentationv1.2.pdf):
 -	**Attenuation value** (Reported Transmit Power - Measured RSSI)
--	**Attenuation “buckets”**, i.e. time spent with an attenuation <=50 and >50
+-	**Attenuation “buckets”**, i.e. times spent within certain attenuation ranges (see below)
 -	**Date** when the exposure occurred (with reduced precision, i.e. one day)
 -	**Duration** of the exposure (<5/5/10/15/20/25/30/>30 minutes)
 -	**Transmission risk level** associated with diagnosis key of other person (downloaded from server, together with diagnosis key)
--	**Total Risk Score** calculated exposure risk level according to the defined parameters
+-	**Total Risk Score** calculated exposure risk level (with a range from 0-4096) according to the defined parameters
 
+### Attenuation Buckets
+
+Both, Apple and Google allow to define a low and a high threshold for the attenuation, forming three individual buckets:
+- attenuation < low threshold
+- low threshold <= attenuation < high threshold
+- high threshold <= attenuation
+
+While in the Google implementations of the Exposure Notification framework, those buckets are contained within the `ExposureSummary` (`attenuationDurations`), Apple has added them to the [`metadata`](https://developer.apple.com/documentation/exposurenotification/enexposureinfo/3586326-metadataenexposureinfo) attribute of the [`ENExposureInfo`](https://developer.apple.com/documentation/exposurenotification/enexposureinfo).
+In the latter implementation, the [`attenuationDurations`](https://developer.apple.com/documentation/exposurenotification/enexposureinfo/3586325-attenuationdurations) of the `ENExposureInfo` contains two buckets around a fixed threshold of 50.
 
 ### Risk score calculation
 
@@ -225,7 +241,7 @@ If the backend calls from the mobile applications cannot be spread as evenly as
 
 ## Cross-border interoperability
 
-A definite prerequisite for compatibility is, that the identifiers of the mobile devices can be matched, i.e. the API by Apple/Google is being used. 
+A definite prerequisite for compatibility is, that the identifiers of the mobile devices can be matched, i.e. the framework by Apple/Google is being used. 
 
 Further details will be added as soon as they are available.
 

translations/README.de.md

@@ -1,9 +1,26 @@
-# Corona-Warn-App
+<p align="center">
+    <a href="https://www.coronawarn.app/de/"><img src="https://raw.githubusercontent.com/corona-warn-app/cwa-documentation/master/images/CWA_title.png" width="400"></a>
+</p>
+
+<hr />
+<p align="center">
+    <a href="#über-dieses-projekt">Über dieses Projekt</a> • 
+    <a href="#wer-wir-sind">Wer wir sind</a> •
+    <a href="#danksagungen">Danksagungen</a> •
+    <a href="#datenschutz">Datenschutz</a> •
+    <a href="#code-of-conduct">Code of Conduct</a> •
+    <a href="#arbeitssprache">Arbeitssprache</a> •
+    <a href="#unsere-dokumentation">Unsere Dokumentation</a> •
+    <a href="#lizenzierung">Lizenzierung</a> •
+    <a href="#informationen-zur-teilnahme">Informationen zur Teilnahme</a> •
+    <a href="https://www.coronawarn.app/de/">Webseite</a>
+</p>
+<hr />
 
 HINWEIS: Die [englische Version](../README.md) der README-Datei ist die maßgebliche Fassung. Bitte haben Sie dafür Verständnis, dass die deutsche Version möglicherweise nicht durchgängig auf dem neuesten Stand ist.
 
 ## Über dieses Projekt
-Wir entwickeln die offizielle COVID-19-App zur Kontaktfallbenachrichtigung für Deutschland, die sogenannte "Corona-Warn-App". Dieses Projekt hat zum Ziel, eine Anwendung auf der Grundlage einer Technologie mit einem dezentralisierten Ansatz zu entwickeln. Als Grundlage dienen die Protokolle [DP-3T](https://github.com/DP-3T/documents) (Decentralized Privacy-Preserving Proximity Tracing) und [TCN](https://tcn-coalition.org/) sowie die Spezifikationen für [Privacy-Preserving Contact Tracing](https://www.apple.com/covid19/contacttracing/) von Apple und Google. Wie DP-3T und TCN folgen auch die Apps und die Backend-Infrastruktur dem Open-Source-Prinzip - lizenziert unter [Apache 2.0 ](../LICENSE). Die Apps (für iOS und Android) werden pseudonymisierte Daten von Mobiltelefonen in der Umgebung mit Hilfe von Bluetooth-Technologie sammeln. Die Daten werden lokal auf den einzelnen Geräten gespeichert, um so den Zugriff auf die Daten und die Kontrolle über die Daten durch Behörden oder andere Instanzen zu verhindern. Wir erfüllen die geltenden Datenschutzvorgaben und garantieren höchste IT-Sicherheitsstandards. Auf diese Weise stellen wir uns den Datenschutzbedenken der Bevölkerung und hoffen dadurch, die Nutzung der Anwendung zu steigern.
+Wir entwickeln die offizielle COVID-19-App zur Kontaktfallbenachrichtigung für Deutschland, die sogenannte "<a href="https://www.coronawarn.app/de/">Corona-Warn-App</a>". Dieses Projekt hat zum Ziel, eine Anwendung auf der Grundlage einer Technologie mit einem dezentralisierten Ansatz zu entwickeln. Als Grundlage dienen die Protokolle [DP-3T](https://github.com/DP-3T/documents) (Decentralized Privacy-Preserving Proximity Tracing) und [TCN](https://tcn-coalition.org/) sowie die Spezifikationen für [Privacy-Preserving Contact Tracing](https://www.apple.com/covid19/contacttracing/) von Apple und Google. Wie DP-3T und TCN folgen auch die Apps und die Backend-Infrastruktur dem Open-Source-Prinzip - lizenziert unter [Apache 2.0 ](../LICENSE). Die Apps (für iOS und Android) werden pseudonymisierte Daten von Mobiltelefonen in der Umgebung mit Hilfe von Bluetooth-Technologie sammeln. Die Daten werden lokal auf den einzelnen Geräten gespeichert, um so den Zugriff auf die Daten und die Kontrolle über die Daten durch Behörden oder andere Instanzen zu verhindern. Wir erfüllen die geltenden Datenschutzvorgaben und garantieren höchste IT-Sicherheitsstandards. Auf diese Weise stellen wir uns den Datenschutzbedenken der Bevölkerung und hoffen dadurch, die Nutzung der Anwendung zu steigern.
 
 ## Wer wir sind
 
@@ -17,6 +34,10 @@ Wir möchten allen danken, die an diesem wichtigen Projekt gleich von Beginn an
 
 In diesem Projekt berücksichtigen wir die Prinzipien der Datenschutzgrundverordnung (DSGVO), um die Privatsphäre aller zu schützen. Wir verarbeiten ausschließlich notwendige Daten und ausschließlich zu dem Zweck, alle wissen zu lassen, ob sie in engem Kontakt mit anderen, bereits infizierten Personen standen, ohne die jeweilige Identität zu offenbaren. Die Einhaltung dieser Grundsätze wird durch verschiedene Schritte sichergestellt, zum Beispiel durch die Implementierung technischer und organisatorischer Maßnahmen, die sich sorgfältig an die hohen Standards der DSGVO halten. Selbstverständlich wird die Anwendung eine verständliche Datenschutzerklärung vorhalten, um so transparent und klar wie möglich zu sein. Da wir die Anwendung als Open-Source-Projekt entwickeln, kann die Community dies überprüfen. Wir begrüßen Ihre Rückmeldungen!
 
+## Code of Conduct
+
+Dieses Projekt hat den [Contributor Covenant](https://www.contributor-covenant.org/) in Version 2.0 als unseren Code of Conduct übernommen. Bitte beachten Sie die Einzelheiten in unserem [CODE_OF_CONDUCT.md](../CODE_OF_CONDUCT.md). Alle Mitwirkenden müssen sich an den Code of Conduct halten.
+
 ## Arbeitssprache
 
 Wir entwickeln diese Anwendung für Deutschland. Wir möchten so offen und transparent wie möglich sein, auch für Interessierte in der globalen Entwicklungscommunity, die nicht Deutsch sprechen. Daher wird sämtlicher Inhalt vor allem auf _Englisch_ zur Verfügung gestellt. Wir bitten auch alle Interessierten, Englisch als Arbeitssprache zu verwenden, etwa für Kommentare im Code, für die Dokumentation oder wenn Sie uns Anfragen senden. Die Anwendung selbst, die zugehörige Dokumentation und sämtlicher Inhalt für diejenigen, welche die Anwendungen nutzen, werden selbstverständlich auf Deutsch (und möglicherweise auch andere Sprachen) zur Verfügung gestellt. Wir werden auch versuchen, Entwicklungsdokumentation auf Deutsch zur Verfügung zu stellen, aber wir bitten um Verständnis dafür, dass es nur mit Englisch als der _Lingua Franca_ der globalen Entwicklungscommunity möglich sein wird, bei der Entwicklung dieser Anwendung mit höchstmöglicher Effizienz zu arbeiten.
@@ -29,6 +50,11 @@ Dieses Repository enthält die Entwicklungsdokumentation und zugehörige Inhalte
 Der Projektumfang wurde gemeinsam von der Deutschen Telekom AG sowie der SAP SE als Auftragnehmer und der deutschen Bundesregierung sowie dem Robert Koch-Institut als Auftraggeber festgelegt. Der Projektumfang kann sich im Laufe der Zeit ändern, wenn neue Anforderungen einbezogen werden müssen oder wenn sich bestehende Anforderungen ändern. Wir begrüßen Rückmeldungen zu allen Bestandteilen dieses Dokuments zum Projektumfang. Allerdings müssen zusätzliche Funktionen oder andere inhaltliche Änderungen, die über das Beheben von Grammatik- oder Schreibfehlern hinausgehen, zwischen den Verantwortlichen abgestimmt werden, bevor sie in das Dokument aufgenommen werden können. Vielen Dank für Ihr Verständnis.
 - [Corona-Warn-App - Scoping-Dokument](scoping_document.de.md)
 
+### Technische Dokumentation
+Die technischen Dokumente sind für ein technisches Publikum bestimmt und repräsentieren den neuesten Stand der Architektur. Die Lösungsarchitektur und die Konzepte können sich im Laufe der Zeit ändern, da sich externe Abhängigkeiten (z.B. das von Apple/Google bereitgestellte Framework) noch immer ändern und neue Anforderungen aufgenommen werden müssen oder sich bestehende ändern. Wir freuen uns über Rückmeldungen zu allen Elementen dieser technischen Dokumente. 
+
+* [Prüfsteine für die Beurteilung von "Contact Tracing"-Apps](pruefsteine.de.md)
+
 ## Lizenzierung
 
 Copyright (c) 2020 Deutsche Telekom AG und SAP SE oder ein SAP-Konzernunternehmen.
@@ -39,6 +65,8 @@ Eine Kopie der Lizenz erhalten Sie unter https://www.apache.org/licenses/LICENSE
 
 Sofern nicht durch anwendbares Recht gefordert oder schriftlich vereinbart, wird jede unter der Lizenz bereitgestellte Software „OHNE MÄNGELGEWÄHR“ UND OHNE AUSDRÜCKLICHE ODER STILLSCHWEIGENDE GARANTIE JEGLICHER ART bereitgestellt. Die genauen Angaben zu Genehmigungen und Einschränkungen unter der Lizenz finden Sie in der [LIZENZ](../LICENSE).
 
+Das "Corona-Warn-App"-Logo ist eine registrierte Wort-/Bildmarke des Presse- und Informationsamts der Bundesregierung. Weitere Informationen finden Sie unter [bundesregierung.de](https://www.bundesregierung.de/breg-de/bundesregierung/bundespresseamt).
+
 ## Informationen zur Teilnahme
 
 Weitere Informationen z.B. darüber, wie Sie das Projekt unterstützen können, unser Team aufgebaut ist oder unsere Projektstruktur aussieht, finden Sie hier: [CONTRIBUTING.md](../CONTRIBUTING.md).

translations/pruefsteine.de.md

@@ -0,0 +1,74 @@
+# Prüfsteine für die Beurteilung von „Contact Tracing“-Apps
+
+Der Chaos Computer Club (CCC) hat einige [Minimalanforderungen](https://www.ccc.de/updates/2020/contact-tracing-requirements) zur Wahrung der Privatsphäre bei der Konzeption und Bewertung von „Contact Tracing“-Apps vorgeschlagen.
+
+Der CCC ist eine renommierte europäische Hackervereinigung, die sich mit dem [Spannungsfeld technischer und sozialer Entwicklungen](https://www.ccc.de) befasst: „Die Aktivitäten des Clubs reichen von technischer Forschung und Erkundung am Rande des Technologieuniversums über Kampagnen, Veranstaltungen, Politikberatung, Pressemitteilungen und Publikationen bis zum Betrieb von Anonymisierungsdiensten und Kommunikationsmitteln.“
+
+Dieses Dokument beschreibt, inwieweit die [aktuelle Architektur](https://github.com/corona-warn-app/cwa-documentation/blob/master/solution_architecture.md) die *technischen* Anforderungen erfüllt. In Bezug auf die *politischen* und *epidemiologischen* Anforderungen verweisen wir an das deutsche Bundesministerium für Gesundheit bzw. das Robert Koch-Institut.
+
+Wir sind davon überzeugt, dass das Konzept der Corona-Warn-App die technischen Anforderungen des CCC erfüllt. Es sind alle dazu eingeladen, die laufende Implementierung der App zu prüfen und jegliche Probleme, Bedenken oder sonstige Themen offen und transparent [direkt in den Entwicklungs-Repositories](https://github.com/corona-warn-app) zu diskutieren.
+
+## Keine zentrale Entität, der vertraut werden muss
+
+Der Server der Corona-Warn-App speichert und verarbeitet keinerlei vertrauliche Informationen, für die Vertrauenswürdigkeit oder Geheimhaltung erforderlich sind. Aufgrund des dezentralen Ansatzes liegen auf dem Server keine geheimen Informationen – alle gespeicherten Informationen sind öffentlich zugänglich.
+
+Auf Basis dieser öffentlich zugänglichen Daten und den sicher auf dem Endgerät gespeicherten Informationen entscheidet die App – und kein Cloud-Service –, ob eine nutzende Person über ein potenzielles Kontaktereignis informiert wird. Diese Information verlässt das Gerät zu keinem Zeitpunkt.
+
+Die App selbst speichert keine Informationen über einzelne potenzielle Kontaktereignisse. Diese Informationen werden über das zugrunde liegende Exposure Notification Framework sicher verarbeitet. Das Framework speichert lediglich sichtbare Rolling Proximity Identifiers (RPI), die sich über einen bestimmten Zeitraum in nächster Nähe befanden. Auch dies wird direkt auf dem Smartphone gespeichert.
+
+Selbst wenn der zentrale Corona-Warn-App-Server kompromittiert sein sollte, können diese Informationen nicht zu Smartphones zurückverfolgt werden, wenn nicht ohnehin schon Zugriff auf das Smartphone besteht. Auch dann kann die App selbst nicht auf die RPIs zugreifen. Der Zugriff auf die Diagnoseschlüssel ist nur mit Zustimmung der nutzenden Person und nur für einen kurzen Zeitraum möglich. Vor der Verarbeitung der Daten werden die Informationen entfernt, die die Diagnoseschlüssel und die Verbindungsmetadaten miteinander verknüpfen. Metadaten, die eine Identifizierung ermöglichen (z.B. die IP-Adresse), werden entfernt, bevor der Backend-Server Diagnoseschlüssel verarbeitet. Dadurch wird das Risiko weiter verringert, dass ein Angreifer diese Informationen miteinander verknüpfen kann.
+
+## Datensparsamkeit
+
+Wie in der Datenschutz-Grundverordnung (DSGVO) vorgeschrieben, ist die [Datenminimierung](https://www.privacy-regulation.eu/de/5.htm) einer der wichtigsten Grundsätze für die Umsetzung der Corona-Warn-App.
+
+Es werden nur die Daten gesammelt, die für ein Funktionieren der App nötig sind. Die nutzenden Personen können und müssen in Verbindung mit der App ausschließlich die folgenden Angaben machen: 
+
+ * Zustimmung zur Nutzung des Exposure Notification Frameworks
+ * Scannen eines QR-Codes mit dem Testergebnis
+ * Eingabe einer TeleTAN bei der Verifizierung eines Testergebnisses per Hotline
+ * Zustimmung zum Upload der täglichen Diagnoseschlüssel
+ 
+Apps können über das Exposure Notification Framework keine Daten zum Standort sammeln:
+
+* [Section 3.3 Exposure Notification APIs Addendum](https://developer.apple.com/contact/request/download/Exposure_Notification_Addendum.pdf)
+* [Section 3.c Google COVID-19 Exposure Notifications Service Additional Terms](https://blog.google/documents/72/Exposure_Notifications_Service_Additional_Terms.pdf). 
+
+Die Diagnoseschlüssel werden nur für den epidemiologisch relevanten Zeitraum von 14 Tagen zentral gespeichert und nach den 14 Tagen automatisch entfernt.
+
+## Anonymität
+
+Nutzende Personen bleiben innerhalb des Corona-Warn-App-Systems anonym, solange ihre Temporary Exposure Keys (TEK) auf ihrem Smartphone verbleiben.
+
+Die Rolling Proximity Identifiers (RPI), die von anderen Smartphones beobachtet werden, können nur mit diesen hochgeladenen TEKs verifiziert werden. Die RPIs werden häufig (alle 10 bis 20 Minuten) auf Basis des Temporary Exposure Keys geändert, der sich wiederum selbst täglich erneuert. Man könnte also z.B. selbst dann nicht feststellen, dass eine nutzende Person jeden Tag im Bus neben derselben Person gesessen hat, wenn die Liste der RPIs für bestimmte Tage einsehbar wäre.
+
+Theoretisch könnte man einer nutzenden Person folgen, die RPIs der Person sammeln, diese mit bestimmten Informationen verknüpfen, die die Person identifizieren, und dann prüfen, ob die Person jemals als infiziert gemeldet wurde. In der Praxis wäre dieser Angriffsvektor zur Deanonymisierung einer nutzenden Person sehr aufwendig, da der Informationsgewinn verglichen mit dem, was man beim Verfolgen der nutzenden Person ohnehin bereits erfahren hat, sehr gering wäre.
+
+Sobald TEKs (im Falle eines positive Testergebnisses) auf den Server hochgeladen werden, wird aus Anonymität Pseudonymität. Wenn der hochgeladene Diagnoseschlüssel verfügbar ist, können alle RPIs eines bestimmten Tages einem einzelnen Diagnoseschlüssel zugeordnet werden. Es ist jedoch nicht möglich, diesen Diagnoseschlüssel konkreten nutzenden Personen oder der International Mobile Equipment Identity (IMEI) von deren Smartphone zuzuordnen, ohne Zugang zum geheimen Speicher des Geräts zu haben.
+
+Nutzende Personen müssen sich nur identifizieren, wenn sie die Erlaubnis erteilen, dass Diagnoseschlüssel per TeleTAN hochgeladen werden dürfen. Diese Identifizierung dient aber nur der Verifizierung und legt außer den Informationen zur Identifizierung, über die die Gesundheitsbehörden ohnehin schon verfügen, keine weiteren Angaben offen. Um noch mehr Anonymität zu erreichen, könnte eine nutzende Person die Hotline mit einem anderen Telefon anrufen als mit dem, das zur Kontakterkennung verwendet wird.
+
+## Kein Aufbau von zentralen Bewegungs- und Kontaktprofilen
+
+Bewegungs- und Kontaktdaten werden nicht zentral gesammelt.
+
+Weder Standortdaten noch die Rolling Proximity Identifiers, die Bestandteil potenzieller Kontaktereignisse sind, werden jemals zentral gespeichert. Das System weiß zu jedem Zeitpunkt nur, dass ein Diagnoseschlüssel zu einer positiv getesteten Person gehört. Das System weiß weder, wen diese Person getroffen hat, noch wo oder wann es zu dem Kontakt kam.
+
+Damit die App erkennen kann, dass ein Kontakt stattgefunden hat, ist keine Identifizierung notwendig. Eine Identifizierung ist nur erforderlich, um die Ergebnisse abzurufen und den Diagnoseschlüssel zu übermitteln. Die App verbindet sich im Rahmen dieses Projekts nicht mit irgendwelchen Profilen in sozialen Medien und wird dies auch in Zukunft nicht tun.
+
+## Unverkettbarkeit
+
+Die Corona-Warn-App und das zugrunde liegende Exposure Notification Framework sehen die erforderlichen kryptografischen und technischen Mittel vor, um zu verhindern, dass die Identität der nutzenden Person und die im System sichtbaren Schlüssel und IDs miteinander verkettet werden können.
+
+Temporary Exposure Keys (TEK) werden täglich neu und ausschließlich auf dem Gerät der nutzenden Person generiert. Über diese TEKs werden alle 10 bis 20 Minuten Rolling Proximity Identifiers (RPI) erzeugt. Solange die TEKs nicht hochgeladen (und damit zu Diagnoseschlüsseln) werden, können RPIs nicht mit einer bestimmten nutzenden Person verknüpft werden. Wenn die Diagnoseschlüssel hochgeladen wurden, können die Diagnoseschlüssel nur mit RPIs verkettet werden, aber nicht direkt mit einer nutzenden Person.
+
+In einem seltenen Grenzfall könnten Diagnoseschlüssel auf eine Einzelperson zurückführbar sein, und zwar wenn sich diese Person über einen längeren Zeitraum als einzige als positiv getestete Person meldet. Indem Diagnoseschlüssel nur veröffentlicht werden, sobald über eine gewisse Zeit ein bestimmter Schwellenwert erreicht ist, wird dieses Risiko gemindert. Darüber hinaus werden Diagnoseschlüssel nur für die letzten 14 Tage vor dem positiven Testergebnis hochgeladen, sodass eine Verkettung von Kontaktereignissen über den epidemiologisch relevanten Zeitraum hinaus nicht möglich ist.
+
+
+## Unbeobachtbarkeit der Kommunikation
+
+Die Maßnahmen der Corona-Warn-App, mit denen gewährleistet wird, dass einzelne Nachrichten und Kommunikationsmuster nicht von Angreifern beobachtet werden können, entsprechen dem aktuellen Stand der Technik.
+
+Etablierte Verschlüsselungsmechanismen wie HTTP over TLS (HTTPS) stellen sicher, dass Nachrichten von außen nicht lesbar sind. Die Metadaten werden entfernt, bevor die Nutzdaten bei der Übermittlung von Diagnoseschlüsseln verarbeitet werden. Somit können diese nicht auf Datenbankebene verkettet werden. Um das Risiko von Man-in-the-Middle-Angriffen weiter zu reduzieren, wird durch HTTP Public Key Pinning sichergestellt, dass vertrauliche Kommunikation nur zwischen der Corona-Warn-App und dem Server stattfindet.
+
+Neben einzelnen Nachrichten, die vom System übertragen werden, müssen auch Kommunikationsmuster abgeschirmt werden. Beispiel: Der Sendeaufruf von Testergebnissen und die Übermittlung von Diagnoseschlüsseln würde normalerweise nur im Fall einer tatsächlichen Infektion stattfinden. In diesem Fall könnte man durch die Beobachtung des Netzwerkverkehrs erkennen, dass eine nutzende Person einen SARS-CoV-2-Test gemacht hat und positiv getestet wurde. Um dies zu verhindern, werden zufällig generierte unechte Meldungen versendet, die von gültigen Meldungen nicht unterschieden werden können. Dadurch sind die Übermittlung von Schlüsseln und der Abruf von Testergebnissen nicht vom Hintergrundrauschen der Systeme unterscheidbar. Dies führt selbst bei beobachtbarem Netzwerkverkehr zu einer plausiblen Abstreitbarkeit.

ui_screens.md

@@ -0,0 +1,28 @@
+# Corona-Warn-App User Interface Screens
+
+The design of the Corona-Warn-App combines the requirements of the German citizens, the German federal government, and the virologists with the latest technological capabilities. At the same time, it provides a user experience that is easy to understand and to follow. The design of the central overview, the usage of signal color to highlight the current risk level, as well as the explanatory illustrations ensure an intuitive consumption of the app.
+
+We highly appreciate your feedback on these screens! Though, please, bear in mind that major changes cannot be implemented without a decision by the Ministry of Health and the Robert Koch Institute. Further documentation, e.g. about questions of accessibility, will follow soon.
+
+## User Validation
+
+We conducted usability tests with representative user groups and improved the design based on their feedback. Furthermore, Apple and Google were involved to optimize the design for iOS and Android usage.
+
+## Accessibility
+
+Accessibility of the application was one of our top priorities when designing and implementing the app. Once available, it will support all accessibility features within the operating systems such as zooming to enlarge text, screen readers like VoiceOver for iOS and TalkBack for Android, or special color contrasts.
+
+## Screens
+
+![Figure 1: UI Screens for Google Android](images/ui_screens/ui_screens_android.png "Figure 1: UI Screens for Google Android")
+Figure 1: UI Screens for Google Android [(high-resolution images)](images/ui_screens/android/)
+
+![Figure 2: UI Screens for Apple iOS](images/ui_screens/ui_screens_ios.png "Figure 2: UI Screens for Apple iOS")
+Figure 2: UI Screens for Apple iOS [(high-resolution images)](images/ui_screens/ios/)
+
+## Screen Descriptions
+
+1. This is the first screen ([Android](https://github.com/corona-warn-app/cwa-documentation/raw/master/images/ui_screens/android/cwa_onboarding_android.png), [iOS](https://github.com/corona-warn-app/cwa-documentation/raw/master/images/ui_screens/ios/cwa_onboarding_ios.png)) that a user sees when launching the app for the first time. It describes the purpose of the app and is only displayed once after the very first app start.
+2. The home screen ([Android](https://github.com/corona-warn-app/cwa-documentation/raw/master/images/ui_screens/android/cwa_home_android.png), [iOS](https://github.com/corona-warn-app/cwa-documentation/raw/master/images/ui_screens/ios/cwa_home_ios.png)) is the entry point to the app for further starts. It provides the user with the current risk status. In case of a positive test, it offers the opportunity to submit the diagnosis keys to the server with a QR code or a TeleTAN. Further, it allows the sharing of the app with others, offers additional information, as well as the app setting button.
+3. The detailed view ([Android](https://github.com/corona-warn-app/cwa-documentation/raw/master/images/ui_screens/android/cwa_detail_android.png), [iOS](https://github.com/corona-warn-app/cwa-documentation/raw/master/images/ui_screens/ios/cwa_detail_ios.png)) of the risk level repeats the information displayed on the home screen. It provides the user with behavioral recommendations in line with his current infection risk. Moreover, it explains how the infection risk was determined.
+4. The settings of the risk calculation screen ([Android](https://github.com/corona-warn-app/cwa-documentation/raw/master/images/ui_screens/android/cwa_risk_calculation_android.png), [iOS](https://github.com/corona-warn-app/cwa-documentation/raw/master/images/ui_screens/ios/cwa_risk_calculation_ios.png)) can be accessed via the home screen as well as via the application settings. It explains the risk calculation and allows users to control it. In case of a significant malfunction of the risk calculation (e.g. the deactivation of Bluetooth) the user will be informed and provided with a solution.