"Raskere BankID": BankID (Norway) bans passwordless sign-in on GrapheneOS

DeletedUser370

Out of curiosity, I temporarily set my default web browser to Brave, and I could reactivate "BankID with screen lock" successfully.

pj65

BankID worked with fingerprint id for an hour. Then i received an sms that my bankid had been revoked and all access to my bank accounts was blocked. Had to meet up in my bank to get access to bank accounts again. They said a security bot had registered a posssible cyber attack on my account. Pixel 9a 2025080600

p-marg

I have used "Faster BankID" on multiple occasions, no issues to report having Vanadium as the default browser, can confirm it works.

p-marg

BankID FAQ:

Some Android devices lack technical support, or so‑called “key attestation,” which is required to enable biometrics. This is when Google verifies the security of key management. For example, if you modify the phone yourself, it can happen that Google is unable to vouch for it.

https://bankid.no/hjelp-bankid-app

This FAQ statement feels incomplete, and it suggests that I should keep sending them feedback every few months about adding support for GrapheneOS.

fid03

This feature still works completely fine on GrapheneOS, but seems to require Google's credential service to be enabled in order to function when Vanadium is set as your default web browser. I had to go to the Settings app > Passwords, passkeys & accounts > enable "Google" in order to activate the feature last week.

I think the Play services dialog claimed that the passkey gets saved to your Google account, but when I checked my Google account settings later it didn't actually sync any passkey related to that.

The app uses a custom tab for this feature, and custom tabs share state with the default web browser. I didn't have to change any settings in Vanadium.

Funny thing, Vanadium now offered me to store the passkey in one of my password managers, or on a security key using the app HW Fido2 Provider. That didn't actually work though, so I'm assuming storing the passkey externally gets blocked by BankID.

To be clear, this feature is now called "BankID med biometri".

twine6148

I've run into a bit of a headache here. I use a self hosted bitwarden instance for passwords. Unfortunately, bitwarden now supports passkeys as well, but is not compatible with bankid with biometrics, while google password manager is.

I've worked around this by using obtainium to install bitwarden, and locked the release to version 2024.4.0, which is the last bitwarden release to not support passkeys. This successfully "falls back" to Google password manager for passkeys, including bankid.

Just putting this out there. I'll request an option on GitHub for bitwarden to offer a way to disable passkeys.

AcclaimSublevel19

twine6148 Perhaps you can set Google as the preferred autofill service in Settings and Bitwarden as an additional one? I think only the preferred one handles passkeys, while you'll still get autofill suggestions for Bitwarden logins.

fid03

twine6148 Works completely fine for me with Proton Pass – which also supports passkeys – set as the preferred service in Settings > Passwords, passkeys & accounts, and Google set as a secondary service. Weird that it doesn't work for you.

AcclaimSublevel19 I think only the preferred one handles passkeys, while you'll still get autofill suggestions for Bitwarden logins.

Both preferred and secondary ones are able to handle passkeys. You can generally choose between them when you sign in with or register passkeys.

fid03

twine6148 Which web browser is set as the default web browser? Settings > Apps > Default apps > Web browser. Try setting it to Vanadium.

phiend

BankID with biometrics / Raskere BankID doesn't use passkeys, it uses device-bound FIDO2 public key credentials. The difference is that a passkey can be synced/copied/moved/tampered with, while a device-bound credential should not. And, a device-bound credential must be able to provide a valid attestation upon creation - proving that the key is stored in a hardware-backed keystore.

As long as your password manager / credential provider can provide a valid attestation for a device-bound FIDO2 public key credential, either using the "android-safetynet" or "android-key" attestation formats, there's nothing stopping you from signing up to BankID with biometrics on GrapheneOS.

However, as far as I'm aware, Google Password Manager with Google Play Services enabled is the only password/credential manager on Android to support device-bound FIDO2 public key credentials.

Additionally, the difference between creating a passkey and a device-bound FIDO2 public key credentials when invoking the WebAuthn API is rather weak, i.e. residentKey: "discouraged" and residentKey: "preferred", vs. a stricter residentKey: "forbidden" and residentKey: "required", some passkey providers will answer to the API call saying "Hey, I can create and store this key", and then create a syncable passkey without an attestation, even though the combination attestation: "direct", residentKey: "discouraged" strongly indicates that a device-bound FIDO2 public credential is what should be created, and not a passkey.

So various password / credential managers offering to save a passkey when a device-bound FIDO2 credential has been requested causes some bad UX and confusing user experiences. Although, this is because the FIDO2 spec. specifies that you can't require an attestation from the API itself, you can only request and verify whether you actually got one, hence why, for example, Bitwarden shows up and says "Save this passkey with me, yes?", and then BankID with biometrics fails to register immediately after, once the attestation is being validated.

TLDR:

BankID with biometrics uses device-bound FIDO2 public key credentials
Only Google Password Manager (using internal libs from Google Play Services) currently supports creating these credentials
This isn't BankID's fault and BankID does not do anything to "block" GrapheneOS
This is all just a consequence of how niche device-bound FIDO2 public key credentials became after the FIDO alliance pivoted to making the WebAuthn spec. about syncable passkeys, at the cost of the device-bound FIDO2 credential UX

So I guess the fix is to use GPM, i.e.:

I had to go to the Settings app > Passwords, passkeys & accounts > enable "Google" in order to activate the feature last week.

And if you don't want to use GPM, you don't really need BankID with biometrics.

fid03

phiend device-bound FIDO2 public key credentials. The difference is that a passkey can be synced/copied/moved/tampered with, while a device-bound credential should not.

Official FIDO2 documentation says otherwise: "passkeys" can either be device-bound or syncable. Here's a brief overview of FIDO2 terms, created by the FIDO Alliance and WICA: https://passkeys.dev/docs/reference/terms/#passkey

Where specifically in the WebAuthn and FIDO2 documentation are you getting all your claims from?

phiend However, as far as I'm aware, Google Password Manager with Google Play Services enabled is the only password/credential manager on Android to support device-bound FIDO2 public key credentials.

There are several third-party ones such as Passchain. If I follow your reasoning, I should also be able to store the BankID credentials on "roaming authenticators" such as Yubikeys, which I can't.

phiend This is all just a consequence of how niche device-bound FIDO2 public key credentials became after the FIDO alliance pivoted to making the WebAuthn spec. about syncable passkeys, at the cost of the device-bound FIDO2 credential UX

What? The WebAuthn specification isn't just about "syncable passkeys". Where are you getting this from? Or are you saying that the FIDO Alliance pretends that it is?

phiend Additionally, the difference between creating a passkey and a device-bound FIDO2 public key credentials when invoking the WebAuthn API is rather weak, i.e. residentKey: "discouraged" and residentKey: "preferred", vs. a stricter residentKey: "forbidden" and residentKey: "required", some passkey providers will answer to the API call saying "Hey, I can create and store this key", and then create a syncable passkey without an attestation, even though the combination attestation: "direct", residentKey: "discouraged" strongly indicates that a device-bound FIDO2 public credential is what should be created, and not a passkey.

Please explain where you're getting this from.

phiend This isn't BankID's fault and BankID does not do anything to "block" GrapheneOS

I think you might've missed the more recent comments about this issue being resolved? The statement in the OP about BankID banning GrapheneOS was an assumption, perhaps or perhaps not a reasonable one but it did seem to create some attention towards the issue.

phiend

fid03

Official FIDO2 documentation says otherwise: "passkeys" can either be device-bound or syncable. Here's a brief overview of FIDO2 terms, created by the FIDO Alliance and WICA: https://passkeys.dev/docs/reference/terms/#passkey

I was a bit inaccurate, let me clarify.

Passkeys can be device-bound yes, but that doesn't make device-bound FIDO2 public key credentials and passkeys the same. Passkeys must be discoverable. Non-discoverable FIDO2 public key credentials can provide attestations, while discoverable FIDO2 public key credentials (passkeys) generally do not, due to privacy considerations.

From the spec:

[Passkey] A Client-side discoverable Public Key Credential Source, or Discoverable Credential for short, is a public key credential source that is discoverable and usable in authentication ceremonies where the Relying Party does not provide any credential IDs, i.e., the Relying Party invokes navigator.credentials.get() with an empty allowCredentials argument. This means that the Relying Party does not necessarily need to first identify the user.

I actually made the exact same interpretation as you, and I myself recently argued that non-discoverable FIDO2 public key credentials are passkeys. I then spoke directly to one of the WebAauthn specification editors, who explained that I was wrong, and that the definition on that page also was wrong, due to it not including the discoverability of the credential.
I then informed passkey.dev of this discrepancy months ago and asked for the definition to be updated.

There are several third-party ones such as Passchain. If I follow your reasoning, I should also be able to store the BankID credentials on "roaming authenticators" such as Yubikeys, which I can't.

If that's the case with Passchain I'm very glad to hear that. Please let me know if you've tried using BankID with biometrics via Passchain.

If the "packed" attestation format was allowed, all that would stop you is the client-side authenticatorAttachment: "platform" selection, which filters away roaming authenticators.

What? The WebAuthn specification isn't just about "syncable passkeys". Where are you getting this from? Or are you saying that the FIDO Alliance pretends that it is?

I never claimed it was all about syncable passkeys. But, between level 2 and level 3 (IIRC) of the webauthn spec the focus became less about attestable high-assurance authentication, and more about passkeys and treating passkeys as a password replacement, focusing on increasing adoption.

As a concrete example of this, Apple completely dropped support for attestable non-discoverable device-bound credentials in iOS16, even though they fully supported it in iOS15. Google kept the support.

Please explain where you're getting this from.

These parameter options are explained in the spec.

I think you might've missed the more recent comments about this issue being resolved? The statement in the OP about BankID banning GrapheneOS was an assumption, perhaps or perhaps not a reasonable one but it did seem to create some attention towards the issue.

I'm just clarifying.

« Previous Page