Why the cloud matters for the IoT

The leading cloud providers - like Amazon Web Services (AWS), Microsoft Azure and IBM’s Watson supercomputer - are making it easier to connect up IoT gateways and even the individual nodes to the IoT. Where previously APIs (such as REST) have needed an intelligent gateway to aggregate the nodes and connect to the cloud, now using cloud-based IDE development systems can provide direct, secure links to the IoT. This can significantly speed up the development and deployment of optimised, secure sensor and actuator networks.

Security is one of the key issues in this integration. Microsoft, for example, has added security capabilities to its Azure cloud, in order to offer ‘IoT as a service’ to designers. This simplifies the development process, making it quicker and easier for customers to get started without having detailed knowledge of the cloud infrastructure. To do this, Azure IoT now supports Device Identity Composition Engine (DICE) and many different kinds of Hardware Security Modules (HSMs).

DICE is an upcoming standard at the Trusted Computing Group (TCG) for device identification and attestation. It enables manufacturers to use silicon gates to create device identification based in hardware. This makes security hardware part of new devices from the ground up. HSMs are the core security technology used to secure device identities and provide advanced functionality - such as hardware-based device attestation and zero touch provisioning. Azure IoT integrates HSM support with new platform services - such as hub device provisioning and management. This enables developers to focus more on identifying specific risks associated with their applications and less on security deployment tactics.

The minimalist approach of DICE is an alternative path to more traditional security framework standards like the Trusted Computing Group’s Trusted Platform Module (TPM), which is also supported on the Azure IoT platform. The Azure Stream Analytics analytical functionality is another addition. This extends from the cloud down to the device level. It has the same unified cloud management for stream analytics running across edge devices and the cloud, and enables organisations to use streaming analytics in scenarios where connectivity to the cloud is limited or inconsistent.

Microsoft has been pushing Azure into the IoT domain through a deal with network provider SIGFOX, which has an extensive Low Power Wide Area Network (LPWAN) wireless infrastructure deployed. These can be accessed via devices such as the Microchip evaluation board that provide long range wireless links to sensor gateways and nodes. This allows the data from the nodes to be collected in the SIGFOX cloud or in the wider Azure cloud, depending on the needs of the end user application.

A different approach
Taking another approach to simplify the integration process for developers, Microchip has also used its acquisition of Atmel as an opportunity to work with AWS - and benefit from the AWS mutual authentication IoT security model. Previously, system developers that connected to this AWS IoT service needed to take very specific actions to comply with the security model employed.

Firstly, they had to pre-register the security authority to AWS servers, in order to establish a trust model. Secondly, for each IoT device they had to generate unique cryptographic keys that were mathematically linked to the pre-registered security authority. Finally, these unique device keys needed to remain secret for the life of the device. In volume production, the generation and secure handling of such unique keys could prove to be a daunting challenge in the chain of manufacturing, especially where third parties with different trust and compliance levels would be involved.

Instead, the AT88CKECC development kit provides a way to meet the security standard of AWS’ mutual authentication model and easily connect to the AWS IoT platform during the evaluation and engineering phases, before moving on to prototyping and pre-production.

This means developers can simply solder the device on the board and connect it over I2C to the host microcontroller, which runs an AWS Software Development Kit (SDK). Once this is complete, there is no need to load unique keys and certificates required for authentication during the manufacturing of the device, as the AWS-ECC508 is pre-configured to be recognised by AWS without any intervention. All the information is contained in this small (3x2mm), easy to deploy, crypto companion device.

The ECC508 exhibits strong resistance to environmental and physical tampering, including countermeasures against expert intrusion attempts. In addition, it features a high quality random number generator, with the internal generation of secure unique keys and the ability to seamlessly accommodate various production flows in the most cost effective manner.

A typical IoT device consists of a small 8-bit microcontroller, and is battery powered. It is usually a challenge for a microcontroller to provide low latency responsiveness, memory and code space for security protocols while keeping power consumption low enough that it can conserve battery life. The ECC508’s low power processor-agnostic cryptographic acceleration function has compatibility with the widest range of resource constrained IoT devices.

Energy harvesting
Elsewhere IBM has teamed up with the EnOcean Alliance to connect energy harvesting devices with IoT networks. This will allow developers to use energy harvesting mechanisms on devices (from sensors to gateways) and easily connect them to the IBM Watson IoT cloud. The EnOcean protocol operates in the sub 1GHz band, as the ISO/IEC 14543-3-1X standard for building automation and smart homes worldwide. Energy harvesting devices such as the AAEON kinetic development kit take energy from the surrounding environment, including motion, light or temperature differences, to power the wireless modules. These modules employ a highly optimised telegram approach to keep the power consumption very low.

Combining hardware like the AAEON kinetic kit with the Watson secure APIs enables IBM’s Bluemix service to provide predictive, cognitive and contextual analytics for decision making. IBM takes this one step further, as it has a facility management platform called Tririga for building automation and all the data from the sensors can be automatically fed into this.

The EnOcean Alliance and IBM have standardised the IP packet interface and simplified the usage of applications in the IoT. This, for example, allows the integration of energy harvesting wireless technology into the IBM Watson IoT platform, so that predictive and real time analysis of facilities can be conducted. The cloud integration can be implemented at the operating system (OS) level as well. For example, MicroEJ’s hybrid C and Kava OS for developing IoT applications can add cloud connection to NXP’s ARM Cortex-M powered Kinetis microcontrollers.

The OS offers a full set of libraries for wired and wireless connectivity, IP-based networking, security, data storage, graphical user interfaces and software component management, through the Kinetis SDK. The OS can provide IoT-ready building blocks based on standard protocols - such as HTTPS REST, CoAP, MQTT or LWM2M - for enabling interoperability with IoT cloud platforms for data streaming and device management. It offers the capability to extend device functionality in the field and manage software content with more flexibility than Over-The-Air (OTA) firmware updates, as software apps can be dynamically installed and uninstalled on the fly.

There is also an app store for MicroEJ solutions where apps can be published by developers and downloaded by devices - as it is with mobile handsets. The company has shown the OS running on NXP’s MRTWR-K65F180M Kinetis K65 Tower System Module. MicroEJ OS can also supports the full family of Kinetis microcontrollers based on ARM Cortex-M0+/M4/M7 cores.

Conclusion
There are many different ways to link wireless devices into the cloud, but cloud providers - from Microsoft and SIGFOX to Amazon and IBM - are all working hard to make this as simple as possible. No longer is it necessary to combine security protocols with the MQTT packets that have specified IP addresses for hundreds or even thousands of IoT nodes. It also moves the IoT architecture choices forward by using each gateway as an aggregator of traffic rather than a security controller. This gives the designer more options in terms of the type of sensors that can be specified and how they subsequently connect to the IoT (for example, through existing wireless networks). While specific APIs for the cloud services have helped, chip makers have also added new devices to manage those connections and provide hardware security to simplify the roll out of IoT networks on a large scale.