...
EVE system has been built with security at the core of its design. One of its SECURITY principles is that, EVE should be trustworthy, and it should provide a deterministic way to measure its software layers, right from firmware, all through bootloader, kernel and user-space applications. It should also provide a mechanism to report these measurements to a third-party for attestation. This is to provide a verifiable software environment to launch user applications, i.e. the Edge Container Objects. The concept of measured boot is not new. For example, mobile phones use measured boot and attest to an attestation server, before initiating a payment transaction. Blockchain smart oracles at the cyber-physical edge, have to prove their software stack as trustworthy, before injecting events into smart contracts. This is a common requirement for distributed systems in general, but it becomes even more important for geographically remote systems like IoT Edge gateways, as there is no perimeter security for these Edge gateways. Since any software can be potentially modified, such measurement architectures typically use a hardware based root of trust (HRoT) or a Trusted Execution Environment(TEE). Here we present a solution based on Trusted Platform Module as the Hardware Root of Trust.
Measured Boot vs Secure Boot
Secure Boot is a security standard where each software layer in the booting sequence measures the next layer, and starts the next layer only if the signature of the software is verified by a certificate rooted to one of the known certificates embedded in the firmware by OEM. Software updates are done through uploading signatures and certificates of the new binary. Since each layer starts the next software layer only if the signature verification is successful, boot process is stopped when one of the stages fail the signature verification. For secure boot to work, all the software layers should be capable of measuring and verifying the next software layer.
Measured Boot, is another security standard, where the measurements are recorded into TPM PCRs but the boot process continues to complete. The measurements can be later read back from TPM and the Audit log of all the measurements can also be fetched. Thus measured boot does not make any judgement about the integrity of the boot stages, but gives opportunity for an external server to inspect the TPM Audit Log and PCR values in a detailed manner to see which components were measured, what their measurements are etc., and make a decision.
| Secure Boot | Measured Boot |
|---|---|
| Core Root of Trust is certificate embedded in Firmware by OEM | Core Root of Trust is Trusted Platform Module (TPM) |
| Does not require connectivity to any remote server to establish chain of trust. | Attestation server needs to inspect TPM PCR values before booting process can be trusted |
| Any new software needs to be signed by a certificate rooted to OEM certificates | An independent trusted third-party (an attestation server), can match the PCR measurements against its expected values |
| Chain of trust is implicitly established if system boots up fine | Chain of trust is established after going through TPM Event Log and PCR values |
| Good against protecting software that rarely changes e.g. firmware binaries, but incures significant administrative overhead for frequently changing binaries e.g. Linux kernel, new drivers etc, as one needs to prepare signed binaries with OEM rooted certificates, and can be an issue if update has to be rolled out to multiple OEM devices | Good against frequently modified binaries, as the new measurements can be uploaded to attestation server, which can be privately managed, and no need to go through OEM. |
| Device will become inaccessible if one of the software layers fail validation since booting process will halt. Good for devices with human presence like smartphones, laptops etc. But poses difficulty for remotely managed systems like IoT Edge gateways, where manual access to the device is limited. Since IoT gateways are managed through remotely located controllers, losing connectivity will severely impact visibility into the system. | Works well for remotely managed systems. Device will be accessible, and controller can still reach the system, and take any corrective action. |
As you can see, both the standards have their own merits and demerits when considering security requirements for a remotely managed EVE system. i.e.
- EVE needs the ability of Secure Boot to establish chain-of-trust without controller (so that EVE can continue to function even during intermittent Internet blackouts)
- At the same time, EVE needs the ability of Measured Boot, where the boot process is completed, and not halted in between (To provide visibility to the EVC)
Therefore, one needs to look at how we can meet these two seemingly conflicting goals. In the following sections, we present a solution mostly based on the principles of measured boot, but also considering the offline operational requirement of EVE. In the end, we also present a hybrid model, where we can add some features from Secure Boot, to provide more security against firmware Rootkits.
In the following sections, we first present the key capabilities of TPM, and then describe how these capabilities can be used in EVE system to arrive at the solution.
Trusted Platform Module as the Silicon RoT
...
Fig 1. Role of EVC as the Remote Attestation Server
...
Software Layers in EVE Booting Process
...