Icon Labs Considers Embedded IoT Security Solutions


Security vulnerabilities can result from implementation flaws, design flaws or failure to properly enable and use security features.

David West is the engineering director of Icon Labs, which is a provider of security solutions for embedded devices. He shared his thoughts regarding the IoT and security.

IoT Evolution: What are the challenges that developers might face when building IoT devices? Which of the emerging IoT standards should they adopt? How can they distinguish their products in this busy and competitive emerging field while meeting meet time-to-market challenges?

David West: Design engineers have a choice when considering security for their devices. It becomes another item on an already long list of challenges causing projects to bog down, or they can opt to jettison security requirements in favor of time to market. The result, not surprisingly, is a host of new devices hitting the market lacking adequate security.   

Examples of insecure devices abound, from medical devices with hard-coded passwords, home routers with exploitable back doors and home automation controllers with multiple security vulnerabilities. 

Security does not need to be an overwhelming challenge for IoT engineers.  By including a few basic security capabilities, they can develop IoT devices with essential security protection today, establishing a strong security foundation on which additional security features can be added in the future.

IoTE: What are some of the vulnerabilities that can present themselves in embedded devices?

DW: Before diving into the problem of securing IoT devices, it is important to consider the origin of security vulnerabilities, especially as related to embedded devices.  Broadly speaking, most vulnerabilities in embedded devices are divided into one of three broad categories: implementation vulnerabilities, design vulnerabilities, and deployment or use vulnerabilities. 

Deployment or use vulnerabilities relate to issues introduced by the user during the operation or installation of the device. Common examples include issues such as not changing default passwords, using weak passwords, not enabling security features, etc.

Implementation vulnerabilities occur when coding errors result in an exploitable weakness during a cyber-attack. The ubiquitous buffer overflow attack is the 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 Secure Software Development Lifecycle or Microsoft’s Security Development Lifecycle and thorough testing criteria help address implementation vulnerabilities. 

Design vulnerabilities are weaknesses resulting from a failure to include proper security measures when developing the device, and are the focus of this article. Examples of design vulnerabilities resulting in security breaches include use of hard-coded passwords, control interfaces with no user authentication, and use of communication protocols sending passwords and other sensitive information in the clear.  Other less glaring examples include devices without secure boot or allow unauthenticated remote firmware updates.

IoTE: What is a secure boot? How does the secure boot assist a device that has the capability?

DW: Secure boot utilizes cryptographic code signing techniques to ensure the device only executes code produced by the device OEM or other trusted party.  In a device with secure boot capability, the boot loader 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 load, ensuing only software from the OEM is allowed to execute.

IoTE: What does a secure firmware update offer?

DW: Secure firmware updates ensure 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, adding an additional layer of protection.

IoTE: Does IoT support remote and secure communication?

DW: 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 all communication is secured. TLS or IPSec should be used when possible. Application data encryption should be considered for wireless protocols such as ZigBee or BLE having encryption built into the protocol, but having known vulnerabilities.  Whenever possible, older, insecure protocols such as Modbus/TCP should be replaced with newer, secure protocols or encapsulated within secure protocols such as TLS.

IoTE: Does security protocols support data when it is at rest? What is the outcome from not protecting the device?

DW: Security protocols provide protection for data while it is being transmitted across networks, but does not protect the data while stored on the device. Large data breaches have resulted from data recovered off of stolen or discarded equipment. Engineers should consider encrypting any sensitive data stored on the device.

IoTE: What about user authentication? Are passwords still useful?

DW: Passwords are still the default solution for user authentication on many devices. Assuming strong passwords are enforced by the device, it is still a reasonable choice. Depending upon the nature of the device and the interfaces available, two-factor, biometric or token-based authentication may be a better choice. No matter the mechanism used, it is critical all users are authenticated before they are allowed to control the device.

For devices allowing remote access over a network, secure remote authentication is an absolute requirement. Ideally, a protocol utilizing certificate based authentication, such as TLS or SSH should be used.

IoTE: Is Public Key Infrastructure (PKI) beneficial for the IoT?

DW: For the IoT, mutual authentication is mandatory, but IT’s methodology is unusable. When devices communicate, they must each validate each other using certificates.  Implemented correctly, no human interaction is required and using certificates eliminates the inherent problems of password-based authentication and other weak authentication mechanisms. Digital certificates, used in this fashion, provide strong authentication. Devices reliably authenticate other legitimate devices, preventing unauthorized communication with rogue devices or other unauthorized systems.

Mutual authentication, as the name implies, requires every device to have a certificate. The manual processes of legacy PKI (IT) solutions don’t scale to the needs and massive numbers of the IoT.

Solutions automating PKI will include a compact Certificate Authority server and device-side SCEP/EST clients.  It’s fully automated process allows devices to securely request new certificates, validate certificates, and recognize when certificates are revoked. It also implements certificate chaining support to ensure all certificates are properly validated. 

Additionally, it manages certificates over the entire lifecycle of the device. It starts with provisioning certificates into the device during manufacturing to prevent counterfeiting and cloning. When devices are purchased and installed on a network, they go through a process of provisioning. During provisioning, 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. 

IoTE: Is security a requirement for all IoT devices? Can the capabilities be helpful to the security of your IoT devices?

DW: Security is a requirement 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.

Edited by Ken Briodagh
Get stories like this delivered straight to your inbox. [Free eNews Subscription]
Related Articles

FOSSA's Recent €6.3M Series A Round to Grow its IoT Satellite Constellation

By: Greg Tavarez    6/20/2024

FOSSA raised a €6.3M Series A round to grow its IoT satellite constellation focused on remote asset management for industrial use cases.

Read More

iVALT Builds Upon IoT Security Measures and Smarter Device Management

By: Alex Passett    6/18/2024

iVALT is looking to stake its claim as a top provider of identity security solutions, and IoT is just one area it can provide support for.

Read More

Accelerating Greatness in IoT: Soracom Officially Joins the AWS ISV Accelerate Program

By: Alex Passett    6/18/2024

Official as of this morning, Soracom Inc. - a provider of advanced IoT solutions on a global scale - announced that it has joined the AWS ISV Accelera…

Read More

Extending the 'Reach' for Powering In-Flight Drones, Courtesy of Engineers at Reach

By: Alex Passett    6/17/2024

"Wireless Power-at-a-Distance" solutions provider Reach has successfully demonstrated how a unified mesh network and wireless power transfer (WPT) sys…

Read More

New Wi-Fi 6 Module from Ezurio will Tackle Greater Connectivity for IIoT Applications

By: Alex Passett    6/17/2024

Ezurio (i.e. the rebranded name of the company known formerly as Laird Connectivity) has announced a new addition to its portfolio of Wi-Fi 6 modules:…

Read More