Chasing Cyber - #17 - In the Bleak Midwinter
eIDAS blows, Log4j foes, and hardware woes
Welcome to the 17th edition. As a warning, this one is a little depressing. You might need some chocolate afterwards. Let’s dive into the content…
Goodbye, Internet Trust
We need to talk about eIDAS 2.0.
For those who care about a secure and safe Internet (and who doesn’t?), eIDAS 2.0 contains many worrying provisions.
As a reminder, eIDAS regulates electronic transactions within the EU. It defines the rules for electronic signatures, timestamps, and other related technologies.
A new version of the standard is at the rubber-stamping phase of approval. And that’s concerning because it includes new rules for website certificates that will weaken the web.
Under the new rules, browser manufacturers will be forced to trust certificate authorities selected by EU member states. This means over 40 new certificate authorities (CAs) will be added overnight to the list of trusted authorities. Every one of these will have the power to generate a certificate for any website in the world.
It gets worse. Today, the 80-odd CAs trusted by your browsers are forced to comply with strict security requirements, set by the browsers themselves. These same standards will not apply to the EU lists, and yet the browsers must not treat them any differently.
In short, this will mean a CA from Malta (with a population of ~500k and GDP of $17bn) can happily issue certificates for every major website in the world.
I wish I had a silver lining comment to wrap this up, but sadly Internet security is about to get worse. The EU has ignored petitions from hundreds of security experts up until now, and it seems like the next steps are a formality.
But hey, it’s nearly Christmas, right?
Do You Even Patch, Bro?
What can the quantum-safe community learn from Log4j?
On the one hand, it’s a terrifying demonstration of how slow we are to deploy security patches.
It’s been two years since the 10.0 severity zero-day based on the Log4j framework was announced on Twitter. And yet, one-third of applications are still running vulnerable versions today (according to a Veracode report).
This saga lends weight to mounting fears that quantum-safe migrations are not beginning soon enough. After all, changing algorithms is much harder than switching Log4j versions.
On the other hand, the world didn’t fall apart due to Log4j.
Bear in mind this vulnerability got the highest possible severity rating. Attackers could use this weakness to trigger remote code execution. And yet, the planes did not fall from the sky, nor did the money evaporate from our banks.
I find this mildly reassuring. Because I’m quite certain the quantum-safe migration will not be completed in time, for many systems.
Hopefully, we’ll get away with it. Hopefully.
It’s Hard For Hardware
Spare a thought for the hardware vendors implementing PQC algorithms.
The pair of talks from NXP and Qualcomm were the most sobering moments from last month’s PQC conference in Amsterdam.
One challenge for hardware vendors is the multitude of new algorithms. Because cyber agencies are recommending hybrid modes, the hardware vendors have to implement and accelerate multiple new algorithms while still supporting today’s options. Ideally without changing their device footprint.
And remember NIST is planning to standardise even more in the future.
On top of this, key sizes and RAM requirements have increased. This is not easy to handle in constrained devices. At least one of the vendors complained that NIST’s concept of an embedded device was way too performant and didn't represent the real devices they work with.
(In NIST’s defence, any choice they make will annoy someone).
The other major challenge is side-channel attack resistance. The use of a certain mathematical transform within most PQC algorithms is causing a real headache for hardware vendors.
Rather than attempting to explain this, I recommend watching 10 minutes of this clip from the conference.
In short, life is tough for these vendors. And they can’t afford to move slowly. Many of their end users, including the automotive industry, have real demands for PQC because their devices stay in the field for 15-20 years.
I’ll be very interested to see what is released in the next year or so. I’m a little concerned we will see a new wave of significant hardware vulnerabilities.
Thanks Duncan I enjoyed the article about hardware constraints. I'd be really interested in your views on NIST's call for additional digital signature schemes. Will any of these be helpful in addressing the challenges you have described?