Developers building IoT sensor devices face a host of challenges and decisions. Which of the emerging IoT standards should they embrace? How can they distinguish their products in this competitive emerging field? How can they meet time-to-market challenges? Which IoT protocols should be utilized?
With these challenges, security can become an afterthought. As a result, examples of insecure devices abound, from medical devices with hard-coded passwords to home routers with backdoors. Smart home devices, including easily hacked baby monitors, smart light bulbs that leak WiFi passwords and network-connected thermostats, have proven to be particularly vulnerable to attack.
Security need not be an overwhelming challenge. By including a few basic security capabilities, developers can create IoT devices with essential security protections, while establishing a strong security foundation on which additional security features can be added in the future.
Vulnerabilities in Embedded Devices
Before considering how to secure IoT sensors and devices, it is important to consider the origin of security vulnerabilities, especially as related to embedded devices. Most vulnerabilities in embedded devices can be divided into one of three categories:
- Implementation vulnerabilities
- Design vulnerabilities
- Deployment vulnerabilities
Deployment vulnerabilities relate to issues introduced by the user during the operation or installation of the device. These include not changing default passwords, using weak passwords, not enabling security features, and similar errors. California and other jurisdictions have enacted legislation requiring IoT devices to utilize unique passwords, which is an important first step to addressing this specific issue.
Implementation vulnerabilities occur when coding errors result in a weakness that can be exploited during a cyber-attack. Buffer overflow attacks are the classic example of implementation vulnerabilities. Another common error is improperly seeding random number generators, resulting in security keys that are easy to guess. Adherence to software development processes such as the OWASP Secure Software Development Lifecycle or Microsoft’s Security Development Lifecycle, along with thorough testing processes, help to remedy implementation vulnerabilities.
Design vulnerabilities are weaknesses that result from a failure to include proper security measures when developing the device. Examples of design vulnerabilities include use of hard-coded passwords, control interfaces with no user authentication, and use of communication protocols that send passwords and other sensitive information in the clear. Other less glaring examples include devices without secure boot, which allow unauthenticated remote firmware updates, or that include “back doors” intended for allowing remote access for debugging and maintenance of the device.
Security vulnerabilities result from implementation flaws, design flaws, or failure to properly enable and use security features.
Security Considerations for IoT Sensors
Security is critical for all IoT devices, and sensor devices are no exception. Sensors play a critical role in IoT solutions, collecting the data that drives the entire solution. Ensuring the integrity of IoT data is crucial.
Building security into sensors presents a unique challenge. Cost is often paramount in designing sensor devices, and in the effort to save costs, the underlying hardware often lacks built-in security features found in higher-end platforms. While these devices are resource-constrained, critical security capabilities can still be included, although trade offs may need to be made. For example, sensors may be able to support encryption, but may only support shorter key lengths than higher-end platforms. The resulting encryption is easier to break, but it may not be critical that this data is susceptible to brute force attacks. Because, by the time the data is decrypted, it has already been used by the IoT system and is no longer valuable.
Secure boot utilizes cryptographic code signing techniques to ensure the device only executes code that was produced by the device OEM or other trusted party. In a device with secure boot capability, the bootloader computes a cryptographically secure hash on the firmware image prior to loading the image. This 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 load, ensuring that only software from the OEM is allowed to execute.
Secure Firmware Update
Secure firmware updates ensure that device firmware can be updated, but only with firmware from the device OEM or other trusted party. Like secure boot, cryptographically secure hash validation is used to verify 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, thereby adding an additional layer of protection.
IoT devices, by definition, will support remote communication with other devices. The communication mechanisms will vary by device but may include wireless protocols ranging from BLE and ZigBee to WiFi, cellular data and Ethernet. Regardless of the transport mechanism and communication protocol, it is important to ensure that all communication is secured. TLS or DTLS should be used when possible. Application data encryption should be considered for wireless protocols such as ZigBee or BLE, which have encryption built into the protocol, but also have known vulnerabilities.
Security protocols provide protection for data while it is being transmitted across networks but does not protect the data while it is stored on the device. Large data breaches have resulted from data recovered from stolen or discarded equipment. Engineers should consider encrypting any sensitive data stored on the device.
Secure Gateways and IoT Edge Devices
In additional to building security capabilities into sensor devices, the security of the overall network must be addressed. IoT sensors often communicate with a gateway or edge device that performs data collection or analysis. The gateway or edge device must provide high levels of security, both for itself and to provide protection for the sensors to which it collects data.
Security is a requirement for all IoT devices, no matter how small or seemingly insignificant. By adding a few basic capabilities, including secure boot, secure firmware update, secure communication, data protection, and user authentication, the security of any device can be significantly increased.
A comprehensive security analysis can identify attack vectors and prioritize security requirements. Engineers can use this information to prioritize development of security features. Only by including security into the devices themselves can we ensure that IoT connected sensors and sensing systems will be protected from cyberattacks.
More info at https://sectigo.com/
About Sectigo - Sectigo provides award-winning purpose-built and automated PKI management solutions to secure websites, connected devices, applications, and digital identities. As the largest commercial Certificate Authority, trusted by enterprises globally for more than 20 years, and more than 100 million SSL certificates issued in over 200 countries, Sectigo has the proven performance and experience to meet the growing needs of securing today’s digital landscape. For more information, visit www.sectigo.com.
Alan Grau has 30 years of experience in telecommunications and the embedded software marketplace. He is VP of IoT/Embedded Solutions at Sectigo, the world’s largest commercial Certificate Authority and provider of purpose-built, automated PKI solutions. Alan joined Sectigo in May 2019 as part of the company’s acquisition of Icon Labs, a leading provider of security software for IoT and embedded devices, where he was CTO and co-founder, as well as the architect of Icon Labs' award-winning Floodgate Firewall. He is a frequent industry speaker and blogger and holds multiple patents related to telecommunication and security.
Prior to founding Icon Labs, Alan worked for AT&T Bell Labs and Motorola. He has an MS in computer science from Northwestern University.