...
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.
...
TPM can be asked to perform a “PCR Extend” command, where a particular hash value would be added to the existing hash value in a Platform Configuration Register(PCR), and the resultant hash value can be stored back in the same PCR. i.e.
PCR_ContentNew = Extend (PCR_Content || NewCurrent, New_Measurement)
One can only extend the current value in the PCR with a new hash value, and the existing contents can not be overwritten. This provides us these key capabilities:
...
Fig 1. Role of EVC as the Remote Attestation Server
Software Layers in EVE Booting Process
Introduction to
...
Foundational Concepts
- A new device state, “Unknown Update Detected” (Abbreviated as UUD) will be introduced in EVC, to notify that measurements of software running on a given device didn't match expected measurements.
- EVC maintains a central database of all the supported EVE software images, and their hash values, indexed with the EVE image version tag
- EVC also maintains a central database of mostly used BIOS firmware images, their signatures, and the certificate provided by the BIOS vendor for validating the signatures, indexed by a combined tag of BIOS version string + Manufacturer
- On receiving attestation request EVE, attestation service module checks PCR Quote against the baseline value. If there is a change, the EVE node is marked as “UUD”. When there is no software change, the PCR quote is expected to be the same across reboots. However, after an EVE software upgrade, it is expected that the baseline value will change for the PCR values. However, after comparing the reported values with the expected values(since EVC knows about the new image version and its hash values), EVC makes a decision: If the reported values match, the baseline for the EVE node is updated. If they don’t, EVE node is marked as UUD.
- An optional feature, "Location-Lock" may be introduced in EVC, to additionally check the Geo-Location reported by device, and flag if the location has changed since its last-seen location. This feature may be critical in some deployments, where a given EVE node may be mounted permanently, and any change in its physical location should be flagged, and optionally considered along with software measurements to conclude if the EVE node is trusted. In this regard, another new device flag, “Unknown Movement Detected” (Abbreviated as UMD) will be introduced in EVC, to indicate that a change in the location of the device has been detected.
- If EVE node is not in “UUD" or "UMD" state, EVC includes all the latest configuration in reply to config request from EVE.
- If edge-node is in “UUD” or "UMD" state, any config request from EVE will be responded with response code 403 - Forbidden. This is to protect any new sensitive images/credentials from getting exposed to the compromised device. The response from EVC in such cases will carry an error code to indicate that there was an attestation failure, and hence partial configuration is being sent. EVE, upon receiving such error codes MUST schedule re-attestation immediately.
- If EVE reboots with a different software image from the configured version, EVC should be able to detect as quickly as possible and force attestation. To this effect a new token is introduced, called "Integrity Token". This token is a random nonce that will be stored in EVE under an encrypted folder. The master-key to decrypt this folder will be sealed against the TPM PCRs. Therefore, if EVE reboots with a different software, unsealing of this key will fail, and hence the new software will not be able to recover the Integrity Token inside it. This token is sent during attestation requests, and if the attestation is successful, the provided token value is sealed against PCR values. This is usually implemented by storing the token inside an encrypted folder, with the master-key protected by TPM with Seal operation.
- Every configuration request from EVE will include this Integrity Token. If there is a token mismatch, HTTP code 403 - Forbidden will be sent to the device as the response, indicating that device should do re-attestation.
- Frequency of attestation: EVE node will be required to periodically attest itself via attestation requests. It is up to the EVC to schedule the frequency of attestation. Whenever EVC replies with Error 403, EVE MUST re-attest. EVC can trigger this either periodically (say every few hours) or when it sees any discrepancy in the Integrity-Token.
...
Fig 4. Firmware Upgrade Management
Handling non-TPM devices
Optional Hybrid Model - Secure Boot & Measured Boot
...