banking and Free Software

Sun Feb 25 12:30:35 UTC 2024

Hi Florian and all subscribed,

Thanks for the elaborate mail and investigation. As you mentioned we have been at this in the Netherlands for quite some while already. My personal experience is more in regards to mobile governmental identification which too revolves around non-free mobile apps.

[https://blogs.fsfe.org/nico.rikken/2022/03/16/dutch-digital-identity-system-crisis/](https://blogs.fsfe.org/nico.rikken/2022/03/16/dutch-digital-identity-system-crisis/)

I'll break down this email down into some topics, hoping to increase the detail in our discussion. It is quite elaborate, also to straighten my own thinking.

### How did we end up here? 

Growing up I had a debit card with my bank account. I could go to the bank office to arrange many things. I could leave a wire transfer form at the bank with my autograph to make a transfer or make a payment. With the debit card I could pay directly at the store or go to the ATM to get cash. At the  ATM I could also check my account balance to make sure I had enough there.

Then internet became abundant. At home you could log in online to check your account balance and make transfers. A username and password wasn't secure enough. Some banks used a sheet of TAN-codes where you'd get a challenge and you'd have to look up the corresponding response code. The security of TAN-codes was increased by sending dedicated codes over SMS which prevented copying of the sheets. Some banks had a unique identifier which you'd have to keep around as the trust was in the identifier. Some banks used identifiers that could be share as they used the debit card for verification. Later identifiers even had a camera that could scan photo-TAN codes to make sure you knew what you were authorizing and to prevent attacks where the contents of the website was changed. 

On mobile I recall some apps with early technology that only allowed you to check your balance ('saldo check'), perhaps because mobile transfers weren't considered secure. Over time banking apps got more capabilities and you could make transfers without an external identifiers and at some point you could even start using them as an identifier for banking from your computer. Since Apple and Google dominated the mobile operating space, the features in the app closely followed the developments of the mobile operating systems. Rather than typing a password you could start authenticating with facial recognition or using your fingerprint, paying with the app in the store as if it was a debit card became a thing, even using a smart watch.

In 2015 in the Netherlands the new technology-focused bank Bunq even started mobile-first. Everything relied on the app. You could create an account after identifying yourself by photographing some ID and your face. There was no website to use as an alternative.

And now with mobile apps being so abundant, it is assumed most people use the app. Some banks are eroding the online experience by removing features from the website and creating new features only in the app. This is something André is keeping track of in the Netherlands.

Businesses and organisations might have another perspective to add to this view, as I've heard that in the past some protocols were used. I remembers that one of my sportclubs in the past used some protocol to send wire transfers digitally.

Regarding the security developments, in the Netherlands people are being robbed on the street where they are being forced to log into their app and transfer the maximum amount to an account of a money mule. Security has become so goed that the human is now the weakest link. Like the XKCD comic [https://xkcd.com/538/](https://xkcd.com/538/) Sometimes I wonder if I should just remove my banking app entirely for this risk. And banks don't refund you because you authorised the transfer.

Going over this history I see a couple of trends:

- Banks make it easy to do business with them digitally by providing 24/7 in your pocket availability. Ease of use is important, which is why the latest platform features are used.
- Security is a continued effort where technology changes constantly to address the weakpoints exploited by attackers.
- Banks don't want to keep (older) alternatives around and reduce it to the minimum in availability and features.

### Digital security

Security is important to banking because money is attractive to thieves, directly hurts the account holders and might have financial consequences for the banks. Which is why there has been a shift in technology. From printed TAN-codes to temporary SMS-tokens to prevent copying. From simple identifiers to ones that use Photo-TAN to show the financial consequences of your authorization to prevent modified transaction details in compromised webbrowsers.

In 2021 the Dutch bank Knab started demanding users to switch to apps for authentication, removing support for the hardware identifiers. The financial regulator considered this reasonable behavior and suggested that the customer would change to a different bank offering an identifier. [https://www.security.nl/posting/722428/Knab+mag+smartphone-app+voor+gebruik+bankrekening+verplichten](https://www.security.nl/posting/722428/Knab+mag+smartphone-app+voor+gebruik+bankrekening+verplichten) Something similar is happening with the Dutch Triodos bank where customers are switching away since they started removing some features in the webbrowser and provide them app-only.

As you mentioned, this is why TOTP isn't suitable, because there is no guarantee that the code is not copied. Solutions have to rely on an external copy-resistant chip/device that stores the material (could be a debit card) or rely on system on chips that have such features built in.

Furthermore, mobile operating systems are more unified with regards to design and security measures to guarantee that nobody messes with the banking app or how it is displayed. You wouldn't want an app to listen in on your pin code, start a fake transaction by simulating screen input or trick you into a transaction by visually changing the amount. Such kind of attacks were common on webbrowsers in the past. As you mentioned banking apps have mechanisms in place to detect less secure environments like rooted phones.

In recent months I learned that methods of rooting now also come with methods to disguise the rooting to make sure that banking apps still function. It seems to be a cat and mouse game.

There are parallels in other security measures like smartcards or modern USB replacements. There exist Free Software firmware implementations like Gnuk and Nitrokey. As I understood in Germany you can identify yourself digitally using the FOSS AusweisApp2 that similarly relies on the chip in the ID-card. Security in chips doesn't address the risk of attackers altering input or output to have you sign a different transaction. This is addressed by dedicated identifiers using Photo-TAN and is also something being addressed by hardware Crypto-wallets (e.g. Trezor) that come with a screen.

FIDO2 seems to be a promising standardised security solution which also supports multiple token variants. I have no practical experience with it though. Still it lacks the guarantees to prevent visual tempering.

I know other means of providing security which have different guarantees. The Dutch FOSS Yivi identification app (previously IRMA) relies on a central webservice during the authentication process which allows you to disable use when your device is lost or stolen (cryptographically it is much more complex).

Some takeaways:

- Banks rely on mobile operating system features and some external detecting software to guarantee security, resulting in a technology lock-in.
- It is a cat and mouse game of attackers and control-seeking users working around measures and of banks to increase security and control together with platform developers and security software providers.
- Security mechanisms based on chips or external tokens (incl. FIDO2) might enable free software implementations, but the risk of compromised environment (browser/app) remains.

### How does this affect Free Software?

Banking is inherently an external service. The main control is about how we interface with banking. I think it is clear that an app-only bank requiring an iOS or Android with Google services operating system is violating technical user freedom as it ties the user to the banking app and consequently on of two non-free ecosystems.

Let's start from the viewpoint proposed by Richard Stallman in the Respects Your Freedom hardware certification (which can certainly be criticised). Basically that if it is siloed off and cannot changed by the user it is ok. This is why we can accept proprietary firmware on a harddisk controller.  
Bank cards function like this, with a dedicated chip running proprietary software, interacting via electronic connectors or NFC.  
Dedicated identifiers function like this, accepting input via challenge codes or photo-TAN. Some can even function over USB, although I'm not sure about the protocols.
FIDO2 might be an enabler here.

To enable a Free Software banking app, it would be great if banks would provide an API. I don't think this is a realistic expectation. Banks want control over the user experience and the features provided by banks differ. Will banks trust users to use various applications to do their banking? I expect them to only to support this if required by legislation.

Besides a Free Software app, the second best would be to run the banking application as much in Free Software as possible: in a webbrowser. Modern websites can leverage the power of web standards for integration including for authentication. It can be provides as a Progressive Web App (PWA), so the application itself is cached. All required interaction is defined by standards and it then becomes OS independent and can even run on new GNU/Linux smartphones.

Besides banking and apps, more and more situations only allow wireless NFC payments, sometimes even without a pinpad. Ideally NFC-payments should be possible using free software or debit cards should stay around.

### What can we do to change the status quo?

Some things come to mind:

- We can raise awareness around this issue. Besides all the technical arguments, it is important that people involved in policy and technology are aware of our perspective on things.
- We can keep track of relevant metrics per bank and per country to be explicit on how large this issue really is.
- We can demand a standards-based browser-first approach which will also be the most portable one. All digital banking features (like creating accounts, setting limits, etc.) should be available in the webbrowser, regardless if used on desktop or mobile.
- We can demand a non-app authentication/authorization-solution to be available. This can be a simple identifier with a pin code or something more elaborate that can visualize the transaction being authorized to offer more guarantees.
- We can demand banking API's to be available that allows user to use a custom (free software) application for the common day-to-day banking tasks. A stretch goal might be to have API's for all the features offered by the bank through the webbrowser.
- We can demand the availability of physical cards to also have a way for wireless payment.
- We can demand the support for NFC-payment via Free Software. I lack technical knowledge in this area wat is possible and is already in place.
- As a last resort we can demand banking features to be available in analog style at the bank and digitally at the ATM. But I would rather like us to be able to participate in the digital realm on an equal level as everybody else. 
- We need to address these issues on a regulatory level to prevent each bank phasing out hardware identifiers as we are now seeing in the Netherlands. In the Netherlands the ATMs have become shared infrastructure (Geldmaat) to share the cost. Something similar could be done for identifiers to reduce overhead for individual banks.

I think we can make similar demands for identification apps, which have many similarities and also tie people to the mobile operating system duopoly.

Looking forward to continue this discussion to refine it to concrete FSFE-actions.

Best,
Nico
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part
URL: <http://lists.fsfe.org/pipermail/discussion/attachments/20240225/478014f6/attachment.sig>