Die Corona-Tracing-Seite auf CrypTool-Online (CTO) demonstriert und implementiert zwei verschiedene kryptografische Protokolle, die für dezentrales, App-basiertes Umgebungs-Tracing genutzt werden.

Wir empfehlen zusätzlich zu dieser Seite den Besuch der CrypTool Corona-Tracing-Visualisierungsseite [1], die eine ansprechende End-Benutzer-Animation enthält, wohingegen sich diese Demonstration mehr auf die Protokolle im Hintergrund fokussiert

Die Visualisierungsseite [1] nutzt dieselbe Implementierung der Protokolle wie diese CTO-Demo.

Einführung

Der Zweck von Umgebungs-Tracing ist, dass man erfährt, ob man ein Infektionsrisiko mit dem Corona-Virus hat, verursacht durch Kontakt mit bereits infizierten Personen. Bei dezentralen Protokollen wird dieses Ziel erreicht, indem nur die minimal erforderlichen und ausschließlich anonyme Daten an eine öffentlichen Stelle geschickt werden.

Tracing-Apps auf den Smartphones verschiedener Benutzer tauschen automatisch Informationen aus, sobald sie sich in einer bestimmten physischen Reichweite zueinander befinden. Technisch wird dies erreicht, indem jedes Smartphone fortwährend Informationen über Bluetooth sendet, die innerhalb einer begrenzten Entfernung von anderen Smartphones empfangen werden können. Die Details des Bluetooth-Transfers sind nicht Teil der Demonstration dieser Seite. Stattdessen setzt diese Seite den Schwerpunkt auf die Details der genutzten kryptografischen Protokolle.

Datenschutz-Ziele

Die dezentralen Protokolle wurden so entworfen, dass sie weder der Öffentlichkeit noch einer zentralen Stelle preisgeben, dass ein Kontakt zwischen zwei Benutzern stattgefunden hat. Lediglich die Apps der beiden Benutzer kennen den Kontakt-Vorgang, jedoch lediglich auf Basis von nicht-personalisierten Daten. Des Weiteren spielt Standortbestimmung (zum Beispiel mittels GPS) überhaupt keine Rolle, da Kontakte rein durch lokalen Bluetooth-Austausch verfolgt werden.

Solange ein Benutzer nicht infiziert ist, besteht für ihn überhaupt kein Anlass, Daten jeglicher Art zu einer zentralen Stelle zu schicken. Tatsächlich wäre es technisch möglich, die Benutzung der App zu erlauben, ohne dass der Benutzer sich für die Benutzung registrieren muss.

Aufgrund der Tatsache, dass Benutzer über den Kontakt mit infizierten Benutzern aufgeklärt werden müssen, verlangt das Protokoll die Offenlegung einiger Informationen. Dies erfolgt jedoch in vollständig nicht-personalisierter Form, sodass infizierte Personen von niemandem identifiziert werden können. Dies wird durch die Anwendung von kryptografischen Methoden erreicht.

Datenschutz-Angriffe basierend auf der Auswertung enormer Datenflüsse, die lokal über Bluetooth empfangen wurden, sollen verhindert werden, selbst dann wenn diese Aufzeichnungen innerhalb großer Gebiete oder in vielen Gebieten gleichzeitig erfolgten. Ein Beispiel eines solchen zu verhindernden Angriffs wäre die Erstellung von Bewegungs- oder Interaktionsgraphen, sogar wenn die Personen im Graph anonym bleiben würden.

Datenschutz-Angriffe basierend auf der Imitierung eines anderen Benutzers (Personifikations-Attacken) sollen ebenfalls verhindert werden.

Benutzung dieser Demonstration

Das Szenario der Demonstration ist aus der Sicht von Alice gestaltet, die noch nicht infiziert ist und auf andere Personen trifft.

Die beiden hellgrünen Bereiche "Alices Kontaktliste" und "Abgleich des öffentlichen Servereintrags mit der Kontaktliste" stellen Vorgänge dar, die lokal auf dem Smartphone von Alice ablaufen.

Wenn Sie den Knopf "Tour starten" im Willkommens-Bereich (oben) anklicken, startet eine enge Führung durch alle Bereiche der Seite. Wenn Sie stattdessen auf den Knopf "Anleitung starten" klicken, startet die Anleitung, die Ihnen zu allen funktionalen Aspekten der Protokoll-Demonstration Hinweise gibt./p>

Es ist empfehlenswert, beim ersten Aufruf der Seite die Tour und die Anleitung zu benutzen. Danach kann man die Animation auch einfach direkt bedienen.

Klicken Sie bitte für den ersten Anleitungs-Schritt auf einen Eintrag im ersten rechteckigen Bereich ("Broadcast-Historie einer anderen Person"). Dieser Klick simuliert dann, dass Alice zu dieser Person Kontakt hatte und dessen Broadcast-ID empfangen hat.

Sie können die Tour und die Anleitung jederzeit verlassen, indem Sie in den Dialogen oder im Anleitungsfenster das Schließen-Kreuz (jeweils oben rechts) anklicken.

---

Referenzen

[1] CrypTool Corona-Tracing-Visualisierungsseite: https://corona-tracing.cryptool.org/

Protokoll-Details

Der dezentralisierte Ansatz erfordert, dass die Tracing-App jedes Benutzers lokale Listen von Kontakt-Vorgängen mit den Apps anderer Benutzer speichert. Die entscheidenden Daten, die hier gespeichert werden, sind diejenigen, die über Bluetooth von den Apps der anderen Benutzer empfangen wurden. Der Hauptinhalt der ausgestrahlten Daten ist ein kurzlebiger Identifizierer (Broadcast-ID) des sendenden Benutzers, mit dem keine Informationen über den Benutzer selbst preisgegeben werden.

Die App wird die versandte Broadcast-ID alle paar Minuten erneuern, um zu verhindern, dass irgendeine empfangende Partei verschiedene Kontakt-Vorgänge mit der gleichen Person assoziieren kann. Neue Broadcast-IDs können nur mittels des täglichen Geheimschlüssels des Benutzers erzeugt werden, wodurch Personifikations-Attacken verhindert werden. Des Weiteren ist es für jemanden, der viele Broadcast-IDs aufgezeichnet hat, nicht einmal möglich, nicht-personalisierte Bewegungs- oder Interaktionsgraphen von Benutzern anzulegen, da er/sie nicht in der Lage ist, verschiedene Broadcast-IDs mit dem gleichen Benutzer zu assoziieren.

Zusätzlich zu der Broadcast-ID wird in der lokalen Kontaktliste auch der Tag (Datum) und die Intensität des Kontakts gespeichert. In dieser Demo wird die Intensität nur anhand der Dauer des Kontakts gespeichert, was der Auslegung im DP-3T-Protokoll entspricht. Andere Intensitätsmaße, wie der Grad der Nähe (gemessen anhand des Bluetooth-Signals), könnten ebenfalls gespeichert werden.

Wenn ein Benutzer durch einen medizinischen Test darüber informiert wird, dass er vor einigen Tagen mit dem Virus infiziert wurde, wird er autorisiert, sich freiwillig in seiner App als infiziert zu melden. Indem er dies tut, sendet er seine kryptografischen Schlüssel (seinen ersten relevanten Tagesschlüssel im DP-3T-Protokoll; und alle seine Temporary-Exposure-Keys, die zu infizierten Tagen gehören, im Exposure-Notification-Protokoll) zu einem öffentlichen Server. Diese Schlüssel können jeweils benutzt werden, um alle Broadcast-IDs abzuleiten, die während des Infektionsintervalls ausgesendet wurden. Vor dem Senden waren diese Schlüssel eine geheime Information, die nur lokal auf dem Smartphone des Benutzers gespeichert wurden. Indem diese Information öffentlich gemacht wird, sind alle anderen Benutzer in der Lage, ihre lokale Kontaktliste gegen alle Broadcast-IDs abzugleichen, die von infizierten Personen hätten ausgesendet werden können.

Die App jedes Benutzers wird in der Lage sein, die Gesamt-Intensität mit infizierten Personen aufzusummieren. Der Benutzer wird anschließend nur dann gewarnt, wenn ein gewisser vorbestimmter Intensitäts-Schwellwert überschritten wurde. Dieser Schwellwert wird von den App-Entwicklern bestimmt und befindet sich nicht im Demonstrationsumfang.

Der App-Benutzer ist die einzige Instanz, die von ihrer Tracing-App über ihr Infektionsrisiko gewarnt wird. Diese Risikoinformation wird niemandem sonst preisgegeben.

Protokoll-Unterschiede

Die CTO-Seite demonstriert die zwei Protokolle DP-3T [1] (vorgeschlagen von europäischen Wissenschaftlern) und Exposure Notification [2] von Apple und Google (basierend auf Spezifikation 1.2).

Die Terminologie der beiden Protokolle unterscheidet sich ein wenig. Die CTO-Seite spiegelt die jeweiligen Original-Begriffe wider.

Funktion	Begriff in "DP-3T"	Begriff in "Exposure Notification"
Broadcast-ID	Ephemeral-Identifier (kurz: EphID)	Rolling-Proximity-Identifier
Geheimer Schlüssel zur Ableitung täglicher Broadcast-IDs	Tagesschlüssel (Day-Key)	Temporary-Exposure-Key
Erneuerungsintervall von Broadcast-IDs	15 Minuten	10 Minuten

Die kryptografischen Details dieser beiden Protokolle unterscheiden sich im Detail, wie in ihren Spezifikationen beschrieben [1] [2]. Der entscheidende Unterschied liegt im Vorgehen, wie Broadcast-IDs von den Geheimschlüsseln hergeleitet werden:

• Bei DP-3T werden alle EphIDs eines Tages von einem Tagesschlüssel abgeleitet, wobei der Tagesschlüssel des nächsten Tages durch Anwendung einer SHA256-Hash-Funktion vom letzten Tagesschlüssel herleitbar ist.
• Bei Exposure Notification werden alle Rolling-Proximity-Identifiers eines Tages von einem Temporary-Exposure-Key abgeleitet, welcher ein reiner Zufallsschlüssel ist. Für jeden Tag gibt es genau einen solchen Schlüssel. Es gibt keine Beziehung zwischen den Temporary-Exposure-Keys verschiedener Tage.

Die Konsequenz hieraus ist, dass es in DP-3T lediglich nötig ist, einen einzelnen Tagesschlüssel des Tages, an dem die Infektion begann, freiwillig hochzuladen. Im Unterschied hierzu werden bei Exposure Notification die Temporary-Exposure-Keys aller Infektionstage hochgeladen. Dies erfordert mehr Bandbreite, da alle hochgeladenen Schlüssel von den Apps aller Benutzer heruntergeladen werden müssen. Der theoretische Vorteil ist, dass es nicht möglich ist herauszufinden, ob Rolling-Proximity-Identifiers, die an verschiedenen Tagen empfangen wurden, zu der gleichen (anonymen) Person gehören. Dies gibt Exposure Notification einen kleinen (hauptsächlich theoretischen) Vorteil beim Datenschutz-Aspekt. Der geringere Bandbreiten-Bedarf ist der Grund, warum die präsentierte DP-3T-Variante als "Low-Cost" bezeichnet wird.

Bei DP-3T werden alle EphIDs eines Tages vor dem Aussenden durchmischt, weshalb die dargestellte Reihenfolge der EphIDs in den Bereichen "Broadcast-Historie einer anderen Person" und "Abgleich des öffentlichen Servereintrags mit der Kontaktliste" voneinander abweicht. Dies ist bei Exposure Notification nicht der Fall.

Es ist auch wichtig zu erwähnen, dass das Exposure-Notification-Protokoll einen Mechanismus anbietet, um zusätzliche Meta-Daten zusammen mit der Broadcast-ID zu senden. Diese Meta-Daten werden ebenfalls in der Konktaktliste der Empfänger gespeichert. Die Meta-Daten sind so verschlüsselt, dass sie nur entschlüsselt werden können, nachdem sich der Benutzer als infiziert gemeldet hat. Dies geschieht zum Zwecke des Transfers zusätzlicher Informationen zum Empfänger, beispielweise der Protokoll-Versionsnummer. Dieser Mechanismus ist nicht in der Demonstration auf dieser Seite enthalten.

Kryptografische Details

Die Sicherheit beider Protokolle basiert auf einer Kombination verschiedener einfacher kryptografischer Verfahren (Hashen, HMACs, Stromchiffren) um geheime Tagesschlüssel und Broadcast IDs deterministisch herzuleiten.

DP-3T

Sobald ein Benutzer mit der Benutzung einer DP-3T-basierten Tracing-App beginnt, wird ein initialer Tagesschlüssel SK₀ als 32 Byte großer Zufallswert von einem kryptografischen Zufallszahlengenerator erzeugt.

Die Tagesschlüssel aller nachfolgenden Tage werden hiervon mittels einer kryptografischen Hashfunktion (SHA-256) rekursiv hergeleitet:

• SK _t = H(SK _t-1 )

Ein 32 Byte großer Tagesschlüssel kann genutzt werden um alle EphIDs eines Tages aus diesem herzuleiten:

• EphID₁ || ... || EphID _n = PRG(PRF(SK _t , ASCII("broadcast key")))
• n = (24 * 60) / 15
• PRF: deterministische Pseudo-Zufallsfunktion (HMAC-SHA256)
• PRG: Stromchiffre ( AES₂₅₆ im Counter Mode)

Jede EphID hat eine Größe von 16 Bytes. Insgesamt gibt es genau 96 EphIDs für jeden Tag, was zu einem Erneuerungsintervall von 15 Minuten führt. Die abgeleiteten EphIDs eines Tages werden in zufälliger Reihenfolge ausgesendet.

Exposure Notification

Bei Benutzung von Exposure Notification werden die Temporary-Exposure-Keys individuell für jeden Tag als 16 Byte große Werte von einem kryptografischen Zufallszahlengenerator erzeugt.

Der Schlüssel tek_i für den Tag i wird daraufhin benutzt um den Rolling-Proximity-Identifier-Key RPIK_i für den gleichen Tag zu erzeugen, indem die folgende Formel angewandt wird:

• RPIK_i = HKDF(tek_i, NULL, UTF8("EN-RPIK"), 16)
• HKDF(key, salt, info, output length): deterministische Pseudo-Zufallsfunktion basierend auf HMAC-SHA256

Dieser Rolling-Proximity-Identifier-Key wird daraufhin benutzt um alle Rolling-Proximity-Identifiers RPI _i,j für den zugehörigen Tag herzuleiten. Die Variable j bezieht sich auf ein bestimmtes Zeitfenster:

• RPI_i,_j = AES₁₂₈(RPIK_i, UTF8("EN-RPI") || 0x000000000000 || ZeitfensterID(j))
• ZeitfensterID(j) = Unix-Epochenzeit von irgendeinem Zeitpunkt während des Fensters j, geteilt durch (60 x 10)

Die 16 Byte großen RPI_i,_j-Werte werden während der zugehörigen Zeitfenster ausgesendet, welche jeweils eine Länge von 10 Minuten haben.

---

Referenzen

[1] DP-3T Protokoll-Spezifikation: https://github.com/DP-3T/documents
[2] Exposure Notification Protokoll-Spezifikation: https://www.apple.com/covid19/contacttracing/