OC5 71: fix typo

* 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

* 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

* Objective: Secure updates

* Preparation: Create updates with signature signed by an untrusted key

* Activities: For each part of the product that can be updated, attempt installation of an update signed by an untrusted key

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

* 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

* 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

* 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

> NOTE: Multiple different versions of software that are _simultaneously_ endorsed/trusted for installation do not constitute a "rollback attack". This mitigation specifically applies to the scenario where 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.

* 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

* 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

* 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

* 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

* 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

* 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

* 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

* 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

* Objective: Data minimization

* Preparation: Follow the instructions to use the product and start a VPN connection, selecting the options that require the least Personal Data, recording all data entered

* Activities: Examine the data entered looking for Personal Data. Review the manufacturer's provided justification for the necessity of this data in relation to providing the service, processing payment or managing the subscription.

* Verdict: If there is any excessive Personal Data recorded or Personal Data recorded without a justified, documented operational reason essential for the delivery of the service or payment processing=> FAIL, otherwise => PASS

* Verdict: If there is any excessive Personal Data recorded or Personal Data recorded without a justified, documented operational reason essential for the delivery of the service or payment processing => FAIL, otherwise PASS

* Evidence: The record of data entered with a short description indicating whether the particular data element alone or in combination with other data elements allows for singling out the individual in accordance with the definition of personal data under the applicable law. Where this is the case, the reason why the data element is required should also be documented.

#### 5.2.12.5 MI-NPER-4: No Personal Data stored on remote data processing systems

* Objective: Confidentiality

* Preparation: Attach a debugger to the VPN client binding to cryptographic functions or capture traffic on all interfaces

* Activities: Create protocol trace when setting up a post-quantum safe tunnel or capture packet showing the encryption headers

* Verdict: Protocol trace or packet capture demonstrating that the PSK is incorporated into key derivation during tunnel establishment => PASS, otherwise => FAIL

* Verdict: Protocol trace or packet capture demonstrating that the PSK is incorporated into key derivation during tunnel establishment => PASS, otherwise FAIL

* Evidence: The protocol trace or packet capture demonstrating the mixing a preshared key into the key derivation process

#### 5.2.14.3 MI-CRYPT-2: Use conformant encryption

* Objective: Data minimization and Confidentiality of data.

* Preparation: Gather the technical documentation detailing the logging architecture of the remote data processing solutions, and obtain administrative access to a test instance of the VPN server configured identically to the production environment

* Activities: Examine the server and routing software configuration files to verify that the logging of connection metadata and Personal Data is disabled or discarded, start a VPN connection from a client and generate network traffic, and inspect the remote server's persistent storage for the client's source IP, destination IPs, or plaintext connection information.

* Verdict: If the server configuration permits the persistent storage of user network traffic data, or if any Personal Data or connection metadata is found persistently stored on the remote data processing system after generating traffic => FAIL, otherwise => PASS.

* Verdict: If the server configuration permits the persistent storage of user network traffic data, or if any Personal Data or connection metadata is found persistently stored on the remote data processing system after generating traffic => FAIL, otherwise PASS.

* Evidence: Copies of the relevant server configuration files demonstrating that logging is disabled, a description of the test traffic generated, and the output of the server storage/log inspection confirming the absence of the specified data.

#### 5.2.15.5 MI LOGG 3: No data persistence or storage enabled on exit nodes

    1. Examine the server's operating system configuration (e.g., filesystem table/fstab, boot parameters) to verify that all system directories (including /var/log and temporary storage) are mounted exclusively on volatile memory (RAM disks).

    2. Verify that unencrypted non-volatile swap partitions are disabled.    

    3. Generate network traffic through the test node, then power cycle (reboot) the server and inspect the storage.

* Verdict: If the server utilizes non-volatile disk-based storage for system logs, swap, or temporary processing, or if any data persists across a power cycle => FAIL, otherwise => PASS.

* Verdict: If the server utilizes non-volatile disk-based storage for system logs, swap, or temporary processing, or if any data persists across a power cycle => FAIL, otherwise PASS.

* Evidence: Copies of the relevant server configuration files demonstrating the use of RAM disks, and the output of the storage inspection after the power cycle.

> NOTE: "Minimization of data compromise due to equipment compromise" is a completely NEW OBJECTIVE

* Objective: Secure deletion

* Preparation: Document every type of stored data or setting that may be changed by the user on the product, how to store it on the product, and how to read it from the product

* Activities: For each type of user data or setting that may be stored and changed by the user on the product, write an instance of the data or setting stored on the product that is different from the default and read it from the product; once all types of data have been written and read, power cycle or reset the product, and read each type of data again

* Verdict: If any data or setting is the same for both of the reads => FAIL, otherwise => PASS

* Verdict: If any data or setting is the same for both of the reads => FAIL, otherwise PASS

* Evidence: Record of each type of data or setting, what data or setting was written, what data or setting was returned by the first read, and what data or setting was returned by the second read, comparison of each one

#### 5.2.16.3 MI-INST: Secure deletion via reinstallation

* Objective: Secure deletion

* Preparation: Document every type of data or setting that may be stored and changed by the user on the product, how to store it on the product, and how to read it from the product

* Activities: For each type of user data or setting that may be stored and changed by the user on the product, write an instance of the data or setting stored on the product that is different from the default and read it from the product; once a breadth of data points have been written and read, reinstall the product with the secure delete option, and read the data or settings again

* Verdict: If any data or setting is the same for both of the reads => FAIL, otherwise => PASS

* Verdict: If any data or setting is the same for both of the reads => FAIL, otherwise PASS

* Evidence: Record of each type of data or setting, what data or setting was written, what data or setting was returned by the first read, and what data or setting was returned by the second read, comparison of each one

#### 5.2.16.4 MI-DELE: Secure deletion via secure deletion function

* Objective: Secure deletion

* Preparation: Document every type of data or setting that may be stored and changed by the user on the product, how to store it on the product, and how to read it from the product

* Activities: For each type of user data or setting that may be stored and changed by the user on the product, write an instance of the data or setting stored on the product that is different from the default and read it from the product; once all types of data have been written and read, activate the secure deletion function, and read the data or settings again

* Verdict: If any data or setting is the same for both of the reads => FAIL, otherwise => PASS

* Verdict: If any data or setting is the same for both of the reads => FAIL, otherwise PASS

* Evidence: Record of each type of data or setting, what data or setting was written, what data or setting was returned by the first read, and what data or setting was returned by the second read, comparison of each one

### 5.2.17 TR-SDTR: Secure data read and transfer

* Objective: Confidentiality of data

* Preparation: List all types of data that may be stored on the product that should not be readable without authorization, what methods of ensuring confidentiality are appropriate for each type, all methods of accessing that data available to an attacker based on the risk assessment, and what the allowable authorization methods are for that access method

* Activities: For each type of data and each access mechanism, determine the method of ensuring confidentiality used, and attempt to read the data without authorization

* Verdict: If all methods of ensuring confidentiality match the type of the data stored, and all the attempts to read confidential data without authorization fail => PASS, otherwise => FAIL

* Verdict: If all methods of ensuring confidentiality match the type of the data stored, and all the attempts to read confidential data without authorization fail => PASS, otherwise FAIL

* Evidence: Logs of determination of type of data and method of confidentiality and attempts to read confidential data without authorization

> NOTE: Data may be protected by the environment, permissions, encryption, salting and hashing, offline storage, or hardware-backed secrets.