Quantum Computing Meets Post-Quantum Cryptography and Software-Defined Vehicles

I’m starting to feel like an old fool (but where are we going to find one at this time of the day?). When I was a kid, cars didn’t have any form of digital computing capability. My parent’s car didn’t even have electric windows. We considered ourselves lucky if the windshield wipers managed to make even a half-hearted attempt to perform their role in life.

I remember when I was around 7 years old. Every weekday morning, my mother and I got into the family car for her to drive me to school. We commenced our journey with her pulling out the choke and pumping the gas pedal like a maniac, after which we both held our breaths while she turned the ignition key. If we were lucky, the car started, in which case we next had to wait for ages for the engine to warm up. If we were unlucky, she’d flooded the engine, in which case we had to wait for ages before we could make another attempt. It wasn’t uncommon for our car to make a graunching noise and fail to start at all, in which case my mother would say “Oh dear” (or words to that effect) and we took the bus. I didn’t learn much about driving but I certainly expanded my vocabulary.

As an aside, public transportation is awesome in the UK and you can easily get by without a car, so I didn’t acquire my first vehicle until I was in my late twenties. This was a Triumph 2000 that I purchased secondhand from someone who used to be a good friend (until he sold me the Triumph 2000). It was built like a tank. Someone once drove their car into the back of mine at some traffic lights. The front of their car was a write-off, while I ended up with a small ding in my rear bumper. Balancing the timing on the dual carburetors was a nightmare. Putting your pedal to the metal to accelerate was equivalent to throwing a gallon of gasoline out of the window.

Now, of course, cars are like NASA command centers on wheels. Current distributed automotive architectures employ hundreds (literally, not figuratively) of microcontrollers scattered throughout the chassis. In addition to the mindboggling complexity associated with these architectures, it’s not uncommon to have three or four kilometers of copper wire linking everything together. The wires alone can weigh around 80 kilograms, which is like having another person in the car. To address this, we are undergoing a shift to what's called zonal architectures, which involves a central multi-core computer system that orchestrates everything via a network that connects to zones around the vehicle. Each zone handles the cross-domain activities required by that zone.

At the same time, we are entering the era of the software-defined vehicle (SDV). One aspect of this is the ability to dynamically update the vehicle over-the-air (OTA)—not just the infotainment system or a certain part of the vehicle, but the complete car over its lifetime, which is 10 to 15 years at least. This not only provides benefits to the user when their car gets better over time, but it also offers advantages to the OEM in the form of incremental revenue opportunities.

Data is the lifeblood of this new SDV world. This is all about data intelligence. It’s not about streaming all the data to the cloud—that's the old way of doing things—instead, it's about processing data at the edge within the vehicle using its more powerful processors to extract intelligence to perform tasks like providing anomaly insight to vehicle health and to be able to run real-time digital twins in the cloud. But that’s a story for another day.

The problem is that there are nefarious scoundrels roaming the world—cybercriminals who want to steal our data and wish us harm. Consider the potential for disaster if one of these slimeballs takes remote control of your vehicle, potentially corrupting the safety systems or causing you to crash. Sad to relate, one of the downsides of smart connected cars is that they provide a large attack surface with multiple attack vectors.

On the bright side, we are protected by cunning cryptographic algorithms. In the case of asymmetric (public key) cryptography, we have RSA, which requires the factoring of prime numbers, and ECC, which requires the solving of elliptic curves. In the case of symmetric cryptography, we have AES-128 and SHA-256. All of these are used to provide different forms of cybersecurity in modern vehicles.

Cracking any of these cryptographic solutions can bring even a modern supercomputer to its metaphorical knees. So, that’s OK. No problem. Right? Well… unfortunately, there’s an elephant in the room and a fly in the soup (I never met a metaphor I didn’t like). The name of our allegorical elephant isn’t Simon—not that there’s anything wrong with Simon as a name—it’s Quantum Computing (I agree, that is a strange name for an elephant, but… allegorical elephants, what can you do?).

What Is Quantum Computing?

A quantum computer exploits quantum mechanical phenomena to perform its computations. What does this mean and how does it do it? I don’t have a clue. All I know is that people have been waffling on about quantum computers since the 1970s, repeatedly saying that we will have them up and running “in the next 10 years.” Sad to relate, we are still probably 10 to 20 years away from having quantum computers that are readily accessible by the masses (i.e., me and my friends), but various entities have been making tremendous strides in this area.

As reported by Science Alert, for example, the most powerful digital computer in the world today, the Frontier supercomputer, would take 47 years (give or take) to solve a certain complex benchmark. By comparison, the Sycamore quantum computer created by Google's Artificial Intelligence division recently managed to crack the same benchmark in a matter of seconds.

The problem is that quantum computers will be able to crack today’s RSA- and ECC-based cryptography in seconds using techniques like Shor's algorithm, which was proposed in 1994. Similarly, Grover’s algorithm can be used to crack AES-128 and SHA-256. Fortunately, symmetric algorithms can be fortified against Grover’s algorithm by moving to AES-256 and SHA-384 or SHA-512. Migration of this kind is painful and expensive, but at least there's something to migrate to. By comparison, in the case of public key cryptography, we have a big problem because RSA and ECC are destined to be dead ducks in a post-quantum computing era.

In cryptography, the term post-quantum cryptography (PQC), which is sometimes referred to as “quantum-proof,” “quantum-safe,” or quantum-resistant,” refers to cryptographic algorithms that are believed to be secure against a cryptographic attack by a quantum computer.

In 2016, to come up with a PQC solution, the National Institute of Standards and Technology (NIST) launched a competition with a formal call for proposals. By the deadline for submissions in 2017, they had 69 candidate solutions. This was followed by a winnowing period. Second round candidates were announced in 2019, third round candidates (7 finalists and 8 alternates) were announced in 2020, and the winners to be standardized were announced in 2022. Formal standards for these winners—CRYSTALS-Dilithium and CRYSTALS-Kyber—are scheduled to become available in 2024, while full market migration to these new PQC standards should be completed by 2030.

CRYSTALS-Dilithium? Dilithium Crystals? You must be joking. Am I the only one who hears the words “But captain, the engines canna take it,” ringing in my ears (for younger readers, I’m channeling Scotty from Star Trek: The Original Series). But we digress…

And so we come to the clever guys and gals at NXP Semiconductors. These little scamps have been industry leaders in the automotive and security markets for decades, so it’s no surprise that NXP was part of the consortium that developed one of the CRYSTALS algorithms.

The reason I’m waffling on about all this here is that the chaps and chapesses at NXP recently introduced their S32G family of vehicle network processors (VNPs). These little rascals (the VNPs, not the folks at NXP) boast 21 Arm processor cores along with a bunch of other cores, and combine ISO 26262 ASIL D safety, hardware security, high-performance real-time and application processing, and network acceleration (phew!)

In addition to everything else, the S32G boasts an integrated hardware security engine (HSE) for cryptographic services and key management, and it includes support for PQC. This means that developers are already starting to integrate S32Gs into their next-generation vehicles in the knowledge that these devices can accommodate the existing cybersecurity standards of today, and they will be able to support the new PQC algorithms of tomorrow as soon as they become formally available.

We truly do live in interesting times. We can but hope they won’t become too interesting or, at least, more interesting than is good for us. How about you? What do you think about all of this?