With recent advances in manufacturing such as automation, remote manufacturing and control concepts, we’re entering the age of Industry 4.0. While the benefits are immense, it has also poses certain risks. For example, if the factory is connected to an offsite data centre through a public or private cloud, network security is a concern.
A connected factory exposes machinery to the risk of unwanted access, which could lead to the machines getting corrupted. At the same time, it impacts production, thereby directly compromising company revenue.
There are some common practices one can take to minimise the risk. Firstly, irrespective of whether you intend to use a wired, wireless or combination solution, ensure that the connectivity technology you choose has standard protocols (such as Wi-Fi®, Bluetooth® etc.). Also, while the industrial segment traditionally prefers proprietary solutions, it makes sense to use standard practices since they run a lower risk of being compromised.
One of the biggest challenges in maintaining security of remote factories is the skill gap among embedded engineers. Most embedded engineers tend to be unfamiliar with cloud infrastructure and IT security concepts. Therefore, they often struggle to create robust and secure IoT infrastructures without the support of IT experts.
Even a single weak link exposes the entire system to hackers, who typically seek just a single point of entry to obtain remote access to a large number of systems. We have seen several recent examples of large-scale damage caused by Distributed Denial of Service
(DDoS) attacks1. Since the weakest link in an IoT network is generally the hardware, the lack of IT knowledge among hardware engineers becomes even more problematic.
The industry is taking steps to address this issue. For instance, embedded chip companies, including Microchip Technology, are doing their part to bridge this knowledge gap. They are working to educate engineers on steps to take to ensure end-to-end secure infrastructure. The major cloud players such as AWS, Google and Microsoft also have a role to play in sharing expertise, as well as PKI management companies such as Kyrio. Knowledge aside, it also requires a mindset change. Many times, IoT implementations tend to consider the security aspect only after the entire network has been designed, which exposes it to security risks. Instead, it is important to take a strategic view of security and incorporate it right at the hardware stage, rather than as an afterthought.
Authentication Mechanisms
A flawless authentication mechanism is one of the most important components to consider while designing a secure system. Because every node is at risk of facing a security breach, it is critical that every node in the network has a unique identity that is protected, trusted
and managed. At all times, it is important to have visibility into who is on the network. Are they who they say they are? Can they be trusted? Can they be monitored? To answer these questions, most systems traditionally use a TLS 1.2 protocol. In this protocol, mutual authentication between a server and an IoT end node happens through a certificate authority, something that both sides trust.
There is, however, a downside to this. For this system to work, one needs to ensure protection of the trust issued by the certification authority all the way – right from the start of the project to the manufacturing to the time the system is deployed. At the IoT end node, the security and protection of the private key needs to be ensured because this key is used to recognise the authenticity of the node.
The problem is that most organisations commonly store the private key within a microcontroller in the clear of a flash memory. This practice is risky because the private key is vulnerable to software manipulations. This makes it possible for anyone to access and look at this memory zone, control it and then obtain the private key.
Even worse, the presence of an authentication mechanism gives the designers of the network a false sense of security, which is the biggest danger that puts the system at risk.
There are two important measures that organisations need to take to take to ensure that the key is protected and secure. The first is to isolate the key and the second is to provision the chip with the key.
Isolating the Key Through a Secure Element
In order to ensure security of the key, it needs to be removed from the microcontroller. Not only that, but the key and other critical credentials have to be isolated from the microcontroller and from any potential software exposure.
One useful concept here is that of a secure element. The idea is to basically provide a safe haven for the key, where no one can assess it. In order to validate authentication, all appropriate challenges/responses from the microcontroller need to be sent to the secure element based on commands from the CryptoAuthLib library. The private key is never exposed, nor does it ever leave the secure element, whether during the product development process or the product lifecycle. This helps to ensure an end-to-end chain of trust.
The secure elements are essentially stand-alone CryptoAuthenticationTM Integrated Circuits (ICs) that hold the private keys needed for IoT authentication. Conceptually, they are similar to a safe, where companies store important documents and secret files.
Getting started with Google Cloud IoT Core secure authentication
A different approach to certificate-based mutual authentication is proposed with the ATECC608a combined with a Cortex-M0+ ATSAMD21 and WINC1500 Wi-Fi network controller connected to Google Cloud IoT Core. The implementation uses a JSON Web based Token (JWT). When an MQTT connection occurs, the CryptoAuthLib hosted in the ATSAMD21 generates the JWT token. A part of the token is hashed and presented to the ATECC608a that will provide an ECDSA signature of the token using the private key hosted in the ATECC608a. This is appended to the rest of the token in the MQTT message in the microcontroller. The signed token is placed in the password location of the MQTT message, which is then presented to Google Cloud IoT Core. Previously, the corresponding public key has been loaded in the Google Cloud IoT Core account which would verify that the signed token is genuine. The TLS and TCP/IP stacks are hosted in the WINC1500, enabling the smallest microcontrollers to be connected securely.
Conclusion
The in-manufacturing secure provisioning process from Microchip with the ATECC608a CryptoAuthentication device, coupled with the Just in Time Registration (JITR) from AWS IoT or the JWT based authentication on Google IoT Core platform, offers best-in-class IoT security. With this true end-to-end IoT security solution, Industry 4.0 security can be ensured to successfully drive safe and efficient growth.
