covid19/cwa-documentation
covid19
/
cwa-documentation
mirror of https://github.com/corona-warn-app/cwa-documentation
1
0
Fork 0
Code Releases Activity

Merge branch 'master' into sol_arch_clarification

This commit is contained in:
Thomas Kowark 2020-07-15 17:58:31 +02:00 committed by GitHub
parent 5390cab699 c466129b83
commit 172260f0f3
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
26 changed files with 5017 additions and 542 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
.alexignore Normal file
View File

@ -0,0 +1 @@
CODE_OF_CONDUCT.md

4
.alexrc.yaml Normal file
View File

@ -0,0 +1,4 @@
allow:
- German
- german
- european

40
.github/workflows/checks.yml vendored Normal file
View File

@ -0,0 +1,40 @@
name: Checks
on: [push]
jobs:
build:
name: Build
runs-on: ubuntu-latest
steps:
- name: Install requirements
run: |
sudo apt install -y automake npm nodejs
- name: Checkout code
uses: actions/checkout@v2
- name: Install npm dependencies
if: always()
run: |
npm install
- name: Linting markdown
if: always()
run: |
npm run-script markdownlint
- name: Checking for broken links
if: always()
run: |
npm run-script checklinks
#- name: Spellchecking english
# if: always()
# run: |
# npm run-script spellcheck
#- name: Detect inconsiderate language
# if: always()
# run: |
# npm run-script detect-inconsiderate-language

1
.gitignore vendored
View File

@ -1 +1,2 @@
.DS_STORE
node_modules

34
.markdownlint.json Normal file
View File

@ -0,0 +1,34 @@
{
"default": true,
"MD013": false,
"MD026": false,
"MD024": {
"allow_different_nesting": true
},
"MD033": {
"allowed_elements": [
"a",
"blockquote",
"br",
"code",
"em",
"hr",
"img",
"li",
"ol",
"p",
"pre",
"sup",
"table",
"tbody",
"td",
"th",
"thead",
"tr",
"u",
"ul"
]
},
"MD034": false,
"MD036": false
}

123
.spelling Normal file
View File

@ -0,0 +1,123 @@
14-day
24-hour
alex
amongst
analytics
APIs
APNs
backend
Backend
barcode
barcodes
BlackDuck
blacklist
broadcasted
Bundesbeauftragter
Bundesnetzagentur
changelog
Changelog
changelogs
Changelogs
Checkmarx
commonmark
Commonmark
config
Config
coronavirus
Covid-19
cwa-app-android
cwa-app-ios
cwa-server
cwa-testresult-server
cwa-verification-iam
cwa-verification-portal
cwa-verification-server
CxSAST
cyber
Cyber
DDoS
deanonymize
Deutsche
DP-3T
e.g.
en_US
epidemiologically
flyer
focussing
Gesundheitsamt
hacktivism
hardcoded
Hardcoded
how-tos
i.e.
IfSG
Informationsfreiheit
Infrastrukturen
iOS
Kritische
lifecycle
Lifecycle
linter
linters
logfile
logfiles
macOS
markdownlint.json
metadata
Metadata
misconfiguration
natively
npm
onboarding
Onboarding
package.json
PEPP-PT
PostgreSQL
pre-printed
Probenbegleitschein
Protecode
pseudonymized
rebase
reinstall
reinstalls
remediate
Remediate
resize
RPIs
SafetyNet
sap.com
Sarbanes-Oxley
SARS-CoV-2
sexualized
socio-economic
SonarQube
Synopsys
TalkBack
TEK
TEKs
Telekom
teleTAN
TeleTAN
teleTANs
TeleTANs
timeframe
timestamp
timestamping
Timestamping
tl
tl;dr
Tx
UI
uninstallation
Uninstallation
unlinkability
Unlinkability
unobservability
Unobservability
unsecure
up-to-dateness
useable
versioning
Vulas
whitelist
WhiteSource

10
CODEOWNERS
View File

@ -5,11 +5,15 @@
# For more details, read the following article on GitHub: https://help.github.com/articles/about-codeowners/.
# These are the default owners for the whole content of this repository. The default owners are automatically added as reviewers when you open a pull request, unless different owners are specified in the file.
* @SebastianWolf-SAP @tkowark @LukasMasuch @raethlein
* @SebastianWolf-SAP @tkowark
# Solution architecture document and its translations
solution_architecture*.md @tklingbeil @SebastianWolf-SAP @tkowark @LukasMasuch @raethlein
/images/solution_architecture/ @tklingbeil @SebastianWolf-SAP @tkowark @LukasMasuch @raethlein
solution_architecture*.md @tklingbeil @SebastianWolf-SAP @tkowark
/images/solution_architecture/ @tklingbeil @SebastianWolf-SAP @tkowark
# Epidemiological Motivation of the Transmission Risk Level
transmission_risk* @kirchnergo @hoehleatsu @weidemannf @dirkschumacher @benzlerj
# How does the Corona-Warn-App identify an increased risk?
cwa-risk* @benzlerj @hoehleatsu @kirchnergo @SebastianWolf-SAP
translations/cwa-risk* @benzlerj @hoehleatsu @kirchnergo @SebastianWolf-SAP

100
CODE_OF_CONDUCT.md
View File

@ -3,128 +3,78 @@
## Our Pledge
We as members, contributors, and leaders pledge to make participation in our
community a harassment-free experience for everyone, regardless of age, body
size, visible or invisible disability, ethnicity, sex characteristics, gender
identity and expression, level of experience, education, socio-economic status,
nationality, personal appearance, race, religion, or sexual identity
and orientation.
We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation.
We pledge to act and interact in ways that contribute to an open, welcoming,
diverse, inclusive, and healthy community.
We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community.
## Our Standards
Examples of behavior that contributes to a positive environment for our
community include:
Examples of behavior that contributes to a positive environment for our community include:
* Demonstrating empathy and kindness toward other people
* Being respectful of differing opinions, viewpoints, and experiences
* Giving and gracefully accepting constructive feedback
* Accepting responsibility and apologizing to those affected by our mistakes,
and learning from the experience
* Focusing on what is best not just for us as individuals, but for the
overall community
* Accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience
* Focusing on what is best not just for us as individuals, but for the overall community
Examples of unacceptable behavior include:
* The use of sexualized language or imagery, and sexual attention or
advances of any kind
* The use of sexualized language or imagery, and sexual attention or advances of any kind
* Trolling, insulting or derogatory comments, and personal or political attacks
* Public or private harassment
* Publishing others' private information, such as a physical or email
address, without their explicit permission
* Other conduct which could reasonably be considered inappropriate in a
professional setting
* Publishing others' private information, such as a physical or email address, without their explicit permission
* Other conduct which could reasonably be considered inappropriate in a professional setting
## Enforcement Responsibilities
Community leaders are responsible for clarifying and enforcing our standards of
acceptable behavior and will take appropriate and fair corrective action in
response to any behavior that they deem inappropriate, threatening, offensive,
or harmful.
Community leaders are responsible for clarifying and enforcing our standards of acceptable behavior and will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful.
Community leaders have the right and responsibility to remove, edit, or reject
comments, commits, code, wiki edits, issues, and other contributions that are
not aligned to this Code of Conduct, and will communicate reasons for moderation
decisions when appropriate.
Community leaders have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, and will communicate reasons for moderation decisions when appropriate.
## Scope
This Code of Conduct applies within all community spaces, and also applies when
an individual is officially representing the community in public spaces.
Examples of representing our community include using an official e-mail address,
posting via an official social media account, or acting as an appointed
representative at an online or offline event.
This Code of Conduct applies within all community spaces, and also applies when an individual is officially representing the community in public spaces. Examples of representing our community include using an official e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event.
## Enforcement
Instances of abusive, harassing, or otherwise unacceptable behavior may be
reported to the community leaders responsible for enforcement at
[corona-warn-app.opensource@sap.com](mailto:corona-warn-app.opensource@sap.com).
All complaints will be reviewed and investigated promptly and fairly.
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to the community leaders responsible for enforcement at [corona-warn-app.opensource@sap.com](mailto:corona-warn-app.opensource@sap.com). All complaints will be reviewed and investigated promptly and fairly.
All community leaders are obligated to respect the privacy and security of the
reporter of any incident.
All community leaders are obligated to respect the privacy and security of the reporter of any incident.
## Enforcement Guidelines
Community leaders will follow these Community Impact Guidelines in determining
the consequences for any action they deem in violation of this Code of Conduct:
Community leaders will follow these Community Impact Guidelines in determining the consequences for any action they deem in violation of this Code of Conduct:
### 1. Correction
**Community Impact**: Use of inappropriate language or other behavior deemed
unprofessional or unwelcome in the community.
**Community Impact**: Use of inappropriate language or other behavior deemed unprofessional or unwelcome in the community.
**Consequence**: A private, written warning from community leaders, providing
clarity around the nature of the violation and an explanation of why the
behavior was inappropriate. A public apology may be requested.
**Consequence**: A private, written warning from community leaders, providing clarity around the nature of the violation and an explanation of why the behavior was inappropriate. A public apology may be requested.
### 2. Warning
**Community Impact**: A violation through a single incident or series
of actions.
**Community Impact**: A violation through a single incident or series of actions.
**Consequence**: A warning with consequences for continued behavior. No
interaction with the people involved, including unsolicited interaction with
those enforcing the Code of Conduct, for a specified period of time. This
includes avoiding interactions in community spaces as well as external channels
like social media. Violating these terms may lead to a temporary or
permanent ban.
**Consequence**: A warning with consequences for continued behavior. No interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, for a specified period of time. This includes avoiding interactions in community spaces as well as external channels like social media. Violating these terms may lead to a temporary or permanent ban.
### 3. Temporary Ban
**Community Impact**: A serious violation of community standards, including
sustained inappropriate behavior.
**Community Impact**: A serious violation of community standards, including sustained inappropriate behavior.
**Consequence**: A temporary ban from any sort of interaction or public
communication with the community for a specified period of time. No public or
private interaction with the people involved, including unsolicited interaction
with those enforcing the Code of Conduct, is allowed during this period.
Violating these terms may lead to a permanent ban.
**Consequence**: A temporary ban from any sort of interaction or public communication with the community for a specified period of time. No public or private interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, is allowed during this period. Violating these terms may lead to a permanent ban.
### 4. Permanent Ban
**Community Impact**: Demonstrating a pattern of violation of community
standards, including sustained inappropriate behavior, harassment of an
individual, or aggression toward or disparagement of classes of individuals.
**Community Impact**: Demonstrating a pattern of violation of community standards, including sustained inappropriate behavior, harassment of an individual, or aggression toward or disparagement of classes of individuals.
**Consequence**: A permanent ban from any sort of public interaction within
the community.
**Consequence**: A permanent ban from any sort of public interaction within the community.
## Attribution
This Code of Conduct is adapted from the [Contributor Covenant][homepage],
version 2.0, available at
https://www.contributor-covenant.org/version/2/0/code_of_conduct.html.
This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 2.0, available at https://www.contributor-covenant.org/version/2/0/code_of_conduct.html.
Community Impact Guidelines were inspired by [Mozilla's code of conduct
enforcement ladder](https://github.com/mozilla/diversity).
Community Impact Guidelines were inspired by [Mozilla's code of conduct enforcement ladder](https://github.com/mozilla/diversity).
[homepage]: https://www.contributor-covenant.org
For answers to common questions about this code of conduct, see the FAQ at
https://www.contributor-covenant.org/faq. Translations are available at
https://www.contributor-covenant.org/translations.
For answers to common questions about this code of conduct, see the FAQ at https://www.contributor-covenant.org/faq. Translations are available at https://www.contributor-covenant.org/translations.

13
CONTRIBUTING.md
View File

@ -1,12 +1,16 @@
# Contributing
## Build status
![Checks](https://github.com/corona-warn-app/cwa-documentation/workflows/Checks/badge.svg)
## Code of Conduct
All members of the project community must abide by the [Contributor Covenant, version 2.0](CODE_OF_CONDUCT.md).
Only by respecting each other we can develop a productive, collaborative community.
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting [corona-warn-app.opensource@sap.com](mailto:corona-warn-app.opensource@sap.com) and/or a project maintainer.
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting [corona-warn-app.opensource@sap.com](mailto:corona-warn-app.opensource@sap.com) and/or a project maintainer.
We appreciate your courtesy of avoiding political questions here. Issues which are not related to the project itself will be closed by our community managers.
We appreciate your courtesy of avoiding political questions here. Issues which are not related to the project itself will be closed by our community managers.
## Engaging in Our Project
@ -38,7 +42,8 @@ The following rule governs code contributions:
## Contributing Documentation
You are welcome to contribute documentation to the project.
You are welcome to contribute documentation to the project. Please see the
installation [document](INSTALL.md)
The following rule governs documentation contributions:
@ -64,7 +69,7 @@ The following rule governs documentation contributions:
## Issues and Planning
* We use GitHub issues to track bugs and enhancement requests.
* We use GitHub issues to track bugs and enhancement requests.
* Please provide as much context as possible when you open an issue. The information you provide must be comprehensive enough to reproduce that issue for the assignee. Therefore, contributors should use but aren't restricted to the issue template provided by the project maintainers.

145
INSTALL.md Normal file
View File

@ -0,0 +1,145 @@
# Development on documentation
## tl;dr
**You will need to use following `npm scripts` before creating a pull request!**
1. `npm install`
2. `npm test`
## Features
* Linting of markdown documents
* Spell checking
* Link checking
## Specifications
This repository checks against following specification:
* [Markdown Commonmark](https://spec.commonmark.org/)
### Languages
Supported languages are:
* [English US](https://en.wikipedia.org/wiki/ISO/IEC_8859-1)
## Prerequisites
To run all the linters please install for your OS:
* [npm](https://github.com/nodesource/distributions)
## Installation
For linting and all the checks you need several npm packages. The following command installs all necessary npm dependencies:
```shell
npm install
```
This installs all dependencies into a local `node_modules` folder.
## Checks
To enforce good spelling and specification conformity there are several checks defined as `npm run-script` targets. To run all checks please execute:
```shell
npm test
```
### Individual checks
If you want to run individual checks see the targets and the description below.
Every individual check can be run like so:
```shell
npm runscript my-individual-check
```
See the package.json file for help.
#### Markdown linter
Markdown linting. See the rules [here](https://github.com/DavidAnson/markdownlint).
```shell
npm run-script markdownlint
```
##### Markdown linter overrides
Sometimes it is not possible to be commonmark conform. In this rare cases an inline tag to skip linting is possible.
Candidates are tables.
```html
<!-- markdownlint-disable-->
| Column 1 | Column 2 | Column 3 |
|----------|----------|----------|
<!-- markdownlint-enable-->
```
Additionally HTML image tags can be allowed globally. This is useful if you need
to resize images, since commonmark has no annotation for this.
This is done with a .markdownlint.json override file which would look something
like this:
```json
{
"no-inline-html": {
"allowed_elements": [
"img",
"table"
]
}
}
```
For more information how to tweak overrides consult the markdown linter
documentation mentioned above.
#### Spell checker
##### English
Spell checking in American English (en_US).
```shell
npm run-script spellcheck
```
##### German
Not implemented yet.
##### Spell checker overrides
Add any additional words to the .spelling file and use the target to sort and
clean them before adding these to master.
```shell
npm run-script format-spelling
```
Please note sometimes overriding is not the way to go. Our terminology should be
applied consistently.
#### Link resolver
All cross references and external URLs are resolved.
```shell
npm run-script checklinks
```
#### Inconsiderate language scanner
This checks against profanity and inconsiderate language. This is help full for
non-natives to detect words that could be inconsiderate. This utilizes [alex](https://github.com/get-alex/alex)
```shell
npm run-script detect-inconsiderate-language
```

42
README.md
View File

@ -4,7 +4,7 @@
<hr />
<p align="center">
<a href="#about-this-project">About this Project</a> •
<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> •
@ -17,11 +17,14 @@
</p>
<hr />
# Corona-Warn-App: Documentation
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 "<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
@ -49,38 +52,43 @@ We are building this application for Germany. We want to be as open and transpar
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.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)
* [Corona-Warn-App Security Overview](overview-security.md)
* [Corona-Warn-App Backend Infrastructure Architecture Overview](https://github.com/corona-warn-app/cwa-documentation/blob/master/backend-infrastructure-architecture.pdf)
* [How does the Corona-Warn-App identify an increased risk?](cwa-risk-assessment.md)
* [Epidemiological Motivation of the Transmission Risk Level (PDF)](https://github.com/corona-warn-app/cwa-documentation/blob/master/transmission_risk.pdf), [(Rmd file)](https://github.com/corona-warn-app/cwa-documentation/blob/master/transmission_risk.Rmd), [(bib references)](https://github.com/corona-warn-app/cwa-documentation/blob/master/transmission_risk_references.bib)
* [Corona-Warn-App Data Privacy Impact Assessment/DPIA (PDF, German)](https://www.coronawarn.app/assets/documents/cwa-datenschutz-folgenabschaetzung.pdf), [DPIA Annex 1](https://www.coronawarn.app/assets/documents/cwa-datenschutz-folgenabschaetzung-anlage1.pdf), [DPIA Annex 2](https://www.coronawarn.app/assets/documents/cwa-datenschutz-folgenabschaetzung-anlage2.pdf), [DPIA Annex 3](https://www.coronawarn.app/assets/documents/cwa-datenschutz-folgenabschaetzung-anlage3.pdf), [DPIA Annex 4](https://www.coronawarn.app/assets/documents/cwa-datenschutz-folgenabschaetzung-anlage4.pdf), [DPIA Annex 5](https://www.coronawarn.app/assets/documents/cwa-datenschutz-folgenabschaetzung-anlage5.pdf)
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.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/develop/docs/architecture-overview.md)
- [Criteria for the Evaluation of Contact Tracing Apps](pruefsteine.md)
- [Corona-Warn-App Security Overview](overview-security.md)
- [Corona-Warn-App Backend Infrastructure Architecture Overview](https://github.com/corona-warn-app/cwa-documentation/blob/master/backend-infrastructure-architecture.pdf)
- [How does the Corona-Warn-App identify an increased risk?](cwa-risk-assessment.md)
- [Epidemiological Motivation of the Transmission Risk Level (PDF)](https://github.com/corona-warn-app/cwa-documentation/blob/master/transmission_risk.pdf), [(Rmd file)](https://github.com/corona-warn-app/cwa-documentation/blob/master/transmission_risk.Rmd), [(bib references)](https://github.com/corona-warn-app/cwa-documentation/blob/master/transmission_risk_references.bib)
- [Corona-Warn-App Data Privacy Impact Assessment/DPIA (PDF, German)](https://www.coronawarn.app/assets/documents/cwa-datenschutz-folgenabschaetzung.pdf), [DPIA Annex 1](https://www.coronawarn.app/assets/documents/cwa-datenschutz-folgenabschaetzung-anlage1.pdf), [DPIA Annex 2](https://www.coronawarn.app/assets/documents/cwa-datenschutz-folgenabschaetzung-anlage2.pdf), [DPIA Annex 3](https://www.coronawarn.app/assets/documents/cwa-datenschutz-folgenabschaetzung-anlage3.pdf), [DPIA Annex 4](https://www.coronawarn.app/assets/documents/cwa-datenschutz-folgenabschaetzung-anlage4.pdf), [DPIA Annex 5](https://www.coronawarn.app/assets/documents/cwa-datenschutz-folgenabschaetzung-anlage5.pdf)
To be published:
* System Operation
- System Operation
### Glossary
For an easier understanding of the used acronyms and special terms in our documents please see our [glossary](glossary.md).
## Licensing
Copyright (c) 2020 Deutsche Telekom AG and SAP SE or an SAP affiliate company.
Licensed under the **Apache License, Version 2.0** (the "License"); you may not use this file except in compliance with the License.
Licensed under the **Apache License, Version 2.0** (the "License"); you may not use this file except in compliance with the License.
You may obtain a copy of the License at https://www.apache.org/licenses/LICENSE-2.0.

3
backend-infrastructure-architecture.md
View File

@ -1,6 +1,7 @@
# German Corona Warn App (CWA)
## Backend Infrastructure Architecture Overview
The file ``backend-infrastructure-architecture.pdf`` complements the "CWA Solution Architecture" document. It is intended as a technical overview document of Corona Warn App (CWA) and its underlying infrastructure and network.
This description of the **cwa backend infrastructure architecture** is not published as MD file, because it is not intended to be developed together with the community. Whoever takes the sources and sets up their own "corona warn app" may use another backend structure. Nevertheless, it might be helpful to know how the current project is implemented in a data center. Therefore, we publish this document as a pdf file.
This description of the **CWA backend infrastructure architecture** is not published as MD file, because it is not intended to be developed together with the community. Whoever takes the sources and sets up their own "Corona-Warn-App" may use another backend structure. Nevertheless, it might be helpful to know how the current project is implemented in a data center. Therefore, we publish this document as a PDF file.

150
cwa-risk-assessment.md
View File

@ -2,32 +2,156 @@
## Prerequisites
People who use the Corona-Warn-App (CWA) and are tested positive for the SARS-CoV-2 coronavirus can allow their CWA to upload the random device keys (*temporary exposure keys*) that have been generated on their smartphones in recent days to the Corona-Warn-App server as *diagnosis keys* and release them there. These diagnosis keys are the basis for risk identification for all other CWA users.
People who use the Corona-Warn-App (CWA) and are tested positive for the SARS-CoV-2 coronavirus can allow their CWA to upload the random device keys (*temporary exposure keys*) that have been generated by their smartphone's operating system in recent days to the Corona-Warn-App server as *diagnosis keys* and release them there.
These diagnosis keys are the basis for risk identification for all other CWA users.
A user who has tested positive for coronavirus uploads up to 15 diagnosis keys: one for each of the up to 14 days before the download, as well as one for the current day, which is uploaded the next day. The latter is necessary because diagnosis keys can only be uploaded for past days.
A user who has tested positive for coronavirus uploads up to 15 diagnosis keys: one for each of the up to 14 days before the upload, as well as (still to be implemented) one for the current day, which is uploaded the next day.
The latter is necessary because diagnosis keys can only be uploaded for past days in order to prevent abuse of diagnosis keys that are still active.
Diagnosis keys do not give any indication as to the identity of a person who has tested positive, but a diagnosis key from a certain day can be matched with the *rolling proximity identifiers* that a user’s smartphone has transmitted via Bluetooth throughout a given day and were received and recorded by other smartphones nearby. Each diagnosis key is appended with a value that indicates the *transmission risk level* that likely existed for the person who has tested positive on the day that the diagnosis key belongs to. This transmission risk is then estimated in a complex procedure, which is based on empirical values and takes the latest scientific findings into account. Every diagnosis key expires after 14 days. Therefore, only the diagnosis keys from the last 14 days are available.
Diagnosis keys do not give any indication as to the identity of a person who has tested positive, but a diagnosis key from a certain day can be matched with the *rolling proximity identifiers* that a user’s smartphone has transmitted via Bluetooth throughout a given day and were received and recorded by other smartphones nearby.
Each diagnosis key is appended with a value that indicates the *transmission risk level* that likely existed for the person who has tested positive on the day that the diagnosis key belongs to.
This transmission risk is [estimated in a mathematical procedure](transmission_risk.pdf), which is based on empirical evidence and takes the latest scientific findings into account.
Every diagnosis key expires after 14 days. Therefore, only the diagnosis keys from the last 14 days are available.
## Procedure
Several times per day, all active Corona-Warn-Apps download the diagnosis keys released on the Corona-Warn-App server and pass them on to the operating system in batches through an interface. The app checks whether any of these received, recorded rolling proximity identifiers match any of the diagnosis keys. If there is a match, this indicates that the user’s smartphone encountered the smartphone of a person who has uploaded a diagnosis key on the day to which the diagnosis key belongs.
Daily, all active Corona-Warn-Apps download the diagnosis keys released on the Corona-Warn-App server and pass them on to the smartphone's operating system in batches through an interface.
The operating system checks whether any of the rolling proximity identifiers that it has received and recorded over the past 14 days match any of the diagnosis keys.
If there is a match, this indicates that the user’s smartphone encountered the smartphone of a person who has uploaded the diagnosis key, on the day to which the diagnosis key belongs.
In the next step, the app analyzes all the matching rolling proximity identifiers for each diagnosis key, to estimate how long the exposure lasted in total on the day in question and how close the smartphones were to each other on average during the exposure. The distance is calculated from the measured reduction in strength of the Bluetooth signal, which is specified in dB (decibel). All exposures for a diagnosis key that lasted less than 10 minutes in total (regardless of how close the smartphones came during that time) or during which the smartphones were more than 8 meters (73 dB attenuation) apart on average (regardless of how long the exposure lasted) are discarded as harmless.
> Note: Days in the context of the Corona-Warn-App and thus in this document are calendar days according to UTC (Coordinated Universal Time). They change at 1 am Central European Time and 2 am Central European Summer Time, respectively.
> NB: In the following, the total of all exposures that belong to a diagnosis key, that is, all exposures over a day between the same two smartphones, is referred to as the “exposure set”.
In the next step, the operating system analyzes all the matching rolling proximity identifiers for each diagnosis key, to estimate how long the encounter lasted in total on the day in question and how close both smartphones were to each other on average during the encounter.
The distance is calculated from the measured reduction in strength of the Bluetooth signal, which is specified in dB (decibel).
Under perfect circumstances, i.e. without any obstacle in the signal pathway (see also section “Consequences and Constraints”), each dB value is associated with a particular distance.
All encounters for a diagnosis key that lasted less than 10 minutes in total (regardless of how close the smartphones came during that time) or during which the smartphones were more than 8 meters (>73 dB attenuation) apart on average (regardless of how long the encounter lasted) are discarded as negligible risk.
For the remaining exposures that have not been discarded as harmless, a *total risk score* is calculated for each exposure set, by multiplying the transmission risk score described above by the *days since last exposure value*, which is calculated as the time between the day of the last exposure and the current day.
> Note: In the following, the total of all encounters that belong to a particular diagnosis key, that is, all encounters over a given day between the same two smartphones, is referred to as the “encounter set”.
All exposure sets that exceed a certain threshold (the *minimum risk score*) are considered to be risk exposures. The other exposure sets are discarded as harmless, like the sets that were previously discarded for being too short and/or too distant.
For the remaining encounters that have not been discarded, a *total risk score* is calculated for each encounter set, by multiplying the transmission risk score described above by the *days since last exposure value*, which is derived from the day count since the most recent encounter to the current day.
At the same time, the remaining risk exposures are added together to determine how much time exposure took place within a very close range below 1.5 meters (55 dB attenuation) and how much time exposure took place in a close range between 1.5 and 3 meters (63 dB attenuation).
All encounter sets whose total risk score exceeds a certain threshold (the *minimum risk score*) are considered to be risk exposures.
The other encounter sets are discarded as negligible risk, like the sets that were previously discarded for being too short and/or too distant.
The total calculated time is then cross- calculated against the *maximum risk score*, the exposure with the highest risk: the time remains unchanged if this risk is estimated as average (for risk exposures), it is extended to one and a half times if the risk is above average, and it is reduced significantly (to around one-sixth) if the risk is below average. As a result, an exposure time of 10 minutes can be extended to more than 15 minutes and an exposure time of 45 minutes can be reduced to less than 10 minutes.
At the same time, all remaining risk exposures are added together to determine how much time exposure took place within a very close range below 1.5 meters (<55 dB attenuation) and how much time exposure took place in a close range between 1.5 and 3 meters (55 to 63 dB attenuation).
Time spent in a distance greater than 3 meters apart will not be considered.
The total calculated time of all exposures of the latest 14 days is then adjusted using the *maximum risk score* of the exposure with the highest risk: the time remains unchanged if this risk is estimated as average (for risk exposures), it is extended to one and a half times if the risk is above average, and it is reduced significantly (to around one-sixth) if the risk is below average.
As a result, an exposure time of 10 minutes can be extended to more than 15 minutes and an exposure time of 45 minutes can be reduced to less than 10 minutes.
## Consequences and Constraints
In the end, a CWA user is notified of an increased risk whenever the risk exposure time calculated as described above amounts to 15 minutes or longer. This notification takes place in the CWA and, at the same time, provides recommendations as to how the user should proceed.
In the end, a CWA user is notified of an increased risk whenever the risk exposure time calculated as described above amounts to 15 minutes or longer.
This notification takes place in the CWA and, at the same time, provides recommendations as to how the user should proceed.
When assessing the times and distances calculated by the CWA, it is important to consider that it is not possible to measure these two parameters precisely. The individually measured times can deviate from the actual exposure time by 5 minutes plus or minus and the calculated distances are approximate values under ideal conditions, that is, without any impediments between the two smartphones. Even minor impediments, such as a person between the two smartphones or a signal-impeding smartphone case, can cause the distance to appear to be twice as large as it actually is.
When assessing the times and distances calculated by the CWA, it is important to consider that it is not possible to measure these two parameters precisely.
The individually measured times can deviate from the actual encounter time by 5 minutes plus or minus and the calculated distances are approximate values under ideal conditions, that is, without any impediments between the two smartphones.
Even minor impediments, such as a person between the two smartphones or a signal-impeding smartphone case, can cause the distance to appear to be twice as large as it actually is.
Due to privacy considerations, the properties described above can currently only be queried for the total set of all risk exposures at the interface to the operating system, but not for individual risk exposures or exposure by day. As long as the number of new infections remains relatively low, this should not make much of a difference, because it is likely that only very few CWA users will have been exposed to multiple persons who have tested positive within the time frame until they are notified.
Due to privacy considerations, the properties described above can currently only be queried for the total set of all risk exposures at the interface to the operating system, but not for individual risk exposures or exposure by day.
As long as the number of new infections remains relatively low, this should not make much of a difference, because it is likely that only very few CWA users will have been exposed to multiple persons who have tested positive within the time frame until they are notified.
## An Example
Anton and Aisha are each notified on the 20th of the month that according to their test results, they have contracted COVID-19.
That same day, Anton allows his CWA to notify other CWA users with whom he has had risk exposures.
The CWA has been running on his smartphone continuously for the past week.
The CWA now uploads his temporary exposure keys from the latest 7 days to the CWA server as diagnosis keys (no further keys are available, because Anton has only been using the CWA for 8 days and the current exposure keys cannot be uploaded yet).
They are assigned the transmission risk levels VI (for the previous day), three times VIII (for the 16th to the 18th), V, III, and I (in descending order for the other past days, the 13th to the 15th).
|||||||||
|-|:-:|:-:|:-:|:-:|:-:|:-:|:-:|
|Transmission risk level|VI|VIII|VIII|VIII|V|III|I|
|Days until upload consent granted|1|2|3|4|5|6|7|
|Generation date of the key|19th|18th|17th|16th|15th|14th|13th|
Table 1: Transmission risk level for Anton’s 7 shared diagnosis keys, based on the interval from the day upload consent is granted (20th)
Aisha hesitates for a day and does not grant consent until the 21st of the month.
Since she activated her CWA several weeks ago and has been running it in the background ever since, her temporary exposure keys from the latest 14 days are available to upload.
Her diagnosis keys are also assigned the transmission risk level VI, three times VIII, V, III, and I in descending order for the previous seven days, but starting with the 20th, and thus offset one day compared to Anton.
(The CWA does not know that both people were informed of their test results on the same day. In the current version, only the date on which consent to upload is granted is available to determine the day-specific transmission risk levels.)
The 7 older days, the period from the 7th to the 13th of the month, are each assigned the transmission risk level I.
||||||||||||||||
|-|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|
|Transmission risk level|VI|VIII|VIII|VIII|V|III|I|I|I|I|I|I|I|I|
|Days until upload consent granted|1|2|3|4|5|6|7|8|9|10|11|12|13|14|
|Generation date of the key|20th|19th|18th|17th|16th|15th|14th|13th|12th|11th|10th|9th|8th|7th|
Table 2: Transmission risk level for Aisha’s 14 shared diagnosis keys, based on the interval from the day upload consent is granted (21st)
Anton and Aisha regularly travel to work together.
Betty takes the same route and occasionally rides the same bus.
All three of them use their smartphones during the journey, which means there are no impediments to the Bluetooth signals.
Betty met Anton and Aisha on the 9th and the 16th, for 10 minutes each in the morning and in the evening.
Anton sat one meter away from Betty, while Aisha sat two meters away.
When Betty’s CWA retrieves Anton’s diagnosis keys on the 21st and passes them on to her smartphone's operating system's interface, an encounter set is recognized for the 16th.
(Anton’s CWA did not upload a diagnosis key for the 9th.)
This encounter set lasted a total of 20 minutes and the smartphones were an average of one meter apart.
This results in values of 1 for both duration and attenuation (also see “Exposure Configuration” in the section “Current Configuration”).
This ensures that this encounter set is not discarded.
The value of the parameter for the delay risk (21 - 16 = 5 days) is configured at 5 continuously and the value for the transmission risk is taken directly from the transmission risk level, which means it is 8.
The total risk level is therefore calculated as 1 x 1 x 5 x 8 = 40, which incidentally is the highest value that can be reached with the current configuration.
The threshold of 11 is exceeded, which means the encounter set counts as a risk exposure.
| | | | | | | | | |
|-|-|-|-|-|-|-|-|-|
|Days since most recent exposure| >=14d (5) | 12-13d (5) | 10-11d (5) | 8-9d (5) | 6-7d (5) | **4-5d (5)** | 2-3d (5) | 0-1d (5) |
|Attenuation| >73dB (0) | >63-<=73dB (1) | >51-<=63dB (1) | **>33-<=51dB (1)** | >27-<=33dB (1) | >15-<=27dB (1) | >10-<=15dB (1) | <=10dB (1) |
|Duration| 0min (0) | >0-<=5min (0) | >5-<=10min (0) | >10-<=15min (1) | **>15-<=20min (1)** | >20-<=25min (1) | >25-<=30min (1) | >30min (1) |
|Transmission risk| I (1) | II (2) | III (3) | IV (4) | V (5) | VI (6) | VII (7) | **VIII (8)** |
Table 3: Parameter values for Betty’s encounter set with Anton on the 16th
Since this risk exposure is the only risk exposure known to Betty’s CWA, it is the only one taken into account in the summary evaluation of her times spent in the distance ranges up to 1.5 meters and up to 3 meters.
Betty spent 20 minutes in the distance range below 1.5 meters, which are counted fully.
Even if these 20 minutes are cross-calculated against the risk exposure with the highest risk, only this one risk exposure is taken into account, with its exposure risk of 40.
The multiplication of these 20 minutes by 40/25 (25 is the currently configured value for “average risk” exposures; also see the risk score normalization divisor in "Configuration of Attenuation and Duration” in the section “Current Configuration”) equals 32 minutes.
Since the CWA sends notifications of increased risk starting with 15 minutes, Betty’s app sends her a notification.
She is notified that she had a risk exposure 5 days ago.
The next day, the 22nd, Betty’s CWA also retrieves Aisha’s diagnosis keys.
It identifies additional encounters on the 16th and the 9th of the month.
Both encounter sets lasted a total of 20 minutes each and the smartphones were an average of two meters apart.
This also results in values of 1 for duration and attenuation.
The delay risk values (22 - 16 = 6 days; 22 - 9 = 13 days) are a constant 5 and the transmission risk values are 5 for the 16th and 1 for the 9th of the month.
As a result, the exposure risks for the 16th are calculated as 1 x 1 x 5 x 5 = 25 and for the 9th as 1 x 1 x 5 x 1 = 5.
The encounter set from the 9th does not reach the threshold and is therefore not counted as a risk exposure.
| | | | | | | | | |
|-|-|-|-|-|-|-|-|-|
|Days since most recent exposure| >=14d (5) | 12-13d (5) | 10-11d (5) | 8-9d (5) | **6-7d (5)** | 4-5d (5) | 2-3d (5) | 0-1d (5) |
|Attenuation| >73dB (0) | >63-<=73dB (1) | **>51-<=63dB (1)** | >33-<=51dB (1) | >27-<=33dB (1) | >15-<=27dB (1) | >10-<=15dB (1) | <=10dB (1) |
|Duration| 0min (0) | >0-<=5min (0) | >5-<=10min (0) | >10-<=15min (1) | **>15-<=20min (1)** | >20-<=25min (1) | >25-<=30min (1) | >30min (1) |
|Transmission risk| I (1) | II (2) | III (3) | IV (4) | **V (5)** | VI (6) | VII (7) | VIII (8) |
Table 4: Parameter values for Betty’s encounter set with Aisha on the 16th
| | | | | | | | | |
|-|-|-|-|-|-|-|-|-|
|Days since most recent exposure| >=14d (5) | **12-13d (5)** | 10-11d (5) | 8-9d (5) | 6-7d (5) | 4-5d (5) | 2-3d (5) | 0-1d (5) |
|Attenuation| >73dB (0) | >63-<=73dB (1) | **>51-<=63dB (1)** | >33-<=51dB (1) | >27-<=33dB (1) | >15-<=27dB (1) | >10-<=15dB (1) | <=10dB (1) |
|Duration| 0min (0) | >0-<=5min (0) | >5-<=10min (0) | >10-<=15min (1) | **>15-<=20min (1)** | >20-<=25min (1) | >25-<=30min (1) | >30min (1) |
|Transmission risk| **I (1)** | II (2) | III (3) | IV (4) | V (5) | VI (6) | VII (7) | VIII (8) |
Table 5: Parameter values for Betty’s encounter set with Aisha on the 9th
In contrast, the risk exposure on the 16th is taken into account in the summary evaluation, which means Betty’s CWA now counts 20 minutes (with Anton) in the distance range up to 1.5 meters fully and an additional 20 minutes (with Aisha) in the distance range up to 3 meters half (that is, 10 minutes).
The calculated 30 minutes are once again cross-calculated with Betty’s risk exposure with Anton, which at 40 is still the highest exposure risk from all risk encounters identified in the recorded 14-day period, resulting in 30 x 40/25 = 48 minutes.
Betty’s updated risk notification now shows 2 risk encounters, the most recent of which took place 6 days ago.
## Current Configuration
As documented in the [risk score calculation section](https://github.com/corona-warn-app/cwa-documentation/blob/master/solution_architecture.md#risk-score-calculation) of the solution architecture document, the actual parameters for the calculation are provided by a set of parameters which are hosted on cwa-server.
This configuration might change over time according to the new research results and insights. The respective current set of configuration values can be looked up in the [cwa-server repository](https://github.com/corona-warn-app/cwa-server):
- [Exposure Configuration](https://github.com/corona-warn-app/cwa-server/blob/master/services/distribution/src/main/resources/master-config/exposure-config.yaml)
- [Attenuation & Duration Configuration](https://github.com/corona-warn-app/cwa-server/blob/master/services/distribution/src/main/resources/master-config/attenuation-duration.yaml)
- [App Configuration, including minimum risk score](https://github.com/corona-warn-app/cwa-server/blob/master/services/distribution/src/main/resources/master-config/app-config.yaml)
- [Risk Score Classification](https://github.com/corona-warn-app/cwa-server/blob/master/services/distribution/src/main/resources/master-config/risk-score-classification.yaml)

22
cwa-versioning.md Normal file
View File

@ -0,0 +1,22 @@
# Versioning
All components of the Corona Warn App use [Semantic versioning](https://semver.org/).
Given a version number MAJOR.MINOR.PATCH, increment the:
- MAJOR version when you make incompatible API changes,
- MINOR version when you add functionality in a backwards compatible manner, and
- PATCH version when you make backwards compatible bug fixes.
We plan to never deprecate outdated API versions. That means that even on MAJOR version changes our goal is to keep the old API functional.
## Maintaining compatible versions
Backend components will always remain compatible due to ongoing the availability of old API versions.
To ensure that all clients use the current "state of the art" information in order to apply the respective algorithms the cwa-server component can deprecate older Android and iOS app versions. The current minimum required app versions can be viewed in the [App Version Config](https://github.com/corona-warn-app/cwa-server/blob/master/services/distribution/src/main/resources/master-config/app-version-config.yaml).
The `app-version-config` is checked by the mobile clients on a regular basis. When the client detects that the required `min` version is higher than the current installed version, the user will be notified about the need to update the app. The app will not be useable until this update is performed.
## Changelogs
Changelogs can be found the in release notes attached to git tags, e.g. [Android App, Version 1.0.3](https://github.com/corona-warn-app/cwa-app-android/releases/tag/1.0.3).

12
glossary.md
View File

@ -15,19 +15,19 @@ This overview provides a description for all acronyms and special terms which ar
| COVID-19 | [Coronavirus disease 2019](https://en.wikipedia.org/wiki/Coronavirus_disease_2019) is an infectious disease caused by severe acute respiratory syndrome coronavirus 2 (SARS-CoV-2). |
| CTR | Acronym for "[Counter (Mode)](https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#CTR)", a mode of operation in cryptography, also used in the [Exposure Notification Framework](https://covid19-static.cdn-apple.com/applications/covid19/current/static/contact-tracing/pdf/ExposureNotification-CryptographySpecificationv1.2.pdf) |
| 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) |
| 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 |
| FCM | Acronym for "[Firebase Cloud Messaging](https://en.wikipedia.org/wiki/Firebase_Cloud_Messaging)", a cross-platform cloud solution for messages and notifications. |
| 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". |
| 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". |
| OTC | Acronym for "[Open Telekom Cloud](https://open-telekom-cloud.com/)"
| PEPP-PT | [Pan-European Privacy-Preserving Proximity Tracing](https://www.pepp-pt.org/), formerly endorsed approach to a COVID-19 exposure notification app for Germany. |
| QR Code | Acronym for [Quick Response Code](https://en.wikipedia.org/wiki/QR_code), a two-dimensional/matrix barcode used in the Corona-Warn-App, handed out by the test center after a test was conducted. See our [solution architecture document](solution_architecture.md) for details. |
| PEPP-PT | [Pan-European Privacy-Preserving Proximity Tracing](https://www.pepp-pt.org/), formerly endorsed approach to a COVID-19 exposure notification app for Germany. |
| QR Code | Acronym for [Quick Response Code](https://en.wikipedia.org/wiki/QR_code), a two-dimensional/matrix barcode used in the Corona-Warn-App, handed out by the test center after a test was conducted. See our [solution architecture document](solution_architecture.md) for details. |
| Registration Token | Used to a) link the mobile phone with the data from the QR Code and b) generate a TAN which is needed to finally perform the upload of the diagnosis keys to the Corona-Warn-App-Server. See our [solution architecture document](solution_architecture.md) for details. |
| REST | Acronym for "[Representational State Transfer](https://en.wikipedia.org/wiki/Representational_state_transfer)". |
| Risk score | Several parameters are used to calculate a risk score, i.e. the likelihood that a user has been exposed to the coronavirus. See our [solution architecture document](solution_architecture.md) for details. |
| Risk score | Several parameters are used to calculate a risk score, i.e. the likelihood that a user has been exposed to the coronavirus. See our [solution architecture document](solution_architecture.md) for details. |
| RKI | The [Robert Koch-Institut](https://www.rki.de/) is Germany’s public health institute. |
| 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. |
@ -35,4 +35,4 @@ This overview provides a description for all acronyms and special terms which ar
| 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. |
| 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. |

633
overview-security.md
View File

@ -1,265 +1,289 @@
# Secure Development
# Overview Security
## Secure Development
## Risk Assessment
An essential part of the development of secure applications is the risk assessment.
An essential part of the development of secure applications is the risk assessment.
### Threat Modeling
At the very beginning of the development process of this solution, development teams started to conduct threat modeling workshops. Within the threat modeling workshops, the teams identified risks, assets and assumptions, decided on risk response and created or updated their security plans.
## Identified Risks, Threats and Proposed Controls
Risks and threats identified during the conducted workshops are listed below. Please note that listed risks, threats and proposed controls are non-exhaustive and will be updated regularly.
### Technical Risks
- <a name="risk-identification-of-infected-person">Identification of infected persons and/or persons under test</a>
- Related threats
- [Insecure design](#threat-insecure-design)
- [Insecure programming](#threat-insecure-programming)
- [PostgreSQL SQL injection](#threat-postgresql-sql-injection)
- [Code injection flaws](#threat-code-injection-flaws)
- [Security misconfiguration](#threat-security-misconfiguration)
- [Wrong choice of technology](#threat-wrong-choice-of-technology)
- [Spoofing of mobile application](#threat-spoofing-of-mobile-application)
- [Misbehavior of mobile application due to backup and/or restore of phone and/or mobile application](#threat-misbehavior-of-mobile-application-backup-restore)
- [Information leakage of unprotected phone and/or mobile application](#threat-information-leakage-unprotected-phone)
- [Tampering of test retrieval and upload parameters](#threat-tampering-test-retrieval)
- [Tampering of diagnosis keys](#threat-tampering-diagnosis-keys)
- [Identity disclosure through metadata correlation](#threat-identity-disclosure-meta-data-correlation)
- <a name="risk-location-disclosure-of-infected-persons">Disclosure of the location of infected persons</a>
- Related threats
- [Insecure design](#threat-insecure-design)
- [Insecure programming](#threat-insecure-programming)
- [Security misconfiguration](#threat-security-misconfiguration)
- [Wrong choice of technology](#threat-wrong-choice-of-technology)
- [Identity disclosure through metadata correlation](#threat-identity-disclosure-meta-data-correlation)
- <a name="risk-social-network-disclosure">Social network disclosure</a>
- Related threats
- [Insecure design](#threat-insecure-design)
- <a name="risk-disclosure-of-notification-status">Disclosure of notification status</a>
- Related threats
- [Insecure programming](#threat-insecure-programming)
- [Using components with known vulnerabilities](#threat-using-components-with-known-vulnerabilities)
- [PostgreSQL SQL injection](#threat-postgresql-sql-injection)
- [Code injection flaws](#threat-code-injection-flaws)
- [Transaction hijacking](#threat-transaction-hijacking)
- [Security misconfiguration](#threat-security-misconfiguration)
- [Wrong choice of technology](#threat-wrong-choice-of-technology)
- [Spoofing of mobile application](#threat-spoofing-of-mobile-application)
- [Misbehavior of mobile application due to backup and/or restore of phone and/or mobile application](#threat-misbehavior-of-mobile-application-backup-restore)
- [Information leakage of unprotected phone and/or mobile application](#threat-information-leakage-unprotected-phone)
- [Tampering of test retrieval and upload parameters](#threat-tampering-test-retrieval)
- [Tampering of diagnosis keys](#threat-tampering-diagnosis-keys)
- [Identity disclosure through metadata correlation](#threat-identity-disclosure-meta-data-correlation)
- <a name="risk-disclosure-of-personal-data">Disclosure of personal data</a>
- Related threats
- [Insecure programming](#threat-insecure-programming)
- [Using components with known vulnerabilities](#threat-using-components-with-known-vulnerabilities)
- [PostgreSQL SQL injection](#threat-postgresql-sql-injection)
- [Code injection flaws](#threat-code-injection-flaws)
- [Transaction hijacking](#threat-transaction-hijacking)
- [Security misconfiguration](#threat-security-misconfiguration)
- [Wrong choice of technology](#threat-wrong-choice-of-technology)
- [Spoofing of mobile application](#threat-spoofing-of-mobile-application)
- [Misbehavior of mobile application due to backup and/or restore of phone and/or mobile application](#threat-misbehavior-of-mobile-application-backup-restore)
- [Information leakage of unprotected phone and/or mobile application](#threat-information-leakage-unprotected-phone)
- [Tampering of test retrieval and upload parameters](#threat-tampering-test-retrieval)
- [Tampering of diagnosis keys](#threat-tampering-diagnosis-keys)
- [Identity disclosure through metadata correlation](#threat-identity-disclosure-meta-data-correlation)
- Non-availability of app functionality
- Related threats
- [Insecure programming](#threat-insecure-programming)
- [Using components with known vulnerabilities](#threat-using-components-with-known-vulnerabilities)
- [PostgreSQL SQL injection](#threat-postgresql-sql-injection)
- [Code injection flaws](#threat-code-injection-flaws)
- [Transaction hijacking](#threat-transaction-hijacking)
- [Security misconfiguration](#threat-security-misconfiguration)
- [Denial-of-service attack against endpoints exposed to the internet](#threat-dos-against-internet-endpoints)
- [Denial-of-service against phone and/or mobile application for backend communication](#threat-dos-against-phone)
- [Mobile application acting as distributed denial-of-service device](#threat-mobile-application-as-ddos-device)
- [Tampering of upload authorization](#threat-tampering-of-upload-authorization)
- [Brute forcing of teleTANs](#threat-brute-forcing-of-teletans)
- [Tampering of test retrieval and upload parameters](#threat-tampering-test-retrieval)
- [Tampering of diagnosis keys](#threat-tampering-diagnosis-keys)
- <a name="risk-incorrect-notification-status">Incorrect notification status</a>
- Related threats
- [Insecure programming](#threat-insecure-programming)
- [Using components with known vulnerabilities](#threat-using-components-with-known-vulnerabilities)
- [PostgreSQL SQL injection](#threat-postgresql-sql-injection)
- [Code injection flaws](#threat-code-injection-flaws)
- [Transaction hijacking](#threat-transaction-hijacking)
- [Security misconfiguration](#threat-security-misconfiguration)
- [Missing cross-country interoperability of mobile application](#threat-missing-cross-country-interoperability)
- [Malicious phone and/or mobile application usage](#threat-malicious-phone-application-usage)
- [Misusage of phone and/or mobile application by user](#threat-misusage-of-phone-application)
- [Misbehavior of mobile application due to backup and/or restore of phone and/or mobile application](#threat-misbehavior-of-mobile-application-backup-restore)
- [Tampering of upload authorization](#threat-tampering-of-upload-authorization)
- [Brute forcing of teleTANs](#threat-brute-forcing-of-teletans)
- [Tampering of test retrieval and upload parameters](#threat-tampering-test-retrieval)
- [Tampering of diagnosis keys](#threat-tampering-diagnosis-keys)
- [False notifications](#threat-false-notifications)
- <a name="risk-identification-of-infected-person">Identification of infected persons and/or persons under test</a>
- Related threats
- [Insecure design](#threat-insecure-design)
- [Insecure programming](#threat-insecure-programming)
- [PostgreSQL SQL injection](#threat-postgresql-sql-injection)
- [Code injection flaws](#threat-code-injection-flaws)
- [Security misconfiguration](#threat-security-misconfiguration)
- [Wrong choice of technology](#threat-wrong-choice-of-technology)
- [Spoofing of mobile application](#threat-spoofing-of-mobile-application)
- [Misbehavior of mobile application due to backup and/or restore of phone and/or mobile application](#threat-misbehavior-of-mobile-application-backup-restore)
- [Information leakage of unprotected phone and/or mobile application](#threat-information-leakage-unprotected-phone)
- [Tampering of test retrieval and upload parameters](#threat-tampering-test-retrieval)
- [Tampering of diagnosis keys](#threat-tampering-diagnosis-keys)
- [Identity disclosure through metadata correlation](#threat-identity-disclosure-meta-data-correlation)
- <a name="risk-location-disclosure-of-infected-persons">Disclosure of the location of infected persons</a>
- Related threats
- [Insecure design](#threat-insecure-design)
- [Insecure programming](#threat-insecure-programming)
- [Security misconfiguration](#threat-security-misconfiguration)
- [Wrong choice of technology](#threat-wrong-choice-of-technology)
- [Identity disclosure through metadata correlation](#threat-identity-disclosure-meta-data-correlation)
- <a name="risk-social-network-disclosure">Social network disclosure</a>
- Related threats
- [Insecure design](#threat-insecure-design)
- <a name="risk-disclosure-of-notification-status">Disclosure of notification status</a>
- Related threats
- [Insecure programming](#threat-insecure-programming)
- [Using components with known vulnerabilities](#threat-using-components-with-known-vulnerabilities)
- [PostgreSQL SQL injection](#threat-postgresql-sql-injection)
- [Code injection flaws](#threat-code-injection-flaws)
- [Transaction hijacking](#threat-transaction-hijacking)
- [Security misconfiguration](#threat-security-misconfiguration)
- [Wrong choice of technology](#threat-wrong-choice-of-technology)
- [Spoofing of mobile application](#threat-spoofing-of-mobile-application)
- [Misbehavior of mobile application due to backup and/or restore of phone and/or mobile application](#threat-misbehavior-of-mobile-application-backup-restore)
- [Information leakage of unprotected phone and/or mobile application](#threat-information-leakage-unprotected-phone)
- [Tampering of test retrieval and upload parameters](#threat-tampering-test-retrieval)
- [Tampering of diagnosis keys](#threat-tampering-diagnosis-keys)
- [Identity disclosure through metadata correlation](#threat-identity-disclosure-meta-data-correlation)
- <a name="risk-disclosure-of-personal-data">Disclosure of personal data</a>
- Related threats
- [Insecure programming](#threat-insecure-programming)
- [Using components with known vulnerabilities](#threat-using-components-with-known-vulnerabilities)
- [PostgreSQL SQL injection](#threat-postgresql-sql-injection)
- [Code injection flaws](#threat-code-injection-flaws)
- [Transaction hijacking](#threat-transaction-hijacking)
- [Security misconfiguration](#threat-security-misconfiguration)
- [Wrong choice of technology](#threat-wrong-choice-of-technology)
- [Spoofing of mobile application](#threat-spoofing-of-mobile-application)
- [Misbehavior of mobile application due to backup and/or restore of phone and/or mobile application](#threat-misbehavior-of-mobile-application-backup-restore)
- [Information leakage of unprotected phone and/or mobile application](#threat-information-leakage-unprotected-phone)
- [Tampering of test retrieval and upload parameters](#threat-tampering-test-retrieval)
- [Tampering of diagnosis keys](#threat-tampering-diagnosis-keys)
- [Identity disclosure through metadata correlation](#threat-identity-disclosure-meta-data-correlation)
- Non-availability of app functionality
- Related threats
- [Insecure programming](#threat-insecure-programming)
- [Using components with known vulnerabilities](#threat-using-components-with-known-vulnerabilities)
- [PostgreSQL SQL injection](#threat-postgresql-sql-injection)
- [Code injection flaws](#threat-code-injection-flaws)
- [Transaction hijacking](#threat-transaction-hijacking)
- [Security misconfiguration](#threat-security-misconfiguration)
- [Denial-of-service attack against endpoints exposed to the internet](#threat-dos-against-internet-endpoints)
- [Denial-of-service against phone and/or mobile application for backend communication](#threat-dos-against-phone)
- [Mobile application acting as distributed denial-of-service device](#threat-mobile-application-as-ddos-device)
- [Tampering of upload authorization](#threat-tampering-of-upload-authorization)
- [Brute forcing of teleTANs](#threat-brute-forcing-of-teletans)
- [Tampering of test retrieval and upload parameters](#threat-tampering-test-retrieval)
- [Tampering of diagnosis keys](#threat-tampering-diagnosis-keys)
- <a name="risk-incorrect-notification-status">Incorrect notification status</a>
- Related threats
- [Insecure programming](#threat-insecure-programming)
- [Using components with known vulnerabilities](#threat-using-components-with-known-vulnerabilities)
- [PostgreSQL SQL injection](#threat-postgresql-sql-injection)
- [Code injection flaws](#threat-code-injection-flaws)
- [Transaction hijacking](#threat-transaction-hijacking)
- [Security misconfiguration](#threat-security-misconfiguration)
- [Missing cross-country interoperability of mobile application](#threat-missing-cross-country-interoperability)
- [Malicious phone and/or mobile application usage](#threat-malicious-phone-application-usage)
- [Misusage of phone and/or mobile application by user](#threat-misusage-of-phone-application)
- [Misbehavior of mobile application due to backup and/or restore of phone and/or mobile application](#threat-misbehavior-of-mobile-application-backup-restore)
- [Tampering of upload authorization](#threat-tampering-of-upload-authorization)
- [Brute forcing of teleTANs](#threat-brute-forcing-of-teletans)
- [Tampering of test retrieval and upload parameters](#threat-tampering-test-retrieval)
- [Tampering of diagnosis keys](#threat-tampering-diagnosis-keys)
- [False notifications](#threat-false-notifications)
### Non-Technical Risks
- <a name="risk-no-alert-on-contact-with-international-users">No alert on contact with international infected users</a>
- <a name="risk-no-alert-on-contact-with-international-users">No alert on contact with international infected users</a>
### Threats and Proposed Controls
#### Use-Case-Independent Threats
- <a name="threat-insecure-design">Insecure design</a>
- Proposed controls
- Use of decentralized architecture based on Google, Apple and [DP-3T](https://github.com/DP-3T/) approach
- <a name="threat-insecure-programming">Insecure programming</a>
- Proposed controls
- Static application security testing
- Dynamic application security testing
- Penetration testing
- <a name="threat-using-components-with-known-vulnerabilities">Using components with known vulnerabilities</a>
- Proposed controls
- Open-source software security testing
- Regular open source software security
- Usage of GitHub security alerts
- <a name="threat-postgresql-sql-injection">PostgreSQL SQL injection</a>
- Proposed controls
- Static application security testing
- Dynamic application security testing
- Penetration testing
- Input validation
- <a name="threat-code-injection-flaws">Code injection flaws</a>
- Proposed controls
- Static application security testing
- Dynamic application security testing
- Penetration testing
- Input validation
- <a name="threat-transaction-hijacking">Transaction hijacking</a>
- Proposed controls
- TLS certificate pinning
- TLS certificate validation
- <a name="threat-security-misconfiguration">Security misconfiguration</a>
- Proposed controls
- Security concept
- Infrastructure as code
- Configuration change management
- Automated configuration checks
- <a name="threat-dos-against-internet-endpoints">Denial of service attack against endpoints exposed to the internet</a>
- Proposed controls
- Distributed denial-of-service countermeasures
- Use of mutual TLS v1.3 for server to server communication
- <a name="threat-insecure-design">Insecure design</a>
- Proposed controls
- Use of decentralized architecture based on Google, Apple and [DP-3T](https://github.com/DP-3T/) approach
- <a name="threat-insecure-programming">Insecure programming</a>
- Proposed controls
- Static application security testing
- Dynamic application security testing
- Penetration testing
- <a name="threat-using-components-with-known-vulnerabilities">Using components with known vulnerabilities</a>
- Proposed controls
- Open-source software security testing
- Regular open source software security
- Usage of GitHub security alerts
- <a name="threat-postgresql-sql-injection">PostgreSQL SQL injection</a>
- Proposed controls
- Static application security testing
- Dynamic application security testing
- Penetration testing
- Input validation
- <a name="threat-code-injection-flaws">Code injection flaws</a>
- Proposed controls
- Static application security testing
- Dynamic application security testing
- Penetration testing
- Input validation
- <a name="threat-transaction-hijacking">Transaction hijacking</a>
- Proposed controls
- TLS certificate pinning
- TLS certificate validation
- <a name="threat-security-misconfiguration">Security misconfiguration</a>
- Proposed controls
- Security concept
- Infrastructure as code
- Configuration change management
- Automated configuration checks
- <a name="threat-dos-against-internet-endpoints">Denial of service attack against endpoints exposed to the internet</a>
- Proposed controls
- Distributed denial-of-service countermeasures
- Use of mutual TLS v1.3 for server to server communication
#### Tracing Only
- <a name="threat-wrong-choice-of-technology">Wrong choice of technology</a>
- Proposed controls
- App-specific notification mechanism
- Minimal logging
- Minimal mobile application permissions
- <a name="threat-spoofing-of-mobile-application">Spoofing of mobile application</a>
- Proposed controls
- Use of iOS and Android signing and store infrastructure
- <a name="threat-missing-cross-country-interoperability">Missing cross-country interoperability of mobile application</a>
- Proposed controls
- Roaming alert
- <a name="threat-malicious-phone-application-usage">Malicious phone and/or mobile application usage</a>
- Proposed controls
- Inform user if functionality seems impaired
- <a name="threat-misusage-of-phone-application">Misusage of phone and/or mobile application by user</a>
- <a name="threat-misbehavior-of-mobile-application-backup-restore">Misbehavior of mobile application due to backup and/or restore of phone and/or mobile application</a>
- <a name="threat-information-leakage-unprotected-phone">Information leakage of unprotected phone and/or mobile application</a>
- Proposed controls
- Additional password protection of the mobile application
- <a name="threat-dos-against-phone">Denial-of-service against phone and/or mobile application for backend communication</a>
- Proposed controls
- Input validation
- TLS certificate pinning
- TLS certificate validation
- <a name="threat-mobile-application-as-ddos-device">Mobile application acting as distributed denial-of-service device</a>
- Proposed controls
- Hardcoded server endpoints
- Digital signature
- Digital signature verification
- Timestamping of digital signature
- <a name="threat-wrong-choice-of-technology">Wrong choice of technology</a>
- Proposed controls
- App-specific notification mechanism
- Minimal logging
- Minimal mobile application permissions
- <a name="threat-spoofing-of-mobile-application">Spoofing of mobile application</a>
- Proposed controls
- Use of iOS and Android signing and store infrastructure
- <a name="threat-missing-cross-country-interoperability">Missing cross-country interoperability of mobile application</a>
- Proposed controls
- Roaming alert
- <a name="threat-malicious-phone-application-usage">Malicious phone and/or mobile application usage</a>
- Proposed controls
- Inform user if functionality seems impaired
- <a name="threat-misusage-of-phone-application">Misusage of phone and/or mobile application by user</a>
- <a name="threat-misbehavior-of-mobile-application-backup-restore">Misbehavior of mobile application due to backup and/or restore of phone and/or mobile application</a>
- <a name="threat-information-leakage-unprotected-phone">Information leakage of unprotected phone and/or mobile application</a>
- Proposed controls
- Additional password protection of the mobile application
- <a name="threat-dos-against-phone">Denial-of-service against phone and/or mobile application for backend communication</a>
- Proposed controls
- Input validation
- TLS certificate pinning
- TLS certificate validation
- <a name="threat-mobile-application-as-ddos-device">Mobile application acting as distributed denial-of-service device</a>
- Proposed controls
- Hardcoded server endpoints
- Digital signature
- Digital signature verification
- Timestamping of digital signature
- <a name="threat-false-notifications">False notifications</a>
- Proposed controls
- No usage of operating system intents
- Proposed controls
- No usage of operating system intents
#### Submission of Exposure Keys
- <a name="threat-tampering-of-upload-authorization">Tampering of upload authorization</a>
- Proposed controls
- Enforce QR code one-time-usage
- TAN as one-time token for upload of diagnosis keys
- Flexibility to adjust teleTAN complexity to situational needs
- <a name="threat-brute-forcing-of-teletans">Brute forcing of teleTANs</a>
- Proposed controls
- Identify clients with features such as SafetyNet attestation or similar
- Increase teleTAN complexity
- Decrease teleTAN lifetime
- Security event monitoring incl. feature toggle
- Flexibility to adjust teleTAN complexity to situational needs
- <a name="threat-tampering-test-retrieval">Tampering of test retrieval and upload parameters</a>
- Proposed controls
- Input validation
- Digital signature
- Digital signature verification
- Use of mutual TLS v1.3
- Use of TLS v1.2/1.3 server authentication only
- Chain diagnosis key delta-packages
- Secure database connections
- Secure Exposure Notification Framework access
- Identify clients with features such as SafetyNet attestation or similar
- <a name="threat-tampering-diagnosis-keys">Tampering of diagnosis keys</a>
- Proposed controls
- Input validation
- Digital signature
- Digital signature verification
- Use of mutual TLS v1.3
- Use of TLS v1.2/1.3 server authentication only
- Chain diagnosis key delta-packages
- Secure database connections
- Secure Exposure Notification Framework access
- Identify clients with features such as SafetyNet attestation or similar
- <a name="threat-identity-disclosure-meta-data-correlation">Identity disclosure through metadata correlation</a>
- Proposed controls
- Separation of metadata and payload
- No TAN storage in verification server back end
- Dummy packages for diagnosis key upload
- Use mix network for anonymity during diagnosis keys upload
- <a name="threat-tampering-of-upload-authorization">Tampering of upload authorization</a>
- Proposed controls
- Enforce QR code one-time-usage
- TAN as one-time token for upload of diagnosis keys
- Flexibility to adjust teleTAN complexity to situational needs
- <a name="threat-brute-forcing-of-teletans">Brute forcing of teleTANs</a>
- Proposed controls
- Identify clients with features such as SafetyNet attestation or similar
- Increase teleTAN complexity
- Decrease teleTAN lifetime
- Security event monitoring incl. feature toggle
- Flexibility to adjust teleTAN complexity to situational needs
- <a name="threat-tampering-test-retrieval">Tampering of test retrieval and upload parameters</a>
- Proposed controls
- Input validation
- Digital signature
- Digital signature verification
- Use of mutual TLS v1.3
- Use of TLS v1.2/1.3 server authentication only
- Chain diagnosis key delta-packages
- Secure database connections
- Secure Exposure Notification Framework access
- Identify clients with features such as SafetyNet attestation or similar
- <a name="threat-tampering-diagnosis-keys">Tampering of diagnosis keys</a>
- Proposed controls
- Input validation
- Digital signature
- Digital signature verification
- Use of mutual TLS v1.3
- Use of TLS v1.2/1.3 server authentication only
- Chain diagnosis key delta-packages
- Secure database connections
- Secure Exposure Notification Framework access
- Identify clients with features such as SafetyNet attestation or similar
- <a name="threat-identity-disclosure-meta-data-correlation">Identity disclosure through metadata correlation</a>
- Proposed controls
- Separation of metadata and payload
- No TAN storage in verification server back end
- Dummy packages for diagnosis key upload
- Use mix network for anonymity during diagnosis keys upload
## Security Planning
Based on the results of the risk assessment, the teams derive the security and also privacy requirements applicable to the solution to mitigate the risks. For each applicable requirement, the team defines a suitable security control, which usually consists of a security activity, a verification measurement, and the time to apply it. The security plan encompasses all security controls that the team decides to complete.
## Security Testing
The teams performs further verifications of the implemented security controls by security testing, following the security test plan the teams created.
The teams performs further verifications of the implemented security controls by security testing, following the security test plan the teams created.
### Static Application Security Testing (SAST)
Whenever possible, the developers integrate these tools directly into their tool environment and use them daily. If this is not possible, the teams set up daily or weekly runs of the static-code analyzers and feeds the results back to the developers for immediate audit and analysis during the development.
- [cwa-app-android](https://github.com/corona-warn-app/cwa-app-android)
- Checkmarx Static Application Security Testing (CxSAST)
- [cwa-app-ios](https://github.com/corona-warn-app/cwa-app-ios)
- Checkmarx Static Application Security Testing (CxSAST)
- [cwa-server](https://github.com/corona-warn-app/cwa-server)
- Micro Focus Fortify Static Code Analyzer
- [cwa-testresult-server](https://github.com/corona-warn-app/cwa-testresult-server)
- Checkmarx Static Application Security Testing (CxSAST), SonarQube, Micro Focus Fortify Static Code Analyzer
- [cwa-verification-iam](https://github.com/corona-warn-app/cwa-verification-iam)
- Checkmarx Static Application Security Testing (CxSAST), SonarQube, Micro Focus Fortify Static Code Analyzer
- [cwa-verification-portal](https://github.com/corona-warn-app/cwa-verification-portal)
- Checkmarx Static Application Security Testing (CxSAST), SonarQube, Micro Focus Fortify Static Code Analyzer
- [cwa-verification-server](https://github.com/corona-warn-app/cwa-verification-server)
- Checkmarx Static Application Security Testing (CxSAST), SonarQube, Micro Focus Fortify Static Code Analyzer
### Open-Source Known Vulnerability Scans
Besides to SAST and whenever applicable, the developers frequently scan their used open-source components for known vulnerabilities and to mitigate findings by patching to a secure version.
Whenever possible, the developers integrate these tools directly into their tool environment and use them daily. If this is not possible, the teams set up daily or weekly runs of the static-code analyzers and feeds the results back to the developers for immediate audit and analysis during the development.
- [cwa-app-android](https://github.com/corona-warn-app/cwa-app-android)
- BlackDuck
- Checkmarx Static Application Security Testing (CxSAST)
- [cwa-app-ios](https://github.com/corona-warn-app/cwa-app-ios)
- BlackDuck
- Checkmarx Static Application Security Testing (CxSAST)
- [cwa-server](https://github.com/corona-warn-app/cwa-server)
- WhiteSource
- Synopsys Protecode
- Eclipse Steady (former SAP Vulas)
- Micro Focus Fortify Static Code Analyzer
- [cwa-testresult-server](https://github.com/corona-warn-app/cwa-testresult-server)
- OWASP Dependency Checker
- Checkmarx Static Application Security Testing (CxSAST), SonarQube, Micro Focus Fortify Static Code Analyzer
- [cwa-verification-iam](https://github.com/corona-warn-app/cwa-verification-iam)
- OWASP Dependency Checker
- Checkmarx Static Application Security Testing (CxSAST), SonarQube, Micro Focus Fortify Static Code Analyzer
- [cwa-verification-portal](https://github.com/corona-warn-app/cwa-verification-portal)
- OWASP Dependency Checker
- Checkmarx Static Application Security Testing (CxSAST), SonarQube, Micro Focus Fortify Static Code Analyzer
- [cwa-verification-server](https://github.com/corona-warn-app/cwa-verification-server)
- OWASP Dependency Checker
- Checkmarx Static Application Security Testing (CxSAST), SonarQube, Micro Focus Fortify Static Code Analyzer
### Open-Source Known Vulnerability Scans
Besides to SAST and whenever applicable, the developers frequently scan their used open-source components for known vulnerabilities and to mitigate findings by patching to a secure version.
- [cwa-app-android](https://github.com/corona-warn-app/cwa-app-android)
- BlackDuck
- [cwa-app-ios](https://github.com/corona-warn-app/cwa-app-ios)
- BlackDuck
- [cwa-server](https://github.com/corona-warn-app/cwa-server)
- WhiteSource
- Synopsys Protecode
- Eclipse Steady (former SAP Vulas)
- [cwa-testresult-server](https://github.com/corona-warn-app/cwa-testresult-server)
- OWASP Dependency Checker
- [cwa-verification-iam](https://github.com/corona-warn-app/cwa-verification-iam)
- OWASP Dependency Checker
- [cwa-verification-portal](https://github.com/corona-warn-app/cwa-verification-portal)
- OWASP Dependency Checker
- [cwa-verification-server](https://github.com/corona-warn-app/cwa-verification-server)
- OWASP Dependency Checker
## Secure Operations
# Secure Operations
## Overview
Deutsche Telekom AG deploys a secure operations framework to maintain security during the lifecycle of all services. Operations of the corona warn app is covered by this in-house standard. Its top-level structure is divided into 18 capabilities that cover the different fields of action:
- [Asset and Configuration Management of Hardware and Software](#asset-and-configuration-management-of-hardware-and-software)
- [Vulnerability Management and Assessment](#vulnerability-management-and-assessment)
- [Incident and Problem Management](#incident-and-problem-management)
@ -282,51 +306,72 @@ Deutsche Telekom AG deploys a secure operations framework to maintain security d
The following chapters contain a brief introduction to each capability.
## Capability Descriptions
### Asset and Configuration Management of Hardware and Software
#### Subject
- Asset Management is a process for developing, operating, maintaining, upgrading, and disposing of hardware and software. An asset in terms of secure operations is any technical resource (configuration item). Configuration management is a process for hardware and software to establish and maintain performance consistency, ensure functional and physical attributes with its requirements and keep design and operational information throughout the lifecycle.
- The Asset Register provides an overview of all relevant assets of an organization and ensures that all relevant business information is identified, defined and organized to facilitate its use and access. Furthermore, the register avoids duplicate information.
- The Asset Register provides an overview of all relevant assets of an organization and ensures that all relevant business information is identified, defined and organized to facilitate its use and access. Furthermore, the register avoids duplicate information.
- Secure Operations Center (SOC) teams and Computer Emergency Response Teams (CERT) require access to this inventory.
#### Objective
- Gain overview of all relevant assets, responsibilities and ownership.
- Use the asset register as a base for vulnerability management, incident and problem management, change management, risk management, logging, monitoring, event management and alarming. Enable secure operations to act.
- Remediate vulnerabilities to reduce the likelihood of exploitation through a threat agent.
### Vulnerability Management and Assessment
#### Subject
- Vulnerability Management & Assessment collects, detects, categorizes, prioritizes and communicates vulnerabilities and remediation information. It enforces and tracks mitigation, e.g. by introducing patch management for security vulnerabilities.
#### Objective
- Provide transparency of generic vulnerabilities.
- Provide transparency of environment-specific vulnerabilities for each asset.
- Provide transparency of environment-specific vulnerabilities for each asset.
- Remediate vulnerabilities to reduce the likelihood of exploitation through a threat agent.
### Incident and Problem Management
#### Subject
- Incident Management is an instrument for the structured treatment of security incidents by collaboration between security services and business operations. It includes all measures, responsibilities and principles for dealing with incidents of the operating processes.
- Management is supported by establishing standardized customer business impact categories.
#### Objective
- Minimize the impact of security incidents and problems in order to avert potential damage to the company, employees and customers - sometimes with a handover to problem management.
- Enable early identification and measurement of incidents and, if needed, timely reporting to regulatory authorities (e.g. Bundesnetzagentur, Bundesbeauftragter für den Datenschutz und die Informationsfreiheit).
- Enable standardized incident reporting and monitoring which allows management escalation to solve security incidents accordingly.
- Enable standardized incident reporting and monitoring which allows management escalation to solve security incidents accordingly.
- Manage security incidents in a standardized way.
- Generate further input for other Information Security Management System (ISMS) processes (e.g. awareness campaigns).
### Change Management
#### Subject
- The change management process has the primary goal of enabling beneficial changes while avoiding negative impact on IT services.
- Change management ensures that all changes have been approved before the go-live and monitors if the approved change is aligned with the security requirements.
#### Objective
- Avoid unsecure and unauthorized changes.
- Avoid unsecure and unauthorized changes.
- Reduce security risk during/due to operational changes. This applies if security-relevant aspects of the change have not been considered before.
- Remediate vulnerabilities through change management to reduce the chance of exploitation through a threat agent.
### Security Services
#### Subject
- Security Services include a single point of contact for internal/external incident reporters who perform a first evaluation of and reaction to security incidents. In case of critical incidents, additional on-demand incident response/hunting capabilities are available to perform a deep-dive analysis and resolution.
- Last-level security responsibility as part of security services handles and takes responsibility for security incidents where dispatch is unclear.
#### Objective
- Evaluate security incidents and minimize the response time including certain event messages and alarming as well as incidents triggered by user reports.
- Evaluate security incidents and minimize the response time including certain event messages and alarming as well as incidents triggered by user reports.
- Handle reported security incidents.
- Minimize the impact of security incidents.
- Provide deep-dive analyses of critical incidents (e.g. advanced persistent threats (APT)).
@ -334,59 +379,79 @@ The following chapters contain a brief introduction to each capability.
- Support certificates.
### Security Testing
#### Subject
- Security testing checks whether the security measures and procedures are still in line with the risk assessments from the company's point of view; check whether the corresponding measures and procedures are regularly tested and kept up to date. Infiltrate through existing perimeters (e.g. technical, physical, access control).
- Security testing assesses if system and configuration settings are compliant to the security requirements and if the implementation contains vulnerabilities.
- Security testing assesses if system and configuration settings are compliant to the security requirements and if the implementation contains vulnerabilities.
- It verifies of company and industry requirements e.g. through audits
- During the lifecycle of a system or application, different types of testing are required. Findings are addressed in related ITIL processes.
#### Objective
- Identify, remediate or accept
- known (e.g. existing Common Vulnerabilities and Exposures(CVE) score) vulnerabilities,
- undiscovered (e.g. SQL injection) vulnerabilities and
- architectural/processing vulnerabilities.
- Identify, remediate or accept
- known (e.g. existing Common Vulnerabilities and Exposures(CVE) score) vulnerabilities,
- undiscovered (e.g. SQL injection) vulnerabilities and
- architectural/processing vulnerabilities.
- Ensure that security and business requirements are fulfilled.
### Threat Intelligence
#### Subject
- Threat Intelligence collects, assesses and shares information on technical and non-technical threats.
- Threat Intelligence collects, assesses and shares information on technical and non-technical threats.
- This information is enriched/extended by collaboration with external associations and non-profit organizations (e.g. FIRST, DAX 30, CSSA, ISF, etc.). It is primarily used for updating the technical security defense and monitoring infrastructure.
#### Objective
- Provide transparency and situational awareness for technical and non-technical cyber security threats.
### Technical Cyber Resilience
#### Subject
- Technical Cyber Resilience solutions defend against specific threats. They are planned, built and operated based on threat exposure. This includes reaction processes for alerts.
- Examples: distributed denial-of-service (DDoS) attack protection, intrusion detection systems (IDS) / intrusion prevention systems (IPS), APT detection, antivirus, web application firewalls, proxies, spam filter.
- Technical Cyber Resilience solutions defend against specific threats. They are planned, built and operated based on threat exposure. This includes reaction processes for alerts.
- Examples: distributed denial-of-service (DDoS) attack protection, intrusion detection systems (IDS) / intrusion prevention systems (IPS), APT detection, antivirus, web application firewalls, proxies, spam filter.
#### Objective
- Minimize impact of specific threats and attacks that consist of:
- Dynamic polymorphic malware
- Multi-stage malware
- (Multi-vector) Distributed denial-of-service attack
- Coordinated persistent attack
- Network anomalies
- Minimize impact of specific threats and attacks that consist of:
- Dynamic polymorphic malware
- Multi-stage malware
- (Multi-vector) Distributed denial-of-service attack
- Coordinated persistent attack
- Network anomalies
- Prevent unauthorized access and modification.
- Provide secure architectures (e.g. layered security).
- Support service continuity and disaster recovery.
### Logging and Monitoring, Event Management and Alarming
#### Subject
- Logging and Monitoring, Event Management and Alarming covers the steps from a single log entry on a device up to creating a resulting security incident. It contains activities like log and alarm definition, log transport and security information and event management system (SIEM) operation including event correlation and analytics.
- Messages and log files of different systems will be collected and evaluated. Suspicious events or dangerous trends can be detected (in real time).
#### Objective
- Detect attackers on internal networks due to behavior that triggers use cases.
- Support investigations in the context of intrusions, breaches, regulatory or policy violations by focusing on highly technical evidence acquisition and evidence analysis.
- Provide input to and support an incident response process.
- Support investigations in the context of intrusions, breaches, regulatory or policy violations by focusing on highly technical evidence acquisition and evidence analysis.
- Provide input to and support an incident response process.
- Provide input to and support legal/disciplinary actions by giving a plausible reconstruction of attacker or user activity.
- Troubleshoot operational security problems.
- Provide advice on needed and common logfiles.
### Partner Management
#### Subject
- Partner Management supports buyers to avoid or reduce risks associated with third-party products and services.
- Partner Management supports buyers to avoid or reduce risks associated with third-party products and services.
- Security requirements must be also fulfilled by external service providers / partners. Therefore, this must be clearly stated in the contracts (e.g. security annex, data processing agreement (DPA), audit rights). The requirements relate among other things to the identification of risks, contract management, control of service during execution and withdrawal of authorizations from external parties upon termination of service provision.
- The partner must ensure functioning hiring and leaving processes for their employees. If needed, services must be provided by security-checked employees.
- The partner must deliver security-related services such as vulnerability information, patch and release delivery or incident collaboration and support.
- The partner must deliver security-related services such as vulnerability information, patch and release delivery or incident collaboration and support.
#### Objective
- Guarantee a consistently high level of security even for services performed by external partners.
- Avoid security gaps in contracts.
- Guarantee collaboration and support by partners in case of security incident (e.g. to update or recover a system in the specified time).
@ -395,79 +460,111 @@ The following chapters contain a brief introduction to each capability.
- Cooperate with selected/certified suppliers (blacklist/whitelist).
### Secure Development
#### Subject
- Secure development (security by design and default) includes considering security aspects in the development stage of systems and platforms adequately. Default settings (e.g. required privileges) should be as low as possible and rarely used features should be deactivated by default. This is a prerequisite for secure operations.
- Some security problems detected during the operations phase can be fixed with a workaround. This should be reported back to development as part of a systematic feedback from operations to development and vice versa.
- Some security problems detected during the operations phase can be fixed with a workaround. This should be reported back to development as part of a systematic feedback from operations to development and vice versa.
#### Objective
- Operate/use only secure systems/platforms.
- Enhance secure development by providing feedback from secure operations.
### Backup and Restore
#### Subject
- Backup and restore in terms of secure operations means to create backups and restore from backups in a secure way in case of disaster recovery.
#### Objective
- Ensure integrity, availability and confidentiality of backups.
- Ensure defined retention times.
### Risk Management
#### Subject
- Risk Management in terms of secure operations means that security risks are transferred and treated according to the risk management process.
#### Objective
- Identify and assess risks and hand them over to the according risk management process.
- Treat risks with a structured approach (e.g. defined ownership, risk lifecycle, report, review tracking).
- Treat risks with a structured approach (e.g. defined ownership, risk lifecycle, report, review tracking).
- Provide resources for enhanced risk mitigation.
### Lifecycle Management
#### Subject
- Lifecycle Management in terms of secure operations focuses on technical rule sets, digital certificates and software in general.
- Lifecycle Management ensures
- maintenance of technical rule sets,
- digital certificates being updated with end of life and
- deactivation of systems out of support of the partner.
- Lifecycle Management ensures
- maintenance of technical rule sets,
- digital certificates being updated with end of life and
- deactivation of systems out of support of the partner.
#### Objective
- Ensure up-to-dateness and traceability of technical security rule sets (e.g. firewall configuration).
- Ensure operation only of systems (Development/Test/Production) that are still actively supplied with security patches from the vendor.
- Ensure that digital certificates are always valid.
### Privileged Access Management
#### Subject
- Privileged access management in terms of secure operations focuses on control processes and the monitoring of accounts with elevated rights.
#### Objective
- Ensure that privileged access is only granted on a need-to-know basis.
- Ensure segregation of duties.
- Ensure detection, alarming and reaction regarding privileged access policy violations.
- Ensure trustworthy and complete authorization for employees and 3rd parties.
### Physical Security
#### Subject
- Physical Security considers the security of buildings/locations (e.g. data center) and the protection/maintenance of infrastructure and resources as well as access controls to prevent loss, damage, theft, compromise or service interruption of an organization's assets.
#### Objective
- Maintain confidentiality, integrity and availability from a physical access perspective.
### Security Training and Skill Assessment
#### Subject
- Security training and skill assessments
- inform about the specific company guidelines and processes for security. Participants receive information on which procedures to follow or which persons to inform when security-relevant events are detected.
- inform about specific threat scenarios which should be known by all employees.
- provide guidance for administrators in form of how-tos (e.g. log file extraction and transfer, etc.).
- inform about the specific company guidelines and processes for security. Participants receive information on which procedures to follow or which persons to inform when security-relevant events are detected.
- inform about specific threat scenarios which should be known by all employees.
- provide guidance for administrators in form of how-tos (e.g. log file extraction and transfer, etc.).
- Specific training for security/operation staff (e.g. incident response, IDS, etc.) must be available.
#### Objective
- Strengthen the overall safety awareness and minimize the risks to IT security caused by internal and external employees
- Strengthen the overall safety awareness and minimize the risks to IT security caused by internal and external employees
- Gain awareness to handle security threats.
- Improve staff’s abilities to perform secure operations.
### Customer and Authority Interaction
#### Subject
- Customer interaction in terms of secure operations means extending existing customer communication with security subjects and ensure the availability of a real-time communication channel in case of an incident.
- Customer interaction in terms of secure operations means extending existing customer communication with security subjects and ensure the availability of a real-time communication channel in case of an incident.
- Adequately and timely communication with authorities and stakeholders is required.
#### Objective
- Improve customer relationship/satisfaction.
- Foster trustful partnerships.
- Gain ideas for product improvements.
- Foster trustful partnerships.
- Gain ideas for product improvements.
- Provide standardized communication structure in case of incident.
- Support customers in identifying security gaps at an early stage and initiate appropriate measures.
- Ensure compliance with reporting obligations towards authorities. Examples:
- General data protection regulation (GDPR)
- Sarbanes-Oxley Act (SOX)
- Kritische Infrastrukturen (KRITIS)
- General data protection regulation (GDPR)
- Sarbanes-Oxley Act (SOX)
- Kritische Infrastrukturen (KRITIS)
- Ensure prompt action to media reports (e.g. fake news).

3626
package-lock.json generated Normal file
View File

File diff suppressed because it is too large Load Diff

32
package.json Normal file
View File

@ -0,0 +1,32 @@
{
"name": "docs",
"version": "1.0.0",
"description": "Corona-Warn-App: Documentation repository",
"main": "README.md",
"dependencies": {
"alex": "^8.1.1",
"markdown-link-check": "^3.8.1",
"markdown-spellcheck": "^1.3.1",
"markdownlint": "^0.20.4",
"markdownlint-cli": "^0.23.2",
"npm-run-all": "^4.1.5"
},
"devDependencies": {},
"scripts": {
"test": "run-s markdownlint checklinks format-spelling",
"spellcheck": "mdspell '**/*.md' --en-us -t -n -a --report '!**/node_modules/**/*.md' '!**/.github/**/*.md' '!**/translations/**/*.md'",
"markdownlint": "markdownlint '**/*.md' --ignore node_modules",
"checklinks": "find . -not -path \"*node_modules*\" -not -path \"*.github*\" -name \"*.md\" | xargs -n 1 markdown-link-check",
"detect-inconsiderate-language": "alex",
"format-spelling": "sort < .spelling | sort | uniq | tee .spelling.tmp > /dev/null && mv .spelling.tmp .spelling"
},
"repository": {
"type": "git",
"url": "git@github.com:corona-warn-app/cwa-documentation.git"
},
"keywords": [
"docs"
],
"author": "Johannes Amorosa",
"license": "Apache 2.0"
}

22
pruefsteine.md
View File

@ -22,19 +22,19 @@ Even if the central Corona-Warn-App server is compromised, this information cann
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:
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
* 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).
* [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.
The diagnosis keys are only stored centrally for the epidemiologically relevant period of 14 days and are removed automatically after that period.
## Anonymity
@ -50,9 +50,9 @@ Users only have to identify themselves when they obtain the permission to upload
## No Creation of Central Movement or Contact Profiles
Movement or contact data is not collected centrally.
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.
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.
@ -70,4 +70,4 @@ The Corona-Warn-App takes state of the art measures to make individual messages
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.
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.

175
scoping_document.md
View File

@ -1,4 +1,5 @@
# TABLE OF CONTENTS
1. [INTRODUCTION](#introduction)
2. [USER JOURNEY](#user-journey)
1. [Description of Usage Profiles (Stakeholders)](#description-of-usage-profiles-stakeholders)
@ -19,72 +20,147 @@
NOTE: This scoping document is also available [in German](translations/scoping_document.de.md).
HINWEIS: Dieses Scoping-Dokument ist ebenfalls [auf Deutsch](translations/scoping_document.de.md) verfügbar.
HINWEIS: Dieses Scoping-Dokument ist ebenfalls [auf Deutsch](translations/scoping_document.de.md)
verfügbar.
# INTRODUCTION
The aim of the Corona-Warn-App is to identify SARS-CoV-2 chains of infection as quickly as possible and to break them. It does this by rapidly and reliably notifying people that they have had contact with infected persons and therefore may have been exposed to the virus. These individuals can then self-isolate, to help stop the SARS-CoV-2 pandemic.
## INTRODUCTION
This document describes the functional requirements of the app’s design from a technical and process-based perspective. This version of the scope document describes the first release and an initial version of the app only.
The aim of the Corona-Warn-App is to identify SARS-CoV-2 chains of infection as
quickly as possible and to break them. It does this by rapidly and reliably
notifying people that they have had contact with infected persons and therefore
may have been exposed to the virus. These individuals can then self-isolate, to
help stop the SARS-CoV-2 pandemic.
The overall planning also foresees publishing other development documents, to solicit feedback from an early stage for potential incorporation in the project. The release architecture document and back-end alpha source code will be made available subsequently.
This document describes the functional requirements of the app’s design from a
technical and process-based perspective. This version of the scope document
describes the first release and an initial version of the app only.
The requirements have been defined and outlined according to a person-centric methodology. This means the entire process flow is designed from the perspective of the people who use the app and the other stakeholders involved in the process. The aim is to map the needs of all stakeholders in such a way that it promotes a high degree of acceptance and makes the respective functions intuitive to use.
The overall planning also foresees publishing other development documents, to
solicit feedback from an early stage for potential incorporation in the project.
The release architecture document and back-end alpha source code will be made
available subsequently.
The interaction points and user experience are mapped based on a user journey. The resulting requirements are assigned to “epics”, or descriptions of the requirements at a high level of abstraction. These epics describe the individual contact points and general functions throughout the process that are required for usage and acceptance of the app. In turn, the epics are used to derive the detailed requirements in the form of user stories (software requirements formulated in everyday language). Through this approach, the individual requirements are structured as they are incorporated in the development process.
The requirements have been defined and outlined according to a person-centric
methodology. This means the entire process flow is designed from the perspective
of the people who use the app and the other stakeholders involved in the
process. The aim is to map the needs of all stakeholders in such a way that it
promotes a high degree of acceptance and makes the respective functions
intuitive to use.
# USER JOURNEY
The interaction points and user experience are mapped based on a user journey.
The resulting requirements are assigned to “epics”, or descriptions of the
requirements at a high level of abstraction. These epics describe the
individual contact points and general functions throughout the process that are
required for usage and acceptance of the app. In turn, the epics are used to
derive the detailed requirements in the form of user stories (software
requirements formulated in everyday language). Through this approach, the
individual requirements are structured as they are incorporated in the
development process.
## Description of Usage Profiles (Stakeholders)
The following key usage profiles and stakeholders are integrated in the user journey, or overall process, and described in their roles:
## USER JOURNEY
### Description of Usage Profiles (Stakeholders)
The following key usage profiles and stakeholders are integrated in the user
journey, or overall process, and described in their roles:
#### App User
All persons who use the app: Are notified of potential exposure to infected persons, verify their own test results, and then warn all the people they have encountered – voluntarily and under a pseudonym.
All persons who use the app: Are notified of potential exposure to infected
persons, verify their own test results, and then warn all the people they have
encountered – voluntarily and under a pseudonym.
#### Hotlines
Provide support to persons who use the app by in answering questions about how to use the app, the technology, and data privacy. If asked, they provide information on proper conduct and where to get further information in case of contact or infection.
Help verify and release test results in the app for infected individuals and can recommend that they contact their health department.
Provide support to persons who use the app by in answering questions about how
to use the app, the technology, and data privacy. If asked, they provide
information on proper conduct and where to get further information in case of
contact or infection.
Help verify and release test results in the app for infected individuals and can
recommend that they contact their health department.
#### Robert Koch Institute (RKI)
Provides epidemiological information and recommendations for using the app (content). Determines the parameters used to measure the number of contacts (to the extent of the API’s technical capabilities).
## User Journey
App usage is divided into different phases, based on contact points and interactions between people that occur successively. In each phase, persons are assigned motivations or requirements that meet their expectations of the app and guide them intuitively through the process.
Provides epidemiological information and recommendations for using the app
(content). Determines the parameters used to measure the number of contacts
(to the extent of the API’s technical capabilities).
### User Journey
App usage is divided into different phases, based on contact points and
interactions between people that occur successively. In each phase, persons are
assigned motivations or requirements that meet their expectations of the app and
guide them intuitively through the process.
![Figure 1: User Journey](user_journey.png "User Journey")
#### *Idea* phase
In this phase, a person decides to get more information about the app. In this phase, persons may have different questions regarding usage of the app (application, data privacy, accessibility, and so on). It should be possible to have these questions answered before downloading the app (hotline, information on the websites of the RKI and Federal Ministry of Health (BMG), App Store/Google Play Store).
In this phase, a person decides to get more information about the app. In this
phase, persons may have different questions regarding usage of the app
(application, data privacy, accessibility, and so on). It should be possible to
have these questions answered before downloading the app (hotline, information
on the websites of the RKI and Federal Ministry of Health (BMG), App
Store/Google Play Store).
#### *Installation* phase
A person decides to download the app (App Store/Google Play Store) and, after the technical installation process, is given an introduction to the app the first time it is opened. In this introductory phase, app users are given an overview of the functionality, terms of use, and privacy provisions; are asked for the necessary consent; and guided through the notification and other settings.
A person decides to download the app (App Store/Google Play Store) and, after
the technical installation process, is given an introduction to the app the
first time it is opened. In this introductory phase, app users are given an
overview of the functionality, terms of use, and privacy provisions; are asked
for the necessary consent; and guided through the notification and other
settings.
#### *Usage* phase
The usage phase is subdivided into four further areas, in which people who use the app have different needs.
The usage phase is subdivided into four further areas, in which people who use
the app have different needs.
1. **Background**
In idle mode, the application runs in the background on the smartphone and saves the pseudo IDs of other nearby app users, automatically and encrypted. At regular intervals, the app pulls from the server a list of pseudo IDs of the persons who have voluntarily reported that they are infected. The app compares their pseudo IDs with those stored on the smartphone to determine whether there has been any exposure.
In idle mode, the application runs in the background on the smartphone and
saves the pseudo IDs of other nearby app users, automatically and encrypted.
At regular intervals, the app pulls from the server a list of pseudo IDs of
the persons who have voluntarily reported that they are infected. The app
compares their pseudo IDs with those stored on the smartphone to determine
whether there has been any exposure.
2. **Exposure**
If exposure to infected persons is determined, app user receives a notification and recommendations on what to do. For instance, that they should contact a medical professional or their responsible health department, and whether they should self-isolate.
If exposure to infected persons is determined, app user receives a
notification and recommendations on what to do. For instance, that they
should contact a medical professional or their responsible health department,
and whether they should self-isolate.
3. **Testing**
If an app user is tested for a SARS-CoV-2 infection, they can start the digital test information process in the app, which notifies them of their test result.
If an app user is tested for a SARS-CoV-2 infection, they can start the
digital test information process in the app, which notifies them of their
test result.
4. **Infection case**
If an app user tests positive for SARS-COV-2 infection, they can voluntarily publish the pseudonymized warn IDs saved in their app. That way, other app users can use their smartphones to find out whether they have been exposed to the infected user.
If an app user tests positive for SARS-CoV-2 infection, they can voluntarily
publish the pseudonymized warn IDs saved in their app. That way, other app
users can use their smartphones to find out whether they have been exposed
to the infected user.
#### *Uninstallation* phase
A person can uninstall the app at any time, completely deleting all the data stored in it.
# FUNCTIONAL DESCRIPTION
A person can uninstall the app at any time, completely deleting all the data
stored in it.
## Overview of Epics
The app functions are divided into user process phases (with direct ties to the user journey) and general support processes. An overview of the epics is depicted below:
## FUNCTIONAL DESCRIPTION
### Overview of Epics
The app functions are divided into user process phases (with direct ties to
the user journey) and general support processes. An overview of the epics is
depicted below:
#### Process Phases of Use
<!-- markdownlint-disable -->
| # | Epic | Description |
|---:|--------|--------------|
| 1 | Onboarding and Installation | All processes that take place the first time the app is used (such as consent, data privacy, language selection) |
@ -93,23 +169,30 @@ The app functions are divided into user process phases (with direct ties to the
| 4 | Exposure (Contact with an Infected Person) | All functions associated with contact points (such as notifications, recommended actions) |
| 5 | Notification of Covid-19 Test Results | Functions related to the notification of test results |
| 6 | Warning trigger | Process to trigger a warning if a test result is positive |
<!-- markdownlint-enable-->
#### Support processes
<!-- markdownlint-disable -->
| # | Epic | Description |
|---:|--------|--------------|
| 7 | Parameter Settings | Parameters for contact point definition |
| 8 | Technical Support | Support processes (such as hotlines) |
| 9 | Accessibility | Apps from public authorities must be accessible, pursuant to the German Act on Equal Opportunities for Persons with Disabilities (BGG, section 12). Apps should be usable by all persons with disabilities. |
| 10 | Content Management | To adjust and update content in the app (texts, links, hotlines, and so on) |
<!-- markdownlint-enable-->
## Overview of User Stories
The requirements the Corona-Warn-App must satisfy, and which define its functional scope, are formulated below in the usual format of a user story, unless specified otherwise:
_“As &lt;stakeholder&gt;, I want &lt;goal&gt;, so that &lt;reason&gt;.“_
The requirements the Corona-Warn-App must satisfy, and which define its
functional scope, are formulated below in the usual format of a user story,
unless specified otherwise:
The corresponding acceptance criteria supplement the specification of the requirements by defining the conditions that the software must fulfill to satisfy user needs..
"As &lt;stakeholder&gt;, I want &lt;goal&gt;, so that &lt;reason&gt;."
The corresponding acceptance criteria supplement the specification of the
requirements by defining the conditions that the software must fulfill to
satisfy user needs..
### Onboarding and Installation
<!-- markdownlint-disable-->
| # of user story ID | User story | Acceptance criteria |
|-----------------|------------|--------------------|
| E01.01 | As an app user, the first time I launch the app, I want to receive an introduction to how it works (app motivation). | 1. An introduction to how the app works is displayed the first time the app is launched.<hr/>2. The introduction to how the app works is not displayed when the app is launched subsequently.<hr/>3. The explanatory content is available to app users in the respective functional areas. |
@ -119,8 +202,9 @@ The corresponding acceptance criteria supplement the specification of the requir
| E01.05 | As an app user, the first time I use the app, I want to be asked whether the application is allowed to send me notifications, so that I can get notifications in a variety of situations. | 1. The app’s notification settings are queried before the app is used for the first time. This enables local notifications. True push notifications from external servers are not supported (APNs/FCM). <hr/>2. The prompt no longer appears after the first time the app is used. |
| E01.06 | As an app user, I want the app to be displayed in my language the first time I use it, so that I can understand how to use the app. | 1. The configured system language is detected.<hr/>2. If the content is not available in the detected system language, English is selected by default.<hr/>3. The first version of the app is expected to be available also in languages other than English. |
| E01.07 | As an app user, I want to see help functions and settings for accessibility during the onboarding process, so that I can use the app. | 1. Accessibility is provided depending on the options available in the respective operating system. |
<!-- markdownlint-enable-->
### Information and Instructions for Using the App
<!-- markdownlint-disable-->
| # of user story ID | User story | Acceptance criteria |
|-----------------|------------|--------------------|
| E02.01 | As an app user, I want to have access to a FAQ list, so that I can find answers to questions I might have about the app. | 1. The app will either contain a link to a web page with FAQs, which is displayed in a browser window, or the web page will be displayed within the app itself. |
@ -129,27 +213,31 @@ The corresponding acceptance criteria supplement the specification of the requir
| E02.04 | As an app user, I want to be able to display publication information for the app, so that I can see who is responsible for development and content of the app. | 1. There is a “Publication information” item in the menu.<hr/>2. The publication information contains the usual information required. |
| E02.05 | As an app user, I want to be able to display the terms of use and data privacy information at any time. | 1. The app provides simple access to the terms of use and data privacy information. |
| E02.06 | As an app user, I want to be able to see various hotlines for technical, privacy-related, health-related, and psychological questions, as well as for verification of test results, so that I can receive further information or answers to my questions. | 1. The app offers access to a technical hotline and a hotline for obtaining a phone TAN.<hr/>2. The times the hotline is available (such as 24/7) is displayed.<hr/>3. Phone numbers can be called directly from the app. |
<!-- markdownlint-enable-->
### Use in the Regular Process
<!-- markdownlint-disable-->
| # of user story ID | User story | Acceptance criteria |
|-----------------|------------|--------------------|
| E03.01 | As an app user, I want to be able to activate and deactivate the app, so that I can switch the functions on and off. | 1. The functions for generating pseudonymized IDs and sending them to nearby devices can be activated and deactivated. <hr/>2. The consequences of activation/deactivation are explained. |
| E03.02 | As an app user, I want to be able to reset to the app to the delivery defaults, so that I can reconfigure it. | 1. The app can be reset to the delivery defaults with a setting option. The saved traces have to be deleted through the system settings. |
| E03.03 | As an app user, I want to be able to adjust the app settings (access permissions, such as notifications) in a menu, so that I can manage the app functions and accesses. | 1. App users can call a menu for app settings. <hr/>2. Notifications can be activated and deactivated.<hr/>3. Access to the functions for generating pseudonymized IDs and sending them to nearby devices can be activated and deactivated.<hr/>4. Before access permissions are deactivated, I receive information as to which app functions will no longer work (in full). |
<!-- markdownlint-enable-->
### Exposure (Contact with an Infected Person)
<!-- markdownlint-disable-->
| # of user story ID | User story | Acceptance criteria |
|-----------------|------------|--------------------|
| E04.01 | As an app user, I want to be notified when a person I have had contact with has reported an infection, so that I can then take the appropriate measures to stop the spread of the virus. | 1. Depending on the notification settings, the app sends a notification to the user.<hr/>2. If the risk assessment for a user changes, a notification informs users that there is news in the app. The actual changed risk assessment is not displayed until the app is opened. |
| E04.02 | As an app user, if I am exposed to the virus, I want to receive instructions from the app, so that I can adapt my behavior to RKI recommendations. | 1. A notification leads the user to the app. The recommendations from the RKI are defined statically in the app. |
<!-- markdownlint-enable-->
### Notification of Covid-19 Test Results
<!-- markdownlint-disable-->
| # of user story ID | User story | Acceptance criteria |
|-----------------|------------|--------------------|
| E05.01 | As the RKI, I want only positive tested users to trigger a one-time warning, so that I can prevent misuse. | 1. Only positive tests can trigger a warning. This is ensured by the verification server and the hotline for the phone TAN procedure.<hr/>2. A warning can only be triggered once for each test. |
| E05.02 | As an app user, in case of a positive test result, I want to receive information about the illness and the necessary next steps, so that I can adapt my behavior to RKI recommendations. | 1. A notification merely informs you that there is news in the app. The test result itself can only be seen in the app. <hr/>2. An info text with defined content is displayed in the app (for example, information about the outcome of the test result, information about necessary measures, a hotline number). |
<!-- markdownlint-enable-->
### Triggering a Warning
<!-- markdownlint-disable-->
| # of user story ID | User story | Acceptance criteria |
|-----------------|------------|--------------------|
| E06.01 | As an app user, I want to be able to scan a QR code provided by a medical professional or test center, so that I can receive my test result in the Corona-Warn-App. | 1. A QR code provided on a flyer from the medical professional or test center can be scanned with the Corona-Warn-App.<hr/>2. An explanatory text is displayed. |
@ -158,25 +246,30 @@ The corresponding acceptance criteria supplement the specification of the requir
| E06.04 | As an app user, I want to be able to use a manual process (in addition to the digital process), for example, through a call center and without a QR code, to send the pseudonymized IDs under which I was visible to other app users in recent days, to the Warn server, so that the people I have been in contact with can be warned by their apps. | 1. The center responsible can generate a TAN and provide it to the person. (The TAN is generated by a server, not the call center itself.) |
| E06.05 | As an app user, I want to be able to enter a TAN in the app, so that I can use the TAN I have been given to assign my test result to my instance of the app. | 1. It is possible to enter a TAN within the app.<hr/>2. The app verifies the entered TAN and provides feedback as to whether it was correct (must be checked whether technically possible). |
| E06.06 | As an app user, after the TAN is verified, I want to share my pseudonymized IDs voluntarily, so that I can warn persons I may have been in contact with. | 1. The IDs can be sent to the Warn server pseudonymized.<hr/>2. Data transmission is only possible if successfully verified beforehand. This is ensured by the verification server and the hotline for the phone TAN procedure.<hr/>3. Data transmission is only possible if the person has granted consent beforehand. |
<!-- markdownlint-enable-->
### Parameter Settings
<!-- markdownlint-disable-->
| # of user story ID | User story | Acceptance criteria |
|-----------------|------------|--------------------|
| E07.01 | As the RKI, I want to be able to configure the parameters (to the extent the API is able to do this) for risk scoring, so that I can keep up with the latest research findings on virus transmission. | 1. Thresholds can be configured dependent on the provided API.<hr/>2. The app receives dynamic configurations from the RKI that can affect how the risk assessment is calculated. |
<!-- markdownlint-enable-->
### Technical Support
<!-- markdownlint-disable-->
| # of user story ID | User story | Acceptance criteria |
|-----------------|------------|--------------------|
| E08.01 | As an app user, I want to be able to contact a hotline, so that I can resolve any technical problems with the app. | 1. The phone number of the technical hotline is stored in the app. |
<!-- markdownlint-enable-->
### Accessibility
<!-- markdownlint-disable-->
| # of user story ID | User story | Acceptance criteria |
|-----------------|------------|--------------------|
| E09.01 | As an app user, I want it to have audio output, so that I can use the app even if I have impaired vision (or am blind), for example. | 1. Accessibility regarding audio output is provided depending on the options available in the respective operating system. |
| E09.02 | As an app user, I want to have good contrast settings, modifiable font sizes, and an easily readable font, so that I can read the texts in the app easily. | 1. Accessibility regarding contrast and font size/type is provided depending on the options available in the respective operating system. |
| E09.03 | As an app user, I want to have the content in simplified language, so that I can easily understand how to use the app and why I should use it. | 1. The texts and languages are defined by the ordering party. |
<!-- markdownlint-enable-->
### Content Management
<!-- markdownlint-disable-->
| # of user story ID | User story | Acceptance criteria |
|-----------------|------------|--------------------|
| E10.01 | As the RKI, I want to manage the app content centrally, so that I can update texts, links, hotlines, and so on once for all the places in the app. | 1. Content management will be carried out based on RKI requirements.<hr/>2. Content will be differentiated by static and dynamic content, in line with technical feasibility.<hr/>3. In the initial version, updates will be performed through an app update. |
<!-- markdownlint-enable-->

101
solution_architecture.md
View File

@ -6,11 +6,12 @@ The diagrams reflect the current state but may also change at a later point in
Please note that further technical details on the individual components, the security concept, and the data protection concept are provided at a later date.
We assume a close association of a mobile phone and its user and, thus, equate the device (phone, app) and the person using it (person, user, individual) and use these terms interchangeably.
We assume a close association of a mobile phone and its user and, thus, equate the device (phone, app) and the person using it (person, user, individual) and use these terms interchangeably.
![Corona-Warn-App Components](images/solution_architecture/CWA_Components.png "Corona-Warn-App Components")
## TABLE OF CONTENTS
1. [INTRODUCTION](#introduction)
1. [Retrieval of lab results and verification process](#retrieval-of-lab-results-and-verification-process)
2. [Upload schedule for Diagnosis Keys](#upload-schedule-for-diagnosis-keys)
@ -26,14 +27,13 @@ We assume a close association of a mobile phone and its user and, thus, equate t
5. [CROSS-BORDER INTEROPERABILITY](#cross-border-interoperability)
6. [LIMITATIONS](#limitations)
## 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 affected individuals have identified possibly infected individuals in personal conversations based on each individuals' memory. This has 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 have identified possibly infected individuals in personal conversations based on each individuals' memory. This has 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")
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*, enables individuals to trace their personal exposure risk via their mobile phones. The Corona-Warn-App uses a new framework provided by Apple and Google called [Exposure Notification Framework](https://www.apple.com/covid19/contacttracing). The framework employs [Bluetooth Low Energy (BLE)](https://en.wikipedia.org/wiki/Bluetooth_Low_Energy) mechanics. BLE lets the individual mobile phones act as beacons meaning that they constantly broadcast a temporary identifier called Rolling Proximity Identifier (RPI) that is remembered and, at the same time, lets the mobile phone scan for identifiers of other mobile phones. This is shown on the right side of *Figure 1*.
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*, enables individuals to trace their personal exposure risk via their mobile phones. The Corona-Warn-App uses a new framework provided by Apple and Google called [Exposure Notification Framework](https://www.apple.com/covid19/contacttracing). The framework employs [Bluetooth Low Energy (BLE)](https://en.wikipedia.org/wiki/Bluetooth_Low_Energy) mechanics. BLE lets the individual mobile phones act as beacons meaning that they constantly broadcast a temporary identifier called Rolling Proximity Identifier (RPI) that is remembered and, at the same time, lets the mobile phone scan for identifiers of other mobile phones. This is shown on the right side of *Figure 1*.
Identifiers are ID numbers sent out by the mobile phones. To ensure privacy and to prevent the 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 is substituted at midnight (UTC) every day through means of cryptography. For a more detailed explanation, see *Figure 10*. Once a TEK is linked to a positive test result, it remains technically the same, but is then called a Diagnosis Key.
The collected identifiers from other users as well as the own keys, which can later be used to derive the identifiers, are stored locally on the phone in the secure storage of the framework provided by Apple and Google. The application cannot access this secure storage directly, but only through the interfaces the Exposure Notification Framework provides. To prevent misuse, some of these interfaces are subjected to [rate limiting](https://developer.apple.com/documentation/exposurenotification/enmanager/3586331-detectexposures). If app users are 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 from up to 14 days back. On the Corona-Warn-App back-end server, all keys of positively tested individuals are aggregated and are then made available to all mobile phones that have the app installed. Additionally, the configuration parameters for the framework are available for download, so that adjustments to the risk score calculation can be made, see the *Risk Scores* section.
@ -42,17 +42,19 @@ Once the keys and the exposure detection configuration have been downloaded, the
It is important to note that the persons that have been exposed to a positively tested individual 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 mobile phone and is not shared.
The Corona-Warn-App pursues two objectives:
1. It supports individuals in finding out whether they have been exposed to a person that has later been tested positively.
2. It receives the result of a SARS-CoV-2 test on a user's mobile phone through an online system. This helps reduce the time until necessary precautions, e.g. a contact reduction and testing, can be taken.
In order to prevent misuse, individuals need to provide proof that they have been tested positively before they can 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 in the app and for the Exposure Notification Framework that they agree 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' mobile phones or if users have decided against the electronic transmission of their test results.
In order to prevent misuse, individuals need to provide proof that they have been tested positively before they can 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 in the app and for the Exposure Notification Framework that they agree 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' mobile phones 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 Corona-Warn-App is crucial for informing others about a relevant exposure and potential infection. However, to prevent misuse, a verification is required before diagnosis keys can be uploaded.
There are two ways for receiving this verification:
1. Using 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). With this integration, the positive test result is already verified and the diagnosis keys can be uploaded right after the users have given their consent.
Reporting positive tests to the Corona-Warn-App is crucial for informing others about a relevant exposure and potential infection. However, to prevent misuse, a verification is required before diagnosis keys can be uploaded.
There are two ways for receiving this verification:
1. Using 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). With this integration, the positive test result is already verified and the diagnosis keys can be uploaded right after the users have given their consent.
2. Providing a human-readable token, e.g. a number or a combination of words, 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")
@ -64,25 +66,25 @@ 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:** 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 mobile 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 mobile phone (*Figure 3*, step 4).
- (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 mobile 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 mobile 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 other barcodes (lab ID, sample IDs).
- **Step 3:** As soon as the test result is available meaning 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 mobile 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 that information is available. The result themselves as well as recommendations for further actions are only displayed after the user has opened the app (see the scoping document for more details).
- If the test returns 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 the 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 used as authorization in the HTTP header of the POST request for upload of the diagnosis keys of 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.
- 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.
![Figure 3: Data flow for the verification process](images/solution_architecture/figure_3.svg "Figure 3: Data flow for the verification process")
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) can be transferred in the body.
As mentioned before, users might have decided against retrieving test results electronically, or the lab may not support the electronic process. Step 3 of *Figure 2* shows 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 a positive test result, 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 lab may not support the electronic process. Step 3 of *Figure 2* shows 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 a positive test result, 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")
@ -90,7 +92,7 @@ The retrieval of the registration token ensures a coupling between a specific mo
If a user deletes and reinstalls the app, the stored registration token is lost, making it impossible to retrieve the test results. In this case the fallback with the health authority workflow (through a hotline) needs to be used.
From a privacy protection perspective, sending push notifications via Apple’s or Google’s push service is not acceptable in this scenario. Even though no specific test results are included in the notifications, the message itself signals that the user has taken a SARS-CoV-2 test. Thus, polling and local notifications are used instead. If a user also decides against local notifications, a manual update of the test results is also possible.
If a user did not receive a teleTAN from the health authority and/or has lost the QR code, a teleTAN needs to be retrieved from a hotline. The hotline ensures that users are permitted to perform an upload before issuing the teleTAN. It is then used as described before, starting from *Figure 4*, step 7.
If a user did not receive a teleTAN from the health authority and/or has lost the QR code, a teleTAN needs to be retrieved from a hotline. The hotline ensures that users are permitted to perform an upload before issuing the teleTAN. It is then used as described before, starting from *Figure 4*, step 7.
### Upload Schedule for Diagnosis Keys
@ -98,7 +100,7 @@ According to the current version of the documentation from Apple and Google (1.3
![Figure 5: Upload schedule for Temporary Exposure Keys (Diagnosis Keys)](images/solution_architecture/figure_5.svg "Figure 5: Upload schedule for Temporary Exposure Keys (Diagnosis Keys)")
As users are not required to confirm negative test results, the functionality of uploading Diagnosis Keys on subsequent days remains theoretical. Each of those uploads could take place earliest at the end of each subsequent day (see (3) in *Figure 5*). It would require explicit consent of the user for each day and could take place up to the time when the person is not considered contagious anymore (but not any longer, as this would lead to false positives).
As users are not required to confirm negative test results, the functionality of uploading Diagnosis Keys on subsequent days remains theoretical. Each of those uploads could take place earliest at the end of each subsequent day (see (3) in *Figure 5*). It would require explicit consent of the user for each day and could take place up to the time when the person is not considered contagious anymore (but not any longer, as this would lead to false positives).
As of now, two uploads are required from the same mobile phone (past diagnosis keys and from the current day). This means, the registration token may not be invalidated after the first upload, but must remain active. The TANs sent to the Corona-Warn-App Server are only valid for a single use. In case of the teleTAN, an additional registration token is created which then allows the app to retrieve TANs for individual uploads.
@ -107,17 +109,18 @@ As of now, two uploads are required from the same mobile phone (past diagnosis k
![Figure 6: Actors in the system, including external parties (blue components to be open-sourced)](images/solution_architecture/figure_6.svg "Figure 6: Actors in the system, including external parties (blue components to be open-sourced)")
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 as explained in the “Retrieval of Lab Results and Verification Process” section and 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, labeled “Transport Metadata Removal” in *Figure 6*.
- Verify association with a positive test through the Verification Server and the associated workflow as explained in the “Retrieval of Lab Results and Verification Process” section and 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, labeled “Transport Metadata Removal” in *Figure 6*.
- Provide [configuration parameters](#data-format) to the mobile applications
- Threshold values for [attenuation buckets](#attenuation-buckets)
- Risk scores for defined values
- Threshold values for risk categories and alerts
- 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)
- Assemble diagnosis keys into chunks for a given time period
- Store chunks as static files (in protocol buffers, compatible with the format specified by Apple and Google)
- Transfer files to a storage service as shown at the bottom of *Figure 6* which acts as a source for the Content Delivery Network (CDN)
- Assemble diagnosis keys into chunks for a given time period
- Store chunks as static files (in protocol buffers, compatible with the format specified by Apple and Google)
- Transfer files to a storage service as 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 that has 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 back end. For a better understanding, the database has been visualized separately.
@ -133,21 +136,22 @@ To prevent this, the aggregated files are shuffled, e.g. by using an ORDER BY RA
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.
Further information can be found in the dedicated architecture documents for the Corona-Warn-App Server, the Verification Server, and the Portal Server. The documents will be linked here, as soon as they are available.
Further information can be found in the dedicated architecture documents for the Corona-Warn-App Server, the Verification Server, and the Portal Server. The documents will be linked here, as soon as they are available.
### Data Format
The current base unit for data chunks will be one hour. Data will be encoded in the protocol buffer format as specified by Apple and Google (see *Figure 8*). It is planned that in case a data chunk does not hold any or too few diagnosis keys, the chunk generation will be skipped.
The server will make the following information available through a RESTful interface:
- Available items through index endpoints (not all implemented in first iteration)
- Newly-added Diagnosis Keys (Temporary Exposure Keys) for the time frame
- Configuration parameters
- 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
- 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
Return data needs to be signed and will contain a timestamp (please refer to protocol buffer files for further information). Using index endpoints will not increase the number of requests, as they can be handled within a single HTTP session. In case the hourly endpoint does not hold diagnosis keys for the selected hour, the mobile application does not need to download it. If, on the other hand multiple files need to be downloaded (e.g. because the client was switched off overnight), they can be handled in a single session as well.
@ -157,7 +161,7 @@ In order to ensure the authenticity of the files, they need to be signed (accord
### Data URL
Retrieving the data in a RESTful format, making it clearer to make it available through a transparent CDN (only requesting the files once).
Retrieving the data in a RESTful format, making it clearer to make it available through a transparent CDN (only requesting the files once).
If no diagnosis keys are available for the selected parameters, but the time frame has already passed, a signed payload with a timestamp and an empty list of diagnosis keys is returned. As this file is also signed by the server and, through the timestamp, is also different from other files without diagnosis keys, its authenticity can be verified.
@ -171,9 +175,9 @@ The data on all involved servers is only retained as long as required. Diagnosis
The functional scope of the mobile applications (apps) is defined in the corresponding [scoping document](https://github.com/corona-warn-app/cwa-documentation/blob/master/scoping_document.md). The apps are developed natively for Apple’s iOS and Google’s Android operating systems. They 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 Apple devices 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 devices, 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).
For Android devices, 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://developers.google.com/android/exposure-notifications/exposure-notifications-api#architecture).
![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)")
@ -186,21 +190,23 @@ The encapsulation especially applies to the part where matches are calculated, a
![Figure 11: Key flow from the receiving perspective (as described in the specification by Apple/Google)](images/solution_architecture/figure_11.svg "Figure 11: Key flow from the receiving perspective (as described in the specification by Apple/Google)")
[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. 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 (with a range from 0-4096) according to the defined parameters
- **Attenuation value** (Reported Transmit Power - Measured RSSI)
- **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 (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 implementation 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).
While in the Google implementation 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-metadata) 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
@ -209,6 +215,7 @@ The information listed above is not visible to the user, but is used internally
![Figure 12: Risk calculation](images/solution_architecture/figure_12.svg "Figure 12: Risk calculation")
*Figure 12* displays how the total risk score is being calculated. The application is provided with a set of parameters, which are marked in blue within the figure.
Those parameters are regularly downloaded from the CWA Server, which means they can be modified without requiring a new version of the application (see [`exposure-config.yaml`](https://github.com/corona-warn-app/cwa-server/blob/master/services/distribution/src/main/resources/master-config/exposure-config.yaml) for details).
Each of the four risk categories (days since exposure, exposure duration, weighted signal attenuation, and the transmission risk factor) receives an input value from the event which is then mapped to a predefined input value interval.
@ -225,7 +232,7 @@ Additionally, a central threshold for the combined risk score specifies whether
Furthermore the Google/Apple framework allows to set a [```minimalRiskScore```](https://developer.apple.com/documentation/exposurenotification/enexposureconfiguration/3583692-minimumriskscore) to exclude exposure incidents with scores lower than the value of this property.
In the current version of the API the time spent within the ranges of attenuation buckets are accumulated over all exposure incidents during one matching session.
Since the number of requests is currently limited, it is not possible to get these values for each day and each exposure incident separately.
While by default there is no minimum value set, this value is being configured accordingly, so that presumably irrelevant exposure incidents are excluded.
While by default there is no minimum value set, this value is being configured accordingly, so that presumably irrelevant exposure incidents are excluded.
![Figure 13: Calculation of the combined risk score](images/solution_architecture/figure_13.svg "Figure 13: Calculation of the combined risk score")
@ -238,7 +245,7 @@ In order to be able to regularly match the RPIs associated with positive tests (
In order to prevent load peaks in the back end, the downloads need to be spread evenly across the set time interval (currently an hour). To achieve that, each client needs to randomly decide on a point of time within the given hour, when it will download the data. With a large number of clients, this should statistically lead to an even distribution of requests.
However, [Apple’s background tasks](https://developer.apple.com/documentation/backgroundtasks) don’t allow a specific point of time when the download task shall be distributed, but instead only let the developer define a [minimum time interval](https://developer.apple.com/documentation/backgroundtasks/bgtaskrequest/3142244-earliestbegindate) after which the tasks should be executed. Even though exact execution times cannot be guaranteed, we expect a behavior as specified above.
However, [Apple’s background tasks](https://developer.apple.com/documentation/backgroundtasks) don’t allow a specific point of time when the download task shall be distributed, but instead only let the developer define a [minimum time interval](https://developer.apple.com/documentation/backgroundtasks/bgtaskrequest/3142244-earliestbegindate) after which the tasks should be executed. Even though exact execution times cannot be guaranteed, we expect a behavior as specified above.
To ensure that as few requests as absolutely necessary are made, the earliest point in time should be at the beginning of the next availability interval. A random number should be added to ensure that the earliest start dates are spread evenly across all clients. For an hourly interval this could be calculated as follows:
@ -264,13 +271,13 @@ If the back end 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 framework by Apple and 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 and Google is being used.
Further details will be added as soon as they are available.
## LIMITATIONS
Even though the system can support individuals in finding out whether they have been in proximity with a person that has been tested positively later on, the system also has limits (shown in *Figure 14*) that need to be considered. One of those limitations is that while the device constantly broadcasts its own Rolling Proximity Identifiers, it only listens for others in defined time slots. Those [listening windows are currently up to five minutes](https://covid19-static.cdn-apple.com/applications/covid19/current/static/contact-tracing/pdf/ExposureNotification-BluetoothSpecificationv1.2.pdf) apart and are defined as being only very short. In our considerations we expect the windows to have a length of two to four seconds. For the attenuation, the two buckets provided by the framework are being considered. A lower attenuation means that the other device is closer; we assume that an attenuation <50dB translates to a distance below two meters. A higher attenuation might either mean that the other device is farther away (i.e. a distance of more than two meters) or that there is something between the devices blocking the signal. This could be objects such as a wall, but also humans or animals.
Even though the system can support individuals in finding out whether they have been in proximity with a person that has been tested positively later on, the system also has limits (shown in *Figure 14*) that need to be considered. One of those limitations is that while the device constantly broadcasts its own Rolling Proximity Identifiers, it only listens for others in defined time slots. Those [listening windows are currently up to five minutes](https://covid19-static.cdn-apple.com/applications/covid19/current/static/contact-tracing/pdf/ExposureNotification-BluetoothSpecificationv1.2.pdf) apart and are defined as being only very short. In our considerations we expect the windows to have a length of two to four seconds. For the attenuation, the two buckets provided by the framework are being considered. A lower attenuation means that the other device is closer; we assume that an attenuation <58 dB translates to a distance below two meters. A higher attenuation might either mean that the other device is farther away (i.e. a distance of more than two meters) or that there is something between the devices blocking the signal. This could be objects such as a wall, but also humans or animals.
![Figure 14: Limitations of the Bluetooth Low Energy approach](images/solution_architecture/figure_14.svg "Figure 14: Limitations of the Bluetooth Low Energy approach")

8
translations/LANGUAGE_STYLE.de.md
View File

@ -1,11 +1,13 @@
# Sprachstil
## Vorurteilsfreie Sprache und Kommunikation
Vorurteilsfreie Kommunikation bedeutet keine Stereotypisierung oder Diskriminierung von Menschen. Es geht darum, alle auf faire und respektvolle Weise zu behandeln. Dies bezieht sich auf verschiedene Dimensionen der Identität einer Person, wie Kultur, Geschlecht, Nationalität, ethnische Zugehörigkeit, Alter, wirtschaftlicher Hintergrund, Religion, sexuelle Orientierung oder besondere Bedürfnisse (Behinderungen). Diese Leitlinien berücksichtigen wir bei allen Veröffentlichungen in diesem Repository.
## Geschlecht und geschlechtsneutrale Sprache
- Wir nutzen geschlechtsneutrale Terminologie, zum Beispiel "Abteilungsleitung" anstelle von "Abteilungsleiter".
- Wir nutzen geschlechtsneutrale Terminologie, zum Beispiel "Abteilungsleitung" anstelle von "Abteilungsleiter".
- Wir wenden diese Regel ausschließlich auf Begriffe an, die sich auf natürliche Personen beziehen. Begriffe, die ein maskulines oder feminines grammatikalisches Geschlecht haben, aber im Text keine natürliche Person beschreiben, können weiterhin uneingeschränkt benutzt werden. Beispiel: Die Verwendung von "Auftraggeber" für juristische Personen wie Firmen, Institutionen usw.
- Wir vermeiden die maskulinen Singular-Pronomen "er", "ihn", "ihm" in generischen Aussagen wie zum Beispiel "Ein Nutzer kann seinen Bildschirm personalisieren". Besser: "Eine Person kann ihren Bildschirm personalisieren"
- Wir achten dabei darauf, dass der Text natürlich klingt. Wir werden die deutsche Sprache dabei nicht bis an die Grenzen der Grammatik und Verständlichkeit ausdehnen. Bei der Suche nach Alternativen dürfen die Aussagen im Text nicht verfälscht werden. So ist etwa nicht immer die Nominalisierung des Partizips I (z.B. "Laufende") gleichbedeutend mit der geschlechtsspezifischen Formulierung (z.B. "Läufer" oder "Läuferin"), da das Partizip I in der Regel primär einen gerade aktiven Vorgang beschreibt. Im Beispiel sind alle "Laufenden" immer auch "Läuferinnen" und "Läufer", umgekehrt ist das jedoch nicht zu jedem Zeitpunkt der Fall.
- Sofern eine neutrale Formulierung ohne eine Verfälschung des Textes bzw. seiner Aussage nicht möglich ist, verwenden wir den Doppelpunkt, gefolgt von der geschlechtsspezifischen Endung, um alle Geschlechter gleich anzusprechen. Beispiele für solche Endungen sind ":in", "innen" oder ":r". Beispiele: "Arbeiter:in", "Lehrer:innen" oder "Vorstandsvorsitzende:r". Diese Option sollte jedoch nur in Ausnahmefällen gewählt werden, da sie den Lesefluss stört. Zudem wird der Doppelpunkt von verschiedenen Screenreadern, die von Personen mit Einschränkung der Sehfähigkeit genutzt werden, explizit ausgesprochen. Beispiel: "Arbeiter Doppelpunkt innen". Dies beeinträchtigt Personen mit besonderen Bedürfnissen und sollte deswegen vermieden werden.
- Wir achten dabei darauf, dass der Text natürlich klingt. Wir werden die deutsche Sprache dabei nicht bis an die Grenzen der Grammatik und Verständlichkeit ausdehnen. Bei der Suche nach Alternativen dürfen die Aussagen im Text nicht verfälscht werden. So ist etwa nicht immer die Nominalisierung des Partizips I (z.B. "Laufende") gleichbedeutend mit der geschlechtsspezifischen Formulierung (z.B. "Läufer" oder "Läuferin"), da das Partizip I in der Regel primär einen gerade aktiven Vorgang beschreibt. Im Beispiel sind alle "Laufenden" immer auch "Läuferinnen" und "Läufer", umgekehrt ist das jedoch nicht zu jedem Zeitpunkt der Fall.
- Sofern eine neutrale Formulierung ohne eine Verfälschung des Textes bzw. seiner Aussage nicht möglich ist, verwenden wir den Doppelpunkt, gefolgt von der geschlechtsspezifischen Endung, um alle Geschlechter gleich anzusprechen. Beispiele für solche Endungen sind ":in", "innen" oder ":r". Beispiele: "Arbeiter:in", "Lehrer:innen" oder "Vorstandsvorsitzende:r". Diese Option sollte jedoch nur in Ausnahmefällen gewählt werden, da sie den Lesefluss stört. Zudem wird der Doppelpunkt von verschiedenen Screenreadern, die von Personen mit Einschränkung der Sehfähigkeit genutzt werden, explizit ausgesprochen. Beispiel: "Arbeiter Doppelpunkt innen". Dies beeinträchtigt Personen mit besonderen Bedürfnissen und sollte deswegen vermieden werden.

18
translations/README.de.md
View File

@ -4,7 +4,7 @@
<hr />
<p align="center">
<a href="#über-dieses-projekt">Über dieses Projekt</a> •
<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> •
@ -17,10 +17,13 @@
</p>
<hr />
# Corona-Warn-App: Dokumentation
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 "<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.
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
@ -47,15 +50,18 @@ Wir entwickeln diese Anwendung für Deutschland. Wir möchten so offen und trans
Dieses Repository enthält die Entwicklungsdokumentation und zugehörige Inhalte.
### Projektumfang (Scoping-Dokument)
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)
* [Wie ermittelt die Corona-Warn-App ein erhöhtes Risiko?](cwa-risk-assessment.de.md)
* [Corona-Warn-App Datenschutz-Folgeabschätzung/DSFA (PDF)](https://www.coronawarn.app/assets/documents/cwa-datenschutz-folgenabschaetzung.pdf), [DSFA Anlage 1](https://www.coronawarn.app/assets/documents/cwa-datenschutz-folgenabschaetzung-anlage1.pdf), [DSFA Anlage 2](https://www.coronawarn.app/assets/documents/cwa-datenschutz-folgenabschaetzung-anlage2.pdf), [DSFA Anlage 3](https://www.coronawarn.app/assets/documents/cwa-datenschutz-folgenabschaetzung-anlage3.pdf), [DSFA Anlage 4](https://www.coronawarn.app/assets/documents/cwa-datenschutz-folgenabschaetzung-anlage4.pdf), [DSFA Anlage 5](https://www.coronawarn.app/assets/documents/cwa-datenschutz-folgenabschaetzung-anlage5.pdf)
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)
- [Wie ermittelt die Corona-Warn-App ein erhöhtes Risiko?](cwa-risk-assessment.de.md)
- [Corona-Warn-App Datenschutz-Folgeabschätzung/DSFA (PDF)](https://www.coronawarn.app/assets/documents/cwa-datenschutz-folgenabschaetzung.pdf), [DSFA Anlage 1](https://www.coronawarn.app/assets/documents/cwa-datenschutz-folgenabschaetzung-anlage1.pdf), [DSFA Anlage 2](https://www.coronawarn.app/assets/documents/cwa-datenschutz-folgenabschaetzung-anlage2.pdf), [DSFA Anlage 3](https://www.coronawarn.app/assets/documents/cwa-datenschutz-folgenabschaetzung-anlage3.pdf), [DSFA Anlage 4](https://www.coronawarn.app/assets/documents/cwa-datenschutz-folgenabschaetzung-anlage4.pdf), [DSFA Anlage 5](https://www.coronawarn.app/assets/documents/cwa-datenschutz-folgenabschaetzung-anlage5.pdf)
## Lizenzierung

150
translations/cwa-risk-assessment.de.md
View File

@ -2,32 +2,158 @@
## Voraussetzungen
Personen, die die Corona-Warn-App (CWA) nutzen und positiv auf das Coronavirus SARS-CoV-2 getestet wurden, können ihrer CWA erlauben, die vom Betriebssystem ihres Smartphones erzeugten zufälligen Geräteschlüssel (*Temporary Exposure Keys*) der vergangenen Tage als sogenannte Positivkennungen (*Diagnosis Keys*) auf den Corona-Warn-App-Server hochzuladen und dort zu veröffentlichen. Diese Positivkennungen sind die Grundlage der Risikoermittlung für alle anderen die CWA nutzenden Personen.
Personen, die die Corona-Warn-App (CWA) nutzen und positiv auf das Coronavirus SARS-CoV-2 getestet wurden, können ihrer CWA erlauben, die vom Betriebssystem ihres Smartphones erzeugten zufälligen Geräteschlüssel (*Temporary Exposure Keys*) der vergangenen Tage als sogenannte Positivkennungen (*Diagnosis Keys*) auf den Corona-Warn-App-Server hochzuladen und dort zu veröffentlichen.
Diese Positivkennungen sind die Grundlage der Risikoermittlung für alle anderen die CWA nutzenden Personen.
Eine Corona-positiv getestete Person lädt bis zu 15 Positivkennungen hoch, nämlich je eine für jeden der bis zu 14 letzten Tage vor dem Hochladen sowie am folgenden Tag die für den aktuellen Tag. Letzteres ist nötig, da Positivkennungen nur für bereits vergangene Tage hochgeladen werden können.
Eine Corona-positiv getestete Person lädt bis zu 15 Positivkennungen hoch, nämlich je eine für jeden der bis zu 14 letzten Tage vor dem Hochladen sowie (derzeit noch nicht umgesetzt) am folgenden Tag die für den aktuellen Tag.
Letzteres ist nötig, da Positivkennungen nur für bereits vergangene Tage hochgeladen werden können, um Missbrauch noch aktiver Positivkennungen zu verhindern.
Positivkennungen lassen keine Rückschlüsse auf die Identität der positiv getesteten Person zu, aber die Positivkennung eines bestimmten Tages passt zu den ständig wechselnden Zufallscodes (*Rolling Proximity Identifiers*), die das Smartphone der Person den ganzen Tag über mittels Bluetooth versendet hat und die von den Smartphones in der Nähe empfangen und aufgezeichnet wurden. An jede Positivkennung ist noch ein Wert angehängt, der angibt, wie groß das Übertragungsrisiko (*Transmission Risk Level*) der positiv getesteten Person an dem Tag, zu dem die Positivkennung gehört, vermutlich gewesen ist. Dieses Übertragungsrisiko wird anhand von Erfahrungswerten unter Berücksichtigung der aktuell vorliegenden wissenschaftlichen Erkenntnisse in einem komplizierten Verfahren geschätzt. Jede Positivkennung verfällt, wenn sie älter als 14 Tage ist. Deshalb sind stets nur die Positivkennungen der letzten 14 Tage verfügbar.
Positivkennungen lassen keine Rückschlüsse auf die Identität der positiv getesteten Person zu, aber die Positivkennung eines bestimmten Tages passt zu den ständig wechselnden Zufallscodes (*Rolling Proximity Identifiers*), die das Smartphone der Person den ganzen Tag über mittels Bluetooth versendet hat und die von anderen Smartphones in der Nähe empfangen und aufgezeichnet wurden.
An jede Positivkennung ist noch ein Wert angehängt, der angibt, wie groß das Übertragungsrisiko (*Transmission Risk Level*) der positiv getesteten Person an dem Tag, zu dem die Positivkennung gehört, vermutlich gewesen ist. Dieses Übertragungsrisiko wird anhand von Erfahrungswerten unter Berücksichtigung der aktuell vorliegenden wissenschaftlichen Erkenntnisse [in einem mathematischen Verfahren geschätzt](../transmission_risk.pdf).
Jede Positivkennung verfällt, wenn sie älter als 14 Tage ist. Deshalb sind stets nur die Positivkennungen der letzten 14 Tage verfügbar.
## Verfahren
Alle aktiven Corona-Warn-Apps laden täglich vom Corona-Warn-App-Server die dort veröffentlichten Positivkennungen herunter und übergeben sie gesammelt über eine Schnittstelle an das Betriebssystem. Dort wird geprüft, ob empfangene und aufgezeichnete Zufallscodes vorliegen, die zu einer der Positivkennungen passen. Ein solches Zusammenpassen zeigt an, dass sich das Smartphone, das die Zufallscodes aufgezeichnet hat, und das Smartphone der Corona-positiv getesteten Person, die die Positivkennung hochgeladen hat, an dem Tag, zu dem die Positivkennung gehört, begegnet sind.
Alle aktiven Corona-Warn-Apps laden täglich vom Corona-Warn-App-Server die dort veröffentlichten Positivkennungen herunter und übergeben sie gesammelt über eine Schnittstelle an das Betriebssystem des Smartphones.
Dort wird geprüft, ob empfangene und aufgezeichnete Zufallscodes der letzten 14 Tage vorliegen, die zu einer der Positivkennungen passen.
Ein solches Zusammenpassen zeigt an, dass sich das Smartphone, das die Zufallscodes aufgezeichnet hat, und das Smartphone der Corona-positiv getesteten Person, die die Positivkennung hochgeladen hat, an dem Tag, zu dem die Positivkennung gehört, begegnet sind.
Als nächstes wird für jede Positivkennung anhand aller dazu passenden Zufallscodes geschätzt, wie lange die Begegnungen jenes Tags insgesamt gedauert haben und wie nahe die Smartphones sich dabei im Durchschnitt waren. Die Entfernung wird aus der gemessenen Abschwächung des Bluetooth-Signals errechnet, die in dB (Dezibel) angegeben wird. Jedem dB-Wert lässt sich eine Entfernung im Freiraum (d.h., ohne Hindernisse im Signalweg; s.a. Erläuterungen im Abschnitt "Folgen und Einschränkungen") zuordnen. Alle Begegnungen zu einer Positivkennung, die insgesamt weniger als 10 Minuten gedauert haben (egal, wie nahe sich die Smartphones dabei gekommen sind) oder bei denen die Smartphones im Durchschnitt mehr als ca. 8 Meter Freiraum (73 dB Dämpfung) voneinander entfernt waren (egal, wie lange sie insgesamt gedauert haben), werden als unbedenklich verworfen.
> NB: Tage im Kontext der Corona-Warn-App und damit auch dieses Dokuments sind Kalendertage nach UTC (Coordinated Universal Time). Der Tageswechsel erfolgt demnach um 1 Uhr Mitteleuropäischer Zeit bzw. 2 Uhr Mitteleuropäischer Sommerzeit.
> NB: Wir bezeichnen die Gesamtheit aller Begegnungen, die jeweils zu einer Positivkennung gehören, also alle Begegnungen eines Tages zwischen denselben zwei Smartphones, im Weiteren als Begegnungsmenge.
Als nächstes wird im Betriebssystem des Smartphones für jede Positivkennung anhand aller dazu passenden Zufallscodes geschätzt, wie lange die Begegnungen jenes Tags insgesamt gedauert haben und wie nahe die beiden Smartphones sich dabei im Durchschnitt waren.
Die Entfernung wird aus der gemessenen Abschwächung des Bluetooth-Signals errechnet, die in dB (Dezibel) angegeben wird.
Jedem dB-Wert lässt sich eine Entfernung im Freiraum (d.h., ohne Hindernisse im Signalweg; s.a. Erläuterungen im Abschnitt "Folgen und Einschränkungen") zuordnen.
Alle Begegnungen zu einer Positivkennung, die insgesamt weniger als 10 Minuten gedauert haben (egal, wie nahe sich die Smartphones dabei gekommen sind) oder bei denen die Smartphones im Durchschnitt mehr als ca. 8 Meter Freiraum (>73 dB Dämpfung) voneinander entfernt waren (egal, wie lange sie insgesamt gedauert haben), werden als unbedenklich verworfen.
> NB: Wir bezeichnen die Gesamtheit aller Begegnungen, die jeweils zu einer bestimmten Positivkennung gehören, also alle Begegnungen eines Tages zwischen denselben zwei Smartphones, im Weiteren als Begegnungsmenge.
Bei den restlichen, nicht als unbedenklich verworfen Begegnungen wird für jede Begegnungsmenge ein Begegnungsrisiko (*Total Risk Score*) errechnet, indem der oben erläuterte Übertragungsrisikowert mit einem Verzugsrisikowert (*Days Since Last Exposure Value*) multipliziert wird, der sich aus der Anzahl der seit der Begegnung vergangenen Tage ableitet.
Alle Begegnungsmengen, die dabei einen bestimmten Grenzwert (*Minimum Risk Score*) überschreiten, werden als Risikobegegnungen angesehen. Die anderen Begegnungsmengen werden ebenso wie zuvor schon die zu kurzen oder zu entfernten Begegnungsmengen als unbedenklich verworfen.
Alle Begegnungsmengen, deren Begegnungsrisiko dabei einen bestimmten Grenzwert (*Minimum Risk Score*) überschreitet, werden als Risikobegegnungen angesehen.
Die anderen Begegnungsmengen werden ebenso wie zuvor schon die zu kurzen oder zu entfernten Begegnungsmengen als unbedenklich verworfen.
Zugleich wird für alle verbleibenden Begegnungsmengen, die Risikobegegnungen, zusammengezählt, wieviel Zeit in einem sehr nahen Entfernungsbereich unter ca. 1,5 Metern (55 dB Dämpfung) verbracht wurde und wieviel Zeit in einem nahen Entfernungsbereich zwischen ca. 1,5 und 3 Metern (63 dB Dämpfung) verbracht wurde. Dabei wird die Zeit im sehr nahen Bereich ganz und die Zeit im nahen Bereich zur Hälfte gezählt.
Zugleich wird für alle verbleibenden Begegnungsmengen, die Risikobegegnungen, zusammengezählt, wieviel Zeit in einem sehr nahen Entfernungsbereich unter ca. 1,5 Metern (<55 dB Dämpfung) verbracht wurde und wieviel Zeit in einem nahen Entfernungsbereich zwischen ca. 1,5 und 3 Metern (55 bis 63 dB Dämpfung) verbracht wurde.
Dabei wird die Zeit im sehr nahen Bereich ganz und die Zeit im nahen Bereich zur Hälfte gezählt.
Die in einer Entfernung von mehr als ca. 3 Metern verbrachte Zeit wird nicht gezählt.
Die so errechnete Gesamtzeit wird dann noch mit dem Begegnungsrisiko der Risikobegegnung mit dem höchsten Risiko (*Maximum Risk Score*) verrechnet. Und zwar so, dass sie unverändert bleibt, wenn dieses Risiko als durchschnittlich (für Risikobegegnungen) eingeschätzt wird, dass sie sich bis auf das ungefähr anderthalbfache verlängert, wenn dieses Risiko überdurchschnittlich ist, und deutlich (bis auf ungefähr ein Sechstel) verkürzt, wenn dieses Risiko unterdurchschnittlich ist. Dadurch kann eine Zeit, die zuvor 10 Minuten betrug, auf über 15 Minuten verlängert werden und eine Zeit, die zuvor 45 Minuten betrug, auf unter 10 Minuten verkürzt werden.
Die so errechnete Gesamtzeit aller Risikobegegnungen der letzten 14 Tage wird dann noch mit dem Begegnungsrisiko der Risikobegegnung mit dem höchsten Risiko (*Maximum Risk Score*) verrechnet.
Und zwar so, dass sie unverändert bleibt, wenn dieses Risiko als durchschnittlich (für Risikobegegnungen) eingeschätzt wird, dass sie sich bis auf das ungefähr anderthalbfache verlängert, wenn dieses Risiko überdurchschnittlich ist, und deutlich (bis auf ungefähr ein Sechstel) verkürzt, wenn dieses Risiko unterdurchschnittlich ist.
Dadurch kann eine Zeit, die zuvor 10 Minuten betrug, auf über 15 Minuten verlängert werden und eine Zeit, die zuvor 45 Minuten betrug, auf unter 10 Minuten verkürzt werden.
## Folgen und Einschränkungen
Am Ende wird die die CWA nutzende Person immer dann über ein erhöhtes Risiko benachrichtigt, wenn die so ermittelte gesamte Risikobegegnungszeit 15 Minuten oder länger ist. Diese Benachrichtigung erfolgt in der CWA und gibt der Person zugleich Handlungsempfehlungen für das weitere Vorgehen.
Am Ende wird die die CWA nutzende Person immer dann über ein erhöhtes Risiko benachrichtigt, wenn die so ermittelte gesamte Risikobegegnungszeit 15 Minuten oder länger ist.
Diese Benachrichtigung erfolgt in der CWA und gibt der Person zugleich Handlungsempfehlungen für das weitere Vorgehen.
Bei der Bewertung der von der CWA ermittelten Zeiten und Entfernungen muss berücksichtigt werden, dass beide Parameter nicht exakt gemessen werden können. Die einzelnen gemessenen Zeiten können bis zu 5 Minuten in beide Richtungen abweichen und die ermittelten Entfernungen sind Näherungswerte unter Idealbedingungen, d.h., wenn z.B. keine Hindernisse zwischen den beiden Smartphones sind. Schon bei kleineren Hindernissen, z.B. einer Person zwischen den beiden Smartphones oder wenn das Smartphone abgeschirmt verstaut ist, kann die Entfernung doppelt so groß erscheinen wie sie wirklich ist.
Bei der Bewertung der von der CWA ermittelten Zeiten und Entfernungen muss berücksichtigt werden, dass beide Parameter nicht exakt gemessen werden können.
Die einzelnen gemessenen Zeiten können bis zu 5 Minuten in beide Richtungen abweichen und die ermittelten Entfernungen sind Näherungswerte unter Idealbedingungen, d.h., wenn z.B. keine Hindernisse zwischen den beiden Smartphones sind.
Schon bei kleineren Hindernissen, z.B. einer Person zwischen den beiden Smartphones oder wenn das Smartphone abgeschirmt verstaut ist, kann die Entfernung doppelt so groß erscheinen wie sie wirklich ist.
Aufgrund von Datenschutzerwägungen können die oben beschriebenen Eigenschaften an der Schnittstelle zum Betriebssystem vorerst nur für die Gesamtheit aller Risikobegegnungen abgefragt werden, nicht aber für einzelne Risikobegegnungen oder tageweise. Solange die Anzahl neuer Fälle vergleichsweise gering bleibt, dürfte das keinen großen Unterschied machen, da vermutlich nur wenige die CWA nutzende Personen im Zeitraum vor ihrer Benachrichtigung Risikobegegnungen mit mehreren positiv getesteten Personen haben, die die CWA nutzen.
Aufgrund von Datenschutzerwägungen können die oben beschriebenen Eigenschaften an der Schnittstelle zum Betriebssystem vorerst nur für die Gesamtheit aller Risikobegegnungen abgefragt werden, nicht aber für einzelne Risikobegegnungen oder tageweise.
Solange die Anzahl neuer Fälle vergleichsweise gering bleibt, dürfte das keinen großen Unterschied machen, da vermutlich nur wenige die CWA nutzende Personen im Zeitraum vor ihrer Benachrichtigung Risikobegegnungen mit mehreren positiv getesteten Personen haben, die die CWA nutzen.
## Ein Beispiel
Anton und Aisha werden am 20. eines Monats über ihr jeweils Corona-positives Testergebnis informiert.
Anton erlaubt noch am selben Tag seiner CWA, andere die CWA nutzende Personen, mit denen er Risikobegegnungen hatte, darüber zu informieren.
Er hat die CWA auf seinem Smartphone seit einer Woche durchgehend aktiviert.
Die CWA lädt nun seine zufälligen Geräteschlüssel der letzten 7 Tage (mehr sind nicht verfügbar, da Anton die CWA erst 8 Tage im Einsatz hat und der aktuelle Geräteschlüssel noch nicht hochgeladen werden kann) als Positivkennungen auf den CWA-Server hoch.
Sie werden mit den Übertragungsrisikograden VI (für den Vortag), dreimal VIII (für den 16. bis 18.), V, III und I (rückwärts für die anderen vorausgegangenen Tage, 13. bis 15.) versehen.
|||||||||
|-|:-:|:-:|:-:|:-:|:-:|:-:|:-:|
|Übertragungsrisikograd|VI|VIII|VIII|VIII|V|III|I|
|Abstand zum Tag der Upload-Zustimmung|1|2|3|4|5|6|7|
|Erzeugungsdatum des Schlüssels|19.|18.|17.|16.|15.|14.|13.|
Tabelle 1: Übertragungsrisikograd für Antons 7 geteilte Positivkennungen, basierend auf dem Abstand zum Tag der Upload-Zustimmung (20.)
Aisha zögert noch einen Tag und gibt ihre Zustimmung erst am 21. des Monats.
Da sie ihre CWA schon vor mehreren Wochen aktiviert hatte und seitdem durchgehend im Hintergrund laufen hatte, stehen ihre zufälligen Geräteschlüssel der letzten 14 Tage zum Hochladen zur Verfügung.
Auch ihren Positivkennungen werden die Übertragungsrisikograde VI, dreimal VIII, V, III und I rückwärts für die 7 vorausgegangenen Tage vergeben, allerdings beginnend mit dem 20. und damit einen Tag gegenüber Anton versetzt.
(Dass beide am selben Tag über ihr Testergebnis informiert wurden, weiß die CWA nicht. In der aktuellen Version steht ihr nur das Datum der Zustimmung zum Hochladen für die Ermittlung des tagesspezifischen Übertragungsrisikograds zur Verfügung.)
Für die 7 noch weiter zurückliegenden Tage, den Zeitraum vom 7. bis zum 13. des Monats, wird jeweils der Übertragungsrisikograd I vergeben.
||||||||||||||||
|-|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|
|Übertragungsrisikograd|VI|VIII|VIII|VIII|V|III|I|I|I|I|I|I|I|I|
|Abstand zum Tag der Upload-Zustimmung|1|2|3|4|5|6|7|8|9|10|11|12|13|14|
|Erzeugungsdatum des Schlüssels|20.|19.|18.|17.|16.|15.|14.|13.|12.|11.|10.|9.|8.|7.|
Tabelle 2: Übertragungsrisikograd für Aishas 14 geteilte Positivkennungen, basierend auf dem Abstand zum Tag der Upload-Zustimmung (21.)
Anton und Aisha fahren regelmäßig zusammen zur Arbeit.
Betty hat denselben Arbeitsweg und sitzt gelegentlich im selben Bus.
Alle drei beschäftigen sich während der Fahrt mit ihren Smartphones, so dass den Bluetooth-Signalen keine Hindernisse im Weg sind.
Betty hat Anton und Aisha am 9. und am 16. morgens und abends für jeweils 10 Minuten getroffen.
Anton saß dabei einen Meter von ihr entfernt und Aisha zwei.
Als Bettys CWA am 21. Antons Positivkennungen abruft und an die Schnittstelle des Betriebssystems ihres Smartphones übergibt, wird eine Begegnungsmenge für den 16. erkannt.
(Für den 9. hat Antons CWA keine Positivkennung hochgeladen.)
Diese Begegnungsmenge hat insgesamt 20 Minuten gedauert und die Smartphones waren im Durchschnitt einen Meter voneinander entfernt.
Daraus ergeben sich Werte von jeweils 1 für die Dauer und die Dämpfung (s.a. "Konfiguration von Begegnungen" im Abschnitt "Aktuelle Konfiguration").
Damit ist sichergestellt, dass diese Begegnungsmenge nicht verworfen wird.
Der Wert des Parameters für das Verzugsrisiko (21 - 16 = 5 Tage) ist durchgehend mit 5 konfiguriert und der Wert des Parameters für das Übertragungsrisiko wird eins-zu-eins vom Übertragungsrisikograd übernommen, beträgt also 8.
Das Begegnungsrisiko errechnet sich damit als 1 x 1 x 5 x 8 = 40, was übrigens der höchste mit der aktuellen Konfiguration erreichbare Wert ist.
Der Grenzwert von 11 wird überschritten, womit die Begegnungsmenge als Risikobegegnung zählt.
| | | | | | | | | |
|-|-|-|-|-|-|-|-|-|
|Verzugsrisiko| >=14d (5) | 12-13d (5) | 10-11d (5) | 8-9d (5) | 6-7d (5) | **4-5d (5)** | 2-3d (5) | 0-1d (5) |
|Dämpfung| >73dB (0) | >63-<=73dB (1) | >51-<=63dB (1) | **>33-<=51dB (1)** | >27-<=33dB (1) | >15-<=27dB (1) | >10-<=15dB (1) | <=10dB (1) |
|Dauer| 0min (0) | >0-<=5min (0) | >5-<=10min (0) | >10-<=15min (1) | **>15-<=20min (1)** | >20-<=25min (1) | >25-<=30min (1) | >30min (1) |
|Übertragungsrisiko| I (1) | II (2) | III (3) | IV (4) | V (5) | VI (6) | VII (7) | **VIII (8)** |
Tabelle 3: Parameterwerte für Bettys Begegnungsmenge mit Anton am 16.
Da diese Risikobegegnung zugleich die einzige Risikobegegnung ist, die Bettys CWA bekannt ist, wird auch nur sie bei der summarischen Auswertung ihrer Aufenthaltszeiten in den Entfernungsräumen bis 1,5 Meter und bis 3 Meter berücksichtigt.
Betty hielt sich 20 Minuten im Entfernungsraum unter 1,5 Meter auf, die zur Gänze gezählt werden.
Auch bei der Verrechnung dieser 20 Minuten mit dem Begegnungsrisiko der Risikobegegnung mit dem höchsten Risiko kann wieder nur diese eine Risikobegegnung mit ihrem Begegnungsrisiko von 40 berücksichtigt werden.
Die Multiplikation der 20 Minuten mit 40/25 (25 ist der aktuell konfigurierte Wert für "durchschnittlich riskante" Risikobegegnungen; s.a. *risk-score-normalization-divisor* in "Konfiguration von Dämpfung & Dauer" im Abschnitt "Aktuelle Konfiguration") ergibt 32 Minuten.
Da die CWA ab 15 Minuten über ein erhöhtes Risiko benachrichtigt, erhält Betty nun eine solche Benachrichtigung.
Zugleich wird ihr mitgeteilt, dass sie eine Risikobegegnung hatte und diese 5 Tage zurückliegt.
Am folgenden Tag, dem 22., ruft Bettys CWA auch Aishas Positivkennungen ab.
Sie erkennt zusätzliche Begegnungen am 16. und am 9. des Monats.
Beide Begegnungsmengen haben insgesamt jeweils 20 Minuten gedauert und die Smartphones waren im Durchschnitt zwei Meter voneinander entfernt.
Auch hieraus ergeben sich Werte von jeweils 1 für die Dauer und die Dämpfung.
Die Verzugsrisikowerte (22 - 16 = 6 Tage; 22 - 9 = 13 Tage) sind konstant 5 und die Übertragungsrisikowerte 5 für den 16. und 1 für den 9. des Monats.
Die Begegnungsrisiken berechnen sich für den 16. also als 1 x 1 x 5 x 5 = 25 und für den 9. als 1 x 1 x 5 x 1 = 5.
Die Begegnungsmenge des 9. erreicht den Grenzwert nicht und zählt damit nicht als Risikobegegnung.
|| | | | | | | | |
|-|-|-|-|-|-|-|-|-|
|Verzugsrisiko| >=14d (5) | 12-13d (5) | 10-11d (5) | 8-9d (5) | **6-7d (5)** | 4-5d (5) | 2-3d (5) | 0-1d (5) |
|Dämpfung| >73dB (0) | >63-<=73dB (1) | **>51-<=63dB (1)** | >33-<=51dB (1) | >27-<=33dB (1) | >15-<=27dB (1) | >10-<=15dB (1) | <=10dB (1) |
|Dauer| 0min (0) | >0-<=5min (0) | >5-<=10min (0) | >10-<=15min (1) | **>15-<=20min (1)** | >20-<=25min (1) | >25-<=30min (1) | >30min (1) |
|Übertragungsrisiko| I (1) | II (2) | III (3) | IV (4) | **V (5)** | VI (6) | VII (7) | VIII (8) |
Tabelle 4: Parameterwerte für Bettys Begegnungsmenge mit Aisha am 16.
|| | | | | | | | |
|-|-|-|-|-|-|-|-|-|
|Verzugsrisiko| >=14d (5) | **12-13d (5)** | 10-11d (5) | 8-9d (5) | 6-7d (5) | 4-5d (5) | 2-3d (5) | 0-1d (5) |
|Dämpfung| >73dB (0) | >63-<=73dB (1) | **>51-<=63dB (1)** | >33-<=51dB (1) | >27-<=33dB (1) | >15-<=27dB (1) | >10-<=15dB (1) | <=10dB (1) |
|Dauer| 0min (0) | >0-<=5min (0) | >5-<=10min (0) | >10-<=15min (1) | **>15-<=20min (1)** | >20-<=25min (1) | >25-<=30min (1) | >30min (1) |
|Übertragungsrisiko| **I (1)** | II (2) | III (3) | IV (4) | V (5) | VI (6) | VII (7) | VIII (8) |
Tabelle 5: Parameterwerte für Bettys Begegnungsmenge mit Aisha am 9.
Die Risikobegegnung des 16. wird hingegen bei der aktualisierten summarischen Auswertung mit berücksichtigt, so dass Bettys CWA nun 20 Minuten (mit Anton) im Entfernungsraum bis 1,5 Metern ganz und weitere 20 Minuten (mit Aisha) im Entfernungsraum bis 3 Meter zur Hälfte (also als 10 Minuten) zählt.
Die so ermittelten 30 Minuten werden wieder mit Bettys Risikobegegnung mit Anton verrechnet, die mit 40 nach wie vor das höchste Begegnungsrisiko aller erkannten Risikobegegnungen des aufgezeichneten 14-Tage-Zeitraums hat, so dass sich 30 x 40/25 = 48 Minuten ergeben.
Bettys aktualisierte Risikobenachrichtigung zeigt jetzt 2 Risikobegegnungen an, von denen die letzte 6 Tage zurückliegt.
## Aktuelle Konfiguration
Wie im [Abschnitt "*Risk Score Calculation*"](https://github.com/corona-warn-app/cwa-documentation/blob/master/solution_architecture.md#risk-score-calculation) des *Solution-Architecture*-Dokuments beschrieben, werden die jeweiligen Parameter für die Berechnung aus von einer Menge an Parametern bestimmt, die vom CWA-Server zur Verfügung gestellt werden.
Diese Konfiguration kann sich über die Zeit auf Basis neuer Forschungsergebnisse und Erkentnisse ändern.
Die jeweils aktuell gültigen Parameterwerte können im [*CWA-Server-Repository*](https://github.com/corona-warn-app/cwa-server) eingesehen werden:
- [Konfiguration von Begegnungen](https://github.com/corona-warn-app/cwa-server/blob/master/services/distribution/src/main/resources/master-config/exposure-config.yaml)
- [Konfiguration von Dämpfung & Dauer](https://github.com/corona-warn-app/cwa-server/blob/master/services/distribution/src/main/resources/master-config/attenuation-duration.yaml)
- [App-Konfiguration, inkl. des minimalen Risikowerts](https://github.com/corona-warn-app/cwa-server/blob/master/services/distribution/src/main/resources/master-config/app-config.yaml)
- [Risikowertklassifizierung](https://github.com/corona-warn-app/cwa-server/blob/master/services/distribution/src/main/resources/master-config/risk-score-classification.yaml)

15
translations/pruefsteine.de.md
View File

@ -22,17 +22,17 @@ Selbst wenn der zentrale Corona-Warn-App-Server kompromittiert sein sollte, kön
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:
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
* 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).
* [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.
@ -64,7 +64,6 @@ Temporary Exposure Keys (TEK) werden täglich neu und ausschließlich auf dem Ge
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.

79
translations/scoping_document.de.md
View File

@ -1,25 +1,27 @@
# INHALTSVERZEICHNIS
1. [EINLEITUNG](#einleitung)
2. [USER JOURNEY](#user-journey)
1. [Beschreibung der Nutzungsprofile (Stakeholder)](#beschreibung-der-nutzungsprofile-stakeholder)
2. [User Journey](#user-journey-1)
3. [FUNKTIONSBESCHREIBUNG](#funktionsbeschreibung)
1. [Übersicht der Epics](#übersicht-der-epics)
2. [Übersicht der User Stories](#übersicht-der-user-stories)
1. [Anbahnung und Installation (Onboarding-Prozess)](#anbahnung-und-installation-onboarding-prozess)
2. [Informationen und Instruktionen zur Nutzung der App](#informationen-und-instruktionen-zur-nutzung-der-app)
3. [Nutzung im Regelprozess](#nutzung-im-regelprozess)
4. [Kontaktfall (Begegnung mit infizierter Person)](#kontaktfall-begegnung-mit-infizierter-person)
5. [Covid-19-Testergebnismeldung](#covid-19-testergebnismeldung)
6. [Auslösen einer Warnung](#auslösen-einer-warnung)
7. [Parametrisierung](#parametrisierung)
8. [Technische Unterstützung](#technische-unterstützung)
9. [Barrierefreiheit](#barrierefreiheit)
10. [Content Management](#content-management)
HINWEIS: Dieses Scoping-Dokument ist auch [auf Englisch](../scoping_document.md) verfügbar.
1. [EINLEITUNG](#einleitung)
2. [USER JOURNEY](#user-journey)
1. [Beschreibung der Nutzungsprofile (Stakeholder)](#beschreibung-der-nutzungsprofile-stakeholder)
2. [User Journey](#user-journey-1)
3. [FUNKTIONSBESCHREIBUNG](#funktionsbeschreibung)
1. [Übersicht der Epics](#übersicht-der-epics)
2. [Übersicht der User Stories](#übersicht-der-user-stories)
1. [Anbahnung und Installation (Onboarding-Prozess)](#anbahnung-und-installation-onboarding-prozess)
2. [Informationen und Instruktionen zur Nutzung der App](#informationen-und-instruktionen-zur-nutzung-der-app)
3. [Nutzung im Regelprozess](#nutzung-im-regelprozess)
4. [Kontaktfall (Begegnung mit infizierter Person)](#kontaktfall-begegnung-mit-infizierter-person)
5. [Covid-19-Testergebnismeldung](#covid-19-testergebnismeldung)
6. [Auslösen einer Warnung](#auslösen-einer-warnung)
7. [Parametrisierung](#parametrisierung)
8. [Technische Unterstützung](#technische-unterstützung)
9. [Barrierefreiheit](#barrierefreiheit)
10. [Content Management](#content-management)
HINWEIS: Dieses Scoping-Dokument ist auch [auf Englisch](../scoping_document.md) verfügbar.
## EINLEITUNG
# EINLEITUNG
Ziel der Corona-Warn-App ist es, SARS-CoV-2-Infektionsketten schnellstmöglich zu erkennen und zu durchbrechen. Personen sollen zuverlässig und schnell über Begegnungen mit anderen infizierten Personen und damit mögliche Übertragungen des Virus informiert werden, damit sie sich freiwillig isolieren können, um damit zu einer Eindämmung der SARS-CoV-2-Pandemie beizutragen.
Dieses Dokument beschreibt die funktionalen Anforderungen an die Gestaltung der App aus einer fachlichen und prozessualen Sicht. Die Beschreibung ist in der aktuellen Version inhaltlich auf das erste Release begrenzt und eine initiale Version.
@ -30,33 +32,41 @@ Die Definition und Gliederung der Anforderungen folgen einer personenzentrierten
Anhand einer User Journey (Nutzungsreise) sind die Interaktionspunkte und das Erlebnis während der Nutzung aufgezeigt. Die daraus entstehenden Anforderungen werden sogenannten Epics (Beschreibung einer Anforderung auf einer hohen Abstraktionsebene) zugeordnet. Die Epics beschreiben die einzelnen Kontakt-Ereignisse sowie übergreifende Funktionalitäten im gesamten Prozess, die für die Nutzung und Akzeptanz der App erforderlich sind. Aus den Epics heraus werden die detaillierten Anforderungen in Form sogenannter User Stories (eine in Alltagssprache formulierte Software-Anforderung) abgeleitet. Die einzelnen Anforderungen werden so strukturiert in den Entwicklungsprozess gebracht.
# USER JOURNEY
## USER JOURNEY
### Beschreibung der Nutzungsprofile (Stakeholder)
## Beschreibung der Nutzungsprofile (Stakeholder)
Folgende wesentliche Nutzungsprofile bzw. Stakeholder sind in die User Journey bzw. in den Gesamtprozess eingebunden und in ihrer Rolle beschrieben:
#### App-Bedienung
Alle Personen, welche die App benutzen: Werden über mögliche Begegnungen mit infizierten Personen informiert, verifizieren eigene Testergebnisse bzw. warnen dann alle Personen, denen sie begegnet sind, freiwillig und pseudonym.
#### Hotlines
Unterstützen Personen bei der Bedienung der App in der Beantwortung von Fragestellungen zur Nutzung der App, zur Technik sowie zum Datenschutz und geben auf Nachfrage verhaltensbezogene Informationen sowie weitere Informationsmöglichkeiten im Kontakt- bzw. Infektionsfall weiter.
Unterstützen bei Verifikation und Freischaltung von Testergebnissen in der App für infizierte Personen und können diesen die Kontaktaufnahme mit dem zuständigen Gesundheitsamt empfehlen.
#### Robert Koch-Institut (RKI)
Stellt epidemiologische Informationen und Handlungsempfehlungen für die Bedienung der App zur Verfügung (Content). Bestimmt die Parameter für die Messung der Kontakte (im Rahmen der technischen Möglichkeiten durch die API).
 
## User Journey
### User Journey
Die Nutzung der App wird aufgrund von nacheinander stattfindenden Kontakt-Ereignissen und Interaktionen von Personen in verschiedene Phasen eingeteilt. Zu jeder Phase sind den Personen Motivationen oder Anforderungen zugeordnet, die ihre Erwartungen an die Funktionsweise erfüllen und intuitiv durch den Prozess leiten.
![Abbildung 1: User Journey](user_journey.de.png "User Journey")
#### Phase *Idee*
In dieser Phase entscheidet eine Person, sich über die App zu informieren. Das kann über unterschiedliche Quellen erfolgen. In dieser Phase haben die Personen ggf. verschiedene Fragestellungen zur Nutzung der App (Anwendung, Datenschutz, Barrierefreiheit etc.). Diese sollen bereits vor dem Download beantwortet werden können (Hotline, Informationen auf Internetseiten des RKI und des BMG, App Store/Google Play Store).
#### Phase *Installation*
Eine Person entscheidet sich zum Download der App (App Store/Google Play Store) und wird nach der technischen Installation beim erstmaligen Öffnen der App durch eine Einführung begleitet. In der Einführungsphase erhält die Person eine Übersicht über die Funktionsweise, Nutzungsbedingungen und Datenschutzbestimmungen sowie erforderliche Einwilligungen, Einstellungen und Benachrichtigungen.
#### Phase *Anwendung*
Die Phase der Anwendung ist in vier weitere Bereiche unterteilt, in welchen die Person unterschiedliche Bedürfnisse hat.
1. **Hintergrund**
@ -76,14 +86,17 @@ Die Phase der Anwendung ist in vier weitere Bereiche unterteilt, in welchen die
Im Fall eines positiven SARS-CoV-2-Befunds kann eine Person freiwillig die in der App gespeicherten eigenen pseudonymen Warn-IDs veröffentlichen, damit andere Personen, die die App nutzen, auf ihrem eigenen Smartphone abgleichen können, ob sie mit der infizierten Person in Kontakt standen.
#### Phase *Deinstallation*
Eine Person kann die App jederzeit deinstallieren. Alle in der App gespeicherten Daten werden vollständig gelöscht.
# FUNKTIONSBESCHREIBUNG
## FUNKTIONSBESCHREIBUNG
### Übersicht der Epics
## Übersicht der Epics
Die Funktionen der App sind in Prozessphasen der Nutzung (mit direktem Bezug zur User Journey) und übergreifende Unterstützungsprozesse unterteilt. Eine Übersicht der Epics ist nachfolgend dargestellt:
#### Prozessphasen der Nutzung
| # | Epic | Beschreibung |
|---:|--------|--------------|
| 1 | Anbahnung und Installation (Onboarding-Prozess) | Sämtliche Prozesse, die insbesondere bei erstmaliger Nutzung der App erfolgen (z.B. Zustimmung Datenschutz, Sprachauswahl)
@ -94,6 +107,7 @@ Die Funktionen der App sind in Prozessphasen der Nutzung (mit direktem Bezug zur
| 6 | Auslösung einer Warnung | Prozess zur Auslösung einer Warnung im Falle eines positiven Testergebnisses
#### Supportprozesse
| # | Epic | Beschreibung |
|---:|--------|--------------|
| 7 | Parametrisierung | Parameter der Kontaktpunktdefinition
@ -102,13 +116,15 @@ Die Funktionen der App sind in Prozessphasen der Nutzung (mit direktem Bezug zur
| 10 | Content-Management | Zur Anpassung und Aktualisierung von Inhalten in der App (Texte, Links, Hotlines etc.)
## Übersicht der User Stories
Die Anforderungen an die Corona-Warn-App, die den fachlichen Umfang der Anwendung definieren, sind nachfolgend in der üblichen Form aus Sicht der nutzenden Personen formuliert, sofern nicht anders angegeben:
_„Als &lt;Stakeholder&gt; möchte ich &lt;Handlung durchführen&gt;, um &lt;gewünschtes Ergebnis zu erzielen&gt;.“_
„Als &lt;Stakeholder&gt; möchte ich &lt;Handlung durchführen&gt;, um &lt;gewünschtes Ergebnis zu erzielen&gt;.“
Die zugehörigen Akzeptanzkriterien ergänzen die Spezifikation der Anforderungen, indem sie Bedingungen definieren, die die Software erfüllen muss, um die Bedürfnisse der nutzenden Personen zu befriedigen.
### Anbahnung und Installation (Onboarding-Prozess)
| # User Story ID | User Story | Akzeptanzkriterien |
|-----------------|------------|--------------------|
| E01.01 | Als Person, die die App nutzt, möchte ich beim erstmaligen Start der App eine Einleitung zur Funktionsweise der App erhalten (App-Motivation). | 1. Einführung in die Funktionsweise der App wird bei erstmaligem Start der App angezeigt. <hr/> 2. Einführung in die Funktionsweise der App wird bei weiteren Startvorgängen nicht angezeigt. <hr/> 3. Die erklärenden Inhalte sind in den jeweiligen Funktionsbereichen zur Nutzung vorhanden.
@ -120,6 +136,7 @@ Die zugehörigen Akzeptanzkriterien ergänzen die Spezifikation der Anforderunge
| E01.07 | Als Person, die die App nutzt, möchte ich bereits während des Onboardings Hilfen und Einstellungen zur Barrierefreiheit bekommen, um die App nutzen zu können. | 1. Die Barrierefreiheit wird im Rahmen der Möglichkeiten der Version des jeweils hinterlegten Betriebssystems genutzt.
### Informationen und Instruktionen zur Nutzung der App
| # User Story ID | User Story | Akzeptanzkriterien |
|-----------------|------------|--------------------|
| E02.01 | Als Person, die die App nutzt, möchte ich Zugriff auf eine FAQ-Liste haben, um mir bei Fragen zur App selbst weiterhelfen zu können. | 1. Es wird entweder ein Link auf eine Internetseite mit FAQs zur Verfügung gestellt, oder die Internetseite wird integriert innerhalb der App dargestellt.
@ -130,6 +147,7 @@ Die zugehörigen Akzeptanzkriterien ergänzen die Spezifikation der Anforderunge
| E02.06 | Als Person, die die App nutzt, möchte ich die verschiedenen Hotlines zu technischen, datenschutzbezogenen, gesundheitsbezogenen und psychologischen Fragestellungen sowie zur Verifikation eines Testergebnisses angezeigt bekommen, damit ich weitere Informationen oder Antworten auf Fragen erhalte. | 1. Die App bietet einen Zugriff auf eine technische Hotline und eine Hotline zur Erlangung einer Telefon-TAN. <hr/> 2. Die zeitliche Erreichbarkeit der Hotlines (z.B. 24/7) wird angezeigt. <hr/> 3. Telefonnummern können direkt aus der App gewählt werden.
### Nutzung im Regelprozess
| # User Story ID | User Story | Akzeptanzkriterien |
|-----------------|------------|--------------------|
| E03.01 | Als Person, die die App nutzt, möchte ich die App aktivieren und deaktivieren können, um die Funktion ein- und auszuschalten. | 1. Die Funktionalität zur Erstellung pseudonymer IDs und deren Aussendung an Geräte in der Nähe kann ein- und ausgeschaltet werden. <hr/> 2. Die Konsequenzen des Ein-/Ausschaltens werden erklärt.
@ -137,18 +155,21 @@ Die zugehörigen Akzeptanzkriterien ergänzen die Spezifikation der Anforderunge
| E03.03 | Als Person, die die App nutzt, möchte ich die App-Einstellungen (Zugriffsrechte, z.B. Benachrichtigungen) in einem Menü anpassen können, um Funktion und Zugriffe der App verwalten zu können. | 1. Ein Menü zu App-Einstellungen kann durch die nutzende Person aufgerufen werden. <hr/> 2. Die Benachrichtigungen können ein- und ausgeschaltet werden. <hr/> 3. Der Zugriff auf die Funktionalität zur Erstellung pseudonymer IDs und deren Aussendung an Geräte in der Nähe kann ein- und ausgeschaltet werden. <hr/> 4. Vor der Deaktivierung der Zugriffsrechte erhalte ich Informationen darüber, welche Funktionen der App dadurch nicht mehr (vollumfänglich) funktionieren.
### Kontaktfall (Begegnung mit infizierter Person)
| # User Story ID | User Story | Akzeptanzkriterien |
|-----------------|------------|--------------------|
| E04.01 | Als Person, die die App nutzt, möchte ich informiert werden, wenn eine Person, zu der ich Kontakt hatte, sich als infiziert gemeldet hat. Damit kann ich geeignete Maßnahmen treffen, um die Verbreitung des Virus zu stoppen. | 1. In Abhängigkeit der Benachrichtigungseinstellung schickt die App eine Benachrichtigung an die nutzende Person.<hr/> 2. Bei einer Änderung der Risikoeinschätzung für die nutzende Person informiert die Benachrichtigung die nutzende Person über Neuigkeiten in der App. Die tatsächlich geänderte Risikoeinschätzung wird erst innerhalb der App angezeigt.
| E04.01 | Als Person, die die App nutzt, möchte ich informiert werden, wenn eine Person, zu der ich Kontakt hatte, sich als infiziert gemeldet hat. Damit kann ich geeignete Maßnahmen treffen, um die Verbreitung des Virus zu stoppen. | 1. In Abhängigkeit der Benachrichtigungseinstellung schickt die App eine Benachrichtigung an die nutzende Person.<hr/> 2. Bei einer Änderung der Risikoeinschätzung für die nutzende Person informiert die Benachrichtigung die nutzende Person über Neuigkeiten in der App. Die tatsächlich geänderte Risikoeinschätzung wird erst innerhalb der App angezeigt.
| E04.02 | Als Person, die die App nutzt, möchte ich im Kontaktfall Handlungsanweisungen durch die App bekommen, um mein Verhalten an die Empfehlungen des RKI anzupassen. | 1. Die Benachrichtigung führt die nutzende Person zur App. Handlungsempfehlungen des RKI sind in der App statisch hinterlegt.
### Covid-19-Testergebnismeldung
| # User Story ID | User Story | Akzeptanzkriterien |
|-----------------|------------|--------------------|
| E05.01 | Als RKI möchte ich, dass ausschließlich positiv getestete Personen einmalig eine Warnung auslösen können, um Missbrauch zu vermeiden. | 1. Nur positive Tests können eine Warnung auslösen. Der Verifikationsserver und die Hotline zum Telefon-TAN-Verfahren stellen dies sicher. <hr/> 2. Für jeden Test kann nur einmal eine Warnung ausgelöst werden.
| E05.02 | Als Person, die die App nutzt, möchte ich im Falle eines positiven Testergebnisses Informationen über die Erkrankung und nötige nächste Schritte bekommen, um mein Verhalten an die Handlungsempfehlungen des RKI anpassen zu können. | 1. Eine Benachrichtigung informiert lediglich über Neuigkeiten in der App. Das Testergebnis selbst kann nur in der App eingesehen werden. <hr/> 2. In der App wird ein Infotext mit definiertem Inhalt angezeigt (z.B. Informationen zum Ausgang des Testergebnisses, Informationen über erforderliche Maßnahmen, eine Hotline-Nummer).
### Auslösen einer Warnung
| # User Story ID | User Story | Akzeptanzkriterien |
|-----------------|------------|--------------------|
| E06.01 | Als Person, die die App nutzt, möchte ich einen vom medizinischen Fachpersonal oder Test-Center ausgehändigten QR-Code scannen können, damit mir später das Testergebnis in der Corona-Warn-App zur Verfügung gestellt werden kann. | 1. Ein auf dem Flyer des medizinischen Fachpersonals oder Test-Centers vorhandener QR-Code kann mit der Warn-App gescannt werden. <hr/> 2. Erklärungstext wird angezeigt.
@ -159,16 +180,19 @@ Die zugehörigen Akzeptanzkriterien ergänzen die Spezifikation der Anforderunge
| E06.06 | Als Person, die die App nutzt, möchte ich, dass ich nach der Verifikation der TAN meine pseudonymen IDs freiwillig teilen und etwaige Kontaktpersonen warnen kann. | 1. IDs können pseudonymisiert an den Warn-Server übermittelt werden. <hr/> 2. Die Übermittlung ist nur möglich, sofern zuvor eine Verifikation erfolgreich durchgeführt wurde. Der Verifikationsserver und die Hotline zum Telefon-TAN Verfahren stellen dies sicher. <hr/> 3. Die Übermittlung ist nur möglich, sofern die Person vorher zugestimmt hat.
### Parametrisierung
| # User Story ID | User Story | Akzeptanzkriterien |
|-----------------|------------|--------------------|
| E07.01 | Als RKI möchte ich die Parameter zur Risiko-Score-Bestimmung (im Rahmen der technischen Möglichkeiten durch die API) einstellen können, um stets den aktuellen Forschungsergebnissen zur Virusübertragung Rechnung zu tragen. | 1. In Abhängigkeit von der bereitgestellten API können Schwellenwerte konfiguriert werden. <hr/> 2. Die App bezieht dynamische Konfigurationen des RKI, die die Berechnung der Risiko-Einstufung beeinflussen können.
### Technische Unterstützung
| # User Story ID | User Story | Akzeptanzkriterien |
|-----------------|------------|--------------------|
| E08.01 | Als Person, die die App nutzt, möchte ich eine Hotline kontaktieren können, um technische Probleme mit der App zu lösen. | 1. Die Telefonnummer der technischen Hotline ist in der App hinterlegt.
### Barrierefreiheit
| # User Story ID | User Story | Akzeptanzkriterien |
|-----------------|------------|--------------------|
| E09.01 | Als Person, die die App nutzt, möchte ich eine Sprachausgabe nutzen können, um die App (z.B. bei fehlendem oder eingeschränktem Sehvermögen) nutzen zu können. | 1. Die Barrierefreiheit bzgl. Sprachausgabe wird im Rahmen der Möglichkeiten der Version des jeweils hinterlegten Betriebssystems verfügbar gemacht.
@ -176,6 +200,7 @@ Die zugehörigen Akzeptanzkriterien ergänzen die Spezifikation der Anforderunge
| E09.03 | Als Person, die die App nutzt, möchte ich, dass mir die Inhalte in einfacher Sprache zur Verfügung gestellt werden, damit ich leicht verstehe, wie ich die App nutzen kann und warum ich es tun sollte. | 1. Die Texte und Sprachen werden vom Auftraggeber definiert.
### Content Management
| # User Story ID | User Story | Akzeptanzkriterien |
|-----------------|------------|--------------------|
| E10.01 | Als RKI möchte ich die Inhalte der App zentral verwalten, um Aktualisierungen von Texten, Links, Hotlines etc. einmalig für alle Stellen in der App durchführen zu können. | 1. Das Content-Management erfolgt auf Grundlage der Anforderungen des RKI <hr/> 2. Der Content wird auf statische und dynamische Inhalte entsprechend der technischen Machbarkeit differenziert <hr/> 3. Aktualisierungen erfolgen in der ersten Version über ein App-Update.