IoT on the Edge – pushing the cloud to the fog

It is broadly agreed that there is not enough Cloud out there to connect all the IoT devices. In the same time the cost pressure on the IoT solutions are pushing the Cloud to the Edge. Not all devices should include a radio and IP stack to connect to Internet or to require Internet to be available nearby. The move to the Edge provides intrinsic value to the IoT product providers: ability to run logic and thus “act” faster locally, and unconnected operation and dollar savings on cloud resources (by deflecting sensor data flow and cloud functions to the Edge gateways).

The Edge gateway is the core element in what is named today the Edge or Fog computing. As the name suggests, it provides gateway functions – it connects sensors/nodes on one end with bidirectional communication, provides one or multiple local functions and extends bi-directional communications to the cloud. An Edge gateway can host multiple applications from different customers.

Cloud IoT providers are already making a big push towards empowering the Edge concept - first Amazon launched the Greengrass then Microsoft announced the private preview of the Azure IoT Edge. The goal is to make it very easy to develop, deploy and maintain services running on the Edge gateways. The move is to enable modern micro services development and deployment practices for the Edge gateways via docker containers or similar technology. This will extend dev ops practices to Edge computing and empower IoT deployments at scale.

In a smart building example, a service integrator would install hundreds of sensors and actuators to implement energy management, parking control, security monitoring, surveillance etc. One or several edge gateways per floor will connect and control the sensors/actuators and perform localized tasks. The Edge gateways are connected to the Cloud via the Internet and process/proxy data, status, insights and remote controller functions back and forth. Developing the specific purpose functions, provisioning the deployment configurations, deploying and managing the sensor connectivity and functions is a very difficult task with such large instances. But if instead the functionality is constructed from smaller building blocks and deployed/orchestrated remotely using containers via easy to use cloud tools then an entire building can become operational in minutes. Deployment scenarios can be developed and tested in advance, and deployed and updated easily. This model is applicable to all IoT verticals – Smart Cities, Connected Manufacturing, Smart Farming, Industrial IoT, etc. Customers will pay for using the high value AI, machine learning, analytics, etc., and will use them in the Cloud and on the Edge.

The main differentiating factor for the Edge IoT providers will be the security assets included in their solutions and the overall security framework their design will require. The Edge is designed to perform functions that today are only supported in the cloud under a controlled environment. It is reasonable to expect that the Edge gateways will be subjected to insecure/hostile conditions. These will be physically reachable and open to a wide range of attacks. It is the Edge IoT Cloud provider’s responsibility to provide a security framework model and proper requirements for securing the Edge. If your Cloud provider thinks differently, walk away!

There are two main components that a secure Edge gateway needs to address. Fundamentally it must implement a secure software platform framework that includes trusted boot, secure key material storage and a trusted execution environment that isolates the cryptographic operations, key material handling and critical functions from the operating system. Secondly the Cloud IoT Edge components (i.e. Greengrass, Azure IoT Edge etc) need to be built on top of the secure gateway platform and utilize the fundamental security features to protect themselves and to extend the security capabilities to the customers’ applications. For example if the Edge gateway connects to the Cloud via TLS then the Cloud Device SDK supplied by the Cloud provider should use the cryptography and the key material provided by the Trusted Execution Environment. Similarly using the same secure platform, the Cloud Edge modules and the OS kernel should be protected at run-time and at rest through run-time integrity check monitoring (preferably hardware based) and secure storage. All functions pertaining to the monitoring and remediation must be implemented outside the reach of the normal OS. Hardware enforced isolation such as TrustZone/TEE must become a requirement for the Edge.

In the containerized development approach it is also very important that customers deploying applications be able to utilize the platform security features inside the container framework.

Performing secure functions such as data signing, signature verification, encryption/decryption, command validation, secure leaf node onboarding and protection of high IP software assets within containers are very important use cases for the Edge customers. Microsoft has recently announced Azure Confidential computing. We will see the same paradigm pushed to the Edge.

Security is becoming the most talked about aspect of the future of IoT. The IoT Edge is introducing a new level of complexity in this realm. I believe the effort to extend the Cloud IoT to the Edge will be expensive enough to cause a lot of Cloud IoT PaaS providers to end their services and close the shop in the coming years. Streamlining security, onboarding, role delegation, introducing container orchestration for resource-constrained devices (mostly embedded ARM ecosystems) will be the key foremost challenges for Cloud IoT players and providers in the immediate future.

Azure IoT Edge Private Preview demo video (Sequitur Labs, IoT Solutions World Congress, Barcelona, October 2017)