| Info |
|---|
Available at: https://www.arm.com/architecture/security-features/platform-security |
| Table of Contents |
|---|
About this document
...
Security specifications enable the design and deployment of compliant devices that are compatible with the ecosystem requirements:
The Platform Security Model, this document, defines the top-level security concepts, identifies, and defines the Platform Root of Trust and generic Platform Root of Trust services
Technical specifications define the security requirements, outline solution architectures, and provide the necessary mitigations identified by threat modelling and security analysis. This includes generic material and references other standards that can be applied to any implementation
Reference architectures are any other applicable specifications that define, for example, hardware and software functional and robustness requirements, and standardized functional interfaces
Certification and compliance show that a deployed device is compliant and compatible with the ecosystem requirements:
Threat Models and Security Analyses (TMSA) identify use case-specific security threats and motivate use case-specific security functional requirements
Compliance testing, for example PSA Functional API Certification, deals with interfaces, functional behavior, and interoperability
Certification programs, for example PSA Certified, assess the implementation of the security functional requirements of a compliant device for vulnerability against the identified threats. The robustness that is required is based on use case, cost and security trade-off and the assessment scope. Certification schemes are an assessment and not a guarantee that a device is free from vulnerabilities
Design and manufacture: Secure-by-design devices should be designed and then manufactured based on security specifications with the aim of achieving robustness certification and functional compliance. Device manufacture includes the provisioning of root secrets and other sensitive information.
Deployment: Service providers manage and support deployed devices through:
Device management: Device manufacturers provide device manufacture data, provisioning, firmware update services, and other support functions. Device management considers devices throughout their lifetime, from factory provisioning through deployment, any re-deployment, in-field analysis, repair, to end-of-life. Data specific to the device management system must be defined by that system. The storage of such data may make use of the Platform Root of Trust services
Device verification: Devices are enrolled with a device verification system, including attestation verification. Depending on ecosystem requirements, device and attestation verification services are expected to be deployed by manufacturers, service providers, or by industry consortia
...
The overall trust anchor for the system. This ensures the platform is securely booted, configured, establishes the secure environments required to support the protection of security sensitive operations, and contains the root parameters. This is called the Platform Root of Trust (PRoT).
The secure environment for the PSM-defined generic security services, referred to as PRoT services. These services facilitate the PRoT and are intended to be used by application specific security services and functionality.
The secure environment for any Application Root of Trust (ARoT) services. An ARoT service can be any application defined security service, which may make use of the PRoT services. Note that some systems may need nothing more than the PRoT and PRoT services.
...
Together, the immutable PRoT Boot ROM and the PRoT Root Parameters form the inherently trusted anchor for the system.
Any compromise means that the anchor may no longer be trusted → Consequently, the PRoT and PRoT services may no longer be trusted → Any ARoT services may not be trusted → Trust in the entire device may be lost.
To minimize this risk, all access to the root parameters and the Boot ROM should be denied as soon as possible after they have fulfilled their purpose, which typically means at the point where control passes to the updateable PRoT. This is termed Temporal Isolation. All processing before a temporal isolation boundary must complete its task and handover to the stage after the boundary; the only way back requiring a reset leading to a system boot. This should be enforced in hardware.
...
The Boot ROM
Isolated locations
contain sensitive data stored in non-volatile memory
Access should only be by the PRoT or PRoT services
Shielded locations
are tamper-resistant isolated locations intended to hold provisioned secrets, including the PRoT root parameters
Tamper resistance may include mechanisms to make active probing difficult, i.e. physical disassembly for access to internal buses and interfaces, may include countermeasures against side-channel attacks, for example, power and timing analysis, or may include protection against power and clock glitching.
Isolation hardware
is the on-chip hardware that is necessary to implement the isolation requirements
Cryptographic on-chip hardware
Trusted subsystem
i.e. it may provide cryptographic operations, such as encryption, decryption, and signature generation, while denying all access to the key material used for the operation.
Lifecycle state management
represents any hardware used to indicate or control operations that are state dependent.
...
Usage, including allowing or denying the use of specific algorithms or modes to a specific key for encryption, decryption, derivation, signing and verification
Export: none, clear, wrapped or delegate. Delegation allows a secure partition to make a key that it owns available, with specified usage and export policies, to another specified secure partition or any non-PSM partition, for example, the Non-secure Processing Environment. The usage and export policies of a delegate key may be more restrictive than the source key, but the policies cannot be relaxed.
A source of random data is required, typically for establishing a secure communication channel. A True Random Number Generator (TRNG) or a suitably seeded Deterministic Random Bit Generator (DRBG) should be used to provide such random data.
...