Companies manufacturing IoT devices recognize the growing threat of cyberattacks and the need to build security into their devices. These IoT and IIOT (Industrial IoT) devices range from small, battery-operated wireless sensors to sophisticated gateways and controls. There is a large variety of devices, and many are resource-constrained in that they have limited memory and computing power.
Although some IoT devices use standard Windows or Linux computing platforms, most are built on specialized hardware and a real-time operating system. But they all face a host of similar security challenges. All IoT devices must securely communicate with cloud systems, gateways, and other IoT devices. They must also be able to encrypt sensitive and private data they collect, and all must be hardened against cyberattacks.
Furthermore, system and network operators must be able to identify devices they install on their networks. It is critical to ensure a device is authentic before letting it be provisioned into an IoT solution or to communicate on an IoT network. Without some sort of verification, the threat of rogue and counterfeit devices remains unchecked.
For many over-burdened engineers and developers, security becomes just another item on an already long list of challenges bogging down projects. In many cases, engineers opt to jettison security requirements in favor of time to market. Not surprisingly, the result is a host of new devices hitting the market with inadequate security. For example, there are medical devices with hard-coded passwords, home routers with exploitable backdoors, and critical infrastructure controllers with a host of security vulnerabilities.
Security, however, does not need to be an overwhelming challenge for IoT engineers. By including a few basic security capabilities, IoT developers can ensure devices have essential security protection while also establishing a strong security foundation for adding security features down the road.
Device Identity in IoT security
Device identity plays two critical roles in the security of IoT devices and networks. First, device identity protects against the introduction of counterfeit devices into the network. Second, it enables strong authentication, a cornerstone of secure communication.
Protecting against counterfeits. Ensuring the authenticity of devices in an IoT network is paramount to the security of the overall IoT system. Rogue and counterfeit devices pose a serious threat to its operation.
Furthermore, counterfeiting electronic products is big business and these knockoff devices hurt the bottom line for OEMs. Counterfeiters will duplicate a device with shoddy materials and get it on the market by using a copy of the original manufacturer’s logo, as well as copies of certification-agency logos. OEM suffers loss in sales as well as damage to their reputations if counterfeit devices fail in the field. Outright counterfeiter production is not the only risk; there is also risk of overproduction from untrusted manufacturing facilities.
Beyond damage to revenues and brand reputation, counterfeit devices also pose a security risk. If a device is not genuine, its behavior is unknown. Fraudsters may build and sell counterfeited devices simply for money. But they may also develop counterfeit devices with nefarious intents. The device could be designed to steal data, interrupt operations of a critical system causing physical harm, or remotely disable a system as part of a ransomware attack.
If the device is not genuine, manufacturers and end users don’t know what it is doing and are not even aware it cannot be trusted. Properly implemented device identity solves this problem.
Secure authenticated communication. Communications using secure protocols is a fundamental requirement for protecting the IoT. Security protocols ensure data and commands exchanged are encrypted and cannot be intercepted, spoofed, or manipulated. These protocols use strong authentication to protect against control commands sent to IoT devices from unauthorized devices. But communications are only secure if you know who you are communicating with.
The most common security protocols for protecting Ethernet-based communication in IoT devices are TSL (SSL; transport layer security, which replaced the older secure socket layer), DTLS (datagram transport layer security), and SSH (secure shell). TLS is available for most embedded platforms, and the security protocol is the most widely used and well-understood. When devices communicate using these protocols, they first authenticate each other before sharing commands or data. They handle authentication by using certificates to validate the other party’s identity.
Establishing strong device identity. A strong device identity is necessary for secure communications and protection from counterfeit devices. Certificate-based authentication using PKI (public key infrastructure) is a proven, scalable way to set up a device identity across a wide range of domains and is well-suited for IoT.
Certificate issuance and management can be automated, eliminating manual processes and minimizing errors. Certificates eliminate the inherent problems of password-based authentication and other weak authentication mechanisms. Used this way, digital certificates give users strong and effective authentication. Devices also reliably authenticate other legitimate devices, preventing unauthorized communication with rogue devices and unauthorized systems.
If the device does not have a valid certificate, it is not allowed onto the network. Although counterfeiters might steal device firmware to make cloned devices, they cannot duplicate valid certificates. Certificates are unique to each device signed by a Certificate Authority (CA). Counterfeiters cannot access the CA or duplicate the PKI system to generate certificates. Manufacturers who use certificate-based authentication with a properly implemented PKI system will stop counterfeiters from being able to pass off their devices as genuine.
Automated certificate issuance and management are critical to handle the large number of IoT communications and devices. Methods of automating PKI will include a CA server supporting enrollment protocols and device-side SCEP/EST (simple certificate enrollment protocol and enrollment over secure transport) clients. Together, these elements can be used to build a fully automated process that lets devices securely request new certificates, validate certificates, and recognize when certificates are revoked. Automating CA also puts in place certificate chaining support to ensure all certificates are properly validated.
Strong device identity starts by securely putting certificates into the device during manufacturing and then actively managing the certificates through the entire life of the device.
Automating CA also manages certificates over the entire lifecycle of the device. The process starts with putting certificates into the device during manufacturing to prevent counterfeiting and cloning. When devices are purchased and installed on a network, they go through an onboarding process. During onboarding, they are first automatically validated using the certificate installed during manufacturing, then issued a new certificate for use on the network. The certificate can later be revoked when the device is decommissioned.
If the device lacks a valid certificate, it is not allowed onto the network. Although counterfeiters steal device firmware to make cloned devices, they are cannot duplicate certificates. Certificates are unique to each device and counterfeiters cannot access the CA or duplicate the PKI system to generate certificates. Without the PKI, they can’t pass off their devices as genuine.
Device Hardening
Before diving into the problem of securing IoT devices, it is important to consider the origin of security vulnerabilities, especially for embedded devices. Broadly speaking, most weaknesses in embedded devices can be divided into three broad categories: deployment or use vulnerabilities, implementation vulnerabilities, and design vulnerabilities.
Deployment or use vulnerabilities relate to issues introduced by the user while operating or installing the device. Common examples include not changing default passwords, using weak passwords, and not enabling security features. While it is a critical topic, this article will not be addressing it.
Implementation vulnerabilities appear when coding errors create an exploitable weakness during a cyber-attack. The ubiquitous buffer overflow attack is a classic example of implementation vulnerabilities. Other examples include improperly seeding random number generators resulting in the generation of easy-to-guess security keys. Adherence to software development processes such as the OWASP’s (open web application security project) Secure Software Development Lifecycle or Microsoft’s Security Development Lifecycle, and thorough security testing criteria can help recognize and resolve implementation vulnerabilities.
Design vulnerabilities stem from a failure to include proper security measures when developing the device. Examples include using hard-coded passwords, control interfaces with no user authentication, and using communication protocols that send passwords and other sensitive information in the clear. Less glaring examples might be devices without secure booting or that allow unauthenticated remote firmware updates.
Security vulnerabilities stem from implementation flaws, design flaws, or failure to properly install and use security features.
Secure booting uses cryptographic code signing techniques to ensure the device only executes code generated by the device’s OEM or other trusted party. In devices with secure booty, the bootloader computes a cryptographically secure hash on the firmware image prior to loading the image. The hash value is compared with a stored hash value to ensure the image is authentic. Public key signing of the stored hash value prevents malicious third parties from spoofing the software and ensures only software from the OEM will execute.
Boot ensures only approved and authorized software is installed and executed.
Secure firmware updates ensure that when device firmware is updated, it is with firmware from the device OEM or another trusted party. Like secure boot, cryptographically secure hash validation verifies the firmware before it is stored on the device. In addition, machine-to-machine authentication methods can be used by the IoT device to authenticate the upgrade server before downloading the new firmware image, adding an additional layer of protection.
IoT devices, by definition, support communication with other devices. The communication mechanisms vary by device but may include wireless protocols ranging from BLE and ZigBee to Wi-Fi, cellular data, and Ethernet. Regardless of the transport mechanism and communication protocol, it is important to ensure all communications are secured. TLS—or for resource-limited devices, DTLS—is frequently used.
Application data encryption should be considered for wireless protocols. ZigBee or BLE might have encryption built into the protocol, but it has known vulnerabilities. Whenever possible, older, insecure protocols such as Modbus/TCP should be replaced with newer, more-secure protocols or encapsulated within secure protocols such as TLS.
Many new IoT platforms include a TPM (trusted platform module) or other hardware providing secure key storage, protected memory regions, and cryptographic acceleration. These elements are building blocks for securing the device and require a security framework to allow easy integration and enable high levels of security, but they are not a silver bullet for device security. Likely candidates for hardware security module support include PUFs (physically unclonable functions), security coprocessors such as TPMs, and trusted execution environments such as ARM’s TrustZone.
PUFs use random patterns in the silicon to differentiate chips from each other and creates a unique random number. The random number is used to seed a strong device ID and cryptographic keys, thereby creating a hardware root of trust.
Security co-processors are physically separate chips offering true isolation of private keys. Isolation of the private key prevents them from being discovered even if a hacker compromises the IoT device’s main processor.
A TPM is an industry-standard-based security chip that securely generates cryptographic keys using true random number generation. It also performs cryptographic functions using those keys on the chip. However, TPMs’ powerful capabilities come at a price; they usually require higher-end IoT devices.
Hardware-based secure key storage provides basic TPM/Secure Element access and services, as well as an easy to use library for embedded devices.
Many chip vendors provide hardware secure elements, another physically separate chip that safeguards and manages digital keys for strong authentication and crypto processing. Many of these elements cost less than TPMs and are therefore well-suited for cost-sensitive IoT devices.
Trust Zone, on the other hand, is a single-chip solution that segregates execution space into secure and insecure worlds, ensuring that insecure apps can’t access security-critical assets. Those same security assets are isolated from tampering.
For devices lacking hardware that protects stored keys, a method of protecting private keys is still required. A software-based storage approach can be used in these situations. This provides an alternative to storing private keys in a file that can be discovered, or from hardcoding keys into the firmware.
Security protocols protect data while it is transmitted across networks, but not while it is stored on the device. Many large data breaches have resulted from data recovered from stolen or discarded equipment. Engineers should encrypt any sensitive data stored on the device.
Passwords are still the default authentication method on many devices. Assuming default passwords are not allowed and strong passwords are enforced by the device, it is still a reasonable choice. Depending on the nature of the device and the interfaces available, two-factor, biometric, or authentication using an RFID or USB card (token authentication) are better choices. Two-factor authentication relies on a password plus a second authentication method, often an authentication code sent via text message. Biometric authentication identifies the user based on some unique physical characteristic such as fingerprint or retinal scan. No matter the mechanism used, it is critical all users are authenticated before they can control the device.
For devices allowing remote access over a network, secure remote authentication is an absolute requirement. As discussed earlier, organizations should use protocols with certificate-based authentication, such as TLS or SSH.
Security is required for all IoT devices, no matter how small or seemingly insignificant. By adding a few basic capabilities, the security of any device can be significantly increased. Strong device identity, using PKI and certificates, is critical.
Alan Grau is vice president of IoT, embedded solutions at Sectigo. For more information, visit www.sectigo.com.
