All the latest news from the industry weekly compiled by the editorial team for you free of charge.
This eMail is already registered.
An unexpected error occured.
Please accept our Terms of Use.
Registration successful.

ROLE OF CONTROLLER Multiprotocol SoCs as the basis for data security

Sep 12, 2022

The increasing interlinking of IT & OT networks makes a complete cyber security strategy for the factory floor on the top priority. SoCs such as the netX 90 communication controller from Hilscher can now serve as its foundation. This article explains what role the controller plays, & what tasks does it perform. - Dirk Fischer, Software Product Manager, Hilscher

Cyber security already in the network controller

It began with harmless emails sent to selected employees of a steel mill, containing concrete information about the working environment or content. The emails were perfectly matched to the respective recipients, which made them barely noticeable in the usual day-to-day work life. But the emails were part of a treacherous plan to attack a German industrial company.

In the case of the attack on the steel mill the attackers ‘gained initial access to the office network’ through a spear phishing attack. This report was written by the Federal Office for Information Security (BSI) in its 2014 annual report. From there, the attackers gradually worked their way ‘into the production networks’. As a result, a blast furnace of the mill could not be shut down properly, leading to ‘massive damage’. The incident took place eight years ago, but in the meantime the threat situation has likely worsened further. The main reason for this is the increasing convergence of information and operating technology with the progressive digitalisation of plants.

It is not enough to isolate systems

For a long time information technology (IT) was clearly distinguished from operational technology (OT). While standard security concepts and tools are used on the IT side, these are largely absent on the OT side. The reasons for this are the heterogeneous nature of the plants, embedded systems with highly limited resources and long maintenance intervals. They relied on firewalls and having the smallest possible number of interfaces. Access to data at operating level was usually not possible from the company network, and certainly not from outside, for example via the internet.

While isolation helps reduce risk, though, it does not fundamentally solve the problem. For example, it does not protect against the installation of compromised devices by employees, or the unintentional use of USB sticks containing hidden malware behind the firewall.

Convergence brings benefits but also risks

The blurred border between IT and OT networks and the creation of new interfaces and access to the field level increase the transparency & visibility of production processes. This enables new technologies to increase productivity, among other benefits, and enable new business models when applications in the cloud can access the field level directly.

Plant owners want to exploit these advantages but must take into account and minimise the risks associated with them. Operating technology must be secure if fraudsters are to be prevented from exploiting transparent processes and better access to them. This is increasing the pressure on field device providers to equip their products with cyber security functions.

Standards help meet new challenges

IEC 62443 has been developed over the last few years in order to standardise the cyber security requirements on field devices. It is a standard consisting of 14 parts which takes a comprehensive view of automation systems. The various roles, including operators, system integrators and component manufacturers, as well as the entire lifecycle of automation systems are considered. Both development processes and technical functions are defined in the standard. Plant owners will increasingly demand that component manufacturers comply with the requirements defined in the IEC 62443 standard and develop and equip their devices accordingly.

Secure hardware is the foundation

This demands suitable hardware. With the netX 90 communication controller from Hilscher, such requirements were considered as early as the concept phase, and the corresponding functions were implemented.

The netX family and the netX 90, its newest member, serve to connect devices to industrial real-time Ethernet and traditional fieldbuses. The communication ports of the netXSoCs can be configured flexibly for any relevant industrial protocol; all that is needed is to reload the protocol firmware. In addition to the netX hardware, Hilscher supplies the protocol firmware in a wide variety of both master and slave versions. These include Profinet, Ethernet/IP and EtherCAT, but also less common systems such as Modbus TCP, CC-Link IE Field, Sercos III and even fieldbuses such as Profibus or DeviceNet.

As stated at the beginning, however, it is no longer sufficient to reliably transfer the process data between the device and the controller: The data must also be protected during the exchange, i.e., kept safe from manipulation and from being read by third parties. In addition, devices themselves must be protected from manipulation, such as the unauthorised installation of firmware, and must identify themselves to other participants as a trusted device.

Cryptocore accelerates security-related algorithms

At the heart of the security features of the netX 90 is the cryptocore. This is a hardware block that significantly accelerates cryptographic algorithms. Hardware acceleration is mandatory, especially when encrypting and decrypting cyclic process data, if the negative impact on performance, in this case the cycle time, is to be kept to a minimum. The encryption of larger amounts of data is usually performed with symmetric block cipher methods such as the Advanced Encryption Standard (AES). With key lengths of 256 bits, the hardware accelerates this algorithm by at least a factor of 15 compared to a pure CPU calculation. Asymmetric encryption methods are used to authenticate subscribers, sign messages, and establish a secure connection. Instead of a common security key, as used in symmetric procedures, a pair consisting of a private and a public key is used. Such procedures require even more processing time. The netX 90 cryptocore provides support for the popular RSA (rivestshamir-adleman) and ECC (Elliptic Curve Cryptography) methods. In addition, it offers other auxiliary functions such as a true random number generator and SHA as well as MD5 hash value calculation in the hardware.

This means that the software initially has a hardware function module available that still has to be converted into concrete safety features.

Targeted use of hardware and software

Secure Boot is one such feature; it is guaranteed by ROM code and is therefore one of the hardware-related functions. After a power-on or reset, the fixed, unchangeable ROM code takes over control. It checks the integrity of the firmware from the internal flash memory before the firmware is started. The root of trust is a public key which is installed by the device manufacturer in a secure, protected area of the flash memory. The firmware is signed using a private key from the device manufacturer. During the boot process, the ROM code uses the public key and firmware signature to verify its authenticity and integrity.

Communication at field level is secured by means of proven methods of information technology. Transport Layer Security (TLS), for example, is used in almost all web servers to enable HTTPS-encrypted communication between the clients, in this case a web browser, and a website. Exactly the same technology is also used for communication by Ethernet/IP between field devices and the controller.

Hilscher uses the mbed-TLS implementation in its Ethernet/IP CIP security protocol firmware. This can be considered a security software kit that is placed above the TCP/IP stack and uses hardware functions of the cryptocore. Essentially, this central software component ensures 3 aspects:

  • A connection is only established with trusted devices. Devices must mutually authenticate themselves.

  • The integrity of the exchanged data is ensured. This allows the manipulation of data to be detected and countermeasures taken.

  • Data can be encrypted if required. This means that even secret and confidential information can be exchanged at field level.

All these tasks are handled by the protocol firmware, so users do not have to worry about it on the application side.

The above features require the presence of digital security certificates. Among other information, they contain the identity of a device or user, a public key, and a signature that ensures the authenticity of the certificate.

Certificate management using Authentication Manager

Management of the certificates is handled by a separate software component within the protocol firmware: Authentication Manager. The user interface allows certificates and private keys to be transferred from the outside into the device or generated directly in the device. Simple applications such as the use of self-signed certificates or integration into an external public key infrastructure (PKI) can therefore be implemented. Protocol-specific certificate deployment mechanisms are also supported.

A second functional area of Authentication Manager is role-based user administration. This can, for example, be used by the web server to restrict access to individual pages for specific groups of users.

Secure with the netX 90

The implementation of security features is costly and time-consuming even without implementing new, productive functions. That is why many device manufacturers are still reluctant to get involved. They are going to have to think again, however. In view of the high risks and costs associated with incidents such as the hacker attack on a steel mill described above, plant owners are increasingly demanding compliance with IEC 62443 requirements. With its security firmware, the netX 90 has started to overcome the obstacles for device manufacturers. (ak)

Image Gallery

  • Block diagram of the loadable firmware

    Block diagram of the loadable firmware

  • Dirk Fischer
Software Product Manager

    Dirk Fischer

    Software Product Manager


Companies related to this article
Related articles