Über Kontaktlisten und Luca App

This blog post is about an ongoing discussion in Germany regarding the use of a specific commercial app to replace contact lists in restaurants that were required when they were open in summer to trace Corona contacts. So i’ll stick to German for it.

Ich bin wahrscheinlich etwas spät dran mit diesem Beitrag, die Diskussion zur Luca App ist “dank” der steigenden Infektionszahlen in Deutschland schon wieder aus dem Fokus der Öffentlichkeit, da sie erwartbar in den nächsten Wochen nicht notwendig wird.

Dennoch möchte ich hier mal auch ein Paar Gedanken aufschreiben, wo ich das Gefühl habe, dass Sie in der Debatte bisher zu kurz kamen.

Kontaktlisten

Sinn der Luca App ist es die Kontaktlisten in Restaurants, Cafes, etc, abzulösen, die im letzten Sommer von den Betreibern geführt werden mussten um im Falle einer Infektion dem örtlichen Gesundheitsamt eine Liste aller Gäste zum fraglichen Zeitpunkt liefern zu können.

Bevor es Sinn macht sich die Luca App genauer anzusehen, sollte man sich die Frage nach der Sinnhaftigkeit dieser Kontaktlisten stellen und ob es nicht eine Methode gäbe, die deutlich weniger Daten erfasst aber zum gleichen Resultat führen würde. Warum? Dazu möchte ich eine kleine Geschichte aus eigener Erfahrung erzählen:

Als Student war ich im letzten Sommer/Herbst regelmäßig mittags in der Mensa meiner Universität essen. Die Mensa hat ein mMn. sehr gut ausgearbeitet Hygienekonzept: Es gilt Masken- und Abstandspflicht bis man mit seinem Essen Platz genommen hat, alle Sitzplätze sind mindestens 2 Meter (eher mehr) von einander entfernt, nach jedem Gast wird der Stuhl und Tisch desinfiziert, die Öffnungszeiten sind in beide Richtungen verlängert um die Besucherzahl besser über den Mittag verteilen zu können (obwohl sowieso deutlich weniger Besucher anwesend, da viele Angestellte und Studenten von zu Hause aus arbeiten). Auch die Mensa hat die Angabe von Gastdaten verlangt: jeder Gast bekommt ein eigenes Formular in Postkarten-Größe und gibt dieses ab wenn er sein Essen erhält.

Eines Tages erhielt ich eine Meldung in der Corona-Warn-App über zwei Kontakte mit niedrigem Risiko. Da ich mit microG Zugang auf die Details der Kontakte habe, konnte ich sehen, dass beide zur Mittagszeit waren – zu der Zeit als ich in der Mensa saß. Da beide Kontakte am selben Tag gemeldet wurden, ist die Wahrscheinlichkeit hoch, dass sie von der selben Person ausgehen, die ebenfalls regelmäßig Gast der Mensa war. Der Fall ist also relativ einfach nachzuvollziehen.

Was aber eigentlich interessant ist: weder das örtliche Gesundheitsamt, noch die Universität haben mich über diesen Kontakt informiert (die Universität benachrichtigt auch unabhängig vom Gesundheitsamt ihre Mitarbeiten und Studenten soweit möglich). Hat die Person etwa vergessen, das Gesundheitsamt zu informieren, dass sie regelmäßig (oder zumindest zwei mal) mittags in der Mensa essen war? Eher unwahrscheinlich – deutlich wahrscheinlicher ist, dass die Verantwortlichen sich gedacht haben, dass sie jetzt wegen einem Fall nicht die halbe Universität in Quarantäne schicken wollen – insbesondere da in der Mensa ja eben wie beschrieben ein gutes Hygienekonzept vorliegt.

An diesem Beispiel möchte ich deutlich machen: Manchmal sind die Kontaktlisten einfach völlig überflüssig. Eine sinnvolle Nutzung erscheint mir in diesem Beispiel jedenfalls nicht möglich oder zumindest nicht gewollt und damit die Datenerfassung eben auch nicht zweckdienlich – was ja eigentlich durch die DSGVO gefordert wäre.

Wenn man sich jedoch dazu entscheidet, überhaupt “Events” wie Restaurantbesuche erfassen zu wollen (und nicht ausschließlich auf entfernungsbasierte Warnsysteme wie der CWA zu setzen) sollte die nächste Frage sein, ob dafür tatsächlich Kontaktlisten notwendig sind. Um den Nutzer zu warnen ist die Speicherung privater Daten eigentlich gar nicht notwendig: Das Gesundheitsamt könnte einfach jeden Tag eine Liste mit Events veröffentlichen (Ort und Zeit) die als Risiko einzustufen sind und die Bürger gleichen diese Liste mit Ihrer eigenen Vergangenheit ab. Das kann für höheren Nutzerkomfort auch durch eine App unterstützt werden, die es erlaubt beim Betreten eines Restaurants einen QR-Code zu scannen, sodass das Event direkt auf dem Gerät gespeichert und automatisch mit der Meldung des Gesundheitsamts abgeglichen werden kann. In der CWA ist derzeit eine ähnliche Funktion in Entwicklung – allerdings komplett ohne Gesundheitsamt: Infizierte laden einfach die Liste Ihrer Events selber hoch.

Angenommen wir entscheiden uns dazu, dass die Erfassung von Kontaktdaten bzw. das Erstellen von Kontaktlisten für uns als Gesellschaft notwendig und sinnvoll ist (ich möchte das aber explizit in Frage stellen). Dann folgt als nächste Frage: welche Daten und von wem sind dazu notwendig: Reicht es in einer Gruppe von 5 Freunden aus, die Daten einer Person anzufragen oder müssen wirklich alle 5 unabhängig informiert werden können? Müssen Details wie Vollständiger Name, Wohnanschrift oder Geburtsdatum erfasst werden oder reicht nicht einfach eine e-Mail-Adresse oder Telefonnummer um Menschen zu kontaktieren? Die Antwort auf diese Frage ist eigentlich eine andere Frage: Wollen wir unsere Mitmenschen informieren oder kontrollieren? Denn die Begründung dafür, warum so viele Daten verpflichtend erfasst werden scheint immer zu sein, dass es dem Gesundheitsamt ermöglicht, rechtlich wirksame Quarantäneanorderungen zu verschicken.

So viel erstmal zu dem Thema der Notwendigkeit von Kontaktlisten. Und um dem Vorwegzugreifen: Kontaktlisten (wenn auch nicht unbedingt in der Form wie sie aktuell erstellt werden) erscheinen mir die einfachste Möglichkeit um Mitmenschen zu informieren, die kein Smartphone o.ä. besitzen. Dazu reicht aber dann häufig eben die Angabe einer Telefonnummer. Ich sehe auch keine direkte Notwendigkeit dieses Kontaktlisten-System auch auf Nutzer auszuweiten, die ein Smartphone besitzen, wenn auf diesem Weg sparsamer mit Daten umgegangen werden kann.

Anforderungen an ein digitales Kontaktlisten-System

Sollten wir zu dem Schluss kommen, dass es keinen geeigneten Ersatz zu den Kontaktlisten (ob digital oder analog) gibt, so sollten wir uns wenigstens Gedanken dazu machen, wie ein digitales Kontaktlisten-System idealerweise auszusehen hat:

  • Kein Vendor-Lock-In: Das System sollte nicht so konzipiert werden, dass nur Software eines einzelnen Anbieters genutzt werden kann. Stattdessen sollte auf offene Standards gesetzt werden: VCard, OpenPGP, e-Mail, um nur einige in den Raum zu werfen die hier eventuell nützlich werden könnten.
  • Kein Datenreichtum: Das System sollte so konzipiert werden, dass niemand mehr Daten erhält, als unbedingt notwendig. Konkret bedeutet das: Die Gesundheitsämter erhalten Kontaktdaten nur, wenn ein Infektionsrisiko/-verdacht vorliegt. Der Gastwirt eines Restaurants und eventuelle Betreiber des Systems erhalten lediglich die Information, dass sie involviert sind, nicht die Kontaktdaten der Besucher.
  • Überprüfbarkeit: Der Datenschutz muss für den Endnutzer überprüfbar sein, das heißt, sämtliche Anwendungen die eventuell Zugriff auf die Daten erhalten müssen Open-Source und Reproducible sein. Das schließt auch die exklusive Nutzung von Web-Basierten Systemen zur Eingabe von Nutzerdaten oder zum Abruf dieser beim Gesundheitsamt aus, da Webseiten jederzeit ohne Überprüfbarkeit durch den Betreiber der Server ausgetauscht werden können.

Das derzeit viel-diskutierte System der Luca App erfüllt zwei der drei Anforderungen gar nicht, lediglich der Datenschutz ist gewahrt, sofern versprochene Verbesserungen implementiert werden (aktuell könnte der Betreiber der Luca App relativ einfach eine Menge privater Daten abgreifen, zumindest wenn die veröffentlichte Dokumentation korrekt ist).

Wie geht es richtig?

Ich habe ja bereits ein Paar offene Standards erwähnt, die hier relevant sein könnten. Hier deshalb auf deren Basis eine Skizze wie diese kombiniert werden könnten, um ein System zur Kontaktdaten-Erfassung zu bauen, dass den oben beschriebenen Anforderungen genügt:

  • Jedes Landesgesundheitsministerium und jedes Gesundheitsamt erzeugt einen OpenPGP-Schlüssel. Der öffentliche Teil des Schlüssels wird jeweils veröffentlicht. Die Landesgesundheitsministerien bestätigen durch Signatur die Echtheit der Schlüssel der Gesundheitsämter in Ihrem Zuständigkeitsbereich.
  • Jedes Restaurant das öffnen möchte erzeugt einen OpenPGP-Schlüssel und hinterlegt diesen und eine Kontakt-e-Mail-Adresse beim örtlichen Gesundheitsamt.
  • Der Gast erzeugt in einer App ein VCard mit seinen Kontaktdetails. Die VCard wird anschließend  für den OpenPGP-Schlüssel des lokalen Gesundheitsamts verschlüsselt. Da die App mindestens die 16 Landesgesundheitsministeriumsschlüssel direkt kennt (weil im Quellcode eingebettet), kann die Echtheit des Gesundheitsamtsschlüssels direkt in der App geprüft werden.
  • Die verschlüsselte VCard wird als animierter QR-Code gespeichert – die Datenmenge dürfte für statische QR-Codes zu groß sein. Alternativ kann die verschlüsselte VCard mit einem zusätzlichen Schlüssel verschlüsselt werden und auf einen Server hochgeladen werden. Der QR-Code enthält dann einen Download-Link und diesen zusätzlichen Schlüssel. Dieser QR-Code wäre dann statisch, kann also auch ausgedruckt werden, sodass das System auch ohne Smartphone genutzt werden kann.
  • Beim Betreten eines Restaurants wird der QR-Code gescant. Der Restaurantbetrieber erhält die für das Gesundheitsamt verschlüsselte VCard und hinterlegt diese in einer lokalen Datenbank gemeinsam mit Datum und Uhrzeit des Scans.
  • Der Nutzer scant auf seinem Smartphone einen QR-Code mit den Details des Restaurants. Dies dient ausschließlich als Erinnerungsstütze um das Gesundheitsamt im Falle einer Infektion vollumfänglich informieren zu können. Das ist also vollständig optional, der Nutzer kann etwa auch zu Hause ein analoges Tagebuch führen.
  • Im Falle einer Infektion informiert der Nutzer das Gesundheitsamt über die Restaurants die er besucht hat. Das Gesundheitsamt schickt eine mit OpenPGP verschlüsselte und signierte Anfrage der Datenherausgabe für einen bestimmten Zeitraum per e-Mail an das Restaurant. Der Betreiber antwortet ebenfalls signiert und verschlüsselt mit einem entsprechendem Export der lokalen Datenbank. Das Gesundheitsamt kann dann die entsprechenden Personen warnen bzw. die verschlüsselte Kontakt-VCard and das lokale Gesundheitsamt des Verdachtsfalls weiterleiten, wenn es sich um einen Gast aus einem anderen Gesundheitsamt handelt.

Das ist jetzt wirklich nur eine kurze Skizze für ein sehr einfaches System, dass aber den Anforderungen gerecht wird. Das System hat sogar noch Bonus-Vorteile gegenüber aktuell geläufigen Systemen:

  • Kommunikation zwischen Nutzern und Gesundheitsamt und zwischen den Gesundheitsämtern kann durch den Aufbau einer OpenPGP-Infrastuktur verschlüsselt erfolgen. Diese Infrastruktur ist von der App und dem aktuellen Einsatzzweck unabhängig und kann langfristig eingesetzt werden.
  • Die VCards können deutlich mehr Informationen enthalten, wenn die entsprechende Person das wünscht. So könnte man zum Beispiel mehrere Adressen und Telefonnummern hinterlegen oder Informationen über gesprochene Sprachen oder Einschränkungen des Hör- oder Sehsinns, die für eine geeignete Kontaktaufnahme relevant sein können.
  • Das ganze System kommt praktisch ohne (neue) externe Dienstleister aus. Eine Infrastruktur für e-Mails dürfte in den meisten Gesundheitsämtern und Restaurants bereits vorhanden sein. Die Apps zum Erstellen und Scannen der QR-Codes sind hinreichend trivial um auf einem alten, längst vergessenem Smartphone installiert zu werden und diesem so einen neuen Zweck zu verleihen. Der Einrichtungsaufwand für alle beteiligten Endnutzer dürfte ähnlich sein wie der für die Luca App.

Corona-Warn-App: transparente Kommunikation?

This blog post is about the German Corona-Warn-App and its communication strategy. So i’ll stick to German for it.

Am 16. und 17. Dezember wurden auf dem offiziellen Blog der Corona-Warn-App zwei Blog-Eintrag veröffentlicht. Der erste kündigt die neue Version 1.9 der App an, der zweite erklärt, wie in der neuen Version Begegnungen und Risiko berechnet werden.

Beide Blog posts sind meiner Meinung nach technisch ungenau, irreführend oder schlichtweg falsch. Der zweite Blog-Eintrag wurde auch nur nötig, weil der erste wenig über die tatsächlichen Änderungen aussagt, sodass viele Nutzer am Ende darüber verwirrt waren.

Continue reading

How to verify that apps from play store match their source code

Given the recent release of the “Corona Warn App” by the German RKI (Robert-Koch-Institut) several users complained that it’s not possible to ensure the app from the Play Store is actually the same as the source code that was published, as the App is not built reproducible.

However, there is still some method to have certainty that the app and source code actually do match, and I’m going to describe this method in this blog post. As an example I’ll use the Corona Warn App (de.rki.coronawarnapp) version 1.0.0, but the method can be applied to any other App as well.

Continue reading

European Commission vs post-truth Google

In April, the European Commission issued a statement against Google for the way they promote and distribute their apps on the Android platform. Google answered last week with a public blog post, more like a marketing campaign, including a video, nice animated pictures and updated websites. Of course, as it’s Google responding, there are a lot of points “proving” the European Commission wrong.

Wait… If it is really proving, why make it a public marketing campaign and not just a letter to the European commission? Do you need to convince the public about something, if you can make points that convince the responsible people? Well, maybe the points they made are not that convincing to some people, so let’s check the details of this campaign. Continue reading

microG Signature Spoofing and its Security Implications

To use all the neat features from the microG project, which allows you to use all features of your Android smartphone without those shitty, proprietary battery-consuming Google blobs, your system is required to support signature spoofing. Currently only very few custom ROMs have built-in support for this feature, luckily you can use Xposed or a patching tool to add the feature to the systems that don’t have it.

But: What is all this about? Is signature spoofing a problem when not using microG? Will it influence my security?

Continue reading