In the autumn of 2016 hackers recruited hundreds of thousands of embedded devices to form malicious botnets. Their Mirai malware infected broadband routers, letting the operators of the botnets employ them in distributed denial of service (DDoS) attacks. It was a wakeup call for the emerging Internet of Things (IoT) industry – showing how hackers could use networked smart devices for their own ends.
Although the Mirai attack focused on consumer devices, the implications for the industrial IoT are serious. Without countermeasures, industrial plants are at risk of falling victim to similar mass attacks. The risks range from lost production to serious damage to connected machinery. Analysis by security experts has shown that manufacturers of devices that have fallen victim to hacks make relatively simple mistakes. In the case of the Mirai attack, there was very little protection in the routers against hackers logging in and uploading new firmware to them.
Groups such as the IoT Security Foundation (IoTSF) have issued recommendations designed to protect against similar attacks. The IoTSF identified measures that would protect against Mirai. They include the need to ensure access codes or passwords are unique to each unit and are not shared among a group of devices. Even if the hacker is able to discover the password for one, they are not able to log into others with the same access credentials. A further recommendation is that devices should protect against having firmware loaded into them that has not been digitally signed by a trusted provider.
Although the answer is to have credentials that are unique to each unit, this can be difficult to manage from a logistical point of view. IIoT systems become very expensive to deploy if each device needs to be provisioned individually by an expert installer. It is also a strategy that increases risk because numerous devices may need to be configured by a small group of people – making them prime targets for industrial espionage and social engineering attacks.
Figure 1: A certificate hierarchy suitable for IIoT implementations.
The point at which unique keys are installed is also an issue. The procedure should occur early in the manufacturing supply chain. This avoids the need to transmit secret keys over the network, which is a major risk to security, especially if an attacker knows when a network is being set up. Given the nature of industrial projects, attacks on private key transfers cannot be ruled out.
There are several steps required to install a sensor node or IIoT device before it can be considered a trusted part of the system. The first step is to enroll it in the network. That is, it needs its own unique network address and the means to communicate with a server – most likely a local gateway or router that facilitates access to the wider IoT.
For ease of use, enrollment can be supported through near field communication (NFC) – tapping the device with a management unit, which may be a smartphone or tablet, that sends the required network data to the device. The unit then configures itself to talk on the network to which it has been given access. But this does not make it a trusted device. Until provisioning and authentication have completed, the other network devices should not trust its data.
The device needs to be trusted by other machines on the network, and the reverse needs to be true. This guarantees to the device that when it sends data to a server or a gateway it is dealing with an authentic machine and not an imposter. If firmware updates are sent by a remote server, they need to be checked against digital certificates to ensure that each update is legitimate and not an attempt by a hacker to subvert the device’s purpose.
Figure 2: The protocol used to deposit device-specific certificates during prototyping and manufacture.
An exchange of digital certificates provides the basis for the establishment of trust to proceed. PKI is a well-proven framework for performing the kind of mutual authentication needed for efficient and secure IIoT operation. It makes it possible to build a supply chain of trust that ensures when a device with an appropriate certificate appears on the network, it will be recognized as trustworthy.
The X.509 standard, for example, leverages the PKI to associate a public key with the identity of the certificate’s owner. Using the public key, anyone accessing the certificate can check that it is a match for the signature in the certificate. The certificate on its own is not enough without a means to verify that the identity of the certificate is legitimate. In order to be trusted, the identity of any networked device must be part of a larger chain of trust that can be verified by a third party. X.509 makes it possible to build such a chain of trust, as can be seen in the TLS security mechanism used by web browsers.
Under X.509, the end of the chain should be a certificate provided by a trusted Root Certificate Authority. From this root certificate, it is possible to create certificates with their own public key and issuer signature that refer to the root. Further certificates can then be generated from these derivative certificates in a tree structure. Through the Distinguished Name of the issuer on each certificate, a client can obtain the public key of the certificate further up the hierarchy to check that the signature of the certificate is legitimate.
Figure 3: A prototyping setup for implementing hierarchical certificate deployment.
In an IIoT device supply, a three-layer hierarchy is an appropriate choice. The root certificate authority for the chain of trust for a device can sit within the manufacturer. Each application or customer for the device is provided with a certificate based on that root document. Finally, each individual device has its certificate derived from the application certificate. This creates a chain of trust that delivers unique certificates to all IIoT devices in a manageable and secure way.
What is then needed is a mechanism for installing the unique certificate on the IIoT device. There are a number of hardware requirements for secure storage that can be difficult to implement on a standard microcontroller and memory combination. There is also the issue of when and how the certificates are programmed into the IIoT device, particularly in the complex manufacturing supply chains used today. Outsourcing may mean the delivery of private keys to facilities that do not have strong security guarantees.
The Microchip ATECC508A provides a solution to the problem. The ATECC508A crypto element uses the Elliptic Curve Diffie-Hellman (ECDH) crypto and key-exchange system. This provides high security with less processing overhead, and therefore longer battery life compared to traditional RSA key systems. In addition to ECDH, the ATECC508A has ECDSA sign-verify capabilities built-in to provide highly secure asymmetric authentication. The ATECC508A employs cryptographic countermeasures to guard against attacks in which the hacker has access to the hardware.
As well as being a secure cryptographic co-processor optimized for constrained embedded systems, it is supported by a manufacturing infrastructure that is able to insert unique keys and certificates securely. The application or customer certificates are created and stored on the Microchip secure manufacturing line with device certificates created as needed when each ATECC508A is programmed. Once programmed, the ATECC508A simply needs to be placed on the target PCB where it cooperates with the host microcontroller over I2C to perform authentication functions.
One important benefit of using a pre-loaded device such as the ATECC508A on an IIoT device is that it is supported by an infrastructure that handles mutual authentication and provisioning. Microchip is working with Amazon Web Services (AWS) to provide the server-side infrastructure for IoT systems. Microchip registers the customer-specific production certificates with AWS to ensure that when a device announces its presence to the cloud, it will be recognized as a valid request. At that point the mutual-authentication handshake occurs, allowing the device to form part of the IIoT system. Updates and requests from the AWS applications that are accompanied by appropriate digital signatures can, conversely, be trusted to be legitimate. To allow easy prototyping, the AT88CKECC development kit for the ATECC508A is supplied with USB dongles that contain self-signed certificates that act as root and intermediate certificate authorities.
Conclusion
Security professionals agree that unique credentials, preferably based on a known secure scheme such as PKI, provide a good defense against mass attack. An infrastructure that brings together cloud services and efficient hardware such as that provided by the ATECC508A and AWS, makes it possible to implement the necessary security at the scale required for IIoT projects.
