| Info |
|---|
Available at: https://www.arm.com/architecture/security-features/platform-security |
...
Goal 1: Devices are uniquely identifiable.
Goal 2: Devices support a security lifecycle.
Each security state defines the security properties of the device.
Goal 3: Devices are securely attestable.
The trustworthiness of a device must be established.
Goal 4: Devices ensure that only authorized software can be executed.
Allowing unauthorized software is acceptable only if such software cannot compromise the security of the device.
Goal 5: Devices support secure update.
Goal 6: Devices prevent unauthorized rollback of updates.
Goal 7: Devices support isolation.
Isolation boundaries aim to prevent one service from compromising other services.
Goal 8: Devices support interaction over isolation boundaries.
This will require validation of exchanged data.
It may also be necessary to ensure the confidentiality and integrity of any data exchanged.
Goal 9: Devices support unique binding of sensitive data to a device.
It may also be necessary to bind the data to the security state (i.e. `to to deny access during debug).
Goal 10: Devices support a minimal set of trusted services and cryptographic operations that are necessary for the device to support the other goals.
...
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.
...
A partition is defined as some processing with a defined logical boundary. Partitions are managed by a partition management function, and may be nested within other partitions.
A partition manager is used to allocate resources to the partitions that it manages.
A processing environment hosts partitions, including any partition manager, and attributes the partitions with specific security properties. Processing environments can be necessary to mitigate specific threats and attacks, or to comply with different certification schemes and assurance levels.
...
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.
...
All images should be signed using asymmetric cryptography and must be verified before use. Each signature must cover at least the image content.
Asymmetric cryptography during boot can be too time-consuming for some applications. Securely storing the computed cryptographic hash value of the images verified during an initial secure boot asymmetric check allows the stored value to be used to reduce the time on subsequent checks. Using a saved hash value in this way is called Hash Locking.
For the hash to be secure, the stored value must be accessible only by the Boot ROM.
To prevent the execution of a different image, the stored hash value should be integrity protected.
To prevent the use of an old image, the integrity-protected stored hash should also be replay protected.
To support update, the stored hash value must be updateable.
The private counterpart of the on-device Boot Validation Key, must be held securely by the operator or device manufacturer, and should never be stored on the device. This applies also to the private counterparts of any other on-device keys that are used in the validation of the boot chain.
Symmetric signing is not recommended.
Boot images should be encrypted if they contain sensitive data or code. It is normal for the image to be signed then encrypted, thus the device decrypts the image before verification and validation. However, if the content is considered confidential and should not be visible to the signing entity then encryption followed by signing is necessary.
...
The cryptographic operations service performs cryptographic processing using input, derived, or persistent keys that are stored in isolated locations or shielded locations. Implementations should meet the following essential security properties:
Isolation
Access controcontrol
Policy
The minimum set of cryptographic policy options is as follows:
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.
...
A typical initial attestation sequence is illustrated and explained in the remaining of this subsection.
...
OR: object record
Secure Storage
Many devices require secure persistent storage to hold sensitive data. That data could come from the manufacturer, or could be application-generated, service-generated, or user-generated. Such storage is called non-isolated storage, and is typically implemented with flash memory either on- or off-chip.
...
PSM: Platform Security Model
PRoT: Platform Root of Trust
SPE: Secure Processing Environment
NSPE: Non-Secure Processing Environment
API: Application programming interface
ABI: Application binary interface
BRK: Binding Root Key
SBRK: Secure BRK
DBRK: Debug BRK
PSBK: Partition Specific Binding Key
...