Future-proof systems through crypto-agility

Hardly any technical system can do without cryptography. The confidentiality and authenticity of data can be ensured by using modern cryptographic methods such as AES [Advanced Encryption Standard]. Cryptographic hash functions, which create a fingerprint of a data record, are an important tool in this process.

However, cryptography is often used as a black box. The assumption is that cryptography is always secure when used correctly. The trust in the cryptography used today also comes from the fact that the algorithms have been tried and tested for decades. The asymmetric RSA method, for example, has been around since the 1970s and, with the appropriate parameterisation, it cannot be broken today. The symmetric block cipher AES has also been studied by the smartest minds in the crypto community for over 20 years without any practical attacks being found.

The weaknesses of today's cryptography

Nevertheless, it would be a fatal mistake to assume that modern cryptography is “impenetrable”. The predecessor algorithm to AES, the Data Encryption Standard (DES), was broken for the first time at the end of the 1990s, after around 20 years of usage, by the specially designed supercomputer “Deep Crack” – within a few days.

Cryptographic hash functions have been repeatedly broken over the years. Both MD5 and SHA-1 are considered insecure today, and even if there are still no practical attacks on the successor SHA-2, the existence of the SHA-3 standard, which is completely detached from the design principles of its predecessors, shows that there are strong doubts about the longevity of SHA-2.

Lifetime of selected algorithms

However, the prospects are discouraging for asymmetric cryptography (i.e. algorithms such as RSA, Diffie-Hellman or cryptography on elliptic curves). As the security of all these methods is based on mathematically related calculation problems, bringing down one method in enough to break all the asymmetric cryptography used today. This can happen, for example, if there is a mathematical breakthrough and an algorithm is found to efficiently calculate a prime factorisation on conventional hardware. The more likely scenario, however, is technical progress in the field of Quantum Computing, because it can execute such an algorithm for prime factorisation.

Transition to post-quantum cryptography

The asymmetric cryptography we use today has an expiration date. Fortunately, the research community has long since recognised the problem and has already provided an alternative in the form of new post-quantum cryptography.

The standardisation of post-quantum cryptography by the NIST [National Institute of Standards and Technology] has also paved the way for the industry to convert its products, processes and services to quantum-safe cryptography. However, this is precisely where it becomes clear that cryptography cannot be regarded as a black box, and that new algorithms, due to new conditions such as statefulness or significantly larger parameters, are not drop-in replacements.

Depending on the complexity of the system, the transition to post-quantum cryptography can become a colossal task. And what happens when the transition is completed? When all systems have been converted and are equipped for the age of quantum computers? By then, the next algorithm will likely have been identified as a cause for concern – whether conflicts have been found for the SHA-2 hash function or, during the transition to post-quantum cryptography, emphasis has been placed on lattice-based algorithms, and new vulnerabilities have been found in them. In such cases, the process starts again, and the next transition to new cryptography begins.

Crypto agility as a design principle

The top priority should be, during the already necessary transition away from classical asymmetric cryptography, to create the necessary conditions and processes to ensure a general interchangeability of the cryptography used. This particularly concerns products that are already in use in the field.

This principle is called crypto agility. A system is crypto agile if it allows the seamless exchange of existing cryptography without the need to modify the underlying infrastructure. This means that a company employing crypto agility as a design principle can replace a compromised cryptographic algorithm with a secure variant within a few days, instead of having to undergo a large-scale transition that takes months to plan.

Case Study: automotive industry

The goal of crypto agility is easier to achieve on some systems than on others. In particular, systems that operate entirely in the cloud and are under the full control of the operator can naturally achieve crypto agility more easily. For distributed systems that are operated from various locations in the real world, there are more challenges on the path to crypto agility.

Let's assume that a car manufacturer (OEM – Original Equipment Manufacturer) wants to make the next generation of its vehicles crypto agile – especially considering the threat posed by quantum computers. What considerations need to be taken into account? A distinction must be made between local changes that only affect the host itself, and changes in communication that affect both communication partners. There are also several process requirements. In the following, we want to have a closer look at some points without being exhaustive.

Local changes

The trust anchor of a control unit is usually the Hardware Security Module (HSM) installed on the control unit or the keys stored in the HSM. An HSM typically used in the automotive industry today fulfils the following purposes, among others:

• Secure storage of keys or hash values, sometimes even unchangeable in e-fuses.
• High-performance execution of cryptographic calculations with the help of hardware accelerators.
• Generation of real random numbers.
• Monotone counters for e.g. downgrade protection.

HSM in the control unit

Here you can quickly see where the concept of crypto agility reaches its limits. If, for example, the verification key for a secure boot mechanism is stored unchangeably in e-fuses, the procedure used cannot be replaced without creating a new secure boot concept.

Hardware accelerators are used to meet certain performance requirements for cryptography in terms of start-up times or response times. If the cryptography that is accelerated with these hardware components must be replaced, the requirements can no longer be met. Possible solutions include integrating the cryptographic calculations completely into the software – or the HSM firmware. However, the HSM processor must have sufficient computing capacity for this. Another option would be to outsource not the entire algorithm, but only the most expensive operations to hardware accelerators. This could reduce the chip area required per accelerated algorithm and allow a larger number of algorithms to be supported by the hardware. However, this is a measure that the OEM can only initiate in close coordination with the semiconductor industry.

For a crypto agile system, the key memories in the HSM must also be dimensioned in such a way that it is possible to store larger keys if the crypto algorithm (or just the parameters of the algorithm) is changed. The same applies to certificate storage, as certificates may contain larger keys and signatures in the future. Here too, the OEM must formulate corresponding requirements for the supplier.

The software that controls the cryptographic algorithms (e.g. AUTOSAR crypto stack) must also be able to map the changed framework conditions of the new algorithms. For example, hash-based methods have a maximum number of signature generations per key pair.

Changes in communication

Basically, a modern vehicle has many interfaces, not all of which are under the control of the OEM. While the OEM can control the type of communication between the vehicle and the back end, or between the vehicle and its own mobile app, the OEM has no influence on standardised communication protocols for V2X or charging communication, for example.

There may also be interfaces on supplied control units that the supplier uses for return analysis, for example. The OEM has no direct influence on these interfaces but can persuade the supplier to update the protocol used by making a corresponding change request. The prerequisite for this is that the OEM has already committed the supplier to crypto agility in the development phase.

Selected communication partners of a vehicle

With the communication protocols used under the control of the OEM, care must continue to be taken to ensure that the protocols are designed flexibly enough for the message format to support larger signatures and possibly additional meta information. The cryptographic algorithm used should be communicated as meta-information in the protocol flow (e.g. choice of cipher suite for TLS).

Process requirements

Appropriate processes must be created for the smooth exchange of cryptography. First, an inventory of the existing cryptography must be carried out, e.g. in the form of a Cryptography Bill of Materials (CBOM). If it then becomes known that a certain algorithm has weaknesses, a decision must be made as to what should be used to replace the algorithm.

This selection of a “backup” algorithm can, of course, also be made in advance. However, it must be noted that a “backup” algorithm should be based on a different mathematical problem in order to minimise the risk of both algorithms becoming insecure at the same time.

The cryptography used must then be updated for all communication partners (e.g. control unit in the vehicle and back-end). The more powerful communication partner (e.g. the back end) should be updated first and ideally support both algorithms during a transition period. There may not be enough resources available on the control device to host both algorithms in parallel. From the point at which the new algorithm has been fully rolled out to the fleet, it can then also be configured in the back end that from now on communication is only permitted with the new algorithm.

If all requirements are met, a crypto exchange process can ideally be integrated into the existing incident response management processes.

Conclusion

Crypto agility refers to the ability of a system to exchange the cryptographic algorithms used without significant restrictions during operation. The effort required to make a system crypto agile depends primarily on the complexity of the system. 

However, especially for complex and distributed systems, a transition to new cryptography is hardly, or not at all, possible without crypto agility. The fact that such a transition will be necessary sooner or later, however, is already a given due to the threat posed by Quantum Computing. Crypto agility is therefore an absolute must to develop future-proof systems – for example, in the automotive, medical technology, building automation, industrial manufacturing and aerospace industries.

Your way to crypto agility

The way in which crypto agility can be most effectively integrated into existing structures depends heavily on the specific needs of your organisation. Alter Solutions can accompany you on this path and develop individual solutions for you. We can work with you in the following areas:

• Assessment of existing security technologies and needs analysis for crypto agility.
• Development of a holistic concept for the implementation of crypto agility for your products.
• Security assessment of hardware and software used, e.g. HSM modules and crypto libraries.
• Development of crypto agile security technologies, including:
  
  • Secure communication protocols.
  • Key and certificate management.
  • Secure Boot.
  • Public Key Infrastructure (PKI).
• Specification of crypto agility in specifications.
• Evaluation of the implementation of crypto agility by suppliers.
• Selection of suitable crypto algorithms considering the given framework conditions.
• Introduction of the necessary processes, such as inventorying cryptography or update strategies.
  
  

Would you like to find out more about crypto agility or integrate it into your systems to make them future-proof? Then contact us today, free of charge and without commitment.

Schedule a non-binding meeting now!