Hardware-backed keystore (TEE/KeyMint) and attestation for Android apps, needed for Vipps and other banking apps

Feature Requests
1

Summary

Android AppSupport currently provides only a software keystore. Apps that create hardware-backed keys and require key attestation fail. In Norway this blocks Vipps (and with it Vipps MobilePay in DK/FI), and likely other banking and eID apps across the Nordics. I’d like to request that AppSupport expose the device’s real KeyMint/TEE to Android apps, together with verified boot, so that these apps can be supported.

What happens today (Jolla Phone 2026, SFOS 5.2.0.20, microG with Google account)

Vipps 10.41.1 gets through BankID login and Play Integrity (requestIntegrityToken() success), then fails when the PIN is set up. Right before, keystore2 reports:

Failed to get rpc for sec level TRUSTED_ENVIRONMENT
Error::Km(HARDWARE_TYPE_UNAVAILABLE)
Error::Km(CANNOT_ATTEST_IDS)

So the integrity check passes; what fails is the missing TEE-backed key and attestation.

What Vipps requires

I asked Vipps directly. Their answer, summarised: Vipps works on GrapheneOS when the bootloader is locked, Google Play Services runs sandboxed, and the app is installed from the Play Store. They are aware this isn’t enough for everyone and are not actively trying to block such setups.

Notably, GrapheneOS does not pass Google’s “device integrity” verdict. This suggests Vipps relies on hardware key attestation with a locked bootloader (GrapheneOS’s verified-boot key being accepted), not on full Google certification. In other words, Sailfish would not need to become a certified Google device. It would need what GrapheneOS provides: a real TEE-backed keystore and a verifiable boot state.

Proposal

  1. KeyMint bridge: expose the vendor KeyMint/Keymaster HAL (already present on the device for libhybris) to keystore2 inside the AppSupport container, instead of the software implementation. keystore2’s per-uid separation would keep app keys isolated.
  2. Verified boot: support a locked bootloader with verified boot on official Jolla devices, and publish Sailfish’s verified-boot key, so attestation can report a trustworthy boot state.
  3. Talk to Vipps (and others): with 1 and 2 in place, ask Vipps to accept Sailfish’s boot key the same way they accept GrapheneOS’s. Vipps states they are not hostile to such setups, so this seems realistic.

Questions for Jolla

  • Does the Jolla Phone’s TEE have factory-provisioned attestation keys that chain to Google’s attestation root? If not, is there an alternative route?
  • Is a locked-bootloader/verified-boot configuration planned for official devices?
  • Would Jolla be willing to approach Vipps MobilePay (and possibly the BankID operators) directly? A request from the OS vendor carries far more weight than individual users.

Why it matters

Vipps, BankID and banking apps are effectively part of public infrastructure in Norway and the other Nordic countries. Today they are the single biggest reason people can’t use Sailfish as their only phone. Hardware-backed keys would also make AppSupport more secure in general, and the same capability is likely needed for the EU Digital Identity Wallet.

Full logs available on request.

9 Likes
2

In the sense that the owner of the device has no control over the data they would like to keep secure, instead handing full contol over to these guys, keeping them securely in power.

3 Likes
3

Fair point, and I worded that badly. There are two separate things here:

  1. Hardware-backed key storage: keys that can’t be extracted from the device. That protects the owner (against malware, theft) and is uncontroversial
  2. Remote attestation: letting a third party verify what the device runs. That’s the part that shifts control away from the owner, and I share the concern.

I’m not asking for this because I like attestation, but because Norwegian society has made Vipps/BankID close to mandatory, and right now the only way to meet their requirements is to carry a Google-blessed Android phone. GrapheneOS shows a middle ground: verified boot with an owner-chosen key, and apps accept that key. The owner still decides what runs; the bank just gets to see it’s that OS. That’s not ideal, but it’s better than today’s choice between Sailfish and functioning as a citizen.

It should also be strictly opt-in: only apps that request attested hardware keys would use it, and nothing changes for anyone else. The longer-term fix is political (eIDAS 2.0, not tying national infrastructure to two US platforms), and I’m pushing on that side too.

6 Likes
4

Please also see this thread:

Unfortunately many sailors in this forum do not discuss possible benefits of this technology for the SFOS ecosystem but constantly spam the threads with their own opinions.

5

Just to note, but I’m not a expert, to my understanding Jolla phone already has locked-bootloader. Which doesn’t matter for AAS side as emulator has zero knowledge regarding the actual phone bootloader status so it wouldn’t know whether it is locked or not. And it sounds something I’m not sure we can even achieve as we aren’t running the android in actual hardware, but on emulator? So this by itself can be blocker we can’t overcome and I would like to see banks changing their apps

6

Only fix for this is truly regulation. Namely, remote attestation has to be banned at the EU level. Completely and in all cases.

As this will obviously will never fly in reality, users need to be able to Bring Their Own Trust.

I don’t care if it’s a TOH, USB stick, NFC key, black box from the bank that I plug into the phone. Needs to be something I can acquire on my own, and do what I want with. Signed GPLv2 firmware a la Solo Keys, let’s go. All of this is possible, just requires legal coercion motivation to do so.

4 Likes
7

I’m Cole, building Walt (an independent tap-to-pay wallet). Adding a second use case to this request: Walt needs the same thing Vipps does. Walt must verify the device through standard Android hardware key attestation, not Play Integrity. This is how Walt runs on GrapheneOS. A KeyMint bridge plus verified boot would serve payments as well as Vipps and BankID.

Question 1 in the original post is the deciding one for us too: does the Jolla Phone’s TEE carry attestation keys that chain to Google’s attestation root? As far as I know, no payment vendor today accepts a chain rooted only in an OS vendor’s own CA.

To be clear, this alone would not get Walt running on Sailfish: it would also need NFC card emulation passed into AppSupport, which is a separate request.

6 Likes
8

Or maybe provide a native SFOS app that has access to NFC directly?

4 Likes
9

I deeply appreciate the work being done here, and I understand this is about trying to provide functionality equivalent to what duopoly phones provide.

To me, however, there is something fundamentally flawed in the underlying idea.

The vast majority of payments made this way are “small”, and the actual mode of operation is “card/phone as convenient cash”. Locking down the phone in an attempt to make it fit for managing the national reserve has no significant benefit for “convenient cash”, while driving “obsolescence” of fully functioning devices and letting Google decide who can or can’t buy loaf of bread.

I don’t want to discourage the effort here, I just wish there also was a less contrived solution fit for the dominating use case.

10

This will be required in Sweden soon as well, the ordinary routine now to create a Mobilt BankID is through NFC scanning your national id card, and currently this does not work inside the AppSupport layer on Sailfish OS