Ensuring security when connecting IIoT systems to the cloud

Author : Xavier Bignalet, Secure Products Group Marketing Manager at Microchip Technology

05 April 2018

Credit: Shutterstock

Opening up factories and their industrial plant to remote access to enable industrial IoT (IIoT) applications is creating potential security vulnerabilities, but as this piece explains, these can be mitigated...

For the digital issue of this piece, please visit this link – or click here to register for EPDT's magazine.

The dawn of Industry 4.0 has seen factories become far more automated, with remote manufacturing and control concepts. While this brings many benefits in terms of business efficiency, it also exposes some very expensive assets to the risk of unwanted access. And it’s not just the high capital value of the machinery that’s being put at risk, but also the revenue from factory-produced goods that could be compromised as well.

If, as is common, the factory is connected to a public or private cloud, then there are of course inherent security risks. This happens as soon as a smart factory is exposed to a network, such as an offsite data centre. The challenge is to retain the elasticity benefits of the smart connected factory, as well as keep up with scaling security across the various industrial networks.

A good starting point is to determine whether the solution will use a wired, wireless or combination solution. From there, it is recommended that users apply connectivity technology that has industry standard protocols, such as Wi-Fi, Bluetooth and Ethernet. For security, usage of standard practices lowers the risk of the connections being compromised.

This goes against the historical habits of the industrial segment, which has tended to be keen on proprietary solutions. The infrastructure needs to be built to last over many years. While many networks have some proprietary protocols, these should be confined to in-house use and not for external connections.

One of the problems, however, is that even the most highly qualified embedded engineers tend to have limited knowledge when it comes to IT security concepts. They are not IT security experts, and that knowledge gap hinders them from being able to create a robust and secure IoT infrastructure. As soon as the connection is made from the factory to the cloud, the engineers are suddenly thrust into the world of Amazon Web Services (AWS), Google, Microsoft Azure (and so on) – and they will quickly find that they need help from IT experts to handle the wide range of ensuing security threats.

For hackers, one of the main targets is to leverage a single point of access to obtain remote access to a large number of systems. Remote attacks can create large-scale damage, as a recent onslaught of attacks, such as the Mirai botnet Distributed Denial of Service (DDoS) attack has shown. For an IoT network, the weakest point is usually the hardware and its user at the end node, given that the engineers looking after this normally lack the IT knowledge to deal effectively with the problem.

However, this is changing. Companies such as Microchip Technology see it as part of their mission to close this gap, by educating engineers on what an end-to-end secure infrastructure should look like. Additionally, big cloud companies such as AWS, Google and Microsoft are crucial sources of expertise.

The big lesson is not to neglect security: avoid considering it as simply an add-on after an IoT network has been designed. By that point, it’s already too late. Security is something that needs to be strategically implemented from the start of any IoT design. Security begins in hardware, and is not something that can simply be added on as an afterthought or supplemented in software.

Authentication

Credit: Flickr

The most important piece of the security puzzle is authentication. A system designer must start with the concept that every node connected to a network needs to have a unique, protected and trusted identity.

Knowing if someone on the network is who they say they are – and if they can be trusted – is paramount. In order to do this, traditional usage of TLS 1.2 and mutual authentication needs to occur between a server and an IoT end node. This is achieved using information that both parties trust: a certificate authority.

This only works, however, if the trust issued from the certification authority is protected all the way from the start of the project, through manufacturing, to the deployment of the system in the smart factory. The private key, which is used to acknowledge the authenticity of the IoT end node, must be secure and protected. Today, a weak, yet common implementation method used for this is to store the private key within a microcontroller in flash memory, where it may be exposed to software manipulations.

However, anyone can access and look at this memory zone, control it and then obtain the private key. This is a flawed implementation and gives designers a false sense of security. This is where the damage and major problems occur.

Secure element

For a secure solution, both the key and other critical credentials need to not only be removed from the microcontroller, but also isolated from the microcontroller and from any software exposure. This is where the concept of a secure element comes into play. The idea behind secure elements is to essentially provide a safe haven in which to store and protect the key, where no one can access it.

Commands from the CryptoAuthLib library allow it to send the appropriate challenges/responses from the microcontroller to the secure element, in order to validate the authentication. At no point in the product development process and its lifecycle is the private key exposed, nor does it ever leave the secure element. Thus, an end-to-end chain of trust can be established.

The secure elements are standalone CryptoAuthentication integrated circuits (ICs) that can be thought of as digital safes where companies can place their secrets. In this case, they hold the private keys needed for IoT authentication.

Provisioning the keys

A second important concept is how the private keys and other credentials are provisioned from the customer into the CryptoAuthentication device. To do this, Microchip provides a platform through which the customer can create and securely arrange programming of their secrets during manufacturing of ICs – without exposure to anyone, including Microchip personnel.

Credit: Shutterstock

Microchip then manufactures the secure element in its facilities, and only just before it leaves these secured common criteria-certified facilities, is it provisioned and sent to the end user.

When customers open AWS IoT accounts, they bring the customer certificates that Microchip created on their behalf, using the Use Your Own Certificate function from AWS.

Then, they use the AWS IoT function (called just-in-time registration, or JITR) to perform a bulk upload of the device-level certificates, which are stored and provisioned in the secure elements, to the AWS IoT user’s account. From there, the customer-level certificate can now verify the device-level certificate, and the chain of trust is effectively complete.

This function is what enables true enterprise IoT scalability with security in mind. There can be many thousands of certificates that can be handled using the JITR process. They can be handled in bulk, rather than one at a time, with no intervention from the user. Instead of having to manually load certificates from the associated devices to a cloud account and expose them to third parties, users can now arrange to register new device certificates automatically. This is as part of the initial communications between the device and AWS IoT – all without compromising security.

Get started with the upgraded AT88CKECC-AWS-XSTK-B kit

On board the Zero Touch provisioning kit is the ATECC508AMAHAW Cryptoauthentication device that comes preconfigured to run the authentication process against the user’s AWS IoT account. The first step is to learn what the chain of trust is by using the new Python scripts, as well as learning about the provisioning process that goes on through Microchip’s factories during the provisioning phase. To a certain extent, the kit shows how the in-manufacturing process principles work.

In addition, the device has strong resistance against physical tampering, including countermeasures against side attacks. It also has a high-quality Federal Information Processing Standard (FIPS) compliant random number generator, low power – cryptographic accelerator, for compatibility with the widest range of resource-constrained IoT devices and the ability to seamlessly accommodate various production flows in a cost-effective manner.

To help bridge the gap between embedded engineers and IT professionals, in addition to the Python script on-boarding experience, the kit comes with CloudFormation script to accelerate the AWS account setup, and ultimately make the Cloud experience more teachable. Using a CloudFormation script, the user can define a user interface (UI) within the AWS environment in a matter of minutes.

Conclusion

The combination of the Just in Time Registration (JITR) from AWS IoT with the ATECC508MAHAW CryptoAuthentication device, and the in-manufacturing secure provisioning process from Microchip, offers best-in-class IoT security. This true end-to-end IoT security solution enables Industry 4.0 security success towards safe and efficient growth.


Contact Details and Archive...

Print this page | E-mail this page