Banken und Freie Software

Florian Snow floriansnow at fsfe.org
Do Feb 22 18:35:55 UTC 2024


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

-- 
Florian Snow - Free Software Foundation Europe e.V.
Schönhauser Allee 6/7, 10119 Berlin, Germany
Registered at Amtsgericht Hamburg, VR 17030
Your support enables our work (fsfe.org/join)


Mehr Informationen über die Mailingliste FSFE-de