Building secure IT systems is a complex and challenging task, as several properties must be achieved for a system to be fully secure. A fundamental property that must be guaranteed is the integrity of the system, i.e. ensuring that no unauthorized entity can control the system’s behavior. Typically, this means ensuring that the software, which is the mutable part that defines a system’s behavior, has not been modified. This goal can be achieved in a number of ways. This article introduces and explains a security service called “Secure Boot”, which is one of the security service Sanctuary provides. It ensures that software loaded during system boot has not been tampered with, e.g. by a rootkit or another advanced persistent threat (APT).
Secure boot incrementally checks the integrity of a system’s software components (e.g., boot loader, operating system, and applications) during startup. Before a software component is executed, its integrity is checked. The verification process is started from the initial component E0 of the platform’s boot process (e.g. UEFI code) and continued iteratively for all components E1 … En that are executed, until the last component En+1 is verified and executed (see Figure 1).
Since the integrity of each component Ei is checked by its predecessor Ei-1 before it is executed, only known (i.e. authentic) software components are loaded and executed. If the integrity of a software component cannot be verified successfully, different reactions are possible. For example, the system can stop execution (also called “fail secure mode”) or it can use an authentic fallback version of the software component whose integrity check failed. The integrity check of a component, however, is only meaningful if the component performing the check itself is correct, and thus, performs the check correctly. This implies that the initial component E0 must be trusted and is often referred to as Root of Trust (RoT). This means that the integrity of E0 must be assumed without being explicitly checked. Hence, it must be protected against (software) attacks. A common method to ensure the integrity of the RoT is to store the code and data of E0 in Read-only Memory (ROM), this way it cannot be changed after the initial production of the system. Starting from the RoT, the integrity of all other components E1 … En is ensured by verifying the integrity of each component Ei by its predecessor Ei-1 before Ei is executed.
Which method is used to verify the integrity of a component depends on the requirements of an application. The most common approach for secure boot is to calculate an integrity measurement value (IMV), which is typically the cryptographic hash digest of the binary code of the software component being verified. The IMV is then compared to a reference IMV, typically certified by the platform manufacturer, platform user, or software vendor. If the IMV calculated by the secure boot mechanism matches the certified reference IMV, the integrity of the software component is confirmed.
Order of Integriy Check
As previously explained, it is important to ensure that the integrity of each software component is verified prior to its execution. Apart from this basic rule, there are no other restrictions on the order of integrity checking and the execution of software components. This means that the integrity of software component En can be verified by any software component E0 … En-1 executing before En is executed.
Figure 2 illustrates such a scenario where the integrity of the software components E1, E2 and E3 are checked by the software component E0 (step 1, 2 and 3 in Figure 2) before E1 , E2 or E3 is executed (steps 4, 6 and 7 in Figure 2). Similarly, E1 verifies E4 (step 5 in Figure 2), although E1 is not loaded immediately before E4. However, in this example, the integrity of each software component is checked before it is loaded.
Reference Integrity Measurement Values
The integrity and authenticity of the reference readings must be guaranteed. Depending on the flexibility requirements of the secure boot mechanism, different approaches for storing and managing reference integrity measurement values (IMVs) are possible.
Reference IMVs Embedded in Software Components
One approach to managing the reference IMVs is to embed the reference IMV of the software component Ei in its predecessor component Ei-1, which is responsible for performing the verification of Ei, see Figure 3. The first component E0 contains the reference IMV of E1 denoted as M(E1), i.e. the expected integrity measurement value of E1. The integrity of M(E1) is protected by the same mechanism that protects the integrity of E0. The integrity of the software component E1‘ itself is checked by E0 before E1‘ is executed. More precisely, E0 calculates the hash value of the binary code of E1‘, denoted as M(E1‘) (step 1 in Figure 3), and compares the result with the reference IMV M(E1 ) (Step 2 in Figure 3). The integrity check of E1‘ succeeds only if M(E1‘) matches M(E1). If this is the case, E1‘ is executed (step 3 in Figure 3) and takes over the role of E0, i.e. E1‘ measures the binary code of E2‘ and only then executes E2‘ if its measurement M(E2‘) matches the reference IMV M(E2) of the software component E2, which is stored in E1‘. This process continues until the integrity of all software components has been verified.
A central limitation of this approach is its lack of flexibility. In particular, updating software component
Reference IMVs Managed in Central Database
A more flexible approach than the embedding approach described above is to manage reference IMVs in a central database, as shown in Figure 4. Before the initial component E0 passes execution to the next component E1‘, it checks the integrity of E1‘. Like before, E0 measures the binary code of E1‘ and compares the result M(E1‘) with the reference IMV M(E1) of E1. This time, however, the reference IMV is stored in a central database that can be read by all software components performing an integrity check. To ensure the authenticity and integrity of the stored IMVs, the integrity of the database must be protected. One way to protect the integrity of the database is to use the same method used to protect the integrity of initial component E0, or use E0 to verify the integrity of the database.
This method enables flexible updating of individual software components. However, updating software components requires an authentic update of the corresponding reference IMV in the database.
IMV Certificates
The most practical approach to implementing secure boot is to use digital signatures (certificates) to ensure the integrity and authenticity of the reference integrity measurement values (IMVs). This approach is depicted in Figure 5. The reference IMV of each software component is provided in a digital certificate issued by a trusted certification authority, which can be for instance the platform manufacturer, the platform user and/or a software provider. The certificate does not have to be kept in protected memory, as its authenticity and integrity is ensured by the digital signature σpk it contains. Before the initial component E0 passes execution to E1‘, it checks the integrity of E1‘. Again, E0 measures the binary code of E1‘ and compares M(E1‘) with the reference IMV M(E1) of E1 contained in the certificate. The authenticity of the reference IMV itself is checked by verifying the certificate with the signing authority’s authentic public verification key pk.
When updating a component En, a new certificate for the version of En must be issued and stored on the platform. Because the certificate can be validated with the same pk public verification key, neither the E0 entity nor the protected store containing pk need to be updated. Because E0 and pk should not require updating during the lifetime of the platform, a simple hardware-based protection like read-only memory (ROM) can be used to protect their integrity and authenticity.
Revocation
In secure boot systems, a revocation may be required because either an entity
In the first case, the reference IMV M(Ei) must be removed and replaced with an updated IMV M(Ei*). Depending on the Secure Boot variant used, this may require updating the predecessor components of Ei with an updated embedded IMV M(Ei*), updating the central IMV database, or issuing a new certificate for M(Ei*). For all variants, the authenticity of the updates must be guaranteed.
In the second case, the secure boot system must learn that the compromised key can no longer guarantee the integrity of an entity
In all cases, the revocation information must be made available to the secure boot system. If a device is not compromised, it can retrieve the updated information over the network, e.g. in the form of a certificate revocation list (CRL) to revoke certificates. A device under the control of an attacker, e.g. a device on which the attacker has exploited a vulnerability in an entity Ei, will not voluntarily update the revocation information. In these cases, the update must be forced, e.g. for example, certificates may be issued with an expiration date that requires an update after the certificate’s validity period has expired. However, these solutions require that the secure boot system can receive updated information, for example over the network. This approach also requires devices to securely store the latest revocation information or maintain the version information with a secure monotonic counter to prevent attacks such as rollback attacks. To ensure the revocation information is up-to-date, the devices need access to reliable time information.
