Archiv der Kategorie: Anforderungen – Requirements

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.

Datenschutzzirkus

Schwerin, Marienplatz. Öffentlicher Raum. Kein Ort der Heimlichkeit und der Privatheit. Was hier geschieht, kann jeder sehen. So auch die Polizei, die den Platz mit Hilfe von Videokameras beobachtet. Daran regt sich Kritik: die Aufnahmen werden unverschlüsselt übermittelt.

Die ersten Idee zu einem Recht auf „Privacy“ – Ungestörtheit in einer individuellen Privatsphäre – verdanken wir dem Aufkommen der Fotografie sowie der Presse. Diese damals neue Entwicklung motivierte Samuel Warren und Louis Brandeis 1890 zu ihrem Essay „The Right to Privacy”, der als Wurzel aller nachfolgenden Diskussionen über die Privatsphäre und später über den Datenschutz gilt.

Hundert Jahre später erregte die „Videoüberwachung“ – die Aufnahme, Übertragung und Aufzeichnung von Bewegtbildern insbesondere für polizeiliche und verwandte Zwecke – den Zorn aller Datenschutzaktivisten und daran hat sich bis heute wenig geändert. Aus der Sicht eines Datenschutzaktivisten gehören Videokameras im öffentlichen Raum zu den schlimmsten Dingen, die uns dort begegnen können. Dies gelte sogar für eine bloße Anscheinsüberwachung durch Kameraattrappen, meinen sie, denn Ausgangspunkt ihrer Kritik ist die selten hinterfragte These, selbst eine nur scheinbare Möglichkeit der Fernbeobachtung oder Aufzeichnung verändere auf wundersame Weise das Verhalten der Beobachteten1.

Mit der Realität hat dies wenig zu tun. Wir sind heute allerorten von Kameras umgeben, allen voran jene in unseren Taschenkommunikatoren, gefolgt von anderen Kameras, die zu allerlei Zwecken in der Landschaft hängen. Von nahezu jedem Ereignis mit Nachrichtenwert taucht früher oder später mindestens ein verwackeltes Händivideo auf. Die Erwartung, sich noch irgendwo in der Öffentlichkeit, jedoch nicht vor einem Kameraobjektiv aufhalten zu können, ist absurd.

Ebenso absurd ist die Vorstellung, die allgegenwärtigen Kameras könnten uns manipulieren und unterdrücken. Wäre dem so, hätten wir es nämlich längst bemerkt. Haben wir aber nicht, also stimmt die Vermutung wahrscheinlich nicht. In Wirklichkeit tun Kameras im öffentlichen Raum niemandem weh, denn sie sehen nur das, was Menschen in aller Öffentlichkeit tun.

Mit Ausnahme der Datenschützer versteht das auch jeder und so regt sich zu Recht kaum noch Protest gegen den Kameraeinsatz. Doch so leicht geben sich Aktivisten nicht geschlagen. Für Datenschützer nimmt eine Kamera nicht nur Bilder und Videos auf, sie verwandelt auch den Anblick eines öffentlichen Raums in personenbezogene Daten, die nach Schutz verlangen.

Ob diese Daten aus einer öffentlichen Quelle stammen, spielt dabei keine Rolle, denn alle personenbezogenen Daten gelten dem Datenschutz als gleich schützenswert (mit Ausnahme der besonders schützenswerten Daten, zu denen etwa die Information gehört, dass der Papst und seine Kardinäle katholisch sind). So kommt es, dass Aufnahmen aus dem öffentlichen Raum nach Auffassung der Datenschützer verschlüsselt versendet werden müssen.

Dass dies sinnlos ist und niemanden vor irgend etwas schützt, spielt keine Rolle, denn der Datenschutz schützt Daten und nicht Menschen. Der Sensor einer Digitalkamera verwandelt ungezwungene Öffentlichkeit in ein amtliches Geheimnis.


1 Gedankenexperiment: Jemand geht in eine Bank/Spielhalle/Tankstelle, hält eine Videokamera vor sich und ruft: „Geld her, ich habe eine Kamera!“ – Würde das funktionieren? Wenn ja, warum? Wenn nein, warum nicht?

Sicherheitstechnik gehört nicht ins Gesetz

Die SPD-Bundestagsfraktion hat ein Positionspapier zum IT-Sicherheitsgesetz 2.0 beschlossen. Da stehen einige sinnvolle Forderungen drin, etwa nach Verbesserungen im Opferschutz und bei den zuständigen Behörden. Andere sind Blödsinn, allen voran jene nach einer Verpflichtung von Dienstanbietern zu spezifischen Sicherheitsmaßnahmen wie 2-Faktor-Authentisierung.

Sicherheit sei kein Zustand, lautet ein geflügeltes Wort, sondern ein Prozess. Dies gilt nicht nur für den Betrieb von IT-Systemen, sondern auch für ihre Entwicklung und Gestaltung. Konkrete Ausprägungen von Sicherheitsfunktionen stehen am Ende einer langen Folge von Entwurfsentscheidungen.

Viele dieser Entscheidungen sind das Resultat von Abwägungen zwischen verschiedenen Entwurfszielen auf verschiedenen Gebieten, zum Beispiel Funktionalität, Usability und Usability. Noch mehr Entscheidungen treffen gar nicht die Entwickler selbst, sondern der Markt und der Stand der Technik, der sich ständig weiterentwickelt.

In diesem Kontext einen sinnvollen und lange haltbaren Fixpunkt zu setzen, ist schwierig, und Politiker sind für diese Aufgabe noch weniger qualifiziert als jene, die wenigstens das Problem verstehen. Die besten Lösungen entstehen vielmehr durch fortwährende Evolution.

Ein Beispiel: Die URL-Zeile im Webbrowser begann ihre Karriere vor mehr als einem Vierteljahrhundert als einfaches Eingabefeld für Web-Adressen. Im Laufe der Zeit stellte sich heraus, dass gefälschte Websites für allerlei Angriffe benutzt werden können und man daher gut daran tut, die Benutzer eines Browsers so gut wie möglich bei der Erkennung solcher Täuschungsversuche zu unterstützen.

Dabei müssen gleichzeitig andere Ziele berücksichtigt werden, wenn die URL-Zeile dient weiterhin auch ihrem ursprünglichen Zweck. Über die Jahre haben die Browser-Entwickler gelernt, auf welche Einzelheiten es ankommt und wie man die verschiedenen Ziele gut unter einen Hut bekommt, und daraus Empfehlungen formuliert.

Diese Empfehlungen repräsentieren den aktuellen Stand; die Entwicklung wird weitergehen, die Anforderungen werden sich ändern und man wird für neue Aspekte des Problems neue Lösungen finden. Evolution eben. „Security by Design“ klingt zwar gut, aber Design ist nichts anderes als forcierte Evolution.

Spezifische Entwurfsvorgaben von Gesetzesrang grenzen diese Evolution willkürlich ein. Sie machen aus einem Lern- und Innovationsproblem eine Compliancefrage und eine bürokratische Angelegenheit. Damit erreichen sie genau das Gegenteil des Gewollten: Die Sicherheit erhöht sich nicht, sondern alle sind nur noch damit beschäftigt, gesetzliche Vorgaben einzuhalten, seien sie nun sinnvoll oder nicht.

Tatsächlich ist liegt simple 2-Faktor-Authentisierung alleine sogar schon hinter dem Stand der Technik. Wer sich moderne, das heißt nichtdeutsche Websites oder gar „die Cloud“ anschaut, findet dort ausgefeilte Systeme zum Identitäts- und Rechtemanagement, in denen die unmittelbare Benutzerauthentisierung nur ein Baustein ist.

Einige andere Bausteine sind an der Benutzerschnittstelle zum Beispiel die Verwaltung von Clientgeräten (Funktionen wie: „Alle angemeldeten Geräte abmelden“), Benachrichtigungsfunktionen („Jemand hat Ihr Passwort dreizehnmal falsch eingegeben.“), die Nichtbehinderung von Passwortmanagern sowie Recovery-Funktionen, mit denen Benutzer in verschiedenen Situationen (Passwort vergessen, gehackt, E-Mail-Adresse verändert) wieder Zugang zu ihrem Account bekommen. All diese Bausteine sind sicherheitsrelevant und jeder von ihnen sowie ihr Zusammenspiel unterliegt ebenso wie die Gestaltung der URL-Zeile im Browser der fortlaufenden Evolution.

Gesetzestexte können schon die statische Komplexität des Themas nicht fassen, von der Weiterentwicklung gar nicht zu reden. Konkrete gesetzliche Vorgaben zur Gestaltung von Authentisierungsfunktionen wären schon bei Inkrafttreten des Gesetzes veraltet oder unvollständig. Sogar als rein wirtschaftlich motivierte Marktregulierung taugt der Ansatz wenig: Ausgerechnet heimische Anbieter wie GMX und Web.de tun sich schwer mit der Zwei-Faktor-Authentisierung, während sie bei den Großen aus Amerika längst Standard ist. Ganz ohne Gesetz übrigens.

Ich wäre der Politik dankbar, wenn sie sich auf das Formulieren von User Stories* beschränken und die Technik den ITlern überlassen würden. Glauben Sie mir, meine Damen und Herren, und das möchte ich hier in aller Deutlichkeit betonen: Es ist besser so. Wer die Evolution der Technik wirklich beeinflussen möchte, sollte das indirekt über die Anreize tun.


*) Eigentlich: Anforderungen, aber die Erklärung, warum Lösungsvorschläge schlechte Anforderungen sind, wäre mir hier zu lang geworden.

 

PS: Jemand hat mir dieses Video zum Thema zugespielt, das ich nachträglich im Text mit verlinkt habe.

Erfolgsfaktoren für den Datenschutz durch Technikgestaltung

Die Forderung nach Datenschutz und Sicherheit „by Design“ ist schnell erhoben und gerade nach Sicherheitsvorfällen sieht rückblickend oft alles nach offensichtlicher Schlamperei aus, die man doch einfach hätte vermeiden können. Wer tatsächlich IT-Systeme gestaltet und dabei Datenschutz- und Sicherheitsanforderungen berücksichtigen soll, steht jedoch einigen Problemen gegenüber. Zum Beispiel kann man zu viel Sicherheit anstreben und sich im Ergebnis selbst blockieren, wie es die Entwicklung der Gesundheitstelematik seit ungefähr anderthalb Jahrzehnten vorführt*, oder vor unmöglichen Entscheidungen stehen, weil es zu vielfältigen Wechselwirkungen zwischen Datenschutz und Sicherheit auf der einen und allen übrigen Anforderungen und Entwurfsdimensionen auf der anderen Seite kommt. Beim Datenschutz kommt hinzu, dass anders als bei der Sicherheit Stakeholder und Angreifer zusammenfallen: Der Datenschutz beschränkt Handlungen, von denen Betreiber und Nutzer eines Systems profitieren.

Mit diesen Schwierigkeiten beschäftigt sich der Beitrag „Erfolgsfaktoren für den Datenschutz durch Technikgestaltung“ zur Konferenz „Die Fortentwicklung des Datenschutzes”, die Anfang November 2017 in Berlin stattfand. Er baut auf vorangegangenen Vorträgen (Was kommt nach „Security by Design“? Chancen der Partizipation im Software Engineering 2016 in Kassel und Security by Design? 2017 in Limburg auf. Im Konferenzband zur Tagung konnte unser Beitrag letztlich nicht erscheinen, da der Verlag über eine faire Rechteübertragung hinaus unannehmbare Forderungen an die Autoren erhob und zu Verhandlungen über die Konditionen nicht bereit war.

*) Großprojekte mit vielen Stakeholdern haben allerdings noch weitere Probleme neben dem Thema Sicherheit, an denen sie scheitern können.

Beschränkter Horizont

Die Forderung nach Ende-zu-Ende-Sicherheit für das besondere elektronische Anwaltspostfach (beA) und andere Dienste geht auf missverstandene Anforderungen und eine eingeschränkte Sicht auf den Lösungsraum zurück. Die missverstandene Anforderung liegt in der Vorstellung, der rechtlicher Schutz der Kommunikation verlange nach technischen Garantien. Die eingeschränkte Sicht auf den Lösungsraum berücksichtigt nur ausgewählte technische Mechanismen, deren Wirkung sie überschätzt, und lässt andere Aspekte des Risikomanagements außer Acht.

✹✹✹

Die Befürworter der Ende-zu-Ende-Verschlüsselung argumentieren, der Schriftverkehr von Rechtsanwältinnen sei besonders sensibel und man müsse ihn deshalb technisch besonders gut vor unbefugter Kenntnisnahme schützen. Die besondere Sensibilität mag man annehmen, wenngleich das beA nicht der Kommunikation zwischen Anwältinnen und ihren Mandantinnen dient, sondern dem Schriftwechsel zwischen Anwältinnen und Gerichten sowie der Anwältinnen untereinander. Jedoch steht die Telekommunikation ganz allgemein unter rechtlichem Schutz durch das Telekommunikationsgeheimnis. Selbst wer sie abhören könnte, darf dies nicht und wird andernfalls verfolgt und bestraft.

Ein wirksamer rechtlicher Schutz macht kann technische Maßnahmen überflüssig machen. Umgekehrt sind individuelle Schutzmaßnahmen dort nötig, wo keine Hilfe zu erwarten ist. Im Alltag verstehen wir das auch und verzichten zum Beispiel meist darauf, unsere leicht verwundbaren Körper besonders gegen Angriffe zu schützen. Wir wissen, dass die Wahrscheinlichkeit eines körperlichen Angriffs gering ist, denn dafür sorgen Polizei und Justiz. Anders verhalten sich etwa Menschen in Kriegsgebieten, die mit solchem Schutz nicht rechnen können.Im Spektrum zwischen diesen Extremen gibt es Mischlösungen, deren Schwerpunkt auf der einen oder anderen Seite liegt. Das Ziel ist letztlich ein akzeptables Restrisiko, ganz gleich mit welchen Mitteln es erreicht wird.

Die Motivation für technische IT-Sicherheit entspringt der eingeschränkten Möglichkeit zur Strafverfolgung im Netz. Zwar gelten Gesetze auch online, doch können sich Täter leichter verstecken und selbst bekannte Täter entgehen der Verfolgung, wenn sie im Ausland sitzen. Ganz ohne Sicherheitstechnik wird ein Anwaltspostfach also nicht auskommen. Allerdings muss man sich sowohl den Schutzbedarf als auch die Sicherheitsstrategie genauer anschauen.

Interessanterweise haben Juristen in dieser Hinsicht realistischere Vorstellungen als Hacker, die perfekte Sicherheit fordern. Juristen gehen ganz selbstverständlich davon aus, dass man Sicherheitsanforderungen nicht überspitzen darf. Das Schutzniveau soll dem alternativer Kommunikationsmittel wie Telefax und Briefpost entsprechen. Auf ein theoretisches Ideal kommt es nicht an. Aus rechtlicher Sicht interessant sind dann rechtliche Implikationen, die sich beispielsweise aus der zeitversetzten Kommunikation ergeben.

Ende-zu-Ende-Verschlüsselung erfüllt keine reale Sicherheitsanforderung, sondern sie strebt ein technisch motiviertes theoretisches Ideal an. Wie ich im vorigen Beitrag erläutert habe, ist dieses theoretische Ideal im realen System kaum zu erreichen. Das ist jedoch kein Problem, da sich die realen Sicherheitsanforderungen am Sicherheitsniveau realer Kommunikationsmittel wie Post, Fax und Telefon orientieren.

✹✹✹

Den Lösungsraum verengt die Forderung nach Ende-zu-Ende-Sicherheit auf scheinbar ideale kryptografische Ansätze. Diese Ansätze sind jedoch nicht nur nicht sinnvoll, wenn man – im Gegensatz zur Gesundheits-Telematik – in endlicher Zeit ein funktionsfähiges System bauen möchte. Es gibt auch Alternativen und Aspekte, von denen die Fokussierung auf das theoretische Ideal ablenkt.

Die Befürworter der kryptografischen Ende-zu-Ende-Sicherheit kritisieren die Umschlüsselung von Nachrichten in einem Hardware-Sicherheitsmodul (HSM). Bei der Umschlüsselung wird eine Nachricht ent- und mit einem anderen Schlüssel verschlüsselt. Auf diese Weise lassen sich die Zugriffsrechte auf der Empfängerseite von der ursprünglichen Verschlüsselung auf der Absenderseite entkoppeln. So kann man Beispielsweise Vertretern Zugriff auf Nachrichten geben, die bereits vor Beginn der Vertretung vom Absender verschlüsselt wurden.

Dies schaffe einen Single Point of Failure, der das ganze System „extrem verwundbar“ mache, argumentieren die Kritiker. Das ist insofern richtig, als ein erfolgreicher Angriff auf die entsprechende Systemkomponente, ein Hardware-Sicherheitsmodul (HSM), tatsächlich sämtliche Kommunikation beträfe. Solche Angriffspunkte gäbe es freilich auch bei einer Ende-zu-Ende-Lösung noch. Alle Kommunikation ausspähen könnte beispielsweise, wer den beA-Nutzerinnen eine manipulierte Version der Software unterjubelt oder wer in die Produktion der zur Nutzung erforderlichen Smartcards eingreift.

Die damit verbundenen Restrisiken nehmen wir jedoch notgedrungen in Kauf und ergreifen Maßnahmen, um sie zu klein zu halten. So wird man beispielsweise die Smartcard-Produktion durch Zugangskontrollen und Überwachung so gut wie eben praktikabel vor unbefugten Eingriffen schützen. Nichts spricht grundsätzlich dagegen, dies auch für die Umschlüsselung zu tun – deswegen unter anderem das Sicherheitsmodul. Die Fokussierung auf das vermeintliche Allheilmittel Ende-zu-Ende-Verschlüsselung verstellt jedoch den Blick auf solche Maßnahmen, die zum Risikomanagement beitragen.

Falls wir in einem Single Point of Failure ein grundsätzliches Problem sähen und die damit verbundenen Risiken für nicht beherrschbar hielten, müssten wir jedoch nach ganz anderen Wegen Ausschau halten. Wir müssten dann nämlich nach einer organisatorischen und technischen Architektur suchen, welche die Auswirkungen eines einzelnen erfolgreichen Angriffs auf einen Teil des Systems, der Nutzer und der Inhalte begrenzt und verlässlich dafür sorgt, dass der Aufwand für erfolgreiche Angriffe proportional zu ihren Auswirkungen wächst.

Solche Ansätze hätten erst einmal überhaupt nichts mit Kryptografie zu tun, sondern mit Organisationsprinzipien. Man könnte beispielsweise ein Ökosystem verschiedener unabhängiger Lösungen und Anbieter schaffen und die Haftung angemessen regeln.  Angriffe auf einen Anbieter beträfen dann nur dessen Nutzer. Mit DE-Mail gibt es sogar bereits ein solches Ökosystem, welches weitgehend brachliegt und sich nach Anwendungen sehnt.

Auf solche Fragen und Ansätze – deren Nutzen und Notwendigkeit allerdings erst nach einer gründlichen Bedrohungs- und Risikoanalyse klar wird – kommt man gar nicht erst, wenn man eine Abkürzung nimmt und blind die Anwendung bestimmter technischer Entwurfsmuster fordert.

Mit Sicherheit ins Desaster

Als wäre das Desaster um das besondere elektronische Anwaltspostfach (beA) nicht schon schlimm genug, kommen nun auch noch Aktivisten aus ihren Löchern und fordern eine „echte Ende-zu-Ende-Verschlüsselung“.

Kann diesen Cypherpunks mal jemand das Handwerk legen? Eine „echte Ende-zu-Ende-Verschlüsselung“ ist für ein beA technisch eben nicht möglich, sondern als Anforderung das Rezept für ein Desaster.

Unter Laborbedingungen lässt sich gewiss ohne große Schwierigkeiten eine Public-Key-Infrastruktur (PKI) aufbauen und auf beliebig viele Teilnehmer skalieren, so dass jeder mit jedem verschlüsselt kommunizieren kann. So eine Labor-PKI löst aber nur das halbe Problem – und macht es schwer, die andere Hälfte zu lösen, die unter den idealisierten Bedingungen der Laborumgebung keine Rolle spielt.

Drei Teilprobleme, mit denen eine Lösung für die Anwaltskommunikation zurechtkommen muss, sind (1) komplizierte Zugriffsrechte, (2) der Konflikt zwischen Vertraulichkeit und Verfügbarkeit sowie (3) Veränderungen im Zeitverlauf.

  1. Komplizierte Zugriffsrechte
    Anwaltskommunikation ist nicht einfach Kommunikation von Person zu Person. Anwälte haben Gehilfen für administrative Tätigkeiten, die beispielsweise Post holen und verschicken. Diese Gehilfen brauchen ausreichende Zugriffsrechte, um ihre Arbeit zu verrichten, aber sie haben keine Prokura. Anwälte haben außerdem Vertreter für Urlaub, Krankheit usw., die von der Anwältin oder der Rechtsanwaltskammer bestellt werden. Alleine der Versuch, § 53 BRAO in eine PKI und eine Ende-zu-Ende-Verschlüsselung zu übersetzen, dürfte Entwicklern einiges Kopfzerbrechen bereiten.
  2. Vertraulichkeit vs. Verfügbarkeit
    Vertraulichkeit der Anwaltskommunikation ist wichtig, aber zweitrangig. Wichtiger ist die Verfügbarkeit. Fragen des Zugangs von Erklärungen und der Einhaltung von Fristen können einen Rechtsstreit unabhängig davon entscheiden, wer in der Sache eigentlich Recht hätte. Vor allem anderen werden Anwältinnen Wert darauf legen, dass sie unter allen Umständen verlässlich kommunizieren können. Demgegenüber genügt hinsichtlich der Vertraulichkeit oft das Schutzniveau „Telefon“.
  3. Zeitliche Dynamik
    Ein reales System zur Anwaltskommunikation muss nicht zu einem Zeitpunkt funktionieren, sondern über einen langen Zeitraum, währenddessen sich die Welt ändert. Das betrifft neben den offensichtlichen Aspekten – Hinzukommen und Ausscheiden von Nutzern in den verschiedenen Rollen, veränderte Vertretungsregelungen usw. – auch die Technik, zum Beispiel den Schlüsseltausch. Damit muss ein beA unter Berücksichtigung von (1) und (2) zurechtkommen. Darüber hinaus können sich auch gesetzliche Regelungen jederzeit ändern.

Wir brauchen deshalb keine Ende-zu-Ende-Sicherheit, sondern im Gegenteil endlich die Einsicht, dass Sicherheit:

  • sekundär ist und der Funktion nicht vorausgeht, sondern folgt,
  • keine theoretischen Ideale verfolgen, sondern reale Risiken reduzieren soll,
  • nicht durch formale Garantien und einzelne Wunderwaffen entsteht, sondern aus der Kombination verschiedener partieller Maßnahmen resultiert,
  • nicht perfekt sein muss, sondern nur gut genug.

Die Vorstellung, man könne konkurrenzfähige Anwendungen um starke Kryptographie herum konstruieren, ist vielfach gescheitert und diskreditiert. Als um die Jahrtausendwende der Online-Handel wuchs, entwickelte man kryptografische Bezahlverfahren von eCash bis SET – den Markt gewannen jedoch Lastschrift, Kreditkarte, Nachnahme und Rechnung. Das Online-Banking wollte man einst mit HBCI / FinTS sicher machen – heute banken wir im Browser oder auf dem Händi und autorisieren Transaktionen mit TANs und Apps. Das vor gut zwanzig Jahren entstandene Signaturgesetz ist in seiner ursprünglichen Form Geschichte und elektronische Signaturen haben sich bis heute nicht auf breiter Front durchgesetzt.

Wer dennoch weiter an die heile Scheinwelt der Ende-zu-Ende-Sicherheit glauben möchte, der möge sich seine Lösungen von den Experten der Gematik entwickeln lassen. Die kennen sich damit aus und sobald ihr Flughafen ihre Telematikinfrastruktur läuft, haben sie sicher Zeit für neue Projekte.

Vortrag: „Security by Design?“

Triggerwarnung: work in progress

Vergangene Woche durfte ich auf dem 1. IT-Grundschutztag 2017 zum Thema Security by Design? vortragen. Das Leitthema der Veranstaltung war Application Security und ich habe passend zu unserer Forschung einen Blick auf die Softwareentwicklung geworfen. Sichere Software ist leicht gefordert, aber die Umsetzung im Entwicklungsalltag bereitet Schwierigkeiten: In frühen Phasen der Entwicklung kämpft man mit Ungewissheit und es ist schwer, Entscheidungen zu treffen; später weiß man mehr, aber die Veränderung wird schwierig – nicht nur technisch, sondern auch in den Strukturen und Routinen des Entwicklerteams.

Der Vortrag entstand aus einer früheren Fassung, die ich gemeinsam mit Andreas Poller auf dem Workshop „Partizipatives Privacy by Design“ im vergangenen Oktober in Kassel gehalten habe. Aus Andreas’ Vortrag auf der CSCW’17 habe ich mir auch Slides geborgt.

Wer die Tonspur zu den Slides hören möchte: einfach fragen.