Live data from Hacker News

German implementation of eIDAS will require an Apple/Google account to function

bmi.usercontent.opencode.de

611–620 of 674 posts

Re: German implementation of eIDAS will require an Apple/Google account to function

#611
post #567

Earlier quoted context omitted.

> The initial limitation to Google/Android is not great, we know that, and we have support for other OSs on our list (like, e.g., GrapheneOS). GrapheneOS uses standard Android APIs for hardware attestation (as opposed to Google-specific ones), so why don't you just use those from the get-go?

They did. This is why Graphene works.

Call me confused. The comment I was responding to is saying something different:

> The initial limitation to Google/Android is not great, we know that, and we have support for other OSs on our list (like, e.g., GrapheneOS).

Re: German implementation of eIDAS will require an Apple/Google account to function

#612

Earlier quoted context omitted.

One important feature of a legal ID is that it's hard to copy, so attestation from the hardware storage would have to be basically mandatory. But yeah, the user could have a choice to this extent.

You can attest that cryptographic key material is safely stored without attesting that their operating system and software running on it is all government-approved. That's what smartcards like Yubikey do, my government certificate is on it and it can't be exported. They could attest that but beyond that, the operating system of the host device is none of their business.

> You can attest that cryptographic key material is safely stored without attesting that their operating system and software running on it is all government-approved.

There's no proper way of doing so on Android.

Some countries, like Estonia, are providing their own SIMs to solve this problem. That indeed works. Unfortunately phones are being made that are eSIM-only and certifying eSIMs to the same EAL level is near-impossible.

Re: German implementation of eIDAS will require an Apple/Google account to function

#613
post #598

Earlier quoted context omitted.

Now you can't bundle malware deep within the system "ROM" unless you want to break SafetyNet's attestation. It's a big change in that aspect.

Custom ROMs tell you that this is not true at all.

Custom ROMs no longer pass SafetyNet attestation, which apps such as banking ones (or streaming service ones) check.

Re: German implementation of eIDAS will require an Apple/Google account to function

#614

Earlier quoted context omitted.

> You could run a modified client that lets you assume any identity you choose Provided you know the secret key to a government-issued certificate. Making it impossible to copy said certificate is not really a requirement for identity verification.

Some countries fixed it already, see Estonian ir Polish IDs with digital layer (performing signing, authentication, etc), and the devices only acting as untrusted interfaces to these.

It’s still impossible to extract an Estonian certificate from the smart card (or Mobiil-ID/Smart-ID), no?

Re: German implementation of eIDAS will require an Apple/Google account to function

#615

Earlier quoted context omitted.

> what you quoted was about the user getting informed whether their system is compromised, which is the job of a secure boot chain User being informed means they have to know what a compromised system would entail. That alone is a huge and frankly impossible thing to expect from regular people. > Most users won't even be bothered to choose and that's fine too, but with remote attestation, it's not the user who decide…

> That alone is a huge and frankly impossible thing to expect from regular people. The systems used by regular people could just refuse to boot further when detecting a compromise, so I'm not sure where this comes from. We have prior art for that too. This is still orthogonal to letting users who want to patch things patch them, and not letting the apps verify what environment they run in. It's all compatible with ea…

> This is still orthogonal to letting users who want to patch things patch them, and not letting the apps verify what environment they run in. It's all compatible with each other, and with both regular and power users.

No, they're fundamentally opposed to each other. The entire point is that developers don't want their apps patched by just anyone, especially not malicious actors. Small minority of power users will inevitably get caught in the crossfire.

> Somehow we could for decades. Whether we'll still be able to in the future depends only on how much noise and friction we'll make about it now.

No, you really couldn't. Past lack of technical means doesn't mean anyone trusted your device nor that we had use-cases where this was important. (It was also usually solved with external hardware, physical dongles and whatnot.)

Re: German implementation of eIDAS will require an Apple/Google account to function

#616

Earlier quoted context omitted.

I’ve just had another, completely stupid but not implausible, idea: > a local internal WSCD, which is a component within the User device, such as a SIM, e-SIM, or embedded Secure Element, So you could issue SIM-cards / eSIM profiles that only do signatures and nothing else. The app then connects to such eSIM (and you keep your main SIM/eSIM in another slot). The less stupid variant is, of course, to get mobile operat…

> The less stupid variant is, of course, to get mobile operators to issue SIM cards with e-sign capabilities. Estonia has that, for example: https://www.id.ee/en/mobile-id/ It works great. Just keep in mind that newer phones are starting to deprecate physical SIM slots. At the same time certifying eSIM implementations to the same EAL level is an absolutely crazy task.

> At the same time certifying eSIM implementations to the same EAL level is an absolutely crazy task.

It probably is, but it does make sense. eSIM standards were built to solve pretty much the same problem (make cloning eSIM profiles impossible), so it should be a good anchor of trust for that.

Re: German implementation of eIDAS will require an Apple/Google account to function

#617

Earlier quoted context omitted.

> That alone is a huge and frankly impossible thing to expect from regular people. The systems used by regular people could just refuse to boot further when detecting a compromise, so I'm not sure where this comes from. We have prior art for that too. This is still orthogonal to letting users who want to patch things patch them, and not letting the apps verify what environment they run in. It's all compatible with ea…

> This is still orthogonal to letting users who want to patch things patch them, and not letting the apps verify what environment they run in. It's all compatible with each other, and with both regular and power users. No, they're fundamentally opposed to each other. The entire point is that developers don't want their apps patched by just anyone, especially not malicious actors. Small minority of power users will in…

> The entire point is that developers don't want their apps patched

That's exactly what I'm trying to say. The entire point is not to secure the user, it's to secure the apps. It's working against the user's interest, as letting the user lie to apps is essential to user's agency. The technical means used to achieve this could also be used to work for the user and ensure their security without compromising their agency, but that's not what happens on mainstream platforms.

> No, you really couldn't.

Yes, you could. Exactly how you describe, so it was used only where it mattered, and in other cases they just had no choice. Today the friction is so low that even McDonald's app will refuse to work on a device it considers untrustworthy. The user does not benefit from that at all.

Re: German implementation of eIDAS will require an Apple/Google account to function

#618

Earlier quoted context omitted.

Some countries fixed it already, see Estonian ir Polish IDs with digital layer (performing signing, authentication, etc), and the devices only acting as untrusted interfaces to these.

It’s still impossible to extract an Estonian certificate from the smart card (or Mobiil-ID/Smart-ID), no?

I believe do, I didn't see a successful attack yet.

Re: German implementation of eIDAS will require an Apple/Google account to function

#619

I attestation should be abolished altogether. An app should have absolutely no way of knowing what kind of device it’s running on or what changes the user has made to the system. It is up to each individual to ensure the security of their own device. App developers should do no more than offer recommendations. If someone wants to use GrapheneOS, root their device (not recommended), or run the whole thing in an emulat…

I agree, you should be able to run anything you want, root your device, etc., but you also have to accept the consequences of that. If an app can no longer verify its own integrity, certain features are simply impossible to implement securely. Think of it this way: A physical ID (which is what we're trying to replace here) also has limitations, it looks a certain way, has a certain size, etc. Just because somebody wa…

No. I reject this framing. It is none of anybody's business how "secure" my device ever is. A smartphone is a piece of electronics, and not a tamper evident identity device.

Re: German implementation of eIDAS will require an Apple/Google account to function

#620
post #490

Earlier quoted context omitted.

But you can run modified client already. Rooted, wildly insecure devices can pass the attestation easily: https://magisk.dev/modules/play-integrity-fix-inject/ Safe, updated devices cannot unless they permit Google to run their surveillance services in the privileged, unconstrained mode.

The documentation actually reveals why this will most likely not work, given you are on expert on mobile security

Oh, you don't say. The above was a link to the source module, but ad with magisk there are many ways to peel the potato.

I've see countless users confirming it works for them, for example by using this workflow: https://magiskzip.com/how-to-pass-integrity-with-strong-chec...

But as an expert on the mobile security you can assure us its not possible to spoof Google play integrity pass with Magisk - am I right?

Post reply on HN