Sicherheit muss zweitrangig sein, sonst steht sie im Weg

Seit zwei Jahrzehnten träumt Deutschland erfolglos davon, die elektrische Regierung, staatsnahe Systeme wie die Gesundheitstelematik sowie das Internet überhaupt dadurch zu fördern, dass man generische Sicherheitsdienste amtlich entwickelt, standardisiert und reguliert. Sichtbare Zeichen dafür sind das Signaturgesetz, die Gesundheitskarte, DE-Mail sowie die eID-Funktion des Personalausweises.

Gut funktioniert hat das in keinem dieser Fälle. Die elektronische Signatur ist so wenig verbreitet, dass man ein darauf gestütztes Verfahren für den elektronischen Entgelt-Nachweis (ELENA) einstellen musste. Die Gesundheitskarte kann nach mehr als einer Dekade Entwicklungszeit – die Gründung der gematik liegt länger zurück als der erste Spatenstich für BER – kaum mehr als ihre Vorgängerin. De-Mail ist im Gegensatz zum Vorgänger eID noch nicht im Stadium der Ideenwettbewerbe angekommen, leidet jedoch unter vergleichbaren Akzeptanzproblemen.

Gemeinsam ist diesen Fällen der Versuch, eine generische Sicherheitstechnologie für eine Vielzahl noch unbekannter Anwendungen zu schaffen in der Annahme, diese Sicherheitstechnologie sei genau das, was den Anwendungen fehle. Beides ist falsch. Wer mit der Sicherheitstechnologie anfängt, macht den Entwurfsprozess kaputt und bekommt Design around Security statt Security by Design, und Anwendungen müssen zuerst funktioneren, bevor man beginnt, ihre Sicherheit zu optimieren.

Funktionieren bedeutet für eine Anwendung, dass sie ihrer Zielgruppe einen nützlichen Satz an Funktionen liefert und dabei schmerzfrei verwendbar ist. Alle anderen Ziele sind untergeordnet, Anwendungen müssen zuerst nützlich und benutzergerecht(*) sein. Der Weg dorthin ist oft steinig und in erfolgreichen Projekten in aller Regel iterativ und inkrementell unter Beteiligung der Nutzer und Stakeholder. Am grünen Tisch bekommt man höchstens Trivialanwendungen entwickelt, die es so ähnlich schon hundertfach existieren, und sebst da kann man sich über die Ähnlichkeit täuschen.

Wer mit der Sicherheit anfängt und zuerst Sicherheitsfunktionen an der Benutzerschnittstelle standardisiert, legt damit einen ganzen Zoo noch unbekannter Anwendungen auf eine Region des Entwurfsraums fest. Ob die jeweils optimalen Lösungen in dieser Region liegen, stellt sich erst später heraus; meistens tun sie es nicht. Das Scheitern daran ist nicht spezifisch für Staatsprojekte, fällt dort jedoch stärker auf. Staatliche Institutionen entziehen sich oft dem Markt, der untaugliche Angebote rigoros aussiebt.

Eine vergleichbare Entwicklung auf dem freien Markt spielte sich in den 1990er Jahren auf dem Gebiet der Online-Bezahlsysteme ab. Im jungen Online-Handel versuchten sich stark auf Sicherheit fokussierter Entwürfe von eCash bis SET zu etablieren. Wie wir heute wissen, setzten sich Kreditkarten und Paypal gegen Verfahren aus dem Kryprographielehrbuch durch. Das ist kein Zufall und keine Verschwörung, sondern die kryptografischen Verfahren waren insgesamt nicht gut genug, um den freien Wettstreit zu gewinnen.

Umgekehrt können sich generische Sicherheitsfunktionen im freien Wettbewerb auch durchsetzen, TLS ist ein Beispiel dafür. Dazu müssen sie jedoch nach und nach von immer mehr Anwendungsentwicklern akzeptiert werden, bis sie schließlich zum De-fakto-Standard geworden sind. Dies gelingt am besten, wenn die Sicherheitsfunktion den Entwurfsraum ihrer Anwendungen nicht wesentlich beschneidet; TLS erfüllt diese Bedingung, weil es keine Anwendungs-, sondern eine überall verfügbare Plattformfunktion ist.

Lässt man Anwendungsentwickler einfach ihre Arbeit tun, so bekommt man funktionierende Anwendungen, wie zum Beispiel das Auswärtige Amt mit seiner Online-Registrierung für die Krisenvorsorgeliste demonstriert. Deutsche, die ins Ausland reisen, können sich bei der zuständigen Auslandsvertretung registrieren lassen, was ihre Unterstützung in Krisensituationen erleichtert. Das geht auch online und das Verfahren funktioniert genau so, wie wir das von anderen Websites kennen – von eID und De-Mail und digitalen Signaturen keine Spur.

Zugegeben, diese Anwendung ist weniger komplex als die Gesundheitstelematik. Dennoch zeigt sich an solchen Beispielen, wie vorgegebene Sicherheitstechnik sinnvollen Entwicklungen im Weg stehen kann, wenn sie mehr ist als ein leicht zu ignorierendes Angebot. Wer eGovernment möchte, muss Anwendungen entwickeln und keine E-Mail- oder Anmeldefunktionen.

(Dies ist die Langfassung von https://plus.google.com/+SvenT%C3%BCrpe/posts/FWxfbri77Sb)

Advertisements

About Sven Türpe

Sven Türpe is a computer scientist. His current research focus is on security engineering methods, techniques, and tools. All opinions expressed in this blog are his own.