Ensuring security when connecting industrial embedded systems to the cloud

Electronics Technical ArticlesSouth-East European INDUSTRIAL Мarket - issue 4/2019 • 07.11.2019

 

Xavier Bignalet, Microchip Technology

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 is not just the high capital value of the machinery that’s being put at risk, but also the amount of corporate revenue from the goods that are produced through the factory at a given time could be compromised as well.

 

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

A good starting point is to determine whether the solution will use a wired, wireless or combination solution. From there, it is recommended to use connectivity technology that has standard protocols, such as Wi-Fi, Bluetooth or Ethernet, to name the most well known in the industrial segment. Usage of standard practices for security lowers the risk of the connections being compromised. It sometimes goes against the historical habits of the industrial segment which is 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 for in-house use and not for external connections.

One of the problems though is that even the most highly-qualified embedded engineers 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 will quickly find that they need help from IT experts to handle the wide range security threats that they are now up against.

For hackers, one of the main targets is to leverage a single point of access to obtain remote access to a large amount of systems. Remote attacks can create large-scale damage as a recent onslaught of attacks, such as the 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 as the engineers looking after this normally lack the IT knowledge to deal with the problem.

This is changing. Companies such as Microchip Technology see it as part of their mission to fill 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 important sources of expertise. The big lesson is not to neglect security or avoid considering it as 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

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 done using information that both parties trust - a certificate authority.

However, this only works if the trust issued from the certification authority is protected all the way from the start of the project, through manufacturing and once the system is deployed 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 the clear of a 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 happen.

 

Secure element

For a secure solution, 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 stand-alone CryptoAuthentication Integrated Circuits (ICs) that can be thought of as the 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. 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 in their behalf using the Use Your Own Certificate function from AWS. Then, they use the AWS IoT function called just-in-time registration (JITR) to perform a bulk upload of the device-level certificates stored and provisioned in the secure elements to the AWS IoT user’s account. The customer-level certificate can now verify the device-level certificate and the chain of trust is now 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 just-in-time registration (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 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 pre-configured to run the authentication process against the user’s AWS IoT account. The first step is to learn what a 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. The kit shows how the in-manufacturing process principles work, to a certain extent. 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 make the Cloud experience more teachable. Using a CloudFormation script, the user can define a User Interface (UI) within the AWS environment in minutes.

The combination of the Just in Time Registration (JITR) from AWS IoT combined with the ATECC508MAHAW CryptoAuthentication device and the in-manufacturing secure provisioning process form 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.

 

LATEST issue 4/2019

issue 4-2019

ALL ARTICLES | ARCHIVE

Top