# Prevention of Controller Area Network (CAN) Attacks on Electric Autonomous Vehicles
## 4 Secure Boot Process
The initial boot stage of a chain of trust is called the root of trust (RoT), which is assumed to be authentic and trusted because its integrity is not validated in the secure boot process. Therefore, the RoT should be protected through hardware mechanisms such as making the RoT one-time programmable (OTP) or deploying the RoT to secure hardware modules such as HSMs and TPMs. As shown in Figure 5, the RoT is used to validate the succeeding stages and it is inherently trusted. Therefore, an attack on the RoT can compromise the whole boot process [30]. The three components of the RoT are called the root of trust for measurement, the root of trust for storage, and the root of trust for reporting. Figure 4: The three components of a secure boot stage. Figure 5: Flowchart of the secure boot’s chain of trust. algorithm to calculate the message image instead of the standard hash-based functions that are used in the traditional ECDSA algorithm. Although it is not recommended to execute software sections that have not been validated, some secure boot strategies choose not to secure boot low-priority software sections. These strategies opt to restrict the authority and accessibility of these sections instead of validating them to speed up the secure boot process. Executing unauthenticated software sections should be investigated carefully to ensure that attacks on these sections will not compromise the vehicle's security. Furthermore, the CAN bus should only be accessed by authentic software sections to prevent malicious access to the bus, which can jeopardize the full network. The execution mode of the secure boot process determines the different secure boot stages and identifies whether these boot stages are validated sequentially, in parallel, or in a combination of sequential validation and parallel validation. The sequential execution mode is when a boot stage is only allowed to execute after it has been validated and trusted, while the parallel execution mode is when a boot stage could be executed before its validation has been completed. In parallel execution, a boot stage is released and then it is validated parallel to its execution. A boot stage executing in a parallel mode should be restricted so that it is not able to interfere with its validation process. The advantage of the sequential mode over the parallel mode is that it offers a higher security level [33] because software sections are not allowed to execute prior to their validation. But in some cases, to meet the timing requirements, the parallel mode is selected to speed up the secure boot process. Countermeasures are the mitigation actions applied by the secure boot process when the validation of a boot stage fails. Countermeasures may consist of one or more of the following: (1) bricking the ECU by not allowing it to execute further code; (2) performing a safe fallback procedure for critical ECUs and then bricking the ECU; (3) restricting the accessibility and authority of the unauthentic software section, which can include blocking access of the unauthentic software section to the CAN bus; (4) blocking the execution of the unauthentic software section; (5) locking the cryptographic secrets and preventing these secrets from being read or modified; and (6) sending a notification indicating that one or more software sections have failed validation. Although the usage of secure boot processes in automotive ECUs is not excessively reviewed in the literature, various research papers have addressed the subject. Ref. [32] implemented a secure boot process of an engine management system using a combination of sequential secure boot and parallel secure boot and using a CMAC as the validation algorithm. The secure boot process was executed via the HSM module of the Infineon TC27x 32-bit AURIX(tm) TriCore(tm) microcontroller. In [34], a secure boot process was implemented on a trusted platform module using an HMAC validation scheme.