17. Juni 2020

Corona Warn App: Tech-Jump in die iOS App

Simon Lischka

Wir haben beim UX Review der Corona Warn App die iOS Variante der Anwendung ausgewertet. Im folgenden Artikel erklären wir euch, was von technischer Seite nötig war, um die Anwendung auszuführen.

Dabei geben wir einen Überblick über die Architektur und technische Funktionsweise der Anwendung. Außerdem zeigen wir euch, wie wir die App ausgeführt und erste Ansätze durchgeführt haben, die den Zustand der Anwendung so manipulieren, dass wir sehen konnten, wie die UI Risikokontakte visualisiert.

 

Zur Erinnerung: Warum geht’s bei der App?

 

Die neue Corona Warn App (CWA) übernimmt eine Risikowarnung bei vermutetem Kontakt mit Covid-19-Infizierten, die betroffene Personen zur Selbstisolation oder Durchführung eines Tests ermutigen kann. Außerdem erhält der User (und das meinen wir im weiteren Verlauf immer geschlechtsneutral 😉 ) per App nach vorheriger Registrierung des Covid-19-Tests sein Testergebnis. Er kann so schnell reagieren und Vorsichtsmaßnahmen einleiten und damit andere über die App warnen lassen, die sich in den letzten Tagen über eine bestimmte Zeit in seiner Nähe aufgehalten haben.

Zur Beurteilung der Nutzbarkeit der App haben wir einen interaktiven Prototypen in Axure gebaut und den Simulator über Xcode genutzt. Anschließend haben wir die App auf einem simulierten iPhone 8 plus untersucht. Doch hier wollen wir nun eintauchen in den technischen Tiefen der App. (Das UX Review gibt es hier zu lesen.)

 

GitHub-Stalking des Entwicklungsstands

 

Da das Projekt offen bei GitHub erhältlich ist, konnten wir auf den Quellcode zugreifen. Unser erster Schritt bestand darin, die Anwendung zu ziehen und zu klonen. Anschließend konnten wir den Quellcode in Xcode betrachten, manipulieren und mit dem Simulator sogar ausführen und die iOS-App zum Laufen bringen.

Mit gewisser Spannung haben wir in den letzten Tagen die Updates der Entwickler verfolgt. Wir stellten beim Anschauen der Versionshistorie fest, dass in der Nacht zu Freitag ein Major Version Bump auf 1.0.0 stattgefunden hat. Änderungen in der Major Version deuten in der Regel signifikante Änderungen an. In diesem Fall war es für uns der Hinweis, dass ein Release kurz bevorsteht.

Auch bei der Android-Variante ist zeitgleich eine ähnliche Commit-Message zu sehen. Vermutlich handelte es sich also um eine interne Deadline, um einen weitgehend stabilen Stand zu erreichen. Am Dienstagmorgen ging die App live und war im App-Store verfügbar.

 

Sicherheitsprüfung durch den TÜV

 

Im Rahmen eines Sicherheits-Reviews des TÜV waren Lücken aufgetreten. Unter anderem wurde beanstandet, dass es möglich sei, mit Hilfe der TAN Verifizierung falsch-positive Diagnoseergebnisse zu vermerken.

Interessant ist, dass der von den deutschen Entwicklern geschriebene Backend-Teil nicht unter den Prüfauftrag des TÜV fiel. Ebenso war das verwendete Apple/Android Exposure Notification Framework, was die Ermittlung und lokale Speicherung von Risikokontakten via Bluetooth LE durchführt, nicht Teil des Prüfauftrags. Es wurden also zentrale Komponenten des Systems nicht geprüft.

Am 14.06.2020 gab der TÜV bekannt, dass die App sicher und stabil sei. Zusätzliche Prüfungen an Backend/Exposure Notification Framework wurden jedoch nicht durchgeführt. Über den Stand der TAN-Verifizierung ist nur bekannt, dass Verbesserungen in Arbeit sind.

 

Funktionsweise der Anwendung

Wir geben euch jetzt einen Überblick über die Funktionsweise der App. Für uns war zunächst interessant, zu verstehen, wie die Ermittlung eines Risikokontaktes überhaupt funktioniert. Wir werden euch das deshalb kurz erklären. Danach werden wir mit euch einen Blick auf die Gesamtarchitektur werfen, um zu verstehen, worin die Arbeit der Entwickler von SAP bestand.

Somit können wir auch die iOS Applikation gut einordnen, die wir bei unserem UX-Review lokal ausgeführt und unter die Lupe genommen haben.

 

Abbildung 1: High-Level Architekturüberblick (Quelle)

 

Hilfreich war für uns, dass die Anwendung gut dokumentiert war. Abbildung 1 ist ein High-Level Architekturüberblick aus der Dokumentation des offiziellen Github-Repos der Corona-Warn-App. Grün markiert sind hier existierende Komponenten, die nicht von SAP/Telekom entwickelt wurden.

 

Risiko-Ermittlung per Bluetooth

 

Zu den existierenden Komponenten gehört das Exposure Notification Framework (oben Rechts auf Abbildung 1), welches von Apple/Google entwickelt wurde und von der Corona Warn App verwendet wird, um Risikokontakte per Bluetooth LE (Low Energy) zu ermitteln. Man bedient sich hier der sogenannten Beacon-Technologie.

Diese besteht darin, in regelmäßigen Abständen energiesparend per Bluetooth LE Informationen zu senden, die von einem anderen Gerät empfangen werden können. Use cases außerhalb der Corona-App sind zum Beispiel das personalisierte Anzeigen von Werbungen in Geschäften. Hier kann die Nähe eines bestimmten Kunden durch die gesendeten Informationen erkannt werden und das Angebot angepasst werden.

Im Fall der Corona Warn App verwendet man diese Beacon-Technologie, um in regelmäßigen Abständen mit Hilfe von Bluetooth LE einen sogenannten Rolling Proximity Identifier (RPI) zu senden. Dies ist eine temporäre Identifikations-ID, die mit kryptographischen Verfahren erzeugt wird und sich ungefähr alle 15 Minuten ändert. Empfangen werden können diese RPIs von anderen Benutzern der Corona-Warn-App die sich in der Nähe befinden.

Neben dem Senden lauscht jedes Gerät mit der App also parallel auch auf RPIs von anderen Anwendern. Die Anwendung sendet RPIs, die sich regelmäßig ändern und empfängt Identifier von anderen Geräten, die sich auch regelmäßig ändern.

Die eigenen temporären Identifier sowie die anderer Telefone (falls für Infektion relevante Distanz und Kontaktdauer gegeben) werden lokal gespeichert. In diesem Moment findet kein Upload der temporären Identifier zu den Servern statt. Man bildet durch die lokal gespeicherten Identifier einen Kontakt ab, der ein Infektionsrisiko darstellen könnte, falls einer der Beteiligten krank wäre.

Durch die regelmäßig wechselnden RPI verspricht man sich, Anonymität zu gewährleisten und die Zuordnung zu einer Person zu verhindern.

 

Abbildung 2: Potentielle Risikokontakte - Speichern von RPIs mit dem Exposure Notification Framework

 

Abbildung 2 stellt die mit dem Exposure Notification Framework durchgeführten Abläufe dar. Ihr seht hier, wie zwei User die Applikation ausführen (App Instance 1 und 2) und in Risikokontakt stehen (also für ausreichend lange Zeit auf naher Distanz sind). Sowohl der eigene RPI als auch der RPI von der anderen Person befinden sich am Ende im jeweiligen lokalen Speicher.

 

Abbildung 3: Vereinfachte Darstellung der Risikowarnung.

 

In Abbildung 3 stellen wir stark vereinfacht dar, was passiert, wenn man jemand begegnet ist, der sich als infiziert gemeldet hat. Hier ist nicht nur das Exposure Notification Framework beteiligt, sondern auch die Backend-Implementierung von SAP/Telekom.

Der User, der App Instance 1 ausführt wurde getestet. Nach entsprechender Verifikation fragt er mit der App seine Covid19-Testergebnisse ab. Diese fallen positiv aus. Stimmt er zu, werden sämtliche persistierte RPIs an das Backend gesendet. Dazu gehören seine eigenen RPI sowie die gesammelten RPIs anderer User in Risiko-Reichweite. Diese werden dort aggregiert gespeichert (linke Seite und Mitte der Darstellung).

Alle 24 Stunden prüft jede installierte Corona Warn App nun, ob ein Match der aggregierten Schlüssel auf dem Backend mit den lokal gesammelten Schlüsseln herrscht. Diese Prüfung erfolgt über APIs des Exposure Notification Framework und liefert einen Risk Score. Dieser wird von der Corona Warn App lokal gewichtet und interpretiert. Der Benutzer erhält dann eine Warnung auf dem Telefon und kann entsprechend reagieren (Beispielsweise: Zuhause bleiben, auch testen lassen).

 

Backend und iOS App

 

Wir haben uns jetzt ausführlich mit der Risikoermittlung, die auf dem Mobiltelefon passiert, beschäftigt. Hierbei stand das Exposure Notification Framework im Vordergrund, welches nicht von SAP/Telekom entwickelt wurde, aber für das Verständnis, wie die Risikoermittlung genau funktioniert, sehr wichtig ist.

In dem Architekturüberblick auf Abbildung 1 seht ihr in der linken Hälfte die Backend-Services, die eine Anbindung an das Laborinformationssystem und die Gesundheitsbehörde realisieren und in blau markiert sind. Hier wird unter anderem die sichere Übertragung der Testergebnisse an den User (Verification Server) und die Speicherung der zuvor erwähnten RPIs vorgenommen (Corona Warn App Service).

Eine genaue Behandlung des Backends würde den Umfang des Artikels sprengen - schließlich interessieren wir uns für die UX Analyse der iOS Anwendung. Positiv anzumerken sei jedoch, dass diese sensiblen Komponenten Open Source sind und von jedem eingesehen werden können. Der TÜV hat zwar noch keine Sicherheitsprüfung vom Backend durchgeführt, eine Einsicht ist aber erstmal prinzipiell möglich. Das ist gut für ein System, welches auf sensiblen Gesundheitsdaten operiert.

 

Ausführen via Xcode

Zurück zum graphischen Teil: Zum Testen der User Experience haben wir die Applikation in Xcode geladen und ausgeführt. Es reichte hierzu aus, sich mit der IDE in den Folder src/xcode zu navigieren und in diesem Pfad das Projekt zu öffnen. Nach Druck auf den Play Button von Xcode wurde der Build problemlos durchgeführt und wir konnten im iPhone-Simulator mit der Benutzeroberfläche interagieren. Remember: Wir haben das am Freitag, den 12.06.2020, gemacht, als die App noch nicht released war.

 

 

Manipulation der Zustände

Unser UX-Experte Ingo kam - kurz nachdem wir die App erfolgreich gestartet haben - auf mich zu und wollte mal schnell sehen, wie die UI sich so verhält wenn man einen Risikokontakt hatte.

Ich habe erstmal nach einer Super-Quick and Dirty Lösung gesucht und habe die Klasse RiskCalculation.swift, die für die Risikoermittlung notwendig ist, manipuliert und ein RiskLevel.increased Wert zurückgegeben.

Das war ziemlich schnell gemacht:

Das Ergebnis:

Man sieht schon, dass wir zwar den Zustand der Applikation modifiziert haben, aber gewisse Details (etwa: "Bisher keine Risiko-Begegnung") noch nicht ganz hinhauen. Zumindest ging es schnell und hat Spaß gemacht - im Ausblick stell ich nochmal kurz dar, wie ich hier weiter vorgehen würde.

 

Fazit

 

Die Anwendung ist gut dokumentiert und fällt auf den ersten Blick nicht negativ auf. Das Projekt ist gut zugänglich und bietet Spielraum, sich noch mit weiteren Aspekten der technologischen Lösung zu beschäftigen. Der erste “Smell” des Codes ist gut.

Der kritischer Aspekt der Sicherheit erfordert bestimmt noch weiterer Prüfung durch Expertenteams. Der OpenSource-Code spielt hier eine wichtige Rolle: Keine Security durch Obscurity ist schon einmal eine gute Richtung.

Aus dem kurzen Kontakt mit der App haben sich für mich noch weitere Playgrounds ergeben:

  • Zustand der App durch Mocks noch tiefgehender faken: Ein normales Vorgehen um die UI Ansichten zu faken wäre es jetzt, einzelne Komponenten - beispielsweise das Exposure Notification Framework oder die Backend-Services - durch Mocks zu ersetzen. So wäre es möglich, noch detailliertere Zustandsmanipulationen vorzunehmen. Etwa auch: Das Vergehen von Zeit nach einem Risikokontakt, etc. Spannend wäre hier, komplette Use Cases durchzuspielen.
  • Deep Dive into the backend: Was im Hintergrund passiert, also das Abfragen von Tests über die API des Gesundheitssystems, TAN Verifikation, Speichern der Identifier etc., sieht spannend aus. Hier wäre es interessant, in die detaillierte Funktionsweise einzusteigen und auch mit dem Code rumzuspielen. Genügend Diagramme sind da. Ein paar Use-Cases mit Blick auf das Gesamtsystem durchzuspielen, könnte sehr spannend sein.
  • Infrastruktur: Die Backend-Services laufen auf der Telekom-Cloud. Hier wäre es interessant, was auf Infrastruktur-Ebene zu sehen ist. Bisher konnten wir durch das Architekturdiagramm sehen, dass ein paar Microservices eingesetzt werden. Mich würde interessieren, wie detailliert mit Themen, wie Skalierung u.a., umgegangen wird. 

 

Hat jemand von euch schonmal das Projekt ausgecheckt und rumgemockt? Wie würdet ihr rangehen?

Welche Aspekte interessieren euch an dem Projekt, liebe Devs? Let us know.

 


+++ Hier geht es zu unserem UX Review! Lest gleich weiter! +++


Ihr möchtet eine UX-Bewertung eurer Anwendungen oder braucht anderweitig Unterstützung für das Thema UX? Hier erfahrt ihr mehr!


 

Simon Lischka
Scala | Software Craftsmanship | Teams

Rufen Sie uns an: 030 – 555 74 70 0

Made with 
in Berlin. 
© leanovate 2020
hearttagtwitterfacebooklinkedinxing