Corona-Tracking: Wie Contact-Tracing-Apps funktionieren, was davon zu halten ist
Wie funktioniert das von Apple und Google vorgeschlagene Konzept für Corona-Apps? Kann es die Ausbreitung von COVID-19 eindämmen? Was ist mit PEPP-PT und DP3T?
Zur Eindämmung des neuartigen Coronavirus SARS-CoV-2 und um es den Menschen zu ermöglichen, wieder einem geregelten Lebensalltag nachzugehen, haben sich Apple und Google zusammengeschlossen, um die Infrastruktur für sogenannte Contact-Tracing-Apps in ihren Mobilbetriebssystemen zu verankern. Contact-Tracing-Apps sollen mit Mitteln des digitalen Zeitalters die Gesundheitsämter bei dem unterstützen, was sie seit jeher machen, um die Ausbreitung ansteckender Krankheiten zu verhindern: Wird ein Patient mit einer meldepflichtigen Krankheit diagnostiziert, versuchen Gesundheitsämter herauszufinden, mit welchen Personen der Patient wann Kontakt hatte. Diese Personen werden dann gewarnt, dass sie infiziert sein könnten und gegebenenfalls gebeten, sich in Quarantäne zu begeben.
Neben dem Ansatz von Google und Apple, die direkt ins Smartphone-System verankert sind, gibt es auch die Projekte DP3T und PEPP-PT – wobei besonders bei letzterem in den vergangenen Tagen einige Differenzen zwischen den Beteiligten aufgetaucht sind. Dabei geht es vor allem darum, ob ein dezentraler Ansatz mit Speicherung der erhobenen Daten auf dem Smarpthone des Besitzes oder eine Lösung mit einem zentralen Server bevorzugt wird.
Apple, Google und DP3T
Um das Contact-Tracing im größeren Stil automatisiert ablaufen zu lassen, bedarf es einiger technischer Raffinessen, besonders wenn man das Ganze nach europäischen Maßstäben datenschutzkonform umsetzen will. Teile dieser Technik sind in den letzten Wochen komplett neu entwickelt worden. Die Methode, an der Apple und Google arbeiten, deckt sich in weiten Teilen mit den Vorschlägen des Projektes Decentralized Privacy-Preserving Proximity Tracing Protocol (DP3T), welches von einer unabhängigen Gruppe europäischer Forscher entwickelt wurde und dessen Beispiel-Quellcode bereits seit einiger Zeit auf der Entwicklungsplattform GitHub rege diskutiert wird.
Apple, Google und die internationale Forschergemeinde hinter DP3T betreiben diesen Aufwand, damit es sich die Regierungen diverser Staaten nicht zu einfach machen und die einfachste Möglichkeit des Contact Tracings umsetzen: Das Smartphone des Nutzers zeichnet per GPS alle seine Bewegungen auf und übermittelt diese an einen zentralen Server unter staatlicher Kontrolle. Ein absolutes Horrorszenario, das es um jeden Preis zu verhindern gilt. Denn hat ein Staat erst einmal diese Art Kontrolle über seine Bürger, ist es unwahrscheinlich, dass er sie freiwillig wieder abgibt. Historiker erkennen in einer solchen Perpetuierung von Notstandsgesetzen ein immer wieder auftretendes Problem moderner Staatsgebilde.
Im Folgenden beschreiben wir Apples und Googles Vorschlag zur Umsetzung eines Contact-Tracing-Systems, das dieser auf Grund der Marktdominanz von Android- und iOS-Geräten wohl die größte Chance hat, sich europaweit durchzusetzen. Dabei handelt es sich aber nicht etwa um Apps, sondern um ein API des jeweiligen Betriebssystems, das dann wiederum von Apps der Gesundheitsämter verschiedener Länder genutzt werden kann. Eine deutsche Corona-App könnte später also beispielsweise genau auf diese Infrastruktur aufbauen.
Ziel ist es, ein System zu entwickeln, mit dem mögliche Kontakte von infizierten Personen gewarnt werden können, damit diese sich dann selbst in Quarantäne begeben und sie so die Infektionskette des Virus durchtrennen. Damit sollen weitere Infektionen verhindert werden. Das soll allerdings erreicht werden, ohne dass die Teilnehmer an diesem System sich gegenseitig identifizieren können. Vor allem soll niemand Rückschlüsse darauf ziehen können, wer infiziert ist. Und es soll verhindert werden, dass irgend eine der Parteien, vor allem der Staat, aus den Tracing-Daten einen Social Graph der Bewegungen der Teilnehmer des Systems rekonstruieren kann.
Tracing ohne Tracking
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.
Was passiert, sobald ein Nutzer positiv getestet wurde?
Sobald ein Nutzer der Contact-Tracing-App sich selbst gegenüber der App als SARS-CoV-2-positiv erklärt, benennt das System die Temporary Exposure Keys für die Tage, an denen der Nutzer als infektiös galt, in Diagnosis Keys um. Diese werden dann an den zentralen Server des Systems übermittelt. Hier weiß der Server zwar, von welchem Handy die Daten kommen, kann aber ansonsten keine Rückschlüsse auf den Nutzer des Gerätes treffen, da dieses ja alle 24 Stunden zufällige neue Temporary Exposure Keys generiert, die sich nicht vorhersagen lassen. Der Server bekommt 14 Keys für die Tage, in denen der Nutzer infektiös war, kann aber nicht sagen, wie dessen Keys in den Tagen davor aussahen oder wie neu generierte Keys in Zukunft aussehen werden. Apple und Google sagen in ihrer Dokumentation, dass der Server keine Metadaten über das Client-Gerät, dass Diagnosis Keys hochlädt, speichern darf.
Zusammen mit dem Rolling Proximity Identifier strahlt das Gerät des Nutzers zusätzlich Bluetooth-Metadaten ab, die dabei helfen sollen, die Entfernung der beiden Geräte voneinander einzuschätzen. Außerdem enthalten sie Angaben über die Länge und Intensität des Funkkontaktes der beiden Handys. Diese Daten sind mit einem eigenständigen 128-Bit-AES-Schlüssel geschützt, der als AEM Key* bezeichnet wird – AEM steht für Associated Encrypted Metadata. Auch der AEM Key wird per HKDF aus dem Temporary Exposure Key erzeugt. Der Empfänger dieser Datenpakete kann sie also erst entschlüsseln, wenn er den Diagnosis Key eines als positiv identifizierten Nutzers vom zentralen Server geladen hat. Vorher sind diese Daten nutzlos.
Zuordnung von Kontakt-Events und Infektionsgefahr
Ein Smartphone, auf dem das Contact Tracing aktiv ist, sammelt also den ganzen Tag Rolling Proximity Identifiers von anderen Geräten ein. Da sich diese regelmäßig ändern, kann sich der Empfänger nicht mal sicher sein, ob zwei unterschiedliche IDs, die er über den Tag hinweg gesehen hat, zum selben Endgerät gehören – sie ändern sich ja alle paar Minuten zusammen mir der MAC-Adresse des Gerätes. Diese IDs werden 14 Tage lang gespeichert, also so lange, wie es für den Krankheitsverlauf von COVID-19 relevant ist.
Meldet sich nun ein Nutzer des Contact-Tracing-Systems bei seiner App als SARS-CoV-2-positiv, so sendet dessen App seine Diagnosis Keys und die dazugehörigen Unix-Zeitstempel für die relevanten Tage an den zentralen Server. Dieser Server verteilt nun die Diagnosis Keys aller positiven Nutzer an alle anderen Teilnehmer des Systems. Wahrscheinlich wird das in der Praxis nicht weltweit passieren, sondern nur für die relevante geografische Region des entsprechenden Nutzers, um den Datenverkehr handhabbar zu halten.
Das Gerät eines Empfängers eines Diagnosis Keys errechnet aus diesem nun, zusammen mit den Unix-Zeitstempeln, die Rolling Proximity Identifiers für die 24 Stunden, in denen dieser gültig war und vergleicht sie mit den Rolling Proximity Identifiers, die es in seiner Datenbank gespeichert hat. Wenn es Übereinstimmungen gibt, hat das Gerät ein Smartphone eines später positiv getesteten Patienten gesehen. Die zu dem Kontakt gehörigen Bluetooth-Metadaten werden erst entschlüsselt, wenn ein solcher Kontakt bestätigt wurde. Nun warnt die App den Nutzer, dass er potenziell Kontakt zu einer infizierten Person hatte. Übereinstimmende Ergebnisse dieses Vergleichs verbleiben auf dem Gerät und dürfen nicht an den Server zurückgemeldet werden.
Die verschachtelt erzeugten Schlüssel sorgen dafür, dass es zwielichtigen Beobachtern von außen, die einfach möglichst viele Proximity IDs mitschreiben, unmöglich gemacht werden soll, einzelne Teilnehmer des Tracing-Systems zu verfolgen. Außerdem soll der zentrale Server davon abgehalten werden, einzelne (infizierte) Nutzer zu identifizieren. In einer früheren Version des Protokolls hatte jeder Nutzer noch einen einmaligen Key, der sich nicht änderte. Dass haben Apple und Google zugunsten der Temporary Exposure Keys geändert, die sich alle 24 Stunden ändern.
Dezentrale oder zentrale Datenverarbeitung?
Apples und Googles Vorschlag wird, genau wie das zugrundeliegende Konzept von DP3T, als dezentrales System bezeichnet. Obwohl ein zentraler Server beteiligt ist, bleiben die Tracing-Daten auf den jeweiligen Geräten der Nutzer. Bis sich ein Nutzer als infiziert outet, werden keine Daten zurück an den Server übermittelt. Und selbst infizierte Personen können nicht eindeutig identifiziert werden, man kann nur ihre Kontakte rekonstruieren. Und auch das ist über die 14 Tage hinaus nicht möglich.
Das steht im Gegensatz zur zentralen Datenverarbeitung, wie sie vom PEPP-PT-Projekt und auch von der französischen Regierung befürwortet wird. Dieser Ansatz hätte einige Vorteile. Unter anderem könnten Epidemiologen die Daten für Studien der Ausbreitung des SARS-CoV-2-Virus nutzen. Außerdem könnten die Entwickler des Systems die Bluetooth-Reichweitenmessung und andere Variablen im System auf das anpassen, was der App im täglichen Einsatz in der echten Welt begegnet. Auf diese Weise könnten etwa unnötige Fehlalarme verhindert und die Genauigkeit des Systems als Ganzes verbessert werden. Eine Idee wäre, diese Feinjustierungen mit Hilfe von Machine-Learning-Algorithmen vorzunehmen, was zwingend auf dem zentralen Server passieren muss. Einen solchen Ansatz scheinen die Verantwortlichen des PEPP-PT-Projektes zu verfolgen.
Apple, Google, die DP3T-Entwickler, viele Wissenschaftler, Datenschutzexperten und Krypto-Fachleute sprechen sich allerdings gegen eine solche zentrale Lösung aus, da ihrer Meinung nach in diesem Fall die Privatsphäre der Nutzer nicht ausreichend geschützt wird. Sie argumentieren, dass dies dem öffentlichen Ansehen solcher Apps schaden würde, was dann dazu führt, dass vor allem in datenschutzkritisch-gestimmten Ländern nicht genügend Bürger eine solche App installieren würden. Sie berufen sich auf die Studie der Universität von Oxford zum Potential von Tracing-Apps, die mindestens 60% Installationsdichte als nötig ansieht und sehen es als unwahrscheinlich an, dass eine zentral-verwaltete App mit schlechter Presse wegen mangelndem Datenschutz das erreichen könne.
Wenn Apple und Google ihren dezentralen Kurs beibehalten, könnte der Einbau ihrer API in Android und iOS sowieso Fakten schaffen, welche die Diskussion schnell irrelevant erscheinen lassen. Den Einschätzungen vieler Entwickler nach lässt sich eine Bluetooth-App, die immer an ist, sowieso nur mit Hilfe der Betriebssystem-Macher sinnvoll umsetzen. Die Frage ist nur, ob Regierungen wie in Frankreich die beiden Großkonzerne dazu bewegen könnten, ihr Konzept zu ändern.
Schwachstellen des Systems
Soweit man das im Moment in einem vernünftigen Rahmen einschätzen kann, ist Apples und Googles Entwurf kryptotechnisch solide und schützt die Privatsphäre der Nutzer auf clevere Weise. Allerdings kann niemand heute garantieren, dass man an Hand der bald millionenfach herumschwirrender Proximity IDs aber nicht doch mit Hilfe von Metadatenanalyse die Bewegungen einzelner Nutzer tracken kann. Es gilt nach aktuellem Wissen auf jeden Fall als relativ sicher, dass das geplante Tracing-System einem solchen Vorhaben signifikante Hürden in den Weg legt.
Natürlich muss man Apple und Google vertrauen. Beide Firmen wissen ganz genau, wer der Nutzer des entsprechenden Endgerätes ist und es wäre ihnen ein leichtes, ihn mit seinen Diagnosis Keys und daraus resultierenden Proximity IDs zu verknüpfen. Dass man dem Hersteller seines Betriebssystems vertrauen muss, ist allerdings immer der Fall. Trotzdem lohnt es sich, darüber noch einmal explizit nachzudenken, wenn es um hochsensible Gesundheits- und Verbindungsdaten geht. Auf jeden Fall birgt das von beiden Firmen vorgeschlagene System viel weniger Missbrauchspotenzial als ein zentrales System, welches womöglich noch unter der direkten Kontrolle einer Regierung steht.
Sollte ich eine Corona-App installieren?
Ob man am Ende eine App, die auf diesem Tracing-Ansatz beruht, installieren will, muss natürlich jeder selbst entscheiden. Das hängt neben Apples und Googles Umsetzung des Betriebssystem-APIs zusätzlich auch noch von der eigentlichen App ab, die man als Endbenutzer schließlich verwendet und ob diese App ohne Sicherheitslücken und Datenschutzmängel daherkommt. Und hinzu kommen noch ganz andere, praktische Fragen. Zum Beispiel dazu, wie sich der permanente Bluetooth-Einsatz auf die Akkulaufzeit meines Handys auswirkt. Und ob sich das Herunterladen der Diagnosis Keys negativ bei meinem Datenvolumen bemerkbar macht.
Sicher ist: Mit einer solcher App helfe ich nur der Allgemeinheit. An meinem persönlichen Krankheitsverlauf ändert sich rein gar nichts, denn Aufgabe der App ist es, mich zu warnen, damit ich mich dann vorsorglich in Quarantäne begeben kann. Ob ich mich infiziere oder nicht, hängt von Virenpartikeln in der Luft oder auf Oberflächen ab, die ich unbewusst aufnehme und schließlich in meinen Blutkreislauf bringe, nicht aber davon, ob mein Smartphone nebenbei noch Bluetooth-Signale in die Welt sendet.
Empfohlener redaktioneller Inhalt
Mit Ihrer Zustimmmung wird hier ein externes Video (Kaltura Inc.) geladen.
Ich bin damit einverstanden, dass mir externe Inhalte angezeigt werden. Damit können personenbezogene Daten an Drittplattformen (Kaltura Inc.) übermittelt werden. Mehr dazu in unserer Datenschutzerklärung.
Unabhängig von meinem persönlichen Krankheitsverlauf könnte so eine App, wenn genug Menschen sie installieren, dazu führen, dass der aktuell geltende Corona-Lockdown gelockert wird, Leute wieder ins normale Leben zurückkehren können und ernste wirtschaftliche Konsequenzen abgemildert werden. Und das wäre, gesellschaftlich gesehen, definitiv ein sehr gutes Ergebnis für uns alle. Ob eine solche App und das darunterliegende Framework allerdings so funktioniert, wie wir uns das alle erhoffen und die Ausbreitung von COVID-19 statistisch signifikant eindämmt, wird sich erst noch zeigen müssen.
Im Großen und Ganzen: ein persönliches Fazit
Der Autor dieses Artikels hält es jedenfalls für sehr fraglich, dass genug Menschen diese App installieren und dass sie dann auch noch gut genug funktioniert, um ihr Ziel zu erreichen. Ganz unabhängig von der technischen Raffinesse der Lösung, die Apple und Google hier erdacht haben, scheint mir eine solche App doch eher ein psychologisches Pflaster für die geschundene Seele der Tech-Nerds im Silikon Valley zu sein, die einfach nicht wahr haben wollen, dass sich manche Probleme einfach nicht mit technologischen Mitteln lösen lassen.
Bluetooth war halt nie für diese Art von Entfernungsmessung gedacht und Contact Tracing überlässt man am besten den Gesundheitsämtern und nicht einer App, oder schlimmer, ominösen KI-Algorithmen auf staatlichen Servern. COVID-19 ist schon schlimm genug, wir sollten dafür sorgen, dass wir es im Nachgang nicht auch noch mit COVID-1984 zu tun bekommen. Ich werde so eine App deswegen nicht installieren und bleibe dafür wohl einfach mal öfter vorsorglich zu Hause, bis sich die Lage wieder beruhigt hat.
(jk)