Arm Community
Arm Community
  • Site
  • User
  • Site
  • Search
  • User
  • Groups
    • Arm Research
    • DesignStart
    • Education Hub
    • Innovation
    • Open Source Software and Platforms
  • Forums
    • AI and ML forum
    • Architectures and Processors forum
    • Arm Development Platforms forum
    • Arm Development Studio forum
    • Arm Virtual Hardware forum
    • Automotive forum
    • Compilers and Libraries forum
    • Graphics, Gaming, and VR forum
    • High Performance Computing (HPC) forum
    • Infrastructure Solutions forum
    • Internet of Things (IoT) forum
    • Keil forum
    • Morello Forum
    • Operating Systems forum
    • SoC Design and Simulation forum
    • 中文社区论区
  • Blogs
    • AI and ML blog
    • Announcements
    • Architectures and Processors blog
    • Automotive blog
    • Graphics, Gaming, and VR blog
    • High Performance Computing (HPC) blog
    • Infrastructure Solutions blog
    • Innovation blog
    • Internet of Things (IoT) blog
    • Mobile blog
    • Operating Systems blog
    • Research Articles
    • SoC Design and Simulation blog
    • Smart Homes
    • Tools, Software and IDEs blog
    • Works on Arm blog
    • 中文社区博客
  • Support
    • Open a support case
    • Documentation
    • Downloads
    • Training
    • Arm Approved program
    • Arm Design Reviews
  • Community Help
  • More
  • Cancel
Arm Research
Arm Research
Research Articles IoT security: From spec to code
  • Research Articles
  • Leaderboard
  • Resources
  • Arm Research Events
  • Members
  • Mentions
  • Sub-Groups
  • Tags
  • Jump...
  • Cancel
Arm Research requires membership for participation - click to join
More blogs in Arm Research
  • Research Articles

Tags
  • Arm Research
  • Arm Trusted Firmware
  • Platform Security Architecture (PSA)
  • Security
  • Integrated Security
  • TrustZone
Actions
  • RSS
  • More
  • Cancel
Related blog posts
Related forum threads

IoT security: From spec to code

Hannes Tschofenig
Hannes Tschofenig
August 26, 2021

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.

One building block in a large ecosystem

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:

  • Provision operational credentials and related security configuration to have the IoT device interact with a management server
  • Update software and firmware to fix bugs and to provide new functionality
  • Configure the device (for example, networking functionality, access control lists)
  • Perform application service provisioning (e.g., configuring the device to use specific application features, which may depend on the customer, the location of the device, or the type of subscription a user has with the service provider)
  • Fault management (e.g. collecting debug logs for detailed analysis by developers)
  • Retrieval of sensor and other device-specific data
  • Control actuators (like motors)

Standardized lifecycle management for IoT devices

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.

LwM2M DiagramFigure 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 

Useful links

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

Anonymous
  • Hannes Tschofenig
    Offline Hannes Tschofenig 9 months ago in reply to StefanH

    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.

    • Cancel
    • Up 0 Down
    • Reply
    • More
    • Cancel
  • StefanH
    Offline StefanH 9 months ago

    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?

    • Cancel
    • Up 0 Down
    • Reply
    • More
    • Cancel
Research Articles
  • Hands-on experience at Singapore Management University

    Andrew Pickard
    Andrew Pickard
    SMU has been working on the SAP Next-Gen student project, to develop innovative sustainability solutions using SAP software and real-world IoT devices from Arm's partner ecosystem.
    • May 30, 2022
  • Cryptography: what is under the mask?

    Andrew Pickard
    Andrew Pickard
    Sorbonne Université has been using Arm processor source code for modelling and verification on the hardware at the micro-architectural level.
    • May 26, 2022
  • How about a short walk?

    Ilias Vougioukas
    Ilias Vougioukas
    Current solutions to improve virtual to physical translation performance are impractical. We present an alternative, where a small change has a significant impact.
    • March 10, 2022