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.

Security versus safety

First, it is necessary to look at the issue of life cycles from a perspective and think about why they are so important to us. It is mainly about ensuring the functionality of the device and the impact of changes to this functionality on human health and property. And this is where the first problem begins to emerge. The terms security and safety are often confused, even though they are two different concepts. Security in the literal sense of the word ensures the protection of data, property or systems from misuse, theft or unauthorized access. It mainly focuses on intentional attacks and disruptions from the outside. On the other hand, safety means the protection of health, life and overall well-being in situations where an accident or failure may occur. The goal is to reduce the risk of injury or damage in the event of an unwanted system failure. The difference can be clearly shown in an "ordinary" lock on a door. A security lock prevents unauthorized access to things. A safety lock, on the other hand, ensures that a person can leave quickly and safely if something goes wrong, for example in a fire. In the case of life cycles, both issues are addressed. On the one hand, the reason is security, which degrades over time. But also safety, which degrades the component itself and makes it technically and morally obsolete, is not unimportant.

Life cycles, technical perspective

If we are talking about a situation where it is necessary to address the life cycles of devices, we probably need to address regular replacement of these devices. This depends on the target conditions and, above all, what kind of lifespan will be decisive for us. The first perspective can be more or less technological, using three basic terms:

Technical lifespan indicates how long a component still physically functions. The technical lifespan is influenced by the architecture and design depending on the operating requirements. In the case of hardware, the lifespan is influenced by the type of components used or the temperature of the device. In the case of electronics, it is commonly stated that when the temperature rises above 20˚C, each step of 10˚C increases the wear of the components by a factor of two. This can be interpreted very loosely as an increase in the failure rate or a decrease in reliability. On the other hand, temperatures below 10˚C or cycling (switching the device on and off) bring other problems. These are voltage peaks, current surges or the effect of different thermal expansion of the materials used (chip tearing).

Moral life describes the time when it no longer makes sense to use a component. This includes not only compatibility, but also the economy of operation or marketing activities (persuading customers). Most often, it is necessary to take into account the acquisition costs, i.e. the price of new equipment, but also the operating costs (TCO - Total Cost of Ownership). These costs include, for example, energy efficiency versus cooling requirements and, above all, service. If the operating costs of the old system exceed the costs of purchasing and operating the new system, this situation can be considered the end of the moral life. The new system usually has a lower TCO than the old one, and replacement then becomes a matter of available funds. In addition to costs, there are various added features, such as supported security functions. In the case of operating costs, it is also necessary to add the performance change; when renewing hardware, a new device usually has 2.5x higher computing power compared to the power consumption within three to five years than the old one (PUE - Power Usage Efficiency).

Support life (more often used as support time) is probably the most demanding discipline. The device can physically work, i.e. it will fulfill its purpose. But that is useless if there is no support for this device. In such a case, any problem that cannot be solved by conventional means leads to a failure or the need to migrate to a new solution. And migration from an unsupported system can be a project nightmare. So, support from the manufacturer and support for security updates becomes more important than technical or moral life under certain conditions. Because support has economic impacts, the following can be roughly stated. Support is available up to 5 years and even warranty or post-warranty service. Between 5-10 years, such service is sometimes possible, but very expensive. As a rule, it only concerns enterprise systems. Between 10-20 years, service is almost impossible, it is solved by cannibalizing components or systems, and over 20 years, the operation of such a system is practically only possible if you have your own warehouse and servicing components.

Life cycles, normative view

In addition to the technological view, there is also a normative view, which is provided by standards such as ITIL, IT4IT, ISO or COBIT. These views differ, but they have one thing in common. The life cycle ends with the end of support. Due to the end of support, the risk of security problems and unavailability increases significantly. From this perspective, the aforementioned assessments can be rewritten as follows:

COBIT is a framework that uses change process management, risk management and responsibility for the product/service. From the perspective of this management method, the benefit of the service must always outweigh the combination of risk (threats and costs to eliminate them), normative non-conformities (and their solutions) and costs. If this is not the case, the service is considered inadequate.

ISO promotes continuous risk management (ISO 270001) when a product or service is not secure and is at the end of its life under the following conditions. Contains vulnerabilities, is not supported or auditable. From the perspective of asset management (ISO 55000), it is a combination of the economics of operation (costs of operation, maintenance and replacement), the impacts of degradation (physical or moral) and the impacts of degradation. Thus, it includes the technical and economic aspects, as well as the assessment of risks.

ITIL determines that the life cycle is a service in itself. As long as the product or service brings value, or if the risks and costs of managing it (including the life cycle management service itself) do not exceed the benefits of managing the product or service, it is still possible to continue to use it. Currently, protection against cost increases is considered to be continuous development or improvement of a given component, the costs of this development are compounded with the benefits for the organization. When the resulting benefit decreases, the product/service is at the end of its life and it is necessary to ensure replacement.

This description is only a basic overview of the complexity of the rules and relationships of life cycles. The aim is not to completely describe these cycles, but only to introduce the issue. Unfortunately, life cycles complicate the management and cooperation of systems. This is especially true if the motivations that lead to these life cycles are not understood. In practice, the biggest problem is often not the technology, but the responsibility (and the related acceptance of risk, the effort to avoid investments) and the know-how of the mentioned persons. This concerns the roles (cryptologist and architect), processes (approval and change management), owners responsible for migration and, most importantly, the persons who will bear the risk of cryptographic debt.

To be continued next time

The continuation of the life cycles will address the Zombie Apocalypse and the impacts of life and attacks on cryptography. The next part will then explain the motivations for cryptography management, the cryptography life cycle, and cryptographic debt. The last part will then 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.