Thread by @mame82

Meine Tweets zu der #LucaApp wurden in den vergangenen Tagen gehäuft mit emotional aufgeheizten Aussagen gemischt, in Teilen auch mit technischen Schwachsinn den einige so on die Heide hauen.

Hier ein paar Klarstellungen:

Es ist mir ziemlich egal von wem digitale Covid ...

Tracing Lösungen beworben werden (schließt auch @lesmoureal ein, dessen Umgang mit kritischen Äußerungen ich dennoch nicht mag).

Luca verfolgt ein anderes Ziel als CWA und nutzt dafür einen zentralen Ansatz. Auch das mag ich nicht, weil es zusätzliche Risiken birgt.

Das SiKo von Luca ist nicht schlecht, wenn man es auf die definierten "Objectives" beschränkt betrachtet (man hat sich hier Mühe gegeben), dennoch reicht das nicht.

Einige begründende Beispiele:

Das Luca backend ist als eine Art Daten Treuhänder zu sehen. Es wurden auch ...

... einige Maßnahmen platziert, die verhindern, dass dieser Treuhänder keine unberechtigte Einsicht in sensitive Daten erhalten kann (klare Kontaktdaten oder Tracing Daten).

Dennoch geht das Konzept an keiner Stelle von einer vollständigen Kompromittierung des Backends aus.

Ein solches Szenario ist durchaus denkbar, nicht weil ich den Entwicklern - wie andere - Dilettantismus unterstelle, sondern weil vieles im Argen liegt.

Der Backend Code wurde scheinbar nie in einem whitebox Ansatz auf Schwachstellen geprüft (insbesondere RCEs), aber auch...

... etwaige Plattform- oder Infrastrukturschwachstellen wären hier relevant. Dies gilt insbesondere, da die Datenlage hier durchaus als so brisant angesehen werden kann, das auch sophisticated Threat Actors interesse haben dürften.

Geht man nun von einer Backend Kompromittierung aus, wäre der Impact sehr beschränkt da ja mit E2EE geworben wird. Die getroffenen Maßnahmen spiegeln das aber nicht wieder.

So liegen zB die Kontaktdaten aller Nutzer auf dem Luca Server, wobei diese lediglich mit ...

... **symmetrisch** mit AES128 im Countermode verschlüsselt sind.

Ich möchte hier ganz klar sagen, dass das nicht per se die Tür für Bruteforce Angriffe für offengelegte "encrypted guest data" Datensätze öffnet, aber man muss auch die Ressourcen beachten, die den in Frage...

... kommenden Angreifern zur Verfügung stehen.

Auch ist nichts über die App-seitige AES Implementierung bekannt (potentielle Schwachstellen), da diese nicht im veröffentlichten Quellcode beinhaltet ist.

Abseits von Bruteforce angriffen, müsste ein threat actor aktiv mit den Nutzern (guests) und Veranstaltern (venue owner) kommunizieren, um an relevante symmetrische Schlüssel zu kommen. Kann er das: Kommt darauf an, wir wissen nicht wie lange ein Angriff auf das Backend ..

... unerkannt bleibt.

Bleibt er unerkannt, ergeben sich zahlreiche Möglichkeiten, die sich nur schwer in Kurzform bei Twitter umreißen lassen, denn hier kommt (richtiger Weise) asymmetrische Verschlüsselung ins Spiel.

Was allerdings klar ist, den öffentlichen Verschlüsselungs-Schlüsseln der Gesundheitsämter - oder besser den daily encryption keys, welche die Gesundheitsämter täglich teilen - kommt eine Entscheidende Rolle zu, da sie von allen beteiligten genutzt werden, um Daten nur für ...

... die Gesundheitsämter zu verschlüsseln (Anmerkung: es gibt an vielen Stellen eine zweite Verschlüsselungs-schicht mit Keys der venues/guests).

Entscheidend hier ist das die öffentlichen Schlüssel der Gesundheitsämter (HDEKP.public) auch von den Gesundheitsämtern stammen ...

... Da die Schlüssel aber vom (kompromittierten) Luca Server verteilt werden, kann ein Angreifer diese einfach durch Schlüssel ersetzen, für die der private Teil bekannt ist (MitM).

Das Problem hier: Fehlende Authentisierung der Kommunikationspartner.

Auch das Authentisierungsproblem wird für die Gesundheitsämter aufgegriffen, aber nicht wie zu erwarten, durch einen Out-Of-Bounds channel oder ähnliches, sondern durch gesonderte signing keys (HDSKP).

Neues Problem: Auch das HDSKP liegt in Hoheit des Luca Server und kann ...

... von einem Angreifer ersetzt werden.

Man macht sich zwar hier schon Gedanken, eine unabhängige Zertifizierungsinstanz zu nutzen (Bundesdruckerei), es wird aber eben nicht getan, während der Service aber offensichtlich schon von Millionen Menschen genutzt wird.

Ich möchte den Thread nicht überdehnen, aber für mich ist Fakt:

Man vertraut hier einem System, ohne alle Aspekte zu kennen.

Das System muss transparent sein und unabhängig unter InformationsSicherheitsAspekten auditiert werden (nicht nur Datenschutz Audit, denn ...

... der geht davon aus, dass theoretische Schutzmaßnahmen greifen).

Ich stimme der Aussage zu, dass Nutzer hier "Betatester" sind (Behörden und Veranstalter auch).

Ich hinterfrage an dieser Stelle nicht, die Notwendikeit einer nicht-anonymen Kontaktverfolgung, da ich kein ...

... Jurist bin, würde eine solche Möglichkeit aber immer vorziehen.

Ich teile nicht die Meinung, dass ein solches Projekt in private Hand gehört und "... der Staat nicht alles regeln muss ...". Man hat hier (wie so oft gepennt) und jetzt bekommt die Geschichte eine unangenehme..

... Eigendynamik.

Müsste man auf ein System wie Luca nutzen, sollte man nicht von SaaS reden, sondern bestehende Lösungen anpassen/erweitern und genauso transparent etablieren wie die bisherigen.

Hinweis: Ich bitte diese Tweets nicht in Flame wars gegen @lesmoureal oder sonstige Luca-Macher einzubauen oder falsch zu zitieren.

Nachtrag:

Weiteres Bsp für "implicit backend trust" aus Luca SiKo

https://twitter.com/mame82/status/1379059699346239489

s/HDEKP\.public/DailyKP.public/g

Anmerkung dazu:

Das relevante Schlüsselpaar ist das "daily key pair" (DKP).

Der private Anteil DKP wird für jedes HD mit seinem HDEKP "um-schlüsselt" (täglich nach Rotation, durch eines der HDs die partizipieren... first-come-first-serve)