Posted by Mark Shapiro

By David West, Director of Professional Services at Icon Labs

Most IoT devices are price-sensitive and deployed outside of a secure perimeter with a very long lifecycle. Unfortunately, in most real world cases though, cost, more than other factors like quality of protection and ease of use, drives security component selection.

When choosing between hardware or software, the foremost solution is to build security into the device and not depend upon the perimeter.

Typically, on-device hardware security may be more effective but at a greater cost than a software solution.

Hardware Security

Likely candidates for hardware solutions include PUF (Physically Unclonable Functions), TPM (Trusted Platform Module), and TrustZone. 

PUF uses random patterns in the silicon to differentiate chips from each other and creates a unique random number. This generated random number is used to seed a strong device ID and cryptographic keys to create a hardware root of trust.

Security co-processors are physically separate chips offering true isolation of private keys. A TPM offers isolation and facilities for the secure generation of cryptographic keys, and limitation of their use, and true random number generation. It also includes capabilities such as remote attestation and sealed storage. However, these powerful security capabilities come at price, usually moving deployment to higher end IoT devices. 

A Hardware Security Module (HSM) is another physically separate chip and likely at a lower cost compared to a TPM. Like the TPM, it safeguards and manages digital keys for strong authentication and provides crypto processing. An HSM traditionally comes in the form of a large plug-in card or a separate external device attaching to the protected device, making it somewhat less suited to an IoT device. Depending upon the perceived and likely threat vectors, an HSM may provide an effective solution.

Trust Zone is another single chip solution segregating execution space into secure and insecure worlds. Insecure apps are not allowed to access security-critical assets. Those same security critical assets are isolated from tampering. Like a TPM, cost moves it to higher-end devices.

Software Security

Compared to hardware, software security provides a layer of protection at a much lower cost while offering a broader range of options. Addressing basic security needs like an embedded firewall, secure boot, and PKI-based authentication can cost-effectively protect the device from attacks originating from both inside and outside the local area network.

Frequent candidates for software security include a firewall blocking unwanted packet and providing intrusion detection, TLS/SSH for secure communication, secure boot, and PKI-based authentication. In certain designs, software may consume more power compared to hardware solutions

Embedded software firewalls provide a critical layer of protection against attacks.  A firewall limits communication to only known, trusted hosts, blocking hackers before they can even launch an attack. 

Most cyber-attacks develop over time, beginning with hackers probing a network; finding and exploiting a vulnerability, then leveraging the exploited device to move deeper into network.  The cycle then repeats from this new beachhead. 

Stopping the attack before it starts begins with detecting the attack is happening.  Intrusion Detection Systems and Intrusion Detection Software (IDS) are commonplace in enterprise networks and PCs. IDS, as the name implies, detects when a system is under attack or being probed.  

Adding IDS capabilities to embedded devices is critical to provide early warning of a cyber-attack. The ability to detect and report potentially malicious activity enables system administrators to block attacks, quarantine compromised systems, and protect their networks. If embedded devices can support basic IDS they will no longer be such easy targets for hackers.

When most engineers consider 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, but a secure 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 an absolute component of secure devices. 

Many small IoT edge devices communicate using 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 are recognized.  These devices typically run on very low cost, lower power processors not supporting the security protocols common in TCP/IP networks. 

Two options to increase security in these types of devices are DTLS, (TLS over UDP) or implementing 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 supported in the intended protocol, the application layer security features can still be used.  Even if the protocol features are supported, the application security features still provide additional security and can be part of a defense-in-depth strategy.

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

Figure 1: Secure boot ensures hackers are unable to install malicious code on an IoT device

Secure boot begins with a first stage bootloader programmed into a protected or non-writable storage location on the device. The first stage bootloader calculates the hash value of the second stage bootloader and verifies the hash is correct by comparing it to a stored, signed hash value for the bootloader or, depending on the system architecture, for the OS itself. 

The second stage bootloader, which can be more complex and may be stored in reprogrammable flash memory, repeats this process verifying the operating system and applications are valid.  If a monolithic RTOS is used, this is performed in a single step. In a Linux device with separately loadable applications, the process can be repeated to validate each application in the system before loading.  Once each layer is validated, it is trusted and can proceed to validate the next high layer in the chain.

Secure boot relies on signed code images to enable validation of the image during the boot process.  The images are signed by the device OEM using their private key.  The OEM’s corresponding public key must be programmed into the device during manufacturing or provisioning so the device can validate the signature for the firmware image using this key. 

Secure firmware update, like secure boot, validates new code images were signed by the OEM during the upgrade process.  If downloaded images fail the validation process, they are discarded and the upgrade is not performed.  Only images passing validation are accepted and saved to the device.  The new images are written to flash, replacing the previous image.   The Heartbleed vulnerability (https://en.wikipedia.org/wiki/Heartbleed) provides a compelling case study for secure remote firmware update.  Without remote update capabilities, there is no way to update the devices without sending a technician onsite, returning the device to the manufacturer, or requesting customers to upgrade the firmware on the device.

A well-known and tested security solution has recently seen a dramatic rebirth in the IoT recently. PKI (Public Key Infrastructure) is a set of technologies and services for managing authentication of computer systems.  PKI certificates are very useful in high security situations. For example, suppose that you needed to securely transmit data between two networked devices. How do you really know you are transmitting the data to the intended device and not to an imposter? One way of ensuring the integrity of the transaction is to use digital certificates to prove the identities of both machines. Without getting into the details of the public/private key cryptography technology that makes this possible, an IIoT device can verify the certificate holder is the entity specified by the certificate.  These services are enabled using public/private key cryptography providing the technical underpinnings of PKI.  The result, which is what really matters, is a device can verify, with cryptographic certainty, the holder of the PKI certificate is really who it claims to be and not an imposter.  

Conclusion

Ultimately, some combination of hardware and software may be required. Building protection into the device itself provides a critical security layer whatever options are used. Security must be considered early in the design of a new device or system.  Support for secure boot or device tamper detection requires specific hardware capabilities, so this capability must be considered prior to that decision.  Since many embedded devices are deployed outside of the standard enterprise security perimeter, it is critical that security be included in the device itself.  Only the system designer will be able to make that determination based upon costs and likely attack vectors.

David West is the Director of Professional Services at Icon Labs, a leading provider of security solutions for embedded devices.  You can reach him at david.west@iconlabs.com