feat(docs): update mboot threat model
Restructure Measured Boot threat model for more description and clarity:
- Add what critical assets are to be protected.
- Mention other attributes and the possible attacks.
- Rephrase the section that describes the Measured Boot backends.
Change-Id: I6577a56184992bf16f4aa1b773d1636781cbb049
Signed-off-by: Tamas Ban <tamas.ban@arm.com>
Signed-off-by: Abhi Singh <abhi.singh@arm.com>
diff --git a/docs/global_substitutions.txt b/docs/global_substitutions.txt
index 80012e7..67fd96a 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 c02e938..abacc9e 100644
--- a/docs/glossary.rst
+++ b/docs/glossary.rst
@@ -136,6 +136,9 @@
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 f8e4f7d..89419de 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 @@
.. 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).
-
- 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.
+ be no further assets to protect (like unsealed keys).
- 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: