Version 1.1 | 23.09.2022
The model consists of five levels (aka stages). Each level is defined by a number of requirements that must be fulfilled on that level.
The maturity levels defined in CAMM serve as a core element for assessing the crypto-agility of a given IT-system. Since the simplest possible classification with a sufficient high degree of precision is desired, five maturity levels have emerged as an appropriate classification for CAMM. This number has also become accepted as a frequent standard value for maturity models like CMM and CMMI (cf. Becker et al., 2009; Lahrmann et al., 2011).
With a smaller number of distinguishable maturity levels, the classification is easier, but the validity suffers. The subdivision into further levels increases the accuracy, but also makes the model more complex. Since current research on crypto-agility is still in its infancy, there is not yet a knowledge base that could justify such a fine-grained differentiation. We may revise the granularity of CAMM or add/remove/move requirements in the future. See below for a history of CAMM adjustments over time.
Level | Name | Requirements |
---|---|---|
0 | Initial / Not possible | none |
1 | Possible | Details |
2 | Prepared | Details |
3 | Practiced | Details |
4 | Sophisticated | Details |
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. Prime examples are devices in the IoT domain that are no longer supported by their manufacturer and platforms where cryptography is hard-coded to hardware features. Another familiar scenario is embedded systems that are inaccessible or where there is no vendor interest in enabling costly updates.
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.
Systems that already implement certain measures for \ca{}, but are not yet fully ready to actively realize it, are assigned in this level. The actual change of cryptographic functions still requires some preparatory work here and means a particular effort, but CA is already seen as an implementable goal.
Crypto-agilityis 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 a number of conditions must be met to ensure the necessary hardware and software requirements and migration mechanisms.
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 allows for a fast migration between different cryptography schemes. This level of maturity should be strived for particularly by libraries and frameworks that are intended for crypto-agility.
Version | Date | Changes |
---|---|---|
1 | 06.02.2022 | -/- (initial Version) |
1.1 | 23.09.2022 | Requirement R2.5 Usability was added |