Quantum computing and cybersecurity: is the danger increasing?

Previous methods are easily broken by quantum computers. To counteract this, mathematical methods are used that are not as vulnerable. This concerns asymmetric cryptographic methods. They are based on a mathematical problem that can be solved incredibly quickly using quantum computers. This means that these asymmetric methods – where there is one key that encrypts and one that decrypts – will be instantly broken if we have quantum computers with the corresponding computing power.

Quantum algorithms are ultimately algorithms that still offer the necessary security in the age of the quantum computer and can also be calculated on classical computers.

Since 2017, the National Institute of Standards and Technology (NIST) has been leading a standardization process for post-quantum cryptography (NISTPQC). The ongoing standardization process represents the most important collaborative effort in the development and primary assessment of quantum-safe cryptography algorithms.

In several iterations of this process – each with an associated conference – all algorithms are carefully analysed and selected. Three iterations have now been completed, and the fourth is currently underway. There are currently four algorithms left, which will now be re-evaluated in the fourth round.

It has been shown that the new generations of controllers do not support post-quantum algorithms. The microcontrollers and processors we use in cars are not always comparable in terms of computing power to the computers we use in the workplace. To compensate for this performance deficit, the manufacturers of these microcontrollers and microprocessors integrate so-called hardware accelerators. This is support in the processor or microcontroller to accelerate cryptographic algorithms. As it is not always possible to calculate these efficiently in software, the hardware must provide support.

Due to the fact that the NIST unexpectedly announced a fourth round of standardization, the manufacturers of automotive controllers no longer had time to integrate appropriate hardware support.

This is a problem because the OEMs are planning to supply their vehicles with software updates for the next ten to 15 years, and we have no hardware support for these algorithms. This means that we have to calculate the post-quantum algorithms in software.

The Software defined Vehicle also works without corresponding hardware support, but the calculation of the secure post-quantum algorithms takes significantly longer, which limits their use under certain circumstances.

Some OEMs have asked us about post-quantum cryptography projects. When asked how quickly this could be calculated, very different estimates emerged. In the end, the uncertainty factor was one million. We couldn’t work with that. That’s why we decided to implement and evaluate the post-quantum algorithms on a standard control unit. This allowed us to see where we were realistically positioned.

For this purpose, we used an open source library on which the algorithms were implemented for the PC. We then modified the algorithms so that they could be calculated on the microcontroller. In the process, we increased the code quality based on automotive standards. We have now obtained usable figures that we have already been able to present at conferences.

In the past, it has been shown that security by obscurity, i.e. the approach of ensuring the security of a system by keeping its functionality secret, has not worked. In our opinion, security-relevant systems are always based on trust. That’s why we put our entire project online at GitHub.

We have to trust that what happens in a security-relevant system is correct and secure. From our point of view, a decisive factor for trust is that we disclose what we are doing. It is important to us that everyone can see that our implementations are implemented properly and that we have not built in any bugs or backdoors that could ultimately allow security to be undermined. To show this, we have disclosed our code. Now it can be examined in detail by anyone.

We hope that experts around the world will take a look at our implementation and report any errors they find. We develop according to our automotive standards, but it can happen that mistakes creep in. The fact that we can draw on expertise from all over the world is a huge advantage.

It is not yet very common in the automotive industry, but this is the first time IAV has done this. This is a pilot project.

Contact:

Philipp Jungklass
Team Lead Functional Software
philipp.jungklass@iav.de
https://www.linkedin.com/in/philipp-jungklass-176a34209/

Marco Siebert
Head of department Embedded Security
marco.siebert@iav.de
linkedin.com/in/marco-siebert-059356235