Security” used to mean worrying about HTTPS certificates on your websites. The notion of a “device” was a browser and all you really had to do was to guarantee that traffic between it and your web servers was encrypted.
Then the “bring your own device” (BYOD) phenomenon caused system administrators to worry about things like isolating WiFi traffic for visitors and providing VPN tunneling software of iOS and Android, so that employees could access corporate assets in the palms of their hands. “Device” then meant “smartphone.”
But now, “device” means something different. Manufacturing equipment, plane engines and even parking meters all qualify. Devices seem to outnumber people, reminding us why we need IPv6. But this new notion of “device” also requires a very different security model unless you want to fall victim to a hacker because you forgot to secure every thermostat in your building.
Building Multiple Security Levels on top of HTTPS
Different vendors address this more complex security model in different ways, but generally speaking, it has three components to it: Authorization Engine, Handshake Certificates and HTTPS.
HTTPS is still the underlying technology for encrypting traffic, but unlike the old days of web surfing (when we used to argue about the length of the keys), modern device traffic puts two layers on top of that base encryption. First, there is a set of certificate handshakes that makes sure that some cloud entity should be talking to the device in question. On top of that is typically a cloud-driven authorization engine that can confirm or deny specific instructions to the device.
An Example: AWS Greengrass
As a concrete example, let’s take a closer look at how Amazon does this for Greengrass, their local Function-as-a-Service offering so that devices can talk to a local core compute service.
The system starts with the Greengrass service on the AWS Console. There, a system administrator defines a Greengrass Group, within which a local Greengrass Core system (typically a local virtual machine), is configured to the on-site eyes and ears. Individual devices, whether they be sensors or actuators of some kind or something else entirely, get configured inside the group as well.
As the diagram shows, all communication throughout the system is performed over HTTPS or MQTT where traffic is encrypted. Core Device (B) and Core Root CA (A) certificates get installed on the Core, as well as Device Certificates (C) on the individual devices. This facilitates the handshaking between points of the system to further authenticate valid communication. On top of that, the Greengrass Service Role (A) and the Group Role (D) provide authorization rules for various requests that pass the first two thresholds.
To breach this system, someone would not only have to decrypt the traffic but also spoof the certificates between the right two components, and even then would be limited to executing functionality limited by the authorization roles.
Traditional security schemes do not handle the scale of devices that dramatically outnumber people connected to a network nor the sophistication of the modern hacker. A modern device communication mechanism has three layers of protection. Not only does a hacker have to beat the encrypted traffic over HTTPS, but they also have to get their hands on the handshake certificates and get inside the cloud console to spoof the authorization engine. This not only scales better than traditional approaches, but makes it much more difficult for an intruder to cause havoc.
Latest posts by Pete Johnson
- Connected Devices, Remote Security: Data Encryption and Security in the Cloud - January 2, 2018
- Application-Defined Networking Basics: Definitions and reasons to think ADN vs. alternatives - December 8, 2017
- Cloud, Agile and What Startups Can Teach the Enterprise - November 15, 2017