On 2/27/24 11:35, Wojtek Kosior wrote:
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.
the only bank i found to outright block devices from using the app was
Revolut (trivial to bypass by adding to MagiskHide/Zygisk denylist).
bunq just showed some dismiss-able warning. ING.pl issued a warning
message that some transaction limits are lowered (and blocked HCE
contactless payments with a very generic message like "Data retrieval
error"; worked on microG after adding to Zygisk denylist). PKO BP
blocked fingerprint login.
the only one with Play Integrity/SafetyNet for me was mBank.pl, but even
then, it still did not require the hardware-based MEETS_STRONG_INTEGRITY
status, and only blocked 2 features: HCE via contactless Blik, and
disabling FLAG_SECURE (which blocks making screenshots in the app).
i think too many completely unaware users, even running Android shipped
by their device manufacturers, just don't pass GPI/SafetyNet checks for
something like this to pass through. the McDonald's app with these and
other invasive checks (such as whether com.topjohnwu.magisk is
installed, or a directory named "TWRP" exists) stands as a good warning.
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?
there is a Huawei equiv:
https://developer.huawei.com/consumer/en/hms/huawei-safetydetectkit
all banks i've checked some time ago either stayed on Google Play only,
told customers certain app features are not available on Huawei devices,
or went for implementing everything twice, e.g. using Google ML Kit for
scanning QR codes on Google Android, and Huawei ML Kit on Huawei,
instead of, say, ZXing.
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.
i've thought about doing that earlier, and i think it's achievable, but
just a lot of work. bunq would probably be the best start point for
that, since they officially offer API with Swagger-based documentation,
a sandbox environment, and SDKs, even to individual customers. AFAIK the
same API is used internally by their own apps. https://developer.bunq.com/
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.rik...@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
_______________________________________________
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
--
lauren n. liberda
it/she, het/zij, to [coś]/ona
https://liberda.nl/
_______________________________________________
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
