by Alan Grau
Cyber-attacks against IoT devices continue to make headlines, with the Fiat Chrysler Jeep hack just the most recent. By now, most embedded developers understand the need for security, but news reports show that understanding the need is not enough. At a recent trade show I spoke with a number of vendors providing IoT solutions and found that far too many had not adequately addressed security. Those few that had a security roadmap were primarily focused on security for the cloud but largely ignored security in the devices.
There are a few basics that embedded developers should address to build secure IoT devices.
- Perform a security assessment before you start your design
- Using an RTOS does not ensure security
- Encryption is not security
- Ensure all attack vectors are addressed
- Securing the cloud is not enough
- Your device will be attacked
Perform a security assessment before you start your design
A security assessment is a critical step in the requirements specification for new devices or when upgrading an existing product. A thorough assessment of the communication interfaces, potential attack vectors and use cases produces a set of security requirements for the device. Understanding how the device is used, how it may be attacked, and what protections are required is critical and can be used to create a security profile for a device.
Consider an IoT enabled credit card scanner used for point of sale transactions. Our hypothetical device uses WiFi to connect to a local hotspot which in turn connects to the credit card processing server via the internet. Clearly, ensuring security of the data transmitted over the WiFi interface is a critical requirement. That alone may not be sufficient to ensure the security of the device. Other questions that would be addressed during a security assessment include:
- Are there other interfaces on the device? In our example, assume it has a USB port.
- How is the USB port used? Does the USB port need to be secure?
- How is the device firmware updated? Is that firmware update process secured?
- Does the device support secure boot to ensure that only authentic firmware from the OEM can run on the device?
- Is sensitive data stored on the device? Does this data need to be protected while stored on the device (i.e., while at rest)?
- Does the stored data need to be protected if someone steals the device and attempts to read the data from the flash file system?
- Are their denial-of-service scenarios that need to be considered?
- What services are provided via the WiFi interface? How are these services secured? e., if there is a web interface for configuration, how is authentication performed? Is the communication secured against replay attacks and packet-sniffing attacks, etc.?
While the security assessment can be a time-consuming process, it provides critical direction for the development of the device and allows prioritization of security features. You may, for example, choose not to secure the device against attacks that require physical access to the device and instead concentrate on ensuring the WiFi interface is secure. If you are building a radio secure military and government communication, you may make different trade-offs. The security assessment is critical in helping make these design decisions.
Using a Real Time Operating System (RTOS) does not ensure security
RTOSes provide many advantages in the development of IoT devices, including fewer security vulnerabilities than Windows and Linux, but this alone does not equate to device security. Even if, in theory, you could develop a product using a perfectly secure operating system, that is only one step towards building a secure device. Even though the theoretical OS would not be vulnerable to attacks that attempted to exploit OS services, it still would not address data security, authentication, or attacks against the application layer.
Encryption is not security
Encryption is clearly a component of security, but simply adding encryption to your device does not ensure that the device is secure. Encryption is an effective tool for protecting data and as part of an authentication mechanism. To effectively protect the data, you must first determine how encryption will be used for data protection.
Security protocols such as TLS provide encryption for data in transit, but do not protect data at rest or data in use. If protection of data at rest is required, then a disk or file encryption solution must be utilized. If protection against memory scraping attacks or other data-in-use attacks is desired, then a memory obfuscation or memory protection solution must be utilized.
Key generation, storage and management are also critical considerations for encryption solutions. Strong encryption can be rendered useless by using an easy to guess encryption or by storing they key in a plain-text file that is easily discovered.
Even after designing a robust encryption solution that addresses all applicable use cases (data in use, data at rest and data in transit) and that covers key generation and storage issues, the issue of security will not have been solved. There are many other attack vectors that need to be considered.
Ensure all attack vectors are addressed
If a secure assessment was performed during the requirements phase of the project, the potential attack vectors should be clearly identified. Each of these attack vectors must be addressed, unless a design trade-off is explicitly made to ignore certain attack vectors.
All IoT device designs should consider certain key security features such as hardening the device via secure boot, authentication, data encryption, firewall protection, intrusion detection and integration with a security management system for event reporting and policy management. Intrusion detection for embedded devices must focus on threats that are relevant to embedded devices. Malware and virus scanning are not required, but detection of unauthorized changes to configuration and firmware must be detected and reported.
Securing the cloud is not enough
Developers who are relying on security at the cloud to ensure protection for their IoT devices are leaving a gaping hole for hackers to exploit. While the servers that provide cloud services are physically secure, locked deep in a data center, IoT devices are widely deployed and are often easily accessible. This physical accessibility opens up a variety of attack vectors. Hackers may attack wireless interfaces, USB ports or even physically crack open the device to read the flash storage, attach probes to communication buses, or reprogram the device with malicious firmware.
Hackers are very talented at finding the weakest points in a network or system and exploiting it to their advantage. Many successful attacks against IT systems have been the result of exploiting a little used, seeming unimportant device as a launching point. Once inside, these hackers can then sniff network traffic to discover passwords, protocols used, network topology and other information to further an attack. Once the attacker has penetrated such a device, they can then act as a trusted insider the network and jump to other, more critical devices on the network.
Your device will be attacked
By now I would hope that all engineers would realize security by obscurity doesn’t work and claiming a device is not a valuable target for hackers is a fallacy. Hackers have breached medical devices and used them as pivot points to steal medical records from hospitals. A smart-home toilet has been remotely hacked, smart-refrigerators have been turned into spamming-bots and most recently blue-tooth enabled skateboards have been breached. Security can no longer be considered as a “nice-to-have” feature, even for seemingly unlikely hacking targets.
Building security into the device
Building protection into the device itself provides a critical security layer – the devices are no longer dependent upon the corporate firewall as their sole layer of security. In addition, the security can be customized to the needs of the device. But this is a complex process and it is critical to get it right.
A solution such as Icon Labs’ Floodgate Security Framework provides the building blocks developers need to ensure the security of their device.
Security is a requirement for all IoT devices, no matter how small or seemingly insignificant. A comprehensive security analysis can identify attack vectors and prioritize security requirements. Everyone involved in the development of technology for critical infrastructure needs to recognize the threats and begin investing today in security solutions that provide the highest possible levels of protection.
Alan Grau is the President and cofounder of Icon Labs, a leading provider of security solutions for embedded devices. You can reach him at alan.grau@iconlabs.com
Icon Labs
www.iconlabs.com
Dorris says
I feel this is one of the so much significant information for me.
And i am satisfied reading your article.
But wanna observation on few common things, The
site style is great, the articles is truly nice : D. Just right process, cheers
ayush says
Most attacks are due to faults in implementation. AES is highly secure form of encryption and it should be implemented more over the course of time.