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.

Measuring cryptographic debt

The problem with this type of technological debt is its measurement and reporting. How to actually approach it? The fundamental building block is Asset management, because "you can't secure something you don't know exists". Those who don't have it unfortunately have a problem managing their own IT and shouldn't even try to manage cryptography. Only based on the asset inventory can you tell what an organization's overview of its assets is. If the asset knowledge coverage is higher than 90%, it is a mature solution. If it is between 70% and 90%, it is a reasonable solution that, although it has its problems, can be worked with. If it is lower than 40%, the organization has a serious problem. And somewhere between 40% and 70% are organizations that have understood how important this knowledge is. For them, the main indicator is the trend, which determines the effort to address this problem.

$$\mathrm{Coverage}=\frac{\text{Assets in CMDB}}{\text{Estimated or Measured Assets}}$$

The second part of such a construction is the measurement of the currency of cryptography, i.e. CFI (Cryptography Freshnesh Index). It is possible to paraphrase it with the rule “Do you have cryptography? And could I see it?” Here, both its affiliation to a certain area and the degree of compliance with standards are evaluated for each cryptographic asset. I note with current standards. Such a list can be prepared, for example, in the following way:

• Outdated algorithms - high risk
• Key length - high risk
• SSL/TLS/DTLS/QUIC version, IPSec version - high risk
• Certificate age - medium risk
• Cryptographic material replacement policy - high risk
• Readiness (currently a question of migration to PQC) - increasing risk
• Unsupported crypto libraries - high risk

In the area of migration to PQC algorithms, the risk for key agreement algorithms (KEM) will be high in 2030 and for digital signatures (DSA) in 2035, and very high after. Nowadays, risk is "only" medium to high.

This is the sum of the risks for each component multiplied by the compliance of these components with the corresponding standards (according to legal weight, these are laws, norms or company policies). If the resulting status is between 90% and 100%, this is a modern setting, corresponding to current requirements. From 70% to 90%, this is an acceptable status, between 50% and 70%, a situation with significant risk. Below the 50% threshold, this is a high cryptographic debt and the organization has serious problems in solving it.

As an extension of these reports, the cryptoagility score (Cryptoagility Score) can be considered. Here, an evaluation is made of how quickly algorithms can be changed. This is a simplification of the representation of complex data into a single value. This is despite the fact that completely different environments are being compared. On the one hand, there are hardcoded algorithms that require months to years to change. On the other hand, the use of independent libraries separated by a transparent layer, which are controlled by configuration and changes are applied in seconds to minutes. Another expanding factor is the ability of cryptoagility to have centralized management, which allows this change to be handled in parallel on multiple systems, or even automated.

$$\mathrm{CAS}=\frac{\sum _{i=1}^n{w}_i\cdot S_i}{\sum _{i=1}^n{w}_i}$$

Where S_i is the dimension score and w_i is the dimension weight. A basic overview of dimensions can be considered in this way:

A similar principle is used by metrics such as MTTR-C (Mean Time To Rotate), which measures the average time required to rotate key material or replace algorithms. Metrics such as DCE (Deprecated Cryptography Exposure), which determines the proportion of the volume of current versus outdated algorithms, take a different approach. Then there is CHS (Certificate Hygiene Score), which again measures the status in several dimensions. One of the dimensions is the ratio of certificate expiration time to the strength of their algorithms, another is the ratio of current algorithms to outdated ones, and so on. A rather interesting report is the Secret Sprawl Index, which measures the rate of uncontrolled spread of secrets in repositories and shared data (environment variables, asset records, containers, folders or files accessible to multiple users) compared to the number of CIs (Configuration Items). Ideally, all of these metrics should be part of regular reports, as they provide an interesting insight into the current state of this technology debt.

$$\mathrm{MTTR-C}=\frac{\sum _{i=1}^n(T_{\text{completion},i}-T_{\text{mitigation},i})}{n}$$

Where Tdetection_i is the time of problem detection and Tmitigation_i is the time of completion of rotations, i.e. problem mitigation. The result is the average solution time, but to protect from distortion, it is necessary to convert the given data to a percentile.

$$\mathrm{Deprecated\; Cryptography\; Exposure}=\frac{\text{deprecated Crypto Assets}}{\text{Total Assets}}\cdot 100$$

DCE is a simple percentage of the obsolescence of the cryptography used. Nevertheless, the information provided has significant informative value. In addition, the calculation can be expanded to include a penalty for the type of obsolescence using weighted averages extended by impact coefficients. In such a case, for example, RC4 or MD5 algorithms can have a significantly higher penalty than, for example, SHA1.

$$\mathrm{CHS}=\frac{\sum _{i=1}^n{w}_i\cdot H_i}{\sum _{i=1}^n{w}_i}-\mathrm{Penalty\; Factors}$$

Where H_i is the hygiene score and w_i is the dimension weight. CHS is very similar to CAS, but in some areas in CHS individual calculation areas can be provided in the form of a percentage rating. Subsequently, the entire CHS rating is reduced by penalties caused by outdated algorithms, expired certificates, self-signed certificates or certificates without ownership. This penalization is controlled by rules that determine the impact of individual threats.

$$\mathrm{Expiration\; Compliance}=\frac{\text{Valid Certificates}}{\text{Total Certificates}}\cdot 100$$

$$\mathrm{Strong\; Algorithm\; Score}=\frac{\text{Certificates with Approved Algorithms}}{\text{Total Certificates}}\cdot 100$$

$$\mathrm{Certificates\; without\; Ownership}=\frac{\text{Certificates without Ownership}}{\text{Total Certificates}}\cdot 100$$

$$\mathrm{SSI}=\frac{\text{Exposed Secrets}+\text{Unmanaged Secrets}}{\text{Total Secrets}}\cdot 100$$

SSI (Secret Sprawl Index) is also an interesting view, especially in terms of the magnitude of the threat created by unauthorized users, programmers or administrators. With a certain degree of caution, this overview can also be included in the calculation of Cryptoagility Score.

Consequence

Based on the technical assessment of life cycles, several limitations with an overall impact on security are obvious. Paradoxically, the biggest problem is the technical lifespan, i.e. the time for which the device is physically functional. Due to their design, most systems move into the zombie category after support ends. And because they continue to work, their security is usually not the goal, or expensive protection mechanisms are solved instead of a simple upgrade. A similar problem exists in the field of cryptography, where the exchange of protocols or algorithms can occur even after 10-15 years. Currently, thanks to artificial intelligence and the increase in attackers' abilities, it is possible to create attack tools in a matter of hours, and this value will continue to decrease.

There are several ways to solve such a situation. Starting with the decision on how to set the rules, through consideration of purchase, support, management and migration. An example is cars, as a commonly available technology. And why is this example so important?

Years ago, a car was purchased with a view to 5-10 years. Even today, the technical support of cars far exceeds the support for the most critical part. Electronics and communication systems are usually only supported for 5-8 years, and this part is currently critical. After this period, the value of the car drops sharply. The reason is the unavailability of repairs for navigation and communication systems. The car becomes a typical zombie solution and the question is how much sense it makes to operate it after this time. The question is also how big an impact this policy will have on the supply chain and the resulting accident rate.

So how should such a situation be approached? Ideally, a combination of the solutions listed below should be used.

• Systems Lifecycle Management Policy If a clear migration policy is set, which requires migration to a new solution after the end of support. This is a management decision that has an impact on the entire life cycle, the economy of operation and the security of all components. In the case of cryptography, then ensure a regular replacement cycle, including a strict limitation of backward compatibility.
• Purchase management policy of systems. When purchasing systems, it is not possible to accept the lowest possible price, but it is necessary to accept an increase in price based on the required support period. As grandmothers used to say: "None of us are rich enough to afford to buy cheap things". In the case of systems requiring support for decades (banking systems, OT technologies, telecommunications, healthcare), it is advisable to centralize purchases in a certain way. If the supplier does not provide the required support of a specific scope and duration, it is necessary to ensure support in another way. This can be your own service department at the group level or outsourcing. Procurement management must consider which component of the system will be the first to end support, and this deadline must be accepted as the end of moral support for the system. At this point, threats to system management are starting to rise sharply. Risk management after the end of moral life is therefore just an attempt to sell a winter coat to a dead man.
• Asset management is one of the most important tools. If the administrator does not know what components he has in the network, he cannot monitor them, let alone manage them. Similarly, the administrator must have an overview of the cryptography used. Asset management must also be combined with status measurement and reporting. In combination with other technologies, it is even possible to implement change management using system policies (enabling and blocking algorithms, protocols, and methods).
• Security management using policies. In the case of cryptography, this is an approach covered by crypto-agility. Similarly, a large number of application and system security issues can be addressed by distributing appropriate patches or configuration policies. These should follow current trends and correspond to both the development of standards and the system architecture and security policies of the organization.

Conclusion

As with all other components, it is not only possible, but even necessary for cryptography to think about regular changes and life cycles. This requires appropriate recording, measurement and management. Cryptography is only valuable if it protects us in an appropriate way. Therefore, each individual component must be able to provide evidence of security. If this is not possible, a compromised or threatening component must be quickly replaced with another. Trust has no place here - trust in a weakened or broken algorithm is an underestimation of the threat. If someone believes in such an algorithm, this trust usually has worse consequences than underestimating the consequences of deploying a new algorithm. All this leads to the need for cryptography management, i.e. crypto-agility.

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.