Menu

IoT FEATURE NEWS

Icon Labs Considers Embedded IoT Security Solutions

By Chrissie Cluney October 11, 2017

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
SHARE THIS ARTICLE
Related Articles

Zentera's Lee Emphasizes Importance of Shared Responsibility

By: Paula Bernier    12/15/2017

Zentera leader, IoT Evolution Expo speaker, discusses enclaves, IoT security, and the company's Internet of Things work with GM.

Read More

IoT Time Podcast S.2 Ep. 57 Unisys

By: Ken Briodagh    12/13/2017

In this episode of IoT Time, Ken Briodagh sits down with Bill Searcy, VP, Global Justice, Law Enforcement, and Border Security, Unisys (unisys.com/saf…

Read More

Canadian Municipalities Get Funding for 72 Infrastructure Improvements

By: Ken Briodagh    12/13/2017

The Canadian Infrastructure and Communities ministry and the Federation of Canadian Municipalities have announced funding for 72 Smart City initiative…

Read More

Hardware-Based IoT Security: Consider Your Options

By: Special Guest    12/13/2017

Risk vs. Reward - a tradeoff that factors into every business decision.

Read More

IoT and Cleantech Join Forces on Clean Energy

By: Special Guest    12/13/2017

The Internet of Things plays an important role in the adoption of clean technology and transforming operations and processes adjusted to the new envir…

Read More