Hallo zusammen,
im Rahmen meiner Arbeit bei der FSFE habe ich mich mit dem Thema Freie Software im Bereich Banken beschäftigt und möchte meine Erfahrungen und Gedanken mit euch teilen. Das Thema ist Teil des größeren Themas der Appifizierung/des Drucks zur Verwendung unfreier Apps für bestimmte Interaktionen.
Mir persönlich fällt in den letzten Jahren auf, dass Banken sehr stark versuchen, ihre unfreien Apps für Bankgeschäfte selbst und auch für die so genannte Zwei-Faktor-Authentifizierung zu erfordern. Tatsächlich blockieren sie oft andere Authentifizierungsmethoden ganz. Das ist natürlich ein Problem für uns, und deshalb habe ich mich mit diesem Thema etwas genauer beschäftigt.
Das niederländische FSFE-Team hat hier einen wunderbaren Anfang gemacht, indem es eine Bank kontaktiert hat, um zu erfahren, warum sie es ihren Kunden erschwert, Freie Software zu benutzen. Meine Aufgabe war es, das Thema allgemeiner anzugehen. Leider war es sehr schwierig, direkt von Banken Antworten zu erhalten. Eine sehr häufige Rückmeldung war, dass es rechtliche Anforderungen gibt, die Dinge so zu tun, wie sie es tun, und dass die IT-Abteilungen vernünftige Entscheidungen getroffen hätten, die nicht zu sehr hinterfragt werden sollten.
Ein Grund, den die Banken manchmal anführten, war PSD2, eine EU-Richtlinie zur Regulierung von Zahlungsdiensten und Zahlungsdienstleistern. So wie ich es nach einigen Hintergrundrecherchen sehe, schreibt PSD2 offenbar keine genauen technischen Maßnahmen vor, auch nicht für den zweiten Faktor. So wie die Banken PSD2 interpretieren, bedeutet dies jedoch, dass sie die Authentifizierngs-Secrets an eine bestimmte Hardware binden müssen. Meiner Meinung nach ist diese Auslegung bereits das erste Problem für Freie Software, denn auch wenn dies keine rechtliche Anforderung ist, schließt es Zwei-Faktor-Lösungen wie TOTP aus, bei denen die Secrets auf mehreren Geräten verwendet oder einfach durch Verwendung einer entsprechenden TOTP-App extrahiert werden können.
Das zweite große Problem ist, wie Banken die Secrets an die Hardware binden: vollständig in Software. Dies macht es erforderlich, dass die Banking-Apps auf gerootete Telefone usw. prüfen, denn wenn ein Telefon gerootet ist, könnte das Secret theoretisch extrahiert werden. Die Root-Checks erfolgen in der Regel durch die Verwendung von Bibliotheken in den Apps, die Sicherheit auch in bösartigen Umgebungen versprechen, z.B. auf einem von Malware befallenen Telefon. Die Banken verlassen sich derzeit mehr auf solche Sicherheitsversprechen als auf tatsächliche Sicherheit, denn echte Sicherheit würde beispielsweise bedeuten, eine richtige Zwei-Faktor-Authentifizierung zu implementieren, statt zwei Apps auf demselben Telefon laufen zu lassen und dies Zwei-Faktor-Authentifizierung zu nennen.
In Kombination sind diese Probleme noch gravierender, da praktisch alle Banken das Verfahren so implementieren und es zu einer Art Best Practice geworden ist. Die Banken befürchten, dass sie bei einer anderen Vorgehensweise im Falle einer angeblich nicht autorisierten Transaktion haftbar gemacht werden könnten. Leider ist es, wie in anderen Bereichen auch, oft einfacher, das zu tun, was alle anderen tun, auch wenn es Schwächen hat, denn dann kann man sein Vorgehen wenigstens damit verteidigen, dass man sich an den "Standard" hält. Und in diesem Fall wird dadurch leider Freie Software eingeschränkt.
Eine Art Ausweg aus dieser Situation ist die Verwendung von Secure Elements in Telefonen. Durch deren Verwendung wären die Secrets tatsächlich an die Hardware gebunden. Das würde bedeuten, dass Freie Software das Secure Element ähnlich wie eine Smartcard nutzen könnte, indem wir es einfach nutzen, um eine Transaktion zu signieren. Dadurch wären Root-Checks und unfreie Apps nicht notwendig. Wie bei einer Smartcard würden jedoch in der Regel immer noch unfreie Schritte stattfinden, nur eben in Hardware. Auch dies wäre also keine perfekte Lösung.
Das größere Problem dabei ist jedoch, dass es keine Standardmethode für die Kommunikation mit Secure Elements gibt, was es für Banken schwierig macht, sie zu verwenden, und es würde erfordern, dass sie eine Liste von Secure Elements führen müssten, so wie eine Liste von CAs. Hinzu kommt, dass die Banken wahrscheinlich nicht auf diese Lösung umsteigen, so lange es keine Zertifizierung dafür gibt; so lange sie eine funktionierende Lösung haben, gibt einfach keinen großen Anreiz für sie, etwas zu ändern.
Eine Sache, die ich sehen konnte, ist, dass Banken oft noch ältere Standards verwenden, die den Zugang mit Freier Software ermöglichen könnten. Einige Apps geben zum Beispiel Fehlermeldungen mit HBCI-Fehlercodes aus. Das hörte sich zunächst vielversprechend an, denn wenn es irgendwo noch ein System gibt, das mit Freier Software kompatibel ist, dann könnten wir vielleicht darauf zugreifen. Leider ist es offenbar jedoch oft so, dass Banken eine weitere Schicht um eine ältere Schnittstelle herum bauen und dann nur noch die neuere Schicht nach außen verfügbar machen. Das mag aus der Sicherheitsgesichtspunkten sogar sinnvoll sein, wenn die Wartung dieser älteren Systeme schwierig ist. Auf diese Weise können Banken intern weiterhin Legacy-Systeme einsetzen, ohne dabei Sicherheitslücken öffentlich angreifbar zu machen, und gleichzeitig haben sie nach außen hin moderne Schnittstellen zur Verfügung. Das bedeutet, dass es leider zu kurz gedacht ist, dass wenn Banken intern HBCI intern nutzen, sie uns einfach weiterhin Zugang dazu geben könnten.
Ein weiterer Lösungsansatz besteht darin, dass Banken verpflichtet sind, Dritten Zugang zu gewähren, um neue Dienste auf Basis bestehender Bankkonten zu ermöglichen. Dies würde es theoretisch erlauben, einen solchen Dienst in Freier Software anzubieten, aber in der Regel ist für die Anmeldung immer noch die sogenannte Zwei-Faktor-App der Bank erforderlich, so dass uns auch das nicht viel hilft.
Irgendwann dachte ich, es gäbe ein Beispiel für eine Bank, die TOTP als zweiten Faktor (und Anmeldung ohne zweiten Faktor) zulässt: Paypal. Aber soweit ich weiß, tritt Paypal hier nicht als Bank, sondern als Zahlungsanbieter auf und nutzt seine Banklizenz für andere Dinge. Das bedeutet, dass Paypal zwar auf den ersten Blick wie ein positives Beispiel in dieser Hinsicht aussieht, es aber doch nicht ist, weil die Anforderungen an Zahlungsdienstleister sehr anders als die für Banken sind.
Ich bin neugierig, was ihr über dieses Thema denkt. Welche Erfahrungen habt ihr mit eurer Bank gemacht? Wie macht ihr euer Banking? Gibt es einen wichtigen Aspekt, den ich übersehen habe? Ich freue mich über jede Rückmeldung.
Happy hacking! Florian