Automated onboarding and security features now help speed the integration of embedded devices into IoT systems.
Arvind Raghuraman, Mentor Graphics, a Siemens company
As the internet of things has evolved it has also grown more complicated. There are myriad choices when it comes to choosing the right cloud platform, cloud apps, device run-time components, communication protocols and topology, and security architecture.
Consider a typical IoT system topology in use today. It includes the cloud which could be running several hosted applications. These applications subscribe to data pushed by IoT devices, process that data, and present it to users in a meaningful fashion. The IoT devices could be categorized under one of two generalized form factors: gateways, and end nodes.
End nodes are leaves in an IoT topology. They typically connect and push data to a cloud or gateway-type back-end. Gateways typically serve as data aggregation points that provide first level processing for data from end nodes. Gateways usually implement localized analytics or other filtering functions that process dense incoming information from end nodes. After first- level processing, gateways push processed data to the cloud.
Let’s go over considerations a system designer should take into account to enable an embedded device to participate in a secure IoT system architecture. We’ll start with device onboarding. This can be discussed under two heads; cloud/gateway, and device side infrastructure.
Cloud platforms typically host device management applications that provide users the interfaces and workflows needed for creation and management of device identities. When a device identity is created, associated device security credentials are generated. Public key based asymmetric authentication schemes are typically used to enable device authentication workflows. The generated security credentials and other important metadata (including the URL of the device management/rendezvous server back-end the device should connect to for on-boarding) should be provisioned to the device by the user.
On the device side, on power-up, the device should check the integrity and origin of software being booted on the device. Secure boot architecture is an important consideration to protect devices from rooting-type attacks. The device’s system design should consider inclusion of tamper-proof secure storage and associated software APIs to access and manage secure storage.
Secure storage is typically needed to store security keys for device onboarding and secure boot, and other sensitive device specific secrets. Once device software is successfully booted, a device application would typically present the user provisioned credentials to a back-end device management application. The back-end could be running on the cloud or on a gateway type device. The back-end app would authenticate the device identity and securely onboard the device.
Next, let’s consider device communications with the backend. With the device securely on-boarded, device applications must create a secure communication channel between the device and the back-end. Depending on the protocol used, the communication session is typically secured using symmetric encryption schemes. Once secure communication is established, the device can push data to and receive asynchronous data from the back end.
To formalize communications between the device and backend, data models are often employed. Once secure communications are established, a data model is established between the device and the backend. This model can be provisioned by the back-end to the device or instantiated and exposed by the device to the back-end.
The data model typically consists of device-specific parameters, methods and commands. Using the data model, back-end apps can subscribe to device data and engage device services. For example, a back-end application could subscribe and plot a temperature parameter exposed by the device; it could invoke an update method to trigger a software update, and on completion it could issue a reboot command to boot new firmware on the device. Data flowing from the back end to the device could also include asynchronous messages signaling alarm conditions or event notifications which the device would process and act on.
Finally, let’s consider device maintenance. A secure infrastructure for creation and delivery of software updates targeted at the device operating system, or at application software and data, is an essential element for IoT device maintenance and security. Most use-cases require privacy, integrity, and authenticity attributes of update artifacts be assured before update artifacts could be consumed by devices. A comprehensive software update infrastructure should include: tooling for encryption and digital signing of update artifacts, a cloud or on-premises-based infrastructure to deliver updates at scale to the device fleet, and device run-time software to receive, authenticate, and implement the update.
On the device side, suitable mechanisms should be present to enable software run-time to assess health of updated software. In case of improper or incomplete updates, device firmware should have the ability to revert the device software stack to a previously known working version.
For devices that are capable of running a GPOS like Linux, application development, deployment, and migration using container-based approaches are becoming widely used. A container-based approach for application management provides several benefits; portability, ease of migration, scalability, standardization, continuous integration (CI) and delivery (CD) flows, application life cycle management, health monitoring, and availability of a rich open-source eco-system of run-time software and tools for management and orchestration of containerized applications, to name a few.
Under the umbrella of device maintenance, health monitoring is another important topic. Device run-time software should expose OS and application specific health parameters to the backend. The device data model could include system health information. Health monitoring applications in the backend would leverage this information to present device health information to users.
Obviously, the process of commissioning and securing IoT devices can be quite involved. So device software frameworks have emerged to help manage the process. An example is the Mentor Embedded IoT (MEI) Framework. It is a collection of software components which compiles into a library. The library comes with a device agent which can be incorporated into the device runtime to start up on device boot. The framework library allows devices to readily onboard and establish communications with widely used cloud platforms that include AWS, Azure, and Siemens’ MindSphere (coming soon).
Incorporating the library into an IoT device gives the device IoT connectivity. In a typical scenario, a gateway could be running Linux and within it, the MEI Framework will appear like a library with a resident agent which boots up on device boot. The agent would be provisioned with the device credentials generated at the time of device-identity creation.
On boot up, the agent would present the credentials to the configured cloud back-end and onboard the device. Once the device is on-boarded, the agent negotiates a system data model consisting of MEI Framework services. The framework services include: software update services that enable back-end apps to update device OS and application software, profiling services that enable Mentor’s profiling tools to debug devices exhibiting abnormal behavior, health monitoring and diagnostic services that enable back-end apps to monitor device health and perform diagnostics.
In addition to out-of-the-box operability with supported cloud platforms, the Mentor Embedded IoT Framework (MEIF) could be configured to enable device operability with several widely used open-source cloud applications that provide device management and monitoring functionality.
Leshan, for example, is an OMA Lightweight Machine to Machine (LWM2M) client and server implementation that brings in a web UI and API for device management. Hawkbit, provides web UI and APIs that enable the infrastructure and interfaces needed to manage device fleet’s software updates. Grafana, a metric analytics and visualization suite, provides a web UI for device health monitoring. Thingsboard, an IoT platform, provides configurable data visualization dashboards for monitoring and management of IoT devices.
In a nutshell, MEI Framework is a library and an agent with associated host- side tooling that can be integrated into a gateway or end-node-type device. The MEI Framework enables an embedded device to readily onboard and communicate with supported cloud platforms. In addition, the library readily enables the device to operate with several open-source device management and monitoring applications that could be hosted on the cloud or on a local on-premises environment.
[…] people are getting more used to FR embedded in their devices, privacy advocates point out that it’s essential to maintain a proper balance between achieving […]