Banken und Freie Software

[dnt]

Hallo,

ich habe irgendwann mal gesehen, dass es von der Varengold Bank (für 
Privatkunden gibt es nur Tages- und Festgeldkontos) eine TAN App in F-Droid 
gibt: https://f-droid.org/packages/de.varengold.activeTAN/

Habe selbst keine Erfahrung damit.

Am Donnerstag, 22. Februar 2024, 19:35:55 CET schrieb Florian Snow:
> 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