Update: Ein kürzerer und prägnanterer Artikel zu diesem Thema wurde bei heise.de als Gastbeitrag veröffentlicht: Alle reden von Clustern – nur die Corona-App nicht.

Seit dem Launch der Corona-Warn-App sind bald 4 Monate vergangen. In dieser Zeit haben wir viel über das Virus gelernt. Dieses Wissen muss nun auch in der App ankommen.

Zur Erinnerung: Die App soll dabei helfen, Risiko-Kontakte zu erfassen. Als Risiko-Kontakt gilt für die App: Abstand weniger als 1,5m; Dauer länger als 15min.

Leider ist es aber bei diesem einen Entscheidungskriterium geblieben. Inzwischen wurde – ohne große Überraschung – eine Reihe von Situationen erforscht, in denen die App nicht zuverlässsig funktioniert.

Messprobleme

Als Paradebeispiel kann hier der öffentliche Nahverkehr gelten: Die “Metallröhre”, in der die Menschen sitzen, führt zu allerhand Reflektionen und Signalstörungen – und schließlich zu keinerlei korrekten Alarmierungen. Update: An der Studie werden methodische Fehler bemängelt, aber auch eine korrekt funktionierende App würde der Bahn-Situation nicht vollkommen gerecht.

Das ist besonders verhängnisvoll, weil die App in genau solchen Situationen, in denen Fremde sich nah kommen und nicht in der Lage sind, sich später zu alarmieren, für zusätzliche Abdeckung sorgen soll.

So hat die Physik dem Bluetooth-Ansatz erwartbare und auch vorher schon bekannte Grenzen gesetzt. In der Gastronomie zum Beispiel gilt unter anderem deshalb die Pflicht zur manuellen Erfassung.

Der Abstand ist nicht das Maß aller Dinge

Doch selbst wenn die Abstandsmessung perfekt wäre, würde sie dem Stand der Wissenschaft nicht gerecht: Zwei gemeinsame Stunden in einem stickigen kleinen Kellerraum mit großzügigem Abstand von drei Metern sind riskanter zu bewerten, als dreißig Minuten an der frischen Luft, bei einem Abstand von 1,50m. Die App kann den Unterschied aber nicht feststellen.

Dieser Effekt wird besonders anschaulich, wenn wir uns eine alltägliche Konferenz-Situation mit 8 Personen in einem Raum vorstellen: Maximal 2 Anwesende werden im Risikobereich von 1,50m Entfernung sein können. Wären wir als Anwesende zufrieden, deshalb keine schnelle Warnung zu erhalten?

Für Contact Tracing in der Gastronomie gibt es bisher keine akzeptable Lösung

Mitglieder des CCC haben in verschiedenen digitalen Contact-Tracing-Lösungen für die Gastronomie Schwachstellen gefunden. Die Systeme wurden oft mit der heißen Nadel gestrickt und setzten auf zentrale Erfassung.

Als sinnvolle Alternative riet ich in dem Zusammenhang zur manuellen Erfassung per Zettel. Daraufhin meldete sich eine Vielzahl an Gastronominnen bei mir, die unter den Problemen des Ansatzes litten:

1. Viele Besucherinnen geben falsche Daten an
2. Einige Besucherinnen gehen lieber in Lokalitäten, die es mit der Erfassung nicht so genau nehmen
3. Oft sind die Zettel schwer leserlich
4. Die Anzahl der Zettel kann schnell in den Bereich mehrerer hundert gehen – pro Tag
5. Die Alarmierung jeder einzelnen Person ist mühsam und zeitaufwändig – das wiederum führt zu massiven Verzögerungen

Mit anderen Worten: Das Zettel-System scheitert an den Anforderungen der Praxis.

Es fehlt der Datentyp „Zusammenkunft“

Die beiden Beispiele Restaurantbesuch und Konferenz haben etwas gemeinsam: Sie bezeichnen die Zusammenkunft mehrerer Personen an einem Ort für einen Zeitraum. Welcher Ort das genau ist, und welche Personen genau anwesend waren, ist dabei unerheblich. Eine zentrale Erfassung verbietet sich also.

Die Corona-Warn-App kann bisher nur Abstände zwischen einzelnen Personen erfassen. Was fehlt, ist der Datentyp der Zusammenkunft. Letzte Woche habe ich einen datenschutzkonformen Ansatz dafür mit Tim Pritlove in unserem Podcast Logbuch:Netzpolitik umrissen. Nahezu zeitgleich haben Wouter Lueks, Seda Gürses, Michael Veale, Edouard Bugnion, Marcel Salathé und Carmela Troncoso ein Whitepaper veröffentlicht, das den Ansatz sauber ausformuliert.

Dezentrales Presence Tracing

Das System ist so simpel, wie datensparsam: Wie schon beim Contact Tracing gibt es keine zentrale Datensammlung darüber wer wen wann wo getroffen hat. Die Information, dass eine Person Teil einer Zusammenkunft war, wird ausschließlich auf ihrem eigenen Gerät gespeichert. Die Alarmierung erfolgt analog zum bisherigen Ansatz der CWA durch Veröffentlichung eines Codes, der für die restliche Öffentlichkeit ohne Aussage ist.

Im Folgenden spiele ich den Ablauf beispielhaft für ein konspiratives Meeting einer Gruppe von Wirecard-Managern durch – der Ablauf für ein Restaurant wäre analog.

1. Die Zusammenkunft wird in der Corona-Warn-App angelegt. Die „Gastgeberin“ erhält einen QR-Code, den sie den anderen Personen zeigen kann. Außerdem erhält sie den Schlüssel, der nötig ist, um die Personen im Anschluss zu alarmieren.
2. Die anderen Anwesenden scannen den QR-Code mit ihrer App. Sie speichern damit den Code dieser Zusammenkunft auf Ihrem Gerät. Ebenso wird die Uhrzeit der Anwesenheit festgehalten.
3. Im Fall einer notwendigen Alarmierung wird der Code der Zusammenkunft (optional zusammen mit dem Risiko-behafteten Zeitraum) veröffentlicht.
4. Wie schon beim Contact Tracing werden von der App alle veröffentlichten Codes heruntergeladen und mit den lokalen Daten abgeglichen.

In der Gastronomie könnte das Verfahren alternativ zur papierbasierten Erfassung angeboten werden. Demgegenüber hätte es nur Vorteile: eine schnelle Alarmierung ist möglich, eine zentrale Datensammlung wird vermieden, Besucherinnen müssen keine persönlichen Daten angeben. Die 10 Prüfsteine für die Beurteilung von „Contact Tracing“-Apps gelten selbstverständlich weiterhin, sind nicht verhandelbar und können von diesem Ansatz bei sauberer Umsetzung erfüllt werden.

Weiterentwicklungen wie diese sollten bei einer 20-Mio-Euro-App nicht aus der Community kommen müssen, sondern aktiv von Telekom und SAP vorangetrieben werden.

Gamma/FinFisher stellt Staatstrojaner her – Schadsoftware, die von Geheimdiensten und Strafverfolgungsbehörden eingesetzt wird. Der Staat hackt seine Bürger – in Demokratien ist das ein heiß diskutiertes Thema. Zuletzt habe ich 2017 dazu als Sachverständiger im Rechtsausschuss des Bundestags Auskunft gegeben: Risiken für die innere Sicherheit beim Einsatz von Schadsoftware in der Strafverfolgung.

Einsatz gegen Oppositionelle

In Diktaturen wird weniger diskutiert, sondern einfach gemacht. Entsprechend häufen sich seit Jahren die Hinweise, dass Gamma/FinFisher in Staaten den Schwerpunkt seiner Kundschaft hat, die nicht für ihre Demokratien bekannt sind: In Ländern wie Bahrain, Ätiopien, Ägypten, und Türkei wurde die Software eingesetzt – natürlich nicht gegen Kriminelle, sondern gegen politische und journalistische Opposition.

Wie kann es sein, dass ein deutsches Unternehmen “Cyberwaffen” an Diktaturen der Welt exportiert? Unterliegen solche Produkte keinen Exportbeschränkungen?
Doch. Natürlich tun sie das.

Exportbeschränkungen

Und genau diese Exportbeschränkungen scheinen umgangen worden zu sein, als die Software im Sommer 2017 gegen die türkische Oppositionsbewegung eingesetzt wurde. Der Nachweis gestaltet sich aber schwierig: Die Exportrestriktionen galten erst ab dem 18. Juli 2015. Wurde die in der Türkei 2017 eingesetzte Schadsoftware vor oder nach diesem Datum geliefert? Und lässt sich überhaupt nachweisen, dass das Sample von FinFisher stammt?

Beitrag des CCC

Der Frage nach Herkunft und Lieferzeitpunkt haben Thorsten Schröder und ich uns letztes Jahr gewidmet. Durch die Analyse von insgesamt 28 FinFisher-Samples konnten wir eine Kontinuität aufzeigen, in die sich das Sample einfügt. Außerdem konnten wir das Herstellungsdatum bestimmen: Es liegt eindeutig nach dem Inkrafttreten der Exportrestriktionen. Ergänzend zu wichtigen Ergebnissen anderer Forscher wurde unsere Analyse Teil der Grundlage einer Strafanzeige gegen das Unternehmen.

Unsere Analyse “Evolution einer privatwirtschaftlichen Schadsoftware für staatliche Akteure” umfasst 60 Seiten. Die in dem Rahmen gebauten Tools und die Rohdaten (inklusive aller Samples) haben wir auf Github veröffentlicht. Auf dem 36C3 hat Thorsten die Ergebnisse in einem Vortrag präsentiert.

Durchsuchungen

Nachdem die Strafanzeige gestellt war, passierte lange Zeit nichts. Doch gestern wurde bekannt, dass in der vergangenen Woche 15 Wohn- und Geschäftsräume im In- und Ausland vom Zollkriminalamt durchsucht wurden.
Wow!

Durchsuchungen in diesem Umfang finden nicht einfach mal so statt. Der Verdacht scheint sich also tatsächlich zu erhärten. Ein Firmengeflecht aus Briefkästen in Malaysia, Bulgarien, Pakistan und Dubai wird nun untersucht. Verwaltet werden die Unternehmen zentral aus München. Wer Exportrestriktionen umgehen will, könnte mit einem solchen Netzwerk ganz gut “Hütchen spielen.”

Zum jetzigen Zeitpunkt bleibt offen, ob der ominöse “Anwalt aus München” einen juristisch wasserdichten Weg gefunden hat, die gesetzlichen Vorgaben zu umgehen. Wenn das der Fall sein sollte, muss die Gesetzgeberin nachbessern.

Weil Software nicht materiell gebunden ist, lässt sie sich über das Internet leicht in alle Länder der Welt “liefern” – meine persönliche Vermutung ist, dass die Durchsuchungen den Nachweis liefern sollen, dass an den verschiedenen Standorten mit der gleichen Code-Basis agiert wird.

Deutschland ist und bleibt stolze Kundin

Dass Gamma/FinFisher ein äußerst zweifelhaftes Unternehmen ist, wird von niemandem mehr infrage gestellt – wahrscheinlich noch nicht einmal von den ebenfalls zweifelhaften Kundinnen.

Deutsche Strafverfolgungsbehörden wissen seit 2012, dass der Funktionsumfang der Software gegen deutsches Recht verstößt. Nun kommt auch noch der Verdacht der kriminellen Umgehung von Exportrestriktionen hinzu. Und erst vor wenigen Wochen wies Amnesty International erneut den Einsatz der Software in Ägypten nach – wie so oft, gegen Oppositionelle.

Dennoch: Das Bundeskriminalamt und die Berliner Polizei sind stolze Kundinnen des Unternehmens. Wann hört Deutschland endlich auf, dieses Unternehmen auch noch mit zu finanzieren, statt dem grundrechtswidrigen, rechtswidrigen und demokratiefeindlichen Treiben endlich ein Ende zu setzen?

Acknowledgements:

Dass wir überhaupt so viel über die Machenschaften des dunklen Geflechts mit Hauptquartier in München wissen, vielen internationalen Forscherinnen, Whistleblowern, Hackern und Journalistinnen zu verdanken:

• Betroffene und Zielpersonen, haben die Angriffe auf sie entdeckt und an Forscherinnen gemeldet
• Aktuelle und ehemalige Angestellte, Informant:innen und andere Whistleblower haben immer wieder wichtige Hinweise gegeben.
• Claudio Guarnieri jagt seit vielen Jahren Staatstrojaner und war auch an der jüngsten Veröffentlichung zum Einsatz in Ägypten maßgeblich beteiligt.
• Das Amnesty Security Lab hat nicht nur die Veröffentlichung zum Einsatz in Ägypten hervorgebracht.
• Andre Meister berichtet auf netzpolitik.org, auch wenn das Unternehmen versucht, seine Berichterstattung zu unterbinden.
• Phineas Fisher hat Gamma/FinFisher gehackt und der Forschungsgemeinschaft viele Anhaltspunkten zur Attribution geliefert: Torrent.
• Das Citizen Lab hat in den vergangenen Jahren mehrere wichtige Analysen veröffentlicht.
• ESET hat unter anderem wichtige Forschung zur Analyse und Deobfuscation von FinFisher veröffentlicht.
• Auch Microsoft kämpft nicht nur gegen diesen Staatstrojaner, sondern teilt die Erkenntnisse auch öffentlich.
• Gesellschaft für Freiheitsrechte, Reporter Ohne Grenzen, European Center for Constitutional and Human Rights und netzpolitik.org haben die Strafanzeige zusammen gestellt.

Gestern hatte ich Gelegenheit im ARD Hauptstadtstudio zu erklären, warum die Bemühungen, Huawei aus deutschen 5G-Netzen heraus zu halten falsch begründet und nicht zielführend sind.

Für das Kunst- und Kulturmagazin “Flick Flack” habe ich erklärt, welche Bedeutung der Begriff “Trolling” für mich hat – und welche nicht.

Spoiler: Die landläufige Auffassung, dass Hass und Hetze im Netz diese Definition erfüllen, teile ich nicht. Hass und Hetze sind einfach nur Hass und Hetze.

Updates:

• 2020-04-26: Nachdem die Bundesregierung zuletzt einen zentralen Ansatz bevorzugte, wird nun ein dezentraler Ansatz verfolgt. Das ist sehr zu begrüßen.
• 2020-04-22: Die Debatte wird aktuell unübersichtlich. Weiterhin stehen dezentrale Ansätze wie DP-3T, Apple/Google und der von mir unten beschriebene Ansatz den “zentralen” Ansätzen gegenüber.
  Der Hauptunterschied ist, wo die Entscheidung über Alarmierung getroffen wird. In dezentralen Ansätzen erfolgen Analyse und Entscheidung für Alarmierung auf den Geräten der Nutzerinnen. In zentralen Ansätzen geschieht dies auf dem bzw. einem Server.
  Ich habe habe den Stand der Debatte und die jeweiligen Argumente in einem Interview mit der Wirtschaftswoche zusammengefasst.
  Meine These: Apple und Google geben jetzt den Ton an, die meisten Diskussionen haben sich erübrigt. Ähnlich habe ich den Stand auch in Logbuch:Netzpolitik Folge 341 zusammengefasst.
• 2020-04-10: Wie zu erwarten war, haben Apple und Google einen gemeinsamen Standard für Contact Tracing entwickelt und veröffentlicht:
  • Contact Tracing – Bluetooth Specification
  • Contact Tracing – Cryptography Specification
  • iOS Contact Tracing API
  • Android Contact Tracing API
• 2020-04-09: Martin Holland und Jürgen Kuri haben das Thema heute in der heise-Show mit mir als Gast besprochen.
• 2020-04-06: CCC veröffentlicht 10 Prüfsteine für die Beurteilung von “Contact Tracing”-Apps

Logbuch:Netzpolitik

In der neuen Folge unseres Podcasts Logbuch:Netzpolitik habe ich unter anderem mit einer Reihe an Missverständnissen zu den Möglichkeiten und Grenzen sogenannter “Corona Apps” auseinander gesetzt.

Zur vollständigen Episode geht es hier: LNP339 Die Fantasie kennt keine Grenzen beim Setzen von Grenzen.

Logbuch:Netzpolitik ist werbefrei, kostenlos und kann überall abonniert werden, wo es Podcasts gibt.

Deutschlandfunk: Computer und Kommunikation

In der aktuellen Folge von Computer und Kommunikation wird der technische Stand von Entwicklung und Diskussion sehr gut von Peter Welchering und Manfred Kloiber zusammengefasst:

Apps im Kampf gegen COVID-19 und ihre Risiken

Updates:

• 2020-04-26: Nachdem die Bundesregierung zuletzt einen zentralen Ansatz bevorzugte, wird nun ein dezentraler Ansatz verfolgt. Das ist sehr zu begrüßen.
• 2020-04-22: Die Debatte wird unübersichtlich und hitzig. Weiterhin stehen dezentrale Ansätze wie DP-3T, Apple/Google und der von mir unten beschriebene Ansatz den “zentralen” Ansätzen gegenüber.
  Der Hauptunterschied ist, wo die Entscheidung über Alarmierung getroffen wird. In dezentralen Ansätzen erfolgen Analyse und Entscheidung für Alarmierung auf den Geräten der Nutzerinnen. In zentralen Ansätzen geschieht dies auf dem bzw. einem Server.
  Ich habe habe den Stand der Debatte und die jeweiligen Argumente in einem Interview mit der Wirtschaftswoche zusammengefasst.
  Meine These: Apple und Google geben jetzt den Ton an, die meisten Diskussionen haben sich erübrigt. Ähnlich habe ich den Stand auch in Logbuch:Netzpolitik Folge 341 zusammengefasst.
• 2020-04-10: Wie zu erwarten war, haben Apple und Google einen gemeinsamen Standard für Contact Tracing entwickelt und veröffentlicht:
  • Contact Tracing – Bluetooth Specification
  • Contact Tracing – Cryptography Specification
  • iOS Contact Tracing API
  • Android Contact Tracing API
• 2020-04-05: Tim Pritlove und ich diskutieren gesellschaftliche und technische Anforderungen in LNP339 Die Fantasie kennt keine Grenzen beim Setzen von Grenzen
• 2020-04-02: Interview zum Thema bei Markus Lanz (youtube)
• 2020-03-31: Tim Pritlove und erklären das allgemeine Konzept in LNP338 Corona Tracking App
• 2020-03-31: Interview bei phoenix (youtube)
• 2020-03-31: Beitrag WDR aktuelle Stunde hinzugefügt
• 2020-03-29: FAQ am Ende des Artikels hinzugefügt

Über eine technisch gestützte Rückverfolgung von Corona-Infektionen werden zur Zeit verschiedene Debatten heiß geführt. Es begann mit der Weitergabe von Bewegungsdaten durch Mobilfunkanbieter an das Robert-Koch-Institut und natürlich ließen auch Gesetzesänderungen zum vollumfänglichen Location-Tracking nicht lang auf sich warten.

Im Folgenden erkläre ich, warum Location-Tracking völlig ungeeignet ist, und welche Methoden stattdessen zielführend sein könnten. Wichtig ist immer, Sinn und Ziel einer solchen App nicht aus den Augen zu verlieren:

Wenn bei einer Person zum Zeitpunkt t eine Infektion festgestellt wird, soll sie in der Lage sein, ihre Kontakte der letzen t–14 Tage darüber zu informieren. Nicht mehr, aber auch nicht weniger. Primäres Ziel sollte also sein, die Kontakte reliabel zu erfassen.

Datentypen

In der Debatte werden die Begriffe „Standortdaten“, „Bewegungsdaten“ und „Kontaktdaten“ wild gemischt. Zunächst müssen wir also klären, wovon überhaupt die Rede ist.

1. Standortdaten: Person x war zum Zeitpunkt t an Ort A

Problem 1: Die räumliche Auflösung via GPS ist ziemlich ungenau.
Ob sich zwei Personen nah genug gekommen sind, um einander zu infizieren, oder ob sie mehrere Meter voneinander entfernt waren, lässt sich anhand der Genauigkeit von GPS einfach nicht entscheiden – eine Unmenge an false positives wäre die Folge.

Problem 2: Da wir uns bewegen, entsteht natürlich eine sehr lange Liste für jede Person. Die Länge der Liste richtet sich dabei nach der Frequenz der Erfassung. Noch dazu sind die Daten personengebunden. Da wir uns zurzeit weitestgehend isolieren, wäre der größte Teil der erfassten Daten zudem noch absolut irrelevant!

Fazit: Standortdaten sind aufgrund ihrer Ungenauigkeit schlichtweg ungeeignet. Schon das allein disqualifiziert sie, so dass wir die immensen Datenschutz- und Grundrechtsverletzungen gar nicht erst zu diskutieren brauchen.

2. Bewegungsdaten: In Zeitraum Δt haben sich n Personen von Bereich A in Bereich B bewegt.

Bewegungsdaten sind also im Gegensatz zu Standortdaten räumlich und zeitlich geringer aufgelöst. Sie sollten darüber hinaus über mehrere Personen aggregiert sein, so das die Identifikation der Bewegungen einzelner nicht möglich sein sollte.

Anwendungszweck: Diese Art Daten eignen sich gut zur Messung der Effektivität von Maßnahmen zur Senkung der Mobilität.Das ist im weitesten Sinne das, was von den Mobilfunknetzen an das RKI gegeben wird – ein Anspruch also, für den es eine seit Jahren existierende Lösung gibt. Diese Lösung wurde kommerziell übrigens allen angeboten, die bereit sind, dafür zu bezahlen. Das RKI ist in der Reihe der Abnehmer vermutlich noch der am wenigsten problematische.

Problem 1: Je nach zeitlicher und räumlicher Auflösung sind diese Daten ggf. von einer böswilligen Anwenderin durchaus de-anonymisierbar. 

Problem 2: Für das Identifizieren von Kontakten sind die Daten nicht geeignet.

3. Kontaktdaten: Person a und Person b hatten zum Zeitpunkt t für einen Zeitraum länger als Δt Kontakt.

Dies ist der einzige relevante Messwert, um den es hier wirklich gehen soll. Wo dieser Kontakt stattgefunden hat, oder an welchem Ort a und b davor und danach waren, ist absolut uninteressant. Wieso sollte das also überhaupt erfasst werden?

Halten wir fest: alles, was erfasst werden muss, sind Kontaktdaten.

Datenspeicherung

Viele vorgeschlagene Konzepte sehen eine zentrale Speicherung von Standort- oder Bewegungsdaten vor. Hierbei würde eine Unmenge an irrelevanten Daten (kein Kontakt) gespeichert. Darüber hinaus ist eine zentrale Datenhaltung aus offensichtlichen Gründen abzulehnen: IANAL; aber nicht nur unterliegen wir hier dem Bereich der DSGVO, sondern auch den besonderen Anforderungen für sensible Gesundheitsdaten.

Die offensichtliche Anforderung ist also, sämtliche Daten dezentral und anonym vorzuhalten – und zwar auf eine Weise anonymisiert, die auch keine Deanonymisierung zulässt.

Es ergeben sich folgende Anforderungen:

• Dezentralität: Jede Person sammelt nur Daten für sich selbst. Diese werden nicht automatisiert weitergegeben.
• Anonymität:
  • Die Daten, die jede Person sammelt, sind nicht geeignet zur Deanonymisierung anderer.
  • Die Daten, die jede Person sammelt, sind nicht geeignet zur Deanonymisierung der Person selbst.
• Datensparsamkeit: Nur im Infektionsfall kann eine Person ihre Daten weitergeben. Auch in diesem Fall geben die Daten aber weder die Identität der infizierten Person, noch die Identität ihrer Kontaktpersonen preis.

Als Mitglied der Jury des Hackathons „Wir vs Virus“ hatte ich die Freude, eine Reihe von Einreichungen zu begutachten, die eine kluge Lösung gefunden haben, diese Anforderungen zu vereinen. Zur Veranschaulichung stark vereinfacht möchte ich sie hier einmal grob darstellen:

1. Mein Handy sendet in regelmäßigen Abständen mittels Bluetooth Low Energy Beacon einen zufälligen Code aus. Dieser Code ändert sich regelmäßig, bspw. alle 30 Minuten.
2. Empfängt mein Handy den Code eines anderen Handys, wird anhand der Signalstärke der Abstand geschätzt. Ist der Abstand gering genug, speichert mein Handy diesen Code. Da sich der Code der anderen Person bald wieder ändern wird, hat mein Handy keine personengebundenen Daten erfasst und ist auch nicht in der Lage, die andere Person längere Zeit zu tracken.
3. Werde ich als infiziert diagnostiziert, veröffentliche ich an zentraler Stelle alle Codes, die ich je gesendet habe auf einem zentralen Server. Hier werden auch die Codes von allen anderen Menschen veröffentlicht, die diagnostiziert wurden.
4. Alle anderen Nutzer laden regelmäßig die veröffentlichten als „infiziert“ markierten Codes herunter. Diese Codes sind ohne jede Aussage über Ort, Zeit oder Personen. Sie haben nur Informationswert für jene Personen, mit denen ich Kontakt hatte.
5. Der Abgleich der veröffentlichten mit den lokal auf meinem Handy gespeicherten Codes ermöglicht das Berechnen meiner Exposition. Dabei ist es unerheblich, ob ich 10 Stunden mit einer infizierten Person verbracht habe, oder jeweils 20 halbe Stunden mit unterschiedlichen infizierten Personen. Selbst das kann aus den Daten nicht rekonstruiert werden.
6. Auf dem zentralen Server befinden sich keinerlei Daten darüber, welche Personen infiziert sind, wo sie sich wann aufgehalten haben, oder welche Personen sie wo getroffen haben.

Trotzdem haben wir auf diese weise den Datensatz bester Qualität, weil genau nur unsere Kontakte aufgezeichnet wurden – jene Daten also, auf die es wirklich ankommt.

Elegante Lösungen

Diesen Anforderungen entsprechen folgende Einreichungen zum Hackathon „Wir vs. Virus“, die alle mittels Bluetooth ausgetauschte, zeitlich beschränkte Codes nutzen. Ich verlinke sie hier ohne Anspruch auf Vollständigkeit, weil ich nicht weiß ob ich alle Einreichungen zu diesem Thema reviewed habe:

• Update: Inzwischen haben sich drei der Projekte zusammengeschlossen:
  ito – track infections, not people!, früher:
  • bandemic
  • bluto
  • privacy preserving disease tracking
  Den weiteren Fortschriff von ito kann man hier begutachten und sich einbringen.
• CovidEncounters

Für Menschen ohne Smartphone würde sich mit leichten Abstrichen in eine QR-Code-Lösung anbieten, bei der die Privatsphäre der Personen zumindest gegenüber wohlmeinenden Kontakten sichergestellt werden könnte – natürlich fehlt dem QR-Code aber die Benachrichtigungsfunktion: Tracking Infection Awareness Alert (IAA)

Wir lernen also: Die Daten der höchsten Qualität und Aussagekraft lassen sich vollständig anonym und dezentral erfassen. Ein wunderschönes Beispiel, wie wir ohne zentralisierte Massenüberwachung sogar ein besseres Ergebnis bekommen – und dabei entspannt und frei weiterleben können, ohne der Corona-Krise gleich noch eine selbstverschuldete Grundrechtskrise folgen zu lassen.

Mein Lob, meine Anerkennung und mein Glückwunsch gilt den „Wir vs Virus“-Teams!

Der Teufel steckt im Detail

Natürlich muss aber auch angemerkt werden, dass nur minimale Änderungen ausreichen würden, die Anonymität oder Dezentralität zu zerstören. Beispielsweise, den Code nicht regelmäßig zu ändern, oder alle Codes immer zentral zu erfassen. Selbstverständlich kann so eine App ausschließlich auf freiwilliger Basis verbreitet werden. Wenn die hier skizzierten Anforderungen kompromisslos erfüllt sind, hätte ich aber keinerlei Bedenken, die App zu nutzen – und ich denke dass es vielen Menschen ähnlich ginge.

Medienberichte

In den Tagesthemen konnte ich gestern diese Gedanken zum Teil ausführen:

Beim 36C3 habe ich einen Vortrag über menschliche Faktoren der IT-Sicherheit gehalten:

Die überwältigende Mehrheit der erfolgreichen Hacks in freier Wildbahn setzen auf menschliche Faktoren. Wie können wir Systeme und Interfaces gestalten, um diese Schwachstellen zu mindern?

Ob Ransomware oder Phishing, APT-Angriffe oder Stalking: Die am häufigsten ausgenutzte Schwachstelle ist der Mensch.

Ein Problem, das nur wenig Forschung tatsächlich angehen will. Stattdessen begnügen wir uns damit, den Usern Dummheit zu unterstellen und menschliche Faktoren der IT-Sicherheit “out of scope” zu sehen.

Der Vortrag wurde aufgezeichnet und ist bei YouTube und auf media.ccc.de verfügbar:

• Youtube: Hirne Hacken – Menschliche Faktoren der IT-Sicherheit
• media.ccc.de: Hirne Hacken – Menschliche Faktoren der IT-Sicherheit

Der Vortrag kann unter diesem Link anonym bewertet werden.
Ausführlicheres Feedback und Anregungen nehme ich auch gern direkt entgegen.

In den letzten Monaten haben Thorsten Schröder und ich endlich mal wieder ein kleines CCC-Projekt zusammen gemacht, das wir beim Congress endlich der Öffentlichkeit präsentieren konnten: Wir haben den Staatstrojaner Finspy in der Android-Version analysiert.

Anlass ist die Strafanzeige der Gesellschaft für Freiheitsrechte. Wie immer ist das Ganze ein bisschen eskaliert und am Ende haben wir nicht einen, sondern 28 Versionen des Staatstrojaners analysiert und die Samples natürlich auf Github veröffentlicht, um der Community weitere Analysen zu ermöglichen.

Der Fall ist politisch pikant, weil auch deutsche Strafverfolger FinSpy kaufen und einsetzen, während diese Schadsoftware aus völlig unerklärlichen Gründen immer wieder in autoritären Regimen beim Einsatz gegen demokratische Kräfte entdeckt wird. Die Zusammenhänge sind in diesem Tagesschau-Beitrag gut erklärt.

Es ist immer eine große Freude und Ehre, mit Thorsten zu arbeiten.
Ich freue mich, dass es sich gelohnt hat:

• CCC analysiert Münchner Staatstrojaner FinSpy (Pressemitteilung)
• Evolution einer privatwirtschaftlichen Schadsoftware für staatliche Akteure – FinFisher FinSpy für Android 2012-2019  (60 Seiten PDF, ~3MB)
• Github-Repo mit Dokumentation und Samples
• Github-Repo mit Analyse-Tools

Pressespiegel (Auswahl)

• Youtube: Ermittlungen gegen FinFisher: Gutachten des CCC (Tagesschau vom 28.12.2019) 
• Deutschlandfunk: Deutsche Spionagesoftware gegen türkische Oppositionelle?
  
• br.de: Chaos Computer Club verfolgt Spur von Spähsoftware
• sueddeutsche: FinFisher: Spionagesoftware made in Germany?
• Deutschlandfunk: Kein Export von Spionagesoftware
• heise.de: Bundestag: Auch Zollfahnder dürfen künftig den Bundestrojaner einsetzen
• zeit.de: Exportkontrolle von Digitalwaffen funktioniert nicht

Mit dem Spiegel habe ich über Darknet-Marktplätze gesprochen.

Gestern habe ich bei der Schwarzkopf-Stiftung Junges Europa einen Vortrag über die großartigen Chancen und aktuellen Probleme des Internets für die Demokratie gehalten:
Verheißung oder Bedrohung? Das Internet und seine Auswirkungen auf die Demokratie [YouTube-Link].

Mein persönliches Highlight war die anschließende Diskussion.
Continue reading →

“Wann, wenn nicht wir*” erscheint am 4. September 2019 im Verlag S. Fischer. Das Buch versammelt Fakten über bereits sichtbare Folgen der Klimakrise und ruft zum Handeln auf. Für alle nachvollziehbar, konkret und undogmatisch erklärt es, wie sich das Rebellieren organisieren lässt: Von der gewaltfreien Kommunikation über das Errichten von Straßenblockaden und die Vorbereitung anderer Protestaktionen bis hin zum Kochrezept für mehrere hundert Menschen.

Das Handbuch von, zu und für Extinction Rebellion ruft zu massenhaftem gewaltfreien zivilen Ungehorsam gegen die Klimakrise und das Massenaussterben auf. Ich habe einen kurzen Beitrag über sichere digitale Vernetzung beigesteuert:

Sicherheit in selbst-organisierenden Systemen

Neben dem Zusammenkommen in den Aktionen im öffentlichen Raum ist die digitale Kommunikation die Grundlage für unsere Vernetzung und Zusammenarbeit. Das Internet ist das perfekte Werkzeug für Überwachung, Kontrolle und Macht – und gleichzeitig das perfekte Werkzeug für ihr Gegenteil: Dezentrale Vernetzung, Befreiung und soziale Veränderung. Es liegt an uns, das befreiende Potenzial der Dezentralität auszuschöpfen, Ihre Schwächen zu kennen, und uns gegen zentralisierte Überwachung zu schützen.
Aus technischer und sozialer Sicht birgt aber auch die Dezentralität einige Risiken – insbesondere im Digitalen: Die größte technische Gefahr besteht in den massenhaften digitalen Spuren, die wir hinterlassen. Das größte soziale Risiko ist die Unterwanderung.

In der vergangenen Woche war ich zu Gast bei Timster, einer Wissenssendung auf dem Kinderkanal. Ich war sehr positiv beeindruckt, wie viel Mühe, Vorbereitung, Nachdenken und Aufwand in die Produktion dieser Kindersendung geht. Das Team hat großen Wert darauf gelegt, die Dinge korrekt und kindergerecht zu erklären – gar keine einfache Aufgabe!

Nach dem öffentlichen Bekanntwerden konnten Täter und Mittäter hinter den ausführlichen Datenveröffentlichungen im “Doxing-Adventskalender” sehr zügig dingfest gemacht werden. Nun ist es Zeit, daraus die richtigen Lehren zu ziehen.

War das ein Superhack?

Nein. Es ist auch nichts, worauf man stolz sein könnte.

1. “Nur” 50 der 1.000 betroffenen Personen wurde wirklich gehackt – der Rest der Daten stammte aus diesen illegalen Zugriffen und vermutlich aus weiteren Recherchen.
2. Das Vorgehen war simpel, hatte keine besondere technische Komponente und
3. der Täter verstand es nicht, seine Spuren zu verwischen um sich nicht erwischen zu lassen.

Das bedeutet aber auch:

Für die Ausgabe 11/12.2018 von Report Psychologie habe ich einen Beitrag über die menschlichen Faktoren beim Hacking beigesteuert:

Wenn Hacker Menschen hacken

»Unser System ist unhackbar«, hören wir diverse Hersteller von Software oder Hardware immer wieder betonen. Und immer und immer wieder werden sie eines Besseren belehrt, sobald Fachkundige mit gutartiger oder bösartiger Motivation diese Aussage auf die Probe stellen.
Wie aber funktioniert eigentlich dieses Hacken? In der Breite der Gesellschaft herrscht über diese Frage eine ausgeprägte Unkenntnis, in deren Schatten sich allerlei mythische Theorien breitmachen…

Ein PDF des Artikels gibt es hier zum Download.

An ugly vulnerabilty in the wordpress plugin wp-gdpr-compliance was recently discovered and reported by Mikey Veenstra of wordfence. Please read his very comprehensive write-up of the vulnerability and its IOC right after updating to the latest version to be safe.

Since I was also using the plugin, this vulnerability was giving me a headache today. Based on wordfences report, I wrote a quick and dirty shellscript to search for indicators of compromise on the various wordpress hosts I am sadly administrating. As usual, please do not run the script without thouroughly checking und understanding what it does. You will likely need to modify constants and paths.

Also, please make sure you stay up to date and on top of things while other researchers discover more indicators of compromise and develop better detection techniques. Continue reading →

Im Heinz-Nixdorf-Forum zu Paderborn wurde heute die Ausstellung “Helfer oder Fälscher – Computer im Wahleinsatz” eröffnet.

Zu diesem Auftakt habe ich keinen kurzen Vortrag über Wahlcomputer gehalten, in dem ich (hoffentlich) leicht verständlich gemacht habe, warum der Einsatz von Computern als Wahlgeräte eine ziemlich dumme Idee ist.

Abschließend nehme ich noch kurzen Bezug auf verbleibende Sorgen, wie DER RUSSE(TM) die Bundestagswahl 2017 – laut BSI – hacken könnte.

Eine Aufzeichnung gibt es hier, bei Vimeo und auch bei Youtube.

[embedyt] https://www.youtube.com/watch?v=eqk4oAeUu1U[/embedyt]