# Towards a maturity model for crypto-agility assessment

Julian Steffen Hohm  Hochschule DarmstadtGermany ,  Andreas Heinemann
Hochschule DarmstadtGermany and  Alexander Wiesmaier  Hochschule
DarmstadtGermany

(2018)

###### Abstract.

This work proposes the Crypto-Agility Maturity Model (CAMM for short), a
maturity model for determining the state of crypto-agility of a given software
or IT landscape. CAMM consists of five levels, for each level a set of
requirements have been formulated based on literature review. Initial feedback
from field experts confirms that CAMM has a well-designed structure and is
easy to comprehend. Based on our model, the cryptographic agility of an IT
landscape can be systematically measured and improved step by step. We expect
that this will enable companies and to respond better and faster to threats
resulting from broken cryptographic schemes. This work serves to promote CAMM
and encourage others to apply it in practice and develop it jointly.

cryptographic agility, Crypto-Agility Maturity Model, CAMM, it security
management

††copyright: acmcopyright††journalyear: 2018††doi:
10.1145/1122445.1122456††conference: Woodstock ’18: ACM Symposium on Neural
Gaze Detection; June 03–05, 2018; Woodstock, NY††booktitle: Woodstock ’18: ACM
Symposium on Neural Gaze Detection, June 03–05, 2018, Woodstock, NY††price:
15.00††isbn: 978-1-4503-XXXX-X/18/06

##  1\. Introduction

In the light of NIST’s current initiative to standardize post-quantum
cryptographic (PQC) algorithms (Computer Security Division, 2017) in order to
withstand potential attacks by powerful quantum computers, for example by
running Shor’s algorithm (Shor, 1994) against RSA, the more fundamental
concept of cryptographic agility (crypto-agility for short) has received an
increasing focus recently, at least as a desirable property in the context of
PQC issues (Niederhagen and Waidner, 2017; Computing Community Consortium
(CCC), 2019; Mehrez and El Omri, 2018; Johnson and Millett, 2017; Grote et
al., 2019a; Kreutzer et al., 2018). Although there is no common understanding
of crypto-agility in general, it is often associated with the ability to
replace a cryptographic scheme in an agile manner with very little efforts.

Following the view of Ott et. al (Computing Community Consortium (CCC), 2019),
in our opinion, crypto-agility needs to be discussed and addressed in a
broader sense. Ott et. al propose the concept of modalities for an expanded
notion of crypto-agility. For example, context agility refers to a crypto-
agile solution, where cryptographic algorithms and strength policies have the
flexibility to be derived automatically from system attributes.

In addition, the demand for crypto-agility can be seen independently of the
current PQC standardization activities of NIST. Just image, NIST will
standardize crypto-scheme X in the near future and X is broken by an even more
clever algorithm than Shor’s algorithm in a few years ahead. This will put us
back in the same situation again and we need to replace X by a stronger scheme
Y in no time. In the face of the quantum computer threat, we should now
transform our crypto solutions into fully comprehensive crypto-agile
solutions.

A first step in this direction is to assess the current crypto-agility of a
particular software or IT system. With this knowledge, further development
towards a crypto-agility solution can then take place. In this work, we
propose the Crypto-Agility Maturity Model (CAMM) to determine the crypto-
agility level of a given software or IT System. CAMM is composed of 5 maturity
levels. For a system to reach a certain level, a number of given requirements
must be met. We have formulated these requirements based on an intensive
literature review on identified crypto-agility publications and assigned them
to the appropriate levels. With CAMM at hand, IT managers can systematically
assess their IT infrastructure and derive concrete measures to further develop
their IT landscape in the direction of crypto-agility.

The further text is structured as follows. Section 2 identifies important
requirements, aspects and properties of crypto-agility derived from
literature, which we will later integrate into our maturity model. This is
followed by the methodology used in order to develop our maturity model for
crypto-agility (Section 3). The model itself is described in Section 4. We
have set up an accompanying website at https://camm.h-da.io in order to
disseminate the model more widely. A brief preliminary evaluation of CAMM is
provided in Section 5, followed by a short discussion and outlook in Section
6. There we point out issues we would like to address in the future.

##  2\. cryptographic agility: Definitions, requirements and aspects

To the best of our knowledge, the notion of cryptographic agility was first
mentioned around 2009/2010 by Bryan Sullivan (Sullivan, 2009, 2010) as a
programming style for abstracting .NET code from hard-coded use of a concrete
hash algorithm, in his case MD5. The term was also coined in 2011 in RFC 6421
(Nelson, 2011) as a communication protocol property. Since then, several
authors have used the term in different manners. Without claiming
completeness, the following understandings can be found in literature.
According to McKay at NIST (Johnson and Millett, 2017) crypto-agility includes
(1) _the ability for machines to select their security algorithms in real time
and based on their combined security functions;_ (2) _the ability to add new
cryptographic features or algorithms to existing hardware or software,
resulting in new, stronger security features;_ and (3) _the ability to
gracefully retire cryptographic systems that have become either vulnerable or
obsolete._ Mehrez and el Omri (Mehrez and El Omri, 2018) and Schneider
(Johnson and Millett, 2017) stress how easy the migration from one crypto
scheme to another can take place. Schneider adds the aspect of remaining
interoperable after a certain hard- or software has evolved. More recently,
cryptographic agility has been mentioned in the context of PQC migration tasks
(Grote et al., 2019b; Richter et al., 2021; Alnahawi et al., 2021).

In addition to the above understandings, at least the following requirements
and aspects for cryptographic agility were requested by different authors: IDs
(for algorithms or sets of algorithms), transitioning, key management,
interoperability (mandatory algorithms), balancing security strengths,
opportunistic security, (effective) migration mechanism (Housley, 2015).
Measurability, interpretability, enforceability, security, performance
(Computing Community Consortium (CCC), 2019). Switch between crypto schemes in
realtime, support for heterogenous environments, policy-aware access to crypto
primitives, automatability (centralized), scalability (Macaulay and Henderson,
[n.d.]). Extensibility, removeability, interoperability, flexibility,
fungibility, reversability, updateability, transition mechanism, backwards
compatibility (Mehrez and El Omri, 2018). Testable (Steel, 2019), usage of
SDKs, crypto APIs (Utimaco, 2018; Niederhagen and Waidner, 2017), preparing
for failure (Johnson and Millett, 2017)

These requirements and aspects vary in granularity and are sometimes vague in
their meaning and implementation. Still, we managed to organize these
requirements and address them at the different levels of CAMM. Appendix A
summarizes the requirements and provides the sources for each requirement. The
tables can also be found at https://camm.h-da.io.

##  3\. Methodology

We describe which methodology was used in order to develop CAMM. In general,
there are two types of maturity models. First focus area maturity models (van
Steenbergen et al., 2010) such as the Dynamic Architecture Maturity Matrix
(DyAMM), the Test Process Improvement (TPI) model and the Software Product
Management (SPM) maturity matrix (Van Den Berg and Van Steenbergen, 2007;
Koomen and Pol, 1999; van de Weerd et al., 2010). Second, fixed-level/staged
maturity models (Becker et al., 2009; Becker et al., 2010) such as CMM resp.
CMMI (Paulk et al., 1993; CMMI Product Team, 2010). We decided to aim at a
fixed-level model because these type of models are far more widely used,
easier to comprehend, and allow for more concrete and comparable statements
(van Steenbergen et al., 2010; Steenbergen et al., 2007). In addition, focus
area maturity models need more data and more experience in the crypto-agility
domain (van Steenbergen et al., 2010) and seemed inappropriate to us, as
crypto-agility research is still in its infancy.

Lasrado et. al (Lasrado et al., 2015) identified three meta models (Becker et
al., 2009; Solli-Sæther and Gottschalk, 2010; Bruin et al., 2005), all
describing a step by step iterative sequential approach for developing a
maturity model. For CAMM, we followed Becker et al. (Becker et al., 2009) as
we judge this approach as the most comprehensive and detailed methodology for
the development of fixed-level models. We, therefore, used it as a starting
point and adapted it for this work. As a result, the following top-down
approach was applied which consists of five phases/steps. We briefly describe
each step and our findings on the basis of Fig. 1.

Figure 1. Applied procedure model for developing CAMM, adapted from (Becker et
al., 2009)

#### Step 1: Problem definition

The first step is to clarify whether and why the lack of a maturity model is
currently a problem for crypto-agility and therefore whether it is worthwhile
to develop a crypto-agility maturity model.

#### Outcome:

A suitable crypto-agility maturity model can help to further expand the state
of knowledge on crypto-agility, as requested by several authors (Computing
Community Consortium (CCC), 2019; Kreutzer et al., 2018; Alnahawi et al.,
2022). A suitable maturity model will therefore allow us to better understand
the state of crypto-agility of a given IT landscape and thus, for example, be
better prepared for the emerging threat of quantum computing.

#### Step 2: Comparison of existing models

In order to solve the previously defined problem, it is researched whether
existing models can be used, improved or adapted in the given context or if an
entirely new model has to be developed.

#### Outcome:

Numerous maturity models have already been identified in the literature
(Becker et al., 2010; Mettler et al., 2010). The most popular CMMI is focused
on processes and is thus not applicable for describing the maturity of a
system’s crypto-agility. Models more specialized in security like the
Cybersecurity Capability Maturity Model (C2M2) (DOE, 2021), the Cybersecurity
Maturity Model Certification (CMMC) (OUSD(A&S), 2020), the Systems Security
Engineering — Capability Maturity Model (SSE-CMM) (ISO/IEC 21827:2008)
(ISO/IEC, 2008) and the Information Security Management Maturity Model
(O-ISM3) (Aceituno, 2017) are mainly focused on improving processes and
practices for cybersecurity and consider crypto-agility only briefly, if at
all. Classification in the Post-Quantum Cryptography (PQC) Maturity Model
(DigiCert, 2020) only focuses on measures against quantum computing threats.
As previously stated, an IT landscape should be as crypto-agile as possible in
order to be prepared for future threats, therefore a more general crypto-
agility maturity model is needed. The Crypto Agility Risk Assessment Framework
(CARAF) only provides a means to analyze and evaluate the risk that results
from the lack of crypto-agility (Ma et al., 2021). Cryptosense reduce their
Maturity Model crypto-agility to technologies and practices provided by their
proprietary Cryptography Lifecycle Management (CLM) (Ross-Gower, 2021). To
sum-up, we have not been able to find an appropriate maturity model that
supports all the requirements formulated for crypto-agility (see Section 2)
and therefore developed CAMM from scratch.

#### Step 3: Iterative maturity model development

The main phase of the process is used to condense the existing crypto-agility
literature requirements into specific dimensions. First, we determine the
objectives and development areas of the iteration. These are the basis for a
first version of a model. Via an iterative process the model is evaluated and
evolves until all requirements fit into the various maturity levels and no
inconsistencies exist.

#### Outcome:

The results are our five maturity levels and the corresponding requirements
leading to CAMM (see Section 4).

#### Step 4: Evaluation

After the development of a maturity model, measures for evaluation,
publication, and maintenance of the model are planned. In contrast to the
process model according to (Becker et al., 2009), the step of evaluation is
preceding the publication of the model in order to be able to implement
potential improvements identified therein before gaining first publicity.

#### Outcome:

Our preliminary results show good structure and comprehensibility for CAMM
(see Section 5).

#### Step 5: Conception of transfer and implementation

Becker et al. (Becker et al., 2009) suggest publishing the maturity model and,
in addition, establishing a website where the maturity level can be
determined. In addition, the website should provide for a survey of model
acceptance, which may indicate the need for further development.

#### Outcome:

Following Becker et al. we set up a website at https://camm.h-da.io. This page
is intended to serve as a central reference source for CAMM. In addition to a
brief description of the model, it contains the list of all requirements,
literature references and publications. We will also provide a toolbox (new
tools or refer to existing ones) to facilitate checking certain requirements
in practice. CAMM is currently labeled with Version 1. Further developments
can then be tagged with higher version numbers. Additionally, the description
of case studies that use CAMM in practice is planned.

##  4\. The Crypto-Agility Maturity Model

The resulting crypto-agility maturity model represents our understanding of
the current state of research on crypto-agility. This model makes it possible
to evaluate a given system according to its ability to implement crypto-
agility requirements. At the same time, it forms a reference that encompasses
the findings from both academia and practice and combines them into an
understanding of the requirements of crypto-agile systems. CAMM’s key
components are the maturity levels and the requirements they contain at each
level, along with their respective properties.

Since it is desirable to have the simplest possible classification while
maintaining a high degree of precision, five maturity levels have emerged as
an appropriate classification size for this model. This number also became a
frequent standard value for maturity models due to the widespread adoption of
the CMM and CMMI (Becker et al., 2009; Lahrmann et al., [n.d.]).

Table 1. CAMM maturity levels Level | Name
---|---
0 | Initial / Not possible
1 | Possible
2 | Prepared
3 | Practiced
4 | Sophisticated

Table 1 illustrates the five defined maturity levels. They are each described
by their name and number and represent a certain development level of a
system. Each level contains a certain number of requirements, all of which
must be met in order to reach that level. In other words, as soon as a
requirement of a given level $X$ is violated, one falls back to level $X-1$
with level 0 as the lowest possible level.

To make the individual maturity levels more tangible, these and the
motivations behind are be presented now. The requirements defined for a
certain level are subsequently specified in Section 4.1.

#### Initial / Not possible

This maturity level expresses the lowest maturity and is reached by default.
The numbering explicitly begins at zero to illustrate the lack of evaluation
or exclusion of crypto-agility. This maturity level implies that there is at
least one system or component that violates the requirements defined at level
1. Possible reasons for this may include hardware or software limitations that
do not allow subsequent changes to the original design. Examples include
devices in the IoT domain that are no longer supported by their manufacturer
and platforms where cryptography is hard-coded to hardware features (Computing
Community Consortium (CCC), 2019). Another familiar scenario is embedded
systems that are inaccessible or where there is no vendor interest in enabling
costly updates.

#### Possible

This maturity level is reached by all systems that can be adapted so that
their cryptography can respond dynamically to future crypto challenges.
However, this does not require any specific activities to be carried out yet,
but only the necessary primary conditions to be met. Many of the requirements
are typical for high-quality software or hardware design.

#### Prepared

Systems that already implement certain measures for crypto-agility, but are
not yet fully ready to actively realize it, are assigned to this level. The
actual change of cryptographic functions still requires some preparatory work
here and means a particular effort, but crypto-agility is already seen as an
implementable goal.

#### Practiced

Crypto-agility is practiced, i.e, migration between different cryptographic
methods is demonstrably, effectively, and securely feasible. In this case,
systems can be assigned to this maturity level. Therefore, several conditions
must be met to ensure the necessary hardware and software requirements and
migration mechanisms.

#### Sophisticated

The highest maturity level is attained by systems that implement advanced
capabilities in terms of crypto-agility. They are particularly characterized
by the fact that compatibility is not limited to a specific system but is
applied in a broader infrastructure. Higher sophistication and practical
testing of the measures allow for a fast migration between different
cryptography schemes. This level of maturity should be strived for
particularly by libraries and frameworks that are intended to be used in the
context of crypto-agility.

Figure 2. CAMM – Stage model perspective

As shown in Fig. 2 the defined maturity levels can be understood as a stage
model. Maturity level 0 forms the lowest stage and symbolizes the lowest or no
capability for crypto-agility. The higher the maturity level, i.e., the higher
the stage, the more agile a systems cryptography is.

For each maturity level, different measures can be used to meet the
requirements, but all must be suitable for achieving a certain level of
maturity.

###  4.1. Requirements

In the following, the requirements that are addressed at a certain level are
presented. Please note, that there are no requirements associated with level 0
of CAMM. Next, each requirement is assigned to a certain category. We have
defined three different categories: Knowledge (K), Process (P), System
property (S). This categorization allows the implementation of measures
necessary to fulfill a certain requirement to be grouped and considered
together. For example, requirements from the category Knowledge require a
similar approach, e.g., the construction of a knowledge database.

Each requirement is labeled by ’R’ following a two-digit number. The first
digit defines the corresponding maturity level, the second digit defines a
sequential ID. This ID does not imply any order of priority. Example: R34
labels requirement 4 within level 3.

#### R10: System knowledge (K)

An adequate evaluation of the requirements of crypto-agility demands detailed
information about the corresponding system. System knowledge thus represents a
requirement that must be met for a system to reach the first maturity level of
crypto-agility. Without detailed knowledge of the system and its domain a
classification is not possible, and the crypto-agility goal of measurability
identified by (Computing Community Consortium (CCC), 2019) cannot be met.
Additionally, the ability to analyze the system is inevitable to assess the
impact on a product or system of an intended change to one or more of its
parts, or to diagnose a product for deficiencies or causes of failures, or to
identify parts to be modified (ISO/IEC, 2011).

#### R11: Updateability (P)

This property describes whether the system can be modified by those
responsible and can be supplied with new software versions without the need to
restrict its functionality (ISO/IEC, 2011). The underlying problem is the
discovery of vulnerabilities in the system and its cryptography, which need to
be fixed after detection. Like initially described by (Mehrez and El Omri,
2018) a system must therefore provide the ability to perform updates. A
prerequisite for the development of such updates is system knowledge.

#### R12: Extensibility (S)

Extensibility can be understood as the process of introducing new
cryptographic algorithms and parameters. In the case of a new attack vector
affecting previous algorithms, new, more secure alternatives can thus be
retrofitted. The ability to add further cryptography methods, variants and
protocols to a system can be understood as an acceptance criterion. This
requirement originates from the crypto-agility properties of (Mehrez and El
Omri, 2018) and requires updateability of the software.

#### R13: Reversibility (P)

In addition to updates, the reversibility of systems is also an important
factor for crypto-agility. The goal of this requirement is to allow a system
to be reset to a previous state. However, unlike the therefore required
updateability, this is not a property of the system but requires an
organizational process. As described by (Mehrez and El Omri, 2018) a system
needs to be able to return to previous version if the update does not operate
as expected.

#### R14: Cryptography inventory (K)

A cryptography inventory is the documentation of the cryptography used in a
system. In addition to simply documenting the algorithms and parameters used,
it is also important to understand their level of security. Thus, this
requirement is an aspect that presupposes a certain knowledge about the system
and the current state of cryptographic security. The rationale for this
requirement is the need to assess a system’s security. If vulnerabilities in
certain cryptographic implementations are discovered, (Kreutzer et al., 2018;
Steel, 2019), among others, demand a cryptography inventory to enable a fast
evaluation of whether a system is affected by them, so countermeasures can be
initiated if necessary.

#### R20: Cryptographic modularity (S)

In the context of crypto-agility, cryptographic modularity is understood as a
system design that enables changes to the cryptographic components without
affecting the functionality of the other system components. In the event of a
vulnerability, the implementation of cryptographic functions, their parameters
and primitives, can be replaced without affecting the system logic. System
knowledge is required to evaluate this property. The necessity of this
property is already confirmed by a large number of experts in this regard
(Mehrez and El Omri, 2018; Richter et al., 2021; Kreutzer et al., 2018;
Housley, 2015; Macaulay and Henderson, [n.d.]).

#### R21: Algorithm IDs (K)

Cryptographic procedures cannot be negotiated between two subsystems without a
convention denoting algorithms and parameters. Thus, common knowledge is
essential to uniquely associate algorithms with their specific parameters for
building agile encrypted communication channels. For IETF protocols, a
mechanism for identification is already mandatory and (Housley, 2015) also
lists it as a requirement for crypto-agility.

#### R22: Algorithm intersection (S)

This requirement implies that all subsystems support a common set of
cryptographic algorithms. Without this intersection of algorithms, secure
communication cannot be established and therefore, at least one algorithm must
be defined that all subsystems mandatorily support. This principle is also
prescribed for IETF protocols and highlighted in RFC 7696 (Housley, 2015) for
cryptographic algorithms agility.

#### R23: Algorithm exclusion (S)

As a counterpart to mandatory algorithms, this property requires a way to
exclude supported algorithms from use. The reason for this is that algorithms
known to be vulnerable should not be used to maintain the security of the
system. However, as originally stated in (Housley, 2015; Mehrez and El Omri,
2018), the exclusion of algorithms simultaneously affects the interoperability
of (sub)systems.

#### R24: Opportunistic security (S)

This requirement pursues the goal of always using the strongest algorithm
supported by the respective communication partners and that is appropriate in
the respective application context. If a particular algorithm cannot be used
for some reason, it is better to use a less secure one than to communicate
without cryptography altogether (Dukhovni, 2014). Even with weak cryptography,
resilience to attacks is increased, albeit minimally in the worst case. This
property requires an intersection of multiple algorithms, assignable by their
ID, which are ranked by their security in the crypto inventory. However, this
property may be constrained by policies that, for example, mandate a certain
level of security. This concept is described in (Dukhovni, 2014) and proposed
by (Housley, 2015) for the crypto-agility of IETF protocols.

#### R30: Policies (P)

Policies serve to constrain the algorithms that are allowed and their
parameters (Macaulay and Henderson, [n.d.]). Without them, insecure algorithms
or algorithms inappropriate for the context could be used. As an essential
factor for the security of systems, they are an essential step in the system
design process and ongoing management. Their specification can constrain the
algorithm intersection, result in algorithm exclusion and hinder opportunistic
security.

#### R31: Performance awareness (K)

Performance awareness describes that the additional overhead for crypto-
agility is known and accepted (Computing Community Consortium (CCC), 2019;
Housley, 2015). If the additional effort of adaptations and deployment for
crypto-agility is not known and accounted for, it may result in unexpected
performance degradation and cost, which could cause the system to fail to meet
specific requirements. To understand the impact of crypto-agility on the
specific circumstances of the system, a deep knowledge of the system is
essential.

#### R32: Hardware modularity (S)

In addition to the cryptographic modularity, a loose binding between hardware
and software is another critical property to support crypto-agility (Mehrez
and El Omri, 2018; Computing Community Consortium (CCC), 2019; Richter et al.,
2021). It represents the possibility of further additions or replacements to
both hardware and software independently and compatible with each other.

#### R33: Testing (P)

If requirements are not tested, no conclusions can be drawn about their
compliance and the quality of the system. A crucial part of the process
towards crypto-agility is regularly testing the system for compliance with
crypto-agile requirements (Steel, 2019; Computing Community Consortium (CCC),
2019; Salem and McCarty, 2021). Therefore, test criteria must exist to
determine which properties the system must meet. The crypto-agility
requirements defined here should be part of the testing.

#### R34: Enforceability (P)

The appropriate measures to achieve crypto-agility must be taken for all
system areas. When the required techniques are carefully specified, a crypto-
agile design can be effectively mandated and enforced (Computing Community
Consortium (CCC), 2019). If the crypto-agility requirements and techniques are
not known, no process can be initiated to implement them. This work
contributes to increasing the enforceability of crypto-agility by providing
the necessary requirements from which actions for systems can be derived and
subsequently implemented.

#### R35: Security (K)

Maintaining security is another integral factor when implementing crypto-
agility(Computing Community Consortium (CCC), 2019). This requires ensuring
that the system is not vulnerable to the threats of various attacks. If this
and the maintenance of the overall security objectives cannot be ensured by
the particular implementation of the cryptographic techniques, they do not
fulfill the expected benefits. In order to obtain knowledge about the security
state of a given system at this level, regular checks must confirm a healthy
security state of the used cryptography and transition mechanisms.

#### R36: Backwards compatibility (S)

This property refers to the time-limited phase during which new versions are
compatible with older states of the system (Mehrez and El Omri, 2018). This
transition period is necessary because the overall system will not be
functional if different concurrently used version states of the subsystems
cannot interact. To ensure that the system does not remain permanently
vulnerable to attack due to security vulnerabilities in old versions, backward
compatibility must only exist within a limited period.

#### R37: Transition mechanism (P)

The process with which it is possible to migrate between cryptographic methods
is mainly responsible for the dynamics of crypto-agility. Here the transition
mechanism constitutes the strategy that ensures the operability of the overall
system for the transition period of performing an update (Mehrez and El Omri,
2018; Housley, 2015; Steel, 2019; Kreutzer et al., 2018). Without a regulated
and secure process, the compatible switch to the new version is not possible
without failures. Therefore, in crypto-agile systems, a methodology must exist
that regulates compatibility and secure communication between subsystems in
different version states for the time-limited duration of the transition and
results in all subsystems being at the new version state afterwards.

#### R38: Effectiveness (P)

The effectiveness of crypto-agility expresses that the process of migrating
between cryptographic algorithms must be feasible in a reasonable amount of
time (Computing Community Consortium (CCC), 2019). The rationale behind this
requirement is to ensure security. If the migration takes longer than the
security of the algorithms can be guaranteed, the whole system is vulnerable.

#### R40: Automation (P)

This is a more advanced measure of crypto-agility, used primarily when a wide
range of platforms should be made crypto-agile. Through automation,
customizations to crypto-agile modules require no, or very little user
interaction and must be able to be performed automatically based on predefined
attributes such as time and context, without interaction with the system
(Macaulay and Henderson, [n.d.]). Thus, the effort for processes within
crypto-agility is minimized by reducing the manual interactions required for
it to a minimum.

#### R41: Context independence (S)

This property requires that requirements and techniques are portable such that
they can be used for other cryptographic scenarios. Also known as
interpretability and flexibility (Computing Community Consortium (CCC), 2019;
Mehrez and El Omri, 2018). This property circumvents the problem that the
approaches used for crypto-agility are each applicable only in their specific
context, and thus a separate solution must be found for each domain.

#### R42: Scalability (P)

To avoid repeating the process of developing a system module for crypto-
agility for all systems, the crypto module must be deployable on other systems
without substantial adjustments. Otherwise, the implementation would always be
tied to specific platforms, and each additional system to be made crypto-agile
would again require a considerable development effort (Macaulay and Henderson,
[n.d.]).

#### R43: Real-time (P)

Another challenge for crypto agility processes is the time required to run
them. In this context, real-time systems assure that adaptations to
cryptographic functions become active in the production system within a
defined period. The goal here is to ensure that adaptations to the
cryptography do not require re-coding and re-booting of the system (Macaulay
and Henderson, [n.d.]).

#### R44: Interoperability (S)

A necessary consideration for crypto-agility is communication beyond the
context of a single system or platform. Here the property of interoperability
expresses that different crypto-agile systems are compatible with each other
(Mehrez and El Omri, 2018; Housley, 2015). The challenge is that connected
systems might not always be in one’s own administrative domain and therefore
cannot be influenced directly. Nevertheless, the global IT infrastructure
should be compatible with all approaches to crypto-agility. To achieve this,
crypto-agile systems must enable information exchange with all foreseen
communication partners based on the information in their respective
specifications.

All requirements are listed in tabular form in Appendix A. For each
requirement, a brief description is given, the problem is outlined, an
acceptance criterion is described, and dependencies and the literature source
on which the criterion is based are given.

##  5\. Preliminary Evaluation

An initial evaluation of CAMM was conducted as part of a master’s thesis(Hohm,
2021) together with a partner company. First, semi-structured interviews were
conducted with two inhouse-experts (one Security Officer and one Consultant
System Software Architect) with regard to the comprehensibility of CAMM. In
addition, the relevance of crypto-agility and post-quantum cryptography within
the company was assessed. While PQC is not yet seen as relevant, they
acknowledge the benefit of the more general cryptographic agility concept.
Both experts confirmed the comprehensibility of CAMM and appreciated the sound
structure. On the other hand, both assume that CAMM must be brought into use
so that more experience can be gained with the model. They assume that
especially level 4 Sophisticated may be be extended or modified.

##  6\. Outlook

Based on an extensive literature review on crypto-agility and the identified
lack of a corresponding maturity model, we propose CAMM to fill this gap. Now,
a broad application of CAMM has to take place to verify the validity and
usefulness of our model and if necessary to adjust the requirements on a
respective level. In addition, a toolbox should be developed that helps to
verify the individual requirements at a certain level with as little effort as
possible.

## References

  * (1)
  * Aceituno (2017) Vicente Aceituno. 2017\.  _Open Information Security Management Maturity Model_.  Open Group Standard. The Open Group.  https://www.ism3.com/node/39
  * Alnahawi et al. (2021) Nouri Alnahawi, Alexander WiesmaierAND Tobias Grasmeyer, Julian Geißler, Alexander Zeier, Pia Bauspieß, and Andreas Heinemann. 2021.  On the State of Post-Quantum Cryptography Migration. In _INFORMATIK 2021 — PQKP-Workshop_ _(GI-Edition: Lecture Notes in Informatics (LNI))_ , Vol. 308. 907–941.
  * Alnahawi et al. (2022) Nouri Alnahawi, Nicolai Schmitt, Alexander Wiesmaier, Andreas Heinemann, and Tobias Graßmeyer. 2022\.  On the State of Crypto Agility. In _18\. Deutscher IT-Sicherheitskongress_. SecuMedia Verlags-GmbH, 103 – 126.
  * Becker et al. (2009) Jörg Becker, Ralf Knackstedt, and Jens Pöppelbuß. 2009\.  Developing Maturity Models for IT Management.  1, 3 (06 2009), 213–222.
  * Becker et al. (2010) Jörg Becker, Bjoern Niehaves, Jens Poeppelbuss, and Alexander Simons. 2010.  Maturity Models in IS Research. In _Int’ Conf. on Information Systems (ICIS) 2010_. Association for Information Systems AIS Electronic Library (AISeL).
  * Bruin et al. (2005) Tonia De Bruin, Michael Rosemann, Ronald Freeze, and Uday Kaulkarni. 2005.  Understanding the Main Phases of Developing a Maturity Assessment Model. In _Australasian Conference on Information Systems (ACIS)_. Australasian Chapter of the Association for Information Systems, 8–19.
  * CMMI Product Team (2010) CMMI Product Team. 2010\.  _CMMI® for Development, Version 1.3_.  Technical Report. Software Engineering Institute, Hanscom AFB.
  * Computer Security Division (2017) Information Technology Laboratory Computer Security Division. 2017.  NIST COMPUTER SECURITY RESOURCE CENTER. PQC Standardization Project.  https://csrc.nist.gov/projects/post-quantum-cryptography
  * Computing Community Consortium (CCC) (2019) Computing Community Consortium (CCC) 2019.  _Identifying Research Challenges in Post Quantum Cryptography Migration and Cryptographic Agility_. Computing Community Consortium (CCC).
  * DigiCert (2020) DigiCert. 2020.  _Post-Quantum Cryptography (PQC) Maturity Model_.  Technical Report.  https://www.digicert.com/content/dam/digicert/pdfs/post-quantum-cryptography-maturity-model-whitepaper-en.pdf
  * DOE (2021) DOE. 2021.  CYBERSECURITY CAPABILITY MATURITY MODEL (C2M2).  https://www.energy.gov/sites/default/files/2021-07/C2M2%20Version%202.0%20July%202021_508.pdf Version 2.0.
  * Dukhovni (2014) Viktor Dukhovni. 2014\.  Opportunistic Security: Some Protection Most of the Time.  RFC 7435.  https://doi.org/10.17487/RFC7435
  * Grote et al. (2019a) Olaf Grote, Andreas Ahrens, and César Benavente-Peces. 2019a.  Paradigm of Post-quantum Cryptography and Crypto-agility: Strategy Approach of Quantum-safe Techniques. In _9th International Conference on Pervasive and Embedded Computing and Communication Systems, PECCS 2019_. ScitePress, 91–98.
  * Grote et al. (2019b) Olaf Grote, Andreas Ahrens, and Cesar Benavente-Peces. 2019b.  A Review of Post-quantum Cryptography and Crypto-agility Strategies. In _2019 International Interdisciplinary PhD Workshop_. IEEE, 115–120.
  * Hohm (2021) Julian Hohm. 2021\.  _Reifegradmodell für die Krypto-Agilität_.  Master’s thesis. Hochschule Darmstadt, Darmstadt, Germany.
  * Horvath and Mahdi (2017) Mark Horvath and David Mahdi. 2017.  _Better Safe Than Sorry: Preparing for Crypto-Agility_.  Technical Report. Gartner.  https://www.gartner.com/en/documents/3645384
  * Housley (2015) Russ Housley. 2015\.  Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms.  RFC 7696.
  * ISO/IEC (2008) ISO/IEC. 2008\.  _Information technology — Security techniques — Systems Security Engineering — Capability Maturity Model® (SSE-CMM®)_ (2 ed.).  Standard ISO/IEC 21827:2008. International Organization for Standardization, Geneva, CH. 144 pages.  https://www.iso.org/standard/44716.html
  * ISO/IEC (2011) ISO/IEC. 2011\.  _Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models_ (1 ed.).  Standard ISO/IEC 25010:2011(E). International Organization for Standardization. 1–34 pages.  https://www.iso.org/standard/35733.html
  * Johnson and Millett (2017) Anne Frances Johnson and Lynette I. Millett (Eds.). 2017\.  _Cryptographic Agility and Interoperability: Proceedings of a Workshop_.  The National Academies Press, Washington, DC.  https://doi.org/10.17226/24636
  * Kempka (2020) Carmen Kempka. 2020\.  PQC4MED Crypto-Agility for Post-Quantum Security In Medical Devices.  _The VAULT_ 26 (8 2020), 26–30.  https://silicontrust.org/wp-content/uploads/2020/08/VAULT_26_final_web.pdf
  * Koomen and Pol (1999) Tim Koomen and Martin Pol. 1999.  _Test Process Improvement: A Practical Step-by-Step Guide to Structured Testing_.  Addison-Wesley Longman Publishing Co., Inc., USA.
  * Kreutzer et al. (2018) Michael Kreutzer, Ruben Niederhagen, and Michael Waidner (Eds.). 2018\.  _Eberbacher Gespräch on Next Generation Crypto_. Frauenhofer SIT.  https://www.sit.fraunhofer.de/de/eberbach-crypto/
  * Lahrmann et al. ([n.d.]) Gerrit Lahrmann, Frederik Marx, Tobias Mettler, Robert Winter, and Felix Wortmann. [n.d.].  Inductive Design of Maturity Models: Applying the Rasch Algorithm for Design Science Research. In _Service-Oriented Perspectives in Design Science Research_ (2011) _(Lecture Notes in Computer Science)_ , Hemant Jain, Atish P. Sinha, and Padmal Vitharana (Eds.). Springer, 176–191.  https://doi.org/10.1007/978-3-642-20633-7_13
  * Lasrado et al. (2015) Lester Allan Lasrado, Ravi Vatrapu, and Kim Normann Andersen. 2015\.  Maturity models development in is research: a literature review. In _IRIS Selected Papers of the Information Systems Research Seminar in Scandinavia_ , Vol. 6. IRIS New York.
  * Ma et al. (2021) Chujiao Ma, Luis Colon, Joe Dera, Bahman Rashidi, and Vaibhav Garg. 2021.  CARAF: Crypto Agility Risk Assessment Framework.  _Journal of Cybersecurity_ 7, 1 (2021).  https://doi.org/10.1093/cybsec/tyab013
  * Macaulay and Henderson ([n.d.]) Tyson Macaulay and Richard Henderson. [n.d.].  Cryptographic Agility in practice: emerging use-cases.  Infosec Global.  https://assets.website-files.com/5bd73d456f7b3f2db2bbbb95/5c76a740dcc2cc4646a06805_ISG_AgilityUseCases_Whitepaper-FINAL.pdf
  * Mehrez and El Omri (2018) Hassane Aissaoui Mehrez and Othmane El Omri. 2018.  The Crypto-Agility Properties.  In _The 12th International Multi-Conference on Society, Cybernetics and Informatics_ , Nagib C. Callaos (Ed.). IIIS, Winter Garden, Florida, U.S.A., 99–103.  http://www.iiis.org/cds2018/cd2018summer/papers/ha536vg.pdf
  * Mettler et al. (2010) Tobias Mettler, Peter Rohner, and Robert Winter. 2010\.  Towards a Classification of Maturity Models in Information Systems. In _Management of the Interconnected World_ , Alessandro D’Atri, Marco De Marco, Alessio Maria Braccini, and Francesca Cabiddu (Eds.). Physica-Verlag HD, Heidelberg, 333–340.  https://doi.org/10.1007/978-3-7908-2404-9_39
  * Mosca (2018) Michele Mosca. 2018\.  Cybersecurity in an Era with Quantum Computers: Will We Be Ready?  _IEEE Security & Privacy_ 16, 5 (2018), 38–41.  https://doi.org/10.1109/MSP.2018.3761723
  * Nelson (2011) David B. Nelson. 2011\.  Crypto-Agility Requirements for Remote Authentication Dial-In User Service (RADIUS).  RFC 6421.  https://doi.org/10.17487/RFC6421
  * Niederhagen and Waidner (2017) Ruben Niederhagen and Michael Waidner. 2017.  _Practical post-quantum cryptography. White Paper_.  Technical Report. Fraunhofer SIT, Darmstadt.  http://publica.fraunhofer.de/dokumente/N-481797.html
  * OUSD(A&S) (2020) OUSD(A&S). 2020\.  Cybersecurity Maturity Model Certification.  https://www.acq.osd.mil/cmmc/docs/CMMC_ModelMain_V1.02_20200318.pdf
  * Paulk et al. (1993) M. C. Paulk, B. Curtis, M. B. Chrissis, and C. V. Weber. 1993\.  Capability maturity model, version 1.1.  _IEEE Software_ 10, 4 (1993), 18–27.
  * Richter et al. (2021) Stefan Richter, Matthew Thornton, Imran Khan, Hamish Scott, Kevin Jaksch, Ulrich Vogl, Birgit Stiller, Gerd Leuchs, Christoph Marquardt, and Natalia Korolkova. 2021.  Agile and Versatile Quantum Communication: Signatures and Secrets.  _Physical Review X_ 11, 1 (2021).  https://doi.org/10.1103/PhysRevX.11.011038
  * Ross-Gower (2021) Sam Ross-Gower. 2021\.  What is Cryptography Lifecycle Management and Why do I need it?  Cryptosense.  https://cryptosense.com/blog/what-is-cryptography-lifecycle-management-and-why-do-i-need-it
  * Salem and McCarty (2021) Malek Ben Salem and Benjamin McCarty. 2021.  _The Race to Crypto-Agility_.  Technical Report. Accenture.
  * Shor (1994) P. W. Shor. 1994\.  Algorithms for quantum computation: discrete logarithms and factoring. In _Proceedings 35th Annual Symposium on Foundations of Computer Science_. 124–134.  https://doi.org/10.1109/SFCS.1994.365700
  * Solli-Sæther and Gottschalk (2010) Hans Solli-Sæther and Petter Gottschalk. 2010.  The Modeling Process for Stage Models.  _J. Org. Computing and E. Commerce_ 20 (07 2010), 279–293.
  * Steel (2019) Graham Steel. 2019\.  Achieving ’Crypto Agility’.  Cryptosense.  https://cryptosense.com/blog/achieving-crypto-agility
  * Steenbergen et al. (2007) Marlies Steenbergen, Martin van den Berg, and Sjaak Brinkkemper. 2007.  A Balanced Approach to Developing the Enterprise Architecture Practice. 240–253.
  * Sullivan (2009) Bryan Sullivan. 2009\.  Cryptographic Agility.  In _MSDN Magazine_. Vol. 24.  https://docs.microsoft.com/en-us/archive/msdn-magazine/2009/august/cryptographic-agility
  * Sullivan (2010) Bryan Sullivan. 2010\.  Cryptographic Agility.  In _BLACK HAT USA 2010_. CAESARS PALACE LAS VEGAS.  https://media.blackhat.com/bh-us-10/whitepapers/Sullivan/BlackHat-USA-2010-Sullivan-Cryptographic-Agility-wp.pdf
  * Utimaco (2018) Utimaco. 2018.  Quantum-Computing_EN_vfinal.  https://hsm.utimaco.com/wp-content/uploads/2018/03/Utimaco_Whitepaper_Quantum-Computing_EN_vfinal.pdf
  * van de Weerd et al. (2010) Inge van de Weerd, Willem Bekkers, and Sjaak Brinkkemper. 2010\.  Developing a Maturity Matrix for Software Product Management. In _Software Business_ , Pasi Tyrväinen, Slinger Jansen, and Michael A. Cusumano (Eds.). Springer, 76–89.
  * Van Den Berg and Van Steenbergen (2007) Martin Van Den Berg and Marlies Van Steenbergen. 2007.  _Building an enterprise architecture practice: tools, tips, best practices, ready-to-use insights_.  Springer Science & Business Media.  https://doi.org/10.1007/978-1-4020-5606-2
  * van Steenbergen et al. (2010) Marlies van Steenbergen, Rik Bos, Sjaak Brinkkemper, Inge van de Weerd, and Willem Bekkers. 2010.  The Design of Focus Area Maturity Models.  In _Global Perspectives on Design Science Research_. Lecture Notes in Computer Science, Vol. 6105. Springer, 317–332.

##  Appendix A Requirements

See next page onwards.

Table 2. Requirements on Level 1

Name |  Systemknowledge
---|---
ID |  10
Category |  Knowledge
Description |  For crypto-agility requirements to be effectively evaluated, detailed knowledge of the affected system and its environment is required.
Problem |  Without knowledge about the systems and understanding about their domain, no assertions can be made about them and crypto-agility cannot be measured.
Acceptance |  An in-depth understanding of the structure and operation of the systems being evaluated is available.
Dependency |  -
Source |  (Computing Community Consortium (CCC), 2019)
Example |  Access to source code and/or hardware specification. Black boxes cannot be evaluated.

Name |  Updateability
---|---
ID |  11
Category |  Process
Description |  Maintainers can modify the system and provide updates to new software versions.
Problem |  If vulnerabilities are identified in the system and its cryptography, it should be possible to fix them.
Acceptance |  Performing updates with modifications is possible.
Dependency |  10
Source |  (Mehrez and El Omri, 2018; Kempka, 2020)
Example |  Mobile apps are often modified by updates. Modifiability is not possible for legacy devices without support.

Name |  Extensibility
---|---
ID |  12
Category |  System property
Description |  The system can be extended with new cryptographic algorithms and parameters.
Problem |  In the event of a new attack vector that affects all previous algorithms, new, secure alternatives need to be added.
Acceptance |  Further cryptography methods, variants and protocols can be added.
Dependency |  11
Source |  (Mehrez and El Omri, 2018; Johnson and Millett, 2017)
Example |  Additional capacity that may be needed later is considered in the design of a system. Not possible for IOT devices that are already at the memory limit or whose performance is not sufficient for more computationally intensive algorithms.

Name |  Reversibility
---|---
ID |  13
Category |  Process
Description |  The system can be rolled back to a previous state.
Problem |  If an update results in problems, the system can be can be rolled back to a previous, functional state.
Acceptance |  Rollbacks to previous versions are possible.
Dependency |  10
Source |  (Mehrez and El Omri, 2018)
Example |  Due to a bug in a system update the system does not behave as expected and is rolled back to a previous state.

Table 3. Requirements on Level 1 (continued) Name |  Cryptography inventory
---|---
ID |  14
Category |  Knowledge
Description |  The cryptographic functions used are documented and their current security level is known.
Problem |  In order to assess whether the system is affected by known vulnerabilities in certain cryptography variants, there must be an overview of the cryptography implementations used.
Acceptance |  A listing of the cryptographic methods used, their parameters and intended use is available, and current developments and recommendations for action on cyber security are observed.
Dependency |  10
Source |  (Horvath and Mahdi, 2017; Kreutzer et al., 2018)
Example |  Inventory as a table with table with the following information: cryptography methods, primitives used, key length, purpose of use, security level, date of deployment, date of deactivation. Trends and developments in cryptographic security are tracked at conferences and in related publications.

Table 4. Requirements on Level 2

Name |  Cryptographic modularity
---|---
ID |  20
Category |  System property
Description |  The system is modularly designed in such a way that changes to the cryptographic components do not affect the functionality of the other system components coupled to it.
Problem |  If the implementation of the cryptographic functions contains vulnerabilities, it can be replaced by another one without affecting the rest of the system logic.
Acceptance |  The specific implementation of the cryptographic functions, their parameters and primitives can be exchanged without affecting the other system components.
Dependency |  10, 11
Source |  (Housley, 2015; Mehrez and El Omri, 2018; Richter et al., 2021; Macaulay and Henderson, [n.d.]; Kreutzer et al., 2018)
Example |  An API separates cryptographic functions and business logic.

Name |  Algorithm IDs
---|---
ID |  21
Category |  Knowledge
Description |  The algorithms used are uniquely identifiable.
Problem |  Without a common understanding of the conventions used to designate algorithms and the parameters used, no cryptographic procedures can be negotiated between two subsystems.
Acceptance |  Each algorithm used with its specific parameters is uniquely referenced by an identifier.
Dependency |  14
Source |  (Housley, 2015)
Example |  IDs of the TLS ciphersuites

Name |  Algorithm intersection
---|---
ID |  22
Category |  System property
Description |  All subsystems share a common set of cryptographic algorithms.
Problem |  A common intersection of algorithms is required to enable interoperability of different sub-systems.
Acceptance |  At least one algorithm is defined that is supported by all subsystems.
Dependency |  21
Source |  (Housley, 2015)
Example |  TLS 1.3 prescribes TLS_AES_128_GCM_SHA256

Name |  Algorithm exclusion
---|---
ID |  23
Category |  System property
Description |  The system can disable the use of supported algorithms.
Problem |  If certain algorithms are vulnerable, they should not further be used.
Acceptance |  If an algorithm is marked as obsolete, it is no longer used for cryptographic tasks.
Dependency |  11, 21, 44
Source |  (Housley, 2015; Mehrez and El Omri, 2018; Johnson and Millett, 2017)
Example |  Legacy algorithms in TLS 1.3 may only be used to ensure backward compatibility with TLS 1.2. MD5 is still widely used for fast, manual checking of downloads for integrity; its use for security-related cryptographic purposes should be discouraged today due to the comparably low collision resistance and the resulting attack vectors.

Table 5. Requirements on Level 2 (continued) Name |  Opportunistic security
---|---
ID |  24
Category |  System property
Description |  The system always uses the strongest available algorithm.
Problem |  If a certain algorithm cannot be used for certain reasons, it is better to use the next most secure algorithm than to discard cryptography altogether.
Acceptance |  The choice of cryptographic algorithms is based on the greatest possible security that is supported by all the subsystems involved, while complying with possible guidelines.
Dependency |  11, 21, 22, 23, 30
Source |  (Housley, 2015)
Example |  Despite weaknesses of MD5, it continues to be used when it is the only mutually supported and therefore the strongest option.

Table 6. Requirements on Level 3

Name |  Policies
---|---
ID |  30
Category |  Process
Description |  Policies are used to restrict the allowed algorithms and their parameters.
Problem |  Without guidelines, insecure algorithms or algorithms unsuitable for the context could be used.
Acceptance |  Guidelines that define the minimum requirements for crypto-agile systems are specified and complied with by the algorithms used.
Dependency |  22, 23, 24, 35
Source |  (Macaulay and Henderson, [n.d.])
Example |  Algorithms used must have at least 2048 bit security level. Only certified solutions solutions may be used.

Name |  Performance awareness
---|---
ID |  31
Category |  Knowledge
Description |  The additional effort and impact of crypto-agility is known and accepted.
Problem |  If the additional effort due to crypto-agility customizations and deployment is not known and accounted for, it may result in unexpected performance degradation and costs, which could cause the system to fail to meet certain requirements.
Acceptance |  Efforts for implementation and efficiency correspond to previously established requirements.
Dependency |  10
Source |  (Computing Community Consortium (CCC), 2019; Housley, 2015)
Example |  The agile platform implies 25% overhead in connection setup compared to using classical cryptography and 100 man-days of development effort.

Name |  Hardware modularity
---|---
ID |  32
Category |  System property
Description |  Hardware and software can be improved or exchanged independently of each other in a compatible manner.
Problem |  Agility is prevented if the system is restricted by the software or hardware used.
Acceptance |  Adaptations to the hardware are possible without affecting its compatibility with the software and vice versa.
Dependency |  11
Source |  (Mehrez and El Omri, 2018; Computing Community Consortium (CCC), 2019; Richter et al., 2021; Kempka, 2020)
Example |  The system provides interfaces that enable the use of more powerful hardware, hardware for quantum cryptography, or more efficient implementation.

Name |  Testing
---|---
ID |  33
Category |  Process
Description |  The system is regularly tested for compliance with crypto-agility requirements.
Problem |  Appropriate tests are required to measure the fulfillment of the requirements and quality of the system.
Acceptance |  There are test criteria that the system must meet, which are regularly checked for compliance.
Dependency |  10
Source |  (Steel, 2019; Computing Community Consortium (CCC), 2019; Salem and McCarty, 2021)
Example |  Fulfillment of requirements gets verified regularly, Migration is run on a parallel test system.

Table 7. Requirements on Level 3 (continued)

Name |  Enforceability
---|---
ID |  34
Category |  Process
Description |  Crypto agility can be made mandatory for certain contexts.
Problem |  If the requirements and techniques of crypto-agility are not known, it cannot be implemented.
Acceptance |  The required techniques are carefully specified and a crypto agile design can be effectively prescribed and enforced.
Dependency |  10, 30
Source |  (Computing Community Consortium (CCC), 2019)
Example |  This model provides a framework against which requirements and measures for a systems crypto-agility can be developed and prescribed.

Name |  Security
---|---
ID |  35
Category |  Knowledge
Description |  The crypto-agility mechanism is secure against attacks.
Problem |  Crypto agility is useless if it is vulnerable to attacks.
Acceptance |  No vulnerabilities are detected during audits of the system.
Dependency |  23, 30, 33
Source |  (Computing Community Consortium (CCC), 2019)
Example |  Regular audits confirm the security of the system.

Name |  Backwards compatibility
---|---
ID |  36
Category |  System property
Description |  New versions are compatible with older states of the system.
Problem |  The system as a whole is not functional if subsystems with different versions cannot interact with each other.
Acceptance |  New versions of the system must support all functions of the previous version during the transition phase.
Dependency |  11,22,37
Source |  (Mehrez and El Omri, 2018)
Example |  Version 2 of a system ensures full functionality in conjunction with subsystems that are still in version 1.

Name |  Transition mechanism
---|---
ID |  37
Category |  Process
Description |  A strategy that ensures the functionality of the overall system for the transition period of performing an update.
Problem |  Agility requires transitions between old and new versions, which must follow a regulated and secure process.
Acceptance |  There is a methodology that regulates compatibility and secure communication between subsystems in different versions for the limited duration of the transition, resulting in all subsystems being at the new version status afterwards.
Dependency |  11, 21, 22, 23, 36
Source |  (Mehrez and El Omri, 2018; Housley, 2015; Steel, 2019; Kreutzer et al., 2018)
Example |  All subsystems in version 1 are upgraded to version 2 without disruptions after a hybrid transition phase.

Name |  Effectiveness
---|---
ID |  38
Category |  Process
Description |  Migration between cryptographic algorithms must be feasible in a reasonable amount of time.
Problem |  If the migration takes longer than the security of the algorithms can be guaranteed, the entire system is vulnerable.
Acceptance |  After a vulnerability in the used cryptography becomes known, it is eliminated promptly and, if possible, before the attacks become practically relevant by migrating to a secure alternative.
Dependency |  14, 33, 37
Source |  (Computing Community Consortium (CCC), 2019)
Example |  x + y ¡ z (Mosca, 2018)

Table 8. Requirements on Level 4

Name |  Automation
---|---
ID |  40
Category |  Process
Description |  Modifications to crypto-agile modules do not require manual interaction.
Problem |  crypto-agility should require as little user interaction as possible.
Acceptance |  Changes and system components responsible for crypto-agility can be made based on pre-determined attributes, such as time and context, without interaction with the system.
Dependency |  37, 38
Source |  (Macaulay and Henderson, [n.d.]; Richter et al., 2021)
Example |  CI/CD pipeline initiates transition when new version is available.

Name |  Context independence
---|---
ID |  41
Category |  System property
Description |  The requirements and techniques used to implement crypto-agility can also be used for other scenarios.
Problem |  The approaches used for crypto-agility should not only be applicable in a specific context.
Acceptance |  The cryptographic approach used must be applicable to at least one other domain.
Dependency |  20, 32
Source |  (Computing Community Consortium (CCC), 2019; Mehrez and El Omri, 2018)
Example |  The mechanism to achieve crypto-agility is applicable in both medicine and IoT scenarios.

Name |  Scalability
---|---
ID |  42
Category |  Process
Description |  The crypto-agility implementation can be deployed in additional systems.
Problem |  If an implementation is always tied to specific platforms, each additional system that is to be made cryptographically agile again means a major development effort.
Acceptance |  The crypto-agility module can be deployed in other systems without in other systems without extensive adaptation.
Dependency |  20, 32, 41, 44
Source |  (Macaulay and Henderson, [n.d.])
Example |  Wrapper of the crypto-agility module for other programming languages exist.

Name |  Real-time
---|---
ID |  43
Category |  Process
Description |  Modifications to cryptographic functions become active in the production system as immediately as possible.
Problem |  Modifications to cryptography should not go live only after a long period of time.
Acceptance |  Added cryptography implementations are reliably ready for use within a defined time period.
Dependency |  37, 40, 42
Source |  (Macaulay and Henderson, [n.d.]; Johnson and Millett, 2017)
Example |  Cryptography is outsourced as an external, redundant component so that cryptographic tasks can be dynamically forwarded to different implementations.

Table 9. Requirements on Level 4 (continued) Name |  Interoperability
---|---
ID |  44
Category |  System property
Description |  Different cryptographically agile systems are interoperable with each other.
Problem |  The compatibility of the cryptography of the global IT infrastructure should not be affected by the introduction of crypto-agility.
Acceptance |  The crypto-agile system enables information exchange with all foreseen communication partners.
Dependency |  22, 23
Source |  (Mehrez and El Omri, 2018; Housley, 2015; Johnson and Millett, 2017)
Example |  A generally accepted crypto-agility specification is introduced, due to which all systems that follow it are interoperable with each other.