Building trust as a foundation for industrial networks following IEC62443

This article originally appeared in the March'23 magazine issue of Electronic Specifier Design – see ES's Magazine Archives for more featured publications.

The consequences of such attacks can be wide ranging and serious, compromising strategic national assets such as power distribution and transportation networks, loss of revenue in manufacturing and jeopardising the safety of humans through potential exposure to hazardous substances.

To mitigate these risks, major industry players have contributed to the formulation of ISA/IEC 62443, a set of standards and technical specifications intended to address the security needs of the Industrial Automation and Control Systems (IACS) that make use of operational technology.

To protect operational technology from serious consequences of cyberattacks the standards require increased security protocols to prevent failures from occurring. For example, if an operator gets caught in machinery, making four or more attempts to stop the machine is not acceptable. Divided in to four tiers, the part that is of most interest to semiconductor manufacturers and users is part four, ‘Components’.

This focuses on specific security-related requirements for products and components. It covers both the technical contents of those products, as well as the processes used to manage them throughout their lifecycle. IEC 62443-4-2, Technical Security Requirements for IACS components, defines technical requirements for products or components.

Security levels As well as the technical requirements, the standard also defines five security levels, from zero to four.

0: No special requirement or protection provided

1: Protection against unintentional or accidental misuse

2: Protection against intentional misuse by simple means, with few resources, general skills as low motivation

3: Protection against intentional misuse by sophisticated means with moderate resources, IACS specific knowledge and moderate motivation

4: Protection against intentional misuse using sophisticated means with extensive resources, IACS specific knowledge and high motivation

Beyond the security levels, the specification also defines seven Foundational Requirements.

1. FR1 Identification and Authentication Control (IAC)

2. FR2 Use Control (UC)

3. FR3 System Integrity (SI)

4. FR4 Data Confidentiality (DC)

5. FR5 Restricted Data Flow (RDF)

6. FR6 Timely Response to Events (TRE)

7. FR7 Resource Availability (RA)

An easy way to simplify the foundational requirements is to remember the term CIA, confidentiality, integrity, availability, which represents all seven. To help meet these requirements, Microchip has published an application note called AN3983. As well as an explanation of the salient points of the standard, it offers a table that refers to the component requirements of the standard and shows how the ATECC608 or TA100 secure authentication ICs can act as a technology enabler to help a manufacturer’s product meet each of the requirements.

Security trends

There are some common security themes across the industrial industry. The number one use case to be implemented is Secure Boot. The motivation for Secure Boot is the need to verify that the code running on a host, the bootloader, is in a trusted state. During its first stage, you would make sure that you can verify the incoming signature of a signed firmware payload that will be verified in your host microcontroller – only then would we allow that host microcontroller to be upgraded.

An expansion of this notion of over-the-air updates would involve routinely upgrading the behavior of your platform and patching any firmware bugs. Secure firmware upgrades in the field should also have the same sort of mechanism, using a public key to verify that incoming public signature and then, in the field, upgrading the behaviour of that platform. Then there is message authentication – you may trust the code that's running in your system now, but each of the nodes needs to communicate with each other within your factory. This means it's important to be able to verify the source of the message cryptographically. A secure authentication IC is important here because you can use things such as AES-based CMAC to verify the source of the message, or HMAC, in either event you would need to use keys to support that use case. This means messages go around the network, and you only respond to messages with a successful cryptographic authentication code. If a hacker gets access to the network and starts sending spoof messages, the other nodes will see that this is not an authenticated message and discard it.

By logging failed authorisation attempts, the main host in the network could take action and maybe even isolate a node that the suspect messages originate from. The third aspect is cryptographically verifying that a particular piece of hardware, for example an industrial pump, is intended for that industrial ecosystem. If a pump fails, the replacement pump is unknown to the system. The main controller in that network could query that pump for its X509 certificate. It could verify the signature of the certificate and see that it chains back to the correct industrial OEM, and then would send a challenge to have that pump use a key in a secure element like the ATECC608 or TA100.

Built in security

The first step in building in trust to the industrial network is to have a trusted silicon to store key certificates and immutable data. The second step is to implement the use cases described above, such as Secure Boot, message authentication or accessory authentication.

The last step is moving from the development phase to a manufacturing phase. This is what we call secure key provisioning – injecting key secrets and certificates into secure elements. This provisioning must be secure, and for vertical segments, there are some standards. The most common one is the common criteria standard. This ensures that the manufacturing is done in a secure manner, so it includes physical protection of the area of the manufacturing plant, including restricting access to the physical IT resource. It's also about the electronic protection, securing the network in terms of the provisioning, access control, back-up, and storage resources.

Another aspect is organisational protection – how to transfer the information, how to manage the security personnel, how to grant access to these personnel, how to manage the maintenance personnel not directly involved in the provisioning.

How do we implement this within Microchip?

Microchip has a secure and standard process to perform what we call the secure change process, a way to bind the secret information (data, keys, certificates) from the customer to Microchip’s secure world in order to perform the provisioning with unique information.

This process is very secure, as it is based on secret exchange package to leverage Microchip’s Hardware Security Module (HSM) infrastructure. The process enables the implementation of the use cases and the generation of the secure exchange package. This will be encrypted then transmitted directly into Microchip’s protection in the HSM. The information will then push to go through the testers, maintaining a fully secure flow from the customer HSM to the secure elements. This is done inside Microchip’s secure factories, which have been audited by 3rd party security labs.

Following this, we can deliver the product to the customer. The shipment process is also defined under the common criteria standard, which ensures that the secure elements are protected during delivery to customers. It also ensures traceability in the supply chain, forming a full process. In summary, we can say that the most important aspect about building trust is not simply the silicon – it's a combination of the silicon, the use cases, the provisioning and the supply chain which, at the end of the day, will enable a customer to manufacture their end system before going live in the field.