DE102021119728A1

DE102021119728A1 - Anonymes verteiltes System zur Kontaktverfolgung und -verifizierung

Info

Publication number: DE102021119728A1
Application number: DE102021119728.7A
Authority: DE
Inventors: Markus Miettinen; Duc Thien Nguyen; Ahmad-Reza Sadeghi
Original assignee: Technische Universitaet Darmstadt
Current assignee: Technische Universitaet Darmstadt
Priority date: 2020-07-31
Filing date: 2021-07-29
Publication date: 2022-02-03
Also published as: US20220051808A1

Abstract

Die Erfindung betrifft ein automatisiertes Kontaktverfolgungssystem zur anonymen Identifizierung von Kontakten zwischen Benutzern, wobei das System mindestens einen Tracing-Server und mehr als ein mobiles Gerät oder Wearable eines Benutzers umfasst, das Mittel zur Nahbereichskommunikation und Mittel zur Ausführung eines Computerprogramms zur Erzeugung von Encounter-Tokens umfasst, wenn ein Benutzer eine vordefinierte Zeitspanne in einem vordefinierten Nahbereich eines anderen Benutzers verbracht hat. Die vorliegende Erfindung zielt darauf ab, die technischen Probleme des Standes der Technik zu überwinden. Insbesondere wird eine Lösung mit verbesserten Datenschutzmöglichkeiten für den Benutzer bereitgestellt. Weiterhin wird ein entsprechendes Computerprogramm, eine sogenannte App, für erschwingliche mobile Geräte oder Wearables bereitgestellt.

Description

Die vorliegende Technologie bezieht sich auf ein automatisiertes Kontaktverfolgungssystem zur anonymen Identifizierung von Kontakten zwischen Benutzern und ein Verfahren zum Betrieb eines solchen Systems. Ferner geht es um ein Verfahren zum Betrieb eines Servers in einem automatisierten Kontaktverfolgungssystem, ein Computerprogramm zum Erstellen von Encounter-Tokens und ein mobiles Gerät oder ein Wearable, das ein solches Computerprogramm enthält.
Hintergrund und Überblick
Die Kontaktverfolgung ist eine bekannte Technik zur Gewinnung von Informationen über persönliche Begegnungen, die in vielen verschiedenen Anwendungsbereichen einsetzbar ist.
Ein Anwendungsfeld kann die Kontaktverfolgung zur Seuchenbekämpfung sein. Viele ansteckende Krankheiten wie das durch das Corona-Virus SARS-CoV-2 verursachte COVID-19 verbreiten sich durch direkten Kontakt zwischen Personen. Um die Ausbreitung von Infektionen in der Bevölkerung zu stoppen, müssen die Gesundheitsbehörden Kontakte und ganze Kontaktketten von infizierten Personen identifizieren und isolieren. Die Kontaktverfolgung beruht derzeit hauptsächlich auf Selbstauskünften der infizierten Personen, was zu einer unvollständigen Liste von Kontakten führt, da sich die Nutzer oft nicht an alle Personen erinnern können, mit denen sie in letzter Zeit in Kontakt waren. Außerdem wird die Rückverfolgung hauptsächlich manuell von den Behörden durchgeführt, was einen enormen Arbeitsaufwand bedeutet. Dies wird zunehmend schwieriger, wenn die Anzahl der infizierten Personen hoch wird.
Ein weiteres Anwendungsfeld kann ein Szenario sein, in dem Benutzer eine überprüfbare Kontaktaufnahme auf automatische und anonyme Weise wünschen. Ein Beispiel für einen solchen Anwendungsfall könnten z.B. Teilnehmer einer Konferenz sein, die später miteinander interagieren wollen, ohne zum Zeitpunkt der Begegnung detaillierte Kontaktdaten austauschen zu müssen.
US2017352119 (A1) offenbart ein System und eine Berechnungsmethode zum Verfolgen der Annäherungsbeziehungen von Personen über ihre mobilen Geräte, so dass solche Annäherungsbeziehungen identifizieren können, wann und wo Personen miteinander in Kontakt kommen. Dementsprechend können die verfolgten Annäherungsbeziehungen Annäherungsbeziehungsdaten bereitstellen. Die Annäherungsbeziehung kann dadurch definiert werden, dass eine erste Person mit einer zweiten Person in Kontakt kommt, was mit einem Signalverfolger verfolgt werden kann. Der Signalverfolger kann ein Signal von einem signalgebenden Gerät, z. B. einem mobilen Gerät, erfassen, und wenn die erste Person das signalgebende Gerät in der Nähe des Signalverfolgers hat, kann der Signalverfolger erfassen und aufzeichnen, dass die erste Person in der Nähe des Signalverfolgers war. Der Signalverfolgungsbereich des Signalverfolgers kann verwendet werden, um eine Annäherungszone der signalabgebenden Vorrichtung an den Signalverfolger zu definieren, wobei Annäherungsgrade Grade der Nähe zum Signalverfolger sein können, und dadurch kann jeder Signalverfolger mehrere Annäherungszonen als konzentrische Zonen mit dem Signalverfolger im Wesentlichen in der Mitte für jede Zone haben. Wenn sich die zweite Person in einer Annäherungszone befindet, während sich die erste Person in der gleichen Annäherungszone befindet, sind die erste Person und die zweite Person so definiert, dass sie eine Annäherungsbeziehung haben. Das System arbeitet mit Personen, die über mobile Computergeräte (MCDs) verfügen, die eine oder mehrere Arten von Signalen aussenden, die von dem einen oder mehreren Signaldetektoren des Signalverfolgers erfasst werden können. Der Signalverfolger empfängt Näherungsdaten von den MCDs und überträgt einige oder alle Näherungsdaten an ein Server-Computersystem.
Es wurde eine Reihe anderer Verfolgungsansätze vorgeschlagen, die auf dem Austausch von Informationen über Proximity-Kommunikation basieren.
Die Exposure Notification API von Apple und Google (https://www.apple.com/covid19/contacttracing) hat erhebliche Schwächen in Bezug auf die Privatsphäre-Eigenschaften. Sie basiert auf sich häufig ändernden, zufälligen Pseudonymen, so genannten Rolling Proximity Identifiers (RPI). Bei diesem Ansatz generiert jede Tracing-App diese RPIs aus einem Daily Tracing Key (DTK) und sendet sie per Bluetooth LE in ihre Umgebung. Apps auf anderen Geräten, die sich in der Nähe befinden, können diese RPIs beobachten und lokal als Aufzeichnung des Kontakts mit dem Gerät, das die RPI beamt, speichern. Dieser Datensatz enthält auch zusätzliche Metadaten wie die empfangene Signalstärke. Sollte ein Benutzer positiv auf COVID-19 getestet werden, lädt die App dieses Benutzers DTKs der letzten x Tage auf einen zentralen Server hoch (derzeit x = 14). Der Server sammelt die empfangenen DTKs von infizierten Personen und bietet sie den Apps anderer Benutzer zum Download an. Die Apps der anderen Benutzer überprüfen den Server regelmäßig auf Updates und laden neue DTKs herunter. Jede App verwendet dann die heruntergeladenen DTKs, um die entsprechenden RPI-Pseudonyme zu berechnen, die von den Apps der infizierten Personen in der jüngsten Vergangenheit verwendet wurden. Das Betriebssystem/der entsprechende Systemdienst vergleicht dann die RPIs dieser infizierten Personen mit den lokal auf dem Gerät gespeicherten RPIs. Wenn übereinstimmende RPIs gefunden werden, werden die Metadaten, z. B. die Signalstärke oder die Dauer der Begegnungen, die mit diesen übereinstimmenden RPIs verbunden sind, verwendet, um einen Risikoscore zu berechnen, der verwendet wird, um zu bestimmen, ob dem Benutzer eine Warnung angezeigt werden soll oder nicht. Der Ansatz von Apple und Google ist somit anfällig für Angriffe zur Erstellung von Benutzerprofilen. Ein Angreifer, der die in einem bestimmten Bereich angezeigten RPIs beobachtet und aufzeichnet, kann seine Beobachtungen mit den veröffentlichten RPIs von infizierten Personen abgleichen und so ein Bewegungsprofil der betreffenden Person erstellen.
Das Contact-Tracing-Framework DP-3T (https://github.com/DP-3T/documents) (Design 2) basiert ebenfalls auf sich häufig ändernden pseudonymen Identifikatoren, sogenannten Ephemeral IDs, die Tracing Apps in ihrer Umgebung aussenden. Tracing Apps zeichnen alle Ephemeral IDs auf, die sie beobachten, um später Kontakte zu ermitteln. Infizierte Benutzer laden ihre Ephemeral IDs auf den Tracing Server hoch, der diese an andere Benutzer weitergibt. Die Tracing Apps anderer Benutzer laden die veröffentlichten Ephemeral IDs herunter und vergleichen sie mit den Ephemeral IDs, die sie zuvor beobachtet und lokal gespeichert haben. Dieses Design ist nicht in dem Maße anfällig für den Profiling-Angriff, wie es der Vorschlag von Apple und Google ist, da die veröffentlichten Ephemeral IDs nicht miteinander verknüpft werden können. Allerdings ist dieser Ansatz anfällig für so genannte Relay-Angriffe. Bei solchen Angriffen zeichnet der Angreifer Ephemeral IDs am Ort A auf und überträgt und sendet sie an einen entfernten Ort B. Das Ziel des Angreifers ist es, das Verfolgungssystem zu sabotieren, indem er gefälschte Kontakte zwischen den Benutzern herstellt. Auch der Ansatz von Apple und Google ist anfällig für diesen Angriff.
Die österreichische StoppCorona Contact Tracing App (https://participate.roteskreuz.at/stopp-corona/) basiert ebenfalls auf dem Austausch von öffentlichen Schlüsseln zwischen Tracing Apps. Allerdings erfolgt der Austausch der öffentlichen Schlüssel mithilfe eines Cloud-Dienstes, von dem die einzelnen öffentlichen Schlüssel heruntergeladen werden. Wenn zwei Tracing Apps aufeinandertreffen, ermitteln sie die gemeinsame Anwesenheit in der Nähe mithilfe des Google Here-Dienstes oder eines ähnlichen Dienstes namens p2pKit. Die Tracing Apps laden dann über den Cloud-Dienst den öffentlichen Schlüssel des Gegenübers auf ihr Gerät herunter. Das Paar öffentlicher Schlüssel - privater Schlüssel jeder Tracing App bleibt immer gleich. Wenn ein Benutzer mit der Krankheit infiziert ist, verschlüsselt seine Tracing App Nachrichten mit einer Warnung unter Verwendung der öffentlichen Schlüssel der Tracing Apps, auf die sie gestoßen ist, und lädt diese verschlüsselten Nachrichten auf den Tracing Server hoch. Alle anderen Suchdienst-Apps laden diese Nachrichten herunter und versuchen, sie mit ihrem privaten Schlüssel zu entschlüsseln. Gelingt die Entschlüsselung, ist dies ein Hinweis darauf, dass ein Kontakt mit einer infizierten Person stattgefunden hat und die Tracing App kann ihren Benutzer warnen. Die österreichische Lösung leidet unter der Schwachstelle der Benutzerverfolgung. Da der Cloud-Dienst an allen Austauschen von öffentlichen Schlüsseln beteiligt ist, kann er alle Begegnungen zwischen Benutzern verfolgen, was die Privatsphäre des Benutzers stark beeinträchtigt. Da der öffentliche Schlüssel der Benutzer statisch ist, ist einerseits die Erstellung von Benutzerbewegungsprofilen möglich, indem die öffentlichen Schlüssel beobachtet werden, die Tracing Apps an verschiedenen Orten übertragen.
Zusammenfassung der Erfindung
Die vorliegende Erfindung wurde im Hinblick auf den oben genannten Stand der Technik gemacht und zielt darauf ab, deren technische Probleme zu überwinden. Insbesondere soll eine Lösung mit verbesserten Datenschutzmöglichkeiten für den Benutzer bereitgestellt werden. Weiterhin soll ein entsprechendes Computerprogramm, eine sogenannte App, für erschwingliche mobile Geräte oder Wearables bereitgestellt werden.
Diese Aufgabe wird gelöst durch ein automatisiertes Kontaktverfolgungssystem zum anonymen Erkennen von Kontakten zwischen Nutzern mit den Merkmalen des Anspruchs 1, ein Verfahren zum Betreiben eines automatisierten Kontaktverfolgungssystems zum anonymen Erkennen von Kontakten zwischen Nutzern mit den Merkmalen des Anspruchs 3, ein Verfahren zum Betreiben eines Servers in einem automatisierten Kontaktverfolgungssystem zum anonymen Erkennen von Kontakten zwischen Nutzern mit den Merkmalen des Anspruchs 6 und ein Computerprogramm zum Herstellen von Encounter-Tokens mit einem Nahbereichskommunikationsprotokoll mit den Merkmalen des Anspruchs 9. Vorteilhafte Ausführungsformen und Weiterbildungen werden in den abhängigen Ansprüchen beansprucht.
Die vorliegende Erfindung überwindet die technischen Probleme des bekannten Standes der Technik. Insbesondere stellt sie eine Lösung mit verbesserten Datenschutzmöglichkeiten für den Benutzer bereit. Ferner wird eine entsprechende App für kostengünstige mobile Geräte oder Wearables bereitgestellt.
Die vorliegende Erfindung ermöglicht keinen Profiling-Angriff ähnlichen demjenigen bei der Exposure Notification API von Apple und Google, da die Tracing App einer infizierten Person nur solche Encounter Tokens an den Tracing Server hochlädt, die eine ausreichend lange Dauer (z.B. 10 Minuten) haben, die für die Übertragung der Krankheit relevant ist.
Außerdem ist die vorliegende Erfindung widerstandsfähiger gegen Relay-Angriffe als das Contact Tracing Framework DP-3T. Um gefälschte Encounter Tokens zu erzeugen, reicht es nicht aus, kryptografische Tokens von A nach B weiterzuleiten und dort erneut zu verbreiten. Der Angreifer müsste auch kryptografische Token am Ort B aufzeichnen und sie an A weiterleiten, damit der Angriff erfolgreich ist.
Das automatische Kontaktverfolgungssystem gemäß der vorliegenden Erfindung ist in der Lage, Kontakte zwischen Personen anonym zu identifizieren. In diesem System verwenden menschliche Benutzer eine auf ihrem mobilen Gerät, z. B. einem Smartphone oder noch bevorzugter einem erschwinglichen Armband, installierte Tracing App, um mit Hilfe eines Nahbereichskommunikationsprotokolls, wie z. B. Bluetooth Low Energy (Bluetooth LE), sogenannte Encounter Tokens zu ermitteln, wenn sie sich eine bestimmte Zeit lang in unmittelbarer Nähe aufhalten. Andere mögliche Kommunikationsprotokolle sind WiFi, Bluetooth, Mobilfunksignale, RFID oder Reifendrucküberwachungssignale (TPMS) und andere Arten von Signalen. Jedes mobile Gerät hat vorzugsweise die Fähigkeit, Signale zu/von einem anderen mobilen Gerät zu senden und/oder zu empfangen. Des Weiteren hat jedes mobile Gerät vorzugsweise die Fähigkeit, Signale zu/von einem Tracing-Server zu senden und/oder zu empfangen. Dieser Tracing-Server kann ein einzelner Server, ein Server-Array, ein verteilter Server, etc. sein. Der Nahbereich wird durch die jeweiligen Bedürfnisse definiert und könnte weniger als 10 Meter, bevorzugt weniger als 8 Meter, noch bevorzugter weniger als 5 Meter und am meisten bevorzugt weniger als 2 Meter betragen. Ein zusätzlicher Faktor, der ebenfalls in den Metadaten des Encounter Tokens gespeichert werden kann, ist die Dauer der Begegnung, die vorzugsweise mehr als 2 Minuten, vorzugsweise mehr als 10 Minuten und besonders bevorzugt mehr als 20 Minuten und am meisten bevorzugt mehr als 30 Minuten beträgt.
In einer Ausführungsform der Erfindung erlaubt das System App-Benutzern, die mit einer ansteckenden Krankheit infiziert sind, mit Hilfe eines Online-Serversystems ausgewählte Encounter Tokens, die sie erstellt haben, freizugeben und zu veröffentlichen, um andere Benutzer zu warnen, mit denen sie in Kontakt waren, und somit einen Encounter Token zu teilen. Andere Benutzer können diese Encounter Tokens vom Online-Server herunterladen und mit den von ihnen lokal gespeicherten Encounter Tokens abgleichen. Wenn ein übereinstimmendes Encounter Token gefunden wird, ist dies ein Hinweis auf eine Begegnung mit dem infizierten App-Benutzer. Die App kann dann den Benutzer warnen, dass ein Kontakt mit einer infizierten Person stattgefunden hat, so dass der Benutzer geeignete Maßnahmen ergreifen kann, wie z. B. Selbstquarantäne oder das Durchführen eines Tests, um festzustellen, ob der Benutzer infiziert wurde.
In einer anderen Ausführungsform der Erfindung kann der Encounter Token als anonym verifizierter Kontakt-Identifikator verwendet werden, z. B. um später verifizierte Kommunikation zwischen den Teilnehmern der Begegnung zu ermöglichen.
In einer weiteren Ausführungsform der Erfindung können Encounter Tokens auch dazu verwendet werden, eine anonyme Gruppe von Personen zu bilden, z. B. Personen, die an einer Veranstaltung teilnehmen oder einen bestimmten Ort besuchen. In einigen Ausführungsformen der Erfindung könnte dies dadurch erreicht werden, dass die kryptographischen Tokens, die zur Erstellung von Encounter Tokens verwendet werden, nicht einzelnen Tracing Apps, sondern Gruppen von Tracing Apps zugeordnet werden. Die erstellten Encounter Tokens wären somit spezifisch für diese Gruppe und nicht für einzelne Personen.
Darüber hinaus könnte eine andere Ausführungsform der Erfindung den Encounter Token als Verschlüsselungsschlüssel verwenden, um Nachrichten zwischen Benutzern oder Gruppen von Benutzern zu verschlüsseln, die sich zuvor begegnet sind.
Die Informationen, die in den Metadaten des Encounter Tokens enthalten sind, können entweder in der Tracing App vordefiniert sein oder vom Benutzer festgelegt werden. Die Metadaten können die Begegnungs-Token-ID des anderen Benutzers, die Entfernung, die Dauer, die Uhrzeit und das Datum der Begegnung enthalten. Sie können auch die Positionsdaten und die MAC-Adresse des mobilen Geräts enthalten, falls erforderlich.
In einer Ausführungsform der Erfindung werden zufällige ephemere kryptografische Token über das Proximity-Kommunikationsprotokoll unter Verwendung von Smartphones gesendet und empfangen. In einer anderen Ausführungsform der Erfindung können auch beliebige tragbare Geräte wie Armbänder verwendet werden, um die Token auszutauschen, da in vielen Anwendungsfällen Smartphones nicht bequem oder sogar nicht erlaubt sind, z. B. bei sportlichen Aktivitäten, bei Kindern oder in vielen Krankenhäusern. Darüber hinaus können solche erschwinglichen Armbänder von den Gesundheitsbehörden kostenlos verteilt werden, um eine maximale Nutzung des automatisierten Kontaktverfolgungssystems zur anonymen Identifizierung von Kontakten zwischen Benutzern zu ermöglichen. Ebenso können solche Armbänder auch als Give Aways für Konferenzteilnehmer in anderen Tracing-Szenarien verwendet werden. Andere mögliche Beispiele sind ausrichtende Organisationen von Veranstaltungen, Schul- oder Universitätsoffizielle, Einrichtungen, die Büroinfrastruktur betreiben, oder ähnliche Stellen.
Die vorliegende Erfindung könnte verwendet werden für

- Pandemiebekämpfung als Kontaktverfolgungssystem zur Verfolgung der Infektionsketten von Virusinfektionskrankheiten wie COVID-19; oder jedes andere gesundheits- oder katastrophenspezifische Verfolgungssystem; oder
- Direkte, verifizierbare und private Kontaktaufnahme und Nachrichtenübermittlung mit verschiedenen Anwendungen, z.B. Auswertung bei Begenungen von Personal, das Strahlung ausgesetzt war.

Die Erfindung ist kommerziell anwendbar, z. B. durch einen Dienstanbieter, der Verfolgungsserver betreibt, Web-Apps, mobile Apps, APIs (für Wearables), Plug-Ins oder Bibliotheken bereitstellt, die in andere Apps von Drittanbietern integriert werden können, Dashboards, Statistiken und Datenanalyse, Messaging.
Das autonome, anonyme, dezentralisierte und die Privatsphäre wahrende Kontaktverfolgungssystem könnte auch verwendet werden für

- Begegnungsbasierte direkte, verifizierbare und private Kontaktaufnahme und Messaging-Dienste
- Begegnungsbasierte statistische Dienste
- zentrale oder dezentrale Verteidigung anonymer oder identifizierter Systeme bei Anwendungsfällen.

Figurenliste
Um die Art und Weise, in der die oben beschriebenen Ausführungsformen implementiert sind, sowie andere Vorteile und Merkmale der Offenbarung am besten zu beschreiben, wird im Folgenden eine genauere Beschreibung gegeben, die in den beigefügten Zeichnungen dargestellt ist. Unter der Maßgabe, dass diese Zeichnungen nur beispielhafte Ausführungsformen der Erfindung darstellen und daher nicht als einschränkend zu betrachten sind, werden die Beispiele mit zusätzlicher Spezifität und Detail durch die Verwendung der beigefügten Zeichnungen beschrieben und erläutert, in denen:

1a eine Systemübersicht zeigt;
1b eine Systemübersicht mit einem Server einer Gesundheitsbehörde zeigt;
1c eine Encounter-Token-Erzeugung zeigt;
2 eine Überprüfung des Infektionsstatus zeigt;
3 das Hochladen eines Encounter-Tokens zeigt;
4 einen Encounter Token Download und eine Kontaktverifizierung zeigt;.

AUSFÜHRLICHE BESCHREIBUNG
Im Folgenden werden verschiedene Ausführungsformen des offenbarten Systems und der Verfahren im Detail besprochen. Während spezifische Implementierungen diskutiert werden, sollte verstanden werden, dass dies nur zu Illustrationszwecken geschieht. Ein Fachmann wird erkennen, dass andere Komponenten, Konfigurationen und Schritte verwendet werden können, ohne vom Geist und Umfang der Offenbarung abzuweichen.
1a zeigt eine Systemübersicht für eine Ausführungsform der vorliegenden Erfindung. Das System umfasst zwei Hauptkomponenten, nämlich jeweilige Tracing-Apps und einen Tracing-Server. Die Tracing-Apps sind auf den jeweiligen mobilen Geräten des Benutzers A und des Benutzers B installiert. Die mobilen Geräte kommunizieren über ein Nahbereichskommunikationsprotokoll miteinander. Außerdem kommuniziert jedes mobile Gerät von Benutzer A und Benutzer B mit einem Tracing-Server.
1b zeigt eine weitere Ausführungsform mit einem Server einer Gesundheitsbehörde. Dieser Server ist mit einem infizierten Benutzer A und mit dem Tracing-Server verbunden, damit der Tracing-Server dem Benutzer B, der eine Begegnung mit Benutzer A hatte, das Risiko einer Infektion aufgrund eines früheren Kontakts mit einer infizierten Person mitteilen kann.
Der Betrieb des Systems aus 1a und 1b kann die folgenden Schritte aufweisen: Erstellen von Encounter-Tokens;
Optionale Verifizierung von infizierten Benutzern, falls in einem epidemologischen Kontext verwendet;
Hochladen des Encounter-Tokens auf einen Tracing-Server;
Herunterladen von Encounter-Tokens von einem Tracing-Server und Kontaktverifizierung; Optionale Freigabe von Kontaktdaten für die epidemiologische Forschung, wenn der Benutzer dies akzeptiert.
Zur Herstellung von Encounter Tokens verwendet die Tracing App eines Benutzers ein Proximity-Kommunikationsprotokoll mit begrenzter Reichweite, um die Anwesenheit von Tracing Apps anderer Benutzer zu erfassen. In einer Ausführungsform der Erfindung könnte das verwendete Proximity-Kommunikationsprotokoll Bluetooth Low Energy sein. In einer anderen Ausführungsform der Erfindung können andere Proximity-Kommunikationsprotokolle wie ZigBee, Z-Wave oder ähnliche Protokolle verwendet werden. Jedes generiert einen zufälligen ephemeren kryptografischen Token und gibt diesen über das Proximity-Kommunikationsprotokoll bekannt. Tracing Apps auf Geräten anderer Benutzer in der Nähe erfassen diese Tokens und speichern sie lokal auf dem mobilen Gerät des anderen Benutzers zur weiteren Verarbeitung.
In einer Ausführungsform der Erfindung enthält dieser kryptografische Token einen zufällig erzeugten ephemeren öffentlichen Schlüssel, der mit der Tracing-App eines Benutzers verbunden ist. In einer anderen besonderen Ausführungsform der Erfindung ist der ephemere öffentliche Schlüssel ein öffentlicher elliptischer Kurven Schlüssel. Der von der Tracing App eines Benutzers bekannt gemachte kryptografische Token muss häufig geändert werden, um Tracing-Angriffe gegen die Tracing App des Benutzers zu vereiteln. In einer Ausführungsform der Erfindung wird der kryptografische Token alle 30 Minuten geändert.
Jede Tracing App eines Benutzers gibt kontinuierlich ihren aktuell gültigen kryptografischen Token bekannt und erfasst jeden anderen kryptografischen Token, der von einer Tracing App eines anderen Benutzers erzeugt und gesendet wird, den sie in einer vordefinierten Nähe wahrnehmen kann. Wenn die Tracing-App eines Benutzers einen kryptografischen Token erkennt, der von einer Tracing-App eines anderen Benutzers ausgesendet wurde, speichert sie den erkannten Token lokal und führt eine Ableitungsfunktion für einen Encounter-Token aus, um einen Encounter-Token für die Begegnung mit dem anderen Benutzer abzuleiten.
Wenn ein mobiles Gerät ein anderes mobiles Gerät findet, starten die beiden Geräte den Austausch ephemerer kryptografischer Token. Zunächst startet ein Gerät den Bluetooth-Client und das andere Gerät den Bluetooth-Server und beide Geräte tauschen ihre kryptografischen Token (CTs) (520-Bit-Länge) aus. Beide Geräte speichern die CTs, die später zur Berechnung von Encounter Tokens (ET) verwendet werden. Die CTs können alle 30 Minuten zusammen mit dem ephemeren Identifikator (EID) geändert werden. Um Energie zu sparen, darf der CT während der 30-minütigen Lebensdauer nur gesendet werden, wenn das Gerät ein neues Gerät findet.
In der Ableitungsfunktion des Encounter-Tokens sind zumindest die folgenden Daten als Eingabe gegeben: der empfangene kryptografische Token der Tracing App des anderen Benutzers und der generierte kryptografische Token der eigenen Tracing App, der zum Zeitpunkt des Empfangs des anderen kryptografischen Tokens gültig war. Basierend auf diesen Eingaben wird ein Encounter Token von der Encounter-Token-Ableitungsfunktion berechnet.
In einer Ausführungsform der Erfindung, die in 1c dargestellt ist, führt die Funktion zur Ableitung des Encounter-Tokens einen bekannten Elliptische Kurven Diffie-Hellman (ECDH)-Schlüsselaustauschalgorithmus durch, bei dem das Encounter-Token ein Sitzungsschlüssel ist, der unter Verwendung der kryptografischen Token erstellt wird, die die öffentlichen Schlüssel der entsprechenden Tracing-Apps darstellen.
In einer anderen Ausführungsform der Erfindung wird der Diffie-Hellman-Schlüsselaustauschalgorithmus verwendet. In einer weiteren Ausführungsform der Erfindung kann auch ein symmetrisches Schlüsselvereinbarungsprotokoll verwendet werden.
In einer weiteren Ausführungsform der Erfindung kann die Begegnungsableitungsfunktion eine einfache Exklusiv-Oder-Operation (XOR) sein, die auf die kryptografischen Token (CT) angewendet wird.
In einer Ausführungsform der Erfindung werden die kryptografische Token-Generierungsfunktion und die Encounter-Token-Ableitungsfunktion während der Zeit ausgeführt, in der das mobile Gerät geladen wird, z. B. während der Nacht, um die Batterielebensdauer des mobilen Geräts zu erhalten.
Jede Tracing App speichert die abgeleiteten Encounter Tokens lokal zusammen mit Metadaten, die die Begegnung charakterisieren. In einer Ausführungsform der Erfindung umfassen die Metadaten mindestens folgende Datenelemente: Dauer der Begegnung, der Begegnung zugeordnete Signalstärken sowie weitere kontextbezogene Informationen über die Begegnung. In einer weiteren Ausführungsform der Erfindung speichert die App auch den Ort der Begegnung als Metadaten.
Um sicherzustellen, dass nur Benutzer, die wirklich infiziert wurden, ihre Begegnungs-Token melden können, muss das System den Infektionsstatus des Benutzers verifizieren, der seine Begegnungs-Token an den Tracing Server übermittelt. Dies kann auf verschiedene Weise geschehen.
In einer Ausführungsform der Erfindung, wie in 2 dargestellt, gibt ein Gesundheitsbehörden-Server einen Authentifizierungscode auth-code an einen Benutzer aus, der positiv auf die Krankheit getestet wurde. Um seinen Infektionsstatus zu verifizieren, wird der Benutzer diesen Authentifizierungscode auth-code in die Tracing App eingeben. Die Tracing App wird dann den Authentifizierungscode auth-code für die Ableitung eines Authentifizierungswertes auth-val beim Hochladen von Encounter Tokens auf den Tracing Server verwenden. In einer anderen Ausführungsform der Erfindung leitet die Tracing App den Authentifizierungswert auth-val unter Verwendung des Authentifizierungscodes auth-code und anderer Metadaten wie einem Datum, einem Zeitstempel oder einem Ortscode ab.
In einer weiteren Ausführungsform der Erfindung kann der Authentifizierungscode auth-code in Form eines QR-Codes gegeben sein, der auf Papier gedruckt oder als PDF-Datei per E-Mail übertragen wird. Der Benutzer kann dann die QR-Code-Lesefunktion der Tracing App verwenden, um den QR-Code zu fotografieren. Die Tracing App extrahiert dann den im QR-Code enthaltenen Auth-Code.
Hochladen des Encounter-Tokens.
Der Benutzer gibt den Authentifizierungscode auth-code in seine App ein, wenn er die Encounter Tokens (ET) auf den Tracing Server hochlädt. Der Server der Gesundheitsbehörde sendet die Liste der gültigen Auth-Codes, die an infizierte Benutzer ausgegeben wurden, an den Tracing Server.
In einer Ausführungsform der Erfindung sendet die Tracing App den Authentifizierungscode auth-code an den Tracing Server. Der Tracing Server prüft, ob der von der Tracing App empfangene Auth-Code in der Liste der vom Server der Gesundheitsbehörde empfangenen gültigen Auth-Codes enthalten ist und antwortet mit einer Nonce (Zufallszahl, einmalig verwendet).
Die Tracing App leitet dann einen Authentifizierungswert auth-val ab und hängt ihn an die Nachricht mit den Encounter Tokens an, die sie zum Tracing Server hochlädt. Der auth-val ist ein kryptografischer Nachrichtenauthentifizierungscode (MAC), der aus den Encounter-Tokens abgeleitet wird, wobei der Authentifizierungscode auth-code als Schlüssel für den Authentifizierungscode verwendet wird: auth-val = MAC(auth-code | ET_1 | ET_2 | ... | ET_k). In einer Ausführungsform der Erfindung wird die vom Tracing Server empfangene Nonce als Schlüssel zum MAC verwendet: auth-val = MAC(nonce, | ET_1 | ET_2 | ... | ET_k).
In einer weiteren Ausführungsform der Erfindung hängt der auth-val auch von Metadaten ab, die sich auf die Encounter Tokens beziehen: auth-val = MAC(auth-code, metadata, | ET_1 | ET_2 | ... | ET_k), oder, auth-val = MAC(nonce, metadata, | ET_1 | ET_2 | ... | ET_k).
Wenn die Tracing App ihre Encounter Tokens an den Tracing Server sendet, prüft der Tracing Server den Authenticator-Wert auth-val, indem er berechnet, ob er unter Verwendung eines gültigen Auth-Codes oder Nonce abgeleitet ist. Wenn der Authentifikatorwert gültig ist, werden die übermittelten Encounter Tokens akzeptiert und vom Tracing Server lokal gespeichert. Andernfalls werden sie zurückgewiesen und verworfen.
In einer weiteren Ausführungsform der Erfindung, die in 3 dargestellt ist, sendet die Tracing App einen Authentifizierungscode auth-code an den Tracing Server und erhält vom Tracing Server eine Liste von Nonces (n_1, n_2, ..., n_k). Die Tracing App berechnet dann einen Authentifizierungswert auth-val_i für jeden Encounter Token ET_i separat: auth-val_1 = MAC(n_1 | ET_1), auth-val_2 = MAC(n_2 | ET_2), ..., auth-val_k = MAC(n_k | ET_k). Der Tracing Server überprüft dann jedes Encounter Token ET_i separat, indem er verifiziert, dass sein Authentifikatorwert auth-val_i unter Verwendung einer gültigen Nonce n_i abgeleitet ist.
In einer bevorzugten Ausführungsform der Erfindung werden die Encounter Token (ET) nicht im Klartext an den Tracing Server übertragen, sondern es wird stattdessen ein kryptografischer Hashwert h(ET) des Encounter Token übertragen.
In einer bevorzugten Ausführungsform der Erfindung lädt die Tracing App nur solche Encounter Token hoch, die eine Dauer haben, die einen Schwellenwert für die Mindestdauer überschreitet (z. B. 10 Minuten). Damit soll vermieden werden, dass unnötige Informationen veröffentlicht werden, die für die Übertragung der Krankheit nicht relevant sind, und so die Privatsphäre des Benutzers geschützt werden.
4 veranschaulicht den Download des Encounter Token und die Kontaktverifizierung. Jede am System teilnehmende Tracing App kann regelmäßig verifizierte Encounter Tokens ET vom Tracing Server herunterladen. In einer bevorzugten Ausführungsform der Erfindung findet der Download mindestens einmal täglich statt. In einer anderen Ausführungsform wird der Zeitpunkt des Downloads basierend auf einem zufälligen Zeitintervall innerhalb der maximalen Intervalldauer bestimmt.
Die Tracing App wird eine Liste (ET_1, ET_2, ..., ET_k) von Encounter Tokens herunterladen. Sie vergleicht dann jeden dieser Encounter Token mit der Liste der Encounter Token, die lokal auf dem mobilen Gerät gespeichert sind. Wenn ein übereinstimmendes ET_i gefunden wird, benachrichtigt die Tracing App den Benutzer, dass eine Begegnung mit einer positiv auf die Infektionskrankheit getesteten Person stattgefunden hat. In einer weiteren Ausführungsform der Erfindung können auch andere geeignete Aktionen durch die Tracing App ausgelöst werden, darunter z. B. die Kontaktaufnahme oder Kommunikation mit Gesundheitsbehörden.
In einer anderen Ausführungsform der Erfindung können nach dem Auffinden eines passenden Encounter Tokens zusätzliche Metadaten, die mit dem Encounter Token gespeichert sind, untersucht werden, um ein Infektionsrisikoniveau zu bestimmen.
In einer weiteren Ausführungsform kann die Benachrichtigung über den Kontakt mit einer infizierten Person durch die Tracing App nur dann ausgelöst werden, wenn das ermittelte Risikoniveau einen bestimmten Schwellenwert überschreitet.
In einer weiteren Ausführungsform können die von der Tracing App ergriffenen Maßnahmen von dem ermittelten Risikoniveau abhängig sein.
In einer bevorzugten Ausführungsform der Erfindung basiert der Abgleich von Encounter Tokens auf den kryptografischen Hashwerten h(ET) der Encounter Tokens (ET).
In einer Ausführungsform der Erfindung kann die Tracing App verwendet werden, um Informationen über verifizierte Begegnungen mit einer externen Instanz zu teilen. Eine externe Instanz könnte z. B. ein epidemiologisches Forschungsinstitut sein. In dieser Ausführungsform fügt die Tracing App der infizierten Person jedem Encounter Token ET_i einen individuellen verschlüsselten Nonce-Wert enc-n_i zu, wobei der Encounter Token ET_i als Verschlüsselungsschlüssel verwendet wird: enc-n_i = encryption(ET_i, n_i). In dieser Ausführungsform werden nur kryptografische Hash-Werte der Encounter Tokens an den Tracing Server gesendet.
In dieser Ausführungsform rufen andere Tracing Apps die verifizierten kryptografischen Hash-Werte h(ET_i) sowie die verschlüsselten Encounter Token-spezifischen Nonce-Werte enc-n_i vom Tracing Server ab. Die Tracing Apps vergleichen die kryptografischen Hashes mit den kryptografischen Hashes ihrer eigenen Encounter Token und wenn eine Übereinstimmung festgestellt wird, verwenden sie den Wert des übereinstimmenden Encounter Token ET_i, um den Nonce-Wert n_i zu entschlüsseln: n_i = decryption(ET_i, encn_i).
In einer bevorzugten Ausführungsform dieser Erfindung wird der Verschlüsselungsalgorithmus AES zur Verschlüsselung und Entschlüsselung verwendet.
In einer bevorzugten Ausführungsform der vorliegenden Erfindung erhält die Tracing App der infizierten Person die verwendeten Encounter Token-spezifischen Nonces n_i vom Tracing Server. In einer anderen Ausführungsform generiert die Tracing App der infizierten Person die Encounter Token-spezifischen Nonces selbst und stellt die Liste der Nonces dem Tracing Server zur Verfügung, wenn sie ihre Encounter Tokens zum Tracing Server hochlädt.
Um einer externen Instanz zu ermöglichen, Kontakte zu infizierten Personen zu verifizieren, teilt der Tracing Server die Liste der Encounter Token-spezifischen Nonces mit der externen Entität. Wenn eine Tracing App feststellt, dass ein Kontakt mit einer infizierten Person stattgefunden hat, verwendet sie den passenden Encounter Token wie oben beschrieben, um die Nonce zu entschlüsseln, die mit dem passenden Encounter Token verbunden ist, und kann diese Nonce an die externe Instanz senden. Wenn die Nonce in der Liste der Nonces enthalten ist, die der externen Instanz vom Tracing Server zur Verfügung gestellt wurde, ist die Nonce ein gültiger Nachweis für einen Kontakt mit einer infizierten Person.
In einer Ausführungsform der Erfindung verfolgt die externe Instanz die Nonces, die ihr als Kontaktnachweis zur Verfügung gestellt werden, und akzeptiert nur eine Instanz jeder Nonce, um es böswilligen Tracing Apps unmöglich zu machen, Kontaktnachweise durch Senden einer entschlüsselten Nonce zu duplizieren.
In einer Ausführungsform der Erfindung wird die für den Austausch der kryptografischen Token erforderliche Proximity-Kommunikation durch ein externes Wearable realisiert. Wearables können Armbänder, Armreife, Halsketten, Schmuckstücke usw. mit eingebauter Verarbeitungsfähigkeit, Speicher und Proximity-Kommunikationsschnittstellen zur Kommunikation mit anderen Tracing Apps oder Wearables sein. Der Hauptvorteil dieser Ausführungsform ist, dass die Tracing-Funktionalität nicht an den Besitz eines Smartphones gebunden ist, sondern auch in Nutzungskontexten eingesetzt werden kann, in denen die Verwendung oder das Tragen eines Smartphones unpraktisch oder nicht möglich ist. Beispiele für solche Nutzungskontexte sind sportliche Aktivitäten, Kinder in der Schule oder auf dem Spielplatz und andere vergleichbare Situationen, in denen nicht davon ausgegangen werden kann, dass die Nutzer ständig ein Smartphone bei sich tragen. Das Tragen eines Armbands hingegen ist nicht störend und kann in den meisten Situationen verwendet werden, z. B. auch unter der Dusche, da Armbänder im Gegensatz zu vielen Smartphone-Modellen in der Regel wasserdicht sind.
In dieser Ausführungsform ist das Wearable mit der Tracing-App des Benutzers gekoppelt und kommuniziert über das Proximity-Kommunikationsprotokoll mit der Tracing-App. Die Tracing App generiert kryptografische Token, die für die Einrichtung des Encounter Tokens verwendet werden, und lädt sie über den Proximity-Kommunikationskanal auf das Wearable hoch. Das Wearable speichert die kryptografischen Token lokal.
Nach einem festgelegten Zeitplan überträgt das Wearable den kryptografischen Token über das Proximity-Kommunikationsprotokoll in seine Nähe. Das Wearable tauscht kryptografische Token mit anderen Geräten in der Nähe aus und speichert kryptografische Token anderer Geräte, auf die es trifft, lokal. Das Wearable und das Smartphone synchronisieren regelmäßig ihre Daten, so dass das Smartphone die von ihm erzeugten kryptografischen Token an das Wearable sendet und das Wearable die von ihm lokal gespeicherten kryptografischen Token zusammen mit den dazugehörigen Metadaten an das Smartphone sendet. Diese Synchronisationsfunktion kann periodisch ausgeführt werden oder wenn das Smartphone aufgeladen wird oder wenn der Benutzer mit der Tracing App interagiert, d.h. die App im Vordergrund läuft.
Die Rolle des Armbands könnte darin bestehen, die kryptografischen Token auszutauschen, die für die Erstellung von Encounter Tokens erforderlich sind, und diese an die Tracing App zu übertragen, mit der es gekoppelt ist. Die Ableitung von Encounter Tokens, das Hochladen von Encounter Tokens auf den Tracing Server, sowie das Herunterladen von Encounter Tokens und die Kontaktverifizierung werden von der Tracing App unabhängig vom Wearable durchgeführt. Die Tracing App könnte auf einem Smartphone, einem PC-Computer oder einem anderen geeigneten Gerät installiert werden, das mit dem Armband und dem Tracing Server verbunden wird.
Das Hoch- und Herunterladen von Informationen kann in Echtzeit oder nachträglich erfolgen, je nach Bedarf und Art des verwendeten Geräts.
Die Anzahl der zu erwartenden Begegnungen ist relevant für die Größe des Datenspeichers, den das mobile Gerät bereitstellen soll. Im Durchschnitt hat ein Benutzer ca. 20 Begegnungen (15 Minuten oder länger) mit anderen Benutzern, ausgenommen bekannte Kontakte, z. B. Haushaltsmitglieder oder Kollegen im gleichen Büro. Daher beträgt die erwartete Anzahl von Begegnungen pro Tag 20 Begegnungen, vorzugsweise 30 Begegnungen, noch bevorzugter 50 Begegnungen pro Tag.
Die App des infizierten Benutzers lädt die Hashes (128 Bit) der Encounter Tokens (ETs) 14 Tage lang hoch. Daher kann die Gesamtmenge der von der App auf den Server hochgeladenen Daten wie folgt geschätzt werden: 14 Tage*20 Encounter Tokens*128 Bits = 35.840 (Bits) oder 4,3 (kB). Bei einer höheren Anzahl von Begegnungs-Token erhöht sich diese Datenmenge entsprechend.
Unter der Annahme, dass es 2000 neue COVID-19-Fälle pro Tag gibt, wird die Tracing-App gemäß einer Ausführungsform der vorliegenden Erfindung 2000 Fälle* 4,3kB = 8.600 (kB) oder 8,6 MB pro Tag vom Tracing-Server herunterladen. Auch hier variiert die Datenmenge in Abhängigkeit von den angenommenen Fallzahlen und der Menge der hochgeladenen Daten.
Unter der Annahme, dass es 2000 neue COVID-19-Fälle pro Tag gibt, erhält der Tracing-Server 2000 Fälle* 4,3kB = 8.600 (kB) oder 8,6 MB pro Tag (das entspricht den Daten, die eine App heruntergeladen hat).
Wenn man weiter annimmt, dass es 50 Millionen App-Benutzer gibt, wird der Tracing-Server 50.000.000 Benutzer* 8,6 MB = 430.000.000 (MB) oder 430 TB pro Tag senden. Wenn die Anzahl der Benutzer höher ist, müssen die Zahlen entsprechend angepasst werden und die Kapazität des Tracing-Servers muss diesen Zahlen entsprechen.
Um einen Encounter Token (ET) zu etablieren, muss das mobile Gerät eine Anzeigenachricht (AM) und einen kryptografischen Token (CT) senden und empfangen, die jeweils 192 + 520 = 712 (Bits) oder 712 *2 = 1.424 (Bits) betragen. Im schlechtesten Fall beträgt die BLE-Bandbreite 125 (kbit/s), d. h. die Tracing-App kann 125.000/1.424 = 175 ETs pro Sekunde aufbauen. Im Idealfall beträgt die BLE-Bandbreite 2 Mbit/s, d. h. die Tracing-App kann 2.000.000/1.424 = 1.404 ETs pro Sekunde aufbauen. Da die Latenzzeit für den Aufbau einer BLE-Verbindung jedoch ca. 6 ms beträgt, kann die Tracing-App nur 1000/6 = 160 ETs pro Sekunde aufbauen, wenn man davon ausgeht, dass die Datenübertragungszeit viel kleiner ist als die Verbindungszeit, kann man davon ausgehen, dass die Tracing-App maximal 100 Encounter pro Sekunde aufbauen kann.
Gemäß einer Ausführungsform der vorliegenden Erfindung zeigt die Tracing-App ständig an und scannt nach Anzeigenachrichten (AMs). Die Tracing-App zeigt periodisch jede Minute AMs an, wobei Geräte 40 Sekunden lang BLE-Anzeigen ausführen und 20 Sekunden lang im Leerlaufzustand sind. Die Tracing-App scannt periodisch alle 50 Sekunden AMs, wobei Geräte 30 Sekunden lang BLE-Scans durchführen und sich 20 Sekunden lang im Leerlaufzustand befinden. Diese Anzeige- und Scanmuster werden empirisch ausgewählt, um sicherzustellen, dass die Tracing-App alle 2 Minuten andere Geräte verfolgt.
Gemäß einem Aspekt der Erfindung werden keine Positionsdaten in den Metadaten des Encounter-Tokens bereitgestellt. Dies erhöht die Privatsphäre des Benutzers und ist für die Bewertung eines Infektionsrisikos nicht notwendig. In anderen Ausführungsformen können die Positionsdaten jedoch in den Metadaten des Encounter-Token enthalten sein.
Der Fachmann wird verstehen, dass andere Ausführungsformen der Erfindung in einem automatisierten Kontaktverfolgungssystem zur anonymen Identifizierung von Kontakten zwischen Benutzern eingesetzt werden können. Ausführungsformen können auch in verteilten Computerumgebungen eingesetzt werden, in denen Aufgaben von lokalen und entfernten Verarbeitungsgeräten ausgeführt werden, die über ein Kommunikationsnetzwerk miteinander verbunden sind (entweder durch festverdrahtete Verbindungen, drahtlose Verbindungen oder durch eine Kombination davon). In einer verteilten Rechnerumgebung können sich Programmmodule sowohl in lokalen als auch in entfernten Speichergeräten befinden.
Die Kommunikation auf verschiedenen Stufen des beschriebenen Systems kann über eine Vielzahl von Kommunikationsprotokollen erfolgen. Obwohl sich die zugrunde liegende Kommunikationstechnologie ändern kann, sind die hier beschriebenen Grundprinzipien weiterhin anwendbar.
Die verschiedenen oben beschriebenen Ausführungsformen dienen nur zur Veranschaulichung und sollten nicht als Einschränkung der Erfindung verstanden werden. Zum Beispiel können die hier beschriebenen Prinzipien auf jedes mobile Gerät oder jeden Tag angewendet werden. Der Fachmann erkennt ohne Weiteres verschiedene Modifikationen und Änderungen, die an der vorliegenden Erfindung vorgenommen werden können, ohne den hier dargestellten und beschriebenen Ausführungsbeispielen und Anwendungen zu folgen, indem nur einige technische Merkmale verschiedener Ausführungsformen, soweit technisch möglich, kombiniert werden, ohne vom Umfang der vorliegenden Offenbarung abzuweichen.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

US 2017352119 [0005]

Claims

Automatisiertes Kontaktverfolgungssystem zur anonymen Identifizierung von Kontakten zwischen Benutzern, wobei das System mindestens einen Tracing-Server und mehr als ein mobiles Gerät oder Wearable eines Benutzers umfasst, das Mittel zur Nahbereichskommunikation und Mittel zur Ausführung eines Computerprogramms zur Erzeugung von Encounter-Tokens umfasst, wenn ein Benutzer eine vordefinierte Zeitspanne in einem vordefinierten Nahbereich eines anderen Benutzers verbracht hat.
System nach Anspruch 1, ferner umfassend einen Server einer Gesundheitsbehörde, der mit dem Tracing-Server und dem mobilen Gerät eines Benutzers verbunden werden kann.
Verfahren zum Betreiben eines automatisierten Kontaktverfolgungssystems zur anonymen Identifizierung von Kontakten zwischen Benutzern, umfassend die folgenden Schritte a) Senden eines kryptografischen Tokens von einem mobilen Gerät eines Benutzers; b) Empfangen eines weiteren kryptografischen Tokens von einem mobilen Gerät eines anderen Benutzers, der sich innerhalb einer vordefinierten Zeitspanne in einem vordefinierten Nahbereich des Benutzers befindet; c) Erzeugen eines verschlüsselten Encounter-Tokens auf dem mobilen Gerät des Benutzers basierend auf den Informationen, die in dem empfangenen kryptografischen Token und dem gesendeten kryptografischen Token enthalten sind; d) Speichern des erzeugten Encounter-Tokens lokal auf dem mobilen Gerät des Benutzers; e) Hochladen des auf dem mobilen Gerät des Benutzers erzeugten Encounter-Tokens auf den Tracing-Server; f) Herunterladen von auf dem Tracing-Server gespeicherten Encounter-Tokens auf das mobile Gerät des Benutzers; und g) Kontaktverifizierung auf Basis der vom Benutzer heruntergeladenen Encounter-Tokens.
Verfahren nach Anspruch 3, ferner umfassend die Verifizierung infizierter Benutzer durch Empfangen eines vom Server der Gesundheitsbehörde ausgegebenen Authentifizierungscodes auf dem mobilen Gerät des Benutzers und Senden des Authentifizierungscodes von dem mobilen Gerät des Benutzers an den Tracing-Server, der den empfangenen Authentifizierungscode mit einer vom Server der Gesundheitsbehörde empfangenen Liste gültiger Authentifizierungscodes vergleicht.
Verfahren nach Anspruch 3 oder 4, wobei das verwendete Proximity-Kommunikationsprotokoll eines von Bluetooth Low Energy, ZigBee, Z-Wave oder ähnlichen ist.
Verfahren zum Betreiben eines Tracing-Servers in einem automatisierten Kontaktverfolgungssystem zur anonymen Identifizierung von Kontakten zwischen Benutzern, umfassend die folgenden Schritte a) Empfangen von Encounter-Tokens, die von mobilen Geräten von Benutzern erzeugt werden; b) Speichern von Encounter-Tokens für eine vordefinierte Dauer; c) Erlauben des Herunterladens von gespeicherten Encounter-Tokens auf das mobile Gerät des Benutzers.
Verfahren nach Anspruch 6 ferner aufweisend das automatische Löschen von Encounter-Tokens nach einer vordefinierten Dauer.
Verfahren nach Anspruch 6 oder 7, ferner aufweisend die freiwillige Freigabe von Kontaktdaten.
Computerprogramm zum Erzeugen von Encounter-Tokens, wenn ein Benutzer eine bestimmte Zeitspanne in einer vordefinierten Nähe eines anderen Benutzers verbracht hat, umfassend Anweisungen, die, wenn das Programm von einem Computer ausgeführt wird, den Computer veranlassen, Folgendes auszuführen Empfangen eines kryptografischen Tokens von der Tracing App eines anderen Benutzers; Erzeugen eines kryptografischen Tokens der eigenen Tracing App, der zu dem Zeitpunkt gültig war, als der andere kryptografische Token empfangen wurde; Berechnen eines Encounter Tokens mit einer Encounter Token Ableitungsfunktion.
Computerprogramm nach Anspruch 9, das, wenn das Programm von einem Computer ausgeführt wird, den Computer veranlasst, einen zufälligen ephemeren kryptografischen Token zu erzeugen.
Computerprogramm nach Anspruch 9 oder 10, das, wenn das Programm von einem Computer ausgeführt wird, den Computer veranlasst, den zufälligen ephemeren kryptografischen Token über das Proximity-Kommunikationsprotokoll bekannt zu machen.
Computerprogramm nach einem der Ansprüche 9 bis 11, das, wenn das Programm von einem Computer ausgeführt wird, den Computer veranlasst, empfangene kryptografische Token zur weiteren Verarbeitung lokal zu speichern.
Mobiles Gerät oder Wearable mit Mitteln zur Nahbereichskommunikation und Mitteln zum Ausführen eines Computerprogramms zur Erzeugung von Encounter-Tokens.