It is so clear how lobbyists operate here. I'd call it undermining national sovereignty.
> unknown system image (e.g. custom ROM)
Oh no, what a horrible crime, somebody dared to modify operating system on their own device..
See also this issue from 2025 where the developers responded: https://gitlab.opencode.de/bmi/eudi-wallet/wallet-developmen...
AFAICT, there is no mention of an Apple or Google account being required in general - the documentation just lists "signals" that are used to securely authenticate a person - such as Google's/Apple's security ecosystems. I am not sure what this means in practice. Can anybody with deeper understanding explain the actual implications and possible outcomes?
(Note: BMI is the German Federal Ministry for the Interior)
If you don’t have an iPhone or an android, you can get a physical one time password device.
It's also ridiculous how it seems we've forgotten computers other than smartphones exist and that not everyone even has a smartphone, let alone with an Apple or Google account.
App attestation does not require an Apple account nor a google account. For Android, it does limit the ROMs to Google certified ones and requires GMS to be installed if Play Integrity is used. An alternative option, would be to use the Hardware Attestation API directly, GrapheneOS would be thanking you.
I've spent a good amount of time implementing exactly this type of system for a backup service.
his document specifies a way to cryptographically attest the integrity of a HTTP request hitting a server.
The attestation proves the request came from a device and attest the legitimacy of the bootloader, OS and app.
Google and Apple are in a privileged position to be able to bypass the app attestation though, so depending on the threat model, it's not bulletproof.
edit: Play Integrity could the worst offender here, as it can be leveraged to force a user to have installed the app through the Play Store. Indirectly, requiring a Google account.
Explanation: https://mastodon.social/@pojntfx/116345725515845020
There is in practice no known way around it for now, and even less so one for regular people, to use this on a device without a Google account
Parents can't control what their children are doing 24/7, and neither should they. But they should expect a society where children are protected from billion dollar corporations stealing their attention and radicalising them, at least until they are old enough to leave mandatory schooling.
There are many "real world" age restrictions that exist, and we have decided those are of benefit to society in general. The "online world" is no different.
If we can't have age restrictions online then they should just be abolished in the real world as well, in the name of preserving "privacy and freedom". The online world doesn't exist in isolation like it did in the 90s and 00s.
The Wallet Unit provides for authentication means which can be bound to multiple identification means, such as the PID, via a public/private key pair, see cryptography.
When issuing the PID, the WB confirms to the PP (via OpenID4VCI Key Attestation) that the keys to which a PID is to be bound are controlled by an authentication means(../05-cryptography.md) that meets certain security requirements with regard to resistance against attackers with a certain attack potential (see ISO/IEC 18045).
Furthermore, in the context of performing electronic identification at assurance level high, such as the PID, it is required that authentication of wallet users is done in accordance with, the requirements for the characteristics and design of electronic identification means at assurance level high, as set out in Implementing Regulation (EU) 2015/1502 (see CIR 2024/2979 Article 5 1. b/g).
Therefore, the authentication means provides two important assurances:
The authentication means protects against duplication and tampering attacks to the key store by attackers with high attack potential. Thus, the PP can be sure that it's issued credentials that are bound to the keys of the authentication mean cannot be duplicated by an attacker with high attack potential and thus the identification means itself cannot be duplicated in their entirety (see CIR 2015/1502 Annex 2.2.1).
The authentication means protects against attacks on the user’s authentication mechanism by attackers with high attack potential. Thus, the PP can be sure that it's issued credentials that are bound to the keys of the authentication mean cannot be misused by an attacker with high attack potential, e.g. for single presentations of a credential (see CIR 2015/1502 Annex 2.3.1).
The first assurance can be achieved by creating and processing the relevant keys in an RWSCD implemented as an HSM that has been appropriately evaluated and certified. This assurance can therefore be achieved independently of the user device.
The second assurance concerns the authentication mechanism of the user towards the relying party when presenting the credential. This includes two-factor authentication of the user towards the RWSCA. The security of the user authentication mechanism and the authentication factors depend on the security of the user device. The solution comprises a possession factor secured by the HKS of the mobile device and a knowledge factor entered via the mobile device.
The security of the possession factor depends on the existence of exploitable vulnerabilities in the HKS of the mobile device that allow the key to be extracted or misused.
The security of the knowledge factor, depends on the existence of exploitable vulnerabilities in the wallet instance and/or the operating system of the mobile device.
A preceding vulnerability analysis and certification of the HKS or the OS with regard to resistance to a specific attack potential, which would significantly reduce the likelihood of the existence of relevant vulnerabilities, is not available for mobile devices in practice. Rather, it can be observed that relevant vulnerabilities have become known for mobile devices in the past.
For this reason, the solution provides for monitoring identified vulnerabilities for the HKS and the operating system of user devices through a mobile device vulnerability management (MDVM) during operation to reduce the likelihood that existing relevant vulnerabilities can be exploited. This is achieved by ensuring that if vulnerabilities are known for a user device that could compromise the user's authentication mechanism towards the RWSCA with a attack potential of ‘high’ or lower, the use of keys secured by the RWSCA/RWSCD is prevented. Thus, the confirmation of the WB to the PP remains valid.
To achieve this goal, the MDVM provides for the following functions:
| Function | Description |
|---|---|
| Verify device/app security posture | Provides verified information regarding device integrity and authenticity, as well as wallet app integrity and authenticity for a specific user device/wallet instance. To achieve this, security functions from the platform of the user device are used, as well as platform independent solutions such as RASP (Runtime Application Self-Protection) solutions. |
| Identify device class | Provides verified information regarding the device model, the operating system incl. version and patch level and the HKS. This could be achieved with the verified information from platform attestations and RASP attestations. |
| Verify vulnerabilities for device classes | Provides up-to-date information on relevant vulnerabilities of the device operation system and HKS of a dedicated device class. |
| Decide on device/app usage | Based on device/app security and vulnerability information, (1) prevent confirmation to the PP via OpenID4VCI Key Attestation if devices/wallet instances are not sufficient secure, (2) prevent the use of RWSCD keys by user authentication with insufficiently secure devices/wallet instances. |
The components and roles for providing these functions are introduced in the decomposition chapter of the architecture.
This chapter provides an overview of the collected signals and their mapping to relevant threats. It also describes additional uses of these signals for plausibility checks and for determining the device class used to query the MDVM databases.
| Signal-Source | Threats | Synergies | Notes |
|---|---|---|---|
| KeyAttestation | rooting via unlocked bootloader, unknown system image (e.g. custom ROM), loss of root of trust (e.g. manipulated boot sequence), app repackaging & tampering & spoofing & downgrading, app cloning, device or HKS emulation attacks, Replay attacks, response reuse, device proxy used to spoof attestations | LPADB, RASP | Used as input for DCVDB, needs LPADB to increase resilience against non-publicly leaked KeyAttestation keys |
| PlayIntegrity | app repackaging & tampering & spoofing, Replay attacks, response reuse, proxy attestations, app downgrade attacks, side-loaded older vulnerable app versions, rooting via unlocked bootloader, unknown system image (e.g. custom ROM), loss of root of trust (e.g. manipulated boot sequence) + Google proprietary backend MDVM verdict to identify compromised devices, Credential theft tools, input automation/bots, overlay attacks (e.g. tapjacking), can be used to enforce security update policies (MEETS_STRONG_INTEGRITY requires a security patch in the last 12 months) | KeyAttestation, RASP | Bootloader state needs to be checked to trust PlayIntegrity verdicts, Unsure how trustworthy → unclear how the evaluation in the google backend works (also known to be often targeted by open source rooting community using leaked KeyAttestation keys) |
| iOS DC Device Check | Replay attacks, tampering with certificate, device proxy used to spoof attestations, app repackaging & tampering & spoofing, leaked debug builds, it's unclear from documentation what additional threats could be mitigated | RASP | DeviceCheck needs additional security measures as it does not attest to the integrity of the device → RASP |
| Leaked Platform Attestation Key Database (LPADB) | rooting based on unlocking bootloader using publicly leaked attestation keys for obfuscation | KeyAttestation | - |
| Device Class Vulnerability Database (DCVDB) | insecure user devices due to publicly known vulnerabilities e.g. rooting/local privilege escalation, TEE, bootloader/chain of trust exploits | KeyAttestation, RASP | DCVDB is only as effective as the identification of the correct device class |
| Runtime Application Self-Protection (RASP) | App Hooking/debugging & Repackaging & tampering, UD rooting & emulation | - | RASP provides a way to continuously and dynamically monitor the app and the user’s device for integrity and authenticity while the app is running. Additionally, it provides an alternative detection framework that operates independently of the platform mechanisms. |
| Signal | Enforcement | Details | Example Value | Mitigated Threats | Additional Usage | Plausibility Check |
|---|---|---|---|---|---|---|
| SecurityLevel | Hardwareenforced | identifies HKS type | TrustedEnvironment or StrongBox | emulation attacks e.g. emulation of devices or key stores | ensure the keys are stored in a secure key storage | used, must always be the same |
| attestationIdModel | Hardwareenforced | identifies device model | e.g. "SM-A146P" for a Samsung Galaxy A14 5G | app cloning | used to identify device class | used, must always be the same |
| attestationIdProduct | Hardwareenforced | identifies device model (alternative source attribute) | e.g. "a14xmeea" for a Samsung Galaxy A14 5G | app cloning | used to identify device class | used, must always be the same |
| attestationIdDevice | Hardwareenforced | identifies device model (alternative source attribute) | e.g. "a14xm" for a Samsung Galaxy A14 5G | app cloning | used to identify device class | used, must always be the same |
| osVersion | Hardwareenforced | identifies OS version | e.g. "130000" for Android 13 | app cloning, downgrade attacks | used to identify device class | used, can only increase, not decrease |
| osPatchLevel | Hardwareenforced | identifies the current security patch level | e.g. "202508" for security patch level August 2025 | - | used to identify device class | used, can only increase, not decrease |
| RootOfTrust. | ||||||
| deviceLocked | Hardwareenforced | identifies the current boot loader state | e.g. "true" if device booted a signed image that was successfully verified by Verified Boot | rooting via unlocked bootloader, unknown system image (e.g. custom ROM), loss of root of trust (e.g. manipulated boot sequence) | - | not used |
| RootOfTrust. | ||||||
| verifiedBootState | Hardwareenforced | identifies the device's Verified Boot state | e.g. "Verified" for fully verified root of trust | rooting via unlocked bootloader, unknown system image (e.g. custom ROM), loss of root of trust (e.g. manipulated boot sequence), emulation attacks | - | not used |
| attestationChallenge | Hardwareenforced | server-provided challenge | max 128 bytes length | Replay attacks, response reuse, device proxy used to spoof attestations | - | not used |
| AttestationApplicationId. | ||||||
| AttestationPackageInfo. | ||||||
| package_name | Softwareenforced | identifies apps that are allowed to use the secret key material under attestation | e.g. "org.sprind.wallet" | app repackaging & tampering & spoofing | - | not used |
| AttestationApplicationId. | ||||||
| AttestationPackageInfo. | ||||||
| version | Softwareenforced | identifies the apps "versionCode" from the build properties | e.g. "1" | app downgrade attacks, side-loaded older vulnerable app versions | - | used, can only increase, not decrease |
| AttestationApplicationId. | ||||||
| signature_digests | Softwareenforced | set of SHA-256 digests of the app's signing certificates | SHA-256 digests in Base64 encoding | app repackaging & tampering & spoofing | - | not used |
Notes:
| Signal | Provider | Details | Example Value | Mitigated Threats | Collect Experience | Plausibility Check |
|---|---|---|---|---|---|---|
| requestDetails. | ||||||
| requestPackageName | OS | Package name the request claims to originate from; Play Integrity verifies it matches the calling app + signing cert | e.g. "org.sprind.wallet" | app repackaging & tampering & spoofing | - | not used |
| requestDetails. | ||||||
| nonce | Wallet Backend | Random value generated by your backend to prevent replay; returned unchanged in the verdict | base64 encoded 16–32 bytes | Replay attacks, response reuse, proxy attestations | - | not used |
| requestDetails. | ||||||
| timestamp | Time when Google produced the verdict | e.g. "1672531199000" (Unix ms) | Replay attacks, response reuse, proxy attestations | - | not used | |
| appIntegrity. | ||||||
| appRecognitionVerdict | Whether the app is recognized as original, unmodified, validly installed | e.g. "PLAY_RECOGNIZED" | app repackaging & tampering & spoofing, side-loading (unintended?) | - | not used | |
| appIntegrity. | ||||||
| packageName | The actual package Google sees executing the request (also from a KeyAttestation) | e.g. "org.sprind.wallet" | app repackaging & tampering & spoofing | - | not used | |
| appIntegrity. | ||||||
| certificateSha256Digest | SHA-256 digest of the app's signing certificate (also from a KeyAttestation) | SHA-256 digests in Base64 encoding | app repackaging & tampering & spoofing | - | not used | |
| appIntegrity. | ||||||
| versionCode | identifies the apps "versionCode" from the build properties (also from a KeyAttestation) | e.g. "1" | app downgrade attacks, side-loaded older vulnerable app versions | - | could be used, can only increase, not decrease | |
| deviceIntegrity. | ||||||
| deviceRecognitionVerdict | Describes device trust level | e.g. "MEETS_STRONG_INTEGRITY" | rooting via unlocked bootloader, unknown system image (e.g. custom ROM), loss of root of trust (e.g. manipulated boot sequence) + Google proprietary backend MDVM verdict to identify compromised devices (we do not know what they are actually doing in their backend) | yes | not used | |
| deviceIntegrity. | ||||||
| deviceAttributes. | ||||||
| sdkVersion | The devices's Android SDK API level (OS Version) | e.g. "33" for Android 13, | app cloning, downgrade attacks | - | could be used, can only increase, not decrease | |
| deviceIntegrity. | ||||||
| recentDeviceActivity. | ||||||
| deviceActivityLevel | integrity token requests on this device in the last hour per app | e.g. "LEVEL_1" to "LEVEL_4" | Bot traffic, emulator farms, proxy device to spoof verdicts | yes | not used | |
| accountDetails. | ||||||
| appLicensingVerdict | Indicates if the app has been installed from PlayStore | e.g. "LICENSED", "UNLICENSED", "UNEVALUATED" | sideloaded APKs without entitlement (unintended?) | yes | not used | |
| environmentDetails. | ||||||
| appAccessRiskVerdict. | ||||||
| appsDetected | List of other apps detected that may capture, overlay, control, or otherwise interfere with your app (screen recorders, overlay malware, automation tools, etc.) | e.g. "KNOWN_CAPTURING", "UNKNOWN_CONTROLLING" | Credential theft tools, input automation/bots, overlay attacks (e.g. tapjacking) | yes | maybe | |
| environmentDetails. | ||||||
| playProtectVerdict | Indicates Play Protect’s assessment of device/app risk | e.g. "NO_ISSUES" or "MEDIUM_RISK" | Using devices with known malware, disabled Play Protect (which is a possible user choice) | yes | maybe |
Notes:
Since we have not yet decided on a RASP solution, the documented detection features should be considered a preliminary set of requirements for potential RASP solutions.
| Detection Feature | Details | Mitigated Threats |
|---|---|---|
| App Hooking/debugging | Monitors for dynamic debugger attachment, library injection, instrumentation frameworks (Frida, Xposed, LSPosed, DobbyHook), and other forms of dynamic manipulation of runtime logic. | Reverse engineering, dynamic runtime manipulation |
| App Repackaging | Detects modifications to the app bundle, re-signing with unauthorized certificates, or injected frameworks before installation. | app repackaging & tampering & spoofing |
| App tampering | Identifies binary patches, altered code segments, unexpected file changes, and modifications to critical logic. | Disabled protections, patched logic |
| UD rooting | Detects rooting indicators such as sandbox violations, privileged file access, injected toolchains, and elevated OS capabilities. | Privilege escalation, unrestricted hooking, bypass of integrity controls and sandbox isolation |
| UD emulation | Detects execution in virtualized, automated, or non-real hardware environments through system behavior checks and hardware consistency verification. | Automation fraud, bot attacks, spoofed devices |
Notes:
| Signal | Provider | Details | Example Value | Mitigated Threats | Plausibility Check |
|---|---|---|---|---|---|
| attestationObject (x5c) | Secure Enclave + Apple attestation servers | CBOR object that proves the App Attest key was generated in a SecureEnclave | Binary CBOR structure | Replay attacks, tampering with certificate, it's unclear from documentation what additional threats could be mitigated, might also identify app repackaging & tampering & spoofing, device emulation, tampered runtime, jailbroken(rooted) OS | not used |
| credentialId | Secure Enclave | 32-byte opaque identifier for the App Attest key generated in the Secure Enclave | Base64 string | Key cloning or device proxy used to spoof attestations | used, checked against assertion |
| clientDataHash | Wallet Backend | SHA-256 hash of your server-provided challenge | 32-byte digest | Replay attacks, response reuse, device proxy used to spoof attestations | not used |
| RP ID | OS + Secure Enclave | your app’s App ID prefix, a period and your CFBundleIdentifier | e.g. SHA‑256( TeamID + "." + BundleID ) | app repackaging & tampering & spoofing | not used |
| environment (aaguid) | OS + Secure Enclave | Indicates whether the key is from "development" or "production" environment | e.g. "production" | leaked debug builds | not used |
| counter | Secure Enclave | counts how many times the key has been used to sign, MUST be 0 for attestations | "0" | It is unclear what the implications are if the counter is not equal to 0 | initially stored to populate DB |
Notes:
| Signal | Provider | Details | Example Value | Mitigated Threats | Additional Usage | Plausibility Check |
|---|---|---|---|---|---|---|
| assertionObject | Secure Enclave | CBOR object containing signature over challenge + state with the App Attest key | Binary CBOR structure | Replay attacks, tampering with certificate, it's unclear from documentation what additional threats could be mitigated, might also identify app repackaging & tampering & spoofing, Device emulation, tampered runtime, jailbroken(rooted) OS | - | Must validate signature with attestation public key |
| keyId (matches credentialId) | Secure Enclave | Identifier of the App Attest key used to sign the assertion | Base64 string | App cloning, device proxy used to spoof attestations | - | Must match known attested keyId (credentialId from attestation) |
| clientDataHash | Wallet Backend | SHA-256 hash of server-generated challenge and optional payload | 32-byte digest | Replay attacks, response reuse | - | not used |
| RP ID | OS + Secure Enclave | your app’s App ID prefix, a period and your CFBundleIdentifier | e.g. SHA‑256( TeamID + "." + BundleID ) | app repackaging & tampering & spoofing | - | not used |
| counter | Secure Enclave | counts how many times the key has been used to sign | "42" | Replay attacks, response reuse, device proxy used to spoof attestations | - | The counter is required to increase monotonically. Big jumps could indicate app/device is used to proxy attestations for other app/devices, lower value then recorded point to a replay attack |
Since we have not yet decided on a RASP solution, the documented detection features should be considered a preliminary set of requirements for potential RASP solutions.
| Detection Feature | Details | Mitigated Threats |
|---|---|---|
| App Hooking/debugging | Monitors for dynamic debugger attachment, library injection, instrumentation frameworks (Frida, Substrate), and other forms of dynamic manipulation of runtime logic. | Reverse engineering, dynamic runtime manipulation |
| App Repackaging | Detects modifications to the app bundle, re-signing with unauthorized certificates, or injected frameworks before installation. | app repackaging & tampering & spoofing |
| App tampering | Identifies binary patches, altered code segments, unexpected file changes, and modifications to critical logic. | Disabled protections, patched logic |
| UD rooting | Detects jailbreak indicators such as sandbox violations, privileged file access, injected toolchains, and elevated OS capabilities. | Privilege escalation, unrestricted hooking, keychain access, bypass of integrity controls. |
| UD emulation | Detects execution in virtualized, automated, or non-real hardware environments through system behavior checks and hardware consistency verification. | Automation fraud, bot attacks, spoofed devices |
Notes:
Also the EU and all those states are also highly incompetent and pretty much only depends on low quality contractors. For example there is very little discussion and info about the fact that the EU digital infrastructure just got owned by what seems to be a random hacker group [0].
- [0] https://cyberalert.com.pl/articles/shinyhunters-eu-europa-br...
The MitID design is strange, but in this regard it is well done.
This was more than 30 years ago. Now we have a great culture of overregulation.
Contrast that with chat control.
My government can read my WhatsApp messages? Not good!
What’s the non-technical narrative here?
Like every school shooting, every energy crisis brings opportunity to saturate the airwaves with shallow noise that gets people overly upset and they’ll ignore everything else.
Every player on both sides is abusing this mechanic for all eternity.
You're linking to a bugtracker. I doubt they're inviting people to spam it with duplicate entries — valid as I think the concern is. But maybe it says somewhere that you can leave feedback here and I just haven't seen it?
You write it as if companies provided tons of help to parents and children. Meanwhile, they spend a lot of money to make it as hard as possible.
Second, kids in Germany have generally a lot more freedom and there is less of knee jerk impulse to blame parents for every accident. Expectation is that adults dont harm them without parents having perfect control every sevond.
Great, I can pay with a digital Euro, Wero or something else, without routing my payments via VISA. I just can't do it without an account with Apple or Google. I'm absolutely baffled by politicians, regulators, banks, merchants and implementors lack of ability to think more than one or two steps out.
Sure, the EU is forcing 3rd. party app store, but no one is using them, so no one is pushing apps to them, especially not governments, banks or payment services, they'll be the last to use them.
> Get banned from society for life
What worries me is that it's a real global problem in all of our non-autocratic societies. On a positive note, I can see how this is actually becoming a common understanding and gaining traction, as hyped AI products are seen by some as 3rd-party- or SaaS-killers. It seems like we know how to differentiate between independence and dependence, and evaluate any risks affiliated with such a decision. But it baffles me that this differentiation manages to float as some ironic stream in our Zeitgeist, and just barely manages to be taken seriously.
From their README:
> We are interested to receive feedback on all aspects described in the document. To provide feedback, please file an Issue on OpenCoDE.
https://gitlab.opencode.de/bmi/eudi-wallet/wallet-developmen...
[1] Maybe with cash, for now, but cash is clearly not long for this world, and your bank account will be inaccessible already.
Public debate and assessing politicians and parties would be so much cleaner then if they couldn't use polarizing issues to rally their support and do w/e they please on all other issues.
At least their version has an obvious solution: Make electric cars and solar panels and then stop having oil problems.
electronic IDentification, Authentication and trust Services
A: exclude these people from society or force them to switch to big tech, and
B: accept the consequence where a single other country holds access to everyone's identity information for convenience reasons (because it works for the 99% that are too tech-illiterate to install software that they control instead of the other way around)
I don't think it's a bad idea though. If only for bringing the issue to the public
And while I do think an alternative would be good, the fact is that protecting the private key is the most important part (for example by keeping it on a smartcard with NFD) - hence why the need for a secure device
"but I want to install alternative Android etc etc" yes that's fine - but you know this is a non-secure-(enough) env.
That's just not possible, or should the system be legally required to run on an Apple II?
As an example, an EU citizen working in Sweden should be able to submit Swedish tax forms whilst living here by using a digital identity from the originating nation.
There are also some standards in place like ETSI standardized extensions to PDF signatures so that you can verify that a signature inside the PDF was actually signed by a specific physical person (the standard is there but it's not fully used throughout the EU yet due to some legacies).
Implementation is a bit of a mess still but things are converging.
To me, there is no difference between your sentences. You require the blessing of an American company to be able use eIDAS. Google has the power to disable eIDAS at a national scale by making the attestation services treat all devices as not certified.
There should be NO reliance whatsoever on a private company not under the control (direct or indirect) of the government let alone a foreign private company.
Edit: I just noticed your username and the fact that your account is very new. Are you astroturfing?
These days an ID system that doesn’t work online is next to useless.
This may not be unwelcome for authorities considering the recent extrajudicial “unpersoning” of many political enemies in the EU.
The issue isn't the phone, it's that a __government__ is depending on an unregulated private enterprise.
Wero however is currently only planned as an android/ios app period. There are rumors that a card will come but that's only rumors for now.
In your list of groups to be baffled about I would add journalists. You see many articles about Wero mentioning digital sovereignty, but have you seen any that criticize the required banking apps only being available in google's and apple's app stores?
Gladly.
There was a time window 2 years ago where it appeared that I need an actual phone number to do my taxes, but even that was replaced with something more universal.
Everyone is trying to cut costs so as to be able to compete there and Europeans are paying the cost of financing this.
Personally I'm going to wait until the average car age in China crosses the 10-year mark to get a new vehicle. Until that happens there will be no incentive to think about longevity.
Although it is a more recent development since a certain billionaire (what else) took up politics as a side hustle.
I don't think we can win this fight. Personally I tried to advocate against eIDAS in Austria and I've had negative success. After my warnings, people like it more.
"Oh, it's an EU thing? it must be good!".
So far the best modern improvement I’ve seen (and it could be further improved of course) is the increasing use of citizens assemblies.
The regulations sometimes feel like additional burden of the user, but not for the manufacturers (aside for the attestation logic); consider:
> (MEETS_STRONG_INTEGRITY requires a security patch in the last 12 months)
Think about how this essentially codifies planned obsolescence due to not forcing the manufacturers to maintain the devices for life.
The technical solution is a hardware root of trust. This is typically a specially hardened chip in the device. A Trusted Platform Module (TPM).
Your Apple ][ does not have a TPM. It cannot run software that can assess it's identity in a trusted manner.
Several paid providers for X.509 certificates exist but document signing certificates cost around 80 € per year [0]. And if I want duplicate X.509 certificates for my redundant Yubikeys then the cost doubles.
Other providers require an initial deposit and then charge per signature [1], which leads to intransparent pricing. In the interest of open commerce, I strongly believe that securely signing an electronic document should cost the same as my manual signature, i.e. nothing.
A partial solution already exists because I can use my electronic ID card with the AusweisApp to prove my identity when interacting with German authorities. This feature is generally useful because I live outside of the EU, but I especially appreciate that I can have my OpenPGP key signed by Governikus (a government provider) to prove the key belongs to my name [2].
Technically, I should be able to use my certified PGP key to sign documents, but in practice most non techies don't know how to validate my signature. For the average user opening my signed PDF in Adobe Reader, I would need an X.509 certificate from a trusted Certificate Authority for users to see the green check mark.
[0] https://shop.certum.eu/documentsigning-certifcates.html
[1] https://www.entrust.com/products/electronic-digital-signing
The problem with modified phones containing malware is very real and unless you want a full on Apple "you're not allowed to touch the OS" model you need some kind of audited OS verification that you as a user or a security sensitive software can depend on.
Yes and if you look back this is not new. Just look at the extraordinary restrictions that apply to:
- What houses you can build,
- What vehicle you can drive,
- What food you can grow and sell.
The result is real estate has become unaffordable for younger people, our car industry is being annihilated, and the agriculture sector hold by a string.
The digital realm enjoyed an unusual level freedom until now because the silent and boomer generations in charge in the EU understood nothing about it.
Now that the EU is getting involved in "computers" we are starting to understand why peasants have been protesting in Brussels and calling those people insane for decades.
But then to save cost including the support cost banks stopped and instead started to require a non-rooted Android/iPhone.
If only currently popular platforms are to be supported, how could a new platform join them in the future if the use of existing ones is mandated by governments?
No I do not. It is plenty secure compared to a corporate version and nobody should be legally able to deny service over me having control over my own computer.
Needing the entire OS to be secure to protect a key is also a dumb idea in general.
I feel like this is getting to the point of gaslighting. Many of the allowed devices are bargain bin Android phones running out of date software with known vulnerabilities in both the operating system and the hardware which is supposed to be protecting the keys.
Meanwhile you could be using a hardware security module in a bank vault in a nuclear bunker surrounded by armed guards and the excuse would be that this "isn't secure" because it hasn't been approved by Google or Apple.
Governments shouldn't be requiring you to use any specific vendor or set of vendors. They should be publishing standards so that anyone who implements the standard can interact with the system.
Slovenia hands out certificates for online government services, including document signing, and it seems to be going fine, with the added benefit that Google can't take away my access.
- someone sends you a docusign link
- you sign up with your email
- you sign with your name in a cutesy font
Theres a dispute? Well it was going to end up in court no matter how you signed it anyway. This has all the hallmarks of a design by committee project by people whose salary is paid regardless of demonstrating market fit, productivity, usage, plain sensibleness...
App attestation can fail on simulators, Graphene OS, dev builds, I've seen it all. There is one check you can do to see if an app was side loaded, so indirectly, can require Google account.
Title is still misleading though, as it explicitly mentions accounts.
But in pure technical & UX terms, you don't need to be logged in.
I assume this should be "intra-EU"? I'm not very familiar with eidas so I'm not sure, but afaik it's about signatures within the EU, not between different EUs (as there is only one in this world). (I hate this inter/intra wording, always have to translate it in my head to understand whether it's like internet (between networks) or like intranet (within a network). Would recommend using "within-" instead of intra whenever it's not already a well-established word, like intranet)
They might have some great software _somewhere_ but I have yet to see it.
It does not have good UX because good UX was never the objective.
But then again, maybe there is nothing that can be done. It boggles my mind that even on HN most people are defending this. It seems like freedom is a completely lost cause.
You are hoping "good minority" will get its way ahead of "evil majority" in indirect democracy but if anything I see the reverse happening in a lot of Western countries today.
Taking speed limits and road safety in general as example I feel vocal minority of car enthusiasts are holding the silent majority hostage and that's the reason we don't have more sensible regulation in a lot of EU countries.
What does this "crimes against currency" mean? I live in several countries at once with different currencies, and I never had a problem with this. And top of this, I travel a lot. I have accounts in 5 countries, in 6 currencies. Should I pay attention to something?
Also, that same lifestyle is based on ignoring externalities applied to commons and/or events happening “somewhere else”, even when factually proven. Little wonder and tiny bit ironic that the same principle has embedded itself so deeply, that it holds true even when the damage is inward, just a few indirections away.
On your side, yes, I think that “people in Europe” intuitively understand that, it just needs time to blossom. The reputation/trust damage self inflicted by the current US administration is triggering a pushback that will expand into the future. As a point in case, it will lead to reconsidering assumptions on habits that many generations of US businesses and diplomats have built.
Many in this thread point at difference instances of services that should be decoupled. Connecting the dots, the larger picture looks painfully obvious to me: Silicon Valley never was a partner to be trusted, and certainly not after they built or bent every business to rely on an ad ecosystem that exploits users.
That original sin, on which a huge portion of Wall Street rests, is now at the center of discussions. Hence, the EU will build tools to address this because it has to, but consumers will flock to them especially from the US, since at this point no one can trust SV companies on data privacy (since Snowdens at least), no one can trust the US administration to protect citizens (since Trump at least), and about half of the US is scared about what’s going on deeply enough (the emotional push needed to break the habit). They will move their data it the EU (where else? China?).
This will be compounded by the fact that everyone tries to build better LLMs and to get AGI, while forgetting that LLMs work on data pipelines.
When you realize the tiny tiny percentage of people that have a phone that is not apple or google, you understand why few people are up in arms.
It simply doesn’t affect many people.
Play Integrity could the worst offender here, as it can be leveraged to force a user to have installed the app through the Play Store. Indirectly, requiring a Google account.
https://www.ausweisapp.bund.de/en/open-source I just saw that it's available in alpine.
So I tried installing it on my postmarketOS smartphone and it runs out of the box: https://i.imgur.com/nRIAyrq.png
My Shift6mq is listed has not having NFC support in postmarketOS, so I can't actually test it, but I assume the USB card reader option will work once it's supported.
But I think there are still cell operators without sim card
This is the final step in the road to full remote attestation, thankfully PCs already come with Microsoft Pluton chips[1] to make it easier.
[1] https://learn.microsoft.com/en-us/windows/security/hardware-...
The big question is how to let users properly handle their certificates so they won't get abused into being useless.
If I understood it correctly, the German current Ausweissapp seems to require NFC to read it from your personal id card together with a PIN code you got with the card, it's not entirely user-friendly since aligning the card with your phone seems to be prickly.
Swedish BankID handles it internally in their app (unlocked via PIN's) but they don't have a good way to use it to sign things (It all relies on the infrastructure even if they give out signature documents it's not compatible with pADES).
There's a new govt sponsored one that I assume will piggyback on the personal cards/passes that are readable via NFC.
Norway and Denmark iirc supports proper signatures but I don't think the certificates are under user control (someone correct me if I'm wrong here).
Now these things are mostly issues for document signatures, authentication is often handled via other flows.
What I skimmed from the article, it seems to be more in line with Swedish BankID and is actually fairly smooth for end users even if less secure than what they have now with Ausweissapp.
Eidas tries to harmonize these implementations across EU member states.
The fact that it's ALWAYS a docusign is the ridiculous part. It is just a glorified where you enter your name and email. No need to pretend otherwise. Any other service would be just as good. This is basic human sheep-like behavior?
Can I also send the Docusign document via Signal without Docusign knowing the person who signs it?
Because that is what the eIDAS is supposed to deliver on top of cryptographic validation of signatures.
And this malware is largely based on open source code (Linux) that was originally developed on open, documented hardware, where the firmware boot loader did nothing more than load the first 512 bytes of your hard disk to address 0x7c00 and transfer complete control to it.
Yes, there were viruses that exploited this openness, but imagine if Linus Torvalds would have needed a cryptographic certificate from IBM or Microsoft to be allowed to run his own code! This is basically the situation we have today, and if you don't see how dystopian this is, I don't know what more to say.
I will never understand why such an overwhelming majority of people seem to just accept this. When frigging barcodes where introduced, there were widespread conspiracy theories about it being the Mark of the Beast -- ridiculous of course, but look at now where in some places you literally can't buy or sell without carrying around a device that is hostile to your interests. And soon it will be mandated by the state for everyone.
Google must be destroyed.
Austria's courts also ruled ages ago that rooting your own device cannot be a legal reason for OEMs like Samsung to refuse warranty coverage, since you can run whatever software you want on hardware you bought.
Maybe your country sucks? Don't blame it on the EU.
The viable solution for that is to provide a trusted hardware implementation that can be used with any computing platform that has a documented interface. It can't be a software-only implementation, basically.
Yeah you could, but most people won't
Should they allow for a yubikey on a non-google phone? Or your own private key? Yes they should. But then there's the issue of enrollment, etc.
Whereas if the collar is touted as fashionable and the lock is hidden until it's engaged, now your problem is not that people don't care, it's that they don't know, which is different.
This barely even seems like the relevant part. If Google was founded in Japan and Apple in Brazil, it would still be foolish to entrench them as a dependency. It would barely even be better to do it with a local company.
> They will move their data it the EU (where else? China?).
This feels like hopium. Network effects are powerful and as long as the internet is actually global, there are really only two options: 1) Centralized megacorps, and then the US ones have both the US apparatus behind them and the incumbency advantage, or 2) open protocols where no corporation of any nation is a gatekeeper.
So for Europeans to get the hooks of the US incumbents out of them, their best chance by far is the second one, and that one is also mostly to the advantage of the Americans who aren't the existing incumbents, which is why it works. Start making phones with open hardware and social networks with open protocols and you can get people outside of your own country to use them because they don't much like the incumbents either, and that's how you reclaim the network effect. Try to clone the US megacorps without the US apparatus to get them established in other countries and they don't because they're wary of foreign central control, which in turn means you don't get the network effect and you lose.
But then it's not so much that data ends up in "the EU" as that it's on your own device and then backed up or distributed as encrypted chunks in a distributed network which isn't tied to any specific jurisdiction.
And here we can simply examine the tax structure and conclude that the problem isn't whether the country sucks, but whether the side you're on sucks.
After all, how can housing be affordable for ordinary workers if they have to subsidize from their own pocket free university, cheap housing, electric cars, high wages, and everything else for the privileged class?
> Maybe your country sucks?
And maybe your country sucks too. It is just North Korea is also the best country to live in (if you're Kim Jong Un).
Countries have centuries of experience providing attestation services through notaries. Germany is even infamous for requiring them for things that would sound ridiculous even in Brazil (both movie and country)
I can’t see why governments couldn’t incorporate this existing infrastructure into the digital world. Make them sell hardware ID wallets, enforce the real identity owner to be present to invalidate a previous ID or whatever, and add legal restrictions for the government not be able to alter these registries
But to remove that incentive you first need to stop punishing app companies for compromised user OSes from legal perspective.
Are you willing to absolve Google, Apple and Deutsche Bank from responsibility of damage that happens on compromised user OSes?
Which was the motivation for cryptographically attesting the boot process and OS, and in part paved the way for app attestation.
There are alternatives though: The Android Hardware Attestation API enables attestation on custom ROMs, but the attestation verifier needs a list of hashes for all "acceptable" ROMs. GrapheneOS publishes these but there's nobody, to my knowledge, maintaining a community list.
While enjoying a high paying job in probably a still very unregulated domain (computers/internet related).
This is not about one country vs another.
The problem is you cannot have a society with everybody winning on both fronts unfortunately. You also need people making, cleaning stuff, growing food, cooking, etc. Not everybody can live in the capital with "very cheap all electric state-subsidized rental car" and Vienna is probably not food self sufficient...
When something is required by law, it needs to work for all people.
It also specifically needs to not entrench incumbents by impeding the ability of challengers that don't currently have market share from ever getting any.
> Should they allow for a yubikey on a non-google phone? Or your own private key? Yes they should. But then there's the issue of enrollment, etc.
There is no such issue because enrollment should be part of the standard so any device that implements the standard can be enrolled.
I’m just saying there are not many people impacted, so there are not going to be many people making noise.
People are simply too deep in the trenches of day to day to object to things that don’t impact them personally
You can give your physical cards to other people or give them access to your computers, too.
> Germany is a strict liability country, and you will be fined or imprisoned for anything that is done with your identity card that was cloned because your PC was infected by malware if you don't report it stolen.
I don't see an issue with this.
Google details new 24-hour process to sideload unverified Android apps (1196 points, 16 days ago, 1262 comments) https://news.ycombinator.com/item?id=47442690
Open protocols are kind of thing techies do when in cooperative mode, when industry isn't looking. But this is not this kind of problem - this is an economic, geopolitical problem. It's not about your local school moving off Windows to Linux, it's about the European corporations moving off Azure to some other cloud solution offered by European corporations (do we even have any?).
I'll grant it, the turmoil of such transitions is a perfect moment for pushing for open protocols, federated solutions, etc. - the industry is distracted, there's more space to sneak in some good solution before everyone notices, and EU has cultural and political tradition of pushing towards FLOSS (even if largely just as an alternative to Microsoft) and associated values/memetic complex. But open anything won't save the day - more corporations will.
It's a blind spot for some software folks, because they forget that FLOSS is an exception here; everything else in the real world - including computing hardware and supporting power and network infrastructure - plays by rules of market economy, with proprietary solutions and clear structures of ownership.
It makes no sense to try and fight this here - but it does make sense to go along with the flow and improve things by pushing for more globally optimal solutions, especially that EU is known to be favorable to using openness in protocols and standards as a policy vehicle, both internally and externally.
> But then it's not so much that data ends up in "the EU" as that it's on your own device and then backed up or distributed as encrypted chunks in a distributed network which isn't tied to any specific jurisdiction.
100% i launched into a long trajectory from the comment i was originally answering to, and stopped short
i think-of? dream-of? try-to-build? what you just said
my "in the EU" claim is mostly around legislation (EU art 8 vs US CLOUDS act vs vs China approach to citizen's data)
the legislation is there, since GDPR it's a matter of tools
since corps built tools, they "forgot" to add the third button on cookie banners: "give me back my data" ... (and fourth: "delete it") but the legal framework is there, as well as most of the tooling (google takeout, and so on from all other major players)
it's not that pipelines for moving data from US corps to inidividual do not exists, it's more that, up to now, whenever i was talking about "data rights" to people, even in tech, i got yawns back
now we have a "perfect storm": distrust towards US (administration, collpasing onto US businesses) + global uncertainty towards AI (where lots of people just perceive something happening but lack any tool that gives them control over it)
this is what i perceive as a tectonic shift that can be used innovatively, by EU businesses, hopefully leveraging open
for completeness, i have indeed wrapped "EU" as the spearhead for this, given the incentives to build it, but yes, central authority over this should live inside of each citizen nation framework (see, Japan and South Korea, both providing legal frameworks for data protection)
Cryptographic attestation is not a problem in itself, the problem is exactly what you already somewhat hinted at: it's who and how decides who to trust and who gets to make (or delegate) the choices. You can make a secure system that lets the user be in charge, but these systems we're discussing here don't (and that's by design; they're made to protect "apps", not users).
No, but Austria is. And our farmers enjoy much support through subsidies - from the EU and our own budget - and social protections, often having better and cheaper health care than most other Austrians, since they are insured under their very own social insurance law (BSVG), contrary to other employees (ASVG) and self-employed (GSVG).
Farmers also enjoy very high levels of respect and appreciation here, even in Vienna.
> While enjoying a high paying job in probably a still very unregulated domain (computers/internet related).
Calling Information Technology an 'unregulated domain' in the EU when we're all busy implementing NIS2 regulation and preparing for the Cyber Resilience Act entering into force soon seems disingenuous.
In the past, when you had a proprietary tool you needed to use to do something, people could analyze and reimplement it. The reasons to do that varied - someone needed "muh freedomz", someone else wanted to do the thing on an unsupported platform, someone else wanted to change something in the way the tool worked (perhaps annoyed by paper jams)... Eventually you could end up with an interoperable FLOSS reimplementation. This has happened with lots of various things - IMs, network service clients, appliance drivers, even operating systems, and this is how people like me could switch away from Windows and have their computers (and later phones) remain fully functional in the society around us, perhaps with minor annoyances, but without real showstoppers.
Remote attestation changes this dynamic drastically. Gaim (Pidgin), Kadu couldn't be made if the service provider like AIM, ICQ, Gadu-Gadu etc. could determine whether you're using the Official App™ from the Official Store™ on the Official OS™ and just refuse to handle requests from your reimplementation. They could still try and be hostile to you without it, and often did, but it wasn't an uneven fight. Currently we're still in the early days and you can still go by in the society by defaulting to use services on the Web, using plastic card instead of phone for payments etc. but this is already changing. And it's not just a matter of networked services either - I bet we're going to see peripheral devices refusing to be driven by non-attested implementations too.
Secure boot chains have some value and are worth having, but not when they don't let the user be in charge (or let the user delegate that to someone else) and when they prioritize the security of "apps" rather than users. The ability for us as users to lie to the apps is actually essential to preserving our agency. Without that we're screwed, as now to connect ourselves to the fabric of the society we'll need to find and exploit vulnerabilities that are going to be patched as soon as they become public.
Scaleway and OVH? Although I’m not sure how they compare at scale to AWS / Azure / GCP.
i am not advocating for a pure "open source will save the world" there are just a few points i'd like you to consider, and hopefully give me insights i can learn from
* other than code, open source has also given us governance "experiments" capable of running critical systems. As another poster was mentioning, the risk is to fallback on "big corps", usually run by "big man", and we are back to zero. The hope? expectations? is that the open source governance ecosystem has tackled this space in enough dimensions to be able to build something over this. I am looking specifically at the area around licenses (mariadb, redis, ...) and just overall governance frameworks, as in "deteach business ownership from ethical frameworks"
* in order to build anything this big/reliable, without megacorp budgets, you can just ... pay FLOSS? They are one of the 2 majorly screwed groups by the current SV setup (with PLENTY of cavaets,amongst them that SV is a huge open soure contributor) The other one being content creators. Slogan? "For this to succeed, you need the best coders and the best marketing departments in the world" Looks to me like incentives are aligned towards them being available. Talking broadly on a systemic level: details need refinement, and space beyond this single message.
* EU (the political instituion) desperately needs this. An innovative tech ecosystem (not startup, not product) driven by "european values" that puts them on the spot. Start with redefining it: there are no users, but citizens. Something effectively out-innovating SV, not just trying to get on par. The risk of "being bought out/copied" doesn't really apply, since (as I said in my original comment) the discriminator is existential: US companies cannot be trusted because they built the existing system. Any attempt to block this (stop users from getting their data back) is going to be challenged by the EU (GDPR violations cannot be brought to court by citizens, only by nation's data authorities, which means a citizen gets big guns and doesn't ned to pay). Also, go on and explain that to all you other (US and not) users.
* A EU cloud provider doesn't have to provide the same services an US provides. That would hardly be innovative. You also don't need to focus on corporations. Provide data storage for citizens, that will be the basis to build a privacy focus cloud, and then business might want that. There is a possible continuation into "advantages of storage&privacy based vs compute", that i skip.
But essentially, to me it seems that an open source, true, "give me back my data" business driven initiative has never been as actionable as now. I short, such a project can make 2 bold statements "We are more innovative than SV" "We have better freedoms than the US"
Yes, thanks. This was my original point "the agriculture sector hold by a string". It is by design unsustainable and if you cut those "high levels of subsidies" it collapses.
> Calling Information Technology an 'unregulated domain' in the EU when we're all busy implementing NIS2 regulation and preparing for the Cyber Resilience Act entering into force soon seems disingenuous.
Yes this is why I said "still"
The same freedom is being abused by malicious actors. Even on Windows (like BlackLotus), but also on pre-infected phones emptying people's bank accounts. This is an incredibly unfortunate outcome, but what's the solution?
I see no other potential outcome than that free computing and trusted computing are going to be totally separate. Possibly even on the same device, but not in a way that lets anyone tamper with it.
EVs are just mechanically much simpler, with a shorter BOM that largely centers around Asian (particularly Chinese) battery, REE, and semiconductor supply chains, so hundreds of thousands of good jobs that supported Germany's industrial model are now economically obsolete.
This is no different to subsidizing public transport, because having this infrastructure local and autonomous is just strategically important enough for the tax payer to finance it. Would you say that public transport in EU capitals is "holding on by a string"?
Most importantly - it's the user who needs to know whether their system has been tampered with, not apps.
False analogy. You can’t have your kitchen knife exploited by a hacker team in North Korea, who shotgun attacks half of the public Internet infrastructure and uses the proceeds to fund the national nuclear program, can you? (I somewhat exaggerate, but you get the idea.)
> Systems can be secure and trusted by the user without having to cede control
In an ideal world where users have infinite information and infinite capability to process and internalize it to become an infosec expert, sure. I don’t know about you, but most of us don’t live in that world.
I agree it’s not perfect. Having to use liquid glass and being unable to install custom watch faces is ridiculous. There’s probably an opportunity for a hardened OS which can be trusted by interested parties to not be maliciously altered, and also not force so many constraints onto users like current walled gardens do. But a fully open OS, plus an ordinary user who has no time or willingness to casually become a tptacek on the side, in addition to completely unrelated full-time job that’s getting more competitive due to LLMs and whatnot, seems more like a disaster than utopia.
Some countries do :) Though I think physical analogies are misleading in a lot of ways here.
> Systems can be secure and trusted by the user without having to cede control, and some risks are just not worth eliminating.
Secure, yes, trustworthy to a random developer looking at your device, no. They're entirely separate concepts.
> Most importantly - it's the user who needs to know whether their system has been tampered with, not apps.
Expecting users to know things does a lot of heavy lifting here.
Isn’t the status quo, that you need to intentionally choose to allow this?
It's also really incredible how people can see "user being in control" and just immediately jump to "user having to be an infosec expert", as if one implied the other. You can't really discuss things in good faith in such climate :(