Posted by IoT Central Team

Introduction

IoT product development crosses several domains of expertise from embedded design to communication protocols and cloud computing. Because of this complexity “end-to-end” or “edge-to-cloud” IoT security is becoming a challenging concept in the industry. Edge in many cases refers to the device as a single element in the edge-to-cloud chain. But the device must not be regarded as a whole when security requirements are defined. Trust must first be established within the processing unit and propagated through several layers of the software stack before the device becomes a trusted end node. Securing the processor requires to properly integrate multiple layers of security and use security features implemented in hardware. Embedded security expertise and experience is required to accomplish such tasks. It is very easy to put a lot of effort on implementing security for an IoT product and in the same time missing to cover key use cases. A simpler way to narrowing down on defining the end-to-end security is to start with identifying the minimum set of business requirements.

Brand image, how a company’s customers perceive and value it, is one of the most valuable assets of any corporation. Two of the most important characteristics of an IoT device that can promote a positive brand image are: resiliency and privacy. For resiliency, this might mean adding features that increase the device’s ability to self-recover from malfunctions or cyber-attacks. For privacy, this means protecting user information and data but also the intellectual property (IP), the product invested in the product. This means that preventing exploitation through vectors such as product\device cloning and over production becomes important. Another business driver is the overall cost of ownership for the product. Are there security related features that can drive the cost down? We include here not just operational cost but also liabilities.

In this blog, we dive deeper into solutions that support these business requirements. We will also discuss a demo we have created in collaboration with our partners Sequitur Labs and Arrow to demonstrate a commercially available approach to solving a number of several security use cases for IoT.

Security in depth – a methodical approach for securing connected products

IoT security must start with securing the device, so that data, data collection, and information processing can be trusted. Security must be applied in layers and facilitate trust propagation from the silicon hardware root of trust (HWRoT) to the public/private cloud or the application provider back-end. Furthermore, the connected paradigm provides the opportunity to delegate access control and security monitoring in the cloud, outside of the device. Narrowing down further, device security must be rooted by enabling fundamental capabilities of the processor or system on chip and consider all three stages of the device lifecycle: inception (manufacturing, first boot), operation, and decommissioning.

In a nutshell we should consider the following layers for securing any IoT product:

• Set a hardware root of trust – secure programming and provisioning (firmware, key material, fuses)

• Implement hardware enforced isolation – system partitioning secure / non-secure

• Design secure boot – authenticated boot chain all the way to an authenticated kernel

• Build for resiliency – fail-safe to an alternative firmware image and restore from off-board location

• Enable Trusted Execution – establish a logical secure enclave

• Abstract hardware security – streamline application development

• Enable security monitoring – cloud based, actionable security monitoring for a fleets of devices

These capabilities provide a foundation sufficient to fulfill the most common security requirements of any IoT product.

Embedded security features needed to build the security layers described above are available today from many silicon providers. However, software is needed to turn these into a usable framework for application developers to easily implement higher layer security use cases without the need for advanced silicon expertise.

Such software products must be architected to be easily ported to diverse silicon designs. Secondly, the software solution must work with the established IoT manufacturing process. “Turning on” embedded security features triggers changes to existing manufacturing flows to accommodate hardware testing before final firmware image can be programmed, burning fuses in the silicon in a specific order and overall handling sensitive cryptographic key material. The fragmentation, complexity, and expertise required are the reasons why embedded security is a challenge to implement at scale in IoT today.

A closer look – commercially available secure platform with Arrow Shield96

AWS partnered with Sequitur Labs and Arrow to provide a commercial solution that follows the approach described in the previous paragraph. This solution follows the NIST SP 800-193 for Platform Firmware Resilience Guidelines and goes beyond to create a secure platform fitted for embedded and IoT products. In the same time it is abstracting the complexity of understanding and utilizing embedded security IP such as hardware crypto, random number generators, fuse controllers, tampers, hardware integrity checkers, TrustZone, on-the-fly memory encryption.

For this blog, we created a demo using the Arrow Shield 96 Trusted Platform (Fig 1) single board computer running Sequitur Labs custom firmware image based on the EmSPARK Security Suite. The Arrow Shield96 board is based on the Microchip SAMD27, a Cortex A5 entry level MPU that embeds a set of security IP capable to fulfill the most stringent security requirements.

Let’s dive deeper into the technical implementation first then into the demo scenarios that fulfill some of customers’ business needs.

Security inception and propagation of trust

Secure boot and firmware provisioning

Introducing secure boot requires initial programming of the CPU, essentially burning keys in the processor’s fuses, setting up the boot configuration, establishing the Hardware Root of Trust, and ensuring the processor only boots authenticated, trusted firmware. Secure boot implementation is tightly correlated to the processor programming and the device firmware provisioning. The following section provides details how secure boot and firmware provisioning can be done properly to establish a trusted security foundation for any application.

Firmware provisioning

EmSPARK Security Suite methodology for provisioning and programming the Shield96 board minimizes complexity and the need for embedded security expertise. It provides a tool and software building blocks that guide the device makers to create an encrypted manufacturing firmware image first. The manufacturing firmware image packages the final components: encrypted blobs of the final device firmware, a provisioning application, and customer specific key material such as private key and X.509 certificate for cloud connectivity, certificate authorities to authenticate firmware components and application updates.
The actual firmware provisioning and CPU programming is performed automatically during the very first boot of the device flashed with the manufacturing image. With the CPU running in secure mode the provisioning application burns the necessary CPU fuses and generates keys using the embedded TRNG (true random number generator) to uniquely encrypt the software components that together form the final firmware. Such components are the Trusted Execution Environment (CoreTEE), Linux kernel, customer applications, Trusted Applications, and key material (such as key material needed to authenticate with AWS IoT Core).

The output – establishing a trusted foundation

The result is firmware encrypted uniquely with a key derived from the HWRoT for each device in a process that does not leave room for device secrets mismanagement or human error. Device diversification achieved this way drastically reduces the cost of manufacturing by eliminating the need for HSMs and secure facilities while providing protection from class break attacks (break one break all).
Another task the provisioning process performs during the very first boot is creating and securely storing a unique device certificate from a preloaded CSR (Certificate Signing Request) template and a key pair generated using the HW TRNG then signed with a customer provided private key only usable securely during the device first boot. The device certificate serves as the immutable device identity for cloud authentication.

Secure boot

The secure boot implemented creates the system partitioning in secure and non-secure domains making sure all peripherals are set to the desired domain. Arm TrustZone and Microchip security IP are at the core of the implementation. CoreTEE, the operating system for the secure domain runs in on-the-fly AES encrypted DDR memory. This protects a critical software component (the TEE) from memory probing attacks. Secure boot has been designed so at the end of the boot process, before handing over control of the processor from the secure domain to the non-secure domain (Linux) to close access to the fuse controller, secure JTAG, and other peripherals that can be leveraged to breach the security.

Building for resilience

Secure boot implements two features that boost device resilience – a fail-over boot from a secondary image (B) when primary boot (A) fails, and the ability to restore a known good image (A) from an off-board location. The solution includes a hardware watchdog and a boot-loop counter (as set by the device maker) that Linux resets to maximum after each successful boot. If Linux fails to boot repeatedly and the counter reaches zero the B partition is set for the next boot. After such failure once the failover boot B is loaded, the device connects to an off-board location (in our demo that is a repository on AWS) retrieves the latest firmware image and re-installs it as the primary one (A). These two features help to reduce operational cost by allowing devices in the field to self-heal. In addition, AWS IoT Device Defender checks device behaviors for ongoing analysis and triggers alerts when behaviors deviate from expected ranges.

In our demo when the alternative firmware image (B) is loaded, an event is triggered in the AWS IoT Device Defender agent. The AWS IoT Device Defender agent running as a TA in the secure domain sends these events to the AWS IoT Device Defender Detect service for evaluation. The TA, running in the secure domain, also signs AWS IoT Device Defender messages to facilitate integrity validation for each reported event.

Another key component of the EmSPARK Suite is the secure update process. Since secure boot is the only process that can decrypt firmware components during device start it is also involved in performing the firmware update. The firmware update feature is facilitated in Linux as an API call that requires a manifest and the signed and/or encrypted new firmware image. The API call performs image signature verification and sets the flag for the boot to update and restarts the board. During next boot the secure boot process decrypts the new image using a pre-provisioned key and re-encrypts it with the board-specific key. The manifest indicates which components need to be updated – Linux Kernel, TEE, TAs and/or bootloader.

Enabling easy development through security abstraction

Arrow Shield through the EmSPARK Suite product preloads a number of TAs (Trusted Applications) with the Shield96 firmware. The figure below is a view of the dual domain implementation and the software components provided with the Shield96 Trusted product in our demo.

These TAs expose a set of secure functions to Linux via a C SDK (called the CoreLocker APIs). The Arrow board and Sequitur’s security suite preloads the following TAs for our demo:

• Cryptographic engine – providing symmetric, asymmetric crypto operations and key generation integrating silicon-specific hardware crypto
  Key-store and a CA-store managed (add, delete) via signed commands

• Secure firmware update

• Secure storage for files and stream data

• TLS and MQTT stacks

• AWS IoT Device Defender secure agent

In addition, a tamper detection and remediation TA has been added for our demo purposes (as detailed in “The demo” section below). These TAs provide a preloaded framework for implementing a comprehensive set of security use cases assuring that security operations are executed in isolation from the application OS in an authenticated and resilient environment. Such use cases include confidentiality, authentication and authorization, access control, attestation, privacy, integrity protection, device health monitoring, secure communication with the cloud or other devices, secure lifecycle management.

All TA functions are made available to application development through a set of C APIs via an SDK. Developers do not need to understand the complexity of creating TAs or using HW security provided by the chipset.

Translating TAs to security use cases

Through a securely managed CA-store (Certificate Authority) the device can authenticate payloads against a set of CAs optionally loaded at manufacturing or later in the device lifecycle. Having the ability to update securely the CAs the device or product owner can transfer the ownership of certain functions such as firmware update or application update to other entities. For example, the customer owns the applications but the firmware update and security management may be delegated to a third party Managed Service Provider while maintaining privacy requirements.
The cryptographic engine is core to anything related to security and implement a set of symmetric and asymmetric cryptographic functions and key generation allowing applications in non-secure domain to execute crypto in isolation. HW crypto is used when implemented by the chipset.

The Microchip SAMA5D2 implements in hardware the ability to monitor in real time regions of memory. In the Shield96 firmware this feature – ICM, Integrity Check Monitoring – is used to monitor the integrity of the Linux kernel. Any modification of the Linux kernel triggers an interrupt in the secure domain. The hardware isolation implemented through TrustZone prevents Linux to even “be aware” of such interrupts. The interrupt triggers a remediation function implemented in a TA and together with the Device Defender Secure Agent TA that does three operations:

• records the tampering event and restarts Linux from the verified, authenticated encrypted image provided through secure boot

• after restart packages the tampering event into a JSON format, signs it for integrity assurance and stores it

• publishes the JSON package to the AWS IoT Device Defender monitoring service

Complementing the edge-to-cloud security strategy with AWS IoT Device Defender

AWS IoT Device Defender audits device cloud configuration based on security best practices and monitors anomalies and threats on devices based on expected cloud- and device-side behaviors on an ongoing basis. In this demo and for complementing the defense mechanisms implemented at the device level, AWS IoT Device Defender performs its monitoring capability and enables customers to receive alerts when it evaluates that anomalous or threat events occurred on an end-node. This demo required installing AWS IoT Device Defender agents on both the non-secure and secure domains of the Shield96 board. The security domain is providing the secure crypto signature (using securely a private key) to device health reports and also isolates the detection and reporting processes from being intercepted by malicious applications. AWS IoT Device Defender agent collects monitored behaviors in the forms of metrics from both domains; then from the secure domain, AWS IoT Device Defender agent sends the metrics to the AWS Cloud for evaluation.

The Demo

For a full demo tutorial, please watch this video .

The demo covers the following scenarios:

• Out of the box experience

• Firmware personalization – secure firmware rotation to provide a logistical separation between manufacturing and production firmware

• Device registration to AWS IoT Core

• Device decommissioning (de-registration) from AWS IoT Core

• Secure firmware update

• Resilience demonstration – tamper event simulation and remediation

• Event reporting to AWS IoT Device Defender

Demonstrating resilience and tamper violation reporting with AWS IoT Device Defender

The boot logic for the demo includes a safety check for tamper events. In this case, we connected a button to an environmental tamper pin. The tamper violation generated by the button press is detected in the next boot sequence so the initial boot code switches to the secondary boot stack, and proceeds to boot the “fail-safe” boot image. Once booted the system will publish the tamper event to AWS IoT Device Defender for logging and analysis. In the demo, the primary and secondary images are identical, so each tamper event simply switches to the other. This allows the demo scenario to be repeated with each tamper event switching the system from A to B or B to A firmware images.

Streamlining personalized firmware to commercial boards

The commercial solution introduced by Arrow with the Shiled96 board includes a cloud based secure firmware rotation from the manufacturing generic firmware using AWS thus streamlining device personalization and providing a production ready device to a multitude of customers.

Out of manufacturing, the Shield96 Trusted board comes preloaded with a minimum and generic version of Linux. The out of the box experience to get to a personalized and up to date firmware is as simple as inserting an SD card and connecting the board to the Internet. The device boots securely, partitions the SD card then using Just-in-Time Registration of Device Certificates on AWS IoT (JITR) registers the device to AWS IoT Core and provisions it to Sequitur’s AWS IoT Core endpoint and to the Sandbox application. Next, the device automatically downloads the most recent generic or customer-specific file system, installs it and restarts. Thus the Sandbox provides lifecycle device management and firmware updates.

The 2-stage firmware deployment starting with a generic preloaded firmware at Arrow Programming Center followed by a cloud based final firmware rotation gives customers valuable features. For instance, an Original Equipment Manufacturer (OEM)\Original Device Manufacturer (ODM) may need to produce devices with firmware variations for deployment in different geographical regions or customized for different customers. Alternatively, the OEM\ODM may want to optimize logistics, manufacture in volume while the firmware is still in development, and load the final firmware in a distribution facility before shipping to customers. It also eliminates the opportunity for IP theft in manufacturing since the final firmware is never present at the manufacturer.

Conclusion

The solution introduced with this blog demonstrates that manufacturers can produce devices at scale while security is implemented properly, taking full advantage of the silicon embedded security IP. This implementation extends niche expertise and years of experience into a framework accessible to any developer.
Why is this important? Advanced security implemented right, massively reduces time to market and cost; the solution is also highly portable to other silicon. Sequitur Lab’s EmSPARK Security Suite is already available for NXP microprocessors (i.MX and QuorIQ Layerscape families) and nVidia Xavier bringing the same level of abstraction to IoT and embedded developers.
In this relationship Arrow proposes a secure single board computer fully provisioned. Arrow adds greater value by offering the ability to customize the hardware and the firmware. Customers can choose to add or remove hardware components, customize the Linux kernel, and subscribe for firmware management and security monitoring.
APN partners complement existing AWS services to enable customers in deploying a comprehensive security architecture and a seamless experience. In this case, Sequitur Labs and Arrow bring to market a game changing product complementing existing AWS edge and cloud services to enable any project of any size to use advanced security without the need for qualified embedded security experts.
Moreover, the product builds on top of HW security features of existing processors while providing the necessary software tools and process to work with existing manufacturing flows and not require secure manufacturing.
For a deeper dive into this solution the Getting Started Guide on the AWS Partner Device Catalog provides board bring up steps and example code for many of the supported use cases.