Hi Stefan, Thank you very much for your questions. Please find our response below:

EUDI wallets must provide authentication means that are suitable for the assurance level high according to CIR EU 2015/1502. This results in high requirements for user authentication when presenting credentials such as the PID. This includes two-factor authentication (2FA) of the user, which is substantially based on security functions and security posture of the user's mobile device, the operating system (OS) and the wallet instance (WI).

The mobile device's hardware-based key store (HKS) is used, for example, to generate and manage private key material as a possession factor for the 2FA. OS and WI provide functions that allow the user to enter a knowledge factor for 2FA and also to use keys in the HKS.

In order to obtain information about the security posture for HKS/OS/WI, we use, among other things, the services available for the respective mobile device platform.

For Android devices, we use, among other things, App Attestation based on a PKI provided with Google Play services to obtain verifiable information about the integrity of the WI and the OS. We also use key attestation to obtain information about the HKS that manages private keys and the OS but key attestation provides us not with information about WI integrity.

At present, we rely on the services provided by Google and Apple as one of the signals for verifying app and platform integrity. Their broad market reach enables us to concentrate on delivering a secure and reliable solution at scale. 

To reduce platform dependencies, we also evaluate additional platform independent signal sources. In this context, we evaluate signals from runtime application self-protection (RASP) systems, for example. We also might revisit later whether there are comparable security mechanisms for other platforms.

Please note that responses are posted from one account, they represent the outcome of discussions and agreement within the National Wallet Development team.

Thanks for the consideration and the reply! So the short answer seems to be "yes". This is unfortunate ...

From recent experience in at least two of Germany's neighbouring countries (CH, AT), hard dependencies on Google Play services, and thus locking out of alternative Android distributions (e.g., GrapheneOS), are not very popular.

The Austrian smartphone-based eID, for example, achieves LoA high while not relying on any Play Integrity services.

Hi Kristina,

thank you for the elaborate response! If I may, I’d like to explore the technical details a bit further, as this is a delicate subject not only because of the consequences of any potential decision, but also on a technical level.

First, the straightforward part: For iOS, I fully agree that we are inevitably tied to Apple infrastructure, so there are no meaningful alternatives at a conceptual level.

Now for the Android side, where I strongly disagree with the idea of using Play Integrity: As I understand the requirements for LoA high, all necessary guarantees can be achieved through the correct application of the attestation capabilities built into every Android device, without relying on the Google Play Integrity API. That said, I may be overlooking something, and I would be grateful for clarification. Using only attestation has the advantage of being fully documented, transparent, and independent of proprietary services, whereas Google Play Integrity introduces a dependency on a closed system whose inner workings are not open to review. The guarantees achieved through attestation, on the other hand, are both verifiable and easier to reason about.

Directly utilising attestation also brings flexibility: you can define your own fine-grained policies, such as required patch levels, OS versions, or app versions. You can also differentiate between generic hardware attestation and requiring Strongbox-grade attestation (i.e., backed by discrete HSMs) if the use case demands it.

Play Integrity makes the tempting offer of a hands-off, ready-to-use integration package while also providing additional measurements beyond what attestation alone delivers. However, these measurements are obtained through undocumented algorithms, and their inner workings are not transparent. As a result, they may add little once you already assert that your app runs on a real device with a locked bootloader and verified OS integrity. From my perspective, such checks are irrelevant for LoA high specifically, since in that context:

• they only come into play if one of the essential guarantees is already violated, and
• they rely on heuristics that cannot be independently reasoned about.

The only really unavoidable Google interaction in either case is the revocation check, which can be done virtually anonymously with a single HTTPS request. With proper caching (as recommended by Google), even their own server logs reveal nothing beyond the fact that the list was downloaded at some point.

Looking forward to a follow up!

Disclaimer: I am the PO of Warden Supreme, which enables you to harness Android’s attestation capabilities for app attestation (given you trust the Android Platform Security Model). My perspective is therefore informed by that role, but I also want to mention that I bring direct experience from introducing key and app attestation into production eID services, so I am familiar with the constraints of such environments.

Thanks!

Any updates on this?

I understand there are certain security requirements, especially that the private key material cannot be duplicated. However, this is also possible on systems having some kind of dedicated hardware for securely storing key material (ARM Trustzone or TPM chips, referred to as local WCSD in https://eudi.dev/1.4.0/arf/#43-architecture-types) or external local WCSD such as smartcards (or possibly Nitro-/Yubikeys, which can be connected to smartphones using NFC or USB-C).

Reading https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A02014R0910-20241018#M2-29 article 5a, 4. I wonder how a system requiring proprietary software and accounts from Google or Apple enables the user to use IW in a "manner, that is [...] transparent and traceable" and "under the sole control of the user". Proprietary software cannot be fully transparent and traceable to the user and the attestation system obviously makes decision whether the app is allowed to do any of the mentioned actions. I already experienced my home's IP address being blocked to access Google's services for a few days, which probably would have prevented using Google's attestation system.

Would it be possible to use the European open source approach Unified Attestation as an alternative? https://www.heise.de/news/Bezahlen-ohne-Google-Neues-Konsortium-will-Custom-ROM-Huerden-beseitigen-11204008.html https://uattest.net/

There needs to be a hardware key alternative like this:

https://www.mitid.dk/en-gb/get-started-with-mitid/how-to-use-mitid/mitid-chip/

Or e.g. like QR-TAN that many banks offer. Beyond that, only a website should be required. Please note Unified Attestation as mentioned above is not sufficient to address this:

Why?

• The Android and iOS requirement itself is harmful. Android/iOS are an abusive monopoly. Two examples of what these platforms are up to:

  1. Both platforms are notorious for at some point stopping security updates while asking you to throw away the device, which with a regular desktop PC typically doesn't happen (and even when it does like with Windows 11, there are alternatives with Linux). On smartphones due to locked down closed-source bootloaders and closed-source drivers, there is typically no long term workaround to avoid this entirely artificially imposed e-waste process.
  2. Both platforms are known for trying to prevent users from installing whatever software they want, e.g. see here about Google's latest efforts to turn Android into an anti-user locked down nightmare. This behavior is deeply anti ownership and monopolist. No citizen should be required to buy such a device.

  Relying on an Android + iOS app ensures that whenever a third competitor arrives, they will never be able to enter the market. This is not a reasonable situation for a citizen wallet to enable.

• Hardware attestation on a user device is a harmful requirement. TPMs, the equivalent on UEFI computers, are notoriously ridden with security holes: https://www.sophos.com/en-us/blog/serious-security-tpm-2-0-vulns-is-your-super-secure-data-at-risk They are also seem to often be vulnerable to relatively simple hardware attacks: https://www.covertswarm.com/post/how-secure-are-tpm-chips (And preventing hardware attacks means you need to use epoxy, glue, etc. and make the device harder to repair, which in my opinion is anti-user.) The whole idea of a closed-source security system the user cannot control is anti-user, and history proves you get the best security by developing a system fully in the open. Is Google's hardware attestation including all hardware components of it fully open? I doubt it.

  (Please note I'm not saying hardware attestation cannot occasionally provide real security benefits. I'm simply saying these are not as big as you may think, and that not allowing the user to choose how they want to keep their device secure but requiring such a proprietary system is a bad idea.)

• Obviously, a Google or Apple account is also a harmful requirement. I don't think I need to explain why.

• A hardware key appears to be the only mechanism that solves all these problems, without a user being required to hand over partial control of their device to third-party controlled anti-user DRM systems.

Stop being misled by big tech propaganda that everyone needs to have a locked down anti ownership smartphone.

---

Also, for anybody external coming by and reading, it seems like the EU just decided to give us the UK Online Safety Act but for the EU: https://digital-strategy.ec.europa.eu/en/library/commission-publishes-guidelines-protection-minors ...which is going to rely on this wallet here.

Using the same kind of language of risk assessment, banning self declaration of age as unsafe, these guidelines are apparently pushing an internet where you need a governemnt id to participate (or to alternatively have your face scanned by Palantir or such) which is dystopian and authoritarian nightmare that would be any future fascist government's fever dream.

Even if you implement these guidelines with a Zero-Knowledge Proof (ZKP) mechanism for age verification, 1. a user can't verify that this is done using ZKP and any update to the verification app could turn this into the perfect citizen tracking mechanism. And 2. a user still needs a digital government id to start with, which already is an anti democracy requirement. (Offering one for convenience as an option isn't a problem, making it mandatory for basic online discourse is.)

History shows there's always a fascist taking control intermittently. Putting such systems into place in advance doesn't seem safe for democracy. Please write about EU's plans here for strict age verification all over the internet, if you're a journalist.

Hello, as a German citizen I'd like to comment on this: While using AppAttest for Apple iOS devices is reasonable, using Play Integrity for Android is not. By requiring Google's proprietary Play Integrity service, you are excluding every Android-based OS that isn't approved by Google. With this, you would essentially be fully dependent on US companies, with no other way to access the EUDI Wallet, which seems highly concerning to me in the current political landscape.

For most users, this surely won't be an issue, but I believe it's very important not to cut off people who are, e.g., privacy/security-focused (GrapheneOS), from this application.

To clarify, Android, unlike iOS, is at its core open source. Due to this, there are many variations of Android. Of course, there are differences between the vendors (Samsung's, Google Pixel's, and Xiaomi's Android versions are all different), but then there are also so-called Custom ROMs. These are often made by smaller communities and need to be installed manually on the device. One big example is GrapheneOS, fully open source, maintained by a Canadian non-profit organization.

GrapheneOS, from a security and privacy standpoint, is better than any other mobile OS, better than iOS or Pixel-Android. To achieve this, GrapheneOS is fully independent of Google and therefore doesn't meet Strong Play Integrity.

But to my understanding, in order to comply with EUDI standards, Play Integrity isn't even needed. GrapheneOS describes an Android-universal alternative working on virtually all Android devices with at least Android 8 (released 2017): https://grapheneos.org/articles/attestation-compatibility-guide. Using this, while still being restricted to OSs for which you have added the verified boot key fingerprints, would achieve independence from US companies. And as described in the GrapheneOS article, both attestation methods could also work together, and if one passes, the app can be used normally. This would create redundancy.

I hope the responsible people understand the need to have a digital ID that works without the approval of US companies — companies that could suddenly decide to stop accepting projects like this, while also cutting off people who use a less-known OS like GrapheneOS.

Of course, it would be better to have a solution enabling all technical devices with the required hardware (Linux, Windows) to be used for digital identification, but this is discussed in other issues, I believe. Replacing the Play Integrity check with the Android Hardware Attestation, or using both and requiring only one to be positive, would at least provide a way to not completely rely on two big US companies when using the EUDI Wallet.

I really hope this will be addressed, as it's vital for digital independence from the United States.

Hi!

I'd just like to point out that your comment can be misinterpreted and clarify a bit: Verified Boot keys don't need to be managed per OEM (but for custom ROMS like GrapheneOS):

• OEM ROM: bootloaderLocked == true && verifiedBootState == VERIFIED --> trusted
• Custom ROM: boootloaderLocked == true && verifiedBootState == SELD_SIGNED && verifiedBootKeyHash in listOfTrustedBootKeyHashes --> trusted, (iff this is agreed upon)

What is much more relevant is device vulnerability management (as Kristina explained in #4 (comment 735094)).
Here is where I want to be explicit about a technical detail: In reality, this will be almost certainly unrelated to verified boot keys, but instead you may blacklist certain device families based on intermediate certificates as part of the attestation certificate chain. This is what Google does (most notably pre-remote-key-provisioning). You are free to be more strict with your attestation checks and maintain your own set of revoked keys in addition to those revoked by Google if, for example, you know about a device family that has an exploitable Bluetooth stack and consider that not secure enough for an EUDIW app. Going out on a limb here, but Google probably won't add such devices to their revocation list, but it could make sense to prevent such devices from running a wallet app (consider a weaponised exploit that exfiltrates your personal data from the wallet app via Bluetooth).

Just to be clear because I do not expect everybody to read the whole thread:

• I am not involved with the German Wallet development
• I commented solely to be more explicit about a technical aspect that could be misinterpreted based on the comment before.
• The examples in my comment are purely for illustration purposes.

This process is still anti ownership and anti consumer, since "listOfTrustedBootKeyhashes" means you can't build your own ROM and boot it. And why shouldn't you be able to? It's a collective brainrot that for smartphones, booting whatever operating system you want, including your own modified versions, is no longer considered a basic accepted freedom.

(I'm aware UEFI has Secure Boot, but the difference is that you can simply turn it off and still do online banking.)

However, I guess it might be acceptable if there is an optional hardware key alternative at least.

Policy was not the topic of my comment.

(edit: glaring typo made it say the opposite)

Hey,

I agree that I would like to see an Alternative to Google or Apple Integrity Checks implemented into the German Version of EUDI Wallet.

Did you here already about https://uattest.net/ - Unified Attestation? I think it could provide a solution for de-googled devices, couldn’t it?

Kind regards

Hi, Unified Attestation certainly is an interesting option. However, as far as I know, it isn't fully released yet and currently remains more of a concept. There is no guarantee it will ever reach operating systems beyond those of the project members. Unless major OEMs (Samsung, Google Pixel, etc.) include Unified Attestation in their Android versions, you would still rely on Google for verifying all but a few European devices.

At a technical level, Play Integrity and Unified Attestation both build on top of the already mentioned hardware-backed attestation but abstract it behind a simpler API. While this is convenient, it also shifts trust decisions to a third party.

In my opinion, a more reasonable approach for now would be to combine the different methods:

First, the native Android Hardware Attestation I (and previously Bernd Prünster) talked about. This is a much more sovereign and transparent way. It would require a little bit of maintenance for a list of trusted self-signed keys of secure projects like GrapheneOS, but would reduce the dependence on Play Integrity.

Second, if this fails, Google Play Integrity (and in the future Unified Attestation) can be used as a fallback if the device's verified boot key isn't included in the database for the native Hardware Attestation, but is still considered secure by Play Integrity/Unified Attestation.

Additionally, as Bernd Prünster pointed out (thanks!), Hardware Attestation would enable to do better-suited device vulnerability management.

This would allow the German EUDI Wallet to work independently of a single provider and create redundancy by using proprietary solutions as a fallback.

I would appreciate hearing the development team's thoughts on this.

(Edited 07.04.26: included Bernd Prünsters comment and clarified the approach)

It would be a start, but it wouldn't solve the dependency on an Android/iOS device itself already being problematic. So whatever happens regarding the Android version, that other problem also should get addressed somehow.

I certainly agree this dependency needs to be addressed (as discussed in #10). However, I see my proposal as a practical and adoptable compromise to first reduce the need for proprietary solutions like Play Integrity. This proposal can be implemented now, without requiring a wider redesign of the concept.

@OC000089341820 Can you adjust the current URL in the issue? It's now https://bmi.usercontent.opencode.de/eudi-wallet/wallet-development-documentation-public/latest/Guidelines/appAttestation/ ("latest/" has been added).