Secure Updates

cloud

: data centre or collection of data centres operated entirely by a third party which rents out space and time on their equipment, as well as providing services for managing infrastructure from outside networks

update

: FIXME

rollback attack

: FIXME

## 3.2 Abbreviations

For the purposes of the present document, the following abbreviations apply:

  * Verdict: The installation fails and warns the user about an invalid signature and possible tampering => PASS, otherwise FAIL

  * Evidence: New update version numbers, and installation log containing mention of a signature mismatch.

#### 5.2.4.8 MI-SUAU: Only authorized software updates

The product shall reject an update that does not match the expected cryptographic hash.

* Reference: TR-SCUD

* Objective: Secure updates

* Preparation: Create an update with an invalid hash

* Activities: Attempt to install the update

* Verdict: Update is not installed => PASS, otherwise => FAIL

* Evidence: Update and invalid hash, error message, before and after comparison of any data that would have been altered if it had been installed

#### 5.2.4.9 MI-SUVH: Secure update has validly signed hash

The product shall reject a hash that is not validly signed by an authorized signing authority.

*Guidance*

The product needs a method of knowing what specific updates are valid for installation. Because of the requirement MI-SURP (rollback protection), the product must have a method of knowing also which previously-valid updates are no longer valid. A simple way of doing this is by providing the device with a metadata file listing all updates that are valid along with each update's hash, size, and name. The device downloads this metadata file upon each update check, verifies that it is signed by a valid signing key, and performs other necessary checks (such as checking expiry or replacement).

* Reference: TR-SCUD

* Objective: Secure updates

* Preparation: Create updates with an invalid hash and correct file size, a valid hash and invalid file size, and an invalid hash and file size

* Activities: Attempt to install each of the created updates

* Verdict: All updates are not installed => PASS, otherwise => FAIL

* Evidence: Updates and invalid hashes and file sizes, error message, before and after comparison of any data that would have been altered if it had been installed

#### 5.2.4.10 MI-SURP: Invalidated update is rejected

The product shall reject an update file that has been indicated to no longer be valid, even if that update file was valid at some point in the past.

*Guidance*

This requirement should not be interpreted to mean that update systems should always have exactly one valid version, and prevent rollbacks to anything but the most current version. However, it is important that products have a way of determining whether a particular update, that was issued at some point in the past and was trusted at the instant it was issued, should still be trusted.

The exact parameters and criteria by which software releases are considered to be trusted are defined by the manufacturer, determined by the product, its security needs, and its intended and reasonably foreseeable uses. Examples of when a software update might be considered to no longer be valid include:

- An old software release is determined to have a critical and remotely-exploitable vulnerability; if that version of software is installed and connected to a network, it is very likely to be compromised.

- An attacker manages to execute a targeted software supply chain attack, and releases a compromised version of a package.

- A product is used in a safety-critical context, and needs to constantly be updated to the latest released version of its firmware to remain in contractual or regulatory compliance for its specific industrial context. The manufacturer therefore repudiates/revokes all previous software versions as soon as they release a new one.

If the update system makes use of a signed metadata file as suggested in the guidance for MI-XXXX, revoking a particular update is simply a matter of removing it from the metadata file, updating the metadata file's version number, and signing the new version. The product can then download and check the metadata file from the repository.

* Reference: TR-SCUD

* Objective: Prevent rollback attacks by rejecting previously-valid packages that contain vulnerabilities

* Preparation: Create an update image that was formerly valid but has been revoked from the repository metadata

* Activities: Attempt to install the revoked update

* Verdict: Update is not installed => PASS, otherwise => FAIL

* Evidence: Revoked update image, error message, before and after comparison of any data that would have been altered if it had been installed

FIXME JON NOTES: Perhaps we can add a definition of "rollback attack" to reduce confusion here. It's not a rollback attack to if there are multiple different versions of software that are simultaneously endorsed/trusted for installation. It's only a rollback attack when the software updater on the product/device can be tricked into trusting a software package that is no longer valid, or tricked into thinking that an older software version is actually a new update.

#### 5.2.4.11 MI-SURC: Signing keys have strictly scoped usage

The key or keys authorized to sign Repository Metadata shall be keys restricted to this specific purpose. Update clients shall verify that the key or keys that sign the Repository Metadata are keys authorized for that specific purpose.

*Guidance*

Signing software updates is a very sensitive role. As such, the software update system needs effective controls to ensure that the key used to sign repository metadata is the key intended for that role. This can be accomplished via specifying roles in root metadata as defined in Uptane/TUF (IEEE-ISTO 6100.1.00), or can be specified using a PKI system, for example via extended role attributes in an X.509 software signing certificate.

* Reference: TR-SCUD

* Objective: Ensure keys are only used for their designated roles and prevent role confusion attacks

* Preparation: Create Repository Metadata signed with a valid key that is intended for a different role

* Activities: Send the incorrectly-signed Repository Metadata to the device during an update check

* Verdict: Update check fails and error is reported => PASS, otherwise => FAIL

* Evidence: Error message, before and after comparison showing local metadata is not changed

#### 5.2.4.12 MI-SUSR: Signing keys have not been revoked or otherwise marked untrusted

The update client shall check for signing key revocation and any other security-relevant changes to the chain of trust, each time it checks for an update.

*Guidance*

If keys are compromised, it is critical that they are revoked as soon as possible, and that the revocation reaches each client of the update system. Therefore, the update system needs to check revocation information as part of the update check, and fail closed if revocation information is not available. Uptane/TUF checks would meet this requirement. If using X.509 CRLs, it is important to fail closed if the CRL cannot be fetched. OCSP stapling is possible here as well, but due care should be taken in designing the validity period of the OCSP response. An OCSP response with an extended validity period provides a long attack window in the case of compromised keys.

Some possible reasons (non-exhaustive) the information in a signature envelope could be discovered to be invalid or insufficient for attesting the validity of the signed content at time of update check:

- X.509 cert for one of the signing keys has expired

- X.509 cert  for one of the signing keys has been revoked by its issuing authority

- Authority that issued the X.509 cert for one of the signing keys has been revoked

- Signing key has been removed from the set of valid signing keys in TUF/Uptane root metadata

* Reference: TU-SCUD

* Objective: Ensure keys have not been revoked and are still valid, including their complete chain of trust

* Preparation: Create Repository Metadata signed with a formerly valid key that has been revoked

* Activities: Send the Repository Metadata signed with the revoked key to the device during an update check

* Verdict: Update check fails and error is reported => PASS, otherwise => FAIL

* Evidence: Error message, before and after comparison showing local metadata is not changed

#### 5.2.4.13 MI-SUMV: Reject update to current or previous version

The product shall reject Repository Metadata if its version number is equal to or less than the highest version number the update client has seen.

*Guidance*

Note that this requirement is about repository metadata. Repository metadata should never be permitted to roll back; it merely communicates the attested validity of a set of software. Software itself can often be permitted to roll back; see also the guidance on MI-XXXX (The product shall reject an update file that has been indicated to no longer be valid).

* Reference: TR-SCUD

* Objective: Prevent rollback attacks by rejecting older versions of Repository Metadata

* Preparation: Have the device perform an update check to obtain the latest Repository Metadata, then prepare an older version of Repository Metadata

* Activities: Send the older version of Repository Metadata to the device during another update check

* Verdict: Update check fails and error is reported => PASS, otherwise => FAIL

* Evidence: Error message, before and after comparison showing update metadata is not changed

#### 5.2.4.14 MI-SUED: Updates not applied from expired sources

Repository Metadata shall have an expiry date included in the signed portion of the metadata. The update client shall verify that repository metadata is not expired before using it.

* Reference: TR-SCUD

* Objective: Prevent use of expired metadata that could enable rollback attacks

* Preparation: Create expired Repository Metadata and configure the update server to provide it

* Activities: Have the device perform an update check with the expired metadata

* Verdict: Update check fails and error is reported => PASS, otherwise => FAIL

* Evidence: Error message, before and after comparison showing update metadata is not changed

### 5.2.5 **[TR-ROUT]** VPN traffic routed only through VPN connection during VPN connection

#### 5.2.5.1 Overview: TR-ROUT

|----------------------|------------------------|

|                      |                        |

## 5.3 Security profiles

Security profiles are an informative resource to the manufacturer to allow them to appropriately evaluate risks based on use cases. All VPNs will have a baseline of security requirements regardless of the use case and environment of their product. Additional security requirements will align with the reasonably foreseeable use (and, potentially, the reasonably foreseeable mis-use) of their particular product, based on the security profile appropriate for their product.