diff --git a/docs/global_substitutions.txt b/docs/global_substitutions.txt index 80012e7b8..67fd96a4d 100644 --- a/docs/global_substitutions.txt +++ b/docs/global_substitutions.txt @@ -31,6 +31,7 @@ .. |OEN| replace:: :term:`OEN` .. |OP-TEE| replace:: :term:`OP-TEE` .. |OTE| replace:: :term:`OTE` +.. |PCR| replace:: :term:`PCR` .. |PDD| replace:: :term:`PDD` .. |PAUTH| replace:: :term:`PAUTH` .. |PMF| replace:: :term:`PMF` @@ -55,6 +56,7 @@ .. |SVE| replace:: :term:`SVE` .. |TBB| replace:: :term:`TBB` .. |TBBR| replace:: :term:`TBBR` +.. |TCB| replace:: :term:`TCB` .. |TCG| replace:: :term:`TCG` .. |TEE| replace:: :term:`TEE` .. |TF-A| replace:: :term:`TF-A` diff --git a/docs/glossary.rst b/docs/glossary.rst index c02e93808..abacc9e46 100644 --- a/docs/glossary.rst +++ b/docs/glossary.rst @@ -136,6 +136,9 @@ You can find additional definitions in the `Arm Glossary`_. OTE Open-source Trusted Execution Environment + PCR + Platform Configuration Register + PDD Platform Design Document diff --git a/docs/threat_model/firmware_threat_model/threat_model.rst b/docs/threat_model/firmware_threat_model/threat_model.rst index f8e4f7d14..89419dea2 100644 --- a/docs/threat_model/firmware_threat_model/threat_model.rst +++ b/docs/threat_model/firmware_threat_model/threat_model.rst @@ -892,28 +892,56 @@ nonetheless once execution has reached the runtime EL3 firmware. .. topic:: Measured Boot Threats (or lack of) - In the current Measured Boot design, BL1, BL2, and BL31, as well as the - secure world components, form the |SRTM|. Measurement data is currently - considered an asset to be protected against attack, and this is achieved - by storing them in the Secure Memory. - Beyond the measurements stored inside the TCG-compliant Event Log buffer, - there are no other assets to protect or threats to defend against that - could compromise |TF-A| execution environment's security. + In the current Measured Boot design the following components form the |TCB|: + + - BL1, BL2, BL31 + - Secure world components + - RMM (if RME extension is implemented) + - The configuration data of the above components + + Across various Measured Boot backends, the data recorded during the flow as + well as the criticality of this data can vary. In most cases, these attributes + are considered valuable assets and are protected against potential attacks: + + - Image measurement: the digest value of a component produced by a hash + function. + - Signer-id: the digest value of the image verification publiy key. The + verification public key is part of the image metadata. + + In addition to these, other metadata attributes (image version, hash algorithm + identifier, etc) could be recorded during the Measured Boot process. But these + are not critical data. + + In this context, an attack means modifying the measurement data (image or + public key hash) or recording arbitrary data as valid measurements. + + The current Measured Boot design consists of two main parts. A frontend, which + is responsible for taking the measurements, and a backend which is responsible + for storing them. |TF-A| makes it possible to integrate various backends. Some + of these are implemented by the |TF-A| projects, while others are part of + different projects, and |TF-A| provides an integration layer. + + - TCG-compliant Event Log: Implemented by |TF-A|. Measurements are stored in + the Event Log which is located on the secure on-chip memory of the AP. The + address of the Event Log buffer is handed off between boot stages and new + measurements are appended to the Event Log. A limitation of the current + Measured Boot implementation in |TF-A| is that it does not extend the + measurements into a |PCR| of a Discrete |TPM|, where measurements would + be securely stored and protected against tampering. + + Beyond the measurements (image digest and signer-id) there are no other assets + to protect or threats to defend against that could compromise |TF-A| execution + environment's security. There are general security assets and threats associated with remote/delegated attestation. However, these are outside the |TF-A| security boundary and should be dealt with by the appropriate agent in the platform/system. Since current Measured Boot design does not use local attestation, there would - be no further assets to protect(like unsealed keys). + be no further assets to protect (like unsealed keys). - A limitation of the current Measured Boot design is that it is dependent upon - Secure Boot as implementation of Measured Boot does not extend measurements - into a discrete |TPM|, where they would be securely stored and protected - against tampering. This implies that if Secure-Boot is compromised, Measured - Boot may also be compromised. - - Platforms must carefully evaluate the security of the default implementation - since the |SRTM| includes all secure world components. + System integrators must carefully evaluate the security requirement and + capabilities of their platform and choose an appropriate Measured Boot + solution. .. _Runtime Firmware Threats: