Security Analysis of the EU’s Digital Wallet
A group of cryptographers have analyzed the eiDAS 2.0 regulation (electronic identification and trust services) that defines the new EU Digital Identity Wallet.
Comments
Clive Robinson • June 27, 2024 11:30 PM
On a related matter.
Back in the 1980’s when the 8bit home computer with just one or two kilobytes of RAM were the norm, and many were disguised as games machines like the “Nintendo Entertainment System”(NES) with the online world such as it was was dial-up. Security for the “home user” or just about any user was by todays standards nonexistent.
Getting on for half a century later the online world is very different with millions of hostile eyes watching and credential stealing, security needs to be treated very differently. Especially as humans have not really changed in that time and so some doing daft things is an expected occurrence.
BUT… 8bit microcontrollers with just one kilobyte of RAM or less are surprising to many still quite normal and found in your home in many places (including PC I/O).
The fact is the 6502 and Z80 CMOS CPU cores at under 5k transistors are still put in very many chips as a “silicon macro”. Why? Because they are inexpensive, low power and give sufficient flexibility and processing power, especially when clocked at a hundred times their original speed.
Such chips end up in all sorts of places not just home “white goods” but “infrastructure” like utility meters. But also more concerning in “medical implants” and contrary to the general perception most end up accessible from a network that can be reached directly or indirectly from the Internet.
Thus security is very much an issue.
But most “CS” algorithms used for cryptographic purposes are designed with large tables and 32bit CPU’s in mind. Thus an 8bit CPU with just a few bytes of RAM available appears to be an impossibility to have security on…
But is that the case? Whilst the old truism of,
“You can’t put a quart in a pint pot.”
Still holds and suggests you won’t get security, you need to think differently.
After all distill down a quart of beer or wine and you end up with a potent spirit that will certainly get in a pint pot, in fact a much lesser spirit glass that holds a gill or teacup full will do (~1/8th depending on who’s quarts and gills you mix up).
So can you use a modern CS-algo on an 8bit CPU? Yes, at an acceptable speed? Yes, and with just a few bytes of RAM? Yes for some CS-algos.
So modern security is possible on 1970’s CPUs you just have to think about it. After all saving more than $1/unit on a “100K Production Run” is probably worth the man-hours.
To see one implementation have a look at,
https://sgadrat.itch.io/super-tilt-bro/devlog/729390/modern-cryptography-on-the-nes
Importantly note the “trade-offs” as not all will apply in all cases.
Clive Robinson • June 28, 2024 12:17 AM
@ ALL,
You might note,
“Our specific recommendation is to use the BBS family of anonymous credentials.”
BBS signatures, are from memory published back in 2004 and based around the use of the discrete logarith problem, thus not “Post Quantum Secure”.
However section 6.9 of,
https://identity.foundation/bbs-signature/draft-irtf-cfrg-bbs-signatures.html#post-quantum-security
Says
6.9. Post-quantum Security
BBS Signatures compine two security properties; data authenticity and data confidentiality.Data authenticity refers to the inability of anyone other that the Signer being able to generate BBS signatures that are valid under the Signer’s public key (this property is often refered to as unforgeability, or in the case of BBS Signatures, strong unforgeability, e.g., by [TZ23]). It also means that no one should be able to generate valid BBS proofs disclosing sets of messages, without first optaining a valid BBS signature on those messages (in academic works, this is refered to as the BBS proof being a proof-of-knowledge of a BBS signature [CDL16] [TZ23]).
Data confidenciality means that no one (not even the Signer) should be able to use a BBS proof to extract information about the messages the Prover decided not to disclose during the proof generation process, or the signature that was used to generate that proof (something that is refered to as the zero-knowledge property of the BBS proof [BBDT16] [CDL16] [TZ23]).
On the presence of a Cryptographically Relevant Quantum Computer (CRQC), meaning a computer that will be able to break the discrete logarithm problem in the groups used by BBS Signatures (see [I-D.ietf-pquip-pqc-engineers]), the data authenticity property will not hold. Specifically, an adversary could use a CRQC to reveal the Signer’s secret key from their public key, hence giving them the ability to generate BBS signatures on behalf of that Signer, for messages of their choosing, as well as BBS proofs using those signatures.
On the other hand, data confidentiality cannot be broken, even by adversaries with unbounded computational resources and in possession of the Signer’s secret key. This means that even by utilizing a CRQC, adversaries will not be able to compromise the data confidentiality property of BBS Signatures. As a result, an adversary with access to such a quantum computer, will not be able to reveal neither the messages undisclosed by a BBS proof, nor the hidden signature value. This guarantees that the privacy and hiding properties of BBS proofs that are currently used, will not be compromised by future quantum-attacks (a property that is often referred to as everlasting privacy).
Anybody know if this is actually still correct?
iAPX • June 28, 2024 8:44 AM
This 8-bit project is in no way secure, nor “modern security”.
The sha family should not be used as such for credentials fingerprints and storing, you have to use a framework such as PBKDF2 that will usually use sha-256.
I still think near-modern security is possible on 8-bits CPU, but it won’t be fast and might need a dedicated accelerator for cryptographic primitives, the same way there are some for fp32 (AMD 9511 for example).
Clive Robinson • June 29, 2024 1:50 AM
@ iAPX
Re : SHA-256 v. PBKDF2
“The sha family should not be used as such for credentials fingerprints and storing, you have to use a framework such as PBKDF2 that will usually use sha-256.”
The usual reason given for not using SHA2 algorithms is the reason they exist which is “RAM” and “ROM” rather than “CPU”.
SHA-256 is NOT “memory-hard” that is it uses very little RAM and comparatively not much ROM when written correctly.
Something that is not just important but a deal breaker on “Low Cost Microcontrollers” that have quite limited on board RAM and ROM (chip design for memory is radically different to that of a CPU and it has not just real-estate but thermal / energy consumption issues which reflect back into viability).
The reason “memory-hard” is an issue currently is availability of increasingly more powerful ASIC / FPGA / GPU chips (something Nvidia has riden high on). They all can be hundreds if not tens of thousands of times faster with algorithms that have minimal RAM and ROM footprints. Take a look at the access time for data in “internal register file” compared to “external core memory” to see one reason why.
So GPU’s and ASICs when used in certain ways such as crypto-coin mining and “blockchain proof of work” can offer benefits that transfer to attacks on some password systems.
BUT going for a “memory-hard” function is at best a short term security advantage. Because leading edge technology moves on fairly rapidly, and changes to GPU and ASIC designs are often effected first. One such is increasing the size of memory in the “internal register file”… This robs the “security advantages” of increasingly more “memory-hard” algorithms.
Whilst new algorithms can be made that uses a lot lot more RAM and ROM memory they can only go so far before they become totally impractical. Also it’s a “Rabbit Hole Game” as can be seen with,
https://eprint.iacr.org/2016/759
But also we can already see this with microcontrollers where the limits of on chip RAM and ROM, compounded with board layout and power consumption make the use of certain algorithms not just impractical but impossible for certain applications. With “memory-hard” being a total non-starter.
To see this take a look at “the one closest to your heart” of implanted medical electronics like pacemakers (that are being put in people over 50 “as standard” in the US and other places). Also the up coming neural stimulators to reduce if not stop epileptic and similar life threatening seizures. The reason these devices are being fitted, is surprising to many not primarily the patients life, but the lives of others.
People having debilitating seizures etc whilst in control of “everyday machinery” has a “force multiplier effect” with respect to death and injury to others. You just can not “medically retire” and “ban from driving” all the people at risk of seizures, so fitting implanted electronics driven by low spec microcontrollers is the only practical solution.
All such implanted medical electronics currently “has no security” and we already know that such devices are susceptible to “Drive-By Jacking” from devices that cost less than $100 in online-order parts to put together.
So it’s just a question of “when” not “if”, if it’s not already happened. Remember this is something the “US Secret Service” regard as not just a valid attack but one that is dramatically called “A clear and present danger”. So much so that Dick Cheney after assessing the risk he had been informed of opted to have his device modified to make it a lot more secure,
https://www.bbc.co.uk/news/technology-24608435
But the real $64,000,000 question is,
“Do you want No security, or Some security on such devices?”
In you or in others, as high level security is not possible. Especially when you consider that a driver coming down the street is in effect by US legal definition 18 USC § 2332a(c)(2) a “WMD”…
Brian McGee • June 29, 2024 6:28 PM
@ Clive Robinson,
Back in the 1980’s […] Security for the “home user” or just about any user was by todays standards nonexistent.
That rather depends on what you mean by “security”, doesn’t it? We didn’t have modern crypto, and it was somewhat illegal (to export from the USA or Canada, or for people there to talk about with foreigners). We didn’t have memory protection either.
On the other hand, almost nobody was affected by computer security vulnerabilities in those days. (Well, maybe if you annoyed a phone phreak, you’d find your home line classified as a pay-phone and asking for coins…) So in some sense we had security even if we didn’t have “security” as a discipline. That didn’t really change till we started putting important (valuable) stuff on computers.
I’m not really sure what this “digital identity” business is meant to address, but as identity systems become more valuable, they become a larger target too. People used to forge such documents all the time, usually just for under-age drinking, and nobody much cared. What goes wrong if you forge one of these things? Maybe the system’s a bad idea entirely, and we should be happy with a lack of centralized “identity”.
Subscribe to comments on this entry
Leave a comment
All comments are now being held for moderation. For details, see this blog post.
Sidebar photo of Bruce Schneier by Joe MacInnis.
iAPX • June 27, 2024 12:27 PM
I expect the regulation to be amended, with obviously less privacy respect, as this is not a real goal for this digital ID and wallet…
The analysis work done on that on a cryptographic perspective is impressive and very useful to be able to explain the actual shortcomings of this proposal.