Security framework for IoT devices

Security challenges continue to make headlines in the IoT – and no vertical market has been spared. Automotive security has been in the headlines recently, but lighting systems, white goods, home security devices, medical equipment, airplanes and industrial automation systems have all had their unfortunate turn in the cyber vulnerability spotlight.

With high profile cyber-attack headlines a weekly occurrence, companies are finally beginning to get serious about IoT security. Building a secure IoT device requires a solution crafted specifically for the types of threats these devices will be exposed to and, more importantly, designed to run on the specialized, low-cost hardware usually found powering IoT devices. IoT devices are by nature, highly connected and therefore provide broad attack surfaces for would-be hackers to exploit. To secure these devices, designers need a comprehensive security framework that provides enterprise-level security in these small devices.

Application layer attacks
In 2013, Security researcher Craig Heffner discovered a backdoor within the firmware found in a number of D-Link routers. The HTTP server in these routers included a backdoor that bypassed the standard authentication process. The web server examined the browser user agent, and if it matched “xmlset_roodkcableoj28840ybtide”, authentication checks were skipped. The string, read backwards, “edited by 04882 joel backdoor” showed that this was an intentionally planted backdoor. The backdoor provided access to the device's configuration capabilities.

In Australia, beginning in January 2000, Vitek Boden waged a three-month war against the SCADA (Supervisory Control and Data Acquisition) system of Maroochy Water Services, which resulted in millions of gallons of sewage spilled into waterways, hotel grounds and canals around the Sunshine Coast suburb. It is an interesting case study because not only did the perpetrator cause pumps to not run when they should have been, he also was able to prevent alarms from being reported, further complicating the problem. This example also shows the danger of insider attacks, as Boden was a former contractor of Maroochy Water Services.

Other widely reported exploitations of application layer services include attacks on web-enabled IP cameras and nanny cams, which have notoriously weak security. A quick google search will reveal multiple reports of successful attacks against web-based security cameras, nanny cams and IP cameras. These vulnerabilities allow unauthorized users to view the video streaming from the camera, allowing them to spy on whatever the camera is set to watch. Even worse, in some cases, they can even instruct the ”Camera On” light to not activate, leaving the victim with no indication that they are being spied upon.

System layer attacks
While application layer attacks are prominent in embedded devices, attacks against system layer services are also found. The Industrial Control Systems Cyber Emergency Response Team (ICS-CERT) issued an advisory regarding Wind River VxWorks TCP Predictability Vulnerability for Industrial Control Systems. Researches also discovered a remote code execution (RCE) vulnerability in VxWorks. These are both network-based vulnerabilities.

The now well publicized Chrysler Jeep Hack is another system level attack against an embedded device – this one involving reprogramming the firmware on a vehicle ECU to enable control of the vehicle over the network.

The Heartbleed bug is a vulnerability in the OpenSSL cryptographic libraries that are widely used in embedded devices. Mark Schloesser, a researcher at security firm Rapid7, says it's not clear how widespread similar problems might be, but believes it's safe to assume that “quite a few embedded devices use vulnerable library versions”. Given the typically long upgrade cycles for firmware in deployed embedded devices, it is likely that many vulnerable devices still exist in the field, even though a patch has been available since April of 2015.

Hackers will probe, and if possible exploit, any interface available on a device. Embedded devices are just as likely to be susceptible to common vulnerabilities resulting from buffer overflows and similar bugs as their enterprise counterparts. However, embedded devices differ from their enterprise brethren in that they are not typically located within the physically secure confines of a data center. As such, they are much more likely to be subject to physical attacks using USB ports, serial ports or even physically intrusive attacks where hackers attempt to read data directly from flash memory or even from communication buses during operation of the device.

Security features – a framework for device security
The first step towards IoT security is to ensure that security is built into the device itself. With the diverse nature and deployment of IoT devices, and the reality that security perimeters can and will be penetrated, it is no longer sufficient to rely on the device being deployed only within a secure network.

Next page >

There is no single one-size fits all security solution for embedded devices. Security requirements must take into consideration the cost of a security failure (economic, environmental, social, etc.), the likelihood of attack, available attack vectors, and the cost of implementing a security solution. The likelihood of attack is higher than you might think. [Studies utilizing ICS system honeypots have shown that Internet connected ICS devices are attacked within 24 hours of first being attached to the network. In our discussion with IoT gateway providers, we commonly hear reports of newly provisioned gateways being probed within 45 minutes of being connected to the Internet.]

Features that need to be considered are:

  • Secure boot & secure firmware updates
  • Secure communication
  • Data at rest protection
  • Embedded firewall & intrusion detection
  • Key and certificate management
  • Authentication
  • Integration with security management systems
    • Security policy management
    • Security event reporting

click for larger image

A security framework, such as the Floodgate Security Framework, provides an integrated suite of security building blocks.

Secure Communication
When most engineers think of security, they typically think of secure communication protocols such as SSL/TLS, SSH, and IPSec. While these protocols are a critical element of security they do not provide complete security. They only protect against protocol-specific attacks; to secure a device requires protection of all attack surfaces.

Security protocols provide protection against packet sniffing, man-in-the-middle attacks, replay attacks and, if strong authentication is used, unauthorized attempts to communicate with the device. Use of these protocols is common in IoT devices and is a must to build secure devices.

Small IoT edge devices are adopting wireless protocols such as ZigBee, Bluetooth Low Energy (BLE) and other wireless and mesh networking protocols. While these protocols have some built in security, it is relatively weak and exploits have been published. These devices typically run on very low cost, lower power processors that don’t support the security protocols commonly utilized in TCP/IP networks. Two options to increase security in these types of devices are DTLS, which is TLS over UDP, or to implement application level security. Application level channel encryption, the use of session tokens, and the use of packet sequence numbers provide important additional security measures to protect against common attacks.  Updates to these protocols, such as the BLE 4.2 privacy features, significantly improve the security of the underlying protocol. If these features are not yet support in the protocol solution being used, these application layer security features can still be used. Even if the protocol features are supported, these application security features still provide additional security and can be part of a defense-in-depth strategy.

Secure Boot and Secure Firmware Updates
Secure boot and secure firmware update capabilities are used to ensure that an IoT device is running authorized code from the device manufacturer. Properly implemented, this eliminates an entire class of vulnerabilities.

Secure boot ensures that hackers are unable to install malicious code on an IoT device

Secure boot begins with a first stage bootloader that is programmedinto a protected or non-writable storage location on the device. Thisfirst stage boot loader calculates the hash value of the second stageboot loader and verifies that the hash is correct by comparing it to astored, signed hash value for the boot loader or, depending on thearchitecture of the system, for the OS itself.

The second stage boot loader, which can be more complex and which canbe stored in reprogrammable flash memory, then repeats this process toverify that the operating system and applications are valid. If amonolithic RTOS is used, this is performed in a single step. In a devicesuch as Linux with separately loadable applications, this process canbe repeated to validate each application in the system before it isloaded. Once each layer is validated, it is then trusted and can proceedto validate the next high layer in the chain.

Secure boot relies on signed code images to enable validation of theimage during the secure boot process. The code images are signed by thedevice OEM using the OEM’s private key. The OEM’s corresponding publickey must be programmed into the device during manufacturing orprovisioning so that the device can validate the signature for thefirmware image using this key.

Secure firmware update, like secure boot, validates that new codeimages have been signed by the OEM during the upgrade process. Ifdownloaded images fail this validation process they are discarded andthe upgrade is not performed. Only images that pass this validationprocess are accepted and saved to the device. These new images arewritten to flash, replacing the previous image. The Heartbleedvulnerability described above, provides a compelling case study for theneed for secure remote firmware update. Without remote updatecapabilities, there would be no way to update these devices withoutsending a technician onsite, returning the device to the manufacturer,or requesting customers to upgrade the firmware on the device.

Data at Rest (DAR) Protection
IoT devices, unlike enterprise servers, are not locked away deep in adata center. Many are located “in the field” with the risk of theft orphysical attack. Any sensitive data stored on these devices should beencrypted to ensure it is protected from physical attacks or datathieves that attempt to read data from the flash drive of the device.

Data at Rest (DAR) protection is the encryption of sensitive data onthe device. Most IoT devices don’t have the computing power to supportfull disk encryption, but sensitive data can and should still beprotected. The specifics will vary from device to device, but data suchas credit card numbers or patient information should always beencrypted. Care must be taken to store the encryption key in protectedmemory on the device or in a secure location such as a USB drive ornetwork server.

The DAR solution should ensure that unencrypted data is never storedon the hard drive. Protected data should be encrypted before it iswritten to a file. Encrypted files should be encrypted in memory andremain in RAM, never written back to the file system without beingencrypted. This ensures data cannot be leaked due to a power failure.

Intrusion Detection
Most embedded devices lack basic security features, making them easy targets for hackers.  As a result, hackers have specifically targeted embedded devices, exploiting these weaknesses.  

Most cyber-attacks develop over time, beginning with hackers probing anetwork looking for, finding and exploiting a vulnerability, and thenleveraging the exploited device to move deeper into network.  The cyclethen repeats from this new beachhead.  Stopping these attacks beginswith detecting that they are happening.  Intrusion Detection Systems andIntrusion Detection Software (IDS) are commonplace in enterprisenetworks and PCs. IDS, as the name implies, detects when a system isunder attack or being probed.  These solutions can take many forms anddetect many different types of attacks, but regardless of form, are inthe main, largely absent for embedded devices.

Adding IDS capabilities to embedded devices is critical to provideearly warning of a cyber-attack. The ability to detect and reportpotentially malicious activity enables system’s administrators to takeaction to block attacks, quarantine compromised systems, and protecttheir networks. If embedded devices can support basic IDS they will nolonger be such easy targets for hackers.

Securing IoT devices against today’s cyber threats as well as futurethreats that will emerge during the lifetime of the device is a criticalchallenge for embedded developers. Low-end IoT devices require a customsolution, designed to meet the memory and performance requirements ofthese resource constrained environments. Windows and Linux basedsolutions are too big, power hungry and slow to support low-end IoTdevices. A security framework such as Icon Labs’ Floodgate SecurityFramework, integrated with the MCU, provides IoT developers with thetools needed to secure their devices.

Alan Grau is the President and cofounder of Icon Labs, a leading provider ofsecurity solutions for embedded devices. You can reach him at

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.