Hinweis: Dieser Artikel ist älter als 3 Jahre
Inhalte, Quelltexte oder Links können zwischenzeitlich überholt sein.

Teil II - in the meantime

Wurde ich während des Schreibens vom ersten Teil von einer neuen Dokumentation und dem ersten Quellcode überrascht, so war das beim zweiten Teil die neue Projektwebsite und die Fertigstellung der Apple/Google API mit dem Namen “Exposure Notification”. Diese wird bereits aktiv via iOS 13.5 Update bzw. Android-Playstore verteilt¹.

Wer die Links zu den Dokumentationen haben möchte:

• Android-Dokumentation
• iOS-Dokumentation

Unterstützt werden alle Android ab Version 6 mit BTLE Hardware. Bei Apple ist BTLE kein Faktor und seit dem iPhone4 in allen Geräten enthalten. Der 2 GB RAM-Bedarf des iOS 13 Betriebssystems ist da der limitierende Faktor. Über diesen verfügen erst die Geräte ab dem iPhone 6S. Vereinfacht gesagt werden alle Geräte unterstützt, die nicht alter als 4-5 Jahre sind².

Werfen wir einen Blick in die Statistik:

• ca. 75% aller Androiden wird unterstützt³.
• Es existieren 58 Mio Smartphones in Deutschland⁴.
• Das Verhältnis Android zu iOS Geräten liegt bei ca. 4:1⁵.

Über’s Knie gerechnet ergibt das einen “best-case” von 43 Mio Geräten (34 Mio Android, 9 Mio iOS). Das ist knapp die Hälfte der Gesamtbevölkerung von 83 Mio. Auf der anderen Seite haben wir den “worst-case” mit 0,5 Mio für die RKI Datenspende App⁶.

Die goldene Mitte läge demnach bei 22 Mio. Persönlich tendiere ich eher auf 10-15 Mio. Jemand möge mich bitte im Dezember an diese Zahlen erinnern.

Zur neuen Website ist zu sagen, dass diese zwar um Datenschutz bemüht ist. Im Detail fehlten dann doch wichtige Security- und Privacy-Features. Als schwerwiegend erachte ich TLS 1.0, die fehlende CSP und die offenkundig nicht definierte Abstimmung zwischen den Teams⁷.

Eine 404 “Seite nicht gefunden” ist noch schön gestaltet. Bis zu einem 405 “Methode nicht erlaubt” (oder anderen HTTP Fehlercodes) reichte die Kreativität der goldenen Hirsche offensichtlich nicht mehr⁸.

Bevor es weitergeht möchte ich aber eines positiv hervorheben: Wie die Jungs von SAP auf Fragen eingehen und Einblick auch in laufende interne Diskussion geben ist vorbildlich und professionell. Dass ich von “Jungs” rede ist nicht diskriminierend. Im sechs-köpfigen Entwicklungs- und Dokumentationsteam gibt es zum Zeitpunkt des Schreibens dieses Blogs keine Frau⁹.

Fortsetzung: Aufbau der Gesamtlösung

Das Server-Backend, die Gegenstelle der mobilen Apps basiert auf einer Open Shift Container-Plattform bestehend aus skalierbaren Docker-Containern. Die App wird dabei mit drei Gegenstellen kommunizieren¹⁰:

• Verification Server
• CWA-Server
• Portalserver

Eine genaue Abgrenzung zwischen CWA-Server und Portalserver wird mir noch nicht ersichtlich. Grob betrachtet soll der Portalserver den Transfer der Daten übernehmen, während der CWA-Server eher die Steuerzentrale in der Kommunikation und Freigabe von Testresultate und Diagnosedaten ist.

Die Kommunikation unter den Servern erfolgt über TLS gesicherte JSON-Webservices¹¹. Die Webservices sind in JAVA/Maven programmiert mit einem ganzen Zoo an Toolchain wie JaCoCo oder sonarcloud, das einem im sonarcloud Dashboard eine bessere Code-Analyse verschafft.

Was die Hochverfügbarkeit betrifft liegt die Projekt-Website hinter mehreren Endpoints. Ich konnte die IPs 87.148.208.250, 87.140.209.25-27 identifizieren. Gut möglich, dass hier auch die späteren Container für die Webservices laufen.

Wirklich viel an Code gibt es nicht zu sehen, da bislang nur das Grundgerüst steht und die Arbeit erst nach Veröffentlichung des Apple/Google Frameworks beginnen kann. Um ein Code-Beispiel zu zeigen: Die Überprüfung von TANs und teleTANs sieht noch so aus:

  private boolean validateTan(String tan) {
    // FIXME Add implementation
    return true;
  }

  private boolean validateTeleTan(String teleTan) {
    // FIXME Add implementation
    return true;
  }

Auf der Datenbankseite existieren so weit ersichtlich zwei Systeme:

• zenko.io Object Storage
• Postgres

Der verwendete Postgres Server liegt zwar in einer aktiv betreuten Version 9.6 vor¹² ist aber dahingehend als unglücklich zu betrachten da diese Version nächstes Jahr End-Of-Life sein wird und keinen Support erhält. Warum auf eine ältere Version zurück gegriffen wird ist schwer zu sagen. Es ist vorstellbar, dass es in der Toolchain etwas gibt, was das vorgibt. Die aktuelle Postgres-Version ist 12.3¹³.

Hinsichtlich dem Object-Storage ist zu betonen, dass in den Dokumenten häufig die Rede von “S3” ist. Das bedeutet nicht, dass dieser bei Amazon liegt. Zenko ist eine Open Source Plattform, die eben genau einen Vendor Lock-In verhindern soll. Gehostet wird alles bei der Telekom, das wurde mir auf Nachfrage extra bestätigt¹⁴.

Was mir die Tage aber in den Kopf kam, war der Skandal um die bei Amazon liegenden Videos der Bundespolizei. Für nur 2.000 Body-Cams mit einem Bruchteil an Datenvolumen einer Corona-App, gäbe es angeblich keine heimische Alternative¹⁵.

Eine Schnittstelle besteht zum zentralen Laborsystem der Testeinrichtungen sowie zu den Mitarbeitern der Gesundheitsämter, wo teleTANs für den manuellen Datenabgleich erstellt werden. In welcher Form ist noch unklar.

Der Schlüsselmeister in der Matrix

Zentrales Element in der Infrastruktur bildet der Verification Server. Über diesen erfolgen sämtliche Authentifizierung und vor allem der Akt der De-Anonymisierung eines Geräts bei der Übermittlung von Testergebnissen, sofern dieses nicht zuvor mit Abgleich zu andern Datentöpfen erfolgt ist, dazu später mehr. Der Ablauf - soweit einsehbar und verstanden - sieht wie folgt aus:

Soweit verstanden, erstellt die App einen gerätebezogene GUID-Hash. Ein Hinweis in der Cross-Border-Interoperability macht deutlich, dass man sich hier wohl auf die API der Hersteller verlässt¹⁶.

Die GUID wird als Hash an den Verification Server gesendet und daraus ein Registration Token abgeleitet. Anschliessend wird dieser wieder zurück an den Clienten gesendet. Am Server verbleiben nur die Hashes. Ob noch weitere Bestandteile oder Salts zum Einsatz kommen bleibt wie das übrige kryptografischen Verfahren noch unklar.

Was fest steht ist, dass es in Folge zu einem Ping-Pong zwischen Smartphone mit TANs, teleTANs und der Übermittlung der Diagnosedaten kommen soll aufgrund der Anforderung, neben dem direkten Weg auch einen manuellen, händischen anzubieten. Die Kommunikation erfasst auch die Zusendung der GUID Hashes an die Systeme der Labore, die damit die Testergebnisse verschlüsseln¹⁷.

Die Komplexität wird zusätzlich erhöht indem JSON-Aufrufe von /result und /tan zur Übermittlung der Testergebnisse mit Zufallsdaten, sogenannten “Dummy Submissions” verschleiert werden sollen¹⁸.

Komplexität

Gleich auf mehreren Wegen soll es einem Benutzer ermöglicht werden, Testergebnisse mit der App zu erhalten bzw. Diagnosedaten zu übermitteln. Alles zusammengefasst in nachfolgenden User-Stories¹⁹

As a user of the app, I want to be able to scan a QR code provided by my doctor or test center, so that I can receive my test result in the Corona-Warn-App.

As a user of the app, I want to be able to use a manual process (in addition to the digital process), for example, through a call center and without a QR code, to send the pseudonymized IDs, under which I was visible to other app users in recent days, to the Warn server so the people I have been in contact with can be warned by their apps.

As an app user, I want to be able to enter a TAN in the app, to use the TAN I have been given to assign my test result to my instance of the app.

Neben einem digitalen Weg mit QR-Code soll es einen zweiten, manuellen Weg mit einer teleTAN geben. Diese teleTAN soll “human readable” sein, was auf eine Zahlen- oder Buchstabenkombination mit geringer Entropie hindeutet²⁰.

Im “Scoping Document” unter dem Punkt User-Story E06.04 ist von Callcentern die Rede, die eine teleTAN aushändigen sollten²¹.

Im “Solution Architecture” Dokument hingegen ist die Rede von “health authority”, also von Mitarbeitern eines Gesundheitsamtes²².

Wissen die von Ihrem Glück? Noch ist nichts von einer Authorisierung oder Authentifizierung von Mitarbeiter zu lesen. Was jedoch bekannt ist, daß diese als Stakeholder bislang nicht einbezigen waren und daß mancherorts Gesundheitsämter an Ihrer Belastungsgrenze arbeiten und unterbesetzt sind²³.

Was, wenn am Ende doch ein namenloser Call-Center-Agent über die Verteilung von teleTAN bestimmt? Technisch kann nicht verhindert werden, dass jemand die App auf mehreren Geräten nutzt. Es kann auch nicht ausgeschlossen werden, dass ein Berechtigter eine teleTAN anfordert und an einen anderen weitergibt²⁴.

Komfortfunktionen vs. Corona

Am meisten erstaunen die vielen “Komfortfunktionen” im “Scoping Document”. Das sind beispielsweise allgemeine Informationen, was bei einer Infektion zu tun sei (User-Story E05.02). Dabei sollen die Inhalte dynamisch anpassbar und vom RKI zentral in einem Content-Management-System (User-Story E10.01) gepflegt werden²⁵.

Wie ist ein Verhalten zu interpretieren, wo kurz nach einem Datenabgleich plötzlich angefangen wird Erklärvideos oder Informationstexte im Internet zu öffnen? Auch wenn niemand sieht, was abgerufen wird, ermöglichen Metadaten wie z.B. Dauer, Datei- und Verzeichnisnamen gewisse Rückschlüsse.

Ich persönlich halte es für unverständlich, warum in Anbetracht der kurzen und holprigen Entwicklungszeit die Komplexität mit solchen Anforderungen erhöht wird. Reichen die bestehenden Informationsangebote nicht aus? Müssen diese diese wirklich auch noch in die App integriert werden? Jedes zusätzlichen Feature - zumal auch noch remote durch ein Content Management System verwaltet - reduziert die Anonymität und die Dezentralität²⁶.