The Internet of Things (IoT) makes security a more important consideration than ever for designers of devices that will provide the eyes, ears, and hands of the network, as well as for command and control functions that monitor, react to, and control those devices. Individually, devices need to be prepared to operate in an environment where attacks might originate from anywhere around them. In addition to being domain experts in the mission function of their embedded devices, system designers must now consider how they can provide that capability when interconnected with devices that may be compromised.

Know what to protect against

Modern embedded systems cover a vast range of architectures, system sizes, capabilities, and operating environments. One thing that most systems in development today share is that they use networking technology to communicate between each other or in their command and control networks. Designers need to step back to look at their systems from the perspective of an adversary. It’s useful to start by asking some fundamental questions, for example:

What kinds of adversary do I need to protect against?

In an interconnected world, potential adversaries can include smart young “explorers” looking for a challenge or bragging rights; competitors looking for trade secrets or weaknesses they can exploit in the marketplace; or committed attackers looking to disrupt or take control of a system because of its own capabilities or to use as a staging platform to launch further attacks. What is true for all of these cases is that sophisticated software and test equipment is more available now than ever, and the Internet makes information to use them readily available and even facilitates the creation of geographically distributed teams with an array of skills to reduce the time it takes to mount a successful attack.

What level of access do they have?

While many threats are based in the network, seeking to exploit weaknesses in protocols or latent software defects, an adversary that has physical access to a system has many more opportunities to probe for weaknesses. Debugging ports, test points, and exposed memories are all favourite entry points from physical access. Care should be taken to secure common entry points such as unauthenticated console access through an Ethernet or serial port during bootstrap, or USB-based post-boot automatic firmware upgrades.

What are the consequences of a successful attack on my system?

The ultimate successful attack gives an attacker complete control of the system, allowing them to inspect and modify firmware. The direct consequences may expose Intellectual Property (IP) or trade secrets, or expose IP licensed from other companies, or create civil liabilities for breach of confidentiality. Indirect consequences can include embarrassment or loss of reputation in a market, or a loss of confidence in customer and partner bases.

What are the consequences to neighbouring systems of a successful attack?

If an attacker gains control of the system, what else does that give them access to? An automobile infotainment system with Wi-Fi connectivity for mobile devices may provide a perfect launch platform for attacks on the vehicle control electronics.

Are the assumptions that drove design decisions in previous generations of my system still valid? What are the implications if they aren’t?

Many embedded systems, especially leaf nodes in sensor and control systems that used to operate over proprietary networks, are being or will be converted to widely available network technologies like Ethernet, Wi-Fi, and TCP/IP. Previously isolated systems may now be accessible from the Internet, even if indirectly through front-office or back-office networks. Knowledge about specialized protocols like CAN is now much more accessible than it once was, so even if the original technologies are still applicable, they may be more accessible and therefore more vulnerable than they once were. Obscurity and obfuscation provide little protection from determined reverse engineering. Test equipment with embedded secrets or service passwords can provide an avenue for attackers to gain access to and control of a system.

Trust begins at home

The first step in securing a system should be building up the trust that its firmware is intact. Secure bootstrap systems use cryptographic signatures on the firmware, traceable to the firmware provider, to determine the authenticity of the firmware. While predominantly firmware, secure bootstrap systems like Elliptic’s tBoot firmware take advantage of hardware features like ARM TrustZone that may be embedded in the processor, or provided at board level. Flexibility is maximized by using public key signing algorithms with a chain of trust that allows the code signing authority to be replaced by revoking and reissuing the signing keys if it is ever compromised. The essential feature that security hinges on is that the root of trust public key is known to the secure bootstrap system, and is unalterable. Storing the public key or a cryptographic hash of it in hardware (preferably in the processor itself) ensures that the root of trust identity can be established.

While the system may be in a trusted state after boot, keeping it intact over time is the next challenge. One approach is to periodically test cryptographic hashes of executable code to look for signs that the code has been modified by malware. Processor features that disallow modification of executable code or allow program code to be randomly relocated at program load can help make the system more difficult to attack.

An approach that is gaining momentum is the use of protection systems that attempt to isolate programs from each other. The idea is that even if one program is compromised, the rest of the system may be able to continue on, or initiate a response to the problem such as reporting it to a logging node in the network and restarting the affected program or the whole system from a clean backup. Security-Enhanced Linux (SELinux) uses mandatory access controls as a mechanism to implement the principle of least privilege: Programs have access to only those system resources that are needed to accomplish the program’s function. A similar approach is beginning to emerge using virtual machines and a lightweight hypervisor to separate task environments from each other. The TrustZone secure environment provides separation of secure processes and even hardware resources from other less-trusted processing.

Trusting your neighbours

Having a trusted, intact system that is operational and running in isolation is not of much value if its purpose is to use the network to communicate in a much larger distributed system. While some kinds of applications demand confidentiality (such as medical devices that handle patient data), most devices require only authentication. In practical terms, the amount of work to provide cryptographic authentication is comparable to providing both authentication and confidentiality. However, the provision of authentication only can make it much simpler to analyse system behaviour and even provide non-critical service extensions since network data is visible, but cannot be changed by intermediate nodes without detection.

Generally, the network itself should be seen simply as a means to communicate, which is not a reason to trust it. In some cases, trust can be established between network elements offline, or through a registration protocol. That registration protocol may be as simple as “trust all devices signed by Manufacturer X’s signing key,” or may require an actual network registration protocol to register individual devices. For example, sensors that will broadcast or multicast readings to many endpoints may sign those results using a public key-signing scheme. When the sensor is added to the network, its public key is added to a database of trusted devices of its particular type (after authenticating the public key itself, of course). Broadcast messages signed with this key may then be trusted to have originated with the device. If the network address is correlated with the device, only the signature is required on the message.

In other cases, it is appropriate for endpoints to establish trust between each other using an online protocol. Internet Key Exchange (IKE), used mostly with IPsec, and the Transport Layer Security (TLS) handshake protocol are both capable of being used in a mode that requires mutual authentication (each side authenticates itself to the other). While these cases are most commonly used in point-to-point secure links, it is also possible to use a secure channel created between endpoints to distribute group keys that allow a group of nodes to create mutual trust in a larger untrusted network. Note, however, that compromise of any member of the group compromises all communications within the group. As always, it is recommended to use well-established protocols like TLS and IKE rather than creating a protocol ad hoc. One reason to authenticate communication with neighbours is to limit the feasibility and damage of Denial-of-Service (DoS) and Distributed Denial-of-Service (DDoS) attacks.

Recovering from failure

Systems that are popular and ubiquitous will inevitably come under attack, and one of those attacks may succeed in uncovering an exploitable vulnerability. A basic tool to help with this is the ability to revoke a device’s credentials so that compromised devices cannot communicate on the network. In some cases, all devices of a particular design may be compromised, which requires being able to identify those devices. And in really serious breaches, a very sensitive device like a code signing node may be compromised. A well-thought-out device credential design and the corresponding signing key hierarchy helps to recover from these kinds of problems, since compromised elements may be revoked and new credentials issued as part of an upgrade, if possible. Without that ability, networks can become vulnerable to the kinds of issues that shut down the Playstation network in April 2013 where 77 million accounts were compromised. The entire network was shut down for weeks while new credentials and replacement firmware were prepared and distributed.

Signing authorities for revocation lists should be distinct from those that are authorized to issue code. And special care should be taken to prevent rollback of code upgrades so that old attacks cannot be launched over and over. While the tendency in the past has been to use ad hoc designs for these elements in embedded systems (if implemented at all), the massive interconnectedness of IoT and Machine-to-Machine (M2M) applications and the potential to use one part of the network to disrupt others makes it wise to use well-proven systems designed by security experts implementing standards-based protocols.

Mike Borza is Chief Technology Officer at Elliptic Technologies.

Elliptic Technologies www.elliptictech.com

Follow: Twitter Facebook LinkedIn