| 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. |
| 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. |
| 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. |
| 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. |
| 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. |
| 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. |
| 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 |
| 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 |
| 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. |
| 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 |
| 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. |
| 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. |
| 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. |
| 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. |
| 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. |
| 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. |
| 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. |
| 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. |
| 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. |
| 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 |
| 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. |
| 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. |
| 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. |
| 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. |
| 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. |