Vergleich der Ansätze

Wie diese Seite zu lesen ist

In dieser Wiki-Page werden die drei Ansätze PEPP-PT, DP3T und DCTS anhand unterschiedlicher Kriterien miteinander verglichen. Dabei lassen sich die Kriterien zunächst in drei große Themenbereiche unterteilen:

• Architektur
• Kommunikationsablauf
• Privatsphäre und Transparenz

Die Kriterien eines Themenbereiches werden schließlich kurz beschrieben und anschließen in einer Tabelle gegenübergestellt.

Hinweis: Alle Tabellen sind interaktiv, wobei sich die Detailbeschreibungen durch Klick auf das Dreieck ▸ aus- bzw. ▾ einklappen lassen.

Abkürzungen

User-ID: permanente ID die zu einem User zugeordnet ist (nur PEPP-PT)

Push-ID: Push-Notification-ID (nur PEPP-PT)

BLE-ID: temporäre (<=1 Stunde) BluetoothLowEnergy-ID

Seed: temporärer (z.b. 1 Tag) Key zum Erzeugen von BLE-IDs (nur DP3T, DCTS)

Architektur

Die meisten Konzepte/Apps lassen sich in zwei Prinzipien unterteilen (zentral und dezentral), je nachdem wo die Daten ausgetauscht und gespeichert werden. Dieses Prinzip beeinflusst stark den Grad des Datenschutzes und weitere Eigenschaften.

Weiterführender Artikel: netzpolitik.org

Kriterium	Zentral	Dezentral
Ort der Generierung der BLE-IDs ...gibt an, wo die BLE-IDs generiert werden.	Server BLE-IDs werden für alle User auf dem Server durch verschlüsseln ihrer User-ID generiert.	Smartphone BLE-IDs werden dezentral auf dem Smartphone des Nutzers aus einem Seed berechnet.
Ort der Berechnung ob Kontakt ...gibt an, wo berechnet/geprüft wird, ob ein Kontakt mit einem Infiziertem stattgefunden hat und wie hoch das Risiko ist.	Server Der Server bestimmt, welche Personen kontakt mit infizierten hatten und wie hoch das Risiko ist.	Smartphone Kontakt- und Risikoberechnung erfolgt auf dem jeweiligen Smartphone des App-Nutzers.
Verfahren bei Aktualisierungen ...gibt an, wie der Algorithmus zur berechnung von Kontakt/Risiko aktualisiert werden kann	Server-Update Es muss nur der Server aktualisiert werden	App-Update Die Nutzer*innen müssen die App aktualisieren.

Konzepte

Kriterium	PEPP-PT	DP3T	DCTS
Architektur ...siehe obere Tabelle	Zentral	Dezentral	Dezentral
Mitglieder Wer hat bei der Entwicklung mitgewirk, auch achten auf Organisationen mit evtl. anderen Interessen, z.B. Firmen mit Überwachungssoftware, ...	viele EU-Universitäten/ Forschungszentren anfangs über 130, inzwischen viele ausgetreten	aus PEPP-PT abgespalten	ito, TU München, TCN Coalition
Kompatibilität mit Apple / Google Schnittstellen Key werden beim ansatz von Google/Apple lokal erzeugt, siehe auch hier	nein Die zentrale erstellung der Bluetooth-IDs ist mit der Schnittstelle nicht möglich, dadurch muss die App permanent geöffnet sein.	ja Die Apple/Google Schnittstelle wurde stark von DP3T inspiriert/ist daran angelehnt	ja da ähnlich zu DP3T

Apps

Kriterium	Corona Warn App
Konzept auf welchem Konzept basiert die App	inspiriert bei DP3T
Land	Deutschland
Entwickler	SAP und Telekom
Verwendet Apple / Google API	ja

Kommunikation

Ablauf der Kommunikation mit Erklärung der Unterschiede in den einzelnen Schritten

Kriterium	PEPP-PT	DP3T	DCTS
Registrierung muss sich die App initial beim Server registrieren	Ja dabei wird vom Client zum Server seine Push-ID übertragen und der Server generiert eine User-ID	nein	nein
Ausgetauschte IDs ...beschreibt welche Art von IDs zwischen zwei Nutzergeräten ausgetauscht werden.	BLE-IDs Austausch via BLE-Broadcasting	BLE-IDs Austausch via BLE-Broadcasting	BLE-IDs Austausch via BLE-Broadcasting
Bestätigung der Infizierung (durch bspw. Arzt/KH/Labor) Die Bestätigung der Infizierung kann auf verschiedenen Weisen erfolgen (z.B. der Nutzer ladet seine Daten mithilfe eines TAN Verfahrens oder ein Labor lädt die Daten nach der Feststellung der Infizierung hoch).	ТAN Verfahren Nutzer generiert ein TAN, die von der Gesundheitsbehörde auf dem Backend aktiviert wird, womit der Nutzer freiwillig sein Infektionsstatus und CTD auf dem Server hochladen kann.	TAN Verfahren Beim Test erhält der Patient einen TAN, die nach dem positiven Befund freigeschaltet wird	TAN Verfahren, oder Übertragung durch einen Arzt Entweder hat die App durch die TAN die Erlaubnis, die Daten an dern Server zu senden oder der Schlüssel, der zur Generierungder BLE-ID's genutzt wurde, wird einer Dritten Person z.B. per QR-Code übertragen, damit diese diese die BLE-ID's für sich generieren und hochladen kann.
Datenmenge bei Übertragung eines Infektionsfalls ...beschreibt die Daten, die beim Infektionsfall vom Infiziertem zum Server übertragen werden	Empfangene BLE-IDs Ein Liste von Empfangenen Bluetooth ID's	Seed und Timestamp Es wird der Seed und der Timestamp der ersten Generierung übertragen, mit der die eigenen BLE-IDs generiert wurden.	Gesendete BLE-IDs Eigenen BLE-IDs, die generiet wurden
Benachrichtigung der User*innen Sollte die Benachrichtigung automatisch erfolgen (z.B. mit Hilfe eines Push-Notification Service, die schon die Kontaktpersonen auf dem Backend speichert) oder nur wenn der Nutzer nachfragt.	Automatisch (Push-Notification Service) Die Benachrichtigung der Nutzer erfolgt automatisch mit Hilfe einer Push-Notification Service, nachdem die Risikoschätzung und Proximity measurment auf dem Backend für die CTD der infizierten Nutzer, die eine Liste von BLE-IDs beeinhaltet hochgeladen wurde. Ein nichtinfiziertes Userapp pollt nach der Benachrichtigung der Push-Notification Service im Hintergrund das Backend-Service um die Infektionsstatus zu bekommen.	manuell Erst nach dem Upload der eigenen Seeds können andere Personen benachrichtigt werden	manuell Erst nach dem Upload eigener BLE-IDs können andere Personen benachrichtigt werden
Art der Benachrichtigungerhaltung (Push vs. Poll) Die Frage, wie man die Daten erhaltet. Push - der Server informiert die Nutzer, Poll - der Nutzer fragt beim Server nach.	Push Wenn ein Nutzer als coronapositiv klassifiziert wurde, sollte er alle seine gespeicherten BLE-ID's mit Timestamps an dem Backend schicken. Da erfolgt erstmal eine Risikoschätzung um zu verstehen welche Kontakte könnten ins Risiko sein und demnächst werden die benachrichtigt.	nicht Spezifiziert eher Pull Der Server hält die Seeds der Infizierten vor und "schickt" diese an die Apps	Poll Der Nutzer fragt beim Server ein aktuelle Liste der Infizierten ab.
Art der Verteilung der Daten vom Server (Broadcast an alle vs. Pull je Geraet) Wie die Daten verteilt werden ?	Broadcast an den Kontakatpersonen der infezierten Person	Clients werden per Broadcast informiert, ein Pull durchzuführen.	Pull je Gerät
Datenmenge beim Prüfen, ob ein Kontakt stattfand Datenmenge, die vom Server zur App übertragen wird, wenn von der App überprüft wird, ob ein Kontakt mit einer infizierten Person vorlag	keine, App erhält direkt Risikinfo Der Server schickt direkt die Risikoinformatik an den Nutzer, da die Auswertung auf dem Server erfolgt.	Liste von Seeds und Timestamps Die Seeds und Timestamps der gemeldeten Faälle, aus denen dann Lokal die BLE-IDs generiert werden, die verglichen werden können mit den empfangenen BLE-IDs	BLE-IDs Liste Eine Liste mit alle BLE-IDs, die gemeldet wurden, die mit den gesehenen Lokal verglichen werden kann. Diese Daten werden durch einen Bloom Filter verkleinert.

Technische Details / Features

Kriterium	PEPP-PT	DP3T	DCTS
Verschlüsselung der Kommunikation ... beschreibt, wie die Daten übertragen werden.	TLS/ OAuth2.0/ Open Broadcast TLS Serverauthentizierung mit Hilfe OAuth2.0 Tokens verwendet bei der Kommunikation zwischen - Backend/App, Backend/Push-Notification service (keine Payload-dateien übertragen, nur als Signalmechanism verwendet), Gesundheitsamtmitarbeiter oder Laboren/Backend. Broadcast kann nur zwischen zwei Apps verwendet werden und ist keine gesicherte Kommunikation.	Private key Kodierung (Seed) / BLE-ID Spreading with Secret sharing Bei der Kommunikation mit dem Backend wird es nicht explizit erwähnt, was für Verschlüsselungsmechanismen benutzt werden. Trotzdem sollte jeder Nutzer ein Seed zur Erstellung seiner BLE-IDs in seinem App haben und die wurde dem Server nur dann bekanntgegeben, wenn der Nutzer infiziert wurde, danach wird ein neuer Seed von dem App automatisch erstellt.Dies könnte auf 2 Weisen erfolgen, entweder wird der Seed zusammen mit einem Zeitraum t geschickt. Für die sichere Kommunikation zwischen zwei BLE-Geräte wird eine EphID Spreading with Secret sharing Verfahren verwendet. Dies erfolgt über ein k von n Secret-sharing-Schema. Anstatt jeder BLE-ID innerhalb von einem Beacon zu schicken, sollte es in n Teilen kodiert werden, sodass es nur dann möglich ist die BLE-ID zu rekonstruiren, wenn mindestens k Teile der Kodierung vorhanden sind.	Asymetrische Verschlüsselung und TOR Upload geschieht über TOR. Beim Download der Daten vom Server, werden nur daten durch asymetrische und kommutativer Verschlüssselung ausgetauscht
Interoperabilität mit anderen Apps / Ansätzen Die Möglichkeit soll bestehen, dass zwei Nutzer BLE Signals zur Proximity tracing unabhängig von dem heruntergeladenen App empfangen werden können. Dieser Punkt ist wichtig, weil es ist zu erwarten, dass in den verchiedenen Ländern, verschiedene Apps benutzt werden (da man verschiedene Anforderungen zur Privatsphäre und Features haben kann), aus dem Grund sollte man unabhängig davon Interoperabilität auf internationale Ebene/ zwischen verschiedenen Apps erlauben.	Ja Dies wird erreicht, indem man verschiedene Backend services und Verfahren zur Generierung des BLE-IDs and User-IDs verwenden könnte, außerdem verschiedenes App in jedem Land. Es sollte möglich sein nachvollzuziehen aus welchem Land ein EBID ursprunglich kommt, dafür sollte ein ECC (encrypted country code) in jeder BLE-ID enkodiert sein.Wenn eine Backend-Dienstleistung eine BLE-ID nicht erstellt hat, dann kann es die BLE-ID zu keiner entsprechenden User-ID zuordnen. Die verschiedenen Backenddienstleistungen sollten miteinander kommunizieren können, damit alle BLE-ID am ende mit dem entsprechenden Push-IDs benachrichtigt werden können. Die Risikoschätzung erfolgt auf dem Home-Dienstleistung und nur die Home-Dienstleistung sollte entscheiden, ob ein Nutzer benachrichtigt werden soll.	Mit anderen Ländern Durch manuelle Eingabe oder GPS, sollen immer die Server angesteuert werden, in deren Ländern sich die Person aufgehalten hat	keine Angabe Dafür müsten die Spezifikation zur Generierung von Schlüsseln einheitlich sein
GPS-Tracing ...beschreibt, ob GPS-Tracing erfolgt.	Nein Es sollte keine Lokalisierung und Tracing mittels GPS stattfinden. Auch die Indentifizierung der Backenddienstleistung für die verschiedenen Länder erfolgt über die BLE-IDs und die Informationen, die in dennen kriptiert wurden.	optional Kann benutzt werden um zu erkannen in welchem Land die App ist	Nein Keine Nutzung vorgesehen
BLE-Nutzung Wird Bluetooth Low Energy in diesem Ansatz als Haupttechnologie verwendet.	Ja Das eigene BLE-ID in dem Zeitpunkt wird mittels BLE broadcastet und BLE-IDs von anderen werden mittels BLE empfangen.	Ja Die eigene BLE-ID in dem Zeitpunkt wird mittels BLE broadcastet und BLE-IDs von anderen werden mittels BLE empfangen.	Ja Zum ID-Broadcasting
Identifizierung mit Hilfe der MAC-Adressen-Übertragung Werden MAC-Adressen bei dem Verfahren während der Kommunikation zwischen zwei Akteure bekanntgegeben, kann man damit ein Akteur identifizieren.	Nein Aus dem Grund, dass BLE verwendet wird, sollte es sowohl bei BLE beacons als auch bei normalen BLE-Geräte nicht möglich sein, dass MAC Adressen in verchiedenen Sessions in einem bestimmten Zeitraum fest und erkennbar sind. Es werden UUIDs umgetauscht, die ohne Vorbemerkung sich verändern können. Es wird aber in der Dokumentation kein solcher Aspekt erwähnt.	Nein Aus dem Grund, dass BLE verwendet wird, sollte es sowohl bei BLE beacons als auch bei normalen BLE-Geräte nicht möglich sein, dass MAC Adressen in verchiedenen Sessions in einem bestimmten Zeitraum fest und erkennbar sind. Es werden UUIDs umgetauscht, die ohne Vorbemerkung sich verändern können. Es wird aber in der Dokumentation kein solcher Aspekt erwähnt.	Nein Kein Tracking möglich, durch Wechsel der BLE-IDs und damit auch der Bluetooth MAC-Adressen
Zweitkontaktverfolgung Ist es möglich Zweitkontaktverfolgung einzusetzen, welcher Ansatz wird bei der Zweitkontaktverfolgung verwendet und unter welchen Umständen (z.b. Zustimmung des ersten Kontaktpersons) ist es möglich.	Keine Angabe, aber möglich Theoretisch ist es möglich bei diesem Ansatz Zweitkontaktverfolgung einzusetzen, da die Kontaktpersonen ihre Kontaktlisten dem Backend mitteilen können. Trotzdem ist die Benachrichtigung des zweiten Kontakts vom Risikoschätzung auf dem Server und anderen Faktoren abhängig und wird nicht in der Dokumentation erwähnt. Trotzdem wird es erwähnt, dass fehlerhafte positive Ergebnisse Auswirkung an dem geistigen Zustand des Persons haben könnte, was eigentlich gegen die Zweitkontaktbenachrichtigung sprechen, aber nicht gegen die Zweitkontaktverfolgung.	Keine Angabe aber eher nein Der Server enthält Seeds nur von den infizierten Personen und aus dem Grund und keine Listen der Kontakten. Auß dem Grund ist es nicht möglich, dass eine Zweitkontaktverfolgung bei dem Server stattfindet. Unklar ist, wie eine Authentifizierung der entsprechenden Personen, die einen Kontakt hatten dem Server gegenüber aussehn kann. Dieser Aspekt ist aber in der Dokumentation nicht erwähnt.	Ja Im Entwurf vorgesehen Durch einen 'zero-knowledge proof' durch den eine Person, die Kontakt mit einer infizierten Person hatte auch Ihre BLE-IDs hochladen kann

Privatsphäre und Transparenz

Allgemein

Kriterium	PEPP-PT	DP3T	DCTS
Welche Daten sieht der Server-Betreiber	User-IDs und Push-ID + Status (Infiziert/Kontakt) Der Status Infiziert/ Kontakt mit Infiziertem ist nur bekannt, falls der Infizierte ihn hochgeladen hat.	Seeds infizierter Nutzer Nach Bestätigung durch den Arzt läd der Infizierte seine Seeds hoch.	BLE-IDs infizierter Nutzer + Zweitkontakte Nach Bestätigung durch Arzt kann der Infizierte seine BLE-IDs hochladen. Wenn ein Kontakt mit einem Infizierten bestand, kann der Nutzer entscheiden auch seine BLE-IDs als "potenziell infiziert" hochzuladen.
Welche Daten sieht die App	BLE-IDs (eigene + Kontakte)	Seed, BLE-IDs (eigene + Kontakte) Aus dem Seed, der jeden Tag gewechselt wird, werden BLE-IDs erzeugt werden.	Seed, BLE-IDs (eigene + Kontakte) Der Temporäre Seed wird täglich gewechselt, daraus werden die BLE-IDs erstellt, die ausgetauscht werden.
Wie lange werden die Daten gespeichert Die Datenspeicherung auf dem Server kann der Nutzer nicht prüfen, aber lokale Daten könnten z.b. per modifizierter App regelmäßig gelöscht werden.	keine Angabe	keine Angabe	2-3 Wochen Ausgehend von der möglichen Inkubationszeit. Kann angepasst werden.
Wer entscheidet über Datenübertragung bei Infektion? siehe auch Bestätigung der Infizierung	Infizierter nach Authorisierung	Infizierter nach Authorisierung	Infizierter nach Authorisierung
Wer entscheidet über Datenübertragung bei Kontakt mit Infiziertem? bei DCTS für Zweitkontaktverfolgung	Infizierter nach Authorisierung Der Infizierte lädt seine Kontakte hoch, dies ist nicht optional wenn man sich für hochladen entscheidet.	Daten werden nicht erhoben	Kontaktperson entscheidet Wenn man Kontakt mit einer infizierten Person hatte, so wird man darüber informiert und hat die Option seine eigenen IDs hochzuladen (siehe Zweitkontaktverfolgung)
Haltung gegenüber Open Source	Wird vorgeworfen, nicht nach Transparenz zu streben.	Abspaltung von PEPP-PT	Unterstützt komplett Open-Source

Identität

Kriterium	PEPP-PT	DP3T	DCTS
Pseudo- / Anonymisierung	Pseudonymisierung die User-ID ist permanent und auf Server gespeichert, damit + Push-Notification-ID ist eine Identifikation möglich	Anonymisierung der Seed ist der einzige konstante und zur Identifikation nutzbare Datenwert, dieser ändert sich jedoch täglich und wird dem Server nur bei Infizierung bekanntgegeben	Anonymisierung der Seed ist der einzige konstante und zur Identifikation nutzbare Datenwert, dieser ändert sich jedoch täglich und wird dem Server nur bei Infizierung bekanntgegeben
Wer kann aus der BLE-ID eine User-ID zurückrechnen?	Server Die BLE-ID ist eine symmetrisch verschlüsselte User-ID	es gibt keine User-ID und die Seeds sind nicht zurückrechenbar	es gibt keine User-ID und die Seeds sind nicht zurückrechenbar
Identifizierung der App-User durch Server (Zuweisung von ID's) Die Zuweisung und Anzahl der temporären und nichttemporären ID's und die Methode, die auf dem Server angewendet wird, um den Benutzern ihre Appdaten zuweisen zu können, ohne die als Person indefizieren zu können.	1 User-ID/mehrere BLE-IDs/ein Push-ID Der Nutzer bekommt eine einzigartige User-ID (Permanent pseudonym of the app), womit er auf dem Backend indentifizert werden kann, die Push-ID wird nur auf dem Backend gespeichert. Dazu bekommt der Nutzer auch mehrere BLE-ID, die er bei dem BLE-Broadcasting schickt, zusammen mit einem Timestamp, sodass er danach mithilfe dieser BLE-ID und dem Timestamp auf dem Server indentifiziert werden kann und von dem Push-Notification Service mit Hilfe seiner Push-ID benachrichtigt werden kann. Der Nutzer bekommt niemals sein User-ID, aber die BLE-IDs werden ihm zugeteilt und zur Nutzung für einem bestimmten Zeitraum gestellt, danach werden neue BLE-IDs für den selben Nutzer vom Server erstellt (bei vorhandener Internetverbindung) und das widerholt sich, sodass es nicht möglich ist, dass der Nutzer von anderen Nutzer mithilfe des BLE-IDs indentifizert wird.	Nein Die BLE-IDs werden nicht vom Server generiert bzw. wenn der Server die erhält, ist schon eine neuer Seed auf der Userapp generiert worden	Nein Die BLE-IDs werden nicht vom Server generiert bzw. wenn der Server die erhält, ist schon eine neuer Seed auf der Userapp generiert worden. Beim Abfragen der infizierten ID's hat eine App jedes mal eine andere ID, ist also vom Server aus nicht zu identifizieren
Kontakt-Graph-Generierung möglich	ja Alle Nutzer haben permanente User-IDs, bei hochladen der Infizerung kennt der Server die permanten User-IDs der Infizierten + aller seiner Kontakte	Nein weil nur eigene IDs hochgeladen werden.	Nein weil nur eigene IDs hochgeladen werden. Bei Zweit-Kontakt-Verfolgung wird durch Zero-Knowledge-Proof verhindert, dass Rückschlüsse auf den begeneten Infiziertem gemacht werden können.

Ideen für weitere Kriterien

manche Kriterien sind schwer kurz zu fassen/objektiv zu beschreiben hier ein paar Ansätze die noch zu klären sind:

Features: was kann alles mit den erhoben Daten gemacht werden: Kontakt-tracking, Zweitkontakttracking, Kontaktgraph, Statistiken?,

Sicherheit: sind Daten geschützt vor diebstahl?, manipulation?, überschwemmen des Systems mit Falschinformationen?, kann ich rausfinden welche BLE-ID zu einem Infiziertem gehört? Was könnte passieren wenn Server/App gehackt wird?

Quellen

• DP-3T Whitepaper
• PEPP-PT
• DCTS
• BLE-Mac-Nachvollziehen