Dutch ‘idealist’ bank ASN blocks non-Google Android, including GrapheneOS
https://play.google.com/store/apps/details?id=nl.devolksbank.asn.bankieren
SQ3A.220705.003.A1.2022071100
Ontill this moment, i did not find anything that did not worked. It seems that the app works like on stock OS
Also works on Pixel 6 Pro without Google Play and Google Play Services installed.
Tried with one of my customers but you cannot log in to the app without Google Play Services @aerique Please correct this @akc3n
Tried with one of my customers but you cannot log in to the app without Google Play Services @aerique Please correct this @akc3n
No, do not correct anything yet. Lets first figure out which app we’re talking about.
I’m using the top app which is the generic banking app. It’s updated, I can login, I can scan QR codes and pay. I use it almost every day, sometimes multiple times. I also do not have Google apps installed, not even in GrapheneOS’ sandbox.
I’ve also used this app (until a few weeks ago) on SailfishOS on its Android emulation which also does not have Google Play Services.
I can also confirm that the second app “mobiel betalen” does not work for me. This app is for wireless payments.
That’s very interesting, we only got to see an error message saying that the internet connectivity doesn’t work, I recognize this from other apps that won’t work without GMS.
Yeah mobile payments definitely won’t work but that’s not what I am talking about either.
If anyone is still experiencing compatibility issues with this banking app, please read new pinned issue post #170
Or https://akc3n.page/banking-issues
@DohnJoe1 The link to app you provided is from a search result, listing several apps. Could you please correct your initial report to specifically include the exact app you were referring to.
I.E., The link to app you provided is incorrect: https://play.google.com/store/search?q=asn%20bank&c=apps&hl=nl&gl=US
For example, the correct url would look like this: https://play.google.com/store/apps/details?id=nl.devolksbank.asn.bankieren
Sorry but none of this was relevant @akc3n. One needs GMS to log in to the account. After you could use it without. During the log in process the app seemed to be using a dependency to check for Internet connectivity. Without GMS you cannot continue.
I’ll go factory reset my spare GrapheneOS phone and see if @ph00lt0 is correct, because this was never the case in the past. (But now I’m afraid to wipe it from my main phone and not being able to install it ;-) )
Please share your findings. We should create some kind of overview of all responses and differences at some point and maybe got to Bits of Freedom and/or Human Rights in Finance if we get stuck.
What it does not verify is the integrity of the calling application and the runtime operating system.
That’s blatantly false and it’s atrocious that a EUROPEAN payment system depends on an AMERICAN service that the US could shut down in minutes.
that the app is distributed through an authentic channel
This has zero security value. If the app is authentic, you might as well have downloaded it from a cybercriminal server.
Wero transactions working fine with Fortuneo v15.0.2 on grapheneos release 2026110200
Uhm, isn’t this supposed to be software that enables EU tech sovereignty, not work actively at achieving US vendor lock-in?
Uhm, isn’t this supposed to be software that enables EU tech sovereignty, not work actively at achieving US vendor lock-in?
I would certainly hope so! Odd thing is, in the interview with the WERO CEO in RTL. (Sorry Dutch):
Soeverein zijn als Europa
Op geopolitiek gebied moet Wero ook een factor worden als het aan Weimert ligt. Ze doelt onder meer op de afhankelijkheid van grote Amerikaanse betaalbedrijven Visa en Mastercard. Het continent is volgens haar kwetsbaar als het betalingsverkeer met bijbehorende data vooral verloopt via partijen van buiten Europa.
Only a disgusting and despicable government or organization want to force people to depend on proprietary (closed-source) software that cannot be audited or verified! Since that software is not transparent as it’s hidden from the eyes for everyone, it cannot be trusted and neither the institutions and people who force you to use such software.
The only software that can be trusted more or less is the FLOSS (Free / Libre and Open Source Software) ant only if the executable builds have been built in a reproducible way!
Part of a new reply by EPI:
Second, on why Google Play Integrity is required rather than Android hardware key attestation alone: Android hardware key attestation verifies that a cryptographic key pair was generated inside a hardware-isolated environment, such as a TEE or StrongBox, and that the key has not left that boundary. What it does not verify is the integrity of the calling application and the runtime operating system.
Since you seem to have a working line of communication with them, please point out that this is wrong:
The standard hardware attestation API can be used to verify the authenticity/integrity of the hardware, firmware, OS and the app running on it. It provides a verified boot key fingerprint for the OS for permitting secure aftermarket operating systems. The app ID, signing key fingerprint(s) and version code of the app enabling hardware attestation are included in the signed public key certificate for the generated key. This enables the app’s service to make sure the app is genuine and unmodified along with chaining trust through the OS to the app which can sign messages with the attested hardware keystore key to prove they come from their app running on top of a verified OS, firmware and hardware.
https://grapheneos.org/articles/attestation-compatibility-guide
Worth reading the linked GitHub issue to the end: yesterday someone asked EPI (the Wero operator) directly, and the reply says hardware key attestation “proves a key was generated in a TEE or StrongBox but not app or OS integrity”, which is why they want Play Integrity. That claim is wrong, and the gap matters for this whole thread.
I’m on the other side of this as a developer: a small Android app where I need some assurance that a capture came from an unmodified device, so I run both Play Integrity and the Keystore key attestation API.
What the attestation certificate actually carries, per the Android spec: the challenge you supplied, the security level (software / TEE / StrongBox), a RootOfTrust extension with verifiedBootState, the verifiedBootKey hash and deviceLocked, and an attestationApplicationId with the package name and signing certificate digest of the app that created the key. That is OS integrity (verified boot, locked bootloader) and app identity, signed by the chip, chained to Google’s published roots. GrapheneOS publishes its verified boot key hashes as a signed JSON and documents how to accept them. So “a list of signing keys to be trusted” is not hypothetical, it is the documented path, and EPI’s stated reason doesn’t hold.
Play Integrity, by contrast, is one SDK call plus one server call to Google, and you get back an array like [“MEETS_DEVICE_INTEGRITY”]. Whether GrapheneOS is in or out is decided on Google’s side; nothing in the token tells you why. In my data (64 verdicts from beta testers’ phones) I have never once seen MEETS_STRONG_INTEGRITY, so in practice everyone is checking the weaker level anyway.
The honest cost of the attestation path: you parse X.509 and the ASN.1 extension yourself and you own the allowlist. My first validator unwrapped the challenge wrong and flagged 13 of my 19 stored keys as mismatched, and choked on DER lengths for 2 more. Once fixed, every real phone chained to one of Google’s two roots (7 TEE, 4 StrongBox), and the only software-attested keys came from Google’s own Play reviewer, who tests apps in an emulator. Today my server trusts the chain for what the key is, doesn’t read RootOfTrust yet, and still gates publishing on the Play verdict, so my app would block GrapheneOS too. Not for security: because the easy check was done first, and “Google said so” is easier to defend in front of an auditor than “I maintain a list of key hashes”.
@danieldk I guess that you’re angry, but I don’t think that your choice of wording is going to be instrumental in persuading the people in charge to spend additional effort in adding support for our OS
@danieldk I guess that you’re angry, but I don’t think that your choice of wording is going to be instrumental in persuading the people in charge to spend additional effort in adding support for our OS
Ah, sorry, I will remove ‘cluebatted’. This term was very common in older Unix/programming circles and not as heavy as you are interpreting it. We were cluebatting eachother or ourselves all the time. 🤗 I take some pride in writing level-headed and comments, so apologies if it did not sound like that.
Aside from that, I’m quite relaxed, since I have a backup phone I’m less affected for now.
Could this announcement from Motorola’s new flagship phone supporting GrapheneOS be helpful in persuading banks and Wero to take our claim seriously? https://motorolanews.com/motorola-signature-27-2/
Plus this article at Tweakers.net: https://tweakers.net/reviews/15570/motorola-signature-27-motorola-trekt-alles-uit-de-kast.html
FYI This issue discussed on Hacker News: https://news.ycombinator.com/item?id=50390124
Is this in the latest version? I installed the app through Aurora store and mine is still working fine.
@Tasqa: How did you file the complaint? I had a chat with support which would escale it to a tech team… that was last Tuesday. I want to file a complaint as well, even though I know this ain’t gonna matter…much.
@GMZ1711: 140 is latest version, I run the same. It depends on the payment flow if you’re confronted with the new Wero, when you do…you won’t come any further than this.
The intermittent fully black screen is just my fingerprint auth.
ADB Logs available upon request