Security

Assumptions and Delegated Mitigations

ID	01
Assumption	Physical attack is out of scope.
Delegated Mitigation	None. None.
Impact if assumption is wrong	Unhandled vulnerabilities.

ID	02
Assumption	Part of NOR flash access restriction is controlled by end platform providers.
Delegated Mitigation	The current hardware and software implementations lack protection to NOR Flash. The vendor should add protection before NOR Flash and program the access restrictions similar to the Memory Side Filter (MSF).
Impact if assumption is wrong	Secure keys/FIP image can be overwritten.

ID	03
Assumption	Part of DDR region access restriction is controlled by end platform providers.
Delegated Mitigation	The current hardware and software implementations lack protection to DDR. The vendor should add protection before DDR and program the access restrictions similar to the Memory Side Filter (MSF).
Impact if the assumption is wrong	Can be overwritten by Malicious software.

ID	04
Assumption	The firmware update capsule is generated from a working set of firmware image blobs (TF-A BL2, SCP BL2, etc.) and not tampered in DDR. (The Firmware Update Capsule contains the FIP image and additional FWU specific headers. On the TC SW stack reference design, the update capsule is preloaded manually to the DDR before execution.)
Delegated Mitigation	None.
Impact if the assumption is wrong	Boot hangs.

ID	05
Assumption	Not using the dummy key provided with the TC software stack for the platform secure boot.
Delegated Mitigation	The vendor should follow RSE guidelines to create custom keys and securely store them.
Impact if the assumption is wrong	The keys are exposed and the secure boot is compromised.

ID	06
Assumption	Securely handle debug and trace for production releases.
Delegated Mitigation	The vendor should disable the debug and trace capability for production releases or enable proper debug authentication as recommended by DEN0034.
Impact if the assumption is wrong	Secure data can be exposed. Arbitrary code can be executed.