"Holder Binding" of the e-ID - Implementation for Android and possible alternative solutions

[andre-kunz]

We would like to continue the discussion that arose from the ‘Add to F-Droid’ issue here, summarise the most important points and address any questions.

The legal provisions apply as requirements for the technological design of the e-ID, namely that the link to the holder must be technically verifiable. For other types of credentials, different forms of attestation can be implemented.

For Android operating systems, we defined the following requirements in our blog post from August 2025:

1. To prevent changes to the operating system, the bootloader must be locked and its status must either be verified or signed with a trusted fingerprint (self-signed).
2. To ensure that the operating system is considered secure and trustworthy, the version of the operating system and its patch level must meet minimum security requirements.
3. The hardware key verification must be valid (attestation and root keys must not be revoked). This ensures that the device properties (bootloader status, OS version, etc.) have been confirmed by hardware that is considered secure. The same mechanism is used to ensure that the e-ID is bound to a hardware-based key.
4. The signature of the Android Package Kit (APK) used matches the version provided by the federal government. This ensures that the software used has actually been provided by the Swiss Confederation and has not been modified.

For these checks, we will use the operating system's API rather than Google's Play Integrity service.

The measures listed are intended not only to protect users, but also to prevent devices from being manipulated in such a way that they can be misused as ID proxies.

We are aware that only a limited selection of operating systems and devices currently meet these criteria. We are monitoring which alternative solutions are being developed in the EU and elsewhere in order to allow other devices and operating systems (see discussion on Linux smartphones). Suggestions from the community are very welcome in this discussion.

[salim-b]

As has been argued by Daniel Micay, the whole point of this exercise is ultimately "to protect against people tampering with the app, not security".

So point 4 above

4. The signature of the Android Package Kit (APK) used matches the version provided by the federal government. This ensures that the software used has actually been provided by the Swiss Confederation and has not been modified.

should actually be the first point since points 1–3 are simply done to be able to trust the signature check result of the OS, IIUC. Or as Daniel Micay puts it: "The whole reason they're doing this is trying to enforce using an OS which enforces the expected security model which most alternate operating systems are known to not be doing."

[Trim]

2. To ensure that the operating system is considered secure and trustworthy, the version of the operating system and its patch level must meet minimum security requirements.

What will happen to a user already registered when its device won't receive any more updates from the manufacturer ?

[andre-kunz]

As a user, you don't have to "register". If you have your e-ID stored on a device that does not meet the requirements anymore, you have to get a new e-ID on a different device.

[simonrupf]

Having discussed with several folks from BITS at the participation meeting last Friday, and given my issue that I want to use the eID, but the swiyu android app doesn't recognize Sailfish OS as a secure environment, and given that the Android platform soon may become even more restricted, I'd like to re-launch this discussion to help out the BITS and make it possible to use the eID outside of the US-controlled platforms (Digital Sovereignty).

Having had the opportunity to chat with other participants of the civil society as well as the BITS & team swiyu itself, here are some ideas that got pondered and the concerns raised by various stakeholders below. Before I commit my resources to any option, I'd like to at discuss with the swiyu project members on a course of action that aligns with their plans and would not fail due to either self-imposed or external constraints.

Discussed solutions:

1. Extend the swiyu eID Android wallet build to provide an alternative APK, not published to the Google Play store, that doesn't use the Google Play services or the remote attestation / secure element mechanism.
   1. do this work inside of the https://github.com/swiyu-admin-ch/eidch-android-wallet/ project
   2. do this work in a community fork of https://github.com/swiyu-admin-ch/eidch-android-wallet/
2. Get the DID toolbox built out into a CLI based eID wallet, for use on any OS that has Java support.
3. Create a FIDO2-hardware-token based CLI application, TUI or GUI being optional or later developments
4. Create a web application using WebAuthn for hardware-token support

Concern & Limitations raised:

• Any client not published by the swiyu team will have to undergo a yet-to-be defined certification, which at this time is out of scope for BITS, due to lack of resources. Therefore they made clear that no third party wallets will be possible for the eID at launch. But they could be possible at a later date - this makes it very risky to invest any resources in developing such an alternative wallet.
• At the participation meeting last Friday, one member of the audience asked about using the swiyu logo in their eID wallet based login solution and the answer made it very clear that swiyu is a registered trademark and it's use will have to be heavily policed (it has to, by trademark law). I don't think anyone willingly wants to invest resources in a project that will potentially run afoul of naming or trademark disputes and I think the limited resources of BITS (our tax money) should not be squandered on legal fees, either.
• While the "secure element" verbiage seems to leave some room for interpretation, members of the FEDPOL explained me, that their requirement really boils down to the private key used in the DID, that is the basis of the eID, must not be subject to copy. That mean no backup allowed, no second devices (though the current wallet allows to setup a second device at eID issuing time?) and therefore excludes any software based solution (i.e. encrypted keys, since those can be copied or installed on multiple devices). While personally, in my threat model, I find this protection of the user from themselves to be overbearing, it is what the powers that be have agreed upon and developing a software-only wallet will therefore not be anything that has chances of getting approved by that to-be-defined certification process.
• DID vs X.509 type of certificates: Mostly for time constraints and because in the past the DID-based solution had already been in development at BITS, at least the initial eID will be DID-based. Unfortunately the EU has since chosen good old X.509 as the basis for EUDI, so at least initially Switzerland will (once more) be an island within Europe. Technically this is mostly a limitation in that there is mature tooling and more prior solutions available for X.509 certificates, which might make it more challenging to adapt such a solution as a wallet for our eID.
• While the frameworks for hardware binding and remote attestation of Apple and Google were assumed to be secure enough, any third party wallet will have to get certified to be "as secure" by BITS or the FEDPOL (?). There isn't any current plan on what the process would consist of, what the requirements to fulfill are, who would have to pay for it (considering hobbiest projects or non-commercial solutions) and BITS has no resources at this time to develop such certification process. This makes it difficult to guess what will fly or not, but likely will be some trial and error and require someone forcing the issue, trying to get "their solution" to become an accepted wallet.

Prior (Wallet) Art:

• SPRIND has selected HEIDI by the Swiss Ubique Innovation AG for funding, to develop an EUDI infrastructure including wallet. They were at last Fridays participation meeting, but I only learned of that when I was already on my way to catch the train, so I've got no insight to share if that solution would in any way be useful or compatible as a basis for such an alternative wallet.
• Another solution not picked by SPRIND for funding is the wwWallet, a web-first wallet using WebAuthn. The latter standard can leverage FIDO hardware tokens, but also other solutions that the BITS or FEDPOL may not consider to be "secure elements". But it would work on desktops and be more than just a CLI, so potentially reach a wider audience.
• There is also a Linux Foundation project, called the OpenWallet Foundation. It doesn't yet list any projects, but interestingly they do invite to a "Global Digital Collaboration" conference in Geneva this summer? Anyone knows who they are and if they have any FOSS wallet software in the pipeline?

So before I waste any (more) of the BITS' limited resources or mine own, could we please align on if there is any further options on the table and how best I could spend my time to work towards getting a solution as soon as possible if not on the same launch day as the eID that does work on other platforms than those of the increasingly unreliable transatlantic partners? What solutions would have any chance of getting either automatic certification (because they are developed as swiyu projects) or at least have reasonable chances of getting certified if developed outside these repos?

I'm very concerned that sooner rather than later, my lack of access to an eID will exclude me from being able to participate in public life, like Twint that has already in some circles started to become the only accepted payment solution (no cash or credit cards) and I can't use either. The latter is from private company, so I can't really do much about that except complain to those that us it as the only payment option, but the eID is a government issued solution, so as a citizen I feel obligated to participate in finding and implementing a solution, even if folks like me still only represent a niche of the population.

[salim-b]

JFYI, I don't know exactly how we should interpret the press statement from 2026-02-25, but this part doesn't sound very hopeful:

Aus Spargründen muss hingegen derzeit auf alle geplanten Weiterentwicklungen verzichtet werden, insbesondere die Anbindung an internationale E‑ID-Systeme, den Back-up Service des Bundes oder die Ausstellung der E-ID in Drittwallets.

Weitere mögliche Sparmassnahmen können ausserdem zur Folge haben, dass dem Bund nicht genügend finanzielle Mittel zur Verfügung stehen, um zusätzlich zur E-ID weitere digitale Nachweise zu entwickeln. Die Einführung des elektronischen Führerausweises sowie Betrieb und Weiterentwicklung des Behördenlogins AGOV werden hingegen aus anderen Budgetposten finanziert.

[simonrupf]

Right, thats what I mean reg. them not having enough resources. Thats sad, but fine - it's our tax money.

So I'm willing to put effort in for free, as it would benefit myself and others. This is MIT-licensed FOSS software - everyone can fork it, modify it, commercialize it, etc.

But obviously it is neither in team swiyu's interest, nor in the interest of eID end-users, if there are "unofficial" apps out there, that they can't detect or reject (easily), and don't follow the FEDPOLs security requirements (that I may not fully agree to, but we are trying to collaborate here).

So I'd like to align with them rather then go the route of a fork and a wasteful game of catch-up with whatever changes they make in the app to prevent third party wallets they haven't had the resources to review or certify. And I want to start this ASAP, so there is a solution ready when the eID starts to get pushed onto the market.