Developers need to establish trust in the IoT

December 07, 2015

Developers need to establish trust in the IoT

All the devices connected to the Internet must be secure, or else. As the Internet of Things (IoT) continues to redefine our daily lives, the debate c...

All the devices connected to the Internet must be secure, or else.

As the Internet of Things (IoT) continues to redefine our daily lives, the debate continues regarding the critical need for security and reliability. In automobiles, medical devices, and avionics, there’s an expectation of reliability due to risk and impact of a failure. While products in these industries must comply to strict government policies driving the use of high-assurance operating systems and encryption, many others do not. Is there the same need for robustness in our network enabled televisions, home appliances, and toys?

All IoT devices are embedded systems. Underneath their layers of software are inputs, outputs, state machines, and data. Consider a Wi-Fi-enabled smart toaster; when added to the home network, it sends “toast ready” messages to your phone. Often misunderstood is that once on your home network, the toaster technically has access to all network traffic between your phone and the Internet, your home computer and printer, your home security system and webcams, and any other device on the network.

Why should we trust that this device, developed by the latest unknown IoT startup and its many partners, isn’t misusing our network data? With malicious software that same toaster can also:

  • Collect and forward all network traffic on your home network
  • If the toaster supports voice commands, software can activate the microphone and also record conversations
  • Spoof commands to other critical systems on the network, including your phones, webcams, and computers

As IoT devices become increasingly critical in our lives, so does our trust in their secure and reliable operation. If the benefits of the IoT are to keep pace with the number of devices, IoT developers carry the responsibility to understand the importance of establishing and preserving that trust in their embedded system designs.

Establishing trust in the IoT

Trust in embedded security refers to an expectation of integrity that a system is operating as designed. Software trusts that hardware is operating properly. Applications trust that the operating system is not corrupting data. Remote systems trust in the device’s identity to which it’s connected.

The process of establishing trust is authentication. A system’s root-of-trust is the point where authentication starts and then extends through each software layer. High-assurance solutions support a root-of-trust in hardware or immutable memory so that it can’t be modified.

At each power on, the Secure Boot process verifies each layer’s authenticity before allowing it to execute. This ensures that the software isn’t corrupted and comes from a valid source. A component is never executed unless proven trustworthy.


Figure 1: Software should be authenticated from the root.




The purpose of Secure Boot is to eliminate the risk of network and physical code injection by verifying that software is free of malware at each power up. There are many tradeoffs to consider with secure boot including boot time, which components to verify, and how to recover. In PCs where data and applications are constantly changing, the value of a unified extensible firmware interface (UEFI) secure boot is to ensure that the BIOS and kernel aren’t modified to eliminate rootkits. Embedded systems are different in that software is compact and static, allowing for authentication of the entire image.

Extending trust remotely

Networks should never be trusted. Always assume that just outside each connector is an attacker trying to capture data, issue commands, and play “man-in-the-middle” with your devices, as shown in Figure 2. At a minimum, the attacker can monitor all data and commands between two devices. Communication between the endpoints can be forwarded to backdoor collection systems. Attackers can also spoof both devices simultaneously, such as turning off the camera and faking status while replacing the camera’s video stream.


Figure 2: The man-in-the-middle topology provides the ability to sniff and spoof interfaces.
(Click graphic to zoom)




Public key infrastructure (PKI) cryptography eliminates the man-in-middle threat by using certificates to mutually-authenticate endpoints. A certificate authority (CA) generates the certificates for each device, vouching for the identity of each by digitally signing the certificate. Digital signatures issued by a private key are only verified by the corresponding public. Therefore, using the CA certificate, each device can authenticate the identity of another system before accepting data.

Certificate authorities are common in Internet security to prove the identity of a web server. In Transport Layer Security (TLS), the client is sent the server’s certificate during connection. A pre-loaded CA certificate is used to authenticate the server before setting up the encrypted session. Rather than assuming the costly task of issuing and managing client certificates, websites instead authenticate the user via name and password through the encrypted tunnel, despite well-known brute force and phishing attacks.

Software authenticity

How do you make sure that software doesn’t get modified? Firewalls, port scanning, vulnerability analysis, separation, and remote authentication all prevent network attacks during operation. However, what about when powered down? What prevents someone from opening the lid and accessing flash memory to inject code or counterfeit?

Using the same PKI principals as certificates, developers can sign software images to prove authenticity during start up and operation with Secure Boot. Code is signed using an asymmetric private key and verified on the device at runtime using the corresponding trust anchor.


Figure 3: Enterprise security infrastructures establish trust in IoT through CA and code-signing services.
(Click graphic to zoom)




Enterprise security infrastructure

Using cryptography, IoT developers can create systems of trustworthy interconnected devices over untrusted public networks. Implementing an end-to-end security strategy requires a platform that includes a cryptographic module, network security protocols, key protection, and secure boot. After all the man-hours securing the device, the investment is still at risk if CA and software signing keys are ever compromised.

Compromise of root PKI keys impacts every device manufactured. And with access to the root key, an attacker can sign malicious software and create fake certificates. Attackers then have the ability to masquerade as valid systems, with the ability to collect data and issue commands at will. Weighing the impact (one device vs. all), protecting the root keys is the most critical function of the entire system and must be prioritized accordingly.

In today’s complex manufacturing and supply chains, a workstation with a hardware security module just won’t do. IoT supply chains include multiple offshore and third party manufacturing locations, where partners need to add software to the security platform without exposing intellectual property to co-located competition. The security infrastructure provides stakeholders with the ability to use keys without the risk of compromise.


Figure 4: An enterprise security infrastructure provides secure key use across distributed supply chains.
(Click graphic to zoom)




Developing an end-to-end security strategy

Integrity Security Services (ISS), a subsidiary of Green Hills Software, supports the IoT revolution by helping clients build trust in their devices through end-to-end embedded security design. Starting with threat assessments to analyze the impact of unauthorized events, organizations can architect a security strategy addressing the ISS Five Rules of Embedded Security.


Table 1: End-to-end security design in practice.
(Click graphic to zoom)




End-to-end security protects during all lifecycle phases throughout manufacturing, operation, and maintenance. An attack doesn’t just occur after the product is sold. Employees, partners, and counterfeiters are also threat candidates, which is why a zero-exposure key management infrastructure is critical.

Unlike production test stations, the security architecture and infrastructure can be reused across multiple product lines. By developing the infrastructure solution first, organizations can incorporate use of the system into multiple products, thereby reducing per unit cost. The cost of security can be further reduced by value-added features, such as remote software update, feature control, and “in-app” purchases. Leveraging the trusted platform and digital identities, developers have the ability to securely communicate and distribute uniquely encrypted files.

Looking ahead

The explosion of IoT is unlike anything we’ve seen before. The challenge we face is deciding what we will let define us during this revolution. Will it bring information services we can trust and build on, or remain a novelty of convenience? Protecting our devices, allowing for parents to monitor their children’s blood sugars from afar, letting homeowners watch over their homes while on vacation, and so on, are the stories that weave through the fabric of this IoT revolution. They echo life, simplicity, and trust accomplished through end-to-end security designs.

Gregory Rudy is the Director of Business Development at Integrity Security Services, a subsidiary of Green Hills Software. He has over 15 years experience in the development of commercial and government technology. Rudy holds a Bachelor of Science degree in Computer Engineering from Cal Poly, San Luis Obispo and an MBA from Johns Hopkins University.

Gregory Rudy, Green Hills Software