BMI’s design, SPRIND’s alternatives, and what works on your Mobile Linux
Benedikt Wildenhain
benedikt.wildenhain@hs-bochum.de
https://ruhr.social/@benedikt https://gitlab-ce.hs-bochum.de/hardwarenahe-it/eudi-wallet/
v0.3 — 2026-05-28
EU Digital Identity Wallet — a state-issued digital identity infrastructure mandated by eIDAS 2.0 (Regulation (EU) 2024/1183, in force May 2024)
What it holds:
Why it matters for Linux users: The wallet will become the primary digital identity mechanism for EU citizens interacting with public services, banks, healthcare, and more. If you can’t run it, you are effectively excluded from digital public life.
| Actor | Role | Germany |
|---|---|---|
| Member State / Wallet Provider | Distributes app, issues WIAs | BMI + SPRIND |
| PID Provider | Issues identity credential into wallet | BSI / BMI |
| Attestation Providers | Issue driving licences, diplomas, … | Any accredited body |
| Relying Parties | Verify presentations from the wallet | Public authorities, private sector |
| QTSP | Operates remote HSM holding private keys | TBD |
The citizen holds the wallet. The citizen controls what is disclosed. The citizen does not control the software stack.
German EUDI wallet work has run on two distinct tracks:
| Track | Lead | Status |
|---|---|---|
| Exploration (2024–2025) | SPRIND Funke | 15-month open prototype competition; 11 → 8 → 4 teams; concluded October 2025 |
| Production (ongoing) | BMI | Wallet that ships 20 November 2026 — Android & iOS only |
Why this matters: Three of the four SPRIND finalists built native mobile-app wallets — the same shape BMI is now building. One built a web-based wallet. That one is wwWallet, and we will get back to it.
Before we do, here is what BMI actually chose to ship.
Step 1 — Device check (MDVM)
The Wallet Provider Backend checks whether your device is “sufficiently secure.” Primary signal: Android Key Attestation — a hardware-rooted certificate chain terminating at a Google-provisioned root CA embedded at device manufacture. (BMI MDVM architecture)
Step 2 — Wallet Instance Attestation (WIA)
If the device passes, the Wallet Provider issues a WIA: a signed credential certifying “this specific app binary on this specific device is genuine.”
The WIA is the gateway credential. Everything downstream depends on it. Without a WIA, no PID Provider will talk to you.
Step 3 — PID issuance
The PID Provider validates the WIA. If valid, it issues your identity credential into the wallet.
Step 4 — Presentation
You present attributes to a Relying Party using OpenID4VP (HTTP-based). Selective disclosure: you reveal only what is asked for.
Key point for Linux users: Steps 1 and 2 are where Linux phones are excluded. Steps 3 and 4 use open, HTTP-based protocols that are platform-agnostic in principle.
Architecture version: v0.9.1 (current, May 2026)
Source code: not yet published — promised “later in 2026”
App platforms: Android and iOS only (initial launch)
Wallet Provider: BMI / SPRIND — single provider at launch
Key tension: The architecture is publicly documented and uses open protocols, but the app binary is closed, obfuscated, and the only path to a WIA.
| Component | Choice | Status |
|---|---|---|
| Primary device-integrity signal | Android Key Attestation | Confirmed, load-bearing |
| Secondary signal | Play Integrity API | Optional — may be dropped |
| Key storage | Local TEE/SE or remote QTSP HSM | Both supported |
| App integrity | RASP + code obfuscation | Load-bearing |
| Reproducible builds | Not possible | Explicitly ruled out |
BMI statement (issue #9, 2026-05-11): “Should the evaluation conclude that Play Integrity does not offer any significant additional security benefit, it will not form part of the final architecture.”
Keys stored in the device’s TEE (Trusted Execution Environment) or Secure Element:
| Step | Component |
|---|---|
| 1 | Device TEE/SE generates key pair |
| 2 | Android Keystore (HARDWARE / STRONGBOX) wraps it |
| 3 | Key Attestation cert chain rooted at Google root CA |
| 4 | MDVM check passes -> WIA issued by Wallet Provider |
This is the default path. Requires a device with a Google-provisioned TEE root. See https://eudi.dev/latest/architecture-and-reference-framework-main/#43-reference-architecture
Keys stored on a QTSP-operated HSM (Remote WSCD / RWSCD):
| Step | Component |
|---|---|
| 1 | QTSP server holds keys (certified HSM, EN 419221-5) |
| 2 | User authenticates via PIN to QTSP |
| 3 | QTSP signs on behalf of user |
| 4 | Device still needs to pass MDVM for WIA |
Even with RWSCD, the device must currently pass MDVM. The keys are off-device, but the device-integrity gate remains. This is a policy choice — not an architectural necessity.
Blocker 1 — WIA gate (hardest; structural; eIDAS 2.0 by design)
The Wallet Provider only issues WIAs to the official BMI-signed binary. A sideloaded APK — regardless of runtime environment — gets no WIA.
Consequence: even a perfect Android emulation layer on Linux is blocked here unless BMI explicitly supports it.
Blocker 2 — Android Key Attestation (hard; platform-level)
Key Attestation requires a hardware-rooted cert chain from the device’s TEE, provisioned by Google at manufacture. Linux phones have no such chain. Neither Waydroid nor ATL can provide hardware-backed Key Attestation. (See BMI issue #2)
Blocker 3 — Play Integrity (medium; may disappear)
Requires Google Play Services and a live call to Google’s servers. Currently optional — BMI is evaluating whether to include it at all. (BMI issue #9)
Waydroid — Android 13 (LineageOS-based) in a Linux namespace container.
What it can do relevant to the wallet:
The specific failure: software-backed Android Keystore
The Android Keystore inside Waydroid is
software-backed (SOFTWARE security level,
not HARDWARE or STRONGBOX).
Key Attestation certificates from a software keystore will not satisfy the MDVM’s LoA High requirement — the cert chain cannot be rooted in a Google-provisioned hardware key without TEE passthrough.
Theoretical fix: A TEE/Keymaster HAL bridge forwarding Key Attestation requests from the Waydroid container to the host device’s physical TEE. This engineering work does not exist today.
Android Translation Layer — reimplements Android APIs natively on Linux. Think Wine, but for Android. No full Android system running in parallel.
Current status: Early development.
Fundamental gaps for security-critical apps:
However: ATL is the architecturally correct long-term direction. If it matures to support hardware-adjacent APIs and gains a Keystore HAL, the picture changes significantly.
ATL is the right long-term direction. It is not a 2026 solution.
A 15-month German federal innovation competition, three stages, concluded October 2025 (SPRIND page).
| Stage | Teams | Funding (funded track) |
|---|---|---|
| 1 | 11 (funded + non-funded) | up to €300K per team |
| 2 | 8 | up to €300K per team |
| 3 | 4 finalists | up to €450K per team |
Published code: https://gitlab.opencode.de/funke
| Team | Backers | Architecture | Linux-compatible? |
|---|---|---|---|
| Animo Easy-PID | Animo Solutions | Native mobile app | No (Android/iOS) |
| Heidi | Authada / partners | Native mobile app, human-centred | No (Android/iOS) |
| Sphereon / Ubique | Sphereon, Ubique | Native mobile app | No (Android/iOS) |
| wwWallet (non-funded) | Sunet + GUnet + Yubico | Browser-based PWA + WebAuthn | Yes |
Three finalists built mobile-app wallets in the same shape as BMI’s design. One built a browser-based wallet — and demonstrated it at all three SPRIND Funke conferences.
wwWallet — open source, runs in any modern browser.
What it is:
What it is not:
The cryptographic move: WebAuthn with the PRF extension.
WebAuthn lets a browser talk to a hardware authenticator (Yubikey, Touch ID, Windows Hello, …). The PRF extension lets that authenticator derive deterministic secrets usable as cryptographic key material, bound to the origin.
| Role | BMI design | wwWallet design |
|---|---|---|
| Hardware-rooted key | Android Keystore / iOS Secure Enclave | WebAuthn authenticator (e.g. Yubikey) |
| Attestation chain | Google / Apple root CA | WebAuthn attestation from authenticator vendor |
| Possession factor | Device with TEE | Hardware authenticator + user verification |
| Platform requirement | Android or iOS | Any browser supporting WebAuthn PRF |
Implication: the hardware trust root moves from the phone to a hardware authenticator the user owns — and the wallet itself runs anywhere.
| Component | Linux phone support |
|---|---|
| Browser (Firefox / Chromium / Epiphany) | yes (Phosh, Plasma Mobile, Sxmo) |
| PWA installation | yes (Firefox supports PWAs on mobile) |
| WebAuthn over USB Yubikey | yes (Linux libfido2) |
| WebAuthn over NFC | partial (depends on phone NFC stack) |
| Platform authenticator (TPM-backed) | yes on systems with TPM 2.0 |
No Waydroid required. No Google Play Services. No Android Keystore HAL. No waiting for ATL to mature.
If Germany shipped a wallet like wwWallet alongside the mobile app, every Linux phone user could use it today.
| Approach | Works today? | Status |
|---|---|---|
| wwWallet (web wallet) | Yes | Demo running; SPRIND-evaluated; not the German wallet |
| Waydroid + official APK | No | Key Attestation software-only |
| ATL + official APK | No | No Keystore HAL; early-stage |
| Native Linux wallet app | No | Does not exist |
| RWSCD + relaxed MDVM policy | No (policy) | BMI policy, not architecture |
| GrapheneOS + Sandboxed Play | Possibly | Play Integrity optional |
The architecture problem is solved. What remains is whether Germany ships any non-mobile wallet. SPRIND already funded the proof.
Option 1 — Adopt a wwWallet-style web flow alongside the mobile app
Already demonstrated by SPRIND finalists. Closest to “deploy what exists.” Requires BMI willingness to accredit a second wallet shape or operate one itself. Architectural cost: low. Political cost: unknown.
Option 2 — RWSCD + relaxed MDVM policy
Keys are off-device on a QTSP HSM. The argument for requiring hardware Key Attestation weakens considerably when no key material is on the device. Policy decision by BMI, not engineering.
Option 3 — Continue waiting for Waydroid / ATL to mature
Multi-year horizon. Architecturally weakest because the WIA gate (Blocker 1) still blocks sideloaded APKs even if attestation worked.
The cheapest option is the one Germany has already prototyped.
The Wallet Provider dependency is not a BMI design choice — it is the legal architecture:
What the wallet gives citizens:
The wallet is state-issued credential infrastructure, not a self-sovereign identity system. The shape of that infrastructure is a choice.
Issue #9 — Play Integrity: Optional per BMI; final architecture decision before November 2026.
Issue #10 — Non-mobile users: MitID-style hardware key / web wallet proposal. No team response after 2 months. Community voices needed.
Funke source code — full funded-track output
wwWallet GitHub org — non-funded reference implementation, MIT-style
The Funke artifacts are the strongest existing argument that web flows and broader platform support are achievable — not theoretical.
| Event | Expected | Significance for Linux |
|---|---|---|
| BMI source code publication | “Later 2026” | Audit MDVM; assess Waydroid feasibility |
| QTSP partner named | Unknown | RWSCD architecture becomes concrete |
| Play Integrity decision | Before Nov 2026 | Removes one blocker if dropped |
| ATL Keystore HAL support | Unknown | Long-term path opens |
| BMI accreditation of a 2nd wallet | None announced | Web-wallet path opens if BMI moves |
| BMI wallet launch | Nov 2026 | eIDAS 2.0 deadline |
| Layer | Situation |
|---|---|
| eIDAS 2.0 mandates LoA High | Hardware-rooted credentials required |
| BMI’s chosen design | Mobile app + Android Key Attestation |
| WIA gate | Official binary only — no self-builds, no alternative runtimes |
| Linux phones (BMI wallet) | No hardware Key Attestation available |
| Waydroid / ATL | Not viable for BMI’s wallet in 2026 |
| wwWallet (SPRIND prototype) | Demonstrated working — not a German wallet |
| Paths for BMI to act | Web wallet, or relaxed MDVM with RWSCD |
BMI’s mobile-app-only design is a choice, not a technical necessity.
SPRIND — the German federal innovation agency — funded a 15-month competition that explored alternatives. wwWallet demonstrated a browser-based EUDI wallet that runs on any modern browser, including those on Linux phones, with WebAuthn replacing Google’s attestation infrastructure.
The architecture problem for Linux users is therefore solved already. What remains is a policy and procurement question: will BMI accredit or operate a second wallet shape alongside the mobile app?
For Linux phone users in the near term, the realistic expectation is still exclusion from the default German wallet — but with the unusual feature that the working alternative has already been built, evaluated by the German government, and is online today.
BMI wallet documentation
SPRIND Funke
wwWallet
Legal & protocols
Android-on-Linux & comparable implementations
Questions? Comments? Corrections?
Participate Hackathon 2026-06-04/05?
| benedikt.wildenhain@hs-bochum.de | |
| Mastodon |
Slides and sources:
Licensed CC BY-SA 4.0 — share and adapt with attribution, same licence. Documents gathering and some reading by hand, summarizing unproudly done with assistance from Anthropic Claude Sonnet 4.6 / Opus 4.6 due to time constraints.