covid19/cwa-documentation
covid19/cwa-documentation
1
0
Fork 0
mirror of https://github.com/corona-warn-app/cwa-documentation synced 2024-11-24 10:14:27 +01:00
Code Releases Activity

Linted all MD files, enabled MD linter for each commit

Browse Source
This commit is contained in:
Sebastian Wolf 2020-07-14 15:19:00 +02:00
parent 6ef01d9ee4
commit ec703906c1
No known key found for this signature in database
GPG Key ID: B53C9059C9EEFDC8
20 changed files with 588 additions and 481 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
.github/workflows/checks.yml vendored
View File

@ -19,10 +19,10 @@ jobs:
run: |
npm install
#- name: Linting markdown
# if: always()
# run: |
# npm run-script markdownlint
- name: Linting markdown
if: always()
run: |
npm run-script markdownlint
- name: Checking for broken links
if: always()

8
.markdownlint.json
View File

@ -1,6 +1,10 @@
{
"default": true,
"MD013": false,
"MD026": false,
"MD024": {
"allow_different_nesting": true
},
"MD033": {
"allowed_elements": [
"a",
@ -9,6 +13,7 @@
"code",
"em",
"hr",
"img",
"li",
"ol",
"p",
@ -24,5 +29,6 @@
"ul"
]
},
"MD034": false
"MD034": false,
"MD036": false
}

24
.spelling
View File

@ -14,13 +14,13 @@ blacklist
broadcasted
Bundesbeauftragter
Bundesnetzagentur
Changelog
Changelogs
changelog
Changelog
changelogs
Changelogs
Checkmarx
Commonmark
commonmark
Commonmark
config
Config
coronavirus
@ -33,8 +33,8 @@ cwa-verification-iam
cwa-verification-portal
cwa-verification-server
CxSAST
Cyber
cyber
Cyber
DDoS
deanonymize
Deutsche
@ -55,21 +55,21 @@ Informationsfreiheit
Infrastrukturen
iOS
Kritische
lifecycle
Lifecycle
linter
linters
Lifecycle
lifecycle
logfile
logfiles
macOS
markdownlint.json
Metadata
metadata
Metadata
misconfiguration
natively
npm
Onboarding
onboarding
Onboarding
package.json
PEPP-PT
PostgreSQL
@ -96,24 +96,24 @@ TalkBack
TEK
TEKs
Telekom
TeleTAN
TeleTANs
teleTAN
TeleTAN
teleTANs
TeleTANs
timeframe
timestamp
timestamping
Timestamping
tl;dr
tl
tl;dr
Tx
UI
uninstallation
Uninstallation
unlinkability
Unlinkability
Unobservability
unobservability
Unobservability
unsecure
up-to-dateness
useable

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.

23
INSTALL.md
View File

@ -57,6 +57,7 @@ Every individual check can be run like so:
```shell
npm runscript my-individual-check
```
See the package.json file for help.
#### Markdown linter
@ -67,7 +68,7 @@ Markdown linting. See the rules [here](https://github.com/DavidAnson/markdownlin
npm run-script markdownlint
```
##### Overrides
##### Markdown linter overrides
Sometimes it is not possible to be commonmark conform. In this rare cases an inline tag to skip linting is possible.
@ -80,9 +81,11 @@ Candidates are tables.
<!-- 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.
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:
This is done with a .markdownlint.json override file which would look something
like this:
```json
{
@ -95,7 +98,8 @@ This is done with a .markdownlint.json override file which would look something
}
```
For more information how to tweak overrides consult the markdown linter documentation mentioned above.
For more information how to tweak overrides consult the markdown linter
documentation mentioned above.
#### Spell checker
@ -111,15 +115,17 @@ npm run-script spellcheck
Not implemented yet.
##### Overrides
##### 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.
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.
Please note sometimes overriding is not the way to go. Our terminology should be
applied consistently.
#### Link resolver
@ -131,7 +137,8 @@ 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)
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

36
README.md
View File

@ -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,31 +52,36 @@ 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/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)
- [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

1
backend-infrastructure-architecture.md
View File

@ -1,4 +1,5 @@
# 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.

1
cwa-risk-assessment.md
View File

@ -146,7 +146,6 @@ The calculated 30 minutes are once again cross-calculated with Betty’s risk ex
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.

3
cwa-versioning.md
View File

@ -1,4 +1,5 @@
# Versioning
All components of the Corona Warn App use [Semantic versioning](https://semver.org/).
Given a version number MAJOR.MINOR.PATCH, increment the:
@ -16,6 +17,6 @@ Backend components will always remain compatible due to ongoing the availability
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
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).

577
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.
### 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.
### 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
- [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.
- [cwa-app-android](https://github.com/corona-warn-app/cwa-app-android)
- BlackDuck
- BlackDuck
- [cwa-app-ios](https://github.com/corona-warn-app/cwa-app-ios)
- BlackDuck
- BlackDuck
- [cwa-server](https://github.com/corona-warn-app/cwa-server)
- WhiteSource
- Synopsys Protecode
- Eclipse Steady (former SAP Vulas)
- WhiteSource
- Synopsys Protecode
- Eclipse Steady (former SAP Vulas)
- [cwa-testresult-server](https://github.com/corona-warn-app/cwa-testresult-server)
- OWASP Dependency Checker
- OWASP Dependency Checker
- [cwa-verification-iam](https://github.com/corona-warn-app/cwa-verification-iam)
- OWASP Dependency Checker
- OWASP Dependency Checker
- [cwa-verification-portal](https://github.com/corona-warn-app/cwa-verification-portal)
- OWASP Dependency Checker
- OWASP Dependency Checker
- [cwa-verification-server](https://github.com/corona-warn-app/cwa-verification-server)
- OWASP Dependency Checker
- 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,30 +306,43 @@ 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.
- 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.
- 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.
@ -313,19 +350,27 @@ The following chapters contain a brief introduction to each capability.
- 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.
- 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.
- Handle reported security incidents.
- Minimize the impact of security incidents.
@ -334,45 +379,61 @@ 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.
- 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.
- 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.
- 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.
#### 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
- 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.
@ -381,12 +442,16 @@ The following chapters contain a brief introduction to each capability.
- 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.
- 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.
#### 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.
#### 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).
- 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.
- 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
- 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.
- Adequately and timely communication with authorities and stakeholders is required.
#### Objective
- Improve customer relationship/satisfaction.
- 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).

4
package.json
View File

@ -1,7 +1,7 @@
{
"name": "docs",
"version": "1.0.0",
"description": "A central repository for documentation",
"description": "Corona-Warn-App: Documentation repository",
"main": "README.md",
"dependencies": {
"alex": "^8.1.1",
@ -13,7 +13,7 @@
},
"devDependencies": {},
"scripts": {
"test": "run-s markdownlint checklinks spellcheck format-spelling detect-inconsiderate-language",
"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",

8
pruefsteine.md
View File

@ -24,10 +24,10 @@ As mandated by the General Data Protection Regulation (GDPR), [data minimization
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:

2
scoping_document.md
View File

@ -185,7 +185,7 @@ 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;.“_
"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

60
solution_architecture.md
View File

@ -11,6 +11,7 @@ We assume a close association of a mobile phone and its user and, thus, equate t
![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,7 +27,6 @@ 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.
@ -42,6 +42,7 @@ 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.
@ -52,6 +53,7 @@ They only have to confirm in the app and for the Exposure Notification Framework
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).
@ -64,19 +66,19 @@ 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")
@ -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.
@ -141,13 +144,14 @@ Further information can be found in the dedicated architecture documents for the
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.
@ -171,7 +175,7 @@ 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://developers.google.com/android/exposure-notifications/exposure-notifications-api#architecture).
@ -186,16 +190,18 @@ 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

2
translations/LANGUAGE_STYLE.de.md
View File

@ -1,9 +1,11 @@
# 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 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"

14
translations/README.de.md
View File

@ -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)
- [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

9
translations/pruefsteine.de.md
View File

@ -24,10 +24,10 @@ Wie in der Datenschutz-Grundverordnung (DSGVO) vorgeschrieben, ist die [Datenmin
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:
@ -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.

75
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)
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.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.