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

Merge branch 'master' into dependabot/npm_and_yarn/path-parse-1.0.7

This commit is contained in:
Dipankar Sarkar 2021-11-08 15:32:22 +01:00
parent a6ecc70d60 183335d9ba
commit b43c9ece83
42 changed files with 213 additions and 3883 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
README.md
View File

@ -29,7 +29,7 @@ We are developing the official COVID-19 exposure notification app for Germany, c
## Who We Are
The German government has comissioned SAP and Deutsche Telekom to develop the Corona-Warn-App for Germany as open source software. Deutsche Telekom is providing the network and mobile technology and will operate and run the backend for the app in a safe, scalable and stable manner. SAP is responsible for the app development, its framework and the underlying platform. Therefore, development teams of SAP and Deutsche Telekom are contributing to this project. At the same time our commitment to open source means that we are enabling -in fact encouraging- all interested parties to contribute and become part of its developer community.
The German government has commissioned SAP and Deutsche Telekom to develop the Corona-Warn-App for Germany as open source software. Deutsche Telekom is providing the network and mobile technology and will operate and run the backend for the app in a safe, scalable and stable manner. SAP is responsible for the app development, its framework and the underlying platform. Therefore, development teams of SAP and Deutsche Telekom are contributing to this project. At the same time our commitment to open source means that we are enabling -in fact encouraging- all interested parties to contribute and become part of its developer community.
## Credits
@ -45,7 +45,7 @@ This project has adopted the [Contributor Covenant](https://www.contributor-cove
## Working Language
We are building this application for Germany. We want to be as open and transparent as possible, also to interested parties in the global developer community who do not speak German. Consequently, all content will be made available primarily in _English_. We also ask all interested people to use English as language to create issues, in their code (comments, documentation etc.) and when you send requests to us. The application itself, documentation and all end-user facing content will - of course - be made available in German (and probably other languages as well). We also try to make developer documentation available in German, but please understand that focussing on the _Lingua Franca_ of the global developer community makes the development of this application as efficient as possible.
We are building this application for Germany. We want to be as open and transparent as possible, also to interested parties in the global developer community who do not speak German. Consequently, all content will be made available primarily in _English_. We also ask all interested people to use English as language to create issues, in their code (comments, documentation etc.) and when you send requests to us. The application itself, documentation and all end-user facing content has - of course - been made available in German. Apart from the initial release in English and German, other languages have been added over time including Bulgarian, Polish, Romanian and Turkish. See the [FAQ available languages](https://www.coronawarn.app/en/faq/#available_languages) entry for more details. We also try to make developer documentation available in German, but please understand that focusing on the _Lingua Franca_ of the global developer community makes the development of this application as efficient as possible.
## Our Documentation

6
backend-infrastructure-architecture.md
View File

@ -1,9 +1,9 @@
# German Corona Warn App (CWA)
# German Corona-Warn-App (CWA)
## Backend Infrastructure Architecture Overview
The file ``backend-infrastructure-architecture.pdf`` complements the "CWA Solution Architecture" document. It is intended as a technical overview document of Corona Warn App (CWA) and its underlying infrastructure and network.
This description of the **CWA backend infrastructure architecture** is not published as MD file, because it is not intended to be developed together with the community. Whoever takes the sources and sets up their own "Corona-Warn-App" may use another backend structure. Nevertheless, it might be helpful to know how the current project is implemented in a data center. Therefore, we publish this document as a PDF file.
This description of the **CWA backend infrastructure architecture** is not published as MD file, because it is not intended to be developed together with the community. Whoever takes the sources and sets up their own "Corona-Warn-App" may use another backend structure. Nevertheless, it might be helpful to know how the current project is implemented in a data center. Therefore, we publish this document as a [PDF](https://github.com/corona-warn-app/cwa-documentation/blob/master/backend-infrastructure-architecture.pdf) file.
More CWA-Server Documentation can be found [here](https://github.com/corona-warn-app/cwa-server/tree/master/docs)
More CWA-Server Documentation can be found [here](https://github.com/corona-warn-app/cwa-server/tree/main/docs).

2
cwa-versioning.md
View File

@ -14,7 +14,7 @@ We plan to never deprecate outdated API versions. That means that even on MAJOR
Backend components will always remain compatible due to ongoing the availability of old API versions.
To ensure that all clients use the current "state of the art" information in order to apply the respective algorithms the cwa-server component can deprecate older Android and iOS app versions. The current minimum required app versions can be viewed in the [App Version Config](https://github.com/corona-warn-app/cwa-server/blob/master/services/distribution/src/main/resources/application.yaml#L93).
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/main/services/distribution/src/main/resources/application.yaml#L118).
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

16
glossary.md
View File

@ -10,7 +10,7 @@ This overview provides a description for all acronyms and special terms which ar
| APNs | Acronym for "[Apple Push Notification service](https://en.wikipedia.org/wiki/Apple_Push_Notification_service)", a platform notification service created by Apple Inc. |
| BGG | The [German Equality of Persons with Disabilities Act](https://www.gesetze-im-internet.de/bgg/), acronym for "Behindertengleichstellungsgesetz", long term: "Gesetz zur Gleichstellung von Menschen mit Behinderungen". |
| BLE, BTLE | [Bluetooth Low Energy](https://en.wikipedia.org/wiki/Bluetooth_Low_Energy) is a wireless personal area network technology. It is used in the Corona-Warn-App. |
| BMG | German [Federal Ministry of Health](https://www.bundesgesundheitsministerium.de/en/en.html), acronym for "Bundesministerium für Gesundheit". |
| BMG | German [Federal Ministry of Health](https://www.bundesgesundheitsministerium.de/en/), acronym for "Bundesministerium für Gesundheit". |
| CDN | Acronym for [Content Delivery Network](https://en.wikipedia.org/wiki/Content_delivery_network). |
| COVID-19 | [Coronavirus disease 2019](https://en.wikipedia.org/wiki/Coronavirus_disease_2019) is an infectious disease caused by severe acute respiratory syndrome coronavirus 2 (SARS-CoV-2). |
| CTR | Acronym for "[Counter (Mode)](https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#CTR)", a mode of operation in cryptography, also used in the [Exposure Notification Framework](https://covid19-static.cdn-apple.com/applications/covid19/current/static/contact-tracing/pdf/ExposureNotification-CryptographySpecificationv1.2.pdf) |
@ -36,3 +36,17 @@ This overview provides a description for all acronyms and special terms which ar
| TCN | The [TCN Coalition](https://tcn-coalition.org/) is a global community of people to support exposure notification apps during the COVID-19 pandemic. |
| TEK | Acronym for "[Temporary Exposure Key](https://covid19-static.cdn-apple.com/applications/covid19/current/static/contact-tracing/pdf/ExposureNotification-BluetoothSpecificationv1.2.pdf)". A key that’s generated every 24 hours for privacy consideration. |
| teleTAN | Authorizes the upload of diagnosis keys from the app to the Corona-Warn-App Server if the test has returned a positive result and if the device wasn't linked using the QR Code. If the authorization is successful, the server will issue a registration token. See our [solution architecture document](solution_architecture.md) for details. |
## Other Glossaries
### Technical FAQ Site
- [English Glossary](https://www.coronawarn.app/en/faq/#glossary)
- [German Glossar](https://www.coronawarn.app/de/faq/#glossary)
### Federal Government (Bundesregierung) FAQ Site
To access the glossaries, scroll down the page to the Glossary / Glossar section:
- [English FAQs](https://www.bundesregierung.de/corona-warn-app-faq-englisch)
- [German FAQs](https://www.bundesregierung.de/corona-warn-app-faq)

3
images/solution_architecture/actors_in_the_system.svg Normal file
View File

File diff suppressed because one or more lines are too long
Side by Side

After

Width:  |  Height:  |  Size: 58 KiB

3
images/solution_architecture/architecture_overview.svg Normal file
View File

File diff suppressed because one or more lines are too long
Side by Side

After

Width:  |  Height:  |  Size: 25 KiB

3
images/solution_architecture/data_flow_verification.svg Normal file
View File

File diff suppressed because one or more lines are too long
Side by Side

After

Width:  |  Height:  |  Size: 38 KiB

3
images/solution_architecture/exposure_windows.svg Normal file
View File

File diff suppressed because one or more lines are too long
Side by Side

After

Width:  |  Height:  |  Size: 14 KiB

901
images/solution_architecture/figure_1.svg
View File

@ -1,901 +0,0 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xl="http://www.w3.org/1999/xlink" version="1.1" xmlns:dc="http://purl.org/dc/elements/1.1/" viewBox="-34 274 1279 692" width="1279" height="692">
<defs>
<filter id="Shadow" filterUnits="userSpaceOnUse" x="-161.9" y="204.8">
<feGaussianBlur in="SourceAlpha" result="blur" stdDeviation="1.308"/>
<feOffset in="blur" result="offset" dx="0" dy="2"/>
<feFlood flood-color="black" flood-opacity=".5" result="flood"/>
<feComposite in="flood" in2="offset" operator="in"/>
</filter>
<font-face font-family="Helvetica Neue" font-size="16" panose-1="2 0 8 3 0 0 0 9 0 4" units-per-em="1000" underline-position="-100" underline-thickness="50" slope="0" x-height="517" cap-height="714" ascent="975.0061" descent="-216.99524" font-weight="700">
<font-face-src>
<font-face-name name="HelveticaNeue-Bold"/>
</font-face-src>
</font-face>
<font-face font-family="Helvetica" font-size="12" units-per-em="1000" underline-position="-75.68359" underline-thickness="49.316406" slope="0" x-height="532.22656" cap-height="719.7266" ascent="770.0195" descent="-229.98047" font-weight="700">
<font-face-src>
<font-face-name name="Helvetica-Bold"/>
</font-face-src>
</font-face>
<font-face font-family="Helvetica" font-size="12" units-per-em="1000" underline-position="-75.68359" underline-thickness="49.316406" slope="0" x-height="522.9492" cap-height="717.28516" ascent="770.0195" descent="-229.98047" font-weight="400">
<font-face-src>
<font-face-name name="Helvetica"/>
</font-face-src>
</font-face>
<marker orient="auto" overflow="visible" markerUnits="strokeWidth" id="FilledArrow_Marker" stroke-linejoin="miter" stroke-miterlimit="10" viewBox="-1 -4 10 8" markerWidth="10" markerHeight="8" color="lime">
<g>
<path d="M 8 0 L 0 -3 L 0 3 Z" fill="currentColor" stroke="currentColor" stroke-width="1"/>
</g>
</marker>
<font-face font-family="Helvetica" font-size="15" units-per-em="1000" underline-position="-75.68359" underline-thickness="49.316406" slope="0" x-height="522.9492" cap-height="717.28516" ascent="770.0195" descent="-229.98047" font-weight="400">
<font-face-src>
<font-face-name name="Helvetica"/>
</font-face-src>
</font-face>
<font-face font-family="Helvetica Neue" font-size="12" panose-1="2 0 5 3 0 0 0 2 0 4" units-per-em="1000" underline-position="-100" underline-thickness="50" slope="0" x-height="517" cap-height="714" ascent="951.9958" descent="-212.99744" font-weight="400">
<font-face-src>
<font-face-name name="HelveticaNeue"/>
</font-face-src>
</font-face>
</defs>
<metadata> Produced by OmniGraffle 7.17.5\n2020-10-16 16:08:56 +0000</metadata>
<g id="high-level-overview" stroke-dasharray="none" stroke-opacity="1" fill="none" stroke="none" fill-opacity="1">
<title>high-level-overview</title>
<rect fill="white" x="-34" y="274" width="1279" height="692"/>
<g id="high-level-overview_Layer_1">
<title>Layer 1</title>
<g id="Graphic_145_shadow" filter="url(#Shadow)">
<rect x="-30" y="275.6805" width="1271" height="684.52064" fill="white"/>
<path d="M -30 275.6805 L 1241 275.6805 L 1241 960.2011 L -30 960.2011 Z" stroke="black" stroke-linecap="round" stroke-linejoin="round" stroke-dasharray="4.0,4.0" stroke-width="1"/>
</g>
<g id="Graphic_2_shadow" filter="url(#Shadow)">
<rect x="620.0835" y="382" width="593.9165" height="291.392" fill="#ccc"/>
<rect x="620.0835" y="382" width="593.9165" height="291.392" stroke="black" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/>
</g>
<g id="Graphic_3_shadow" filter="url(#Shadow)">
<rect x="1133" y="468" width="63.125" height="178" fill="white"/>
<rect x="1133" y="468" width="63.125" height="178" stroke="black" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/>
</g>
<g id="Graphic_4_shadow" filter="url(#Shadow)">
<rect x="1024" y="468" width="72.125" height="178" fill="white"/>
<rect x="1024" y="468" width="72.125" height="178" stroke="lime" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
<g id="Graphic_5_shadow" filter="url(#Shadow)">
<rect x="666" y="468" width="244" height="178" fill="#fecc66"/>
<rect x="666" y="468" width="244" height="178" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
<g id="Graphic_7_shadow" filter="url(#Shadow)">
<rect x="20" y="895.664" width="122.125" height="24.335999" fill="white"/>
<rect x="20" y="895.664" width="122.125" height="24.335999" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
<g id="Graphic_6_shadow" filter="url(#Shadow)">
<rect x="152" y="896" width="122.125" height="24" fill="white"/>
<rect x="152" y="896" width="122.125" height="24" stroke="lime" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
<g id="Graphic_12_shadow" filter="url(#Shadow)">
<path d="M 973.6385 581.8517 L 980.1247 578.65626 L 973.6385 575.4608 Z" fill="blue"/>
<path d="M 973.6385 581.8517 L 980.1247 578.65626 L 973.6385 575.4608 Z" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
<g id="Graphic_13_shadow" filter="url(#Shadow)">
<rect x="958.3062" y="571.87114" width="18.666016" height="14"/>
</g>
<g id="Graphic_14_shadow" filter="url(#Shadow)">
<circle cx="969.6252" cy="556.85714" r="12.0000191748228" fill="white"/>
<circle cx="969.6252" cy="556.85714" r="12.0000191748228" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
<g id="Graphic_15_shadow" filter="url(#Shadow)">
<circle cx="1114.5625" cy="557" r="12.0000191748228" fill="white"/>
<circle cx="1114.5625" cy="557" r="12.0000191748228" stroke="black" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/>
</g>
<g id="Graphic_18_shadow" filter="url(#Shadow)">
<path d="M 1032 396 L 1084 396 C 1097.8071 396 1109 407.1929 1109 421 L 1109 421 C 1109 434.8071 1097.8071 446 1084 446 L 1032 446 C 1018.1929 446 1007 434.8071 1007 421 L 1007 421 C 1007 407.1929 1018.1929 396 1032 396 Z" fill="white"/>
<path d="M 1032 396 L 1084 396 C 1097.8071 396 1109 407.1929 1109 421 L 1109 421 C 1109 434.8071 1097.8071 446 1084 446 L 1032 446 C 1018.1929 446 1007 434.8071 1007 421 L 1007 421 C 1007 407.1929 1018.1929 396 1032 396 Z" stroke="lime" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/>
</g>
<g id="Graphic_23_shadow" filter="url(#Shadow)">
<rect x="666" y="756.098" width="122.125" height="54" fill="#ccc"/>
<rect x="666" y="756.098" width="122.125" height="54" stroke="black" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/>
</g>
<g id="Graphic_22_shadow" filter="url(#Shadow)">
<rect x="960.4375" y="771" width="166.125" height="49.392" fill="white"/>
<rect x="960.4375" y="771" width="166.125" height="49.392" stroke="black" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/>
</g>
<g id="Graphic_24_shadow" filter="url(#Shadow)">
<circle cx="1167.125" cy="708" r="12.0000191748228" fill="white"/>
<circle cx="1167.125" cy="708" r="12.0000191748228" stroke="black" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/>
</g>
<g id="Graphic_27_shadow" filter="url(#Shadow)">
<circle cx="898" cy="851" r="12.0000191748228" fill="white"/>
<circle cx="898" cy="851" r="12.0000191748228" stroke="black" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/>
</g>
<g id="Graphic_35_shadow" filter="url(#Shadow)">
<rect x="686" y="782.098" width="55.208496" height="19" fill="#fecc66"/>
<rect x="686" y="782.098" width="55.208496" height="19" stroke="black" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/>
</g>
<g id="Graphic_37_shadow" filter="url(#Shadow)">
<rect x="666" y="822.402" width="122.125" height="54" fill="#ccc"/>
<rect x="666" y="822.402" width="122.125" height="54" stroke="black" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/>
</g>
<g id="Graphic_36_shadow" filter="url(#Shadow)">
<rect x="686" y="848.402" width="55.208496" height="19" fill="#fecc66"/>
<rect x="686" y="848.402" width="55.208496" height="19" stroke="black" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/>
</g>
<g id="Graphic_39_shadow" filter="url(#Shadow)">
<rect x="666" y="891.902" width="122.125" height="54" fill="#ccc"/>
<rect x="666" y="891.902" width="122.125" height="54" stroke="black" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/>
</g>
<g id="Graphic_38_shadow" filter="url(#Shadow)">
<rect x="686" y="917.902" width="55.208496" height="19" fill="#fecc66"/>
<rect x="686" y="917.902" width="55.208496" height="19" stroke="black" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/>
</g>
<g id="Graphic_47_shadow" filter="url(#Shadow)">
<rect x="20" y="300.986" width="136" height="41.014" fill="white"/>
<rect x="20" y="300.986" width="136" height="41.014" stroke="lime" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
<g id="Graphic_48_shadow" filter="url(#Shadow)">
<rect x="183" y="300.986" width="80" height="41.014" fill="white"/>
<rect x="183" y="300.986" width="80" height="41.014" stroke="black" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/>
</g>
<g id="Graphic_49_shadow" filter="url(#Shadow)">
<rect x="290" y="300.986" width="80" height="41.014" fill="white"/>
<rect x="290" y="300.986" width="80" height="41.014" stroke="black" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/>
</g>
<g id="Graphic_50_shadow" filter="url(#Shadow)">
<rect x="20" y="396" width="136" height="41.014" fill="white"/>
<rect x="20" y="396" width="136" height="41.014" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
<g id="Graphic_51_shadow" filter="url(#Shadow)">
<rect x="183" y="396" width="187" height="41.014" fill="white"/>
<rect x="183" y="396" width="187" height="41.014" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
<g id="Graphic_52_shadow" filter="url(#Shadow)">
<rect x="20" y="496" width="350" height="41.014" fill="white"/>
<rect x="20" y="496" width="350" height="41.014" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
<g id="Graphic_53_shadow" filter="url(#Shadow)">
<rect x="20" y="596" width="144" height="113.007" fill="white"/>
<rect x="20" y="596" width="144" height="113.007" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
<g id="Graphic_54_shadow" filter="url(#Shadow)">
<rect x="20" y="799.365" width="144" height="41.014" fill="white"/>
<rect x="20" y="799.365" width="144" height="41.014" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
<g id="Graphic_55_shadow" filter="url(#Shadow)">
<rect x="369" y="652" width="122.125" height="41.014" fill="white"/>
<rect x="369" y="652" width="122.125" height="41.014" stroke="lime" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
<g id="Graphic_56_shadow" filter="url(#Shadow)">
<rect x="376" y="662" width="122.125" height="41.014" fill="white"/>
<rect x="376" y="662" width="122.125" height="41.014" stroke="lime" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
<g id="Graphic_57_shadow" filter="url(#Shadow)">
<rect x="383" y="672" width="122.125" height="41.014" fill="white"/>
<rect x="383" y="672" width="122.125" height="41.014" stroke="lime" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
<g id="Graphic_59_shadow" filter="url(#Shadow)">
<path d="M 106.8885 371 L 110.08395 377.48624 L 113.2794 371 Z" fill="black"/>
<path d="M 106.8885 371 L 110.08395 377.48624 L 113.2794 371 Z" stroke="black" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/>
</g>
<g id="Graphic_60_shadow" filter="url(#Shadow)">
<rect x="100.75049" y="357" width="18.666016" height="14"/>
</g>
<g id="Graphic_61_shadow" filter="url(#Shadow)">
<circle cx="88.5835" cy="369" r="12.0000191748228" fill="white"/>
<circle cx="88.5835" cy="369" r="12.0000191748228" stroke="black" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/>
</g>
<g id="Graphic_63_shadow" filter="url(#Shadow)">
<path d="M 241.8885 371 L 245.08395 377.48624 L 248.2794 371 Z" fill="black"/>
<path d="M 241.8885 371 L 245.08395 377.48624 L 248.2794 371 Z" stroke="black" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/>
</g>
<g id="Graphic_64_shadow" filter="url(#Shadow)">
<rect x="235.7505" y="357" width="18.666016" height="14"/>
</g>
<g id="Graphic_65_shadow" filter="url(#Shadow)">
<circle cx="223.5835" cy="369" r="12.0000191748227" fill="white"/>
<circle cx="223.5835" cy="369" r="12.0000191748227" stroke="black" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/>
</g>
<g id="Graphic_67_shadow" filter="url(#Shadow)">
<path d="M 347.8885 371 L 351.08395 377.48624 L 354.2794 371 Z" fill="black"/>
<path d="M 347.8885 371 L 351.08395 377.48624 L 354.2794 371 Z" stroke="black" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/>
</g>
<g id="Graphic_68_shadow" filter="url(#Shadow)">
<rect x="341.7505" y="357" width="18.666016" height="14"/>
</g>
<g id="Graphic_69_shadow" filter="url(#Shadow)">
<circle cx="329.5835" cy="369" r="12.0000191748228" fill="white"/>
<circle cx="329.5835" cy="369" r="12.0000191748228" stroke="black" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/>
</g>
<g id="Graphic_79_shadow" filter="url(#Shadow)">
<path d="M 295.3885 468.257 L 298.58395 474.74325 L 301.7794 468.257 Z" fill="blue"/>
<path d="M 295.3885 468.257 L 298.58395 474.74325 L 301.7794 468.257 Z" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="3"/>
</g>
<g id="Graphic_80_shadow" filter="url(#Shadow)">
<rect x="289.2505" y="454.257" width="18.666016" height="14"/>
</g>
<g id="Graphic_81_shadow" filter="url(#Shadow)">
<circle cx="277.0835" cy="466.257" r="12.0000191748227" fill="white"/>
<circle cx="277.0835" cy="466.257" r="12.0000191748227" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="3"/>
</g>
<g id="Graphic_84_shadow" filter="url(#Shadow)">
<path d="M 111.82452 462.26424 L 108.62907 455.778 L 105.43362 462.26424 Z" fill="blue"/>
<path d="M 111.82452 462.26424 L 108.62907 455.778 L 105.43362 462.26424 Z" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
<g id="Graphic_85_shadow" filter="url(#Shadow)">
<rect x="100.12261" y="463.236" width="18.666016" height="14"/>
</g>
<g id="Graphic_86_shadow" filter="url(#Shadow)">
<circle cx="88.70562" cy="466.507" r="12.0000191748228" fill="white"/>
<circle cx="88.70562" cy="466.507" r="12.0000191748228" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
<g id="Graphic_93_shadow" filter="url(#Shadow)">
<path d="M 115.1189 562.26424 L 111.92345 555.778 L 108.728 562.26424 Z" fill="blue"/>
<path d="M 115.1189 562.26424 L 111.92345 555.778 L 108.728 562.26424 Z" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
<g id="Graphic_94_shadow" filter="url(#Shadow)">
<rect x="103.41699" y="563.236" width="18.666016" height="14"/>
</g>
<g id="Graphic_95_shadow" filter="url(#Shadow)">
<circle cx="92" cy="566.507" r="12.0000191748228" fill="white"/>
<circle cx="92" cy="566.507" r="12.0000191748228" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
<g id="Graphic_99_shadow" filter="url(#Shadow)">
<path d="M 277.51333 718.4946 L 283.99957 715.2991 L 277.51333 712.1037 Z" fill="blue"/>
<path d="M 277.51333 718.4946 L 283.99957 715.2991 L 277.51333 712.1037 Z" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
<g id="Graphic_100_shadow" filter="url(#Shadow)">
<rect x="262.181" y="708.514" width="18.666016" height="14"/>
</g>
<g id="Graphic_101_shadow" filter="url(#Shadow)">
<circle cx="273.5" cy="693.5" r="12.0000191748228" fill="white"/>
<circle cx="273.5" cy="693.5" r="12.0000191748228" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
<g id="Graphic_117_shadow" filter="url(#Shadow)">
<path d="M 151.96781 756.186 L 155.16326 762.67225 L 158.35871 756.186 Z" fill="blue"/>
<path d="M 151.96781 756.186 L 155.16326 762.67225 L 158.35871 756.186 Z" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
<g id="Graphic_118_shadow" filter="url(#Shadow)">
<rect x="145.8298" y="742.186" width="18.666016" height="14"/>
</g>
<g id="Graphic_119_shadow" filter="url(#Shadow)">
<circle cx="133.66281" cy="754.186" r="12.0000191748228" fill="white"/>
<circle cx="133.66281" cy="754.186" r="12.0000191748228" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
<g id="Graphic_113_shadow" filter="url(#Shadow)">
<path d="M 78.88944 749.8572 L 75.69399 743.371 L 72.49854 749.8572 Z" fill="blue"/>
<path d="M 78.88944 749.8572 L 75.69399 743.371 L 72.49854 749.8572 Z" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
<g id="Graphic_114_shadow" filter="url(#Shadow)">
<rect x="67.18753" y="750.829" width="18.666016" height="14"/>
</g>
<g id="Graphic_115_shadow" filter="url(#Shadow)">
<circle cx="55.77054" cy="754.1" r="12.0000191748228" fill="white"/>
<circle cx="55.77054" cy="754.1" r="12.0000191748228" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
<g id="Graphic_122_shadow" filter="url(#Shadow)">
<path d="M 409.3614 632.8187 L 402.87517 636.0141 L 409.3614 639.2096 Z" fill="blue"/>
<path d="M 409.3614 632.8187 L 402.87517 636.0141 L 409.3614 639.2096 Z" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
<g id="Graphic_123_shadow" filter="url(#Shadow)">
<rect x="407.04183" y="629.014" width="18.666016" height="14"/>
</g>
<g id="Graphic_124_shadow" filter="url(#Shadow)">
<circle cx="415.12484" cy="614" r="12.0000191748228" fill="white"/>
<circle cx="415.12484" cy="614" r="12.0000191748228" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
<g id="Graphic_131_shadow" filter="url(#Shadow)">
<path d="M 609.11124 712.3187 L 602.625 715.5141 L 609.11124 718.7096 Z" fill="blue"/>
<path d="M 609.11124 712.3187 L 602.625 715.5141 L 609.11124 718.7096 Z" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
<g id="Graphic_132_shadow" filter="url(#Shadow)">
<rect x="606.79166" y="708.514" width="18.666016" height="14"/>
</g>
<g id="Graphic_133_shadow" filter="url(#Shadow)">
<circle cx="614.8747" cy="693.5" r="12.0000191748228" fill="white"/>
<circle cx="614.8747" cy="693.5" r="12.0000191748228" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
<g id="Graphic_140_shadow" filter="url(#Shadow)">
<path d="M 495.8656 536.6477 L 489.37934 539.8431 L 495.8656 543.0386 Z" fill="blue"/>
<path d="M 495.8656 536.6477 L 489.37934 539.8431 L 495.8656 543.0386 Z" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
<g id="Graphic_141_shadow" filter="url(#Shadow)">
<rect x="493.546" y="532.843" width="18.666016" height="14"/>
</g>
<g id="Graphic_142_shadow" filter="url(#Shadow)">
<circle cx="501.629" cy="517.829" r="12.0000191748228" fill="white"/>
<circle cx="501.629" cy="517.829" r="12.0000191748228" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
<g id="Graphic_145">
<rect x="-30" y="275.6805" width="1271" height="684.52064" fill="white"/>
<path d="M -30 275.6805 L 1241 275.6805 L 1241 960.2011 L -30 960.2011 Z" stroke="black" stroke-linecap="round" stroke-linejoin="round" stroke-dasharray="4.0,4.0" stroke-width="1"/>
</g>
<g id="Graphic_144">
<text transform="translate(-13.243494 935.737)" fill="black">
<tspan font-family="Helvetica Neue" font-size="16" font-weight="700" fill="black" x="0" y="16">Figure 1: High-level architecture overview</tspan>
</text>
</g>
<g id="Graphic_2">
<rect x="620.0835" y="382" width="593.9165" height="291.392" fill="#ccc"/>
<rect x="620.0835" y="382" width="593.9165" height="291.392" stroke="black" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/>
<text transform="translate(625.0835 382)" fill="black">
<tspan font-family="Helvetica" font-size="12" font-weight="700" fill="black" x="0" y="11">Mobile Phone</tspan>
<tspan font-family="Helvetica" font-size="12" font-weight="700" fill="black" x="0" y="25">Apple iPhone or Android phone</tspan>
</text>
</g>
<g id="Graphic_3">
<rect x="1133" y="468" width="63.125" height="178" fill="white"/>
<rect x="1133" y="468" width="63.125" height="178" stroke="black" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/>
<text transform="translate(1138 515)" fill="black">
<tspan font-family="Helvetica" font-size="12" font-weight="400" fill="black" x="1.2089844" y="11">Bluetooth </tspan>
<tspan font-family="Helvetica" font-size="12" font-weight="400" fill="black" x="15.555664" y="25">Low </tspan>
<tspan font-family="Helvetica" font-size="12" font-weight="400" fill="black" x="7.551758" y="39">Energy </tspan>
<tspan font-family="Helvetica" font-size="12" font-weight="400" fill="black" x="11.225586" y="53">(BLE) </tspan>
<tspan font-family="Helvetica" font-size="12" font-weight="400" fill="black" x=".5527344" y="67">Hardware </tspan>
<tspan font-family="Helvetica" font-size="12" font-weight="400" fill="black" x="3.2158203" y="81">Interface</tspan>
</text>
</g>
<g id="Graphic_4">
<rect x="1024" y="468" width="72.125" height="178" fill="white"/>
<rect x="1024" y="468" width="72.125" height="178" stroke="lime" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
<text transform="translate(1029 536)" fill="black">
<tspan font-family="Helvetica" font-size="12" font-weight="400" fill="black" x="5.714844" y="11">Exposure </tspan>
<tspan font-family="Helvetica" font-size="12" font-weight="400" fill="black" x="1.381836" y="25">Notification </tspan>
<tspan font-family="Helvetica" font-size="12" font-weight="400" fill="black" x="1.0595703" y="39">Framework</tspan>
</text>
</g>
<g id="Graphic_5">
<rect x="666" y="468" width="244" height="178" fill="#fecc66"/>
<rect x="666" y="468" width="244" height="178" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
<text transform="translate(671 522)" fill="black">
<tspan font-family="Helvetica" font-size="12" font-weight="700" fill="black" x="45.896484" y="11">Corona-Warn-App (CWA)</tspan>
<tspan font-family="Helvetica" font-size="12" font-weight="400" fill="black" x="28.623047" y="25">Test result retrieval and exposure </tspan>
<tspan font-family="Helvetica" font-size="12" font-weight="400" fill="black" x="64.643555" y="39">notification (tracing)</tspan>
<tspan font-family="Helvetica" font-size="12" font-weight="400" fill="black" x="31.277344" y="67">(Apple iOS and Google Android)</tspan>
</text>
</g>
<g id="Graphic_7">
<rect x="20" y="895.664" width="122.125" height="24.335999" fill="white"/>
<rect x="20" y="895.664" width="122.125" height="24.335999" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
<text transform="translate(25 900.832)" fill="black">
<tspan font-family="Helvetica" font-size="12" font-weight="400" fill="black" x="20.707031" y="11">Open Source</tspan>
</text>
</g>
<g id="Graphic_6">
<rect x="152" y="896" width="122.125" height="24" fill="white"/>
<rect x="152" y="896" width="122.125" height="24" stroke="lime" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
<text transform="translate(157 901)" fill="black">
<tspan font-family="Helvetica" font-size="12" font-weight="400" fill="black" x="8.704102" y="11">Existing Solutions</tspan>
</text>
</g>
<g id="Group_10">
<g id="Graphic_14">
<circle cx="969.6252" cy="556.85714" r="12.0000191748228" fill="white"/>
<circle cx="969.6252" cy="556.85714" r="12.0000191748228" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
<g id="Group_11">
<g id="Graphic_13">
<text transform="translate(963.3062 571.87114)" fill="blue">
<tspan font-family="Helvetica" font-size="12" font-weight="400" fill="blue" x="0" y="11">R</tspan>
</text>
</g>
<g id="Graphic_12">
<path d="M 973.6385 581.8517 L 980.1247 578.65626 L 973.6385 575.4608 Z" fill="blue"/>
<path d="M 973.6385 581.8517 L 980.1247 578.65626 L 973.6385 575.4608 Z" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
</g>
</g>
<g id="Line_9">
<line x1="982.6252" y1="556.8777" x2="1023" y2="556.94146" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
<g id="Line_8">
<line x1="911" y1="556.90325" x2="956.6252" y2="556.8674" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
<g id="Graphic_15">
<circle cx="1114.5625" cy="557" r="12.0000191748228" fill="white"/>
<circle cx="1114.5625" cy="557" r="12.0000191748228" stroke="black" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/>
</g>
<g id="Line_16">
<line x1="1097.125" y1="557" x2="1102.0625" y2="557" stroke="black" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/>
</g>
<g id="Line_17">
<line x1="1127.0625" y1="557" x2="1132.5" y2="557" stroke="black" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/>
</g>
<g id="Graphic_18">
<path d="M 1032 396 L 1084 396 C 1097.8071 396 1109 407.1929 1109 421 L 1109 421 C 1109 434.8071 1097.8071 446 1084 446 L 1032 446 C 1018.1929 446 1007 434.8071 1007 421 L 1007 421 C 1007 407.1929 1018.1929 396 1032 396 Z" fill="white"/>
<path d="M 1032 396 L 1084 396 C 1097.8071 396 1109 407.1929 1109 421 L 1109 421 C 1109 434.8071 1097.8071 446 1084 446 L 1032 446 C 1018.1929 446 1007 434.8071 1007 421 L 1007 421 C 1007 407.1929 1018.1929 396 1032 396 Z" stroke="lime" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/>
<text transform="translate(1012 407)" fill="black">
<tspan font-family="Helvetica" font-size="12" font-weight="400" fill="black" x="20.652344" y="11">Exposure </tspan>
<tspan font-family="Helvetica" font-size="12" font-weight="400" fill="black" x="1.9785156" y="25">Notification Data</tspan>
</text>
</g>
<g id="Group_19">
<g id="Line_21">
<path d="M 1039.777 459 C 1045.4431 455.667 1050.7033 449.3643 1056.777 449 C 1060.1342 448.79864 1063.741 450.4115 1067.3903 452.3343" marker-end="url(#FilledArrow_Marker)" stroke="lime" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/>
</g>
<g id="Line_20">
<path d="M 1076.223 456.814 C 1070.7415 460.5423 1065.8507 467.6357 1059.777 468 C 1056.2704 468.2103 1052.3682 466.17774 1048.4133 463.8447" marker-end="url(#FilledArrow_Marker)" stroke="lime" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/>
</g>
</g>
<g id="Graphic_23">
<rect x="666" y="756.098" width="122.125" height="54" fill="#ccc"/>
<rect x="666" y="756.098" width="122.125" height="54" stroke="black" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/>
<text transform="translate(671 756.098)" fill="black">
<tspan font-family="Helvetica" font-size="15" font-weight="400" fill="black" x="0" y="15">Mobile Phone</tspan>
</text>
</g>
<g id="Graphic_22">
<rect x="960.4375" y="771" width="166.125" height="49.392" fill="white"/>
<rect x="960.4375" y="771" width="166.125" height="49.392" stroke="black" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/>
<text transform="translate(965.4375 781.696)" fill="black">
<tspan font-family="Helvetica" font-size="12" font-weight="400" fill="black" x="14.359375" y="11">BLE Beacon Mechanics</tspan>
<tspan font-family="Helvetica" font-size="12" font-weight="400" fill="black" x="20.365234" y="25">(No active connection</tspan>
</text>
</g>
<g id="Graphic_24">
<circle cx="1167.125" cy="708" r="12.0000191748228" fill="white"/>
<circle cx="1167.125" cy="708" r="12.0000191748228" stroke="black" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/>
</g>
<g id="Line_25">
<line x1="1166.9129" y1="695.5018" x2="1166.0813" y2="646.4999" stroke="black" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/>
</g>
<g id="Line_26">
<path d="M 1167.125 720.5 C 1167.125 741.99785 1173.8017 773.6734 1167.125 785 C 1160.4483 796.3266 1140.4141 787.311 1127.0606 788.4664" stroke="black" stroke-linecap="round" stroke-linejoin="round" stroke-dasharray="4.0,4.0" stroke-width="1"/>
</g>
<g id="Graphic_27">
<circle cx="898" cy="851" r="12.0000191748228" fill="white"/>
<circle cx="898" cy="851" r="12.0000191748228" stroke="black" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/>
</g>
<g id="Line_28">
<line x1="909.6872" y1="846.5577" x2="978.0596" y2="820.5696" stroke="black" stroke-linecap="round" stroke-linejoin="round" stroke-dasharray="4.0,4.0" stroke-width="1"/>
</g>
<g id="Graphic_35">
<rect x="686" y="782.098" width="55.208496" height="19" fill="#fecc66"/>
<rect x="686" y="782.098" width="55.208496" height="19" stroke="black" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/>
<text transform="translate(691 784.598)" fill="black">
<tspan font-family="Helvetica" font-size="12" font-weight="400" fill="black" x="8.825928" y="11">CWA</tspan>
</text>
</g>
<g id="Graphic_37">
<rect x="666" y="822.402" width="122.125" height="54" fill="#ccc"/>
<rect x="666" y="822.402" width="122.125" height="54" stroke="black" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/>
<text transform="translate(671 822.402)" fill="black">
<tspan font-family="Helvetica" font-size="15" font-weight="400" fill="black" x="0" y="15">Mobile Phone</tspan>
</text>
</g>
<g id="Graphic_36">
<rect x="686" y="848.402" width="55.208496" height="19" fill="#fecc66"/>
<rect x="686" y="848.402" width="55.208496" height="19" stroke="black" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/>
<text transform="translate(691 850.902)" fill="black">
<tspan font-family="Helvetica" font-size="12" font-weight="400" fill="black" x="8.825928" y="11">CWA</tspan>
</text>
</g>
<g id="Graphic_39">
<rect x="666" y="891.902" width="122.125" height="54" fill="#ccc"/>
<rect x="666" y="891.902" width="122.125" height="54" stroke="black" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/>
<text transform="translate(671 891.902)" fill="black">
<tspan font-family="Helvetica" font-size="15" font-weight="400" fill="black" x="0" y="15">Mobile Phone</tspan>
</text>
</g>
<g id="Graphic_38">
<rect x="686" y="917.902" width="55.208496" height="19" fill="#fecc66"/>
<rect x="686" y="917.902" width="55.208496" height="19" stroke="black" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/>
<text transform="translate(691 920.402)" fill="black">
<tspan font-family="Helvetica" font-size="12" font-weight="400" fill="black" x="8.825928" y="11">CWA</tspan>
</text>
</g>
<g id="Line_40">
<line x1="788.5897" y1="807.5386" x2="886.3801" y2="846.3842" stroke="black" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/>
</g>
<g id="Line_41">
<line x1="788.625" y1="849.9775" x2="885.5005" y2="850.8831" stroke="black" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/>
</g>
<g id="Line_42">
<line x1="788.5897" y1="894.4614" x2="886.3801" y2="855.6158" stroke="black" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/>
</g>
<g id="Graphic_44">
<text transform="translate(801 790.762)" fill="black">
<tspan font-family="Helvetica Neue" font-size="12" font-weight="400" fill="black" x="7105427e-20" y="11">Broadcasting</tspan>
</text>
</g>
<g id="Graphic_43">
<text transform="translate(971 844)" fill="black">
<tspan font-family="Helvetica Neue" font-size="12" font-weight="400" fill="black" x="2.2845" y="11">Broadcasting of RPI </tspan>
<tspan font-family="Helvetica Neue" font-size="12" font-weight="400" fill="black" x="2.0445" y="25.336">encrypted metadata</tspan>
</text>
</g>
<g id="Graphic_46">
<text transform="translate(872.884 882)" fill="black">
<tspan font-family="Helvetica Neue" font-size="12" font-weight="400" fill="black" x="0" y="11">Scanning</tspan>
</text>
</g>
<g id="Graphic_47">
<rect x="20" y="300.986" width="136" height="41.014" fill="white"/>
<rect x="20" y="300.986" width="136" height="41.014" stroke="lime" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
<text transform="translate(25 307.493)" fill="black">
<tspan font-family="Helvetica" font-size="12" font-weight="400" fill="black" x="2.633789" y="11">Laboratory Information </tspan>
<tspan font-family="Helvetica" font-size="12" font-weight="400" fill="black" x="28.32715" y="25">System (LIS)</tspan>
</text>
</g>
<g id="Graphic_48">
<rect x="183" y="300.986" width="80" height="41.014" fill="white"/>
<rect x="183" y="300.986" width="80" height="41.014" stroke="black" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/>
<text transform="translate(188 307.493)" fill="black">
<tspan font-family="Helvetica" font-size="12" font-weight="400" fill="black" x="17.65625" y="11">Health </tspan>
<tspan font-family="Helvetica" font-size="12" font-weight="400" fill="black" x="11.322266" y="25">Authority</tspan>
</text>
</g>
<g id="Graphic_49">
<rect x="290" y="300.986" width="80" height="41.014" fill="white"/>
<rect x="290" y="300.986" width="80" height="41.014" stroke="black" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/>
<text transform="translate(295 314.493)" fill="black">
<tspan font-family="Helvetica" font-size="12" font-weight="400" fill="black" x="16.323242" y="11">Hotline</tspan>
</text>
</g>
<g id="Graphic_50">
<rect x="20" y="396" width="136" height="41.014" fill="white"/>
<rect x="20" y="396" width="136" height="41.014" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
<text transform="translate(25 409.507)" fill="black">
<tspan font-family="Helvetica" font-size="12" font-weight="700" fill="black" x="10.751953" y="11">Test Result Server</tspan>
</text>
</g>
<g id="Graphic_51">
<rect x="183" y="396" width="187" height="41.014" fill="white"/>
<rect x="183" y="396" width="187" height="41.014" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
<text transform="translate(188 409.507)" fill="black">
<tspan font-family="Helvetica" font-size="12" font-weight="700" fill="black" x="51.146484" y="11">Portal Server</tspan>
</text>
</g>
<g id="Graphic_52">
<rect x="20" y="496" width="350" height="41.014" fill="white"/>
<rect x="20" y="496" width="350" height="41.014" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
<text transform="translate(25 509.507)" fill="black">
<tspan font-family="Helvetica" font-size="12" font-weight="700" fill="black" x="117.30371" y="11">Verification Server</tspan>
</text>
</g>
<g id="Graphic_53">
<rect x="20" y="596" width="144" height="113.007" fill="white"/>
<rect x="20" y="596" width="144" height="113.007" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
<text transform="translate(25 638.5035)" fill="black">
<tspan font-family="Helvetica" font-size="12" font-weight="700" fill="black" x="15.560547" y="11">Corona-Warn-App </tspan>
<tspan font-family="Helvetica" font-size="12" font-weight="700" fill="black" x="48.31738" y="25">Server</tspan>
</text>
</g>
<g id="Graphic_54">
<rect x="20" y="799.365" width="144" height="41.014" fill="white"/>
<rect x="20" y="799.365" width="144" height="41.014" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
<text transform="translate(25 805.872)" fill="black">
<tspan font-family="Helvetica" font-size="12" font-weight="700" fill="black" x="6.991211" y="11">European Federation </tspan>
<tspan font-family="Helvetica" font-size="12" font-weight="700" fill="black" x="42.32031" y="25">Gateway</tspan>
</text>
</g>
<g id="Graphic_55">
<rect x="369" y="652" width="122.125" height="41.014" fill="white"/>
<rect x="369" y="652" width="122.125" height="41.014" stroke="lime" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
<g id="Graphic_56">
<rect x="376" y="662" width="122.125" height="41.014" fill="white"/>
<rect x="376" y="662" width="122.125" height="41.014" stroke="lime" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
<g id="Graphic_57">
<rect x="383" y="672" width="122.125" height="41.014" fill="white"/>
<rect x="383" y="672" width="122.125" height="41.014" stroke="lime" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
<text transform="translate(388 678.507)" fill="black">
<tspan font-family="Helvetica" font-size="12" font-weight="400" fill="black" x="11.709961" y="11">Content Delivery </tspan>
<tspan font-family="Helvetica" font-size="12" font-weight="400" fill="black" x="15.395508" y="25">Network (CDN)</tspan>
</text>
</g>
<g id="Group_58">
<g id="Graphic_61">
<circle cx="88.5835" cy="369" r="12.0000191748228" fill="white"/>
<circle cx="88.5835" cy="369" r="12.0000191748228" stroke="black" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/>
</g>
<g id="Graphic_60">
<text transform="translate(105.75049 357)" fill="black">
<tspan font-family="Helvetica" font-size="12" font-weight="400" fill="black" x="0" y="11">R</tspan>
</text>
</g>
<g id="Graphic_59">
<path d="M 106.8885 371 L 110.08395 377.48624 L 113.2794 371 Z" fill="black"/>
<path d="M 106.8885 371 L 110.08395 377.48624 L 113.2794 371 Z" stroke="black" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/>
</g>
</g>
<g id="Group_62">
<g id="Graphic_65">
<circle cx="223.5835" cy="369" r="12.0000191748227" fill="white"/>
<circle cx="223.5835" cy="369" r="12.0000191748227" stroke="black" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/>
</g>
<g id="Graphic_64">
<text transform="translate(240.7505 357)" fill="black">
<tspan font-family="Helvetica" font-size="12" font-weight="400" fill="black" x="0" y="11">R</tspan>
</text>
</g>
<g id="Graphic_63">
<path d="M 241.8885 371 L 245.08395 377.48624 L 248.2794 371 Z" fill="black"/>
<path d="M 241.8885 371 L 245.08395 377.48624 L 248.2794 371 Z" stroke="black" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/>
</g>
</g>
<g id="Group_66">
<g id="Graphic_69">
<circle cx="329.5835" cy="369" r="12.0000191748228" fill="white"/>
<circle cx="329.5835" cy="369" r="12.0000191748228" stroke="black" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/>
</g>
<g id="Graphic_68">
<text transform="translate(346.7505 357)" fill="black">
<tspan font-family="Helvetica" font-size="12" font-weight="400" fill="black" x="0" y="11">R</tspan>
</text>
</g>
<g id="Graphic_67">
<path d="M 347.8885 371 L 351.08395 377.48624 L 354.2794 371 Z" fill="black"/>
<path d="M 347.8885 371 L 351.08395 377.48624 L 354.2794 371 Z" stroke="black" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/>
</g>
</g>
<g id="Line_70">
<line x1="88.42998" y1="356.50093" x2="88.26415" y2="342.99992" stroke="black" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/>
</g>
<g id="Line_71">
<line x1="88.26415" y1="395.00008" x2="88.42998" y2="381.49907" stroke="black" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/>
</g>
<g id="Line_72">
<line x1="223.42998" y1="356.50093" x2="223.25801" y2="342.49996" stroke="black" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/>
</g>
<g id="Line_73">
<line x1="329.6931" y1="356.50047" x2="329.81583" y2="342.5" stroke="black" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/>
</g>
<g id="Line_74">
<line x1="329.5835" y1="396" x2="329.5835" y2="381.5" stroke="black" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/>
</g>
<g id="Line_75">
<line x1="223.5835" y1="396" x2="223.5835" y2="381.5" stroke="black" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/>
</g>
<g id="Group_78">
<g id="Graphic_81">
<circle cx="277.0835" cy="466.257" r="12.0000191748227" fill="white"/>
<circle cx="277.0835" cy="466.257" r="12.0000191748227" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="3"/>
</g>
<g id="Graphic_80">
<text transform="translate(294.2505 454.257)" fill="blue">
<tspan font-family="Helvetica" font-size="12" font-weight="400" fill="blue" x="0" y="11">R</tspan>
</text>
</g>
<g id="Graphic_79">
<path d="M 295.3885 468.257 L 298.58395 474.74325 L 301.7794 468.257 Z" fill="blue"/>
<path d="M 295.3885 468.257 L 298.58395 474.74325 L 301.7794 468.257 Z" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="3"/>
</g>
</g>
<g id="Line_77">
<line x1="276.92517" y1="452.7579" x2="276.75225" y2="438.01393" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="3"/>
</g>
<g id="Line_76">
<line x1="277.0835" y1="493.257" x2="277.0835" y2="479.757" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="3"/>
</g>
<g id="Group_82">
<g id="Graphic_86">
<circle cx="88.70562" cy="466.507" r="12.0000191748228" fill="white"/>
<circle cx="88.70562" cy="466.507" r="12.0000191748228" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
<g id="Group_83">
<g id="Graphic_85">
<text transform="translate(105.12261 463.236)" fill="blue">
<tspan font-family="Helvetica" font-size="12" font-weight="400" fill="blue" x="0" y="11">R</tspan>
</text>
</g>
<g id="Graphic_84">
<path d="M 111.82452 462.26424 L 108.62907 455.778 L 105.43362 462.26424 Z" fill="blue"/>
<path d="M 111.82452 462.26424 L 108.62907 455.778 L 105.43362 462.26424 Z" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
</g>
</g>
<g id="Line_87">
<line x1="88.52218" y1="453.5083" x2="88.30352" y2="438.0139" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
<g id="Line_88">
<line x1="88.70562" y1="496" x2="88.70562" y2="479.507" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
<g id="Group_91">
<g id="Graphic_95">
<circle cx="92" cy="566.507" r="12.0000191748228" fill="white"/>
<circle cx="92" cy="566.507" r="12.0000191748228" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
<g id="Group_92">
<g id="Graphic_94">
<text transform="translate(108.41699 563.236)" fill="blue">
<tspan font-family="Helvetica" font-size="12" font-weight="400" fill="blue" x="0" y="11">R</tspan>
</text>
</g>
<g id="Graphic_93">
<path d="M 115.1189 562.26424 L 111.92345 555.778 L 108.728 562.26424 Z" fill="blue"/>
<path d="M 115.1189 562.26424 L 111.92345 555.778 L 108.728 562.26424 Z" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
</g>
</g>
<g id="Line_90">
<line x1="91.97569" y1="553.507" x2="91.94484" y2="537.014" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
<g id="Line_89">
<line x1="92" y1="595" x2="92" y2="579.507" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
<g id="Graphic_96">
<text transform="translate(9.875 552.421)" fill="black">
<tspan font-family="Helvetica Neue" font-size="12" font-weight="400" fill="black" x=".933" y="11">Verification </tspan>
<tspan font-family="Helvetica Neue" font-size="12" font-weight="400" fill="black" x="12.375" y="25.336">of TAN</tspan>
</text>
</g>
<g id="Group_97">
<g id="Graphic_101">
<circle cx="273.5" cy="693.5" r="12.0000191748228" fill="white"/>
<circle cx="273.5" cy="693.5" r="12.0000191748228" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
<g id="Group_98">
<g id="Graphic_100">
<text transform="translate(267.181 708.514)" fill="blue">
<tspan font-family="Helvetica" font-size="12" font-weight="400" fill="blue" x="0" y="11">R</tspan>
</text>
</g>
<g id="Graphic_99">
<path d="M 277.51333 718.4946 L 283.99957 715.2991 L 277.51333 712.1037 Z" fill="blue"/>
<path d="M 277.51333 718.4946 L 283.99957 715.2991 L 277.51333 712.1037 Z" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
</g>
</g>
<g id="Line_102">
<line x1="164" y1="693.63866" x2="260.5" y2="693.5165" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
<g id="Line_103">
<line x1="286.4998" y1="693.4243" x2="382" y2="692.8683" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
<g id="Graphic_104">
<text transform="translate(213.5 728.402)" fill="black">
<tspan font-family="Helvetica Neue" font-size="12" font-weight="400" fill="black" x="12.504" y="11">Aggregated keys + </tspan>
<tspan font-family="Helvetica Neue" font-size="12" font-weight="400" fill="black" x="26.778" y="25.336">Configuration</tspan>
</text>
</g>
<g id="Group_116">
<g id="Graphic_119">
<circle cx="133.66281" cy="754.186" r="12.0000191748228" fill="white"/>
<circle cx="133.66281" cy="754.186" r="12.0000191748228" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
<g id="Graphic_118">
<text transform="translate(150.8298 742.186)" fill="blue">
<tspan font-family="Helvetica" font-size="12" font-weight="400" fill="blue" x="0" y="11">R</tspan>
</text>
</g>
<g id="Graphic_117">
<path d="M 151.96781 756.186 L 155.16326 762.67225 L 158.35871 756.186 Z" fill="blue"/>
<path d="M 151.96781 756.186 L 155.16326 762.67225 L 158.35871 756.186 Z" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
</g>
<g id="Group_111">
<g id="Graphic_115">
<circle cx="55.77054" cy="754.1" r="12.0000191748228" fill="white"/>
<circle cx="55.77054" cy="754.1" r="12.0000191748228" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
<g id="Group_112">
<g id="Graphic_114">
<text transform="translate(72.18753 750.829)" fill="blue">
<tspan font-family="Helvetica" font-size="12" font-weight="400" fill="blue" x="0" y="11">R</tspan>
</text>
</g>
<g id="Graphic_113">
<path d="M 78.88944 749.8572 L 75.69399 743.371 L 72.49854 749.8572 Z" fill="blue"/>
<path d="M 78.88944 749.8572 L 75.69399 743.371 L 72.49854 749.8572 Z" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
</g>
</g>
<g id="Line_110">
<line x1="55.77054" y1="741.1" x2="55.77054" y2="709.007" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
<g id="Line_109">
<line x1="133.52668" y1="741.1867" x2="133.19582" y2="709.593" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
<g id="Line_108">
<line x1="134.13192" y1="797.5727" x2="133.80336" y2="767.1853" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
<g id="Line_107">
<line x1="56.3045" y1="797.593" x2="55.93013" y2="767.099" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
<g id="Graphic_106">
<text transform="translate(137 768.762)" fill="black">
<tspan font-family="Helvetica Neue" font-size="12" font-weight="400" fill="black" x="2.6112538" y="11">Upload/Download </tspan>
<tspan font-family="Helvetica Neue" font-size="12" font-weight="400" fill="black" x="31.939254" y="25.336">of keys</tspan>
</text>
</g>
<g id="Graphic_105">
<text transform="translate(-21 714.007)" fill="black">
<tspan font-family="Helvetica Neue" font-size="12" font-weight="400" fill="black" x="12.916" y="11">Callback </tspan>
<tspan font-family="Helvetica Neue" font-size="12" font-weight="400" fill="black" x="2.698" y="25.336">Notifications</tspan>
</text>
</g>
<g id="Graphic_120">
<text transform="translate(15 451.921)" fill="black">
<tspan font-family="Helvetica Neue" font-size="12" font-weight="400" fill="black" x="3.254" y="11">Retrieve </tspan>
<tspan font-family="Helvetica Neue" font-size="12" font-weight="400" fill="black" x="5.36" y="25.336">Results</tspan>
</text>
</g>
<g id="Group_121">
<g id="Graphic_124">
<circle cx="415.12484" cy="614" r="12.0000191748228" fill="white"/>
<circle cx="415.12484" cy="614" r="12.0000191748228" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
<g id="Graphic_123">
<text transform="translate(412.04183 629.014)" fill="blue">
<tspan font-family="Helvetica" font-size="12" font-weight="400" fill="blue" x="0" y="11">R</tspan>
</text>
</g>
<g id="Graphic_122">
<path d="M 409.3614 632.8187 L 402.87517 636.0141 L 409.3614 639.2096 Z" fill="blue"/>
<path d="M 409.3614 632.8187 L 402.87517 636.0141 L 409.3614 639.2096 Z" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
</g>
<g id="Line_125">
<line x1="428.1248" y1="614.0225" x2="665.26316" y2="614.43255" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
<g id="Line_126">
<line x1="164.49582" y1="614.43255" x2="402.12485" y2="614.0224" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
<g id="Graphic_127">
<text transform="translate(352 568.328)" fill="black">
<tspan font-family="Helvetica Neue" font-size="12" font-weight="400" fill="black" x="22.662" y="11">Upload of keys</tspan>
<tspan font-family="Helvetica Neue" font-size="12" font-weight="400" fill="black" x="5.184" y="25.336">(+TAN for Verification)</tspan>
</text>
</g>
<g id="Group_130">
<g id="Graphic_133">
<circle cx="614.8747" cy="693.5" r="12.0000191748228" fill="white"/>
<circle cx="614.8747" cy="693.5" r="12.0000191748228" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
<g id="Graphic_132">
<text transform="translate(611.79166 708.514)" fill="blue">
<tspan font-family="Helvetica" font-size="12" font-weight="400" fill="blue" x="0" y="11">R</tspan>
</text>
</g>
<g id="Graphic_131">
<path d="M 609.11124 712.3187 L 602.625 715.5141 L 609.11124 718.7096 Z" fill="blue"/>
<path d="M 609.11124 712.3187 L 602.625 715.5141 L 609.11124 718.7096 Z" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
</g>
<g id="Line_129">
<path d="M 627.8747 693.5 L 788.125 693.5 L 788.0824 647" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
<g id="Line_128">
<line x1="506.125" y1="692.8678" x2="601.8749" y2="693.4244" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
<g id="Graphic_134">
<text transform="translate(551.74984 727.514)" fill="black">
<tspan font-family="Helvetica Neue" font-size="12" font-weight="400" fill="black" x="3.216" y="11">Download of keys and </tspan>
<tspan font-family="Helvetica Neue" font-size="12" font-weight="400" fill="black" x="27.888" y="25.336">configuration</tspan>
</text>
</g>
<g id="Group_139">
<g id="Graphic_142">
<circle cx="501.629" cy="517.829" r="12.0000191748228" fill="white"/>
<circle cx="501.629" cy="517.829" r="12.0000191748228" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
<g id="Graphic_141">
<text transform="translate(498.546 532.843)" fill="blue">
<tspan font-family="Helvetica" font-size="12" font-weight="400" fill="blue" x="0" y="11">R</tspan>
</text>
</g>
<g id="Graphic_140">
<path d="M 495.8656 536.6477 L 489.37934 539.8431 L 495.8656 543.0386 Z" fill="blue"/>
<path d="M 495.8656 536.6477 L 489.37934 539.8431 L 495.8656 543.0386 Z" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
</g>
<g id="Line_138">
<line x1="514.629" y1="517.829" x2="664.6552" y2="517.829" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
<g id="Line_137">
<line x1="371" y1="517.2658" x2="488.6291" y2="517.77295" stroke="blue" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"/>
</g>
<g id="Graphic_136">
<text transform="translate(457.25627 473)" fill="black">
<tspan font-family="Helvetica Neue" font-size="12" font-weight="400" fill="black" x="2.9139095" y="11">Retrieve results </tspan>
<tspan font-family="Helvetica Neue" font-size="12" font-weight="400" fill="black" x="27.86791" y="25.336">+ TAN</tspan>
</text>
</g>
<g id="Graphic_143">
<text transform="translate(893.7727 804.365)" fill="black">
<tspan font-family="Helvetica Neue" font-size="12" font-weight="400" fill="black" x="0" y="11">Scanning</tspan>
</text>
</g>
</g>
</g>
</svg>
Side by Side

Before

Width:  |  Height:  |  Size: 58 KiB

3
images/solution_architecture/figure_10.svg
View File

File diff suppressed because one or more lines are too long
Side by Side

Before

Width:  |  Height:  |  Size: 20 KiB

3
images/solution_architecture/figure_11.svg
View File

File diff suppressed because one or more lines are too long
Side by Side

Before

Width:  |  Height:  |  Size: 20 KiB

3
images/solution_architecture/figure_12.svg
View File

File diff suppressed because one or more lines are too long
Side by Side

Before

Width:  |  Height:  |  Size: 40 KiB

3
images/solution_architecture/figure_13.svg
View File

File diff suppressed because one or more lines are too long
Side by Side

Before

Width:  |  Height:  |  Size: 16 KiB

3
images/solution_architecture/figure_14.svg
View File

File diff suppressed because one or more lines are too long
Side by Side

Before

Width:  |  Height:  |  Size: 52 KiB

3
images/solution_architecture/figure_2.svg
View File

File diff suppressed because one or more lines are too long
Side by Side

Before

Width:  |  Height:  |  Size: 47 KiB

3
images/solution_architecture/figure_3.svg
View File

File diff suppressed because one or more lines are too long
Side by Side

Before

Width:  |  Height:  |  Size: 38 KiB

3
images/solution_architecture/figure_4.svg
View File

File diff suppressed because one or more lines are too long
Side by Side

Before

Width:  |  Height:  |  Size: 35 KiB

3
images/solution_architecture/figure_5.svg
View File

File diff suppressed because one or more lines are too long
Side by Side

Before

Width:  |  Height:  |  Size: 17 KiB

1336
images/solution_architecture/figure_6.svg
View File

File diff suppressed because it is too large Load Diff
Side by Side

Before

Width:  |  Height:  |  Size: 92 KiB

3
images/solution_architecture/figure_7.svg
View File

File diff suppressed because one or more lines are too long
Side by Side

Before

Width:  |  Height:  |  Size: 40 KiB

3
images/solution_architecture/figure_8.svg
View File

File diff suppressed because one or more lines are too long
Side by Side

Before

Width:  |  Height:  |  Size: 36 KiB

3
images/solution_architecture/figure_9.old.svg
View File

File diff suppressed because one or more lines are too long
Side by Side

Before

Width:  |  Height:  |  Size: 26 KiB

1512
images/solution_architecture/figure_9.svg
View File

File diff suppressed because it is too large Load Diff
Side by Side

Before

Width:  |  Height:  |  Size: 44 KiB

3
images/solution_architecture/high_level_architecture.svg Normal file
View File

File diff suppressed because one or more lines are too long
Side by Side

After

Width:  |  Height:  |  Size: 71 KiB

3
images/solution_architecture/interaction_flow_verification.svg Normal file
View File

File diff suppressed because one or more lines are too long
Side by Side

After

Width:  |  Height:  |  Size: 46 KiB

3
images/solution_architecture/interaction_mobile_application.svg Normal file
View File

File diff suppressed because one or more lines are too long
Side by Side

After

Width:  |  Height:  |  Size: 46 KiB

3
images/solution_architecture/ios_releases.svg Normal file
View File

File diff suppressed because one or more lines are too long
Side by Side

After

Width:  |  Height:  |  Size: 17 KiB

3
images/solution_architecture/key_flow_receiving.svg Normal file
View File

File diff suppressed because one or more lines are too long
Side by Side

After

Width:  |  Height:  |  Size: 19 KiB

3
images/solution_architecture/key_flow_sending.svg Normal file
View File

File diff suppressed because one or more lines are too long
Side by Side

After

Width:  |  Height:  |  Size: 20 KiB

3
images/solution_architecture/limitations.svg Normal file
View File

File diff suppressed because one or more lines are too long
Side by Side

After

Width:  |  Height:  |  Size: 52 KiB

3
images/solution_architecture/protocol_buffer.svg Normal file
View File

File diff suppressed because one or more lines are too long
Side by Side

After

Width:  |  Height:  |  Size: 35 KiB

3
images/solution_architecture/rat_process.svg Normal file
View File

File diff suppressed because one or more lines are too long
Side by Side

After

Width:  |  Height:  |  Size: 130 KiB

3
images/solution_architecture/risk_calculation.svg Normal file
View File

File diff suppressed because one or more lines are too long
Side by Side

After

Width:  |  Height:  |  Size: 70 KiB

3
images/solution_architecture/trl_mapping.svg Normal file
View File

File diff suppressed because one or more lines are too long
Side by Side

After

Width:  |  Height:  |  Size: 48 KiB

3
images/solution_architecture/upload_schedule.svg Normal file
View File

File diff suppressed because one or more lines are too long
Side by Side

After

Width:  |  Height:  |  Size: 16 KiB

3
images/solution_architecture/verification_teletan.svg Normal file
View File

File diff suppressed because one or more lines are too long
Side by Side

After

Width:  |  Height:  |  Size: 33 KiB

0
user_journey.png → images/user_journey.png
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 54 KiB

After

Width:  |  Height:  |  Size: 54 KiB

2
overview-security.md
View File

@ -457,7 +457,7 @@ The following chapters contain a brief introduction to each capability.
- Guarantee collaboration and support by partners in case of security incident (e.g. to update or recover a system in the specified time).
- Ensure controlled, monitored and minimized access for partners.
- Ensure compliance with internal/external requirements (e.g. security checks).
- Cooperate with selected/certified suppliers (blacklist/whitelist).
- Cooperate with selected/certified suppliers (avoid/prefer list).
### Secure Development

2
pruefsteine.md
View File

@ -68,6 +68,6 @@ As a rare edge case, diagnosis keys could be attributed to a single person in ca
The Corona-Warn-App takes state of the art measures to make individual messages and communication patterns unobservable to malicious entities.
Well-established encryption mechanisms such as HTTP over TLS (HTTPS) ensure that messages are not readable for outside viewers. Metadata is removed before processing payload in diagnosis key submissions and can therefore not be linked to them on a database level. To further reduce the possibility of man-in-the-middle attacks, certificate pinning shall ensure that trusted communication only happens between the Corona-Warn-App and the server.
Well-established encryption mechanisms such as HTTP over TLS (HTTPS) ensure that messages are not readable for outside viewers. Metadata is removed before processing payload in diagnosis key submissions and can therefore not be linked to them on a database level. To further reduce the possibility of man-in-the-middle attacks, static public key pinning shall ensure that trusted communication only happens between the Corona-Warn-App and the server.
Besides shielding individual messages that are transmitted by the system, also communication patterns need to be disguised. Consider, for example, that polling for test results and submitting diagnosis keys would only happen in case of a real infection. In this case, observing network traffic would be sufficient to know that users took a SARS-CoV-2 test and had a positive result. This attack surface is mitigated by random fake messages that are indistinguishable from valid ones. This way, key submission and the retrieval of test results are indistinguishable from the system's background noise, creating plausible deniability for users even if network traffic is observed.

2
scoping_document.md
View File

@ -92,7 +92,7 @@ interactions between people that occur successively. In each phase, persons are
assigned motivations or requirements that meet their expectations of the app and
guide them intuitively through the process.
![Figure 1: User Journey](user_journey.png "User Journey")
![Figure 1: User Journey](./images/user_journey.png "User Journey")
#### *Idea* phase

224
solution_architecture.md
View File

@ -13,8 +13,9 @@ We assume a close association of a mobile phone and its user and, thus, equate t
## 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)
1. [Retrieval of lab results and verification process](#pcr-tests-retrieval-of-lab-results-and-verification-process)
2. [Rapid Antigen Tests: Result Retrieval](#rapid-antigen-tests-result-retrieval)
3. [Upload schedule for Diagnosis Keys](#upload-schedule-for-diagnosis-keys)
2. [BACKEND](#backend)
1. [Data format](#data-format)
2. [Data URL](#data-url)
@ -30,27 +31,29 @@ We assume a close association of a mobile phone and its user and, thus, equate t
## INTRODUCTION
To reduce the spread of [COVID-19](https://www.ecdc.europa.eu/en/covid-19-pandemic), it is necessary to inform people about their close proximity to positively tested individuals. So far, health departments and affected individuals have identified possibly infected individuals in personal conversations based on each individuals' memory. This has led to a high number of unknown connections, e.g. when using public transport.
To reduce the spread of [COVID-19](https://www.ecdc.europa.eu/en/covid-19-pandemic), it is necessary to inform people about their close proximity to individuals that have tested positive. Without the use of digital solutions, health departments and affected individuals can only identify possibly infected individuals in personal conversations based on each individuals' memory or through manually maintained paper lists. This has led to a high number of unknown connections, e.g. when using public transport.
![Figure 1: High-level architecture overview](images/solution_architecture/figure_1.svg "Figure 1: High-level architecture overview")
| ![Figure 1: High-level architecture overview](images/solution_architecture/high_level_architecture.svg "Figure 1: High-level architecture overview") |
|:--:|
| **Figure 1: High-level architecture overview**|
The Corona-Warn-App (see [scoping document](https://github.com/corona-warn-app/cwa-documentation/blob/master/scoping_document.md )), shown centrally in *Figure 1*, enables individuals to trace their personal exposure risk via their mobile phones. The Corona-Warn-App uses a new framework provided by Apple and Google called [Exposure Notification Framework](https://www.apple.com/covid19/contacttracing). The framework employs [Bluetooth Low Energy (BLE)](https://en.wikipedia.org/wiki/Bluetooth_Low_Energy) mechanics. BLE lets the individual mobile phones act as beacons meaning that they constantly broadcast a temporary identifier called Rolling Proximity Identifier (RPI) that is remembered and, at the same time, lets the mobile phone scan for identifiers of other mobile phones. This is shown on the right side of *Figure 1*.
Identifiers are ID numbers sent out by the mobile phones. To ensure privacy and to prevent the tracking of movement patterns of the app user, those broadcasted identifiers are only temporary and change constantly. New identifiers are derived from a Temporary Exposure Key (TEK) that is substituted at midnight (UTC) every day through means of cryptography. For a more detailed explanation, see *Figure 10*. Once a TEK is linked to a positive test result, it remains technically the same, but is then called a Diagnosis Key.
The collected identifiers from other users as well as the own keys, which can later be used to derive the identifiers, are stored locally on the phone in the secure storage of the framework provided by Apple and Google. The application cannot access this secure storage directly, but only through the interfaces the Exposure Notification Framework provides. To prevent misuse, some of these interfaces are subjected to [rate limiting](https://developer.apple.com/documentation/exposurenotification/enmanager/3586331-detectexposures). If app users are tested positively for SARS-CoV-2, they can update their status in the app by providing a verification of their test and select an option to send their recent keys from up to 14 days back. On the Corona-Warn-App back-end server, all keys of positively tested individuals are aggregated and are then made available to all mobile phones that have the app installed. Additionally, the configuration parameters for the framework are available for download, so that adjustments to the risk score calculation can be made, see the *Risk Scores* section.
Once the keys and the exposure detection configuration have been downloaded, the data is handed over to the Exposure Notification Framework, which analyzes whether one of the identifiers collected by the mobile phone matches those of a positively tested individual. Additionally, the metadata that has been broadcasted together with the identifiers such as the transmit power can now be decrypted and used. Based on the collected data, the Exposure Notification Framework provided by Apple and Google calculates a risk score for each individual exposure as well as for the overall situation. Exposures are defined as an aggregation of all encounters with another individual on a single calendar day (UTC timezone). For privacy reasons, it is not possible to track encounters with other individuals across multiple days.
The collected identifiers from other users as well as the device's own keys, which can later be used to derive the identifiers, are stored locally on the phone in the secure storage of the framework provided by Apple and Google. The application cannot access this secure storage directly, but only through the interfaces the Exposure Notification Framework provides. To prevent misuse, some of these interfaces are subjected to [rate limiting](https://developer.apple.com/documentation/exposurenotification/enmanager/3586331-detectexposures). If app users are tested positive for SARS-CoV-2, they can update their status in the app by providing a verification of their test and select an option to send their recent keys from up to 14 days back. On the Corona-Warn-App back-end server, all keys of individuals that have tested positive are aggregated and are then made available to all mobile phones that have the app installed. Additionally, the configuration parameters for the framework are available for download, so that adjustments to the risk score calculation can be made, see the *Risk Scores* section.
Once the keys and the exposure detection configuration have been downloaded, the data is handed over to the Exposure Notification Framework, which analyzes whether one of the identifiers collected by the mobile phone matches those of the device of another individual that has tested positive. Additionally, the metadata that has been broadcasted together with the identifiers such as the transmit power can now be decrypted and used. Based on the collected data, the Exposure Notification Framework provided by Apple and Google groups exposures into 30 minute "exposure windows", which in turn can be used to determine the individual risk. Exposures are defined as an aggregation of all encounters with another individual on a single calendar day (UTC timezone). For privacy reasons, it is neither possible to track encounters with other individuals across multiple days, nor to link individual exposure windows to each other.
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.
It is important to note that the persons that have been exposed to a positive 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.
1. It supports individuals in finding out whether they have been exposed to a person that has later been tested positive.
2. It receives the result of a SARS-CoV-2 test on a user's mobile phone through an online system. This helps reduce the time until necessary precautions, e.g. a contact reduction and testing, can be taken.
In order to prevent misuse, individuals need to provide proof that they have been tested positively before they can upload their keys. Through this integrated approach, the verification needed for the upload of the diagnosis keys does not require any further action from the users.
In order to prevent misuse, individuals need to provide proof that they have been tested positive before they can upload their keys. Through this integrated approach, the verification needed for the upload of the diagnosis keys does not require any further action from the users.
They only have to confirm in the app and for the Exposure Notification Framework that they agree to share their diagnosis keys. Manual verification is also possible if the lab that performed the testing does not support the direct electronic transmission of test results to the users' mobile phones or if users have decided against the electronic transmission of their test results.
### Retrieval of Lab Results and Verification Process
### PCR tests: Retrieval of Lab Results and Verification Process
Reporting positive tests to the Corona-Warn-App is crucial for informing others about a relevant exposure and potential infection. However, to prevent misuse, a verification is required before diagnosis keys can be uploaded.
There are two ways for receiving this verification:
@ -58,11 +61,13 @@ There are two ways for receiving this verification:
1. Using the integrated functionality of the Corona-Warn-App to retrieve the results of a SARS-CoV-2 test from a verification server (see Figure 2, Step 4a). With this integration, the positive test result is already verified and the diagnosis keys can be uploaded right after the users have given their consent.
2. Providing a human-readable token, e.g. a number or a combination of words, as verification to the app. This token is called teleTAN (see Figure 2, Step 4b).
![Figure 2: Interaction flow for verification process](images/solution_architecture/figure_2.svg "Figure 2: Interaction flow for verification process")
| ![Figure 2: Interaction flow for verification process](images/solution_architecture/interaction_flow_verification.svg "Figure 2: Interaction flow for verification process") |
|:--:|
| **Figure 2: Interaction flow for verification process**|
*Figure 2* and *Figure 3* illustrate the verification process. *Figure 2* shows the interaction flow of the user and *Figure 3* the flow and storage of data. Additions to the preexisting 'conventional' process through the introduction of the Corona-Warn-App and the integrated test result retrieval are marked blue in *Figure 2*.
This preexisting process for the processing of lab results includes that the doctor requesting the test also receives the results, so patients can be informed in a timely manner. As required by law ([§9 IfSG](https://www.gesetze-im-internet.de/ifsg/__9.html)), the responsible health authority (“Gesundheitsamt”) is notified by the lab about the test results as well. The notifications in case of a positive test includes, amongst others, the name, address, and date of birth of the positively tested individuals, so that they can be contacted and informed about the implications of their positive test. This is also represented in step 3 of *Figure 2*.
This preexisting process for the processing of lab results includes that the doctor requesting the test also receives the results, so patients can be informed in a timely manner. As required by law ([§9 IfSG](https://www.gesetze-im-internet.de/ifsg/__9.html)), the responsible health authority (“Gesundheitsamt”) is notified by the lab about the test results as well. The notifications in case of a positive test includes, amongst others, the name, address, and date of birth of the positive tested individuals, so that they can be contacted and informed about the implications of their positive test. This is also represented in step 3 of *Figure 2*.
The flow for using the app is as follows, referencing the steps from *Figure 2*:
@ -81,13 +86,17 @@ The TAN is used as authorization in the HTTP header of the POST request for uplo
- 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")
| ![Figure 3: Data flow for the verification process](images/solution_architecture/data_flow_verification.svg "Figure 3: Data flow for the verification process") |
|:--:|
| **Figure 3: Data flow for the verification process**|
Note regarding *Figure 3* and *Figure 4*: The white boxes with rounded corners represent data storage. The HTTP method POST is used instead of GET for added security, so data (e.g. the registration token) can be transferred in the body.
As mentioned before, users might have decided against retrieving test results electronically, or the lab may not support the electronic process. Step 3 of *Figure 2* shows that in these cases the health authority (“Gesundheitsamt”) reaches out to the patient directly. Also during this conversation, the teleTAN can be provided to the patient, which can be used to authorize the upload of diagnosis keys from the app to the Corona-Warn-App Server (step 4b of *Figure 2*). This process is also visualized in *Figure 4*. Whenever patients are contacted regarding a positive test result, they can choose to receive a teleTAN. The teleTAN is retrieved from the web interface (*Figure 4*, step 1) of the portal service by a public health officer. This service in turn is requesting it from the Verification Server (2-3). The teleTAN is then issued to the officer (4-5) who transfers it to the patient (6). Once the patient has entered the teleTAN into the app (7), it uses the teleTAN to retrieve a registration token from the Verification Server (8-10). Once the user has confirmed the upload of the Diagnosis Keys, the application requests a TAN from the server, using the registration token (11-13). This TAN is needed by the server to ensure that the device is allowed to do the upload. These TANs are not visible to the user. After uploading the TAN and the diagnosis keys to the Corona-Warn-App Server (14), the Corona-Warn-App Server can verify the authenticity of the TAN with the Verification Server (15-16) and upon receiving a confirmation, store the diagnosis keys in the database (17).
![Figure 4: Verification process for teleTAN received via phone](images/solution_architecture/figure_4.svg "Figure 4: Verification process for teleTAN received via phone")
| ![Figure 4: Verification process for teleTAN received via phone](images/solution_architecture/verification_teletan.svg "Figure 4: Verification process for teleTAN received via phone") |
|:--:|
| **Figure 4: Verification process for teleTAN received via phone**|
The retrieval of the registration token ensures a coupling between a specific mobile phone and a GUID/teleTAN, preventing others (even when they have the QR code) to retrieve test results and/or to generate a TAN for uploading diagnosis keys. Upon the first connection with the Verification Server, a registration token is generated on the server and sent back to the client. In the information they receive, the patients should be asked to scan the QR code as soon as possible, as all further communication between client and server only uses the registration token which can only be created once.
If a user deletes and reinstalls the app, the stored registration token is lost, making it impossible to retrieve the test results. In this case the fallback with the health authority workflow (through a hotline) needs to be used.
@ -95,76 +104,101 @@ From a privacy protection perspective, sending push notifications via Apple’s
If a user did not receive a teleTAN from the health authority and/or has lost the QR code, a teleTAN needs to be retrieved from a hotline. The hotline ensures that users are permitted to perform an upload before issuing the teleTAN. It is then used as described before, starting from *Figure 4*, step 7.
### Rapid Antigen Tests: Result Retrieval
While the PCR tests described before require a laboratory to receive the test results, Rapid Antigen Tests (RAT) can be evaluated shortly after taking the sample, at the Point of Care (PoC). Also the results for those Rapid Antigen Tests shall be transmitted to the Corona-Warn-App installed on the users' phones, so they can subsequently be used to warn others.
As the infrastructure for Rapid Antigen Tests is more distributed in comparison to PCR tests (i.e. locally and with regards to the operators: mobile test locations at venues, workplaces, etc., ), also the infrastructure for transmitting the test results needs to operate in a distributed way.
| ![Figure 5: End-to-end overview for Rapid Antigen Tests](images/solution_architecture/rat_process.svg "Figure 5: End-to-end overview for Rapid Antigen Tests") |
|:--:|
| **Figure 5: End-to-end overview for Rapid Antigen Tests**|
The overview contains two processes, one is part of the CWA scope, while the other belongs to a third party (the test provider).
The process flow shown assumes that users schedule an appointment on the provider's infrastructure (step 1-2), which is assigned an internal ID specific to the provider (step 3).
The backend is then able to calculate a CWA Test ID (step 4) by applying a hash algorithm. Depending on the choice of the users, personal data may or may not be used to calculate the hash.
The backend may then return a confirmation, which is then used to provide a QR-Code and/or link. With this QR-Code/link users can add the Rapid Antigen Test to their Corona-Warn-Apps.
The CWA Test ID can then be validated locally (not as a means of security, but to make sure it is a valid code) using the exact same hashing algorithm as used on the backend (step 7).
The test is then registered on the CWA infrastructure (step 8-11). The testing process itself, including the transmission to the providers backend (steps 12-20) takes place independently from the CWA infrastructure.
The test result is linked to the CWA Test ID and transmitted to the CWA infrastructure (step 21-22).
### Upload Schedule for Diagnosis Keys
According to the current version of the documentation from Apple and Google (1.3), the first set of up to 14 Temporary Exposure Keys (TEK; called Diagnosis Keys when linked to a positive test) needs to be uploaded after the positive test result becomes available and the consent to the upload has been given (see (1) in *Figure 5*). As the TEK of the current day can still be used to generate new RPIs, it cannot be made available right away. If it was uploaded before the end of the day, malicious third parties could use it to generate valid RPIs linked to a positive test. Instead, once it is uploaded, it is replaced by a new TEK (see (2) in *Figure 5*). This upload takes place in the background and requires no additional consent as the framework grants a 24-hour grace period for the request of Diagnosis Keys.
A set of up to 15 Temporary Exposure Keys (TEK; called Diagnosis Keys when linked to a positive test) needs to be uploaded after the positive test result becomes available. The consent might have either been given when registering the test or after receiving the positive test result.
In order to prevent that the TEK of the current day can be used to generate new RPIs after the submission, it is uploaded with a shorter validity (only until the point of submission) in comparison to the other Diagnosis Keys. To make sure that malicious third parties cannot use it to generate valid RPIs linked to a positive test, uploaded keys are not published immediately, but only after a defined safety period.
![Figure 5: Upload schedule for Temporary Exposure Keys (Diagnosis Keys)](images/solution_architecture/figure_5.svg "Figure 5: Upload schedule for Temporary Exposure Keys (Diagnosis Keys)")
| ![Figure 6: Upload schedule for Temporary Exposure Keys (Diagnosis Keys)](images/solution_architecture/upload_schedule.svg "Figure 6: Upload schedule for Temporary Exposure Keys (Diagnosis Keys)") |
|:--:|
| **Figure 6: Upload schedule for Temporary Exposure Keys (Diagnosis Keys)**|
As users are not required to confirm negative test results, the functionality of uploading Diagnosis Keys on subsequent days remains theoretical. Each of those uploads could take place earliest at the end of each subsequent day (see (3) in *Figure 5*). It would require explicit consent of the user for each day and could take place up to the time when the person is not considered contagious anymore (but not any longer, as this would lead to false positives).
As users are not required to confirm negative test results, the functionality of uploading Diagnosis Keys on subsequent days remains theoretical. Each of those uploads could take place earliest at the end of each subsequent day (see (2) in *Figure 6*). It would require explicit consent of the user for each day and could take place up to the time when the person is not considered contagious anymore (but not any longer, as this would lead to false positives).
As of now, two uploads are required from the same mobile phone (past diagnosis keys and from the current day). This means, the registration token may not be invalidated after the first upload, but must remain active. The TANs sent to the Corona-Warn-App Server are only valid for a single use. In case of the teleTAN, an additional registration token is created which then allows the app to retrieve TANs for individual uploads.
## Backend
## Back End
![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)")
| ![Figure 7: Actors in the system, including external parties (blue components to be open-sourced)](images/solution_architecture/actors_in_the_system.svg "Figure 7: Actors in the system, including external parties (blue components to be open-sourced)") |
|:--:|
| **Figure 7: 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 7*.
- Accept uploaded diagnosis keys and store them (optional) together with the corresponding information (days since onset of symptoms/transmission risk level ) into the database. Note that the transport of connection 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 7*.
- Provide [configuration parameters](#data-format) to the mobile applications
- Threshold values for [attenuation buckets](#attenuation-buckets)
- Risk scores for defined values
- Encoding and mapping of the Transmission Risk Level
- Threshold values for risk categories and alerts
- Weight mappings for the ENF (not used, but need to be present)
- Valid country codes for EFGS Visited Countries
- 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)
- Transfer files to a storage service as shown at the bottom of *Figure 7* which acts as a source for the Content Delivery Network (CDN)
- Handle the integration with the [European Federation Gateway Service](https://github.com/eu-federation-gateway-service/efgs-federation-gateway) which consists of:
- Downloading keys which are shared from connected countries and making them available for use by the CWA Mobile applications
- Upload relevant keys for DE to the service to share with other connected countries
- Expose a callback API which can be used by the EFGS to notify CWA when new key batches are available for download
- Handle the translation of keys values for DSOS and TRL
Those tasks relevant for interaction with the CWA Mobile application are visualized in *Figure 7*. Each of swim lanes (vertical sections of the diagram) on the left side (Phone 1, Phone 2, Phone n) represents 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.
Those tasks relevant for interaction with the CWA Mobile application are visualized in *Figure 8*. Each of the swim lanes (vertical sections of the diagram) on the left side (Phone 1, Phone 2, Phone n) represents 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.
![Figure 7: Interaction of the mobile application(s) with the back-end servers and CDN](images/solution_architecture/figure_7.svg "Figure 7: Interaction of the mobile application(s) with the back-end servers and CDN")
| ![Figure 8: Interaction of the mobile application(s) with the back-end servers and CDN](images/solution_architecture/interaction_mobile_application.svg "Figure 8: Interaction of the mobile application(s) with the back-end servers and CDN") |
|:--:|
| **Figure 8: Interaction of the mobile application(s) with the back-end servers and CDN**|
Note that even if a user has not been tested positive, the app randomly submits requests to the Corona-Warn-App Server (represented in *Figure 7* by Phone 2) which on the server side can easily be ignored, but from an outside perspective exactly looks as if a user has uploaded positive test results. This helps to preserve the privacy of users who are actually submitting their diagnosis keys due to positive test results. Without dummy requests, a malicious third party monitoring the traffic could easily find out that users uploading something to the server have been infected. With our approach, no pattern can be detected and, thus, no assumption can be taken.
If diagnosis keys need to be uploaded on subsequent days of the submission of a positive test result, also that behavior should be represented within the random (dummy) submissions.
Note that even if a user has not been tested positive, the app randomly submits requests to the Corona-Warn-App Server (represented in *Figure 8* by Phone 2) which on the server side can easily be ignored, but from an outside perspective exactly looks as if a user has uploaded positive test results. This helps to preserve the privacy of users who are actually submitting their diagnosis keys due to positive test results. Without dummy requests, a malicious third party monitoring the traffic could easily find out that users uploading something to the server have been infected. With our approach, no pattern can be detected and, thus, no assumption can be taken.
It could be possible to identify temporary exposure keys that belong together, i.e. belong to the same user, because they are posted together which results in them being in a sequential order in the database.
To prevent this, the aggregated files are shuffled, e.g. by using an ORDER BY RANDOM on the database while fetching the data for the corresponding file.
Alternatively, returning them in the lexicographic order of the RPIs (which are random) is a valid option as well. The latter might be more efficient for compressing the data afterwards.
The configuration parameters mentioned above allow the health authorities to dynamically adjust the behavior of the mobile applications to the current epidemiological situation. For example, the risk score thresholds for the risk levels can be adjusted, as well as how the individual data from exposure events influence the overall score.
The configuration parameters mentioned above allow the health authorities to dynamically adjust the behavior of the mobile applications to the current epidemiological situation. For example, the risk score thresholds for the risk levels can be adjusted, as well as how the individual data from exposure events influence the overall outcome of the risk assessment.
Further information can be found in the dedicated architecture documents for the Corona-Warn-App Server, the Verification Server, and the Portal Server. The documents will be linked here, as soon as they are available.
Further information can be found in the dedicated architecture documents for the [Corona-Warn-App Server](https://github.com/corona-warn-app/cwa-server/blob/main/docs/ARCHITECTURE.md), the Verification Server, and the Portal Server.
### Data Format
The current base unit for data chunks will be one hour. Data will be encoded in the protocol buffer format as specified by Apple and Google (see *Figure 8*). It is planned that in case a data chunk does not hold any or too few diagnosis keys, the chunk generation will be skipped.
The current base unit for data chunks is one hour. Data is encoded in the protocol buffer format as specified by Apple and Google (see *Figure 9*). In case a data chunk does not hold any or too few diagnosis keys, the chunk generation will be skipped and the keys are made available as soon as the threshold has been passed.
The server will make the following information available through a RESTful interface:
The server makes the following information available through a RESTful interface:
- Available items through index endpoints (not all implemented in first iteration)
- Available items through index endpoints
- 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
- Parameters for configuring the risk 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.
Return data needs to be signed and needs to 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.
In order to ensure the authenticity of the files, they need to be signed (according to the specifications of the API) on server side with a private key, while the app uses the public key to verify that signature. To ensure roaming qualities (protocol interoperability with servers in other geographical regions), it is planned to move to a single agreed protocol once finally defined.
In order to ensure the authenticity of the files, they need to be signed (according to the specifications of the API) on server side with a private key, while the app uses the public key to verify that signature. Exchange with other geographical regions takes place through the European Federation Gateway.
![Figure 8: Data format (protocol buffer) specified by Apple/Google](images/solution_architecture/figure_8.svg "Figure 8: Data format (protocol buffer) specified by Apple/Google")
| ![Figure 9: Data format (protocol buffer) specified by Apple/Google](images/solution_architecture/protocol_buffer.svg "Figure 9: Data format (protocol buffer) specified by Apple/Google") |
|:--:|
| **Figure 9: Data format (protocol buffer) specified by Apple/Google**|
### Data URL
@ -180,67 +214,75 @@ The data on all involved servers is only retained as long as required. Diagnosis
## MOBILE APPLICATIONS
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*.
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 8*.
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 Apple devices an OS version of at least 12.5 (for older devices) or 13.7 is required for the system to work, as the framework is integrated into the operating system (see Figure 10).
For Android devices, the features will be integrated into the [Google Play Services](https://9to5google.com/2020/04/13/android-contact-tracing-google-play-services/), which means that only this specific application needs to be updated for it to work. Devices starting with Android 6.0 (API version 23) and integrated BLE chips will be [supported](https://developers.google.com/android/exposure-notifications/exposure-notifications-api#architecture).
| ![Figure 10: iOS Releases and ENF Support](images/solution_architecture/ios_releases.svg "Figure 10: iOS Releases and ENF Support") |
|:--:|
| **Figure 10: iOS Releases and ENF Support**|
![Figure 9: Architecture overview of the mobile application (focused on API usage/BLE communication)](images/solution_architecture/figure_9.svg "Figure 9: Architecture overview of the mobile application (focused on API usage/BLE communication)")
For Android devices, the features are integrated into the [Google Play Services](https://developers.google.com/android/exposure-notifications/exposure-notifications-api#architecture), 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 are [supported](https://developers.google.com/android/exposure-notifications/exposure-notifications-api#architecture).
| ![Figure 11: Architecture overview of the mobile application (focused on API usage/BLE communication)](images/solution_architecture/architecture_overview.svg "Figure 11: Architecture overview of the mobile application (focused on API usage/BLE communication)") |
|:--:|
| **Figure 11: Architecture overview of the mobile application (focused on API usage/BLE communication)**|
The app itself does not have access to the collected exposures, i.e. the Rolling Proximity Identifiers, and neither is it informed if a new one has been collected by the framework. As depicted in the *Figure 10* and *Figure 11*, the Exposure Notification encapsulates handling of the keys, including all cryptographic operations on them. The only output of the black box upon an infection is a collection of temporary exposure keys as shown in *Figure 10*. Those are subsequently called diagnosis keys.
![Figure 10: Key flow from the sending perspective (as described in the specification by Apple/Google)](images/solution_architecture/figure_10.svg "Figure 10: Key flow from the sending perspective (as described in the specification by Apple/Google)")
| ![Figure 12: Key flow from the sending perspective (as described in the specification by Apple/Google)](images/solution_architecture/key_flow_sending.svg "Figure 12: Key flow from the sending perspective (as described in the specification by Apple/Google)") |
|:--:|
| **Figure 12: Key flow from the sending perspective (as described in the specification by Apple/Google)**|
The encapsulation especially applies to the part where matches are calculated, as the framework only accepts the diagnosis keys as input, matches them to (internally stored) RPIs and returns a list of exposure events without a link to the corresponding Rolling Proximity Identifiers (see *Figure 11*). With the use of the corresponding Associated Encrypted Metadata Key, the Associated Encrypted Metadata (AEM) of the captured RPI can be decrypted. This metadata contains the transmission power (which is used to calculate the attenuation). Additionally, an epoch (usually a 24 hour window) for the exposure is determined, as well as the duration of the exposure in 5-minute increments (capped at 30 minutes).
The encapsulation especially applies to the part where matches are calculated, as the framework only accepts the diagnosis keys as input, matches them to (internally stored) RPIs and returns a list of exposure events without a link to the corresponding Rolling Proximity Identifiers (see *Figure 12*). With the use of the corresponding Associated Encrypted Metadata Key, the Associated Encrypted Metadata (AEM) of the captured RPI can be decrypted. This metadata contains the transmission power (which is used to calculate the attenuation). The Exposure Notification Framework assembles exposures into 30-minute-windows per other device and 24-hour epoch. Those windows contain additional details for individual scan instances, which will be explained later.
![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)")
| ![Figure 13: Key flow from the receiving perspective (as described in the specification by Apple/Google)](images/solution_architecture/key_flow_receiving.svg "Figure 13: Key flow from the receiving perspective (as described in the specification by Apple/Google)") |
|:--:|
| **Figure 13: 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
All exposure events are collected by the ENF internally and are split up into "Exposure Windows", which represent all instances where one other specific device (without known identity) has been detected within a 30 minute window. If an encounter lasted for more then 30 minutes, multiple exposure windows are derived. Those cannot be related to each other neither can it be determined in which order (and possible overlap), exposures windows have occurred. This means that if for example five exposure windows are presented to the app by the ENF, it cannot be determined whether those have been five different devices or a single other device with 2.5 hours of contact. Same applies to the timely arrangement, i.e. all windows could have happened in parallel, with partial overlap or after one another.
| ![Figure 14: Exposure Windows](images/solution_architecture/exposure_windows.svg "Figure 14: Exposure Windows") |
|:--:|
| **Figure 14: Exposure Windows**|
Each exposure window contains the following information:
- **infectiousness** and **report type** parameters, defined by the sending app
- **day of the exposure**
- **multiple scan instances**, i.e. occurrences, where the other device has been actively identified during the scanning process
### Attenuation Buckets
Both, Apple and Google allow to define a low and a high threshold for the attenuation, forming three individual buckets:
While in the first version of the Exposure Notification Framework, Apple and Google allowed to define multiple thresholds for the attenuation, this functionality can now be implemented within the application through the data from the exposure windows.
- Attenuation < low threshold
- Low threshold <= attenuation < high threshold
- High threshold <= attenuation
Currently, the application forms four attenuation ranges (sometimes also called "buckets"), which have a specific weight applied:
While in the Google implementation of the Exposure Notification Framework, those buckets are contained within the `ExposureSummary` (`attenuationDurations`), Apple has added them to the [`metadata`](https://developer.apple.com/documentation/exposurenotification/enexposureinfo/3586326-metadata) attribute of the [`ENExposureInfo`](https://developer.apple.com/documentation/exposurenotification/enexposureinfo).
In the latter implementation, the [`attenuationDurations`](https://developer.apple.com/documentation/exposurenotification/enexposureinfo/3586325-attenuationdurations) of the `ENExposureInfo` contains two buckets around a fixed threshold of 50.
- Very far
- Far
- Medium
- Close
### Risk Score Calculation
### Risk Calculation
The information listed above is not visible to the user, but is used internally to calculate a risk score, which again is mapped to one specific app-defined risk level. This easy-to-understand risk level is displayed to the user. Further information regarding the individual exposure events (such as the matched Rolling Proximity Identifier, the Temporary Exposure Key or the exact time) remains within the secure storage of the framework and cannot be retrieved by the application.
![Figure 12: Risk calculation](images/solution_architecture/figure_12.svg "Figure 12: Risk calculation")
| ![Figure 15: Value mapping during the risk calculation](images/solution_architecture/trl_mapping.svg "Figure 15: Value mapping during the risk calculation") |
|:--:|
| **Figure 15: Value mapping during the risk calculation**|
*Figure 12* displays how the total risk score is being calculated. The application is provided with a set of parameters, which are marked in blue within the figure.
The Exposure Notification framework allows to attach as "days since onset of symptoms" parameter to the diagnosis key while uploading them to the server. As this parameter strongly influences the infectiousness during an encounter, it is also used in the risk calculation. However, the ENF only allows a translation from the DSOS to either "no risk" (0), "low risk" (1) or "high risk" (2). To allow a more fine grained interpretation of the exposure windows, the additional parameter "report type" (four possible values) is used to derive an internal "Transmission Risk Level" with eight possible values. Of those eight values, two are dropped by the ENF automatically, as the report type "recursive" might be dropped in current implementations. It is important to understand, that the field "report type" does not correspond to the actual report type, but is only technically used as a 2 bit field. The mapping is also shown in Figure 15.
| ![Figure 16: Risk calculation](images/solution_architecture/risk_calculation.svg "Figure 16: Risk calculation") |
|:--:|
| **Figure 16: Risk calculation**|
*Figure 16* displays how the total risk score is being calculated. The application is provided with a set of parameters, which are marked in blue within the figure.
Those parameters are regularly downloaded from the CWA Server, which means they can be modified without requiring a new version of the application (see [`exposure-config.yaml`](https://github.com/corona-warn-app/cwa-server/blob/master/services/distribution/src/main/resources/main-config/exposure-config.yaml) for details).
Each of the four risk categories (days since exposure, exposure duration, weighted signal attenuation, and the transmission risk factor) receives an input value from the event which is then mapped to a predefined input value interval.
Each of those input value intervals is then assigned a risk score from 0-8, where 0 represents a very low risk and 8 represents a very high risk. This means that from each of the rows in the figure, one value is selected according to the input value for the corresponding category. As an example: an exposure duration input value of D=15.3 minutes is mapped to the interval 15 < D <= 20, which in the current implementation has a value of 1 assigned to it, i.e. the *Exposure Risk* would be equal to 1 in this example. The product of the four risk scores is used as the **total risk score** of the individual exposure.
According to the [documentation of the framework](https://developer.apple.com/documentation/exposurenotification/enexposureconfiguration), "the attenuation is weighted by the duration at each risk level and averaged for the overall duration". In order to incorporate the time spent within the ranges of attenuation buckets mentioned before, each of those three buckets is assigned a weight value as shown in *Figure 13*.
The individual time values are multiplied with their according weight (*weight_1*, *weight_2* and *weight_3*).
Their sum and a default bucket offset (called *weight_4* in *Figure 13*) forms the *Exposure Score*.
Finally, the maximum of the *total risk score* over all the considered events, i.e. the largest risk score, is normalized and then multiplied with the above exposure score. The resulting product of the *exposure score* and the *normalized maximum total risk score* then forms the so called **combined risk score**.
The combined risk score is used to determine which defined risk level should be displayed to the user, e.g. “low risk” or “high risk”. For this decision, [app-defined thresholds](https://github.com/corona-warn-app/cwa-server/blob/master/services/distribution/src/main/resources/main-config/risk-score-classification.yaml) for the individual risk levels apply.
As the values above are multiplied with each other, a single category with a risk score of 0 means that the overall risk score is also 0.
Additionally, a central threshold for the combined risk score specifies whether an exposure event should be considered or not.
Furthermore the Google/Apple framework allows to set a [```minimalRiskScore```](https://developer.apple.com/documentation/exposurenotification/enexposureconfiguration/3583692-minimumriskscore) to exclude exposure incidents with scores lower than the value of this property.
In the current version of the API the time spent within the ranges of attenuation buckets are accumulated over all exposure incidents during one matching session.
Since the number of requests is currently limited, it is not possible to get these values for each day and each exposure incident separately.
While by default there is no minimum value set, this value is being configured accordingly, so that presumably irrelevant exposure incidents are excluded.
![Figure 13: Calculation of the combined risk score](images/solution_architecture/figure_13.svg "Figure 13: Calculation of the combined risk score")
As mentioned before, the individual scan instances from the exposure windows are weighted according to the weight attached to the individual bucket. When those individual instances are summed up, they can be multiplied with a transmission risk value (which in turn is derived from the TRL described before). The result is one normalized exposure time per day. If those times are summed up, the overall risk can be determined, as shown in *Figure 16*.
Note that the transmission risk level plays a special role in the above calculations: It can be defined by the app and be associated with each individual diagnosis key (i.e. specific for each day of an infected person) that is being sent to the server. It contains a value from 1 to 8, which can be used to represent a calculated risk defined by the health authority. As an example it could contain an estimate of the infectiousness of the potential infector at the time of contact and, hence, the likelihood of transmitting the disease. The specific values are defined as part of the [app](https://github.com/corona-warn-app/cwa-app-android/blob/master/Corona-Warn-App/src/main/java/de/rki/coronawarnapp/util/ProtoFormatConverterExtensions.kt) - a motivation of the parameter choices is found in the document [Epidemiological Motivation of the Transmission Risk Level](https://github.com/corona-warn-app/cwa-documentation/blob/master/transmission_risk.pdf).
@ -264,7 +306,7 @@ Further details can be found in the dedicated architecture documents for the mob
## RUNTIME ENVIRONMENT (HOSTING)
The back end will be made available through the [Open Telekom Cloud (OTC)](https://open-telekom-cloud.com/).
The back end is made available through the [Open Telekom Cloud (OTC)](https://open-telekom-cloud.com/).
For the operation of the back end, several bandwidth estimations need to be taken. As a high adoption rate of the app is an important requirement, we are considering up to 60 million active users.
@ -278,16 +320,20 @@ If the back end calls from the mobile applications cannot be spread as evenly as
A definite prerequisite for compatibility is that the identifiers of the mobile devices can be matched, i.e. the GAEN framework by Apple and Google is being used.
[Most European countries are developing similar contact tracing apps](https://ec.europa.eu/info/live-work-travel-eu/health/coronavirus-response/travel-during-coronavirus-pandemic/mobile-contact-tracing-apps-eu-member-states_en). These apps may use the common frameworks by Google and Apple, enabling transmission and detection of GAEN format diagnosis keys between devices running different contact tracing applications.
[Most European countries are developing similar contact tracing apps](https://ec.europa.eu/info/live-work-travel-eu/coronavirus-response/travel-during-coronavirus-pandemic/mobile-contact-tracing-apps-eu-member-states_en). These apps may use the common frameworks by Google and Apple, enabling transmission and detection of GAEN format diagnosis keys between devices running different contact tracing applications.
Each country has its own separate database, which contains the keys from infected individuals. In order to coordinate exposure information between countries, a common service is required to enable interoperability.
The [European Federation Gateway Service (EFGS)](https://github.com/eu-federation-gateway-service/efgs-federation-gateway) enables interoperability of diagnosis keys between the connected country backend servers.
![Figure 15: High-level EFGS overview](images/solution_architecture/EFGS_overview.jpg "Figure 15: High-level EFGS overview")
| ![Figure 17: High-level EFGS overview](images/solution_architecture/EFGS_overview.jpg "Figure 17: High-level EFGS overview") |
|:--:|
| **Figure 17: High-level EFGS overview**|
The Federation Gateway Service facilitates backend-to-backend integration. Countries can onboard incrementally, while the national backends retain flexibility and control over data distribution to their users.
For example, if a German citizen visits France and then becomes infected, the keys of the German citizen are then relevant for the citizens of France. In this case the German citizen keys would be shared with the EFGS to enable the French backend to obtain the keys. Similarly, if a French user is visiting Germany, that user's keys are of relevance to the German database.
For example, if a German citizen visits Italy and then becomes infected, the keys of the German citizen are then relevant for the citizens of Italy. In this case the German citizen keys would be shared with the EFGS to enable the French backend to obtain the keys. Similarly, if a French user is visiting Germany, that user's keys are of relevance to the German database.
![Figure 16: Autonomous National Backend](images/solution_architecture/EFGS_Autonomous_Backend.jpg "Figure 16: Autonomous National Backend")
| ![Figure 18: Autonomous National Backend](images/solution_architecture/EFGS_Autonomous_Backend.jpg "Figure 18: Autonomous National Backend") |
|:--:|
| **Figure 18: Autonomous National Backend**|
In the example above, user A from country A travels to country B and afterwards tests positive. Only the relevant users (those which came within proximity of the infected user A) in Country B will receive the alert.
Devices only communicate with their country's backend. That country's backend is then responsible to send relevant keys to the EFGS.
@ -297,13 +343,15 @@ In order for the EFGS to function correctly, all users must specify their visite
## LIMITATIONS
Even though the system can support individuals in finding out whether they have been in proximity with a person that has been tested positively later on, the system also has limits (shown in *Figure 14*) that need to be considered. One of those limitations is that while the device constantly broadcasts its own Rolling Proximity Identifiers, it only listens for others in defined time slots. Those [listening windows are currently up to five minutes](https://covid19-static.cdn-apple.com/applications/covid19/current/static/contact-tracing/pdf/ExposureNotification-BluetoothSpecificationv1.2.pdf) apart and are defined as being only very short. In our considerations we expect the windows to have a length of two to four seconds. For the attenuation, the two buckets provided by the framework are being considered. A lower attenuation means that the other device is closer; we assume that an attenuation <58 dB translates to a distance below two meters. A higher attenuation might either mean that the other device is farther away (i.e. a distance of more than two meters) or that there is something between the devices blocking the signal. This could be objects such as a wall, but also humans or animals.
Even though the system can support individuals in finding out whether they have been in proximity with a person that has been tested positive later on, the system also has limits (shown in *Figure 19*) that need to be considered. One of those limitations is that while the device constantly broadcasts its own Rolling Proximity Identifiers, it only listens for others in defined time slots. Those listening windows are three minutes apart and are defined as being only very short. In our considerations we expect the windows to have a length of four seconds. A lower attenuation means that the other device is closer, while a higher attenuation might either mean that the other device is farther away (e.g. a distance of more than two meters) or that there is something between the devices blocking the signal. This could be objects such as a wall, but also humans or animals.
![Figure 14: Limitations of the Bluetooth Low Energy approach](images/solution_architecture/figure_14.svg "Figure 14: Limitations of the Bluetooth Low Energy approach")
| ![Figure 19: Limitations of the Bluetooth Low Energy approach](images/solution_architecture/limitations.svg "Figure 19: Limitations of the Bluetooth Low Energy approach") |
|:--:|
|**Figure 19: Limitations of the Bluetooth Low Energy approach**|
In *Figure 14*, this is visualized, while focusing on the captured Rolling Proximity Identifiers by only a single device. We are assuming that devices broadcast their own RPI every 250ms and use listening windows with a length of two seconds, five minutes apart. There are five other active devices – each representing a different kind of possible exposure. In the example, devices 3 and 4 go completely unnoticed, while a close proximity with the user of device 2 cannot be detected. In contrast to that very brief, but close connection with the user of device 5 (e.g. only brushing the other person in the supermarket) is noticed and logged accordingly. The duration and interval of scanning needs to be balanced by Apple and Google against battery life, as more frequent scanning consumes more energy.
In *Figure 19*, this is visualized, while focusing on the captured Rolling Proximity Identifiers by only a single device. We are assuming that devices broadcast their own RPI every 250ms and use listening windows with a length of four seconds, three minutes apart. There are five other active devices – each representing a different kind of possible exposure. In the example, devices 3 and 4 go completely unnoticed, while a close proximity with the user of device 2 cannot be detected. In contrast to that very brief, but close connection with the user of device 5 (e.g. only brushing the other person in the supermarket) is noticed and logged accordingly. The duration and interval of scanning needs to be balanced by Apple and Google against battery life, as more frequent scanning consumes more energy.
It must be noted that some of the encounters described above are corner cases. While especially the cases with a very short proximity time cannot be detected due to technical limitations, the framework will be able to detect longer exposures. As only exposures of longer duration within a certain proximity range are considered relevant for the intended purpose of this app, most of them will be covered.
It must be noted that some of the encounters described above are corner cases. While especially the cases with a very short proximity time cannot be detected due to technical limitations, the framework is able to detect longer exposures. As only exposures of longer duration within a certain proximity range are considered relevant for the intended purpose of this app, most of them are covered.
## PRIVACY-PRESERVING DATA DONATION
@ -331,4 +379,6 @@ The authenticity proof is OS-specific and uses native capabilities:
The following diagram shows the individual components and their interaction:
![Corona-Warn-App Components](images/solution_architecture/device_attestation.svg "Privacy-preserving Data Donation")
| ![Figure 20: Privacy-preserving Data Donation](images/solution_architecture/device_attestation.svg "Figure 20: Privacy-preserving Data Donation") |
|:--:|
| **Figure 20: Privacy-preserving Data Donation**|

2
translations/pruefsteine.de.md
View File

@ -68,6 +68,6 @@ In einem seltenen Grenzfall könnten Diagnoseschlüssel auf eine Einzelperson zu
Die Maßnahmen der Corona-Warn-App, mit denen gewährleistet wird, dass einzelne Nachrichten und Kommunikationsmuster nicht von Angreifern beobachtet werden können, entsprechen dem aktuellen Stand der Technik.
Etablierte Verschlüsselungsmechanismen wie HTTP over TLS (HTTPS) stellen sicher, dass Nachrichten von außen nicht lesbar sind. Die Metadaten werden entfernt, bevor die Nutzdaten bei der Übermittlung von Diagnoseschlüsseln verarbeitet werden. Somit können diese nicht auf Datenbankebene verkettet werden. Um das Risiko von Man-in-the-Middle-Angriffen weiter zu reduzieren, wird durch HTTP Public Key Pinning sichergestellt, dass vertrauliche Kommunikation nur zwischen der Corona-Warn-App und dem Server stattfindet.
Etablierte Verschlüsselungsmechanismen wie HTTP over TLS (HTTPS) stellen sicher, dass Nachrichten von außen nicht lesbar sind. Die Metadaten werden entfernt, bevor die Nutzdaten bei der Übermittlung von Diagnoseschlüsseln verarbeitet werden. Somit können diese nicht auf Datenbankebene verkettet werden. Um das Risiko von Man-in-the-Middle-Angriffen weiter zu reduzieren, wird durch statisches Public Key Pinning sichergestellt, dass vertrauliche Kommunikation nur zwischen der Corona-Warn-App und dem Server stattfindet.
Neben einzelnen Nachrichten, die vom System übertragen werden, müssen auch Kommunikationsmuster abgeschirmt werden. Beispiel: Der Sendeaufruf von Testergebnissen und die Übermittlung von Diagnoseschlüsseln würde normalerweise nur im Fall einer tatsächlichen Infektion stattfinden. In diesem Fall könnte man durch die Beobachtung des Netzwerkverkehrs erkennen, dass eine nutzende Person einen SARS-CoV-2-Test gemacht hat und positiv getestet wurde. Um dies zu verhindern, werden zufällig generierte unechte Meldungen versendet, die von gültigen Meldungen nicht unterschieden werden können. Dadurch sind die Übermittlung von Schlüsseln und der Abruf von Testergebnissen nicht vom Hintergrundrauschen der Systeme unterscheidbar. Dies führt selbst bei beobachtbarem Netzwerkverkehr zu einer plausiblen Abstreitbarkeit.