Seite 3: Was passiert, sobald ein Nutzer positiv getestet wurde?

Inhaltsverzeichnis

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.