From their inception, PCs, industrial systems, and all manner of computing devices were designed as individual points of compute. As a result, security was never top of mind.

However, today everything is connected. The IoT and Industry 4.0 have introduced new security threats that were not originally considered. Therefore, the way we think about building, managing, and maintaining electronic systems must also change.

Securing connected devices begins far sooner than most think, and extends far beyond the job of a single engineer or company. Even in systems that utilize robust components, vulnerabilities can present themselves as early as the semiconductor manufacturing stage and persisit throughout firmware development, application programming, and connecting devices to networks.

Unfortunately, there’s no single-point solution that protects against all of these potential threat vectors. But tools, processes, and methodologies are becoming available that can relieve some of the security burden from embedded and IoT engineers.

How Early Should You Start Securing Your Products?

To answer the above question, it’s important to consider the fundamental beginnings of any connected device – its silicon. In this regard, the manufacture of a product is just as important as how it is used later.

Let’s look at a company like GlobalFoundries (GF), for example, whose Fab 8 300 mm fabrication plant in Malta, New York, is capable of producing more than 700k wafers annually when at full capacity. The facility produces 14 nm GPUs and CPUs like AMD’s Zen-based Ryzen and Epyc SoCs, as well as all sorts of other semiconductors that support applications for datacenter processing to 5G networking.

Fab 8 is GF’s most advanced manufacturing plant, in part because it is almost completely automated. It’s also ITAR compliant (Figure 1).

Figure 1. GlobalFoundries Fab8 Facility

International Traffic and Arms Regulations (ITAR) are export restrictions that help control the flow of military-related technologies identified on the United States Munitions List (USML). And while import/export controls may not seem like they have anything to do with IoT device security, they have almost everything to do with it.

That’s because any vendor who works with such products must meet a long list of requirements to maintain compliance with ITAR. These include:

• Person limits on the manufacturing floor
• Restricted use of mobile devices
• Redundant copies of work to prevent work stoppages in the event of an attack
• Mandates that all fab employees use digital workstations
• The use of paperless systems that limit unauthorized viewing of information

“The ITAR is set up to control and prevent the release of critical technologies, sensitive technologies to the US government,” said Ezra Hall, director of the aerospace and defense business line at GF. “And you can imagine all of the sensitive types of applications that the US government might build semiconductors for, and those fall into the ITAR, among other things that are non-semiconductors.”

ITAR compliance assures that a manufacturing facility is equally, if not more, secure than the devices produced there. Hall noted that bringing Fab 8 in compliance with ITAR regulations has opened a dramatic market opportunity, and all of the devices fabricated at “the most advanced pure-play semiconductor factory campus in the U.S.” are subjected to the same secure manufacturing practices.

Securing Device Memory

Once a device is passed the stage of inception, vendors then need to decide how they can make the memory and information stored within it as secure as it can be. Whether it be through processes such as secure boot or TEEs, the memory must be secured in order to secure the entirety of the device.

The main purpose of secure hardware like a trusted execution environment (TEEs) is to protect valuable instructions and IP stored in memory. After all, that’s why many systems elect to run their secure boot processes from these regions.

But despite the growing availability of TEE solutions like Arm TrustZone, many developers still struggle with the complexities of TPMs, memory protection units (MPUs), and other secure hardware elements. Indeed, Hubertus Grobbel, the vice president of security solutions at Swissbit, noted that the biggest challenge with a process like secure boot is simply making it easy for developers to understand and use.

More specifically, how do you use these technologies without locking yourself out?

“Look at all the various options that a developer has, like a TPM or secure element attached next to a processor or integrated into a processor, or software security integrated in the processor,” Grobbel said. “Typically, you also have a TrustZone, right?

“Once [you integrate a security solution] in the CPU, you more or less stuck to the CPU. And if something breaks in the CPU, you’re just kind of stuck with CPU hardware that is potentially unmaintainable and unmanageable over the entire life cycle. So, our approach is we offer a security that is integrated into something that the developer needs anyway.

“That is storage.”

Swissbit recently released Secure Boot Solution for Raspberry Pi, a data encryption and access protection mechanism based on the "Raspberry Edition" of the PS-45u-DP-microSD card (Figure 2). According to Grobbel, the solution is ideal for defending systems against unauthorized data access, code manipulation, and IP violations. Even better, it comes with a companion software development kit (SDK).

Figure 2. Swissbit Security

The Secure Boot Solution for Raspberry Pi SDK offers an open-source pre-boot environment based on the U-Boot mainline and kernel, which allows developers of all levels to access the same type of security functionality available on modern MCUs and MPUs. Furthermore, the open-source nature of the solution provides users with the flexibility to modify their security implementations to meet the needs of their specific application and system resources.

The Big Challenge of Securing Devices

Beyond the boot process, there is still a need to secure higher level application software running on connected devices as bugs in this code could provide unwanted access to other sensitive system utilities.

Haydn Povey, CEO of Secure Thingz and General Manager of Embedded Security Solutions at IAR Systems, realizes this. In response, IAR has released the C-Trust development tool suite, which allows developers without deep technical security knowledge to easily encrypt their application code with little-to-no software rework.

C-Trust enables this through an encryption process that binds the application to elements of the target hardware, thereby continuing the chain of trust implemented with operations like secure boot (Figure 3).

Figure 3. Embedded Trust and C-Trust Processes

“We use cryptography to first of all ensure that the devices are the correct devices,” Povey said. “So, with STMicroelectronics devices, for example, we utilize a capability they've integrated called SFI, or Secure Firmware Installation so that we can guarantee that it is a valid ST device using cryptography. We can then take control of that device to create a pairing and then load the application in an encrypted format.

“Even if somebody sat between the computer and the device being programmed, they’d only see garbage. And we can ensure that the application you intended to load onto that device is the right application.“

The manual portion of a C-Trust installation involves selecting trusted memory regions that an application will use to gain access to resources. But this also gives developers the opportunity to set permissions that prevent data from an untrusted memory region from reaching an application that tries to access it.

As shown in Figure 3, all of the functionality of C-Trust can be accessed through the IAR Embedded Workbench environment.

Certifying Security

Of course, the hallmark of an IoT device is that it is connected, in one way or another, to a network of some type. That network could even be the Internet itself.

From an IoT security perspective, the challenge this presents for many engineers is that they are dealing with severely resource constrained endpoint devices. These systems often don’t have the local compute or memory resources needed for web-based cryptography like AES-256.

To address this challenge, companies like Veridify (formerly SecureRF) are developing ‘lightweight’ methods of encryption that are viable in small footprint systems with limited ROM and RAM. The company’s Device Ownership Management and Enrollment (DOME) Client, for example, is a software library that provides provisioning, management, and secure connectivity tools for ultra-compact IoT edge systems, and delivers encryption that can be run quickly even on CPUs operating at low clock speeds.

“In terms of resources on the embedded client itself, typically we say up to maybe 20Kbytes of ROM is needed to contain the DOME client library. And at any given time, it might use perhaps 800 bytes of RAM” said vice president of development at Veridify Drake Smith.

The DOME client is delivered with a software development kit, which contains a single DOME client library and Android and iOS interface appliances.

“We give you the parallel platform for doing the updates, for provisioning and for some of the other management functions that wouldn't be the focal point of the actual industry device,” said Louis Parks, CEO of Veridify. “[That device] is meant to be managing lights or heat or elevators in a building, which is what it does. It may have the keys to security, but again, by ensuring these structured platforms, we can help the customer manage it in the field, manage it securely, manage the handoffs and the updates.”

DOME is also Arm Platform Security Architecture (PSA) Level 1 Certified, which means that users can integrate it within a larger security construct that ensures system protections today and a roadmap for the future.

How Do We Know IoT Devices Are Meeting Our Security Standards?

Despite with the release of tools and methodologies that simplify security at every level of the IoT solutions stack there will be vulnerabilities in every connected device. And, one of the more disheartening aspects of the topic is that even when vendor A does everything within its power to create a robust, secure IoT endpoint, if vendor B cut corners in a product that is on the same network all of those efforts could have been for nothing.

In response, key IoT organizations have been working towards security standards that would hold companies to some minimum level of accountability. For example, David Kleidermacher, VP of Engineering and Head of Android Security and Privacy at Google, represents his company on the board of the Internet of Secure Things – or ioXT – alliance, an industry consortium looking to implement a global standard for IoT security.

In a recent interview with Embedded Computing Design, Kleidermacher noted that the challenging part of this process is not actually the creation of standards, but rather the creation of a scalable compliance program that considers all potential devices and use cases.

But for such programs to be possible, they need to have teeth behind them that only governments can provide. And Kleidermacher wants governments worldwise to create mandates around IoT security standards that both promote and ensure their use in connected devices.

Until that time, be it somewhere down the road if it happens at all, vendors must put security at the forefront of their connected device thought processes. And consider the complexities of security that range all the way from component inception to the time an IoT product reaches the hands of a consumer.