For IoT applications, attacks are a fact of life. Hackers and bots will inevitably find your system and probe it for weaknesses.
While every IoT application must protect against security threats, medical systems require extra attention given the sensitivity of patient data and the risks associated with equipment malfunction. Below are three key elements that should be part of any IoT security strategy, followed by a specific design example employing the Device Authority IoT Security Platform.
1. Onboarding and Authentication
An IoT application can involve numerous devices distributed over a large geography. For example, in a medical device application with new patients being added continuously, onboarding and provisioning of new IoT devices to the network must be controlled and secured.
Device authentication ensures that no unauthorized devices enter the circle of trust. It prevents data and commands exchanged between the IoT devices and the cloud application from being spoofed by an unauthorized entity. Any tampering with this communication link could seriously compromise the system. In the medical market, it could jeopardize patient safety.
But the exchange of security keys between IoT devices and the cloud server during the authentication process is a potential point of attack. Many client-server applications use asymmetric cryptography to handle authentication before sensitive data is exchanged. The public key used in this type of cryptography can be linked back to a user's identity. Figure 1 illustrates how the link between two secure endpoints could be a vulnerability.
In some IoT applications, such as medical devices, this is an issue because privacy of the transmitted data must be secured according to HIPAA regulations. A system that authenticates trusted devices without exchanging keys across the network eliminates both the potential security vulnerability and the privacy risk.
Figure 1. A good security strategy avoids the exchange of security keys between an IoT device and a cloud server, a critical attack point. (Source: Device Authority).
2. Policy-Based Encryption
IoT applications require encryption that is policy-driven based on specific data payloads and individual transmission recipients. For example, wearable sensors might not require any special encryption when connecting to a local health monitor, but this same data would require encryption when sending to a remote facility.
The security protocols between these can be differentiated based on the specific sender and receiver or other parameters. The ability to implement policy-based security protocols is an essential security strategy in balancing the need for access control with the objective of reducing the footprint, cost, and power of a processing element.
3. Secure Upgrades
The third key element that should be part of any IoT security strategy relates to device maintenance. A large-scale cloud IoT application requires a way to perform software and firmware upgrades to remote devices while ensuring that only trusted software is installed.
The system must be able to control access to devices for updates, verify the source of updates, and validate the integrity of the updates themselves. Validating trusted devices relates back to having a secure device authentication process.
Processing Power Sufficient for IoT Security
Cloud IoT application developers tackle these three security strategies listed above in a variety of ways. For example, the KeyScaler Platform by Device Authority manages policy-based encryption, secures software upgrades by enforcing trust, and uses a unique approach to device authentication. The KeyScaler Platform is lightweight and efficient; it was recently used in a medical application running on the Intel® Quark™ SE C1000 Microcontroller (formerly Atlas Peak).
The C1000 suits this application well, as it supports a 32-MHz, 32-bit processor with a floating-point unit. It has 8 kbytes of one-time programmable memory. The JTAG lock and read/write access controller can shut down unauthorized access to an on-die non-volatile memory.
With a low-power footprint, it is ideal for small IoT devices and supports an industrial temperature profile, allowing it to be used outdoors. Most important, it has the processing power required to execute security algorithms like the KeyScaler Platform algorithm for registering and authenticating devices.
The KeyScaler Platform eliminates the need to share or store keys on devices through a dynamic device authentication process. Matching keys are derived independently on the IoT device, running on the microcontroller and the KeyScaler cloud server.
Corporate enterprises currently use an analogous approach to authenticate laptop logins: The user is given an authentication code that they type in to confirm their identity. If the code matches what’s on the server, the laptop is authenticated.
Enhancing the Trust Anchor
Device Authority is also involved in Intel®'s Zero Touch Onboarding for IoT program, where “headless” devices can be powered on to locate and automatically onboard to IoT management platforms. This uses a technology called Intel® Enhanced Privacy ID (EPID), which is a fixed-device identity discoverable by software.
In this model, Device Authority will receive the anonymous device registration and EPID hardware identity and begin to manage the operational authentication lifecycle for the device. Together, these form a continuous hardware-enforced trust anchor from activation to operation. The combination of EPID hardware identity and Device Authority dynamic key technologies provide ongoing end-to-end operational security for IoT devices, enabling policy-driven access control and data protection for IoT applications and services.
As the IoT continues to grow, keeping applications safe from security breaches remains a top priority. Cloud applications will need to implement the three key elements of IoT security strategy described here to help resist attacks and stay one step ahead of the attackers.
About the Author
Eran Strod is a technology writer and marketing consultant. He started his career as an embedded software developer at CSPI – before VMS became Windows. In the era of the Intel i860, he moved into applications engineering at Alacron and served as a systems engineer at Motorola Computer Group specializing in storage and networking. After earning an MBA at Northeastern University, in the High Tech MBA program, Eran switched to product marketing, managing a 16-core network processor for Motorola Semiconductor. During that time he also led Motorola’s RapidIO initiative. Eran led marketing for the Defense Business of Mercury Computers and worked in open source governance for Black Duck Software. He managed a digital signal processing product family and software suite for Curtiss-Wright Embedded Computing and as a Director of Product Marketing led the marketing team at Atrenne Computing Solutions.Follow on Twitter More Content by Eran Strod