Life cycles and cryptography

We subconsciously suspect connections with the age of equipment, its reliability and general security. On the other hand, it is difficult to imagine the above problem in the field of cryptography and to accept these development impacts. I was wondering how it is even possible to consider the mentioned life cycles, what impact they have on security, or what relationships there are between the life cycles of cryptography and other applications or services. The goal is to understand the motivations to maintain the current solution, the impacts of extension on technological debt and to what extent the approach using cryptoagility can solve the mentioned problems. This article series tries to summarize the causes that hinder regular and, most importantly, rapid change of cryptography, as well as to provide an overview of the reasons. If we know the reasons for these problems, we are able to consider them and make appropriate decisions.

Motivation for cryptography management

The first thing that comes to mind when thinking about encryption? Data is encrypted to ensure confidentiality. This is based on the CIA security triad (Confidentiality, Integrity, Availability). But ensuring confidentiality does not solve the motivation for cryptography management. This is influenced by the following reasons.

• Minimizing costs. Migrating cryptography from one algorithm to another is expensive, and implementation or architectural problems can occur due to ignorance. Unfortunately, protecting against these costs leads to legacy compatibility, creating cryptographic debt.
• Minimizing risks. As in the previous point, migrating cryptography creates risks. The same as using outdated cryptography. Algorithms that are too new and too old may have weaknesses or side effects, so the effort is to use only those that have been tested. Unfortunately, inappropriate risk management usually leads to reputational or legal problems. It is affected by threats and is affected by possible attacks.
• Performance of algorithms and their latency, which affects their usability. Any cryptography, whether it is encryption, ensuring integrity or authenticity, leads to limitations. These limitations can be of a technical or economic nature, they affect operation and influence decisions about the transition. I want to address this issue in a separate article, it is a completely specific problem.
• Compliance, i.e. compliance with standards. Paradoxically, at present, regulations can be a stronger reason than the technical reasons themselves. Examples include CRA, DORA, eIDAS2, PSD2, HIPAA, NIS2, PCI-DSS, PSD2 … and others

Just like with outdated technologies, where technological or security debt arises, a similar situation also occurs with cryptography. Unfortunately, it is also often overlooked and neglected. The strongest motive is, or rather should be, the elimination of cryptographic debt. The longer the migration is postponed, the faster the risk grows and the more expensive the transition is. The biggest risk is therefore not weak cryptography. The first is clinging to old technologies, i.e. stagnation. This increases risk and, in fact, costs. Therefore, the only applicable solution for cryptography management is cryptoagility. From a technological point of view, this means designing systems with a separation of algorithms from logic, using abstract layers (separation of libraries) and other necessary extensions, including policy management.

Cryptography Life Cycle

Estimates of the cryptography life cycle can be based on data on past algorithms and their success. This means the time of deployment, the length of support in standards and cryptographic libraries. Unfortunately, it is very difficult to estimate future. For this reason, it is more of a description of the current situation than a general rule, and unfortunately, there is little data available to find regular patterns. The lifetimes given in the table correspond to the largest, practically usable keys for the algorithms. However, this value is gradually increasing, currently for symmetric algorithms it is 256b and for asymmetric ones like RSA it is 3072b.

Unfortunately, other unpleasant influences come into play. When the need for migration of cryptographic algorithms increases, it is usually at a time when the cryptographic debt also gradually increases. The replacement of algorithms and protocols currently takes between 10 and 15 years. And not only in the case of the end of moral, but also in the case of the end of technical life. This is a time interval beyond which reason remains. Conjuring up backward compatibility, unwillingness of customers to migrate or insufficient support from manufacturers then increases the risks to absurd values. Despite all this available information, it is still possible to find in risk matrices for technically outdated protocols or algorithms with a "low" or "low to medium" risk rating. In such a case, this is a gross underestimation of the situation.

To further complicate the problem, it is also necessary to consider the behavior of attackers. Due to developments in artificial intelligence, which support the speed of programming, the time required to create exploits is getting shorter every year. These tools are also becoming more complicated and allow for significantly greater possibilities for abuse. By 2026, the time to create such a tool should be less than one day (already surpassed). Next year, the time is estimated to be less than 1 hour. At this rate, next year, with the same trend, the time could be less than 10 minutes. In contrast, the interval between replacing cryptographic algorithms of 10 to 15 years is completely incredible. The transition to cryptography resistant to quantum computers is supposed to increase data security. New algorithms are being created for this purpose. They require deep knowledge of mathematics to understand their functionality, and this is where the last group of problems lies. First, there is the implementation problem, requiring the programmer to understand the principles of the algorithm and its limitations. Otherwise, the implementation is likely to suffer from problems that can lead to impacts on the confidentiality and integrity of the data. Today, the biggest problem is not the algorithm, but its implementation. Another, more hidden problem is the development of mathematics. The fact that we currently do not know the methods of attack against these algorithms does not exclude the possibility of finding a new vulnerability. The probability is low, but the possibility is still there. And owners must be prepared for the problems mentioned.

Cryptographic debt and what to do about it?

What does cryptographic debt actually mean? It is a situation where the updating of protocols, algorithms and other components of the system lags behind reality. That is, there is no management of the life cycles of cryptographic algorithms and key material. There is a lack of knowledge of the dependencies between components, or there is a lack of overview of components, i.e. insufficient inventory. Therefore, any reaction to changes is slow, measurable in months or years. The reason for the emergence of this debt is usually the costs of migration. This requires costs associated with assessing the situation, deciding on the extent of the impacts, all of which are added together with the costs of the change itself. The paradox of migration is a situation where the most frequent reason for postponing the decision on change is the requirement for backward compatibility with clients. After all, the client always pays for the operation of the organization. But in this situation, we actually do not protect all the clients, because we would not have to protect some of them. This is directly contrary to the principles of security. Insufficient updating of protocols and algorithms creates a larger "attack surface", an environment rich in targets. That is, it accepts a larger range of threats, reduced support and, under certain conditions, completely insufficient configuration options. The icing on the cake of the whole problem is the subsequent, almost exponential increase in migration costs. This can so-called concrete the organization in a non-updatable state.

However, insufficient development also brings a problem with knowledge. In such an environment, these usually fall behind reality. This is the extent of adequate knowledge among both responsible persons and users. The reason is simple. Using outdated algorithms that have limited ways of verifying the confidentiality, integrity and authenticity of data is not only a threat to the ability to protect data. It is also a threat to the development of knowledge, which threatens further evolution in the same way as a lack of finances. Insufficient knowledge leads to wrong decisions. And wrong decisions can cause the withdrawal of funds in the form of fines and penalties, or the loss of orders. In such a case, limited funds will become even thinner, or cash flow will be limited.

Eliminating this type of technological debt requires not only knowledge and considerable effort, but also corresponding financial costs. Since these are repetitive activities, it is advisable to support them with internal rules. However, the rules must be based on asset management and their monitoring. If the organization has visibility of individual components, knows their current configuration, and requires corresponding standardized sets of reports (Bill of Materials), costs can be significantly reduced thanks to simplified management.

A condition for the above approach is also a "polite" approach by manufacturers to cryptography. It should be separated by an abstract layer, completely independent of the system logic. Cryptographic modules should be easily interchangeable and should have standardized descriptions (CBOM – Cryptography Bill of Materials). Replacing support modules or changing the configuration should not be a job that takes several months or years, it should be a matter of minutes.

In addition to the above conditions, it is also necessary to address the issue of management in the organization. That is, who is responsible for migration, who bears the risk of technological debt, what roles are needed for this (cryptologist, architect, etc.) and what processes cover these changes. At the same time, it is appropriate to define a crypto policy that defines the life cycle of algorithms. The life cycle of key material and its security classification must also be described. This is therefore a certain formalization of procedures, which makes sense mainly in the case of larger organizations.

To be continued next time

The continuation of the life cycles will address the measurement of cryptographic debt and the implications for managing and servicing this debt. This overview does not cover the life cycle of cryptographic material, nor the issue of migrating to quantum-resistant cryptography. These topics are covered in other articles.

Autor článku:

Jan Dušátko

Jan Dušátko has been working with computers and computer security for almost a quarter of a century. In the field of cryptography, he has cooperated with leading experts such as Vlastimil Klíma or Tomáš Rosa. Currently he works as a security consultant, his main focus is on topics related to cryptography, security, e-mail communication and Linux systems.