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 similar schemes I have seen implemented a single-use-key as a re-used limited-use-key to enable that use case.
The card he tested was apparently live in production, but 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.
There may be a DoS vulnerability in some card schemes where you can use 'torn' NFC connections to get the key and transaction counter on the card applet to increment and desynchronize from the counter recorded on the server, bricking the card - or potentially many en masse with some SDR equipment.
Given the physical user enrollment costs, there are some basic impossibilities in these protocols that will always reduce their security to a set of trade-offs that depend on economics and obscurity. Security research like this acts as a check on the efficacy of totalitarian controls like digital id, and it is important work to continually demonstrate that there are risks and costs to the regimes that impose them. I am very grateful this researcher has done work to discredit this scheme.
> [...] 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 your point "some smartcard schemes don't use key diversification, so this one probably doesn't either", and more generally "some smartcard schemes are implemented insecurely, so surely this one must be too"?
> There may be a DoS vulnerability in some card schemes where you can use 'torn' NFC connections to get the key and transaction counter on the card applet to increment and desynchronize from the counter recorded on the server, bricking the card
Speculation again, or do you have concrete evidence for this protocol being susceptible to torn transactions? Some are, some aren't.
Also, you know what else you can do to a card when you have physical access to it? You can take a pair of scissors and cut it in half! A remote bricking capability would be concerning, but requiring an intentional and repeated transaction tear hardly seems noteworthy.
> Given the physical user enrollment costs, there are some basic impossibilities in these protocols [...] I am very grateful this researcher has done work to discredit this scheme.
It seems like you are generalizing from one concrete project to all smartcard systems, for what seem to be somewhat irrational motives.
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.
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.
You are immediately prevented from creating an implementation which works on Windows/macOS/Linux, and it is reinforcing the Google/Apple duopoly in the smartphone market.
Moreover, you are relying on "trusted execution" remaining unbroken in thousands of different dirt-cheap smartphone models. It's not a question of "if" it gets broken, but "when". And revocation isn't exactly an option either, because you risk leaving millions of people unable to use your government-mandated app.
I believe that applications like these should be explicitly designed around the possibility of the user device being compromised or a malicious third party interacting with it instead - even if that means a loss of functionality.
And while you are at it, make it fully open source to make it easier for the security community to review it for silly things like the self-rolled crypto we see here.
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.
I wonder why do they need the whole secure channel thing instead of making the card hold a client certificate and use standard mutual TLS with their backend server.
As adev_ mentioned, TLS implicitly requires a lot of things that can be considered expensive for very low power devices (dare I say "bloat"). Examples being things like X509 certificates.
Another thing to consider is that TLS supports multiple use cases and has multiple versions, so it has stuff like algorithm negotiation, version negotiation and some other things that are really unnecessary when you just want a secure channel between two parties with pre-shared keys[1]. If you strip all those extra things from TLS you'll basically end up making your own protocol anyway.
What I'd like to see is a standardized protocol for this exact use case: two parties with pre-shared public keys, no algo negotiation[2], and only sending what's really needed over the wire without extra metadata. TLS is not quite right for this use case IMO.
[1] Yes, TLS-PSK exists but it's largely an afterthought and not always implemented by libraries, because it's considered a niche use case for TLS. To some degree, same thing can be said about client certificates.
[2] I think the article does say that they have algo negotiation in their custom implementation anyway. Personally I'd hardcode something like ChaCha20Poly1305, mainly because it's reasonably fast in software and on low-power devices.
I believe they are hoping to make a system which adds some sophisticated capabilities - for example:
* Can't read any identity information from the card contactlessly without a PIN, so you need somewhere to enter the PIN.
* Ability to prove your age without disclosing your identity, so you need somewhere to choose how much info to share.
* To validate ID cards for people whose phones are dead, the ability do to the above securely even on a sketchy nightclub bouncer's phone.
* Making all this stuff accessible on normal people's phones, not some $$$$ dedicated reader hardware.
* Ability to provably give another person permission to collect a parcel for you (I can only assume French parcel services are a lot more fastidious than ones in my country) with four-way coordination between the two people, the parcel service and the government.
Between these factors, I assume they want the mobile app itself to also be pretty heavily locked down so that even if that nightclub bouncer wanted his phone to record your PIN or whatever it wouldn't work.
And no doubt it's also crossed some people's minds that if there was ever another pandemic, creating a sudden need for a new vaccine passport, it sure would be convenient to have an extensible national ID system....
Noob question: why don't governments issue a private key to every citizen so that they can identify themselves "easily" in web forms and the like? The government would keep the corresponding public key.
You could go in person to any government building and request a new private key to override the previous one if needed.
Because securely storing the keys is quite difficult, and the whole system doesn't work if the keys are routinely compromised ("You could go in person to any government building and request a new private key to override the previous one if needed." doesn't cut it) - so the only reasonable way of issuing such private keys would be on a smartcard where it's reasonably difficult to extract/copy, and you could know if the actual card was lost.
Estonia has been doing this for a long time now with their ID cards. It can be extended to sim-based (mobile ID) or device/app based (smart ID) key pairs as well.
It's not just for the citizens but all residency cards and e-residency works this way, too.
I cannot understand, seriously, how we could have built a system where you have to have French documents in order to identify yourself to various services.
A friend's of mine dad is Polish. He is retired and worked for years in France. Now he cannot access all of his retirement data because some sites require France Connect and he does not have any French papers anymore.
When asked about that, France Connect's support basically replied "fuck you" (in French).
There must be thousands of people in his situation and yet, nobody cares.
There are similar hassles in Sweden with their BankID for people who can't get it, but have connections to Sweden one way or another. Swedish bureaucracy works quite well if you fit the mold, but can be totally useless if you don't. I think the issue is that as long as enough of the "normal" population thinks it work, no one really cares about those it doesn't work for.
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.
Palantir is a particularly bad example, it being american. France care a lot about sovereignty and would never allow (and for good reasons) an external entity to have that much control. It probably did ask for a contractor on an "appel d'offre" to build this so it's the same but with a french actor.
One company doing everything would just incite them to charge whatever they want at the taxpayer expenses, and do the bare minimum since there would be no competition to drive them out of business.
Because governments, like almost all entities, are beholden to budgets and accounting which incentivizes low spending. So you get lowest-bid contractors. On top of that, Europe (and especially France, IMO) isn’t real comfortable with foreign tech solutions at the moment.
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.
[+] [-] motohagiography|2 years ago|reply
The card he tested was apparently live in production, but 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.
There may be a DoS vulnerability in some card schemes where you can use 'torn' NFC connections to get the key and transaction counter on the card applet to increment and desynchronize from the counter recorded on the server, bricking the card - or potentially many en masse with some SDR equipment.
Given the physical user enrollment costs, there are some basic impossibilities in these protocols that will always reduce their security to a set of trade-offs that depend on economics and obscurity. Security research like this acts as a check on the efficacy of totalitarian controls like digital id, and it is important work to continually demonstrate that there are risks and costs to the regimes that impose them. I am very grateful this researcher has done work to discredit this scheme.
[+] [-] lxgr|2 years ago|reply
Is your point "some smartcard schemes don't use key diversification, so this one probably doesn't either", and more generally "some smartcard schemes are implemented insecurely, so surely this one must be too"?
> There may be a DoS vulnerability in some card schemes where you can use 'torn' NFC connections to get the key and transaction counter on the card applet to increment and desynchronize from the counter recorded on the server, bricking the card
Speculation again, or do you have concrete evidence for this protocol being susceptible to torn transactions? Some are, some aren't.
Also, you know what else you can do to a card when you have physical access to it? You can take a pair of scissors and cut it in half! A remote bricking capability would be concerning, but requiring an intentional and repeated transaction tear hardly seems noteworthy.
> Given the physical user enrollment costs, there are some basic impossibilities in these protocols [...] I am very grateful this researcher has done work to discredit this scheme.
It seems like you are generalizing from one concrete project to all smartcard systems, for what seem to be somewhat irrational motives.
[+] [-] mariusor|2 years ago|reply
[+] [-] realusername|2 years ago|reply
[+] [-] crote|2 years ago|reply
You are immediately prevented from creating an implementation which works on Windows/macOS/Linux, and it is reinforcing the Google/Apple duopoly in the smartphone market.
Moreover, you are relying on "trusted execution" remaining unbroken in thousands of different dirt-cheap smartphone models. It's not a question of "if" it gets broken, but "when". And revocation isn't exactly an option either, because you risk leaving millions of people unable to use your government-mandated app.
I believe that applications like these should be explicitly designed around the possibility of the user device being compromised or a malicious third party interacting with it instead - even if that means a loss of functionality.
And while you are at it, make it fully open source to make it easier for the security community to review it for silly things like the self-rolled crypto we see here.
[+] [-] lxgr|2 years ago|reply
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.
[+] [-] usr1106|2 years ago|reply
[+] [-] Nextgrid|2 years ago|reply
[+] [-] qweqwe14|2 years ago|reply
Another thing to consider is that TLS supports multiple use cases and has multiple versions, so it has stuff like algorithm negotiation, version negotiation and some other things that are really unnecessary when you just want a secure channel between two parties with pre-shared keys[1]. If you strip all those extra things from TLS you'll basically end up making your own protocol anyway.
What I'd like to see is a standardized protocol for this exact use case: two parties with pre-shared public keys, no algo negotiation[2], and only sending what's really needed over the wire without extra metadata. TLS is not quite right for this use case IMO.
[1] Yes, TLS-PSK exists but it's largely an afterthought and not always implemented by libraries, because it's considered a niche use case for TLS. To some degree, same thing can be said about client certificates.
[2] I think the article does say that they have algo negotiation in their custom implementation anyway. Personally I'd hardcode something like ChaCha20Poly1305, mainly because it's reasonably fast in software and on low-power devices.
[+] [-] firtoz|2 years ago|reply
Government work is so much fun.
[+] [-] adev_|2 years ago|reply
Your budget in term of compute and memory is extremely low. I would be surprised a proper RSA/ECDSA signature from an X509 certificate can hold there.
Very likely I would say no. And that's why the home made crypto.
[+] [-] michaelt|2 years ago|reply
* Can't read any identity information from the card contactlessly without a PIN, so you need somewhere to enter the PIN.
* Ability to prove your age without disclosing your identity, so you need somewhere to choose how much info to share.
* To validate ID cards for people whose phones are dead, the ability do to the above securely even on a sketchy nightclub bouncer's phone.
* Making all this stuff accessible on normal people's phones, not some $$$$ dedicated reader hardware.
* Ability to provably give another person permission to collect a parcel for you (I can only assume French parcel services are a lot more fastidious than ones in my country) with four-way coordination between the two people, the parcel service and the government.
Between these factors, I assume they want the mobile app itself to also be pretty heavily locked down so that even if that nightclub bouncer wanted his phone to record your PIN or whatever it wouldn't work.
And no doubt it's also crossed some people's minds that if there was ever another pandemic, creating a sudden need for a new vaccine passport, it sure would be convenient to have an extensible national ID system....
[+] [-] mongol|2 years ago|reply
[+] [-] danwee|2 years ago|reply
You could go in person to any government building and request a new private key to override the previous one if needed.
[+] [-] runeks|2 years ago|reply
The citizens obviously wouldn't want the government generating their private keys. Because then it wouldn't be a private key any more.
[+] [-] PeterisP|2 years ago|reply
[+] [-] workfromspace|2 years ago|reply
It's not just for the citizens but all residency cards and e-residency works this way, too.
[+] [-] BrandoElFollito|2 years ago|reply
A friend's of mine dad is Polish. He is retired and worked for years in France. Now he cannot access all of his retirement data because some sites require France Connect and he does not have any French papers anymore.
When asked about that, France Connect's support basically replied "fuck you" (in French).
There must be thousands of people in his situation and yet, nobody cares.
[+] [-] CogitoCogito|2 years ago|reply
[+] [-] tecleandor|2 years ago|reply
[+] [-] usr1106|2 years ago|reply
[+] [-] louison11|2 years ago|reply
[+] [-] GaelFG|2 years ago|reply
[+] [-] rubenfiszel|2 years ago|reply
[+] [-] Thaxll|2 years ago|reply
They even serve cards for the DoD: https://www.thalesgroup.com/en/markets/digital-identity-and-...
[+] [-] ajb|2 years ago|reply
https://www.bbc.co.uk/news/world-europe-51487856
[+] [-] laurent123456|2 years ago|reply
[+] [-] sircastor|2 years ago|reply
Hence hiring the “local clowns”
[+] [-] usr1106|2 years ago|reply
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?
[+] [-] lxgr|2 years ago|reply
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.
[+] [-] qweqwe14|2 years ago|reply