Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

European digital ID wallets rely on safety services of Google and Apple

waag.org

Post reply on HN
Print view View original

271–280 of 327 posts

Re: European digital ID wallets rely on safety services of Google and Apple

#271

Post by ulrikrasmussen »

tomega2134 wrote: post #252
ulrikrasmussen wrote: post #147

Earlier quoted context omitted.

I think the reason these systems require device bound keys is because the government is concerned with easily mass-produced forged age certificates. With software keys you can get an age certificate which can be copied instantly to a large number of devices, with hardware keys the government knows that the certificate is tied to a single physical unit.

Is this EU protocol so weak that it cannot withstand this attack, i.e. is duplicate age certificate use not detected or prevented?

You can't really prevent that unless you design a system which is inherently designed to track people, e.g. by phoning home to the issuer on each credential verification. The system being deployed right now is based on the issuer issuing batches of single-use credential tokens to device-bound single-use keys, which on the plus side means that colluding verifiers cannot use age credentials as cookies to track people. It is still vulnerable to colluding verifiers and issuers though, because the issuer can de-anonymize the tokens (it knows them and their linking to the identity of the user). This scheme also means that if the keys that the tokens are issued to are not device bound, then it is trivial to copy the age credentials to someone else.

To my knowledge, even more sophisticated ZKP schemes still rely on device bound keys to protect against duplication.

Re: European digital ID wallets rely on safety services of Google and Apple

#272

Post by Retr0id »

microtonal wrote: post #269
jt2190 wrote: post #217

Earlier quoted context omitted.

Why is attestation always bad, all the time? When two people interact there’s a trust/risk calculation on both sides. Isn’t attestation just a means of reducing risk for both parties? (We can debate who should control the attestation process and how it should work but your point 1 suggests that there is never a good form of attestation.) What would we do instead?

Definitely not bad all the time. For instance, GrapheneOS provides the Auditor app, with which you can verify from another phone or from a server that the OS is not tampered with. It also uses remote attestation. So, there are certainly useful applications.

I question the usefulness of Auditor. It can flag if a modified version of GrapheneOS has been booted, for example. But flashing a modified version of GrapheneOS requires erasing userdata, which you'd notice the moment all your data isn't there. Unless someone uses an exploit, but Key Attestation cannot detect exploits.

I suppose if you've bought a device with GrapheneOS already installed, you can use it to verify the installation. But that could also be achieved by reflashing a known-good image yourself.

Re: European digital ID wallets rely on safety services of Google and Apple

#273

Post by summm »

microtonal wrote: post #209
TingPing wrote: post #163

Earlier quoted context omitted.

The chain of trust always has a software layer. I don’t believe what you want is possible. I find the bank talking point strange, why are they special, are they even targeted more. It just feels like a boogeyman “think of your money!”

For all practical purposes it's possible to do this. The boot ROM only boots a vendor-signed bootloader, the bootloader verifies the OS kernel, etc., until you have a fully verified boot chain. A secure enclave, which is completely separated from the main CPU and OS performs the attestation using a private key in its tamper-resistant storage and embeds the results of verification by the bootloader. There may be some…

Nope. It is still not possible to give someone else (the government, or the bank) control over your phone while at the same time run software that you alone control with higher privileges. Please don't mix that up with "is practically hard to implement because of sloppy code. Also your attacker model is still "occasional evil government agency or evil private corporation wants to crack and read your messages", while what is discussed here is more fundamental "evil government or abusive corporation controls your phone in the first place, and can just remote control it you can't use really secure apps"

Re: European digital ID wallets rely on safety services of Google and Apple

#274

Post by faust201 »

littlecranky67 wrote: post #47

Here in Germany we had court rulings saying the german railway (DB) must offer offline tickets that do not require a computer or smartphone to purchase to not discriminate against the elderly. I am pretty sure we will see similar rulings for EUDI wallet requiring Google/Apple.

Ideally they should have also told all German banks distribute or offer non-App based accounts or 2FA? But they did not.

Also people are dependent on Play or App store. DB does not offer the app for direct download.

Re: European digital ID wallets rely on safety services of Google and Apple

#275

Post by lxgr »

xpuente wrote: post #254
lxgr wrote: post #244

Earlier quoted context omitted.

Smartcards have attestation too.

But how can you verify that the processor's own software, which ultimately runs the application, has not been compromised?

The software running on the smartcard? You write that yourself, and hopefully your security processes are good. The nice thing about smartcards is that the trusted computing base is massively smaller than that of a regular operating system.

If you disallow installing applications post-issuance (which is probably a good idea for ID cards), you don't even have to worry about VM runtime integrity either, as there will be only your application running on the card.

Re: European digital ID wallets rely on safety services of Google and Apple

#276

Post by summm »

jt2190 wrote: post #266
Retr0id wrote: post #229

Earlier quoted context omitted.

A hypothetical useful use of attestation is that a company promising to process personal data securely could actually prove it to end-users, by open-sourcing their server-side code and using reproducible builds combined with remote attestation, to prove to the client that the server-side is running unmodified within a secure enclave. I struggle to think of a useful use for it on the end-user client side, though.

Isn’t the client-side case something like “the banking app you’re entering your account password into is the binary the bank created and not a compromised binary that will drain your bank account”?

No, this would just require a publicly verifyable signature of the software, and the user would just choose to have their operating system verify it. No remote attestation or other hand-over-your-controls necessary.

Re: European digital ID wallets rely on safety services of Google and Apple

#277

Post by pimterry »

jt2190 wrote: post #217
microtonal wrote: post #199

Earlier quoted context omitted.

I think there are two fights that are both worth fighting: 1. Completely outlawing remote attestation. 2. In a world where remote attestation is given, let it be controlled in a fair way and not just by Google and Apple. The risk is that only fighting for (1) leaves you in a world with remote attestation, where only Google and Apple can decide who gets to pass and who not. In fact, that is pretty much the world we ar…

Why is attestation always bad, all the time? When two people interact there’s a trust/risk calculation on both sides. Isn’t attestation just a means of reducing risk for both parties? (We can debate who should control the attestation process and how it should work but your point 1 suggests that there is never a good form of attestation.) What would we do instead?

It's an anti-competitive concern all the time.

If we gatekeep service access to specific implementation attestations, it becomes much harder for new implementations to emerge. It doesn't really matter who controls the process.

In that sense, it's always bad. In this specific scenario for example it directly blocks emergence of alternative Android ROMs and Android-mostly-compatible devices like the various Linux phones.

There may be times where that downside is worthwhile, but it's always a downside, and we should very strongly discourage attestation wherever possible on that basis for the health of both the tech ecosystem and the business market around it.

Re: European digital ID wallets rely on safety services of Google and Apple

#278

Post by deaux »

nradov wrote: post #231
intrasight wrote: post #189

Earlier quoted context omitted.

I just dont buy the argument that it would be that expensive for the governments to provide certified keychain fobs that provide hardware based identification.

It's pretty expensive to deal with all of the technical support and identity verification work when people lose their devices and need to have credentials reset.

It's even more expensive to have your country's digital ID held hostage by the US or its big tech players.

Re: European digital ID wallets rely on safety services of Google and Apple

#279

Post by qurren »

jt2190 wrote: post #217
microtonal wrote: post #199

Earlier quoted context omitted.

I think there are two fights that are both worth fighting: 1. Completely outlawing remote attestation. 2. In a world where remote attestation is given, let it be controlled in a fair way and not just by Google and Apple. The risk is that only fighting for (1) leaves you in a world with remote attestation, where only Google and Apple can decide who gets to pass and who not. In fact, that is pretty much the world we ar…

Why is attestation always bad, all the time? When two people interact there’s a trust/risk calculation on both sides. Isn’t attestation just a means of reducing risk for both parties? (We can debate who should control the attestation process and how it should work but your point 1 suggests that there is never a good form of attestation.) What would we do instead?

> When two people interact there’s a trust/risk calculation on both sides.

You should never base your trust on the other party having a piece of hardware that has restrictions that you approve of. That is fragile, especially in a world where some people are better at making or modifying hardware than others. It is also a fundamental violation of basic freedoms to prevent people from modifying hardware that they own, and not something you can reliably police, and thus is a terrible way to establish trust from a technical perspective.

It's much better to base trust on established cryptographic methods on a protocol level. You treat them as a black box, and the trust is established by the inputs and outputs, not what's inside the box. An example of this would be handing them an image of a digital ID paired with a cryptographic signature that only the government holds the private keys to. They have no computationally viable way to edit the image and still have it match the paired signature. It's easily verified based on the government's public key, and they cannot re-sign it without the government's private key. It doesn't depend on hardware restrictions.

The fact that there is so much focus on hardware means there are likely deeper motives here, e.g. surveillence being dressed up as convenience.

Re: European digital ID wallets rely on safety services of Google and Apple

#280

Post by deaux »

u1hcw9nx wrote: post #184
Luker88 wrote: post #36

The EU reference for wallets strictly required google play services https://github.com/eu-digital-identity-wallet/eudi-app-andro... So Italy's IO app https://github.com/pagopa/io-app (wallet, documents, age verification) continuously refuses the users' request for GrapheneOS support and requires google. Nothing will change until the lawsuits start coming in. The only hope is the motorola/grapheneOS collaboration and…

This is only reflects their market share for now. The EU legally forbids member states from making a smartphone mandatory to access public services. The EU explicitly anticipated the danger of relying entirely on the iOS and Android and designed the EUDI Wallet framework to allow for other physical form factors. For example; 1. Smart Cards (for example The Current National ID) 2. Standalone Hardware Tokens & USB Keys

> The EU legally forbids member states from making a smartphone mandatory to access public services.

Yes, I'm sure they'll still allow for mail-in of obscure forms to access public services, which will then take 3 weeks to be processed.

If the EU actually wanted to "anticipate" this danger they'd have made it mandatory to include a physical form factor in EUDI wallets. In reality, they don't mind this danger, so it's optional, and you can bet most countries won't include one and make Google and Apple the only options.

Post reply on HN