About this document
This document is one of a set of resources provided by Arm that can help organizations develop products that meet the security requirements of PSA Certified on Arm-based platforms.
This document underlies the PSA Certified™ framework and certification scheme.
Key goals for designing devices based on essential security properties are described in this security model. These essential properties are used to define a Platform Root of Trust for a platform on which end-products can be built.
This Platform Root of Trust (PRoT) covers the set of hardware and firmware necessary to support non-secure and secure processing.
Platform Security Model Overview
This Platform Security Model (PSM) is one document in a holistic set that includes:
threat models and security analyses,
security requirement specifications and application programming interfaces,
all architecture-agnostic.
This security model is the top-level document for the other platform security specifications and defines a common language, high-level robustness rules, and models.
Products may go through a security evaluation, such as PSA Certified, to provide a measure of the robustness of the implementation.
The 10 Security Goals
Abstraction allows these goals to be applied as required, for example, to an end user connected device, a hardware component, a software component, or a service.
The term device is used to represent any entity at any level that must be secure and trustworthy. |
Goal 1: Devices are uniquely identifiable.
Goal 2: Devices support a security lifecycle.
Goal 3: Devices are securely attestable.
Goal 4: Devices ensure that only authorized software can be executed.
Goal 5: Devices support secure update.
Goal 6: Devices prevent unauthorized rollback of updates.
Goal 7: Devices support isolation.
Goal 8: Devices support interaction over isolation boundaries.
Goal 9: Devices support unique binding of sensitive data to a device.
Goal 10: Devices support a minimal set of trusted services and cryptographic operations that are necessary for the device to support the other goals.
Connected Devices Within an Ecosystem
The devices deployed within the context of an ecosystem are expected to comply with a variety of functional and security requirements, depending on the use cases of the deployment ecosystem.
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
Device Models
The device models defined by PSM covers three fundamental parts:
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.
There are many ways to build a PSM compliant device. For this reason, the following generalized concepts are used.
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.
A minimal PSM compliant device is illustrated in the Figure above. There are two processing environments.
Secure Processing Environment (SPE), hosts secure partitions, for PSM-defined security processing.
Non-Secure Processing Environment (NSPE), hosts partitions for all other processing.
The SPE hosts the following PSM elements:
The Platform Root of Trust, comprises:
The Immutable Platform Root of Trust, which is inherently trusted. This largely refers to the hardware, including any firmware that cannot be updated on a production device.
The Updateable Platform Root of Trust, such as firmware and configuration that is trusted by verification through a chain of trust tied to the trust anchor and can be updated on a production device. This largely refers to software, but may include configurable hardware that can be changed.
The Platform Root of Trust Services, which includes the secure storage, cryptographic, and attestation services. Typically, these are part of the updateable Platform Root of Trust.
Any Application Root of Trust (ARoT) service(s), which are not covered in this document. They are expected to use interfaces provided by the PRoT services but must have no direct access to the immutable PRoT. Typically, ARoT services are updateable.
noteA secure partition must only host the PRoT, the PRoT services, or any ARoT services. All other processing must be completely outside any secure partition and secure processing environment.
A secure partition must only host the PRoT, the PRoT services, or any ARoT services. All other processing must be completely outside any secure partition and secure processing environment.
PSM allows for systems where there is the need for more than one secure processing environment (SPE).
Provided the PSM security requirements are not violated, non-PSM security processing environments can co-exist. As the trust anchor for the device, the PRoT may need to include functionality specific to any non-PSM security service, and the PRoT SPE will need to meet any specific non-PSM processing environment security properties.
Isolation
Isolation ensures that processing in one partition cannot compromise any code, run-time state including hardware, and secrets, of any other partition either directly or via misuse of software-controlled hardware elements.
PSM requires each secure processing environment (SPE) to be means from all other processing environments.
Isolation between partitions is not defined by PSM but will depend upon the security requirements and any applicable certification scheme.
It is recommended that all processing, especially software, is designed assuming that the isolation boundaries are enforced.
Isolation of partitions is handled by a partition management function. This function may be fulfilled, for example, by an Operating System, which may, itself, be a partition isolated from other virtual machines by a hypervisor that also fulfils a partition management function.
Each outer most partition manager is hosted in a single processing environment. Note that a nested secure partition can only be nested within another secure partition, and hosted in a secure processing environment.
Immutable Platform Root-of-Trust Protection
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.
Trusted Subsystems
A trusted subsystem is any configurable or updateable security functionality, possibly containing a processor capable of code execution, that the PRoT or PRoT services rely on for correct operation. Examples include on-chip security co-processors, and off-chip secure elements, Trusted Processing Modules or Subscriber Identity Modules.
A trusted subsystem may have its own root of trust and its own security lifecycle. However, all configuration and updates must be performed by the PRoT, and that configuration and state must always be attestable by the PRoT.
Platform Root of Trust
The Platform Root of Trust (PRoT) includes the hardware and software components that are responsible for:
system level security configuration,
anchoring the secure boot process to establish a chain of trust for the platform,
establishing any partitions for its own functionality
establishing the isolated secure processing environments.
The PRoT services provide functionality available to the system beyond the initialization phase, for these, PSA Certified define some interfaces in the form of APIs and ABIs.
In this document no distinction is made between software and firmware. |
Hardware Elements
The Platform Root of Trust includes the following hardware elements. Access to these hardware elements should be possible only via the PRoT and PRoT services.
Software Elements
The Platform Root of Trust and services typically includes the following software elements, as shown in the Figure above:
Secure boot extends the chain of trust anchored in the Boot ROM to the system.
Secure update enables the immutable PRoT, the PRoT services and any ARoT services to be updated to mitigate any vulnerabilities identified.
Processing environment management enforces any required isolation between the managed processing environments and enforces any association of system-level resources to those processing environments.
Secure partition management enforces any required isolation between the managed secure partitions and controls access to resources for each secure partition.
Internal Trusted Storage (ITS) is a PRoT service that provides partition-based access control to isolated and shielded locations for all PSM secure processing environments.
Secure Storage is a PRoT service that provides secure storage in non-isolated storage for any ARoT service.
Cryptographic operations is a PRoT service that provides partition-based access control to the use of keys and cryptographic processing for all secure partitions that implement PRoT or ARoT functionality.
Initial Attestation is a PRoT service that allows a validation entity, to validate the trustworthiness of the Platform Root of Trust, its implementation, and updateable components loaded during secure boot.
Non-Isolated Storage
Non-isolated storage is storage where access control either logically or physically (if off-chip or removable) cannot be enforced by the PRoT. Non-isolated storage is useful for application-specific data, which may include cryptographically protected data where the required keys are protected by the PRoT service.
PRoT Parameters
Implementation ID: public data that uniquely identifies the implementation. Typically, this identifies the device manufacturer, the device model and version number, and any other data necessary to uniquely identify the device and the Immutable PRoT
Instance ID: a public value that identifies the specific instance of the device identified by the Implementation ID. This also allows identification of the instance Initial Attestation Key, and, possibly, the Hardware Unique Key.
Hardware Unique Key: a secret key unique to each device instance that is used to derive other device unique secrets and to bind data to that instance
Boot Validation Key (BVK): the public part of an asymmetric key pair used for authentication during secure boot
Initial Attestation Key: a secret private key from an asymmetric key-pair accessible only to the Initial Attestation service. To prevent cloning or spoofing, this key must be unique to each device instance or to a collection of identical devices. They should not be shared between different versions of a device, between different devices, or between manufacturers.
Boot Decryption Key: a secret symmetric key used where the boot images authenticated by the Boot ROM are encrypted.
Initial parameters (all of the above except Instance ID) are those directly accessible or used by the immutable PRoT, but can be copied to, or used as seeds for derivation of Initial Boot State data. Depending on the certification profile, initial parameters are stored in isolated locations or shielded locations.
Updateable parameters (Implementation ID, Instance ID, Initial Attestation Key) are those that are used by the PRoT services. They should only be directly accessible by the updateable PRoT code and can be copied to or derived and stored in the Main Boot State.
PRoT Security Lifecycle
A lifecycle defines the states of an object through its lifetime. Each security state in the security lifecycle of a device defines the security properties in that state. Security state can depend on:
Software versions
Run-time status such as data measurements, hardware configuration, and status of debug ports
Product lifecycle phase, for example, development, deployment, returned to manufacturer, or end-of-life
The generic security lifecycle shown in the Figure below is intended to capture only the minimum set of notional lifecycle states and transitions. The described characteristics of each state will need to be related to the actual states that arise in an implementation and deployment.
Device assembly and test: The device will be running manufacture and diagnostic software. This is not a secure state and, therefore, is not an attestable state. Test secrets and identities may be present. Production platform security parameters must not be present.
PRoT Provisioning: The device is programmed with production platform security parameters, and is configured so it can enter the Secured state. This is not a secure state and, therefore, not an attestable state.
Secured: The PRoT is fully operational and secured. This is the operational security state for most of the life of the device. Only in this state do the platform security parameters become available to any PRoT software. This is a secure and attestable state.
Debug: If entering either debug state is supported once a device is in the Secured state, then a system reset is required. Only if the device can still be considered trustworthy after debug can it be returned to the Secured state; this is called recoverable debug. Otherwise, debug is considered as non-recoverable.
Decommissioned: Entering this state requires a system reset. This is because the device includes production secrets and the act of reset requires the removal of, or permanent denial of access to, any previous data and derivation of Secured state sensitive data. This is not a secure state and so not an attestable state.
Additional states and sub-states may exist in any real device. Any sub-state must retain the properties of its parent. Both parent and sub-states must always be attestable once a device enters an attestable state.
Debug
When the device is in Secured state, logging of events or reporting of diagnostics in a way that does not expose sensitive data and does not affect the trustworthy operation of the device is permitted. The ecosystem may require that such logs and reports are only accessible by a device management system, and are integrity and confidentiality protected. → This is called non-intrusive debug.
This PSM is concerned with protection of the PRoT and PRoT services when the device is subject to intrusive debug.
Intrusive forms of debug should be restricted to authorized debug agents and require a secure authorization process, with the debug rights granted by an appropriate device management service.
Lifecycle of other components
Other components in a system, for example, trusted subsystems, may have their own lifecycles. The overall product built from the components may also have its own lifecycle. Note that such lifecycles must never be in a state that conflicts with or compromises the security requirements of the Platform Root of Trust security lifecycle.
PRoT Binding
The following types of binding are applicable when sensitive data owned by secure partitions are stored in Non-isolated Storage. Binding may also be used to protect Internal Trusted Storage.
Device binding binds the data to the owning device instance. No other device instances can directly access the data.
Partition binding binds the data to the owning secure partition. No other partition in any processing environment can directly access the data.
Lifecycle State Binding binds the data to specific security lifecycle state.
Binding relies on secret keys and cryptography. The generation and storage of the required keys depends on the lifecycle security state, which includes the supported debug modes. It is recommended to use run-time-derived keys to support lifecycle binding. Derivation is essential if recoverable debug is supported because the return to the secured state requires the generation of the secured state keys.
Device-binding Root Keys
Two binding root keys are defined. Both are security lifecycle-state dependent, and so should be derived after a system reset. Derivation for device binding is essential if recoverable debug is supported.
Secure BRK (SBRK): The same key can only be derived when the device is in a secure security lifecycle state. This ensures that the data that is bound to this key cannot be accessed when the device is in any debug mode.
Non-PRoT Debug BRK (DBRK): The same key can only be derived when the device is in a secure security lifecycle state, or in any debug mode that does not compromise the PRoT.
Derivation of the binding root keys must be through a cryptographic one-way derivation from a hardware unique secret key, for example, the Hardware Unique Key. Derivation ensures that any derived BRK is unique to the device. The derivation must result in SBRK and DBRK being different.
The derived SBRK or DBRK should be used only to derive a Partition Specific Binding Key (PSBK).
Secure Partition-specific Binding Keys
Each PSBK is a cryptographic one-way derivation either from one of the binding root keys, or from an existing derived PSBK that is owned by that secure partition.
When a PSBK is derived, the following data are used.
Explicit parameters provided by the calling secure partition:
The identity of the calling secure partition, which is called the Partition ID, must be an implicit parameter that is provided on behalf of the calling secure partition. This binds the derived PSBK to that secure partition and guarantees the uniqueness of the derived PBSK
The Use Policy does not include export in the clear of the derived PSBK. Thus, a PSBK cannot be used where shared knowledge of the key is required.
PRoT Secure Boot and Firmware Update
Secure boot, sometimes called verified boot, uses cryptography to verify the next stage code and any metadata. The secure boot flow must start with an inherently trusted Boot ROM in the Immutable PRoT; this is the trust anchor for the boot validation chain.
Image Signing, Validation and Encryption
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.
Verified and Version Validated Components
The table above shows the minimal set of verified components and the minimal set of version-checked components.
Anti-rollback
Anti-rollback is used to reject earlier versions of the firmware, software or data that may contain known errors or vulnerabilities. Secure boot must only allow components that have the same or newer version number than the reference version number for that component to be executed.
Boot State
Boot state refers to the data intentionally left at a temporal isolation boundary in the secure boot flow. There are two isolation boundaries defined, leading to an Initial Boot State and a Main Boot State.
Initial Boot State
The initial boot state is the set of data that is provided by the Boot ROM for use by the Main Bootloader. Initial boot state includes the following:
A random boot seed that is generated on each system reset. This can be used by later services, for example, to allow an attestation validation entity to ensure that attestation reports for different Attestation End Points, were generated in the same boot session
For each component that is validated by the Boot ROM, at least the following component information must be captured:
Any Initial Parameter that are required by later stages must be copied from Isolated Locations or Shielded locations, or be derived as appropriate. This is to comply with the parameter visibility rules.
Initial boot state must be only directly accessible to the Main Bootloader, and should not be modified once set by the Boot ROM.
Main Boot State
The main boot state is the set of data provided by the Main Bootloader for use by the Platform Root of Trust Services. The main boot state includes the following:
The initial boot state data
All platform security parameters must be copied to the main boot state, to comply with the parameter visibility rules.
For each component that is validated by the Main Bootloader, at least the following component information must be captured:
Main Boot State must be only directly accessible to the Platform Root of Trust services, and to ensure that the data are trusted, should not be modified once set by the Main Bootloader.
Firmware Update
The selection and download of updates depend on the specific ecosystem and is not defined here. Ideally:
Downloads are over a secure connection from an authorized repository. This helps to prevent networked attackers from sending arbitrary images, though this may make it impractical for future operators to use a different repository. The download may be encrypted
Downloads are authenticated and integrity checked at the time of download, though this may be impractical in some constrained systems.
System Suspend and Hibernation
Suspension and hibernation are low power modes that allow a device to resume from a known point more rapidly than a full system start (a cold boot).
Suspension typically means that some of the state is held in an always-on-power domain on the chip, and any dynamic RAM is placed in self-refresh mode.
Hibernation typically means that all the state is written to some persistent storage before the power is removed. Some of this storage must be on-chip to deny substitution and ensure integrity and freshness.
For suspension or hibernation, the creation and signing of the required resume state, and the process of entering the low power mode, must be performed by trusted code. On resume, validation of the saved resume state must be performed by trusted code anchored in the Boot ROM.
If the integrity of any of the saved resume state is invalid, or replay is detected, then the Boot ROM must proceed with a full system restart.
PRoT Services
This section covers the Platform Root of Trust Services that are made available to any secure partitions. They may also be made available to other partitions provided that the isolation properties are met. PSM does not require the use of any specific API. However, APIs are available and are referenced in this section as examples, and PSA Certified has an API functional compliance programme.
Internal Trusted Storage
Internal trusted storage provides secure partition access to data stored in isolated locations and shielded locations.
Access to sensitive data may depend on the security lifecycle state.
Implementation may rely on the physical access properties of isolated locations or protected locations, or by binding based on the security lifecycle state of the device.
Internal Trusted Storage is supported by the PSA Storage API.
Cryptographic Operations
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 control
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.
The PSA Crypto API provides an interface to the cryptographic operations.
Initial Attestation Service
Evidence provided in an attestation report makes a statement about the state of the entity being attested and is the Attestation End Point (AEP).
An attestation report is intended to be checked by an Attestation Validation Entity (VE). Deployment of attestation services is eco-system dependent. The scope of the AEP and how the attested AEP report is used are application specific and not defined by PSM.
The Initial Attestation Service (IAS) provides a signed Initial Attestation Token (IAT). The IAT includes the state of the Platform Root-of-Trust, including whether a debug state has been entered, and any claims made by AEP. The IAT is bound to the specific device instance through use of the Initial Attestation Key (IAK). The format of the IAT is not defined by PSM, however, the PSA Attestation API supports CBOR encoded IETF Entity Attestation Token.
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.
Secure storage is expected to be available to Application RoT services, but may be available to other partitions provided that that the following properties are met:
Defined ownership of all stored data, regardless of the management of data on the storage device
Privacy and integrity protection to prevent the data from being accessed or modified by an unauthorized agent, including when the device is in a non-secure state, such as during debug
Replay protection to prevent a stored set of data from being replaced by a previously stored version of the data set
Depending on implementation requirements and certification profiles, these properties may be enforced by isolation, or by cryptography, or a combination of both.
Secure storage is supported by the PSA Storage API.
New Terms
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