banking and Free Software

Tue Feb 27 10:35:15 UTC 2024

I have some more thoughts.  First, context (which most of you know):

The roots checks performed by apps are a strong problem because they
(1) block people from using a nonfree app on an otherwise free phone
and (2) have the potential to prevent reverse-engineering efforts
against the app.  Statement (2) might not be obvious but it's true —
most apps seem to be using Google Play Integrity APIs (which I'll refer
to as "GPI" from now on).  GPI can consult the device's cryptographic
coprocessor to prove that the device still has its bootloader locked
(and is therefore unrooted, unless via unofficial means like exploiting
a kernel vulnerability or similar).  A proof[1] generated by such
cryptographic hardware module would then be verified server-side by the
bank.  If verification fails, bank can partially or completely limit
app's functions. 

Not all banks require the such strong, hardware verification right now.
But they could start requiring it at any time.

So, in this context, is anyone aware how things look like on
Huawei phones?  They now come without Google Play and with Google
services replaced by Huawei ones.  Is GPI absent there?  Is there an
analogous component instead?

That would be relevant because Huawei is one of the major mobile phone
manufacturers.  It seems to have even convinced some banks to add their
apps to its AppGallery.  While all this is still proprietary, it might
be opening up an entrance for freesw folks willing to reverse-engineer
their way to app freedom.

Btw, I wonder if GPI violates existing consumer and *competition*
protection laws?  As I understand it, CPU/phone manufacturer must go
into some deal with Google to have its crypto silicon respected by GPI.
Otherwise, we'd be able to install GPI on a device we fully control and
cryptographic proof would be meaningless.  So independent CPU/phone
manufacturers are effectively harmed by anti-competitive practices of
Google.

Best
Wojtek

[1] Even keys hidden in hardware can theoretically be extracted from
    microscopic photos of the integrated circuit (which would enable
    reverse-engineering).  But this is unfortunately beyond the reach of
    our tiny freesw community :c

-- (sig_start)
website: https://koszko.org/koszko.html
fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A
follow me on Fediverse: https://friendica.me/profile/koszko/profile

♥ R29kIGlzIHRoZXJlIGFuZCBsb3ZlcyBtZQ== | ÷
c2luIHNlcGFyYXRlZCBtZSBmcm9tIEhpbQ== ✝
YnV0IEplc3VzIGRpZWQgdG8gc2F2ZSBtZQ== | ?
U2hhbGwgSSBiZWNvbWUgSGlzIGZyaWVuZD8= -- (sig_end)

On Sun, 25 Feb 2024 13:30:35 +0100 Nico Rikken <nico.rikken at fsfe.org>
wrote:

> 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: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fsfe.org/pipermail/discussion/attachments/20240227/7105444d/attachment.sig>