Monday, December 23, 2024

Industrial IoT (IIoT) will Require Embedded Hardware Security

- Advertisement -

The Industrial IoT (IIoT), a subset of the IoT evolution, is quite the rage within automation companies as they seek to add a high-margin software component to their traditional businesses. Since Maxim Integrated chips are used to build these automation systems, we get a unique perspective on how automation system design has to evolve, or in some cases, change as companies attempt to put their automation systems online to take advantage of the IIoT. This paper briefly introduces IIoT and focuses on security challenges that must be solved to implement secure IIoT-capable end systems.

THE INDUSTRIAL IOT IN MANUFACTURING

Manufacturing can get the most leverage from the IIoT because of the sheer amount of data it can capture and process; data is the underpinning of the IIoT since it can be analyzed and visualized to help optimize operations and costs. Within manufacturing, security solutions provided by intelligent sensors, distributed control, and complex, secure software are the glue for this new revolution.

To realize the promise of IIoT, we have to put a lot of our systems, even legacy systems, up in the cloud. This will have profound security implications since the security implementation for industrial control systems has not kept pace at best, and in some cases, is non-existent. This will change as actors (malicious or otherwise) realize that a factory or a plant is effectively on-line, and exploit different attack opportunities.

- Advertisement -

Security will have to be a combination of software as well as embedded hardware to protect critical control systems from a variety of attacks. Three key challenges are: hardware authentication with secure keys, secure communications using TLS, and secure boot. Since connectivity (the thing that enables IIoT) completely exposes all of our security shortcomings, security cannot be an afterthought if we are to realize the benefits of the IIoT.

THE BENEFITS OF THE IIOT AT WORK

A good example of the IIoT at work is General Electric’s newest $170 million plant U.S. factory in upstate New York.1 It opened about a year ago to produce advanced sodium-nickel batteries used to power cell-phone towers. The factory has more than 10,000 sensors spread across 180,000 square feet of manufacturing space, all connected to a high-speed internal Ethernet. They monitor activities such as which batches of powder form the battery ceramics; how high a temperature is needed to bake them; how much energy is required to make each battery; and, what local air pressure is being applied. On the plant floor, employees with tablets can pull up all the data from Wi-Fi nodes set up around the factory.

Another good manufacturing example is the Siemens Amberg Electronics Plant that manufactures the Simatic programmable logic controllers (PLCs).2 Production is largely automated; machines and computers handle 75% of the value chain on their own—the rest of the work is done by people. Only at the beginning of the manufacturing process is anything touched by human hands, when an employee places the initial component (a bare circuit board) on a production line. From that point on, everything runs automatically. What’s notable here is that Simatic units control the production of Simatic units. About 1,000 such controls are used during production, from the beginning of the manufacturing process to the point of dispatch.

IIoT harnesses sensor data, machine-to-machine (M2M) communication, and automation technologies. Smart machines are better than humans at accurately and consistently capturing and communicating data used to fix inefficiencies and solve problems in terms of up-time, scheduled maintenance, power efficiency, and more efficient utilization, sooner. Maxim Integrated has broken down the IIoT in terms of a stack as shown

in Fig. 1. At the very bottom of the IIoT stack, we have the devices (systems) on the factory or process floor. These can be field sensors, controllers, industrial PCs, etc. All of these are hardware systems and can include aspects of hardware security. These end devices must have useful data to communicate and are generally hooked up to communication hubs, gateways, and switches so that the data is put in the cloud (or an intranet) as big data.

But that’s not all. The promise of IIoT is that this data can be integrated within the ERP and CRM software of the firm to not only efficiently plan and cost out a manufacturing process, but also to use the customer/market information to change assembly lines and process parameters.

The top of the stack impacts your software development and integration; the bottom impacts your system design perspective.

Primarily the benefits of IIoT can be broken down into three groups (Fig. 2): asset, process, and enterprise optimization. It is easier to optimize a motor than it is to optimize a drilling operation, which in turn, is easier to optimize than the manufacturing lines of a large enterprise. But optimizing at every level is the dream of IIoT.

The first level of analysis and interaction occurs at the edge: the data is collected from a sensor (e.g., a wind turbine sensor, a motor encoder, or a vibration signature). This is processed locally to help understand how to tweak parameters that would give the highest efficiency or provide an early indicator of a potential failure.

The next level of analysis is done at the control room or plant level where sensor data from multiple end devices and even multiple assembly lines is aggregated to make decisions that would increase the efficiency of the factory or a process. For example, a control room making idling or sleep decisions of the various end devices to reduce the overall power profile of the process.

fig1
Fig. 1. Industrial IoT Stack From an Automation Perspective
Fig. 2. Potential Industrial IoT Benefits
Fig. 2. Potential Industrial IoT Benefits

These first two aspects of using data to positively impact operations is what we are all familiar with and use in some way, shape, or form; however, what IIoT envisions is not just an increase in the data collection and analysis at the first two stages, but integrating the process data with the enterprise data to make really interesting decisions that so far have not been made before.

Consider a company enjoying a market explosion. The assembly line can be programmed to manufacture higher volumes of the product, or completely bypass sub-assemblies adding features not valued by the market. Now, combine both the operating and financial data to provide more insight to the CFO. The agility of the company and its ability to pivot, change, and continue to grow can be exponential. Indeed, it is an attractive proposition, and many are eager to move forward, quickly. So quickly that security has not been keeping up with the new IIoT systems.

INDUSTRIAL IOT EXPOSES SYSTEM VULNERABILITIES

There are a few ways that IIoT systems are vulnerable to attacks. Among the two most prominent are cloud storage and network architecture.

Putting data on the cloud (public or private) is an integral component of the IIoT. But, this comes with huge security implications. Traditionally, industrial control system (ICS) vendors have maintained that their systems have a built-in air gap. This is no longer true when these systems have a direct or indirect connection to the Internet. IIoT is going to drive the understanding that ICSs need to have embedded authentication and security features.

Let’s look next at the network architecture that enables the IIoT. Fig. 3 provides a top-level view of how the field devices in a factory or a manufacturing process are ultimately connected to the network.

There has always been the control network, a host of field sensors, actuators or servo drives (and other such devices) connected to PLCs or DCSs. Typically, this control network is a bunch of isolated networks. But increasingly, the control networks that manage different sections of a factory or process are connected together, creating the plant network.

A plant network lets supervisors see the entire plant operation and deduce how the different sections of a plant interact with each other. Information at this level allows for the optimization of the entire plant or an oil field operation. Ultimately, this plant network information is integrated with the enterprise/business network to enable the real promise of IIoT.

Fig. 3. Mapping Security by Plant Network Levels
Fig. 3. Mapping Security by Plant Network Levels

Each level of operation within the control network needs to have its security needs assessed—security is different at each level. If you start at the top, the domain of IT, what you have are secure switches and servers that are (hopefully) updated with the latest software and patches:

 At the plant level, security is not up to date. However, IT still does have some control.
 At the control network layer, the PLC architectures are decades old. Generally, updates are rare, and frequent patches cannot be applied to systems that are responsible for 100% factory uptime. Security is generally weak here.

 At the field level, which is generally never discussed, security is virtually nonexistent. Field devices are open, trusted, and cannot really have any encryption implemented because interoperability is paramount. If we look at field slave devices, such as sensors and actuators, these systems have zero security features (for the most part) and work on protocols developed almost 30 years ago during the 1970s through the 1990s.

ADDRESSING RISKS IN INDUSTRIAL CONTROL SYSTEM

When we look at the field level in more depth, the two primary points that present risk to the ICS are remote field sensors and IO modules. At stake are uptime, predictable maintenance, and overall industry efficiency: the cornerstones of IIoT.

 The Risks with Remote Field Sensors

Physical security of all sensors may not always be possible, especially when the sensor is very remote like those used to monitor oil and natural gas fields. Inaccessibility further makes sensors vulnerable to physical attacks, so it is essential to authenticate all sensors before their data is accepted. However, in most cases, our field sensors, even those used in critical infrastructure systems, are both open and trusted. This vulnerability of our field sensors has not gone unnoticed.

In 2014, the well-known Black Hat conference featured a paper by Russian researchers who conclude that attacking an enterprise system directly is too much trouble. Instead, they concocted and describe a “Man in the Middle” attack by spoofing and replacing an open and trusted HART modem-based field sensor.3 They describe the process in detail and even make the software libraries available for download.

Our focus on secure systems for IIoT must begin with a trusted sensor that is sending the data to the cloud or the PLC. The implications of a security breach on these remote devices can be profound.

 The Risks with IO Modules

Another way to get access to an open trusted system is using cloned IO modules to deliver malware. Factory owners are used to replacing IO modules within their PLCs. There have been cases in Asia where cloned IO modules (with a fake corporate logo of some of the top automation vendors) are available in the market. Again, since this is a trusted system with traditionally little to no embedded security, it can be an effective vehicle for delivering malware to the main PLC CPU. Physical security (making sure that PLC system updates are limited to a select set of people) can deter this, but keep in mind this does not need to be a malicious act. You might not even know whether this is a cloned or fake IO module.

 Implementing Hardware Authentication with a Field Sensor

A systems solution for the potential risks described can be simple: if you are going to trust the data from a slave subsystem, the data must be authenticated. There is a simple embedded hardware approach to keeping these kinds of trusted systems secure. An authentication scheme was instituted years ago for medical and consumer products such as printer cartridges. These systems traditionally employ a standards-based authentication process, using a custom secure device.

This authentication scheme is based on the challenge-response exchange between the host and the slave device (Fig. 4). The host system sends a challenge used by the slave system to compute a response. This response is validated by the host system to make sure the slave system is not cloned or counterfeit. Only after validation will the host communicate with the slave system.

A simple conceptual block diagram of a hardware-based authentication scheme similar to the symmetric SHA-256 algorithm is shown in Fig. 5.

The SHA-256 protocol, based on a challenge-and-response exchange between authorized devices, will authenticate the sensor before its data is accepted and read. SHA-256 authentication makes it almost impossible for an attacker to connect to a network, to pretend to be a sensor, or even to replace the senor system with a compromised system, unless they have an identical authentication device with the same programmed-in private key.

Vendors such as Maxim Integrated will provide the key programming service at a U.S. stateside facility, then ship a programmed authentication device to you. This device will have a unique key that is known only to you. The devices that store the key are tamper-proof with a range of active and passive tamper protections built-in.

Fig. 4. Authenticating the Slave Module: Can be used with both a field sensor and an IO module
Fig. 4. Authenticating the Slave Module: Can be used with both a field sensor and an IO module
Fig. 5. Sensor authentication with SHA-256 (private key)
Fig. 5. Sensor authentication with SHA-256 (private key)

THE RISKS WITH PLC CPU AND SOLUTIONS

What controls your plant or process is the PLC and the main CPU that is running all the control algorithms. But these systems were never designed to withstand security attacks and breaches. Hence, once these systems are connected online, there are many ways to compromise the main CPU of the PLC. Some of the attack surfaces can be applications software, OS, or hardware, but the most vulnerable surface is the firmware. If the firmware can be modified or infected, any change due to malware is not only hard to detect, but also if it is found, it is very difficult to ascertain the intention or purpose behind it.

Most PLCs lack source and data authentication on firmware uploads. Some PLCs even lack checksums for validating the correct transfer of the firmware. If the attacker can modify the PLC firmware, they can:
• take complete control over the infected system,
• learn about the production process,
• selectively sabotage the manufacturing operation (aka Stuxnet), or
• propagate to the enterprise from a trusted manufacturing system.

Not everyone wants to take control of your system to destroy your plant. The risks can be more subtle. There is a lot of intellectual property embedded in a manufacturing setup, and sometimes the intent is merely to get at this IP. This kind of malware will not manifest itself by creating problems in your manufacturing setup.

Automation World once reported, “The interesting thing about Dragonfly is that it targeted ICS information not for the purpose of causing downtime, but for the purpose of intellectual property theft. The potential damage could include the theft of proprietary recipes and production batch sequence steps, as well as network and device information that indicate manufacturing plant volumes and capabilities.”4

The system solution to mitigating something like this is to implement secure boot for the main PLC CPU. This is a way of authenticating the firmware and only accepting software that has a valid digital signature. Depending on your requirements, the user could also encrypt the firmware. The security processing demands can easily overwhelm the MIPS of a traditional PLC CPU or even create latency issues. This is best done by off-loading the security functions to a low-cost, off-the-shelf secure microprocessor that is built for these functions; as shown here. The system shown here in Fig. 6 uses an external secure micro to validate the firmware’s digital signature.

All the above examples use keys to enable authentication, but this raises the question of key protection. Physical security of an encryption key, is of prime consideration in many applications since there is no security once the key is compromised.

To properly address physical security, several issues must be considered. These include: a physical mechanism for generating random keys, a physical design that prevents covert electronic interception of a key that is being communicated between authorized agents, and a secure method of storing a key that protects against clandestine physical and mechanical probing.

Various secure key storage devices provide system designers a host of features that range from package design to external-sensor interfaces, and internal circuit architectures. These requirements were developed by the Military in the form of FIPS 140 standard, and many chip vendors such as Maxim Integrated provide very comprehensive tamper-proof capabilities that can be used in industrial control systems.

THE FUTURE OF IOT SECURITY

There may be other approaches to security as well, and as we begin to realize how important security is in a connected factories environment, we will eventually coalesce around a few approaches.

IIoT in manufacturing is in high demand, and is a growing trend. Security will also eventually grow to cover vulnerabilities, but the need is already here.

Fig. 6. Secure Boot of the Main PLC CPU
Fig. 6. Secure Boot of the Main PLC CPU

REFERENCES
[1] Siemens Press Brief on the Amberg Electronics plant
[2] Complete presentation available at Blackhat
[3] Automation World


SHARE YOUR THOUGHTS & COMMENTS

EFY Prime

Unique DIY Projects

Electronics News

Truly Innovative Electronics

Latest DIY Videos

Electronics Components

Electronics Jobs

Calculators For Electronics