Archiv der Kategorie: Security

Diebstahlsicherung

Nothämmer in öffentlichen Verkehrsmitteln werden gerne geklaut. Das hat zwar keinen Sinn, ist aber ganz leicht und manchem betrunkenen Halbstarken reicht die bloße Gelegenheit. Heute ist mir diese clevere Diebstahlsicherung begegnet: An den Nothammer kommt man erst, nachdem man die Notbremse gezogen hat. Das ist im Notfall kein Hindernis, aber Gelegenheitsdieben verdirbt es den Spaß. Zwar ist es nicht schwer, den Notbremsgriff zu ziehen, doch zieht man damit sogleich die Aufmerksamkeit der Fahrerin auf sich. Das dürfte zur Abschreckung genügen.Notbremsgriffmit Nothammer

Unterschätzte Risiken: software-definiertes Eigentum

Juristen unterscheiden aus gutem Grund zwischen Eigentum und Besitz. Mein vor gut einem Jahr geklautes Fahrrad zum Beispiel ist immer noch mein Eigentum, ich besitze es nur nicht mehr. Das Eigentum ist ein Recht, welches sich aus Gesetzen, Verträgen und nötigenfalls Gerichtsbeschlüssen ergibt. Der Besitz, die Verfügungsgewalt ist eine Tatsache, deren Ausprägung rechtmäßig oder unrechtmäßig sein kann. Verleihe ich etwa ein Fahrrad, so gelangt es rechtmäßig in den Besitz eines anderen, während ich Eigentümer bleibe. Gibt der Entleiher das Fahrrad nicht wie vereinbart zurück, sondern unterschlägt es, wird sein Besitz unrechtmäßig.

Solche Begriffe und Unterscheidungen sind über Jahrhunderte gewachsen und haben sich bewährt. Nun ist jedoch die wunderbare Blockchaintechnologie angetreten, unser geachsenes Verständnis von Eigentum und Besitz zu zerreißen. Wie zu erwarten war, geht das in die Hose.

Ihr habt sicher die Geschichte von dem Programmierer gelesen, der ein Passwort vergessen hat. Dieses Passwort gehört zu einer verschlüsselten Festplatte, auf dieser Festplatte ist ein Bitcoin-Wallet gespeichert, an diesem Bitcoin-Wallet hängen quantisierte Blockchain-Ergänzungsprivilegien im Umfang von ungefähr 7.000 Bitcoin und bei den Preisen, zu denen solche Privilegien derzeit gehandelt werden, könnte man sie für ein mittleres Vermögen in echtem Geld verkaufen. Das ist blöd gelaufen und wenn etwas blöd läuft, kann man daraus lernen.

Lektion 1: Verschlüsselung ≠ Sicherheit

Unter den klassischen Schutzzielen Vertraulichkeit, Integrität und Verfügbarkeit wird letztere von Security-Laien gerne als Mauerblümchen behandelt. Oft ist Verfügbarkeit wie hier jedoch das wichtigste Schutzziel. Zwischen Verfügbarkeit und Vertraulichkeit muss man meistens abwägen, gerade wenn man Daten verschlüsselt, denn je sicherer die Verschlüsselung ist, desto schwieriger wird es, die Verfügbarkeit sicherzustellen. Ob und unter welchen Rahmenbedingungen Verschlüsselung zur Sicherheit beiträgt, muss man deshalb im Einzelfall anhand einer gründlichen Bedrohungs- und Risikoanalyse herausfinden.

Lektion 2: Software-definiertes Eigentum überfordert

In der von libertären Vorstellungen geprägten Blockchain-Welt ist sich jeder selbst der Nächste. Den Unterschied zwischen Besitz und Eigentum gibt es dort nicht, nur die Verfügungsgewalt über bestimmte Schlüssel („Wallets“). Wie beim guten alten Sparstrumpf unterm Kopfkissen muss jeder selbst für seine Sicherheit sorgen, ohne Unterstützung von Institutionen zu erhalten. Das ist im richtigen Leben anders, da kann man sein Bargeld zur Bank bringen und erhält dafür eine Anspruch auf Auszahlung. Unter Umständen kann man seinen Anspruch sogar noch nach einer Bankenpleite erfolgreich geltend machen, nämlich im Rahmen der Einlagensicherung. Im Vergleich zu einer Bank ist ein Bitcoin-Wallet sehr unbequem, weil es nur Besitz und kein davon unabhängiges Eigentum gibt.

Lektion 3: Software-definiertes Eigentum überfordert doppelt

Nicht nur muss man sich mit einem Bitcoin-Wallet ganz alleine um seine Sicherheit kümmern, man hat es dabei auch noch besonders schwer. Alles hängt am Wallet. Das muss vertraulich bleiben, denn wer Zugriff auf die geheimen Schlüssel bekommt, erhält die Verfügungsgewalt über die am Wallet hängenden Transaktionsprivilegien. Nebenbei braucht man auch noch eine sichere Ausführungsumgebung für Programme, um das sicherzustellen. Ein Wallet muss aber auch verfügbar bleiben, denn sonst kann man selbst nichts mehr damit anfangen. Das alles unter einen Hut zu bringen, ist schwer. Als Bankkunde hat man viel einfacher und bekommt nebenbei noch Service dazu, zum Beispiel Karten, mit denen man bezahlen kann.

Lektion 4: Auf lange Sicht sind wir alle tot. Und Bitcoin et al. auch.

Etwas weniger offensichtlich ist ein weiteres Problem. Bitcoin-Fans erklären oft und gerne, die Gesamtzahl der in der Bitcoin-Community herstellbaren quantisierten Transaktionsprivilegien sei von vornherein auf einen Maximalwert begrenzt. Dies ist jedoch nur die halbe Wahrheit, denn mit jedem verlorenen Wallet gehen, falls die Technik wie spezifiert funktioniert, die daran gebundenen quantisierte Transaktionsprivilegien unwiderruflich verloren. Das tatsächlich verfügbare Volumen an Transaktionsprivilegien („Bitcoins“) nimmt also auf lange Sicht ab, bis keine mehr übrig sind. Geld auf der Bank kann man zum Beispiel problemlos erben, wenn man über die erforderlichen Papiere verfügt. Bitcoin nicht, wenn der Erblasser sei Passwort nicht aufgeschrieben hat. Schreibt er es jedoch auf, riskiert er den Kontrollverlust.

Vielleicht ist es das beste, Bitcoin und alles davon Abgeleitete als Aktionskunst zu betrachten. Dann macht es wenigstens Sinn.

Attack Scenario ≠ Threat

The below video gives an example of what some people would call a threat model. For all I can tell the video leaves out some detail but is otherwise accurate. Why does it appear hilarious or silly rather than reasonable?

As a joke the video exploits a mismatch between the sensible, even verifiable analysis it presents and the ridiculous assumptions it implies. If this attack scenario manifested itself it would play out pretty much as presented. However, the implied very narrow and specific mode of operation – firing cannon rounds at computers – does not correspond with the behavior of any reasonably imaginable threat agent. Any agent with the capability to deploy main battle tanks is facing a wide range of possible uses and targets. Shooting individual personal computers remains not only far from being one of the more profitable applications of this capability, but guarantees a negative return. The cost is high and destruction of specific, low-value items promises rather limited gains. There are also much cheaper methods to effect any desired condition on the specific type of target, including its complete destruction.

While the attack scenario is accurate, it lacks, therefore, a corresponding threat that would produce actual attacks. Such a threat would exist, for example, if the assumed target were other main battle tanks rather than personal computers.

CoronApp-News 2020-09-06

Corona ändert alles. Jahrzehntelang stand die Deutsche Bahn unangefochten an der Spitze der deutschen Meckercharts, doch nun muss sie der Corona-Warn-App Platz machen:

Ob wir alle am Coronavirus oder aber an Corona-Apps sterben werden, bleibt offen.

CoronApp-News 2020-08-30

Diese Woche war wenig los.

  • In einem Monat, Ende September, soll die europäische Vernetzung der geeigneten nationalen Apps stehen.
  • Das Exposure Notification Framework, auf das sich viele  Kontaktbenachrichtigungsapps stützten, wird selbständiger. War bereits bisher die Kontakterfassung eine Funktion des Betriebssystems, so soll künftig auch der Empfang von Warnungen ohne besondere App möglich werden. Nur zum Auslösen einer Warnung nach einem positiven Test benötigt man dann noch eine offizielle App.
  • Die New Yorker Generalstaatsanwältin macht sich unterdessen Sorgen um den Datenschutz und fordert von Apple und Google, alternative  Kontaktverfolgungsapps an die kurze Leine zu nehmen, die in den Appstores angeboten werden. Anders als bei offiziellen Apps der Gesundheitsbehörden auf der Grundlage des Exposure Notification Frameworks, von denen es nur eine pro Land geben kann, sei bei unabhängigen Apps auf anderer Basis der Datenschutz nicht immer gewährleistet.
  • Nicht direkt eine App, aber immerhin digital: Reiserückkehrer aus Risikogebieten sollen sich künftig auf einer Website registrieren können.
  • Zu guter Letzt war die Kontaktverfolgung in Restaurants usw. auch diese Woche wieder für Nachrichten gut. Im Saarland ist die bisher geltende Regelung verfassungswidrig und Hacker haben eine Cloudanwendung eines Gastronomie-Dienstleisters gehackt, die neben einigen Millionen Reservierungen auch eine hohe fünfstellige Zahl von Corona-Kontaktdatensätzen aus 180 Restaurants enthielt.

CoronApp-News (2020-08-23)

Der Sommer neigt sich dem Ende zu und langsam könnte eine Corona-Warn-App ihren Nutzen beweisen, aber anscheinend glaubt kaum noch jemand daran:

Nicht gehört habe ich in den letzten Tagen von den Bemühungen um eine europaweite Integration der nationalen Corona-Apps. Weiß man, wie es darum steht?

CoronApp-News (2020-08-16)

In Sachen Corona-App drehen wir uns zunehmend im Kreis:

  • Die Downloadzahlen der Corona-Warn-App steigen nicht mehr nennenswert, sie lagen Anfang August bei 16,6 Millionen. Bis dahin hat die Hotline gut 1000 TANs für Benachrichtigungen herausgegeben.Wie viele davon tatsächlich verwendet wurden, weiß niemand. In der Schweiz bleibt ein Drittel der ausgegebenen Codes ungenutzt. Benachrichtigungen durch die App erfolgen jedenfalls selten genug, um Nachrichtenwert zu haben.
  • Damit Infizierte via App ihre Kontakte warnen können, müssen sie erst einmal von ihrer Infektion wissen und ein positives Testergebnis vorweisen. An diesem Punkt können Warn-Apps ohne eigenes Zutun scheitern. Neben Bayern mit seiner mittelgroßen Überrmittlungspanne hat dies auch Kalifornien aufgrund eines abgelaufenen TLS-Zertifikats demonstriert. Derweil gibt das Gesundheitsamt Trier dem ZDF Einblicke in seine Arbeit mit altmodischen Faxgeräten und die daraus resultierenden Probleme.
  • Sächsische Firmen wollen für Menschen ohne Smartphone einen zur Warn-App kompatiblen Corona-Warn-Buzzer entwickeln.
  • Den Datenschutz stellen Covid-19 und die Gegenmaßnahmen auf vielfältig  interessante Weise auf den Prüfstand. Lukas Mäder wundert sich in der NZZ zu Recht darüber, dass Restaurants ihren Gästen die App-Nutzung vorschreiben dürfen, zugleich jedoch deren Kontaktdaten erfassen müssen. Ebenso dürfe ein Arbeitgeber die App-Nutzung nicht kontrollieren, wohl aber Fieber messen. Und im Großen und Ganzen regt das alles niemanden auf. Werden wir eines Tages auf Covid-19 als Keimzelle eines realistischen, wirklich risikoorientierten Datenschutzes zurückblicken? Oder werden wir uns stattdessen daran gewöhnen, dass eine aus Sicht des Datenschutzes hochkritische App aus Datenschutzgründen leider, leider ohne Erfolgskontrolle auskommen muss?
  • Zu guter Letzt erregen Gästelisten in Restaurants usw. weiter die Datenschutzgemüter. Gefühlt erscheint jede Woche eine neue App mit dem Versprechen, die ad hoc eingeführte Zettelwirtschaft zu ersetzen und zugleich den Datenschutz zu verbessern.

Auf in die nächste Runde!

CoronApp-News (2020-08-09)

Corona-Apps füllen das diesjährige Sommerloch ganz gut  aus:

  • Ein Kommentar von Patrick Bernau zeigt noch einmal die Nebenwirkungen des rigiden technischen Datenschutzes im Exposure Notification Framework und der darauf basierenden Corona-Warn-App auf. Zudem macht er auf eine interessante Begründung aufmerksam: Eine weltweit verbreitete Plattform müsse auch in Gegenden mit geringer ausgeprägter Demokratie und Rechtsstaatlichkeit ohne Nebenwirkungen funktionieren. Apple und Google liefern uns als den technischen Datenschutz, den wir uns wünschen würden, lebten wir in einem Schurkenstaat.
  • Die Zeitschrift Connect hat die Corona-Warn-App auf Sicherheitsmängel untersuchen lassen, ohne dass dabei nennenswerte Probleme aufgetaucht wären. SAP ist stolz wie Oskar.
  • Unterdessen hakt es immer noch bei der Anbindung der Testlabore an die Infrastruktur der Corona-Warn-App. Anstelle des eigentlich vorgesehenen Verfahrens – beim Corona-Tets erhält man einen QR-Code, registriert damit seine App anonym als Empfänger für das Testergebnis und kann bei einem positiven unmittelbar eine Warnung an seine Kontaktpersonen auslösen – müssen App-Nutzer weiterhin häufig die Hotline bemühen, falls ihr Test positiv ausfällt und sie warnen möchten.
  • Was die App am Ende bringt und wie oft sie falsch liegt, ist auch unabhängig davon noch nicht geklärt. Eine Statistikprofessorin hat ein Modell entwickelt, mit dem man online spielen kann, um die theoretische Maximalleistung unter verschiedenen Annahmen zu ermitteln. Dieses Modell geht davon aus, dass alle Beteiligten die App nutzen.
  • Seit Anfang August hat auch Kanada eine App zur Kontaktverfolgung, COVID Alert.
  • Zu guter Letzt schreit auch die Erfassung von Kontaktdaten in Restaurants etc. weiter nach einer guten Lösung. In Baden-Württemberg müssen Restaurantbesucher jetzt keine E-Mail-Adresse mehr angeben – die Gesundheitsämter dürfen ihnen aus Datenschutzgründen ohne Einwilligung keine unverschlüsselte E-Mail schicken und E-Mail verschlüsseln kann kein Mensch, weil es keiner braucht.

Schönen Montag!

CoronApp-News (2020-08-02)

Die Infektionszahlen steigen, die Aktienkurse sinken und mit den Corona-Apps geht es langsam voran:

  • Nach der deutschen Corona-Warn-App sollen SAP und Telekom nun auch die europäische Plattform zur Vernetzung der nationalen Apps entwickeln. Miteinander verbunden werden sollen zunächst jene Apps, die auf das Exposure Notification Framework von Apple und Google setzen. Bluetooth-seitig sind sie ohnehin kompatibel, mit einem Update des Frameworks auch offiziell. Etwas bauen muss man jedoch noch für die Benachrichtigungen, die gegenwärtig nur national verarbeitet und versandt werden.
  • Die dänische Corona-App hat nach einer Pressemitteilung des dortigen Gesundheitsminsiteriums bisher 48 Kontaktpersonen informiert, von denen 46 nicht durch die parallele Kontaktverfolgung der Gesundheitsbehörden identifiziert wurden. Das muss kein gutes Zeichen sein, sondern kann auch auf Defizite der herkömmlichen Kontaktverfolgung hinweisen. Ein neuer Bericht aus Südkorea vermittelt einen Eindruck davon, welchen Aufwand erfolgreiche Kontaktverfolger treiben müssen. Schafft das eine App wirklich besser?
  • Serge Vaudenay beleuchtet die dunkle Seite von SwissCovid. Auch die App für die Schweiz setzt auf das Eposure Notification Framework der Smartphoneplattformen und wie überall ist nicht alles Gold, was glänzt. Die dünne Anforderungsanalyse rächt sich.
  • Wie berichtet, setzt auch Großbritannien vorerst auf die manuelle Kontaktverfolgung, wenn auch mit weniger Erfolg. Schottland jedoch schert aus und möchte doch eine App entwickeln. Grundlage soll die irische App sein, welche auch in Nordirland bereits getestet wird.
  • Zu guter Letzt nimmt die Digitalisierung manchmal auch überhand: Eine Reisende, die aus einem Risikogebiet am Flughafen Tegel eintraf, wollte sich dort testen lassen. Ihr Versuch scheiterte jedoch am fehlenden Smartphone, denn nur damit kann man sich dort für den Test anmelden und später das Ergebnis erfahren.

Habt Ihr alle Eure Klopapiervorräte aufgestockt?

CoronApp-News 2020-07-26

Die Infektionszahlen steigen und mit ihnen die Aufgeregtheit:

Jetzt warten wir mal ab, wie sich die zweite Welle auf die App auswirkt. Habt Ihr alle noch genug Klopapier?

CoronApp-News (2020-07-05)

Auch diese Woche blieb es vergleichsweise ruhig.

  • Die kumulierten Downloadzahlen der deutschen Corona-Warn-App steigen nur noch langsam. Die asymptotische Grenze scheint irgendwo in der Gegend von 15 Millionen zu liegen. Bis Vorgestern sollen über die App einige Hundert Fälle gemeldet worden sein. Der wirkliche Nutzen lässt sich jedoch nur schwer schätzen.
  • Ein Hindernis wird nach und nach beseitigt: Die Corona-Warn-App ist jetzt auch in den Appstores einiger anderer europäischer Länder erhältlich. Dass es so schwer ist, die App weltweit unter die Leute zu bringen, liegt an der Macht der Smartphone-Plattformen, von denen sie abhängig ist.
  • Michael Veale erklärt beim Guardian noch einmal, wieso die Fokussierung auf Privacy im Sinne möglichst guter Datengeheimhaltung am realen Problem vorbeigeht, das sich aus dieser Plattformmacht und der Interaktion mit Nutzern zusammensetzt.
  • Von Katastrophen im Zusammenhang mit der Corona-Warn-App war bislang nichts zu hören und auch die Mahnungen vor der App als Eintrittskarte haben sich als haltlose Spekulation erwiesen. Dennoch gibt es weiter Kritik an der Datenschutzfolgenabschätzung zur App und Forderungen nach einer spezifischen Rechtsgrundlage.
  • In der Schweiz zählt man nicht nur Downloads, sondern aktive Apps, und derzeit ist es eine gute Million.
  • Zu guter Letzt zieht die Corona-Warn-App auch Bastler an.

Vielleicht gewöhnen wir uns jetzt einfach an die App?

 

[OT] „Pearls of Juggling“ auf Deutsch

Bis zum 5. Juli:

Thematisch passt es hier eigentlich nicht rein, aber vielleicht stolpert trotzdem jemand darüber, den es interessiert. Zurzeit läuft eine Crowdfunding-Kampagne mit dem Ziel, eine deutsche Übersetzung des Buchs „Pearls of Juggling“ von Anthony Trahair zu finanzieren. In diesem Buch geht es nicht ums Werfen und Fangen, um Tricks und Muster oder die verschiedenen Gegenstände, die sich jonglieren lassen, sondern um Themen wie Bewegung, Musik, Training, Kreativität und Auftritte. Erreicht die Kampagne ihr Ziel von 120 Vorbestellungen, erhaltet Ihr für 24 € ein signiertes Exemplar der Übersetzung.

Bei Interesse bitte hier entlang: https://www.ulule.com/pearls-of-juggling-in-deutsch/

CoronApp-Links (2020-05-16)

Das Wetter ist zu schön, um das Wochenende vor dem Computer zu verbringen. Trotzdem hier eine Auswahl der Links rund um Corona-Apps und verwandte Themen, die sich während der vergangenen Woche angesammelt haben:

Bei so viel Text wünscht man sich fast eine Quarantäne, um genügend Zeit zum Lesen zu haben.

CoronApp-Links (2020-05-09)

Auch diese Woche haben sich allerlei Meldungen und Artikel zum Thema Corona-App angesammelt:

Die deutsche App soll nach aktuellem Stand im Juni erscheinen. Das Thema wird uns also noch eine Weile begleiten.

Dezentrale Engstirnigkeit, zentraler Realismus

Auch in der automatischen Kontaktverfolgung per Smartphone-App traut sich Großbritannien, einen eigenen Weg zu gehen. Dort beginnt gerade der Testbetrieb einer Corona-App, der eine zentrale Datenverarbeitung zugrunde liegt. Die Briten verfolgen damit in jeder Hinsicht das Gegenteil des deutschen Ansatzes: Während dort eine zentrale Lösung weitgehend einsatzreif ist, hat man hier gerade dezentral von vorne angefangen, nachdem das bereits laufende Projekt PEPP-PT mit seiner Entscheidung gegen eine streng dezentralisierte Lösung politisch in Ungnade gefallen war. Die hierzulande mitschwingenden paneuropäischen Großmachtphantasien fanden auf der Insel naturgemäß ohnehin keinen Raum.

Die Gretchenfrage: „Zentral oder dezentral?“ entstand als Artefakt einer öffentlichen Debatte, weil sie zu Positionierungen einlud, ohne Sachkenntnis zu verlangen. Den Anschein überragender Bedeutung erlangte sie zum einen durch die im Nachhinein ungeschickt wirkende Ankündigung von PEPP-PT, den technischen Datenschutz in den Mittelpunkt zu rücken, zum anderen durch das eigennützige Handeln einiger Beteiligter. Während PEPP-PT im Laufe seiner Entwicklungsarbeit offenbar das Problem und den Lösungsraum besser verstand und sich vom dezentralen Extrem verabschiedete, spitzten dreihundert Professoren die ohnehin zu enge Fokussierung auf technischen Datenschutz noch zu. Als ginge es darum, unter idealisierten Voraussetzungen zwischen zwei einander widersprechenden Hypothesen die richtigere auszuwählen, konstruierten sie ein Entweder-Oder zwischen zentral und dezentral und gaben sogleich ohne Experiment die Antwort, selbstverständlich müsse es dezentral sein. Unterdessen sprangen Apple und Google auf den bereits abfahrenden Zug auf und präsentieren sich seither so geschickt als Retter der Privatsphäre, dass sogar Margrethe Vestager darauf hereinfällt und galant darüber hinwegsieht, wie das Duopol seine Plattform-Macht ausspielt.

Welche Erfolgsaussichten die Kontaktverfolgung per Smartphone und Bluetooth insgesamt hat, bleibt unabhängig von der technischen Architektur vorerst unklar. Setzt man diese Idee jedoch um, und sei es nur als Experiment, sollte man sich dabei um die bestmögliche Lösung bemühen. Was eine Lösung gut oder weniger gut macht, bestimmt dabei nicht ein zentrales technisches Detail, sondern der reale Nutzen im Anwendungskontext.

Für zentrale Elemente wie in Großbritannien spricht einiges. Erstens ist eine komplett dezentrale Architektur ohnehin nicht realistisch. Zum einen braucht man selbst bei Datenspeicherung auf den Endgeräten irgendeine zentrale Instanz zur Nachrichtenverteilung und Koordination, wenn man zugleich jede Datensammlung anonym halten und nicht Adressen wie zum Beispiel Telefonnummer für die spätere Benachrichtigung speichern möchte. Zum anderen gehören zu den verwendeten Plattformen unvermeidlich zentrale Instanzen wie Appstores und Telemetrie. Ausgehend von einem Aluhut-Bedrohungsmodell können sich Nutzerinnen und Nutzer in solch einer Umgebung sowieso auf keine Eigenschaft einer App verlassen, denn jederzeit könnte eine neue Version automatisch installiert werden, die alles ganz anders macht.

Zweitens gehören Feedbackmechanismen heute zum Stand der Technik. Seit Software nicht mehr auf Datenträgern in Pappschachteln, sondern online vertrieben und auf vernetzten Geräten benutzt wird, haben Entwickler die Möglichkeit, Telemetriedaten aus der Software selbst sowie Nutzerfeedback unmittelbar zu erhalten und auszuwerten. Das erleichtert und beschleunigt die Fehleerkennung und -behebung sowie die Weiterentwicklung enorm und erlaubt sogar interaktive Experimente mit realen Benutzerinnen und Benutzern. Beim Einsatz einer noch wenig getesteten Technologie sind Feedbackmechanismen besonders wichtig, denn sehr wahrscheinlich erlebt man Überraschungen und muss unerwartete Probleme lösen. Eine letztlich experimentelle App im Zuge der Pandemiebekämpfung einfach herauszugeben und dann sich selbst zu überlassen, wäre grob fahrlässig, zumal über das neue Coronavirus noch zu wenig bekannt ist.

Drittens kollidieren Anforderungen aus dem Anwendungskontext mit extremistischen Datenschutzkonzepten. Die Kontaktverfolgung ist kein belang- und folgenloses Smartphonespiel wie Pokémon Go, sondern sie soll reale Konsequenzen haben. Beim herkömmlichen Vorgehen gehören zu diesen Konsequenzen Quarantäneanordnungen der Gesundheitsämter. Solche Anordnungen benötigen einen Adressaten und im Rechtsstaat müssen sie auch begründet sein, um ggf. einer gerichtlichen Prüfung standzuhalten. Im Sozialstaat ist darüber hinaus geregelt, wer welchen Teil der Lasten trägt und wie beispielsweise eine quarantänebedingte Arbeitsunfähigkeit abgefedert wird. Die Verfechter eines dezentral-anonymen Ansatzes haben bis heute keine Vorschläge unterbreitet, wie das eine oder das andere funktionieren soll. Weder können die Gesundheitsämter damit irgend etwas durchsetzen, noch erhalten Betroffene eine ausreichende Begründung oder gar eine Bescheinigung zur Vorlage bei Vertragspartnern und öffentlichen Stellen.

Viertens drängen sich Nebenfunktionen einer für den Masseneinsatz bestimmten App geradezu auf. Eine offensichtliche ist die Erfassung statistischer Daten, um den Gesundheitsbehörden ein klareres Bild des Pandemieverlaufs zu vermitteln. Dazu muss man doch wieder Daten an eine zentrale Stelle übermitteln und es kann gut sein, dass sich dann aus einem integrierten Ansatz schnell Synergieeffekte ergeben.

In Großbritannien hat man sich offenbar mit den Anforderungen der Anwendung auseinandergesetzt, während Deutschland kontextarm über Technik stritt. Dort möchte man zum Beispiel besonders gute Virenverteiler anonym ausfindig machen und darauf Risikoeinschätzungen stützen. Ob das funktionieren kann, wird sich zeigen; um eine an der Oberfläche nicht offensichtliche Idee handelt es sich allemal. Ein zentralerer Ansatz ist auch nicht automatisch ein Zeichen für Nachlässigkeit oder Primitivität der Implementierung, er kann für alle realistischen Belange einen gleichermaßen effektiven Datenschutz gewähren. Nur eines haben die Briten ebenso versäumt wie die Bundesregierung: die entwickelte Technik rechtlich und organisatorisch mit vertrauensbildenden Maßnahmen zu flankieren. Ich wünsche ihnen dennoch viel Erfolg. Schneller fertig werden sie schon mal, wie auch einige andere Länder, die dem dezentralen Extremismus eine Absage erteilten.

Privacy by Design or Poor Requirements Engineering?

Privacy – or security or any other desirable, ethereal property – by design sounds like a great thing to do. Alas, design is complicated and hard to guide or control as a process. One common misunderstanding has become obvious in current efforts to develop and deploy contact tracing technology contributing to epidemic control. Some of these efforts such as DP^3T, TCN, or Apple’s & Google’s announcement promote privacy to the top of their list of objectives and requirements. This is wrong. It would be appropriate in an R&D project developing experimental technology, but contact tracing is an actual, real-world application and must fulfill real-world requirements. Premature optimization for technical privacy protection does not help its cause.

First and foremost, an application needs to support a basic set of use cases and provide the necessary functions in such a way that the overall approach makes sense as a solution of the given problem(s). For contact tracing, essential use cases include:

  • contact identification,
  • contact listing, and
  • contact follow-up.

In addition, any large-scale application of contract tracing needs to support:

  • safeguards against abuse, and
  • monitoring and governance.

Each use case entails requirements. Contact identification must be sufficiently reliable and comprehensive; it must also take place quickly after an infection has been detected. Contact listing needs some form of risk assessment, a method to notify contacts, and a way to justify mandatory quarantine requests. Contact follow-up needs some idea how and when to interact with listed contacts. Underlying the whole design must be some conception of which contacts matter, what an identified contact implies, what to do with or require from identified contact persons, and what to achieve through contact tracing. There needs to be some definition of success and failure for the system and individual cases, and some monitoring of how well the system operates. One also has to think about possible abuses and misuses of the system such as evasion, manipulation, or exploitation, and find ways to prevent them or to deal with them when they occur.

Such questions are to be answered in the high-level design of a contact tracing system. They can and should be pondered at the level of paper prototypes, forcing developers to get specific but allowing quick modification and user testing. Technology has to be considered at this point primarily as a constraint: What is realistically possible or available and would the design be feasible to implement? However, some fundamental design decisions have to be made at this level after evaluating alternatives, for example, which parts of the system to automate and which ones to leave to humans, or which technologies, platforms, and devices to consider and use.

Like any design process, this high-level system design may take any number of iterations before converging toward something that might work when implemented. New questions will likely come up in the process. If, for example, the system is to leave tracing to humans, how much time can they spend per case, how many of them will be needed, how will they work, and which types of data and support would really help them?

Secondary requirements like performance or privacy can and should already be considered at this stage. Privacy by design means just that, to consider privacy protection as dimensions of the design spaces from the beginning on. However, privacy is a dependent design dimension and like all other requirements it is subject to trade-offs. Dependent means that any design decision can affect the privacy properties of a system. One cannot delegate privacy to a system component or function that would take care of it comprehensively regardless of the design of any other aspect of the system. Trade-offs occur when once has to choose between design alternatives; each option will likely have some advantages over the others but also some disadvantages, so that one has to compromise and keep a balance.

Misunderstanding privacy by design as privacy technology über alles, demonstrated by current proposals for privacy-preserving contact tracing, is a recipe for disaster. Starting with perfect technical privacy protection as the primary requirement constitutes a premature optimization that de-prioritizes all other requirements and design dimensions, delays important design decisions while arbitrarily constraining them without impact assessment, and prevents well-considered trade-offs from being made. The most likely result is a system that performs well at most in the privacy dimension, reflecting the priorities of its designers.

As a symptom, none of the proposals for privacy-preserving contact tracing has yet answered question like the following: How does it assure the reliability of the data it collects or produces? Which failure modes and error rates does it produce? How is the system to be monitored for problems and abuses? In which institutional framework is it designed to operate? How does it distribute responsibilities between involved parties? How are outputs of the system to be interpreted and used in the real world, which consequences should they have and which ones are not desirable? How can its operation become transparent for its users? Should participation be mandatory or voluntary and how can the design be optimized for either case? If participation is mandatory, how would this be enforced, how can the system be made universally accessible for everyone, and how may people evade it? If voluntary, which incentives does the system create and which features let users trust or distrust the system? Such questions need to be discussed and addressed long before the technical minutiae of data protection.

Placing technical privacy protection in the center of attention can make sense in a research project, where one develops new technology to evaluate its properties and capabilities. The stakes are low in such a project, where the results are prototypes and research papers. Developing a real-world system, especially one to be used at the intended scale of contact tracing apps, requires a broader perspective and comprehensive requirements analysis.


P.S. (2020-04-18): Government Digital Services of Singapore with their TraceTogether app apparently got their requirements analysis and design process right:

One thing that sets TraceTogether apart from most private efforts to build a Bluetooth contact tracer, is that we have been working closely with the public health authorities from day 1. (…) The team has shadowed actual real-life contact tracers in order to empathise with their challenges.

P.S. (2020-04-19): The closest to a requirements document I have seen so far is this: Mobile applications to support contact tracing in the EU’s fight against COVID-19,  Common EU Toolbox for Member States (via).

P.S. (2020-04-22): The Ada Lovelace Institute published a quick evidence review report titled: Exit through the App Store? A rapid evidence review on the technical considerations and societal implications of using technology to transition from the COVID-19 crisis, which makes a number of reasonable recommendations.

 

Digitalfeindliche Hetze

Gegen alles Digitale kann man in Deutschland ungestört hetzen, zumal unter dem Deckmantel der Sicherheit. Eines der beliebtesten Opfer neben dem Internet: die Kartenzahlung, die sich nun langsam doch auch in Deutschland durchsetzt. In welchem Maße dies auf die Deckelung der Transaktionsgebühren durch die EU zurückgeht, auf die zunehmende Verbreitung NFC-fähiger Karten zum bequemen kontaktlosen Bezahlen auch kleinster Beträge oder schlicht darauf, dass zu guter Letzt auch die Deutschen langsam in der Moderne ankommen, sei dahingestellt. Doch einige meinen immer noch, man hätte nie von den Bäumen herunterkommen oder noch besser, nie die Ozeane verlassen sollen. Ihre Geheimwaffe: Sicherheitsbedenken, denn die lassen sich zumindest in den Augen von Laien kurzfristig schwer ausräumen.

Der SWR demonstriert diese Masche am Beispiel der NFC-fähigen Kredit- und Debitkarten, die heute fast jeder besitzt:

Im Wesentlichen demonstriert dieser Beitrag, dass kontaktloses Bezahlen kontaktlos funktioniert, sowie dass die Infrastruktur dafür günstig zu haben und überall einsetzbar ist. Um sich vor Fernsehteams auf der Jagd nach Sensationen zu schützen, so empfiehlt der Beitrag am Ende, sollen wir unsere praktischen Karten kastrieren, indem wir sie umständlich in Schutzhüllen packen oder die NFC-Funktion gleich komplett deaktivieren lassen.

Wie bei solchen Skandalisierungsversuchen üblich, drückt sich der Beitrag um jede Risikobetrachtung. Das hatte so ähnlich ein gutes Jahr zuvor schon das Fachmagazin c’t versucht, musste jedoch bald zurückrudern. Wie der Anbieter des dort verwendeten mobilen Bezahlterminals zu recht betonte, wurde dort wie auch nun im Fernsehbeitrag des SWR lediglich ein technischer Transaktionsvorgang nachgewiesen, nicht jedoch ein erfolgreicher Geldtransfer zum Täter, der ohne Identifizierung desselben sowie ohne Eingriffsmöglichkeiten in dessen Handeln kaum zu bewerkstelligen wäre.

In der Gesamtschau begrenzen mehrere Mechanismen und Entwurfsmerkmale das Risiko kontaktloser Zahlungskarten:

  1. Zahlungen erfordern physische Nähe zwischen Terminal und Karte. Dies begrenzt die Zahl der effektiven Versuche, die ein Täter pro Zeiteinheit machen kann, sowie die Zahl der Angriffe, denen ein Karteninhaber ausgesetzt ist.
  2. Für Transaktionen ohne PIN-EIngabe sind der Betrag pro Transaktion wie auch die Zahl der aufeinanderfolgenden Transaktionen und deren Gesamtbetrag beschränkt. Selbst wer sich dauerhaft in der Nähe seines Opfers aufhielte, könnte nicht beliebig viele, beliebig hohe Transaktionen auslösen.
  3. Es handelt sich um Buchgeldtransaktionen, die nachvollzogen und nötigenfalls auch rückgängig gemacht werden können. Um an Bargeld zu kommen, müsste der Täter nicht nur Transaktionen auslösen, sondern auch über das resultierende Guthaben auf einem Konto frei und ohne Risiko verfügen können.

Unabhängig davon muss man sich auch noch die Geschäftsbedingungen der Bank anschauen und die darin festgelegten Haftungsregeln berücksichtigen. Selbst ein technisch erfolgreicher Angriff bliebe für Karteninhaber folgenlos, wenn sie Schadenersatzansprüche gegen ihre Bank geltend machen könnten.

All diese verschweigt der SWR-Beitrag. Er demonstriert lediglich einen technischen Vorgang, der Journalisten auf den ersten Blick überraschen mag. Hätten sie gründlich recherchiert, statt nur einen Wichtigtuer für eine telegene Vorführung zu suchen, hätte ihnen das sicher jemand erläutert. Weil sie das anscheinend nicht getan haben, handelt es sich um digitalfeindliche Hetze – oder doch nur um schlechten Journalismus?

Schnapsidee: Falschfahrerwarnung als Werbegag in der Radio-App

Der Radiosender Antenne Bayern hat sich von Bosch einen Werbegag für seine App bauen lassen und mir stehen die Haare zu Berge. Es handelt sich um eine neue Funktion in der App des Senders, eine Falschfahrerwarnung. Das noble Ziel: „Keine Verkehrstoten mehr durch Falschfahrer“, doch der Weg erscheint fragwürdig.

Die Warnfunktion besteht offenbar aus zwei Teilen. Der eine erkennt Falschfahrten daran, dass sich eine aktive Instanz der App in der falschen Richtung durch eine Autobahnauffahrt bewegt, und meldet dieses Ereignis an einen Clouddienst. Der andere empfängt Warnmeldungen und gibt sie aus. Nach eigenen Angaben hat man dabei auch an den Datenschutz gedacht. Technisch ist das so weit plausibel und den Datenschutz glaube ich einfach mal ohne Prüfung. Wenig Sinn ergibt jedoch das Konzept insgesamt, wenn als übliche Anforderungen an einen Sicherheitsmechanismus erstens Verlässlichkeit verlangt und zweitens die Anpassung der Technik an den Menschen.

Die Verlässlichkeit scheitert daran, dass sie Warnfunktion in einer Radio-App steckt. Erkannt werden nur Falschfahrer, welche die App benutzen und die Funktion aktiviert haben, gewarnt ebenso nur Nutzer der App mit aktivierter Warnfunktion. Laut den Mediadaten für Antenne Bayern hat die App im Monat knapp 300.000 „Unique User“. Das entspricht etwa der Einwohnerzahl von Bayerns drittgrößter Stadt Augsburg oder weniger als 2,5% der bayerischen Bevölkerung. Gehört ein Geisterfahrer nicht zu dieser Minderheit, warnt auch niemand vor ihm. Nach Angaben von Bosch steckt die Funktion noch in einigen anderen Apps, aber das ändert nichts am grundlegenden Problem, dass Entertainment-Apps kein guter Träger für Sicherheitsfunktionen sind.

Selbst wenn die Warnfunktion auf jedem bayerischen Mobiltelefon aktiv wäre, übersähe sie immer noch ausgerechnet ortsunkundige Auswärtige sowie jeden, der das Telefon zu Hause ließe, dessen Akkuladung zur Neige ginge oder der im Funkloch geisterführe. Umgekehrt hätten Bayern auswärts wenig von der Warnfunktion, nähmen sie per App zwar ihren Lieblingssender mit, begegneten jedoch in der Fremde falschfahrenden Saupreißn ohne App. Man müsste schon gewaltiges Glück in einem nicht sehr wahrscheinlichen Unglück haben, um aus der App überhaupt jemals eine gerechtfertigte und spezifische Warnung zu erhalten.

Nicht verlässlich scheint die App auch im Hinblick auf die Abdeckung relevanter Gefahrensituationen. Geisterfahrer im engeren Sinne können überall auftreten und zur Gefahr werden, wo Straßen getrennte Richtungsfahrbahnen haben und hohe Geschwindigkeiten gefahren werden. Laut Beschreibung erfasst die App nur Autobahnen und lässt damit Bundesstraßen und andere autobahnähnliche Schnellstraßen unberücksichtigt. Darüber hinaus würde mich interessieren, wie das System mit ausgedehnten und unkonventionellen Falschfahrten umgeht. Bei mir vor der Haustür schaffte ein betrunkener Lkw-Fahrer vor einem Jahr eine Geisterfahrt von einem Rastplatz über 21 Kilometer und ein Autobahnkreuz, bevor er gestoppt wurde. Wer nur Auffahrten überwacht, müsste sehr großflächig vor der Gefahr warnen, um alle Betroffenen erreichen zu können.

Unklar bleibt aus der kurzen Erläuterung, wie hoch das Risiko von Fehlwarnungen ist. Merkt es die App oder die Cloud dahinter, wenn etwa ein Bauarbeiter Antenne Bayern hört und sich bei der Arbeit falsch herum durch eine Autobahnabfahrt bewegt? Oder ein Autofahrer, der eine Panne hat und mit dem Händi in der Tasche ordnungsgemäß das Warndreieck aufstellt? Und wie steht es um Manipulationsmöglichkeiten? Was passiert, wenn jemand mit aktiver App in der falschen Richtung neben der Abfahrt herläuft? Wie ist der Clouddienst gegen das Einspeisen falscher Daten aus anderen Quellen als der echten App geschützt?

Daneben stellen sich bei einer solchen Funktion Fragen der benutzergerechten Gestaltung. Falls die App verlässlich warnen könnte, so müsste sie den betroffenen Fahrern – dem Geisterfahrer sowie jenen, denen er entgegenkommt – eine wirksame Warnung übermitteln. Da Geisterfahrten selten sind, wird es sich in der Regel um die erste Warnung dieser Art handeln, die der Fahrer erhält, und dann bleibt keine Zeit zum Nachdenken.

Unter diesen Umständen kommt eigentlich nur eine akustische Warnung mit einer direkten Handlungsanweisung in Frage. Vorbilder dafür liefert jedes moderne Flugzeugcockpit in unmittelbaren Gefahrensituationen. So warnt das Ground Proximity Warning System (GPWS) vor bevorstehendem Bodenkontakt und das Traffic Alert and Collision Avoidance System (TCAS) vor Zusammenstößen mit anderen Flugzeugen. Beide Systeme sagen den Piloten in knappen Worten, was sie tun sollen, denn für alles andere ist keine Zeit. Im Falle des TCAS wird die Anweisung zudem mit dem anderen Flugzeug koordiniert, so dass die Piloten des einen Flugzeugs zum Steigen und die anderen zum Sinken aufgefordert werden. Piloten werden zudem darauf trainiert, mit diesen Warnungen richtig umzugehen. Demgegenüber lenkt eine App auf dem Händi mit einer ungewohnten Warnung eher ab als dass sie hülfe und auf eine situationsabhängige Ausweichanweisung hoffen Betroffene wohl vergebens.

Im Auto und erst recht in einer Radio-App muss man sich außerdem noch Gedanken darüber machen, wie man wirklich wichtige Informationen aus dem Geplapper der Radiomoderatoren, des Navigationsgeräts oder des E-Mail-und-Kurznachrichtenvorlesers heraushebt. Vielleicht ist der Sprachkanal dann doch keine gute Wahl und es wäre besser, den entgegenkommenden Geisterfahrer im Head-Up-Display mit einem größer werdenden roten Punkt zu markieren.

In der vorliegenden Form ist die Falschfahrerwarnung in der Radio-App nichts weiter als ein Werbegag und daran änderte sich wenig, machten möglichst viele Menschen in Bayern mit, wie es sich der Sender wünscht. Eine sinnvolle Warnfunktion müsste Falschfahrten überall verlässlich, aber ohne Fehlarme und Manipulationsmöglichkeiten erkennen und in Gefahrensituationen verbal spezifische, umsetzbare Anweisungen zur Gefahrenabwehr geben. Dazu müsste sie zwingend in die Fahrzeugelektronik integriert sein – Hersteller Bosch sieht dies anscheinend als Alternative zum Smartphone vor – und zur Detektion von Falschfahrten auf absehbare Zeit zusätzlich auf Sensoren außerhalb der Fahrzeuge zurückgreifen. Wäre man darauf nicht angewiesen, könnte man gleich das Entwurfsziel ändern und überlegen, wie man Falschfahrer rechtzeitig stoppt, statt vor ihnen zu warnen.