BanDemic – eine App gegen die Ausbreitung des Virus

#WirVsVirus

Corona App

Beitrag von |

Wie können wir als Gesellschaft die Herausforderungen, die im Zuge der Corona Krise entstehen, mit neuen Lösungen gemeinsam meistern?*

Vom 20. bis 22. März nahm ich am #WirvsVirus-Hackathon teil – eine digitale Gemeinschaftsaktion, initiiert durch die Bundesregierung, in der Lösungen für Zeiten der Corona-Pandemie entwickelt wurden.

Ein Zugeständnis, welches zeigt, dass Hoffnung in die Digitalisierung gelegt wird, Krisen zu überstehen.

Fast 23.000 Menschen nahmen teil. 3.000 Herausforderungen, die es zu lösen galt, ergaben am Ende rund 1.500 Projekte. Die Herausforderungen (sog. Challenges) stellten die Bundesministerien, Behörden wie die Bundespolizei, Unternehmen sowie Kliniken oder wurden durch die Bevölkerung eingereicht.

In unserem Team haben wir uns der Herausforderung angenommen, ein Mittel zu finden, infizierte Personen schnell ausfindig machen zu können, sowie herauszufinden, mit welchen Personen die infizierte Person in Kontakt stand.  Denn, je schneller infizierte Personen isoliert werden können, desto stärker und schneller flacht die Kurve für die Zahl der weiteren Ansteckungen ab.

Das Problem: Wie findet man heraus, mit wem eine Person Kontakt hatte? Und wie geschieht das, ohne persönliche Rechte zu verletzen oder gar eine flächendeckende Überwachung? 

Unsere Idee: BanDemic - eine App um die Anzahl der Neuinfektionen zu reduzieren

BanDemic gibt, unter Einhaltung geltender Datenschutzbestimmungen, Rückschlüsse über den Weg der Infektion. Dadurch können infizierte Personen schneller ausfindig gemacht werden.

Bei der Erarbeitung unserer Lösung war uns die Einhaltung folgender drei Faktoren wichtig:

 

  • Anonymität: Die Identität erkrankter Personen ist zu schützen.
  • Datenschutz: Die Kontakte einer Person sollten nicht veröffentlicht werden.
  • Sicherheit: Das System muss gegen Zugriffe von Dritten gesichert sein.

Unser Vorgehen: Umsetzung im STRICT-Protokoll

Unsere gewählte Technologie: Bluetooth Low Energy (BLE). Damit kann ein Smartphone ohne hohen Stromverbrauch einen Identifikator versenden, womit der Kontakt von benachbarten Geräten registriert werden kann. Durch die Messung der empfangenen Signalstärke wird zusätzlich eine ungefähre Entfernung ermittelt, um das Infektionsrisiko besser abzuschätzen. Dies funktioniert ohne jegliche GPS-Lokalisierungsdaten.

Die grundsätzliche Idee dahinter: Wird jemand positiv auf COVID-19 getestet, wird dessen Identifikator öffentlich gemacht und jede weitere Person kann für sich prüfen, ob sie zu der infizierten Person Kontakt hatte, indem alle beobachteten Identifikatoren dagegen geprüft werden.

Die Kontaktpersonen können sich anschließend auf COVID-19 testen lassen und eigene Kontaktpersonen informieren.

BLE-Infografik

Diese einfache Methode bietet jedoch aus zwei Gründen wenig Schutz:

  • Eine langlebige UUID könnte es ermöglichen eine Person zu tracken.
  • Da die UUID per Bluetooth öffentlich versendet wird, kann theoretisch jeder UUIDs abhören und behaupten es gäbe eine Infektion.

Das erste Problem lässt sich durch regelmäßiges Wechseln der UUID lösen.

Dem zweiten Problem kann durch eine ärztliche Bestätigung entgegengewirkt werden. Nur die Information der Kontaktpersonen zweiten Grades erfolgt ohne Arzt und muss technisch abgesichert werden. Dafür wurde das STRICT-Protokol erfunden (simply track infection).

Die zufällig gewählte UUID wird daher nicht mehr öffentlich gemacht, sondern mit Hilfe einer Einweg-Hashfunktion (SHA256) in eine neue “BLE-ID” (Bluetooth Low Energy ID) transformiert. Diese wird den Kontaktpersonen per Bluetooth bekannt gemacht.

Diese BLE-ID wird anschließend durch die Hashfunktion transformiert und zu einer neuen Infections-ID.

Bei einem Infektionsfall wird die UUID dem Server bekannt gegeben. Dieser berechnet im Anschluss die Infection-ID und gibt diese bekannt. Die beiden anderen Identifikatoren vom Infektionsfall (UUID und BLE-ID) werden nicht veröffentlicht.

Infografik

Eine Kontaktperson (Orange im Bild) hat nun die Möglichkeit aus der empfangenen BLE-ID des Infektionsfalles (Rot im Bild) die Infection-ID mit denen aus seiner eigenen Datenbank abzugleichen.

Um ihre eigenen Kontakte zu warnen, schickt sie dem Server:

 

  • Die BLE-ID des bestätigten Falles (Rot). Dadurch beweist sie, dass sie tatsächlich Kontakt hatte, da diese nicht anhand der öffentlich bekannten Infection-ID berechnet werden kann.
  • Ihre eigene UUID. Diese kann durch Personen, die ihre BLE-ID über Bluetooth beobachtet haben, nicht berechnet werden und beweist somit deren Identität.
BLE-Infografik

Der Server veröffentlicht dann die Infection-ID der orangenen Kontaktperson.

Eine verbleibende Schwachstelle hinsichtlich der Einhaltung des Datenschutzes ist, dass der zentrale Server ebenfalls von den Kontakten der infizierten Person erfährt. Der Server könnte folglich deren IP-Adressen speichern und somit Kontaktprofile erstellen.

Der Hackathon hat viele neue Ideen hervorgebracht.

Einige dieser Gruppen haben sich nun zusammengeschlossen, um weiterhin an einer optimalen Lösung der Projekte zu arbeiten.

Eine Übersicht der 1.500 Projekte findet sich hier.

Christophe Schmaltz

Über den Autor

Christophe Schmaltz
Senior Software Developer

Christophe Schmaltz ist seit 3 Jahren als Senior Backend Developer bei UDG United Digital Group angestellt. Erste Hackathon-Erfahrung sammelte er 2019 beim UDG-internen Hackathon. Dabei befasste er sich intensiv mit Bluetooth- und Low-Energy-Technologien.