Due to increasing digitalization, IT security plays an increasingly important role in the automation of machines and plants. One particular aspect is the secure identification of components – both during takeover and in operation.

More and more components are being networked with each other due to digitalization. The Internet Protocol (IP) is used above all in the internal network. Its use makes it possible to communicate freely on the network and not be restricted to a specific area. This has been a particularly important aspect since the start of the Corona pandemic and the associated establishment of the home office. 

At the same time, there is an increasing need to secure data transmission and to find out whether the recipient of the data is a secure contact. This is particularly important when it comes to transmitting sensitive data. Such identification must also be possible via the network, i.e., digitally.

In the following article, you will learn how you can ensure secure identification, what requirements arise in the process, and how you can check device certificates. We hope you enjoy reading.

Support for secure identification

Current transmission protocols – such as https or OPC UA – support the secure identification of the communication partner with the help of digital certificates. Various applications can be realized here: On the one hand, certificates can be used that were already applied when the respective device was manufactured, so-called “initial device IDs”. However, the user can also assign the certificates himself. These are then referred to as “Local Device IDs”. A description of the certificates can be found in the international standard IEEE 802.1AR.

Composition of the electronic key

The electronic certificate is usually presented when the communication connection is established. Technically, several elements are used. An electronic key consists of two parts. One part is private and known only to the owner. The second, publicly accessible part is embedded in the electronic certificate. If the private part of the key has been generated and stored in a secure element – for example, a Trusted Platform Module (TPM) – it cannot be stolen or copied. Secure elements also ensure that key generation is performed in a high-quality manner. This process results in very high trustworthiness of the electronic key.

Trustworthiness of the device certificate

The public key is stored in an electronic certificate. This certificate then contains further attributes, such as the name of the manufacturer and the serial number of the product. The certificate is then signed by the issuer (Certification Authority, CA) and thus becomes proof of authenticity. The trustworthiness of the certificate must be ensured by the device manufacturer. The manufacturer has its own electronic keys with which it signs the device certificates and protects them from disclosure and misuse. For this purpose, the keys are also generated and stored in secure elements (hardware security modules, HSMs). Access to the HSMs is controlled so that device certificates can only be retrieved by authorized parties in production. Of course, the device manufacturer’s infrastructure and production processes must also be designed in such a way that only original devices can obtain such a device certificate, so that users have confidence in the proof of authenticity.

The degree of trustworthiness in the device identities results from the interaction of the technical and organizational elements of this Public Key Infrastructure (PKI). The RFC 3647 standard explains how the PKI processes can be documented in a comprehensible manner in the Certificate Policy (CP) and the Certification Practices Statement (CPS). In this way, the trustworthiness of the device identity can be assessed.  

Requirements from the relevant standards and norms

Various standards and norms explicitly require the secure handling of device identities to enable secure operation in the automation solution. In addition to the aforementioned IEEE 802.1AR, which describes certificates for device identities, IEC 62443 “Security for industrial automation and control systems”, for example, specifies that identities based on secure keys must be used in secure key stores if a security level of greater than or equal to 3 is to be achieved.

To read more about the different levels of security, follow this link to our blog post, “Next Level of Security: PLCnext Control“.

Requirements and concepts for safe commissioning and safe operation are presented in various places, for example in the “Security Extensions for Profinet” or for OPC UA in the “Device Provisioning” section. The procedure always follows the same pattern. As a prerequisite for secure identification, the components must have manufacturer certificates that can be used to check the authenticity of the device supplied. The component is then assigned an identity in the operator network. This operator certificate is now used for the actual data transmission in the automation system. The manufacturer’s certificate would only be needed again if the component were to be resold, for example.

Checking the device certificate

The realization of secure device identities starts with the use of secure key stores – such as TPMs – in the corresponding products. During manufacturing, the key pairs must be generated securely. A certificate signing request is then sent to the PKI to obtain a device certificate. Since this process can only take place at predefined verification stations, only authorized devices receive an x.509 certificate that can be traced back to a trust anchor (root certificate) of the device PKI. The certificate is now stored in the device and can be used for authentication within the supported protocols. The component manufacturer provides the trust anchors (root certificates) if they are not already integrated in the applications. For example, the engineering software for programming a controller (PLC) already contains the trust anchors for the respective controllers, so that the user does not have to take any further steps.

The verification of the device certificate is composed of two elements. In the first step, the certificate chain up to the trust anchor must be correct. This means that each certificate has been properly signed by the next higher instance up to the trust anchor – the root certificate. The trust anchor itself must have been obtained from the device manufacturer and stored in the appropriate certificate store. As a rule, software libraries perform the analysis of the digital signatures. After that, it is still necessary to check whether the device certificate also matches the component. According to IEEE 802.1AR, the following properties are stored for this purpose:

•     organizationName (O): Name of the manufacturer

•     commonName (CN): Device type

•     serialNumber (SN): Serial number of the device

Additional entries can also be stored. In the context of the development of the digital nameplate, where a URI is specified via a QR code applied to the device, this URI can also be stored in the certificate. In our PLCnext Control, for example, the QR code is applied to the housing. This acts as a digital nameplate for identification and reference to further information. From November 2022, PLCnext Control will be the first product to be equipped with corresponding certificates from the new infrastructure.