@@ -193,8 +193,15 @@ For the purposes of the present document, the terms given in Regulation (EU) 202
12.**cryptographic property**: property provided or supported by a cryptographic mechanism
13.**cryptographic mechanism**: security-related procedure using cryptography
> NOTE 1: The term “cryptographic mechanism” is used in this annex as an umbrella term covering the categories used in the ECCG Agreed Cryptographic Mechanisms (ACM) catalogue [\[1\]](#_ref_1), including cryptographic algorithms, primitives, schemes, protocols, protocol profiles, cipher suites, modes of operation, constructions and parameter sets.
> NOTE 2: The terms “cryptographic primitive”, “cryptographic construction”, “cryptographic scheme” and “cryptographic protocol” are used consistently with the ECCG Agreed Cryptographic Mechanisms (ACM) catalogue [\[1\]](#_ref_1).
> NOTE 3: A cryptographic mechanism can be specified at different levels of abstraction. For example, AES is a cryptographic primitive, AES-GCM is a mode of operation / authenticated encryption construction, TLS 1.3 is a protocol, a TLS 1.3 restricted cipher-suite profile is a protocol profile, and TLS_AES_128_GCM_SHA256 is a cipher suite.
> NOTE 4: Cryptographic properties include, for example, confidentiality, integrity, authenticity, entity authentication, message authentication, key establishment, key confirmation, replay protection, collision resistance, second-preimage resistance, pre-image resistance, signature unforgeability, non-repudiation, forward secrecy and password-verifier protection. Where relevant, a cryptographic property can be expressed using a formal cryptographic notion, for example IND-CPA, IND-CCA, IND-CCA2, EUF-CMA, SUF-CMA or authenticated key exchange security.
> NOTE 5: A cryptographic property is distinct from a product-level technical requirement, although it can support such a requirement. For example, a secure communication requirement can rely on cryptographic properties such as confidentiality, integrity and authentication.
## 3.2 Symbols
@@ -1356,36 +1363,11 @@ As the product is delivered without known exploitable vulnerabilities, those leg
***CON_CRYPTO-1** The product’s default configuration shall only use cryptographic mechanisms that meet at least one of the following criteria:
1. ACM-listed: the cryptographic mechanism is listed in the ECCG Agreed Cryptographic Mechanisms (ACM) catalogue \[i.8\].
2. ACM-extended: the cryptographic mechanism is not listed in the ECCG Agreed Cryptographic Mechanisms (ACM) catalogue \[i.8\] and meets at least one of the following conditions:
1. the cryptographic mechanism is listed in clause K.3.2 as an ACM-extended cryptographic mechanism for the specific product function(s);
2. where the cryptographic mechanism is not listed in clause K.3.2, the cryptographic mechanism meets all the following criteria:
1. the cryptographic mechanism, or where applicable the ACM-listed cryptographic mechanism on which it is based, is not deprecated per the ECCG Agreed Cryptographic Mechanisms (ACM) catalogue \[i.8\];
2. the cryptographic mechanism has been specified, developed or maintained through a transparent process by a recognised European, international or sector-specific standards development organisation, or by an industry specification organisation accountable for the relevant specification, including CEN, CENELEC, ETSI, ISO, IEC, ISO/IEC JTC 1, IETF, IEEE, ITU-T, NIST, 3GPP, O-RAN Alliance, BSI, ACN, C2SP; or the cryptographic mechanism is listed as suitable in a publicly available cryptographic catalogue maintained by a recognised national or governmental cybersecurity authority, where the catalogue is maintained under a documented revision and retirement process, including BSI TR-02102-1, BSI TR-02102-2, BSI TR-02102-3 and BSI TR-02102-4;
3. the cryptographic mechanism is described in a valid, publicly available and uniquely referenceable specification;
4. the cryptographic properties of the cryptographic mechanism are known;
5. no known weakness affects the cryptographic mechanism in a way that affects its cryptographic properties;
6. the cryptographic mechanism is required for a specific set of product functions;
3. Interoperability-based: the cryptographic mechanism is listed in clause K.4.2 as an interoperability-based cryptographic mechanism for specific product function(s) and external specification(s) or external requirement(s).
***CON_CRYPTO-1** The product shall implement Annex K where relevant.
***CON_CRYPTO-2** To prevent rollback or downgrade [i.10] the product shall:
* enforce a monotonic policy/configuration version (or equivalent mechanism);
* preven the re-enabling of deprecated algorithms or the disabling of security checks via a rollback operation without having an explicit logged administrative override in place.
> NOTE 1: The reference to the product’s default configuration is intended to define a clear and assessable baseline, corresponding to the configuration in which the product is placed on the market. The product can provide several configurations that fulfil the requirement.
> NOTE 2: For products supplied as hardware platforms or components to be configured by an integrator, references in this annex to the product’s default configuration refer to the configuration specified for the intended operational use of the product after integration, including the relevant integration assumptions and configuration constraints.
> NOTE 3: The applicable ACM catalogue version is identified in the normative references of the present document.
> The lifecycle treatment of mechanisms affected by ACM deprecation dates, expiry dates, migration conditions or usage limitations is addressed in clause K.2.
> NOTE 4: In this clause, an external specification or external requirement means a specification or requirement that is imposed on the product, and which requires the use of a specific cryptographic mechanism for the product to interoperate with an identified system, platform or operational context.
> An external requirement can be a regulatory requirement, operational constraint, technical interoperability constraint, or platform compatibility requirement.
> NOTE 5: Inclusion of a cryptographic mechanism under the interoperability-based criterion does not classify that mechanism as state-of-the-art cryptography.
> EXAMPLE: Examples of product functions include secure communication based on TLS 1.3; authenticated encryption of communicated data based on AES-GCM; storage confidentiality based on AES-XTS; firmware signature verification based on Ed25519; and key derivation based on HKDF.
### 5.7.2 Secure channel
A **secure channel** used in transportation is a cryptographically protected communication channel.
The product’s default configuration shall only use cryptographic mechanisms that meet at least one of the following criteria:
1. ACM-listed: the cryptographic mechanism is listed in the ECCG Agreed Cryptographic Mechanisms (ACM) catalogue \[i.8\].
2. ACM-extended: the cryptographic mechanism is not listed in the ECCG Agreed Cryptographic Mechanisms (ACM) catalogue \[i.8\] and meets at least one of the following conditions:
1. the cryptographic mechanism is listed in clause K.3.2 as an ACM-extended cryptographic mechanism for the specific product function(s);
2. where the cryptographic mechanism is not listed in clause K.3.2, the cryptographic mechanism meets all the following criteria:
1. the cryptographic mechanism, or where applicable the ACM-listed cryptographic mechanism on which it is based, is not deprecated per the ECCG Agreed Cryptographic Mechanisms (ACM) catalogue \[i.8\];
2. the cryptographic mechanism has been specified, developed or maintained through a transparent process by a recognised European, international or sector-specific standards development organisation, or by an industry specification organisation accountable for the relevant specification, including CEN, CENELEC, ETSI, ISO, IEC, ISO/IEC JTC 1, IETF, IEEE, ITU-T, NIST, 3GPP, O-RAN Alliance, BSI, ACN, C2SP; or the cryptographic mechanism is listed as suitable in a publicly available cryptographic catalogue maintained by a recognised national or governmental cybersecurity authority, where the catalogue is maintained under a documented revision and retirement process, including BSI TR-02102-1, BSI TR-02102-2, BSI TR-02102-3 and BSI TR-02102-4;
3. the cryptographic mechanism is described in a valid, publicly available and uniquely referenceable specification;
4. the cryptographic properties of the cryptographic mechanism are known;
5. no known weakness affects the cryptographic mechanism in a way that affects its cryptographic properties;
6. the cryptographic mechanism is required for a specific set of product functions;
3. Interoperability-based: the cryptographic mechanism is listed in clause K.4.2 as an interoperability-based cryptographic mechanism for specific product function(s) and external specification(s) or external requirement(s).
> NOTE 1: The reference to the product’s default configuration is intended to define a clear and assessable baseline, corresponding to the configuration in which the product is placed on the market. The product can provide several configurations that fulfil the requirement.
> NOTE 2: For products supplied as hardware platforms or components to be configured by an integrator, references in this annex to the product’s default configuration refer to the configuration specified for the intended operational use of the product after integration, including the relevant integration assumptions and configuration constraints.
> NOTE 3: The applicable ACM catalogue version is identified in the normative references of the present document. The lifecycle treatment of mechanisms affected by ACM deprecation dates, expiry dates, migration conditions or usage limitations is addressed in clause K.2.
> NOTE 4: In this clause, an external specification or external requirement means a specification or requirement that is imposed on the product, and which requires the use of a specific cryptographic mechanism for the product to interoperate with an identified system, platform or operational context. An external requirement can be a regulatory requirement, operational constraint, technical interoperability constraint, or platform compatibility requirement.
> NOTE 5: Inclusion of a cryptographic mechanism under the interoperability-based criterion does not classify that mechanism as state-of-the-art cryptography.
> EXAMPLE: Examples of product functions include secure communication based on TLS 1.3; authenticated encryption of communicated data based on AES-GCM; storage confidentiality based on AES-XTS; firmware signature verification based on Ed25519; and key derivation based on HKDF.
### K.1.2 Assessment of product cryptographic configuration
