docs: Criteria for the Evaluation of Contact Tracing Apps

README.md

@@ -63,6 +63,7 @@ The technical documents are intended for a technical audience and represent the
 * [Corona-Warn-App Test Result Server Software Design](https://github.com/corona-warn-app/cwa-testresult-server/blob/master/docs/architecture-overview.md)
 * [Corona-Warn-App Mobile Client (Android) Architecture](https://github.com/corona-warn-app/cwa-app-android/blob/master/docs/architecture-overview.md)
 * [Corona-Warn-App Mobile Client (iOS) Architecture](https://github.com/corona-warn-app/cwa-app-ios/blob/development/docs/architecture-overview.md)
+* [Criteria for the Evaluation of Contact Tracing Apps](pruefsteine.md)
 
 To be published:
 * System Operation

pruefsteine.md

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

translations/README.de.md

@@ -50,6 +50,11 @@ Dieses Repository enthält die Entwicklungsdokumentation und zugehörige Inhalte
 Der Projektumfang wurde gemeinsam von der Deutschen Telekom AG sowie der SAP SE als Auftragnehmer und der deutschen Bundesregierung sowie dem Robert Koch-Institut als Auftraggeber festgelegt. Der Projektumfang kann sich im Laufe der Zeit ändern, wenn neue Anforderungen einbezogen werden müssen oder wenn sich bestehende Anforderungen ändern. Wir begrüßen Rückmeldungen zu allen Bestandteilen dieses Dokuments zum Projektumfang. Allerdings müssen zusätzliche Funktionen oder andere inhaltliche Änderungen, die über das Beheben von Grammatik- oder Schreibfehlern hinausgehen, zwischen den Verantwortlichen abgestimmt werden, bevor sie in das Dokument aufgenommen werden können. Vielen Dank für Ihr Verständnis.
 - [Corona-Warn-App - Scoping-Dokument](scoping_document.de.md)
 
+### Technische Dokumentation
+Die technischen Dokumente sind für ein technisches Publikum bestimmt und repräsentieren den neuesten Stand der Architektur. Die Lösungsarchitektur und die Konzepte können sich im Laufe der Zeit ändern, da sich externe Abhängigkeiten (z.B. das von Apple/Google bereitgestellte Framework) noch immer ändern und neue Anforderungen aufgenommen werden müssen oder sich bestehende ändern. Wir freuen uns über Rückmeldungen zu allen Elementen dieser technischen Dokumente. 
+
+* [Prüfsteine für die Beurteilung von "Contact Tracing"-Apps](pruefsteine.de.md)
+
 ## Lizenzierung
 
 Copyright (c) 2020 Deutsche Telekom AG und SAP SE oder ein SAP-Konzernunternehmen.

translations/pruefsteine.de.md

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