Reversing 'France Identité': The New French Digital ID • Hacker News Board

Re: Reversing 'France Identité': The New French Digital ID

#51

Post by lxgr » Fri, Oct 06, 2023, 1:12 PM UTC

usr1106 wrote: post #3

I am far from understanding the technical details. But it feels like they severly violated the rule of not running your own cryptography. If they had used TLS the MITM would have been much less likely as long as the app does not accept user-defined cerificates?

TLS is powerful, but not a fit for literally every scenario, especially if you have more than one, possibly variably trusted entities in your protocol. That's why there are still encryption and authentication layers above TLS.

One simple example are apt repositories: It's desirable to be able to host deb packages on many servers, often controlled by semi-trustworthy parties, and still allow clients to authenticate them. It would be possible to use TLS alone for package download, but that would require handing over your authentication keys to every single mirror server.

So arguably, Debian did "roll their own crypto" – but it was strictly for the better.

Re: Reversing 'France Identité': The New French Digital ID

#52

Post by lxgr » Fri, Oct 06, 2023, 1:14 PM UTC

realusername wrote: post #7

The idea is terrible even from the first lines, relying on the hardware key attestation means giving up the id card to Google and Apple approved devices which is absolutely not what you want as a country.

I generally agree, although I do understand the motivation for requiring device attestation here: Since the card neither has a PIN pad, nor a display, there is a lot of trust on the mobile device to be honest when it comes to signature operations.

Another solution would be an external, Bluetooth-connected terminal with both a PIN pad (or biometric authentication) and a display, but that would mostly defeat the purpose of using smartcards: The entire point of schemes like this is that users don't need to buy and carry yet another device beyond the smartphone and an ID card that they already own.

Re: Reversing 'France Identité': The New French Digital ID

#53

Post by lxgr » Fri, Oct 06, 2023, 1:17 PM UTC

mistrial9 wrote: post #37

mariusor wrote: post #26

Earlier quoted context omitted.

Could you please expand how any of the findings, or any attempts at digital ID are about surveillance and totalitarianism? Your post, as it is now, is brandishing big and scary words based on flimsy assumptions and without any real backup.

> flimsy assumptions and without any real backup saying this does not make it true -- volumes of political science are written on the topic of public identity. The perfect world where every instrument is applied fairly and in no other way, does not exist. A quick knowledge of modern investigation systems by law and tax authorities will be evidence of the alternate uses of this tech. Details on these topics could easi…

The parent comment is does not talk about the political desirability of public identity, but rather makes (largely baseless as far as I can tell, unlike the article) claims about the technical security of one particular scheme.

> The perfect world where every instrument is applied fairly and in no other way, does not exist.

True – yet the absence of a government-provided system often means that inferior means of identity verification will have to be used by people and businesses. (Have you ever opened a bank account or credit card in the US?)

That's why we get absurd private initiatives like Worldcoin that seem every bit as dystopian as some of the more poorly implemented government-based ID schemes.

Re: Reversing 'France Identité': The New French Digital ID

#54

Post by motohagiography » Fri, Oct 06, 2023, 1:20 PM UTC

lxgr wrote: post #44

motohagiography wrote: post #20

This is so good and important to show that these identity schemes are more about surveillance than security, as the security guarantees are limited and insufficient for any long period of time. An additional approach I might recommend for exploration would be to find the "offline mode," where it would have to re-use IVs and challenges over a short window when the app can't validate against the back end service. Other…

> [...] one of the main vulnerabilities in protocols like these is in the 'personalization' stage of the setup, where each card gets a set of default 'provisioning keys,' which are used to register the card and get unique user keys for it. A sample of unpersonalized blanks would yield that, and the costs associated with mitigating this with batch specific keys for provisioning is typically too much complexity. Is you…

These were presented areas for further research, as there are precedents for these vulns, and the economics of card distribution haven't changed much. This is a technical discussion about vulns in protocols, and given I've worked on them in the past, these were how I broke previous proposed protocols that were reimplementations of a variation on the EMV protocols. What's changed in the protocols is they have been simplified to use ECC keys (they couldn't support PKI previously because RSA keys were too long to fit in the SE key slots), but the main issue of effectively tokenizing authentication transactions (using those AES-GCM keys) has the same limitations as the original protocol - albeit with an ECC keypair to do app/device attestation.

Is this scheme vulnerable to that? Unknown. Are these attacks paths for additional vuln research that is exceptionally valuable and has significant policy consequences? Absolutely.

Re: Reversing 'France Identité': The New French Digital ID

#55

Post by lxgr » Fri, Oct 06, 2023, 1:21 PM UTC

mariusor wrote: post #47

lxgr wrote: post #39

Earlier quoted context omitted.

Smartcards, including the contactless kind (often called NFC, but that’s technically a related but different set of standards), have been able to perform RSA signatures since the 90s. A secure channel between a backend holding the keys (usually in an HSM) and a card read by a mobile device is pretty standard, actually. That's how remote card top-up usually works. The relevant smartcard standards (ISO 7816 or GlobalPl…

How about EC signatures? My Yubikey (which I imagine is a bit more sophisticated than a NFC tag can be) is said to be able to hold Ed2519 keys and use them for signing, but I was never able to actually do that. :)

Elliptic curve signatures are even easier since they're computationally less efficient and can be implemented in software on newer smartcards!

I'm using a GPG key on my Yubikey, and while I haven't tried using Ed25519 and Curve25519 in particular (GPG support for these is still not ubiquitous), the GPG smartcard application in general works quite well for both SSH and actual OpenPGP use.

Re: Reversing 'France Identité': The New French Digital ID

#56

Post by lxgr » Fri, Oct 06, 2023, 1:26 PM UTC

motohagiography wrote: post #54

lxgr wrote: post #44

Earlier quoted context omitted.

> [...] one of the main vulnerabilities in protocols like these is in the 'personalization' stage of the setup, where each card gets a set of default 'provisioning keys,' which are used to register the card and get unique user keys for it. A sample of unpersonalized blanks would yield that, and the costs associated with mitigating this with batch specific keys for provisioning is typically too much complexity. Is you…

These were presented areas for further research, as there are precedents for these vulns, and the economics of card distribution haven't changed much. This is a technical discussion about vulns in protocols, and given I've worked on them in the past, these were how I broke previous proposed protocols that were reimplementations of a variation on the EMV protocols. What's changed in the protocols is they have been sim…

EMV is a completely different protocol, though! You wouldn't use a vulnerability discovered in TLS (or its implementation in OpenSSL) as an example for why SSH/OpenSSH is an insecure protocol, would you?

A smartcard is in the end just a general purpose computer (with some physical hardening and a really weird and poorly layered protocol stack that costs hundreds of CHF to even read; thank you, ISO!) – it can be just as secure or insecure as any computer system.

> Is this scheme vulnerable to that? Unknown.

Yes, but you sprinkle your comment with just enough domain language to make it seem like you have a concrete security concern for the scheme presented in the article.

I'd consider that pretty misleading, especially in the context of trying to make a point on policy, as opposed to security ("significant policy consequences", as you say).

Re: Reversing 'France Identité': The New French Digital ID

#57

Post by PoignardAzur » Fri, Oct 06, 2023, 1:27 PM UTC

GaelFG wrote: post #24

louison11 wrote: post #10

Does anyone know why a private govtech business like Palantir doesn’t take over all these use cases? Governments are notoriously bad at tech, why isn’t there a massive private corporation catering to all these use cases and ensuring state of the art security? Instead of hiring local clowns that release half baked solutions like this.

In fact they do. Barely any development FOR the french government is done internally, all is externalized to "specialized" extern private companies (a known exemple Cap Gemini). I wouldn't call them clowns, and they do have competent people but they totally do focus more on public money extraction than on quality, like nearly all monopoly position companies. Results are sometime good sometime not.

It's starting to change, though. In fact, it's very frustrating that the french government keeps delegating projects to SSII consultants long after it's built up its own very competent open-source-friendly developer workforce.

Re: Reversing 'France Identité': The New French Digital ID

#58

Post by lxgr » Fri, Oct 06, 2023, 1:34 PM UTC

mistrial9 wrote: post #38

mariusor wrote: post #34

Earlier quoted context omitted.

Digital identity is the key for scaling democracy up, decreasing bureaucracy and integrating the act of being a citizen in day to day life, instead of being a chore that everyone complains about. It could allow for abuse for sure, but what technology doesn't. Assuming bad faith ab-initio and using those exact "terms of art" give out very strong vibes of conspiracy theories and sovereign citizen fetishes.

> Digital identity is the key for scaling democracy up unintended consequences are the topic at hand right? In all the world's countries, which shows "democracy scaling up" ? The single largest country is called China, they use Digital ID for scaling.

Many EU countries, and the EU itself (with eIDAS) are rolling out digital identity schemes as well.

I'm able to communicate with most government agencies of one European country digitally, as a result – definitely beats having to take a 10-hour flight or to at least find a printer and mail envelopes back and forth across the Atlantic, containing "physical signatures" that no company or government can realistically validate anyway.

Re: Reversing 'France Identité': The New French Digital ID

#59

Post by realusername » Fri, Oct 06, 2023, 1:35 PM UTC

lxgr wrote: post #52

realusername wrote: post #7

The idea is terrible even from the first lines, relying on the hardware key attestation means giving up the id card to Google and Apple approved devices which is absolutely not what you want as a country.

I generally agree, although I do understand the motivation for requiring device attestation here: Since the card neither has a PIN pad, nor a display, there is a lot of trust on the mobile device to be honest when it comes to signature operations. Another solution would be an external, Bluetooth-connected terminal with both a PIN pad (or biometric authentication) and a display, but that would mostly defeat the purpos…

What they probably want to know here I guess is "is this device secure?" and there's just no technical answer to that, the result of the key attestation doesn't help you one bit to decide that.

The only way to do it is indeed to run some kind of computation on the device, usually those get plugged in to have more power.

The key attestation has a very small list of things it's actually useful for anyways, it's generally a bad idea to use it.

Re: Reversing 'France Identité': The New French Digital ID

#60

Post by motohagiography » Fri, Oct 06, 2023, 1:40 PM UTC

lxgr wrote: post #56

motohagiography wrote: post #54

Earlier quoted context omitted.

These were presented areas for further research, as there are precedents for these vulns, and the economics of card distribution haven't changed much. This is a technical discussion about vulns in protocols, and given I've worked on them in the past, these were how I broke previous proposed protocols that were reimplementations of a variation on the EMV protocols. What's changed in the protocols is they have been sim…

EMV is a completely different protocol, though! You wouldn't use a vulnerability discovered in TLS (or its implementation in OpenSSL) as an example for why SSH/OpenSSH is an insecure protocol, would you? A smartcard is in the end just a general purpose computer (with some physical hardening and a really weird and poorly layered protocol stack that costs hundreds of CHF to even read; thank you, ISO!) – it can be just…

Security protocols have a short list of moving parts and trade offs and where to attack them. RNGs, key storage, key derivation, counters, and access modes, to name a few. They're only completely different to people who don't understand them.

If you are using symmetric secrets in smart cards, you're using something within a degree of EMV because you need compatability with existing reader infrastructure, and alignment to existing standards to get anyone to accept it. the AES-GCM was the giveaway because I seem to remember a related vuln where to facilitate compatability in software instead of the smart card, the designers used the counter as an additional secret. If the designers of this scheme were not constrained by existing reader infrastructure and standards schemes, they would have done this in a more modern and elegant way, likely using a Schnorr signature or a ratchet.

Protocol designers make trade-offs that they don't advertise because they represent a consensus of the risk between the solution parties. It appears in this case, there are some obvious opportunities for further research.