Introduction to PSA Certified IoT Security Framework
Internet-of-Things (IoT) devices are designed to connect to the internet and/or exchange information with other devices, making them a target for hackers who can exploit security vulnerabilities. Implementing robust security measures to ensure data integrity, confidentiality, and availability on those devices has become a priority.
Security within the IoT industry has historically been fragmented, lacking a common language and standardized processes, implementations, and certifications, leading to inconsistent and mostly inadequate levels of security across devices. From a product developer perspective, security was seen as a complex and expensive process that could increase time-to-market and negatively impact the business.
This is the challenge that the PSA Certified IoT Security Framework aims to solve by offering a standardized approach to creating secure IoT devices, from analysis through to security assessment and certification. In addition, it also provides free resources and training material that help educate product developers about various security topics, such as threat modeling and certification.
The framework divides security design into a simple four-step process of analyze, architect, implement and certify to guide product developers into implementing the appropriate level of security in their IoT devices. This blog post focuses on the implementation step, specifically the PSA Certified APIs, which establishes a separation between security-critical firmware and application firmware. To learn more about security by separation, Non-Secure Processing Environment (NSPE) and Secure Processing Environment (SPE), we recommend reading our DevZone blog post An Introduction to Trusted Firmware-M.
What are PSA Certified APIs
The PSA Certified APIs are a set of high-level standardized software interfaces that aim to enhance the security of IoT devices. They are designed to support a range of different use cases and are organized around the following groups:
Utilizing the PSA Certified APIs brings several benefits for developers implementing security into IoT devices.
- Enhanced security: PSA Certified APIs enable devices to meet industry-standard security requirements and enhance the overall trustworthiness of IoT devices.
- Implementation agnostic: By utilizing PSA Certified APIs, developers don't need to be concerned about the underlying hardware and software implementation.
- Reduce time-to-market: Utilizing an API standard can accelerate development time and reduce costs associated with developing, testing, and certifying custom solutions.
- Flexible and scalable: The various use cases supported ensure that the PSA Certified APIs can be used across multiple devices, from very simple ones to more complex systems.
- Future proof: PSA Certified APIs are designed to be updated over time as security threats evolve, ensuring devices remain secure throughout their lifecycle.
PSA Crypto API
This section will sum up some of the features of the PSA Crypto API and how they can be specific to our implementation.
For a full explanation, see the official documentation on the PSA Crypto API can be found at PSA Crypto. See psa/crypto.h for versioning.
To sum up some advantages of the PSA Crypto API:
The PSA Crypto API is a single API for all cryptographic drivers, which means that you can use the same functions for the nRF52840, nRF5340 and nRF9160 devices, as well as future ones.
The API will work for applications with and without Trusted Firmware-M.
The PSA Crypto API will automatically select cryptographic libraries based on project configurations. This way, the codebase for cryptography can easily be reused across multiple projects.
The PSA Crypto API is designed to be safe and easy to use, lowering developers' possibility of introducing vulnerabilities into their end devices.
For example, the functions in the PSA Crypto API use Key Identifiers to handle keys, so developers do not have to handle keys manually. See Keystore Interface for the concept.
When to use the PSA Crypto API?
The Crypto API is used to request cryptographic operations in the nRF Connect SDK.
Supported operations include hashing, encryption/decryption, authenticated encryption and signature generation/verification. See our cryptographic samples for more examples.
See our Driver configurations and supported features for a list of supported functionality.
What is the Nordic solution for the PSA Crypto API?
The Crypto API will use different libraries depending on hardware capabilities and user configuration.
These libraries are:
- cc3xx libraries: Provides support for the CryptoCell 310 and CryptoCell 312 hardware peripherals. See Crypto Libraries.
- nrf_oberon: nrf_oberon is a highly optimized software library for cryptographic algorithms created by Oberon Microsystems and licensed to Nordic Semiconductor ASA for redistribution.
For a specific cryptographic operation, the PSA Crypto API will use the library configured for the operation.
If multiple libraries have been enabled, cc3xx will be prioritized, given that the CryptoCell supports the cryptographic operation.
Here is a simplified figure illustrating the library selection:
Where to find samples and documentation on the PSA Crypto API
API reference: PSA Crypto API
Configuration: Driver configurations and supported features
Samples: Cryptographic samples
PSA Secure Storage API
This section will sum up some of the features of the PSA Secure Storage API and how they can be specific to our implementation.
For a full explanation, see the official documentation on the PSA Secure Storage API can be found at PSA Secure Storage API. See psa/protected_storage.h for versioning.
The Secure Storage API consists of Internal Trusted Storage and Protected Storage.
The Internal Trusted Storage API is used internally by the SPE to store data persistently in secure flash. It is possible to expose the Internal Trusted Storage API to the NSPE, but we do not recommend this.
The Protected Storage API is for storing data persistently in secure flash and provides integrity checks to the stored data. The Protected Storage API is an Application Root of Trust service and is available in the Non-Secure Callable interface, making the Protected Storage API callable from either SPE or NSPE.
Data in Protected Storage has ownership, so data stored from SPE is only available to the SPE.
| Internal Trusted Storage | Protected Storage | |
| Persistent Storage | Yes | Yes |
| Root of Trust (RoT) | Platform RoT Service |
Application RoT Service |
| Available in SPE | Yes | Yes |
| Available in NSPE | No (by default) | Yes |
| Encryption | No * | Yes |
| Integrity Check | No | Yes |
* Internal Trusted Storage have experimental support for encryption with CONFIG_PSA_ITS_ENCRYPTED.
What is the Nordic solution for the PSA Secure Storage API?
nRF chips with a System Protection Unit (SPU) hardware peripheral have functionality for flash access control, making it possible to configure flash sections as secure.
Internal Trusted Storage and Protected Storage will save data to the sections of secure flash. This way, the NSPE can not directly access data saved by the Internal Trusted Storage API or Protected Storage API.
Internal Trusted Storage is only available internally
For nRF chips without an SPU, the PSA Secure Storage API will save data in regular flash storage.
What is a common use case for the PSA Secure Storage API?
To store sensitive user information in an external flash, I would use the Protected Storage API.
This would encrypt the data, protecting it in case the external flash is lost.
The Protected Storage API would also perform integrity checks on the data, so I know if I can still trust the read data.
Where to find samples and documentation on the PSA Secure Storage API
API reference: PSA Secure Storage API
Samples: Zephyr: PSA Protected Storage sample
PSA Attestation API
Official documentation on the PSA Attestation API can be found at PSA Attestation API. See psa/initial_attestation.h for versioning.
PSA Certified also has a Device Attestation and Entity Attestation Tokens Explained post, which gives an overview of attestation.
When to use the PSA Attestation API?
Arm explains this well in Device Attestation and Entity Attestation Tokens Explained:
"Cloud service providers need to make informed judgements on end devices to ensure the data they are providing can be trusted. EAT has the capabilities to provide this source of trust, using a cryptographically signed piece of data containing claims that are generated in the device RoT. There are many ways it can be useful, but most importantly it can be read by the relying party. The relying party can verify the claims made by the device such as:
- The unique identity of the device
- Installed software on the device and its integrity status
- Security assurance and certification status
- Manufacturer of the device hardware
Using this information, the relying party can make informed decisions such as whether the device is legitimate and should be onboarded, or what services should be enabled based on its security credentials."
Where to find samples and documentation on the PSA Attestation API
API reference: PSA Attestation API
Samples: TF-M: PSA template
PSA Firmware Update API
The nRF Connect SDK does not implement the PSA Firmware Update API.
Instead, other options are available for the immutable bootloader and the upgradable bootloader.
See Bootloaders and Device Firmware Updates for more information on available bootloaders.
These bootloaders fulfil requirements by PSA Certified, and several of our devices are already PSA Certified Products.
Closing
The fragmented IoT security landscape is moving into standardized approaches such as PSA Certified, which continues to gather momentum across the industry. This brings benefits at multiple levels, from the developers who can accelerate time-to-market, to the end device customers who will be more confident about utilizing those devices. Nordic is part of this standardization effort and aligns with PSA Certified to provide our customers the industry-leading security enablers with which they can implement the adequate security level for their IoT products.
Feel free to leave a comment and tell us how you are tackling security in your IoT product and how Nordic's product offering has helped you implement the security requirements of your application.