Seite 2: Tracing ohne Tracking

Inhaltsverzeichnis

Das Ziel von Contact Tracing ist es, Kontakte zwischen Personen aufzuzeichnen, um die Kontaktpartner im Nachhinein warnen zu können, wenn sich eine der Personen als SARS-CoV-2-positiv herausstellt. Es wird hier davon ausgegangen, dass ein signifikanter Anteil der Bevölkerung ein Smartphone immer dabei hat und die Tracing-App auf dem Gerät installiert ist. Experten der Universität von Oxford rechnen damit, dass die aktiven Teilnehmer mindestens 60 Prozent der Bevölkerung ausmachen müssen, wenn das System funktionieren soll.

In den Richtlinien der Europäischen Kommission zu Contact Tracing ist unmissverständlich festgelegt, dass Location Tracking des Benutzers nicht erwünscht ist, da es für die Erfüllung der Aufgabe solcher Apps nicht nötig ist und einen schwerwiegenden Eingriff in die Privatsphäre der Nutzer darstellt. Deswegen eignen sich GPS und WLAN-Ortung nicht, um die Position des Gerätes in Relation mit anderen Geräten in der Nähe zu bestimmen. Wie will eine solche Contact-Tracing-App dann aber feststellen, ob ein anderes Smartphone – und damit ein potenzieller SARS-CoV-2-Infektions-Vektor – in der Nähe ist? Der Konsens bei den Entwicklern ist, dass man eine solche Funktion am besten mit Entfernungsmessung über das Protokoll Bluetooth Low Energy (BLE) umsetzt.

Bluetooth-Entfernungsmessung

Nun ist Bluetooth eigentlich nicht zur Entfernungsmessung gedacht, aber wie jeder Transmitter kann auch der Bluetooth-Funkchip in modernen Handys zur groben Entfernungsmessung umfunktioniert werden. Dazu sendet jedes Gerät mit der Tracing-App in regelmäßigen Abständen ein Broadcast-Signal und lauscht selber auf solche Signale anderer Geräte in Reichweite – je nach Gerät und Einsatzart in der Regel zwischen 10 und 400 Meter. Aus der Signalstärke eines empfangenen Signals lässt sich grob abschätzen, wie weit der Absender entfernt ist.

Hier liegt auch ein großes Fehlerpotential des Systems, denn die Entwickler versuchen, die Ausbreitung eines Virus mit Hilfe der Ausbreitung von Funksignalen im UHF-Band abzubilden. Dieses Vorgehen birgt viele Fallstricke. Etwa lässt eine Glasscheibe zwischen zwei Personen und ihren Smartphones UHF-Signale problemlos passieren, verhindert aber verlässlich die Ausbreitung des SARS-CoV-2-Virus. Außerdem werden Funksignale unter bestimmten Bedingungen sehr gut um Ecken reflektiert, die von Infizierten ausgesonderten Tröpfchen mit Virenpartikeln unter Umständen aber nicht. Die App läuft also Gefahr, Fehlalarme zu verursachen. Etwa wenn ein Fahrradfahrer an der Ampel neben einem geschlossenen Auto anhält und die Handys beider Verkehrsteilnehmer trotzdem munter Bluetooth-Signale austauschen.

Ganz unabhängig davon haben unterschiedliche Smartphone-Modelle unterschiedliche Sende- und Empfangscharakteristiken, die sich dummerweise auch noch ändern, je nachdem, wie das Gerät gehalten wird. Hinzu kommt die Frage, wie lange sich zwei Geräte gegenseitig sehen müssen, damit der Algorithmus entscheidet, dass ein signifikantes Infektionsrisiko gegeben ist. Die Entwickler des Tracing-Systems müssen alle diese Variablen beachten und ihren Entfernungsmessungs-Code so gut es geht an diese imperfekte Welt anpassen.

Gehen wir nun also davon aus, die Entwickler haben ihren Bluetooth-Code so gut es eben geht justiert und es werden nur Broadcast-Signale anderer Smartphones gespeichert, die bestimmte Relevanzkriterien erfüllen und von denen wir ausgehen können, dass sie ein entsprechendes Infektionsrisiko darstellen. Nun gilt es, diese Signale so zu strukturieren, dass die Privatsphäre der einzelnen Nutzer der Tracing-App gewahrt bleibt. Apple und Google, basierend auf dem Entwurf von DP3T, stellen sich die Lösung dieses Problems wie folgt vor.

Ein Nutzer, viele Schlüssel

Jedes Smartphone generiert alle 24 Stunden einen sogenannten Temporary Exposure Key. Dieser ist 128 Bits lang und wird vom Gerät jeden Tag erneut mit Hilfe des eingebauten Pseudo-Zufallszahlengenerators erzeugt. Dieser Key wird mit AES verschlüsselt und auf dem Gerät des Nutzers gespeichert. Zusammen mit dem Temporary Exposure Key speichert das Gerät (ebenfalls AES-verschlüsselt) einen Zeitwert, der angibt, von wie lange dieser Schlüssel gültig ist. Dieser Wert wird in 10-Minuten-Intervallen berechnet, die mit Hilfe des Unix-Zeitstempels angegeben werden.

Das Smartphones eines Nutzer speichert immer die letzten 14 dieser Temporary Exposure Keys. Das basiert auf medizinischen Studien, die davon ausgehen, dass Patienten, die mit dem SARS-CoV-2-Virus infiziert sind, maximal 14 Tage lang ansteckend sind.

Aus dem Temporary Exposure Key generiert das Smartphone mit Hilfe der kryptografischen Schlüsselerzeugungsfunktion HKDF einen sogenannten Rolling Proximity Identifier Key (RPIK). Aus diesem wiederum werden regelmäßig Rolling Proximity Identifier erzeugt, die dann über Bluetooth abgestrahlt werden. Bei DP3T heißen diese Identifier "Ephemeral ID" oder "EphID". Diese Rolling Proximity Identifier werden vom Gerät jedes Mal neu generiert, wenn sich dessen Bluetooth-MAC-Adresse ändert. Das ist bei BLE-Geräten in der Regel alle 15 bis 20 Minuten der Fall. Der Rolling Proximity Identifier ist ein 128-Bit-Wert, der aus dem aktuell geltenden RPIK, dem aktuellen Unix-Zeitstempel und etwas Padding-Daten erzeugt wird.

Der Besitzer eines Temporary Exposure Keys kann alle Rolling Proximity Identifier mit einem dazugehörigen Zeitwert diesem Temporary Exposure Key zuordnen. Besitzt er nur die Rolling Proximity Identifier, kann er daraus aber nicht den Temporary Exposure Key ableiten. Es handelt sich hierbei um eine kryptografische Einweg-Funktion die verhindern soll, dass jemand, der Proximity Identifier abgreift, daraus auf Temporary Exposure Keys oder sogar einzelne Bluetooth-Geräte schließen kann.