## 3 Background  
### Platform Security Architecture  
Platform Security Architecture (PSA) is a security framework developed by ARM that became an industry standard for embedded devices. PSA provides a set of guidelines and best practices for designing secure hardware and software environments. It includes features like secure boot, hardware isolation, TEE, and secure communication protocols to protect devices, data, and communications.  
**Secure boot** ensures that only authenticated software can run on the device, protecting it against unauthorized or tampered code during the boot process. The entire chain of trust is built on an RoT component, which is inherently trusted and executed after a system reset. It relies on hardware elements like eFuses, ROM, or protected flash memory, which are immutable once programmed. For example, the hash of the verification public key can be stored in one-time programmable eFuses. The boot sequence may involve multiple stages, where each firmware image is responsible for verifying the integrity of the next image in the chain before it is allowed to execute. The hash of the public key used to verify a specific image is stored in the preceding boot stage. Therefore, any attempt to compromise the chain of trust requires altering the RoT public key hash, which is central to the verification process.  
**Hardware isolation** utilizes CPU addressability isolation to protect specific registers and memory regions. ARM architectures incorporate the TrustZone security extension, which introduces the concept of secure and non-secure environments through a new CPU state bit. This allows or denies transactions initiated by the core based on the execution context and the security attributes of the target address. In addition, all secondaries connected to the bus are either TrustZone-aware or are protected by a security firewall. This new privilege level is independent of the original exception levels (EL 0-2) and operates orthogonally to them. Additionally, a Security Monitor at EL3 may be present in some architectures to manage the software transition between the two trust domains.  
**Trusted Execution Environment** is generally implemented using both hardware and software techniques. It creates an isolated execution context in which untrusted applications cannot access sensitive data or operations. This environment leverages hardware features such as secure memory regions, cryptographic keys, and secure boot mechanisms to ensure that code and data remain protected. The TEE ensures that even if the underlying system is compromised, the execution of sensitive code remains secure, providing integrity, confidentiality, and isolation for critical operations.  
**Attestation** serves as a critical mechanism for verifying a device's trustworthiness, offering essential insights to cloud service providers or peer nodes. It enables informed decisions on whether to trust a device and allow its interaction within a secure system. Built on EAT, attestation relies on signed claims to provide key information, such as a device's security configuration, software version, and identity. The flexible format of EAT tokens also allows for the inclusion of custom claims tailored to specific use cases, such as runtime integrity verification or compliance with regional regulations. By refreshing attestation tokens periodically, the process supports continuous monitoring, ensuring that devices remain secure and compliant over time.