CAMM Level 1 Requirements

Level 1 (Possible) Requirements

No 1.0

ID 1.0
Name Systemknowledge
Description For crypto-agility requirements to be effectively evaluated, detailed knowledge of the affected system and its environment is required.
Category Knowledge
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 none
Source Ott et al. 2019
Example Access to source code and/or hardware specification. Black boxes cannot be evaluated.

No 1.1

ID 1.1
Name Updateability
Description Maintainers can modify the system and provide updates to new software versions.
Category Process
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 1.0
Source Kempka 2020 Mehrez and El Omri 2018
Example Mobile apps are often modified by updates. Updateability is not possible for legacy devices without support.

No 1.2

ID 1.2
Name Extensibility
Description The system can be extended with new cryptographic algorithms and parameters.
Category System property
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 1.1
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.

No 1.3

ID 1.3
Name Reversibility
Description The system can be rolled back to a previous state.
Category Process
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 1.0
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.

No 1.4

ID 1.4
Name Cryptography inventory
Description The cryptographic functions used are documented and their current security level is known.
Category Knowledge
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 1.0
Source Kreutzer et al. 2018 Horvath and Mahdi 2017
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.

CAMM Level 2 Requirements

Level 2 (Prepared) Requirements

No 2.0

ID 2.0
Name Cryptographic modularity
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.
Category System property
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 1.0 1.1
Source Kreutzer et al. 2018 Mehrez and El Omri 2018 Housley 2015 Macaulay and Henderson Richter et al. 2021
Example An API separates cryptographic functions and business logic.

No 2.1

ID 2.1
Name Algorithm IDs
Description The algorithms used are uniquely identifiable.
Category Knowledge
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 1.4
Source Housley 2015
Example IDs of the TLS ciphersuites

No 2.2

ID 2.2
Name Algorithm intersection
Description All subsystems share a common set of cryptographic algorithms.
Category System property
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 2.1
Source Housley 2015
Example TLS 1.3 prescribes TLS_AES_128_GCM_SHA256

No 2.3

ID 2.3
Name Algorithm exclusion
Description The system can disable the use of supported algorithms.
Category System property
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 1.1 2.1
Source Housley 2015 Johnson and Millett 2017 Mehrez and El Omri 2018
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.

No 2.4

ID 2.4
Name Opportunistic security
Description The system always uses the strongest available algorithm.
Category System property
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 1.1 2.1 2.2 2.3
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

No 2.5

ID 2.5
Name Usability
Description The Systems crypto-agility modul is easy to use.
Category System property
Problem If crypto-agility is hard to use for developers and end users, it might be configured in a weak manner or not used at all.
Acceptance A usability study proves that the system is easy to use.
Dependency 1.0 1.2 2.2 1.3 2.1
Source Johnson and Millett 2017 Ott et al. 2019
Example If crypto keys are printed out onto QR codes, newer algorithms may require longer keys and thus a greater density of information on the QR codes, which in turn can make the QR codes more error-prone ans thus less usable.

CAMM Level 3 Requirements

Level 3 (Practiced) Requirements

No 3.0

ID 3.0
Name Policies
Description Policies are used to restrict the allowed algorithms and their parameters.
Category Process
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 2.2 2.3 2.4 3.5
Source Macaulay and Henderson
Example Algorithms used must have at least 2048 bit security level. Only certified solutions solutions may be used.

No 3.1

ID 3.1
Name Performance awareness
Description The additional effort and impact of crypto-agility is known and accepted.
Category Knowledge
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 1.0
Source Ott et al. 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.

No 3.2

ID 3.2
Name Hardware modularity
Description Hardware and software can be improved or exchanged independently of each other in a compatible manner.
Category System property
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 1.1
Source Mehrez and El Omri 2018 Ott et al. 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.

No 3.3

ID 3.3
Name Testing
Description The system is regularly tested for compliance with crypto-agility requirements.
Category Process
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 1.0
Source Ott et al. 2019 Steel 2019 Ben Salem and McCarty 2021
Example Fulfillment of requirements gets verified regularly, Migration is run on a parallel test system.

No 3.4

ID 3.4
Name Enforceability
Description Crypto agility can be made mandatory for certain contexts.
Category Process
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 1.0 3.0
Source Ott et al. 2019
Example This model provides a framework against which requirements and measures for a systems crypto-agility can be developed and prescribed.

No 3.5

ID 3.5
Name Security
Description The crypto-agility mechanism is secure against attacks.
Category Knowledge
Problem Crypto agility is useless if it is vulnerable to attacks.
Acceptance No vulnerabilities are detected during audits of the system.
Dependency 2.3 3.0 3.3
Source Ott et al. 2019
Example Regular audits confirm the security of the system.

No 3.6

ID 3.6
Name Backwards compatibility
Description New versions are compatible with older states of the system.
Category System property
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 1.1 2.2 3.7
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.

No 3.7

ID 3.7
Name Transition mechanism
Description A strategy that ensures the functionality of the overall system for the transition period of performing an update.
Category Process
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 1.1 2.1 2.2 2.3 3.6
Source Mehrez and El Omri 2018 Housley 2015 Kreutzer et al. 2018 Steel 2019
Example All subsystems in version 1 are upgraded to version 2 without disruptions after a hybrid transition phase.

No 3.8

ID 3.8
Name Effectiveness
Description Migration between cryptographic algorithms must be feasible in a reasonable amount of time.
Category Process
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 1.4 3.3 3.7
Source Ott et al. 2019
Example x + y < z Mosca 2018

CAMM Level 4 Requirements

Level 4 (Sophisticated) Requirements

No 4.0

ID 4.0
Name Automation
Description Modifications to crypto-agile modules do not require manual interaction.
Category Process
Problem Crypto-agility should require as little user interaction as possible.
Acceptance Changes and system components responsible for cryptographic agility can be made based on pre-determined attributes, such as time and context, without interaction with the system.
Dependency 3.7 3.8
Source Richter et al. 2021
Example CI/CD pipeline initiates transition when new version is available.

No 4.1

ID 4.1
Name Context independence
Description The requirements and techniques used to implement crypto-agility can also be used for other scenarios.
Category System property
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 2.0 3.2
Source Mehrez and El Omri 2018 Ott et al. 2019
Example The mechanism to achieve crypto-agility is applicable in both medicine and IoT scenarios.

No 4.2

ID 4.2
Name Scalability
Description The crypto-agility implementation can be deployed in additional systems.
Category Process
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 2.0 3.2 4.1 4.4
Source Steel 2019
Example Wrapper of the cryptographic agility module for other programming languages exist.

No 4.3

ID 4.3
Name Real-time
Description Modifications to cryptographic functions become active in the production system as immediately as possible.
Category Process
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 3.7 4.0 4.2
Source Steel 2019 Johnson and Millett 2017
Example Cryptography is outsourced as an external, redundant component so that cryptographic tasks can be dynamically forwarded to different implementations.

No 4.4

ID 4.4
Name Cross-System Interoperability
Description Different cryptographically agile systems are interoperable with each other.
Category System property
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 2.2 2.3
Source Housley 2015 Johnson and Millett 2017 Mehrez and El Omri 2018
Example A generally accepted crypto-agility specification is introduced, due to which all systems that follow it are interoperable with each other.