Blog

Sinn und Unsinn der Corona-Warn-App

Die Corona-Warn-App auf dem Prüfstein: Was lässt sich nach mehr als 100 Tagen sagen?

Die Coronavirus-Pandemie hat seit Monaten die Welt fest im Griff. Die Infektionszahlen steigen. Die zweite Welle, sie rollt. Umso wichtiger ist eine sichere und schnelle Nachverfolgung der Kontakte und der damit verbundene Schutz aller Menschen. In vielen Ländern wurden deshalb bereits digitale Tracing-Apps eingeführt, um eine weitere Ausbreitung der Pandemie zu verhindern. Je nachdem wie hoch die Priorität der Datenschutzaspekte in den einzelnen Ländern ist, kommen dabei unterschiedliche Ansätze zum Tragen: ein zentrales oder dezentrales Kontaktnachverfolgungssystem.

In Deutschland gab es eine lebhafte Debatte über die Einhaltung des Datenschutzes und letztendlich fiel die Wahl auf eine dezentrale Lösung. Die Mitte Juni veröffentlichte Corona-Warn-App ist in Deutschland gut angenommen worden. Inzwischen mehren sich jedoch die Zweifel an ihrem Nutzen – besonders im Hinblick auf die Kosten. Es ist nicht klar, wie viele Menschen sie tatsächlich nutzen und welchen Mehrwert sie für die Eindämmung der Corona-Pandemie hat.

Um zu beurteilen, ob und inwiefern die Corona-Warn-App bei der Eindämmung der Corona-Pandemie nützlich ist, liefert der folgende Beitrag einen Überblick. Dazu sind neben Ergebnissen eigener Untersuchungen internationale Studien sowie die aktuelle Berichterstattung eingeflossen.

Unser Ziel ist es, eine kritische Auseinandersetzung zu initiieren, die die Kosten-Nutzen-Relation und noch wichtiger die technologische Souveränität erörtert. Außerdem geht es darum, die wissenschaftliche Forschung voranzutreiben. Dafür wurden folgende Aspekte näher betrachtet:

  • Datenübertragung via Bluetooth-Technologie und deren Tücken
  • Angriffe auf die Corona-Warn-App – wie sicher sind die Daten?
  • Wie viele Menschen nutzen die Corona-Warn-App?
  • Dezentrale App ohne datenschützende digitale Infrastruktur 
  • Souveränität statt Dominanz von Google und Apple

Klicken Sie hier für den vollständigen Bericht.

Wie die Google-Apple-Lösung Bewegungsprofile von infizierten Personen preisgibt

Vor kurzem veröffentlichten wir eine Publikation, die im Detail erläutert, wie ein Angreifer die Informationen, die durch den Kontaktnachverfolgungsansatz von Google und Apple (GAP) freigegeben werden, dazu verwendet, detaillierte Bewegungsprofile der Infizierten Personen zu erstellen. Auch die deutsche Corona-Warn-App ist hiervon betroffen, da sie auf dem GAP-Ansatz aufbaut und daher auch dieselben Schwachstellen hat.

Wir haben viele Fragen zu dieser Publikation bekommen und wollen deshalb hier noch in einer etwas vereinfachten Form darstellen, warum der GAP-Ansatz die Informationen preisgibt, die es erlauben, die Bewegungen von infizierten Personen im Detail nachzuvollziehen.

Der GAP-Ansatz

Wie viele andere Tracing-Ansätze auch, basiert der GAP-Ansatz auf mobilen Smartphone-Apps, die Informationen über Bluetooth LE austauschen, wenn zwei App-Nutzer eine Begegnung haben, bei der sich unter Umständen eine Ansteckung stattfinden könnte. Im GAP-Ansatz geschieht dies, indem die Apps kurzlebige Bluetooth-Kennungen, sogenannte Rolling Proximity Identifier (RPIs), in ihre Umgebung ausstrahlen. Diese RPIs werden von anderen Apps in der Nähe registriert und lokal gespeichert. Mithilfe der gespeicherten RPIs können Apps im Nachhinein feststellen, ob ein Kontakt mit einem infizierten App Nutzer stattgefunden hat, wenn sie die RPIs dieses Nutzers in Erfahrung bringen und mit ihren lokal gespeicherten RPIs abgleichen können.

Im GAP-Ansatz, wie in Abbildung 1 unten gezeigt, generiert jede Tracing App täglich sogenannte Daily Tracing Keys (DTK), also sich täglich ändernde ‚Tagesschlüssel‘. Von diesen Tagesschlüsseln werden dann die RPIs für den jeweiligen Tag abgeleitet, sodass jedes dieser RPIs ca. 10 Minuten gültig ist und dann gegen ein neues RPI ausgewechselt wird. An einem Tag (24 Stunden) verwendet eine App insgesamt 144 verschiedene RPIs.

Abbildung 1: Google-Apple (GAP) Tracing-Ansatz

Wenn ein App Nutzer positiv auf COVID-19 getestet wird, kann er seine Kontaktpersonen warnen, indem er seine RPIs durch das Tracing-System freigibt. Dies passiert, indem die App dieses Nutzers die Tagesschlüssel (DTKs) der letzten Tage (bis zu 14 Tage) an den Tracing-Server schickt. Der Tracing-Server verteilt die Tagesschlüssel dann weiter an alle anderen Apps im System.

Andere Apps laden sich regelmäßig die neuen DTKs von infizierten Personen auf ihre lokalen Geräte herunter, und generieren mithilfe der DTKs die RPIs der infizierten Personen. Dann vergleichen sie diese RPIs mit den lokal gespeicherten RPIs. Falls es eine Übereinstimmung gibt, ist dies ein Beweis für einen Kontakt mit einer infizierten Person und die App kann den Nutzer hierüber warnen.

Das Problem

Das Problem beim GAP-Ansatz ist, dass die DTKs jeweils für 24 Stunden gültig sind, und daher alle am System Teilnehmenden nicht nur die RPIs einer infizierten Person ableiten können, sondern auch ganz genau wissen, dass diese RPIs derselben Person zugeordnet werden können. Dies heißt, dass wenn ein Angreifer in einem bestimmten Gebiet strategisch platzierte Bluetooth-Sensoren dazu benutzt, um RPIs von vorbeilaufenden Tracing-App-Nutzern zu sammeln, der Angreifer im Nachhinein in der Lage ist, mithilfe der von infizierten Nutzern freigegebenen DTKs, die dazugehörigen RPIs abzuleiten und diese mit seinen aufgezeichneten RPIs abzugleichen. Dadurch kann der Angreifer feststellen, ob und wann eine infizierte Person an seinen Beobachtungssensoren vorbeigelaufen ist und kann unter Umständen ein detailliertes Bewegungsprofil der infizierten Nutzer erstellen.

Der Angriff

Die oben geschilderte Schwachstelle am GAP-Ansatz wurde schon von vielen Sicherheitsforschern theoretisch diskutiert. Um zu zeigen, dass es sich hierbei nicht nur um einen theoretischen, sondern auch um einen durchaus reellen Angriff handelt, haben wir ein Angriffsszenario experimentell nachgestellt und unter realen Bedingungen ausgeführt.

Wir haben, wie in Abb. 2 dargestellt, an diversen Stellen in Darmstadt Bluetooth-Sensoren aufgestellt, die die Sensoren eines Angreifers darstellen sollten. Diese Sensoren waren sehr einfache Smartphone-Apps, die die RPIs von vorbeilaufenden Tracing-App Nutzern über Bluetooth LE sammelten und speicherten.

Abbildung 2: Platzierung der Bluetooth-Sensoren des Angreifers in der Stadtmitte von Darmstadt

Während des Experiments zeichneten wir die RPIs von zwei Testnutzern auf, die sich zeitgleich in der Stadtmitte bewegten. Die Testnutzer nutzten Tracing Apps, die RPIs gemäß der Spezifikation von GAP in ihre Umgebung ausstrahlten.

Ein Beispiel der gesammelten Sensordaten an den Beobachtungsstellen B und E ist in Abb. 3 dargestellt. Wie zu sehen ist, scheinen die gesammelten RPIs zufällig, und lassen keine Rückschlüsse über Bewegungen der Nutzer zu.

Abbildung 3: Gesammelte RPI-Daten an den Beobachtungsstellen B und E

Dieses Bild verändert sich jedoch drastisch, wenn man den Fall simuliert, dass einzelne Nutzer sich mit COVID-19 infiziert haben, und ihre DTKs freigeben, mit deren Hilfe die RPIs der einzelnen Nutzer abgeleitet werden können. Da nun die RPIs eindeutig einzelnen Nutzern zugeordnet werden können, kann man, wie in Abb. 4 exemplarisch gezeigt, Rückschlüsse über die Anwesenheit einzelner Nutzer in der Nähe der Beobachtungsstellen machen.

Abbildung 4: Verlinken der RPIs des Nutzers 1 mithilfe des freigegebenen DTK

Dadurch ist es möglich, die Bewegungen von infizierten Nutzern nachzuvollziehen, wenn sie ihre DTKs freigeben. In unserem Experiment konnten wir dadurch die Bewegungen von zwei Testnutzern rekonstruieren. Abb. 5 zeigt das Resultat.

Abbildung 5: Rekonstruktion der Bewegungsprofile von zwei Nutzern mithilfe der freigegebenen Trading-Daten

Mithilfe der Beobachteten RPIs konnten wir feststellen, dass Nutzer 1 zunächst in der Nähe von Beobachtungspunkt A (ein Wohnquartier) gesichtet wurde und danach in D (Klinikum und Apotheke), C (Polizeistation), B (Rathaus) und E (eine Kneipe), bevor der Nutzer die Runde bei Position A beendete. Es wäre also denkbar, dass Nutzer 1 irgendwo in der näheren Umgebung von A wohnt, da es sich dabei um ein Wohnquartier handelt. Auch könnte man spekulativ ableiten, dass der betroffene Nutzer gesundheitliche Probleme hat, oder mit der Polizei zu tun hat. Für Nutzer 2 konnten wir feststellen, dass er vom Rathaus (B) gestartet ist, einen Abstecher in die Kneipe (E) gemacht hat, bevor er bei Position F gesichtet wurde, in der Nähe eines Lokals für Sportwetten. Des Weiteren konnten wir feststellen, dass beide Nutzer die Position B zur gleichen Zeit verließen und zur gleichen Zeit in der Nähe der Kneipe (E) ankamen, dort eine Weile verbrachten und sogar zur gleichen Zeit die Kneipe wieder verließen. Dadurch liegt die Annahme nahe, dass diese beiden Nutzer eine soziale Beziehung zueinander haben.

Fazit

Unser Experiment zeigt, dass Beobachtungen von Nutzern in Verbindung mit den dazugehörigen Zeitstempeln eine Menge an Informationen über Nutzer verraten können, da der Angreifer Informationen darüber bekommt, welche Orte infizierte Nutzer besucht haben und wie viel Zeit sie dort verbrachten. Diese Informationen können wiederum dazu genutzt werden, um spezifische Lebensumstände von Personen in Erfahrung zu bringen, z.B., in welchem Gebiet die Person wohnt (Aufenthaltsort während der Nacht) und wo sie arbeitet (Aufenthaltsort tagsüber). Je mehr der Angreifer solche distinktiven Einzelheiten über die betroffene Person ableiten kann, desto einfacher ist es für ihn, die Person eindeutig zu identifizieren und dadurch die Anonymität des Systems zu brechen.

Tags:

Corona-Tracing-Ansatz von Google und Apple hat Defizite bei Datenschutz und Sicherheit

Ein Forschungsteam der Technischen Universität Darmstadt, der Universität Marburg und der Universität Würzburg hat jüngst in Publikationen als theoretisch möglich beschriebene Datenschutz- und Sicherheitsrisiken der Spezifikation des von Google und Apple vorgeschlagenen Ansatzes für Corona-Apps unter realistischen Bedingungen praktisch demonstriert und bestätigt. Auf dem Ansatz basiert unter anderem die von der Deutschen Telekom und SAP im Auftrag der Bundesregierung entwickelte deutsche Corona-Warn-App; aber auch die schweizerischen und italienischen Kontaktnachverfolgungs-Apps nutzen diese Plattform.

Durch Experimente in realen Szenarien zeigte das Forschungsteam, dass bereits theoretisch bekannte Risiken mit gängigen technischen Mitteln ausgenutzt werden können. So kann zum einen ein externer Angreifer detaillierte Bewegungsprofile von mit COVID-19 infizierten Personen erstellen und unter bestimmten Umständen die betroffenen Personen identifizieren. Zum anderen ist ein Angreifer in der Lage, die gesammelten Kontaktinformationen durch sogenannte Relay-Angriffe zu manipulieren, was die Genauigkeit und Zuverlässigkeit des gesamten Kontaktnachverfolgungssystems beeinträchtigen kann.

Kontaktnachverfolgungs-Apps auf mobilen Geräten versprechen die Möglichkeit, den manuellen Aufwand zur Identifizierung von Infektionskreisläufen erheblich zu reduzieren und die Abdeckung der Kontaktnachverfolgung zu erhöhen. Einer der bekanntesten Vorschläge zur Kontaktnachverfolgung stammt aus der Zusammenarbeit der Konzerne Google und Apple. Es ist zu erwarten, dass die beiden US-amerikanischen Firmen diese neue Standardfunktionalität in ihre jeweiligen mobilen Betriebssysteme, Android und iOS, integrieren werden. Einige Länder, darunter auch Deutschland, haben in ihren nationalen Projekten zur digitalen Ermittlung von Kontaktpersonen bereits diesen Ansatz gewählt.

Ausgangspunkt für die Experimente der IT-Sicherheitsexperten und -expertinnen der drei Universitäten waren zuvor veröffentlichte Berichte über mögliche Datenschutz- und Sicherheitsrisiken im Zusammenhang mit den Entwicklungen des sogenannten „Google Apple Protokoll“ (GAP). Das Forschungsteam testete, ob die konzeptionell beschriebenen Angriffe in der Praxis ausgeführt werden können. Die Experimente zeigen, dass GAP einerseits anfällig ist für die Erstellung von Profilen und so möglicherweise die De-anonymisierung von infizierten Personen erlaubt. Andererseits sind in GAP auch so genannte Relay- oder Wurmloch-Angriffe möglich, wodurch Angreifer falsche Kontaktinformationen generieren können und somit die Genauigkeit und Korrektheit des Gesamtsystems leidet.

Das Forschungsteam realisierte die Angriffe mithilfe handelsüblicher preiswerter Werkzeuge wie Bluetooth-Sniffer (als App auf Smartphones oder Raspberry Pis), die auch in mobilen Umgebungen eingesetzt werden können. Da die Implementierung des GAP-Ansatzes noch nicht für die breitere Wissenschafts-Community verfügbar ist, hat das Forschungsteam die Angriffe basierend auf bereits publizierten Spezifikationen konstruiert. Die Ergebnisse zeigen, dass bei Verwendung strategisch platzierter Sensoren auf Smartphones in einem bestimmten Gebiet die Bewegungen infizierter Personen, simuliert durch Testpersonen, detailliert rekonstruiert werden können. Dadurch war es möglich, sensible Aufenthaltsorte der Testpersonen sowie mögliche soziale Beziehungen zwischen ihnen zu identifizieren.

Die Anfälligkeit von GAP für sogenannte Relay- oder Wurmloch-Attacken offenbart ebenfalls Schwächen. Diese Methode versetzt einen Angreifer in die Lage, die sogenannten Bluetooth-Benutzer-IDs, die von einer Kontaktnachverfolgungs-App erzeugt werden, zu sammeln und unbemerkt an weiter entfernte Orte weiterzuleiten. Unter anderem konnten erfolgreich Bluetooth-IDs zwischen zwei 40 Kilometer voneinander entfernten Städten übertragen werden. Dadurch kann ein Angreifer das Kontaktnachverfolgungssystem als Ganzes beeinträchtigen, indem er Informationen über die Anwesenheit von Infizierten an vielen Orten fälschlicherweise dupliziert, was zu einer erheblichen Zunahme von Fehlalarmen über das potenzielle Infektionsrisiko führen könnte.

Insgesamt sieht das Forschungsteam noch deutliches Verbesserungspotenzial für den von Google und Apple vorgeschlagenen Ansatz für Corona-Apps. Eine detaillierte Beschreibung der Experimente und ihrer Ergebnisse ist im vollständigen Studienbericht zu finden.

Tags: , ,

Neue App-Version 1.8 Beta veröffentlicht

Seit heute steht eine neue Version 1.8 Beta der TraceCORONA App zum Download bereit. Diese Version beinhaltet mehrere Verbesserungen:

  • Mehrsprachige App: Deutsch oder Englisch
  • Verbesserungen in der Bluetooth-Kommunikation
  • Verbesserungen in der Nutzbarkeit und der Nutzeroberfläche

Sie können die neue App-Version hier herunterladen:

Wir würden uns freuen, wenn Sie sich die Zeit nehmen würden, um die App zu Testen. Eine Anleitung dazu, was sie testen können, finden Sie hier.

Auch würden wir uns über jeglichen Feedback zu der App freuen. Am besten können Sie uns ihr Feedback über user Feedback-Formular zukommen lassen.

Viel Spass und Erfolg beim Testen!

Erhebliche Privatheitsmängel im Corona-Warn-App Konzept der SAP/Telekom

Erste technische Details der Corona-Warn-App, die von SAP und Telekom entwickelt wird, sind herausgegeben worden. Es scheint, dass sich diese Lösung sehr eng an dem von Apple und Google gemachten Vorschlag orientieren wird. Dies ist zum einen gut, da der Grundansatz auf einer verteilten Ermittlung von Kontakten basiert, aber andererseits auch enttäuschend, da dieser Ansatz erhebliche Defizite in Hinsicht auf die Privatheit und Anonymität von infizierten Nutzern vorweist.

Wie schon in einem früheren Blogbeitrag erläutert, ist es klar, dass der Kontaktnachverfolgungsprozess auf einer verteilten Kontaktüberprüfung basieren sollte. Die drei wichtigsten Tracing-Konzepte, die ein solches Modell verfolgen, sind das von Apple und Google vorgeschlagene Konzept, welches jetzt auch für die Corona-Warn-App angewandt wird, der in der Schweiz initiierte Ansatz DP-3T sowie TraceCORONA, das von der Technischen Universität Darmstadt entwickelt wurde.

Von diesen ist der Vorschlag von Apple und Google im Bezug auf den Schutz der Privatheit Infizierter am schwächsten, da infizierte Personen quasi alle Bluetooth-IDs veröffentlichen müssen, die sie an den Tagen verwendet haben, an denen sie möglicherweise infektiös waren (genauer gesagt sind es kryptographische Schlüssel, anhand derer die entsprechenden Bluetooth-IDs abgeleitet werden können). Somit ist es allen am System beteiligten Apps und Systemen möglich, die Bewegungen infizierter Personen während dieser Tage nachzuvollziehen, indem sie Aufzeichnungen von Bluetooth-IDs an spezifischen strategisch gewählten Orten in einem bestimmten Gebiet sammeln und diese dann mit den von Infizierten veröffentlichten Bluetooth-IDs abgleichen. (Dieser Ansatz ist übrigens konzeptuell äquivalent mit dem Design 1 des DP-3T Projekts.) Dies ist eine große Bedrohung für die Anonymität der Nutzer, da bekanntermaßen ein erheblicher Teil aller Menschen anhand ihrer Bewegungsprofile eindeutig identifiziert werden können.

Das Design 2 des Schweizer DP-3T-Projekts bietet einen besseren Schutz für infizierte Personen, da die Verlinkung zwischen den Bluetooth-IDs einer infizierten Person in diesem Modell nur dem Backend-System bekannt ist. Daher können andere Nutzer des Systems die Bluetooth-IDs von Infizierten nicht zur Nachverfolgung ihrer Bewegungen missbrauchen. Im DP-3T-Design 2 ist es jedoch durchaus möglich, dass das Backend-System infizierte Personen missbräuchlich verfolgen könnte, da alle Bluetooth-IDs eines spezifischen Nutzers dem Backend-System bekannt sind.

Im Gegensatz zu fast allen anderen vorgeschlagenen Kontaktnachverfolgungsmodellen basiert TraceCORONA nicht auf häufig wechselnden pseudonymen Bluetooth-IDs, sondern auf Kontakt-Token, die eigentlich starke kryptographische Schlüssel sind und für jede Begegnung zwischen zwei Nutzern separat generiert werden. Die kryptographischen Eigenschaften dieser Kontakt-Token ermöglichen es, dass selbst bei unbefugtem Zugriff auf Informationen im Backend-System sie nicht mit den Bluetooth-IDs verknüpft werden können, die die Geräte über Bluetooth übertragen und mit Bluetooth-Sensoren erfasst werden können. Die Feststellung eines Kontakts ist deshalb nur für die direkt an einem Kontakt beteiligten Geräte möglich, und die Verfolgung infizierter Benutzer daher selbst unter Verwendung von Backend-Systeminformationen nicht möglich. Ein Vergleich der Funktionen und Eigenschaften von TraceCORONA mit anderen wichtigen Tracing-Anwendungsmodellen finden Sie hier.

Tags: , , , , , , , ,

Risiken von Tracing Apps mit unzureichenden Datenschutzlösungen

Die größten Risiken, die mit Kontaktnachverfolgungs-Apps (Contact Tracing) verbunden sind, ergeben sich aus dem potenziellen Missbrauch der von ihnen gesammelten Daten. Im Vergleich zu vielen anderen Anwendungen sammelt eine App zur Kontaktnachverfolgung gezwungenermaßen vertrauliche und detaillierte Informationen über Kontakte und Beziehungen zwischen einzelnen Nutzern. Dazu kommt, dass um effektiv zu sein, eine solche App von möglichst vielen Bürgern freiwillig installiert und aktiv benutzt werden muss. Daher hat eine solche App das Potenzial, erheblich mehr Informationen über Kontakte von Personen zu sammeln als jedes andere derzeit von Behörden verwendete System! Es ist daher wichtig, dass die Implementierung eines solchen Systems so gestaltet wird, dass eine effektive Kontaktnachverfolgung zwar ermöglicht wird, aber dabei die Privatheit der Nutzer so weit wie möglich gewahrt bleibt.

Zentralisierte Tracing-Modelle wie z.B. die in Singapur verwendete TraceTogether-Lösung oder die in Australien verwendete CovidSafe-Anwendung sowie das in Deutschland entwickelte PEPP-PT-Modell bieten diesbezüglich keinen angemessenen Schutz der Privatsphäre für ihre Nutzer.

Diese Systeme basieren auf einem Ansatz, bei dem ein zentrales Back-End-System jeder Benutzeranwendung eine eindeutige Kennung (ein Pseudonym) zuweist, aus der häufig wechselnde pseudonyme Kennnummern (Proximity-IDs) abgeleitet und über Bluetooth an andere Geräte in der Nähe übermittelt werden. Die Schwäche dieses Ansatzes besteht darin, dass das Backend-System alle Proximity-IDs aller Nutzer mit dem eindeutigen Pseudonym eines jeden Nutzers verknüpfen kann. Dies ermöglicht wiederum eine umfassende Überwachung aller Nutzer des Systems.

Durch das Aufzeichnen von Proximity-IDs, die von Bluetooth-Sensoren an mehreren strategisch platzierten Beobachtungspunkten in einem bestimmten Gebiet (z.B. in einer bestimmten Stadt) beobachtet werden, ist es im Prinzip möglich, die Bewegungen einzelner Nutzer zwischen diesen Beobachtungspunkten zu verfolgen und so eventuell sehr detaillierte Bewegungsprofile einzelner Personen zu erfassen.

Obwohl das System die wahren Identitäten einzelner Nutzer nicht explizit erfasst oder aufzeichnet, ermöglichen jedoch solche Bewegungsprofile, einen Großteil der Nutzer mit hoher Wahrscheinlichkeit zu identifizieren. Dies liegt daran, dass Bewegungsprofile von Person zu Person sehr einzigartig sind. Wenn man beispielsweise lediglich die Standorte des Zuhauses einer Person (Hauptaufenthaltsort während der Nacht) und des Arbeitsplatzes (Hauptaufenthaltsort tagsüber) kennt, kann man einen Großteil aller Personen eindeutig identifizieren. Auch andere Möglichkeiten zur De-Anonymisierung gibt es: beispielsweise ist es denkbar, dass man einen Bluetooth-Sensor in die Nähe einer Kamera mit der Fähigkeit zur Gesichtserkennung platziert und dadurch ermöglicht, über Bluetooth die Proximity-ID und damit das personenspezifische Pseudonym einer erkennbaren Person zuzuordnen. Somit würde die betroffene Person vollständig de-anonymisiert.

Aus den oben genannten Gründen sollten Kontaktnachverfolgungs-Apps auf ein dezentrales Kontaktnachverfolgungsmodell aufbauen. In solchen Modellen bekommt das Backend-System keine Informationen über die kurzlebigen Pseudonyme der Nutzer und kann diese daher auch nicht einzelnen identifizierbaren Personen zuordnen. Folglich hat wegen der grundsätzlichen Probleme, die mit dem zentralisierten Modell verbunden sind, die Bundesregierung vor einiger Zeit beschlossen, den von ihr ursprünglich unterstützten Ansatz des PEPP-PT-Konsortiums aufzugeben, und anstatt klar festgelegt, dass die deutsche Coronavirus-Tracing App auf einem dezentralen Ansatz zur Kontaktnachverfolgung aufbauen soll.

Tags: , , , , ,