A developer-friendly way to access security functionality has now been established, with the PSA Functional Application Programming Interfaces (APIs), a deliverable of the PSA Certified program. The PSA Crypto API allows developers to transparently access security functionality residing on and off the chip. Further APIs, such as the storage API, initial attestation API or the firmware update API, have also been made available, enhancing the ease with which security functionality can be accessed. Although initially supporting Cortex-M microcontrollers, they have recently also been made available for A-class processors. API specifications are important, but implementations are even better. In the case of the PSA Crypto API the implementation can be found in Mbed TLS.
With the goal of securing Internet of Things (IoT) devices, these APIs are just one building block in a larger ecosystem. Trusted Firmware-M (TF-M) and Trusted Firmware-A (TF-A) offer reference software running on a TrustZone system, implementing these APIs. TrustZone offers software isolation capabilities and thereby reduces the attack surface by separating security-sensitive code from regular application code. The Trusted Firmware project allows developers to focus on implementing the software running in the Non-secure Processing Environment (NSPE), such as a sensor monitoring application, while the security functionality is being taken care of. NSPE software can use PSA Functional APIs to access security services offered by TF-M/TF-A running in the secure world. Note that the area of applicability for the PSA Functional APIs has been extended beyond TrustZone, and now also includes dual-core M-class devices as well as Corstone-based System on Chip (SoC) designs. Here, the TF-M software is meant to run on a M-class processor that sits next to an A-class processor on the same SoC.
The FIDO Alliance has recently published their specification for secure device onboarding called FIDO Device Onboard (FDO). FDO, when run successfully, configures the device so that it can execute an IoT device management protocol. Device management allows a company managing a fleet of IoT devices to remotely perform all major functions needed for proper operation of an IoT device. These functions include:
Lightweight Machine-to-Machine (LwM2M) is a standardized IoT device management protocol. Originally proposed in 2012, it is one of the few standardized device management protocols designed to operate on constrained IoT devices. Skipping forward to the present day, LwM2M is available in open-source implementations. It has gone through extensive interoperability testing with more than 45 companies, and the specification itself has evolved through several iterations over the years. The most recent version of LwM2M, v1.2, was published in 2020. With v1.2 LwM2M can now be used over many different transports, including MQTT, HTTP, CoAP over UDP and TCP, and can even operate over non-IP-based bearers (such as SMS, LoRaWAN, and Cellular IoT). Figure 1 illustrates the protocol stack. This year, the specification was enhanced with gateway functionality so that an IoT island can be connected to a LwM2M infrastructure using a gateway in a simple manner.
Figure 1: LwM2M v1.2 Protocol Stack
LwM2M, as well as FDO, utilizes cryptographic functions and may use attestation, and incorporates a firmware update mechanism. To utilize the features offered by TF-M and TF-A, the implementation of an FDO client or a LwM2M client on an IoT device must use the PSA Functional APIs, since the security services are exposed to applications with those APIs. The open-source Pelion Cloud Client implementation, for example, utilizes the Mbed TLS implementation under the hood. It can therefore use the PSA Crypto API (since it is part of Mbed TLS) to conveniently access TF-M and TF-A provided services.
LwM2M addresses device management use cases which are required by any IoT device, and developers can leverage the work done by OMA SpecWorks on LwM2M through an open and transparent development process. The LwM2M specifications have been implemented and some of those implementations are available as open source code. OMA SpecWorks organizes ‘testfests’ to test conformance of implementations against the specifications using a detailed test specification. When specification work for protocols and APIs are combined with reference implementations, IoT developers are able to secure their IoT devices more easily than ever before. They benefit from the state-of-the-art security technology utilized in its design. Importantly, all of this is achievable while utilizing energy-efficient and low-cost microcontrollers, crucial for constrained IoT designs.
If you are interested in the details, please consider watching a recent talk on "Internet of Things (IoT) Security: from specification to code", or contact me with any questions.
Watch the talk Questions? Contact Hannes
Trusted Firmware: https://www.trustedfirmware.org/
PSA Certified: https://www.psacertified.org/
LwM2M v1.2: https://omaspecworks.org/lwm2m-v1-2-is-now-available/
LwM2M Gateway: http://www.openmobilealliance.org/release/LwM2M_Gateway/V1_1-20210518-A/HTML-Version/OMA-TS-LWM2M_Gateway-V1_1-20210518-A.html
PSA Crypto API: https://armmbed.github.io/mbed-crypto/
FIDO Device Onboard: https://fidoalliance.org/specs/FDO/fido-device-onboard-v1.0-ps-20210323/
Corstone: https://developer.arm.com/ip-products/subsystem/corstone
Hey Stefan, you can actually look at the Mbed TLS implementation at github.com/.../mbedtls. The Mbed TLS project uses a number of C preprocessor directives to include or exclude certain features during the compilation process. The full list of defines can be found in the include/mbedtls/mbedtls_config.h file. If you build the code with MBEDTLS_USE_PSA_CRYPTO enabled, then PSA Crypto API is used (instead of the legacy Mbed TLS API). I hope this helps.
Is there some resource like a tutorial or a paper describing how to implement a security protocol like TLS by using ARM PSA cryoto API?