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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Discussion mailing list Discussion@lists.fsfe.org https://lists.fsfe.org/mailman/listinfo/discussion This mailing list is covered by the FSFE's Code of Conduct. All participants are kindly asked to be excellent to each other: https://fsfe.org/about/codeofconduct
