Blog
Cryptoagility as a term that should have started (and not only started) being talked about
In the field of security, it is necessary to have an overview of the managed components. But for a long time, no comprehensive procedure was available for cryptography. The result is an unpleasant situation that threatens security and increases the costs of change management.
Cryptographic agility
Crypto agility is a term that has been appearing frequently in the field of IT security recently, especially in the field of cryptography. Its main goal is to simplify and, of course, accelerate changes to cryptographic mechanisms, i.e. increase management flexibility. The reason is the existence of security threats (errors in protocols, algorithms or techniques), changes in regulations, transitions to other technologies.
Cryptography is supposed to provide us with key security properties: confidentiality, integrity, authenticity and non-repudiation. However, without appropriate management, these properties cannot be achieved effectively. Managing cryptographic protocols and algorithms is very demanding today, and if multiple applications from different manufacturers cooperate, the change can take weeks or months. If, for example, the above-mentioned security threat appears in such a case, the entire organization and often the associated supply chain are at risk. Therefore, the responsibility for crypto-agility is not only a task for product design, but is also part of implementation, IT operators, IT and security architects, software and hardware developers, as well as standards developers, and last but not least, for management.
In this area, there are several examples of problems with the elimination of the old and the transition to the new cryptography. The points listed below are a reminder of the situation that prevails in the IT area, but there would be significantly more examples from reality:
1) Migration from the DES algorithm to its successor, the AES algorithm. The DES algorithm was standardized in 1977, but the first practical demonstration of an attack appeared around 1990. In 1999, the 3DES standard was created as a temporary replacement. Although AES was standardized in 2001, DES was removed from the standard in 2005. The 3DES algorithm was marked as non-compliant in 2015 and has been banned for use since 2023, but the migration to this standard has not been successfully completed to date.
2) Migration from the RC4 algorithm to other stream or block algorithms. This algorithm has been commercially available since 1987. In 2005, a paper appeared highlighting statistically significant dependencies, yet the algorithm was practically broken only in 2015. It can still be found in Kerberos/Active Directory, older versions of TLS, and other places. Its alternative name is ARCFOUR, but it is an identical algorithm.
3) Breaking the MD5 hashing algorithm. The MD5 algorithm was published in 1991 and broken in 2005. Nevertheless, it is still part of some versions of the NTP, SMB protocols, authentication mechanisms, digital signatures, integrity checks and other components, all of which are very easily vulnerable.
Cryptoagility is currently emphasized due to the transition to quantum-resistant cryptography (PQC – Post-Quantum Cryptography). However, the relationship between cryptoagility and PQC is not unambiguous: cryptoagility is an approach to cryptography management focused on rapid change, while the transition to PQC is only one of the cases when controlled change is required. We thus distinguish between the reason for the change and the method of its management. In the long term, individual cryptographic algorithms gradually become obsolete, so it is necessary to ensure regular replacement. In addition, there are occasional breakthroughs that allow for a sudden change in security. In such a case, it is extremely important to be prepared to react quickly. Examples from the past are extremely useful in this regard. Whether it is the breaking of the RC4 algorithm, the transition from the DES or 3DES algorithm to the AES algorithm, the breaking of the MD5 or SHA1 hash functions, the use of default nonces in the symmetric AES-GCM algorithm, as well as the arrival of quantum computers. All of the above changes were characterized by a sudden change in the perception of security. These changes require a quick reaction of the organization, especially in the current environment, and that is why cryptoagility is so important. This element is also related to developments in the field of PQC. Purely hypothetically, what if one of the proposed algorithms is broken? What if developments in this area allow solving one of the mathematical problems? At the moment, we need cryptoagility and the ability to react quickly.
In addition to the speed of change (flexibility), the above management method is intended to ensure a reduction in personnel requirements. On the other hand, it requires the fulfillment of certain conditions. One of the most important is effective resource management, i.e. functional asset management. This process requires a complete overview of individual devices and their configurations. The use of standard descriptions allows for the automatic identification of possible changes and improvements. If a security incident occurs in the field of cryptography, an acceptable solution can be found very quickly. Standard sets should contain various lists (BOM – Bill of Materials). For crypto-agility, only one of them is most important, the so-called CBOM. This is an acronym for Cryptography Bill of Materials. Of course, asset management also uses other sets, here is an overview of the basic ones:
- HBOM (Hardware Bill of Materials)
- SBOM (Software Bill of Materials)
- CBOM (Cryptography Bill of Materials)
- OBOM (Operational Bill of Materials)
- MBOM (Manufacturing Bill of Materials)
- RBOM (Runtime Bill of Materials)
- AIBOM (Artificial Intelligence Bill of Materials)
- MLBOM (Machine Learning Bill of Materials)
- SaaS (Software as a Service Bill of Materials)
- VEX (Vulnerability Exploitability eXchange)
This overview of individual BOM sets is important for asset management, but it is much more important for the owner. It allows him to manage more effectively with lower costs. But cryptography changes can only be managed effectively with complete information about resources. So asset management must be available. What exactly does this mean?
Asset management is a process that determines what and where I have and who manages it. Records of items are so-called CIs. Individual CIs (Configuration Items) are stored in the CMDB (Configuration Management Database) along with their configurations and links. If standardized lists are used for configuration, change is a matter of comparing the lists and possibly generating a new configuration. It is possible to go further and define a crypto policy for the entire organization, which significantly simplifies configuration and reduces the cost of changes. All changes can be automated and unified, which reduces the amount of effort required.
The importance of asset management and its relationship to BIA/BC: Functional asset management is essential not only for rapid response to security incidents, but also for linking with Business Impact Analysis (BIA) and Business Continuity (BC). A properly managed CBOM allows you to quickly assess the impact of changes or incidents on the organization's critical processes and ensures business continuity. Currently, BOM modules, including CBOM, should be part of the delivery from reputable manufacturers. The description must include configuration options and, ideally, the default configuration. Changing the configuration depends on the administration of a specific system; factory settings may not always be applied. Configuration options are a critical factor - their absence means that the organization must create its own CBOM lists, which increases the workload.
The next step is to support cryptography management according to a defined policy. Centrally distributed settings enable uniform management across the organization and cooperating equipment. This reduces the risk of outages and system complexity, while increasing the speed of change management. CBOM is also essential when working with multiple organizations, where finding common solutions is both knowledge- and system-intensive. A modern environment contains tens to hundreds of applications and thousands of microservices, so reconfiguration is a technological and project challenge. Without a centralized policy repository, organizations would face either high costs or unplanned outages.
CBOM, as a definition of cryptography implementation properties, contains many, perhaps at first glance, unimportant properties. There is a list of system properties, i.e. what algorithms and protocols are supported. There is a system description, which can be hardware and firmware definitions, or definitions of used libraries and their versions. There is a list of supported randomness generators, secret derivation libraries (KDF – Key Derivation Function) and many other functionalities. At the same time, there is also a description of the current status. What is allowed, what algorithms and key lengths are available. So in addition to the system's capabilities, there is also a description of its current settings.
The problem with CBOM at present is mainly the need to describe the system's capabilities. Obtaining this information is extremely challenging and the available information is not entirely accurate. The reason is insufficient cooperation with suppliers or partners, low level of provision of information about the capabilities of crypto libraries and other similar shortcomings. Currently, a very small number of manufacturers offer customers a description of the system's properties in a standardized format, which makes standardization and subsequent automation difficult. Some suppliers not only do not provide data on supported algorithms, which makes standardized crypto-agility management difficult. They often do not even provide evidence of the correctness of the implementation or code audit, or as an alternative, compliance with standards or certification. At the same time, confidence in the correctness and knowledge of the capabilities of the cryptosystem is important for management. What can be done about it?
In my opinion, it is crucial to define the criteria for selecting a solution. The security of information systems and their components should include standardized overviews and the possibility of automating changes. If the security of information systems and their components is required, the criteria should also include appropriate overviews and compliance. It should also be possible to ensure the automation of the aforementioned changes according to requirements in the form of policies. In another case, the customer is exposed to the risk of repeated implementations, which, depending on the complexity, have significant economic and operational impacts. Therefore, it seems to me that feedback by rejecting a product that does not meet such conditions is appropriate. Perhaps this can motivate the manufacturers in question in an appropriate way. This method is also known as "voting with your feet".
Recent past issues overview:
| Incident | Year | Issue category | Mitigation scale | Damage estimate (€) |
| Debian RNG | 2006–2008 | weak RNG | months | 50,000–500,000 (costs for key replacement and system recovery) |
| Dual_EC_DRBG | 2007–2013 | compromised RNG | years | €1–10 million (theoretically millions of systems compromised) |
| DigiNotar | 2011 | compromised CA | months | €8–12 million (loss of trust, CA liquidation) |
| Heartbleed | 2014 | implementation bug | months | €1–2 billion (patch, TLS key recovery, reputation) |
| SHA-1 migration | 2014–2017 | outdated algorithm | years | €5–20 million (massive certificate migration, operational outages) |
| Logjam | 2015 | weak DH parameters | months | €500,000 – €5 million (theoretical threat to 8% of HTTPS servers) |
| DROWN | 2016 | old protocol | months | €1–10 million (theoretical threat to 33% of servers) |
| ROCA | 2017 | weak RSA generator | months to years | €100–500 million (smartcards, TPM, identity compromise) |
| Marriott Breach | 2018 | certificate management / long-term compromise | years | €100–120 million (500 million customers, sensitive data leaked) |
| SolarWinds | 2020 | certificate management / supply chain | months | €200–500 million (federal agencies, large companies) |
| Twitter/X (TLS certificate) | 2020 | certificate management / certificate expiration | hours | 50–200 thousand. € (API outage) |
| Let’s Encrypt root expiration | 2021 | trust chain expiration | years | €1–5 million (legacy and IoT issues) |
| Twitter/X (TLS certificate) | 2022 | certificate management / authentication error | hours | 50–200 thousand. € (operational downtime) |
Currently, similar errors would usually reach a direct cost an order of magnitude higher. An extreme example would be an error similar to HeartBleed. The direct costs would be around 10 billion Euros. But I don't even dare to estimate the indirect costs, caused by problems with loss of trust, impacts on the economy, but also fines from the GDPR perspective.
Far more challenging to accept is the result of the following overview of technology migration times. For most algorithms, the time to removal is not in the order of days or weeks, but surprisingly 10–15 years. Considering the potential impacts, this is a strong argument for a crypto-agility architecture.
| Name | Year (announcement – completion) | Issue category | Scale of mitigation | Impact estimate (€) |
| SSL 2.0 deprecation | 1996–2011 | obsolete protocol | years | ~200–500 million € |
| End of SSL 3.0 support | 2014–2015 | vulnerable protocol (POODLE) | months to years | ~500 million – 1 billion € |
| End of TLS 1.0 support | 2016–2021 | obsolete protocol | years | ~1–2 billion € |
| TLS 1.1 End of Support | 2016–2021 | Deprecated protocol | years | ~500 million – 1 billion € |
| DTLS 1.0 End of Support | 2015–2022 | Deprecated protocol | years | ~100–300 million € |
| RC4 Vulnerability | 2001–2016* | weak cryptographic algorithm | years | ~1–3 billion € |
| DualEC DRBG Vulnerability | 2007–2014 | compromised RNG | years | ~100–500 million € |
| MD5 Vulnerability | 2004–2012 | collisional hash function | years | ~500 million – 1 billion € |
| DES support end | 1998–2005** | weak symmetric algorithm | years | ~200–500 million € |
| Support end 3DES | 2016–2023** | obsolete symmetric algorithm | years | ~500 million – 1.5 billion € |
| SHA-2-224 (limited use) | 2001–present | hash function with limited use | years | ~50–100 million € |
| Other block ciphers with 64bit block (CAST5/CAST128, Blowfish, IDEA etc.) | 2016–2023 | obsolete block ciphers (64bit block, Sweet32) | years | ~200–600 million € |
* is still a supported part of Microsoft Active Directory in 2026
** migration is still not complete (TLS ciphersuite, SSH, IPSec ...)
In conclusion, the following can be said, and it is not very encouraging news:
- If we look at the current situation, in 2026 the time to create an exploit for a known vulnerability was reduced to just 8 hours. In 2027, at the same pace of change, it should be less than 5 minutes. Next year around minute. This is contrasted by the migration time between technologies in the order of years. May there are something wrong?
- Cryptoagility without CBOM is not cryptoagility. Rather, it is agile crypto-hazard. The same can be said about asset management. Knowledge supported by facts is something different from faith. Therefore, there is a difference between governance based on hard data and faith in governance that does not actually exist. Without knowledge of the environment, the potential implementation of policies is not a gamble, but downright suicidal behavior.
References:
- NIST Crypto Agility
Source: https://csrc.nist.gov/ - Standard FIPS 46-3
Source: https://csrc.nist.gov/ - NIST SP 800-131A
Source: https://csrc.nist.gov/ - RC-4 No More
Source: https://www.rc4nomore.com/ - Finding MD5 Collisions – a Toy For a Notebook
Source: http://eprint.iacr.org/ - HBOM (Hardware Bill of Materials)
Source: https://www.ntia.doc.gov/ - SBOM (Software Bill of Materials)
Source: https://www.ntia.doc.gov/ - CBOM (Cryptography Bill of Materials)
Source: https://cyclonedx.org/ - OBOM (Operational Bill of Materials)
Source: https://www.iso.org/ - MBOM (Manufacturing Bill of Materials)
Source: https://www.siemens.com/ - RBOM (Runtime Bill of Materials)
Source: https://vex-cisecurity.org/ - AIBOM (Artificial Intelligence Bill of Materials)
Source: https://www.aibom.org/ - MLBOM (Machine Learning Bill of Materials)
Source: https://www.mlops.community/ - SaaS (Software as a Service Bill of Materials)
Source: https://www.sbomframework.org/ - VEX (Vulnerability Exploitability eXchange)
Source: https://www.oasis-open.org/ - ZeroDay Clock (From Vulnerability to Exploitation)
Source: https://zerodayclock.com/
Autor článku:
Podobné články
Your learning platform for cryptography
and security.
1. Introductory Provisions
1.1. These General Terms and Conditions are, unless otherwise agreed in writing in the contract, an integral part of all contracts relating to training organised or provided by the trainer, Jan Dušátko, IČ 434 797 66, DIČ 7208253041, with location Pod Harfou 938/58, Praha 9 (next as a „lector“).1.2. The contracting parties in the general terms and conditions are meant to be the trainer and the ordering party, where the ordering party may also be the mediator of the contractual relationship.
1.3. Issues that are not regulated by these terms and conditions are dealt with according to the Czech Civil Code, i.e. Act No.89/2012 Coll.
1.4. All potential disputes will be resolved according to the law of the Czech Republic.
2. Creation of a contract by signing up for a course
2.1. Application means unilateral action of the client addressed to the trainer through a data box with identification euxesuf, e-mailu with address register@cryptosession.cz or register@cryptosession.info, internet pages cryptosession.cz, cryptosession.info or contact phone +420 602 427 840.2.2. By submitting the application, the Client agrees with these General Terms and Conditions and declares that he has become acquainted with them.
2.3. The application is deemed to have been received at the time of confirmation (within 2 working days by default) by the trainer or intermediary. This confirmation is sent to the data box or to the contact e-mail.
2.4. The standard time for registration is no later than 14 working days before the educational event, unless otherwise stated. In the case of a natural non-business person, the order must be at least 28 working days before the educational event.
2.5. More than one participant can be registered for one application.
2.6. If there are more than 10 participants from one Client, it is possible to arrange for training at the place of residence of the intermediary or the Client.
2.7. Applications are received and processed in the order in which they have been received by the Provider. The Provider immediately informs the Client of all facts. These are the filling of capacity, too low number of participants, or any other serious reason, such as a lecturer's illness or force majeure. In this case, the Client will be offered a new term or participation in another educational event. In the event that the ordering party does not agree to move or participate in another educational event offered, the provider will refund the participation fee. The lack of participants is notified to the ordering party at least 14 days before the start of the planned term.
2.8. The contract between the provider and the ordering party arises by sending a confirmation from the provider to the ordering party.
2.9. The contract may be changed or cancelled only if the legal prerequisites are met and only in writing.
3. Termination of the contract by cancellation of the application
3.1. The application may be cancelled by the ordering party via e-mail or via a data mailbox.3.2. The customer has the right to cancel his or her application for the course 14 days before the course takes place without any fees. If the period is shorter, the subsequent change takes place. In the interval of 7-13 days, an administrative fee of 10% is charged, cancellation of participation in a shorter interval than 7 days then a fee of 25%. In case of cancellation of the application or order by the customer, the possibility of the customer's participation in an alternative period without any additional fee is offered. The right to cancel the application expires with the implementation of the ordered training.
3.3. In case of cancellation of the application by the trainer, the ordering party is entitled to a full refund for the unrealized action.
3.4. The ordering party has the right to request an alternative date or an alternative training. In such case, the ordering party will be informed about all open courses. The alternative date cannot be enforced or enforced, it depends on the current availability of the course. If the alternative training is for a lower price, the ordering party will pay the difference. If the alternative training is for a lower price, the trainer will return the difference in the training prices to the ordering party.
4. Price and payment terms
4.1. By sending the application, the ordering party accepts the contract price (hereinafter referred to as the participation fee) indicated for the course.4.2. In case of multiple participants registered with one application, a discount is possible.
4.3. The participation fee must be paid into the bank account of the company held with the company Komerční banka č. 78-7768770207/0100, IBAN:CZ5301000000787768770207, BIC:KOMBCZPPXXX. When making the payment, a variable symbol must be provided, which is indicated on the invoice sent to the client by the trainer.
4.4. The participation fee includes the provider's costs, including the training materials. The provider is a VAT payer.
4.5. The client is obliged to pay the participation fee within 14 working days of receipt of the invoice, unless otherwise stated by a separate contract.
4.6. If the person enrolled does not attend the training and no other agreement has been made, his or her absence is considered a cancellation application at an interval of less than 7 days, i.e. the trainer is entitled to a reward of 25% of the course price. The overpayment is returned within 14 days to the sender's payment account from which the funds were sent. Payment to another account number is not possible.
4.7. An invoice will be issued by the trainer no later than 5 working days from the beginning of the training, which will be sent by e-mail or data box as agreed.
5. Training conditions
5.1. The trainer is obliged to inform the client 14 days in advance of the location and time of the training, including the start and end dates of the daily programme.5.2. If the client is not a student of the course, he is obliged to ensure the distribution of this information to the end participants. The trainer is not responsible for failure to comply with these terms and conditions.
5.2. By default, the training takes place from 9 a.m. to 5 p.m. at a predetermined location.
5.3. The trainer can be available from 8 a.m. to 9 a.m. and then from 17 a.m. to 6 p.m. for questions from the participants, according to the current terms and conditions.
5.4. At the end of the training, the certificate of absorption is handed over to the end users.
5.5. At the end of the training, the end users evaluate the trainer's approach and are asked to comment on the evaluation of his presentation, the manner of presentation and the significance of the information provided.
6. Complaints
6.1. If the participant is grossly dissatisfied with the course, the trainer is informed of this information.6.2. The reasons for dissatisfaction are recorded in the minutes in two copies on the same day. One is handed over to the client and one is held by the trainer.
6.3. A statement on the complaint will be submitted by e-mail within two weeks. A solution will then be agreed within one week.
6.4. The customer's dissatisfaction may be a reason for discontinuing further cooperation, or financial compensation up to the price of the training, after deduction of costs.
7. Copyright of the provided materials
7.1. The training materials provided by the trainer in the course of the training meet the characteristics of a copyrighted work in accordance with Czech Act No 121/2000 Coll.7.2. None of the training materials or any part thereof may be further processed, reproduced, distributed or used for further presentations or training in any way without the prior written consent of the trainer.
8. Liability
8.1. The trainer does not assume responsibility for any shortcomings in the services of any third party that he uses in the training.8.2. The trainer does not assume responsibility for injuries, damages and losses incurred by the participants in the training events or caused by the participants. Such costs, caused by the above circumstances, shall be borne exclusively by the participant in the training event.
9. Validity of the Terms
9.1 These General Terms and Conditions shall be valid and effective from 1 October 2024.Consent to the collection and processing of personal data
According to Regulation (EU) No 2016/679 of the European Parliament and of the Council on the protection of individuals with regard to the processing of personal data and on the free movement of such data and repealing Directive 95/46/EC (General Data Protection Regulation, hereinafter referred to as "the Regulation"), the processor xxx (hereinafter referred to as "the Controller") processes personal data. Individual personal data that are part of the processing during specific activities at this web presentation and in the course of trade are also broken down.Although the collection of data is ubiquitous, the operation of this website is based on the right to privacy of each user. For this reason, the collection of information about users takes place to the extent absolutely necessary and only if the user decides to contact the operator. We consider any further collection and processing of data unethical.
Information about the records of access to the web presentation
This website does not collect any cookies. The site does not use any analytical scripts of third parties (social networks, cloud providers). For these reasons, an option is also offered for displaying the map in the form of a link, where the primary source is OpenStreet and alternatives then the frequently used Maps of Seznam, a.s., or Google Maps of Google LLC Inc. The use of any of these sources is entirely at the discretion of the users of this site. The administrator is not responsible for the collection of data carried out by these companies, does not provide them with data about users and does not cooperate on the collection of data.Logging of access takes place only at the system level, the reason being the identification of any technical or security problems. Other reasons are overview access statistics. No specific data is collected or monitored in this area and all access records are deleted after three months.
Information about contacting the operator of the site
The form for contacting the operator of the site (administrator) contains the following personal data: name, surname, e-mail. These data are intended only for this communication, corresponding to the address of the user and are kept for the time necessary to fulfil the purpose, up to a maximum of one year, unless the user determines otherwise.Information about the order form
In case of an interest in the order form, the form contains more data, i.e. name, surname, e-mail and contact details for the organisation. These data are intended only for this communication, corresponding to the address of the user and are kept for one year, unless the user determines otherwise. In the event that a business relationship is concluded on the basis of this order, only the information required by Czech law on the basis of business relations (company name and address, bank account number, type of course and its price) will continue to be kept by the administrator.Information about the course completion document
Within the course, a course completion document is issued by the processor. This document contains the following data: student's name and surname, the name and date of the course completion and the employer's name. The information is subsequently used for the creation of a linear hash tree (non-modifiable record). This database contains only information about the provided names and company names, which may or may not correspond to reality and is maintained by the processor for possible re-issuance or verification of the document's issuance.Rights of the personal data subject
The customer or visitor of this website has the possibility to request information about the processing of personal data, the right to request access to personal data, or the right to request the correction or deletion of any data held about him. In the case of deletion, this requirement cannot be fulfilled only if it is not data strictly necessary in the course of business. The customer or visitor of this website also has the right to obtain explanations regarding the processing of his personal data if he finds out or believes that the processing is carried out in violation of the protection of his private and personal life or in violation of applicable legislation, and the right to request removal of the resulting situation and to ensure the correction.Furthermore, the customer/visitor of this website may request restriction of processing or object to the processing of personal data and has the right to withdraw his/her consent to the processing of personal data at any time in writing, without prejudice to the lawfulness of their processing prior to such withdrawal. For this purpose, the contact e-mail address support@cryptosession.cz is used.
The customer/visitor has the right to file a complaint against the processing of personal data with the supervisory authority, which is the Office for Personal Data Protection.