A **secure channel** referred in [REQ-TECH-2] and used in transportation is a cryptographically protected communication channel.
When privileged information is transferred or accessed, the transport channel provides confidentiality, integrity protection, endpoint authentication, and protection against downgrade to less secure configurations.
TLS may be used for this purpose, but other mechanisms may also be used where they provide an equivalent level of protection and are implemented as defined in Annex K.
-**[REQ-CRYPTO-0]** The product shall ensure that the channel uses state-of-the-art cryptographic functions and configuration according to the requirements of the foreseeable use.
-**[REQ-TECH-3]** All endpoints in a secure channel shall cryptographically verify others through mutual auhentication.
-**[REQ-CRYPTO-1]** The product shall ensure that the channel can not be impaired by downgrading it [i.10].
-**[REQ-CRYPTO-2]** The product shall implement secure channel as per Annex K.
-**[REQ-CRYPTO-3]** The product shall protect the data transfer, the confidentiality and the integrity of the data according to the requirements of the foreseeable use.
Mutual trust is in plural form not exluding IP Multicast or Anycast usage if implemented.
**Figure 5.2.1-1: Secure channel example with TLS**
The figure 5.2.1-1 is an illustration of a simple TLS protected communication between product and the managed device, where the device initiates the connection towards reachable endpoint based on a DNS address configured into the managed device.
The device validates the provided public certificate and logs in with machine credentials.
NMS authorises the query based on the role and identity of the device.
Conformity with this clause does not require use of DNS, TLS, certificate-based authentication, where equivalent security outcomes are achieved by other means appropriate to the product design and foreseeable use.
Other approaches are possible, including where the product is responsible for initiating the TLS connection towards the managed device and logging into the managed device.
In this case, the managed device is responsible for authorizing the product based on the identity of the product.
### 5.2.2 Cryptographic key intialisation and rotation
@@ -1090,7 +1090,13 @@ Recognising that there may be vulnerabilities discovered between the time that a
This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (b).
***SBD__CRYPTO-1** Cryptographic mechanisms not covered by **CON_CRYPTO-1** shall be disabled by default.
> NOTE: Cryptographic mechanisms not covered by **CON_CRYPTO-1** are disabled by default.
***SBD_CRYPTO-1** For backward compatibility:
* the product shall inform the user about the security implications when not using the default configuration;
* the product shall inform the user the component requiring the weaker mechanism;
* the product shall inform the user the justification for backward compatibility;
* the product shall provide the user a instructions how to transition to a secure cryptography.
> NOTE: The CRA essential requirement laid out in Annex 1 Part 1 (2) (b) foresees an applicability exception to the secure configuration by default in case there is an agreement between manufacturer and business user in relation to a tailor-made product with digital elements.
@@ -1282,15 +1288,6 @@ As the product is delivered without known exploitable vulnerabilities, those leg
6. the cryptographic mechanism is required for a specific set of product functions;
7.<mark>[any additional criteria specified by the vertical standard, where applicable]</mark>.
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-3** To prevent rollback or downgrade:
* the product shall enforce a monotonic policy/configuration version (or equivalent mechanism);
* the product shall record changes in tamper-evident audit logs;
* the product shall prevent re-enabling deprecated algorithms or disabled security checks via rollback without an explicit logged administrative override.
***CON_CRYPTO-4** For backward compatibility:
* the product shall inform the user about the security implications when not using the default configuration;
* the product shall inform the user the component requiring the weaker mechanism;
* the product shall inform the user the justification for backward compatibility;
* the product shall provide the user a instructions how to transition to a secure cryptography.
> 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.
@@ -1306,6 +1303,36 @@ As the product is delivered without known exploitable vulnerabilities, those leg
> 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.
When privileged information is transferred or accessed, the transport channel provides confidentiality, integrity protection, endpoint authentication, and protection against downgrade to less secure configurations.
TLS may be used for this purpose, but other mechanisms may also be used where they provide an equivalent level of protection and are implemented as defined in Annex K.
***CON_CRYPTO-2** To prevent rollback or downgrade:
* the product shall enforce a monotonic policy/configuration version (or equivalent mechanism);
* the product shall record changes in tamper-evident audit logs;
* the product shall prevent re-enabling deprecated algorithms or disabled security checks via rollback without an explicit logged administrative override.
***CON_CHANNEL-1** The product shall ensure that the channel uses cryptographic functions and configuration according to the **CON_CRYPTO-1**.
***CON_CHANNEL-2** All endpoints in a secure channel shall cryptographically verify others through mutual auhentication.
***CON_CHANNEL-3** The product shall ensure that the channel can not be impaired by downgrading it [i.10].
***CON_CHANNEL-4** The product shall implement secure channel as per Annex K.
***CON_CHANNEL-5** The product shall protect the data transfer, the confidentiality and the integrity of the data according to the requirements of the foreseeable use.
**Figure 5.7.2-1: Secure channel example with TLS**
The figure 5.7.2-1 is an illustration of a simple TLS protected communication between product and the managed device, where the device initiates the connection towards reachable endpoint based on a DNS address configured into the managed device.
The device validates the provided public certificate and logs in with machine credentials.
NMS authorises the query based on the role and identity of the device.
Conformity with this clause does not require use of DNS, TLS, certificate-based authentication, where equivalent security outcomes are achieved by other means appropriate to the product design and foreseeable use.
Other approaches are possible, including where the product is responsible for initiating the TLS connection towards the managed device and logging into the managed device.
In this case, the managed device is responsible for authorizing the product based on the identity of the product.
## 5.8 Integrity protection
This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (f).
