Phoenix Contact
Secure identification through digital certificates
Due to increasing digitalization, IT security is playing an increasingly important role in the automation of machines and systems. The secure identification of components is proving to be a particular aspect of this - both when taking possession and during operation.
As part of digitalization, more and more components are being networked with each other. The Internet Protocol (IP) is also used internally on the network. By using this, it is possible to communicate freely within the network and not be restricted to a certain range. At the same time, the need to secure data transmission is increasing. Among other things, this aspect means that the remote station can be reliably identified before the sender forwards sensitive data, for example. Such identification must also be possible via the network, i.e. digitally.
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 implemented in this context: On the one hand, certificates can be used that were already applied when the respective device was manufactured, so-called "initial device IDs". On the other hand, the user can issue the certificates themselves. These are referred to as "Local Device IDs". A description of the certificates can be found in the international standard IEEE 802.1AR [1].
Composition of the electronic key
The electronic certificate is typically presented when the communication connection is established. Technically, several elements are used. An electronic key consists of two parts: One part is private and only known to the owner. The second, publicly accessible part is embedded in the electronic certificate. If the private part of the key is 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 the key generation is of a high quality. This procedure results in a very high level of trustworthiness of the electronic key.
Trustworthiness of the device certificate
The author: Dr.-Ing. Lutz Jänicke is Corporate Product & Solution Security Officer at Phoenix Contact, Blomberg.
© Phoenix ContactThe public key is stored in an electronic certificate. This certificate then contains further attributes, such as the manufacturer's name and the serial number of the product [1]. 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. They must protect the electronic keys they use to sign the device certificates against disclosure and misuse. For this purpose, the keys are also generated and stored in secure elements (Hardware Security Modules, HSM). Access to the HSMs is controlled in such a way that device certificates can only be retrieved by authorized parties in production. The infrastructure and production processes of the device manufacturer must be designed in such a way that only original devices can receive such a device certificate, so that users have confidence in the proof of authenticity.
|
Forum Safety&Security 2022 |
|---|
|
From September 21 to 22, 2022, everything at Landshut University of Applied Sciences will revolve around the topic of safety and security in IT and OT. The program is now online. The keynote speech will take participants into the 'digital underworld' and is dedicated to the 'anatomy of an attack': speaker Tim Berghoff, Security Evangelist at G Data CyberDefense, will take participants on an imaginary journey from the security vulnerability to the blackmail message. Because no one can be safe from attacks. After this prelude, the program continues with two tracks: while one track is dedicated to methods and tools for safety and security, the other dives deep into the security aspects and problems of applications. |
The degree of trustworthiness of the device identities results from the interaction of the technical and organizational elements of this Public Key Infrastructure (PKI). The RFC 3647 [2] 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
Figure 1: Authenticity check of supplied components using the device certificates issued by the manufacturer PKI.
© Profinet Protocol Security v1.05. s.l.: PNO, 2019Various standards and norms explicitly require the secure handling of device identities in order to enable secure operation in the automation solution. In addition to the aforementioned IEEE 802.1AR (1), 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 keystores if a security level of greater than or equal to "3" is to be achieved (requirement CR 1.9).
Requirements and concepts for secure commissioning and secure operation are set out in various places, for example in the "Security Extensions for Profinet" [3] or for OPC UA in the "Device Provisioning" section [4]. 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 supplied device(Figure 1). The component is then assigned an identity in the operator network(Fig. 2). This operator certificate is now used for the actual data transmission in the automation system. The manufacturer certificate would only be needed again if the component is to be resold, for example.
Figure 2: Manufacturer and operator certificate: After taking possession, the operator certificate used during operation is also uploaded.
© Profinet Protocol Security v1.05. s.l.: PNO, 2019Checking the device certificate
The realization of secure device identities begins with the use of secure key memories - such as TPMs - in the relevant products. The key pairs must be generated securely during production. A certificate signing request is then sent to the PKI in order to obtain a device certificate. As this process can only take place at predetermined checkpoints, 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 in the context of the supported protocols. The component manufacturer provides the trust anchors (root certificates) if they are not already integrated into the applications. For example, the engineering software used to program a controller (PLC) already includes the trust anchors for the respective controllers so that the user does not have to take any further steps.
Figure 3: Typical contents of a device certificate: Manufacturer name, device type and serial number.
© Phoenix ContactThe verification of the device certificate consists 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 duly 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 analyze the digital signatures. It is then necessary to check whether the device certificate also matches the component. In accordance with IEEE 802.1AR, the following properties are stored for this purpose:
Figure 4: Digital rating plate with QR code for identification and reference to further information.
© Phoenix Contact- organizationName (O): Name of the manufacturer,
- commonName (CN): Device type,
- serialNumber (SN): Serial number of the device(Fig. 3).
Additional entries can also be stored. In the context of the development of the digital type plate, in which a URI is specified via a QR code applied to the device, this URI can also be stored in the certificate(Figure 4).
| Establishment of a device PKI |
|---|
|
Phoenix Contact offers automation components that are suitable for use in environments with high security requirements. The security quality is guaranteed thanks to the development process certified in accordance with IEC 62443-4-1. The AXC F 2152 PLCnext controller is the first controller to be certified by TÜV Süd in accordance with IEC 62443-4-2. The company has established a device PKI that can be used to generate secure device identities in accordance with IEEE 802.1AR. The device PKI is operated according to high procedural standards, which are documented in the Certificate Policy and Certification Practices Statement. The processes are supported by a secure technical implementation. The PKI, which is implemented using specialized appliances, is used in Phoenix Contact's secure data center. Certified hardware security modules protect the electronic keys. In this way, the controllers are comprehensively protected against cyber attacks. |
| Literature |
|---|
| [1] IEEE 802.1AR - Standard for Local and Metropolitan Area Networks - Secure Device Identity. s.l. : IEEE Standards Association, 2018. |
| [2] RFC 3647: Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework. s.l. : IETF, 2003. |
| [3] Profinet Protocol Security v1.05. s.l. : PNO, 2019. |
| [4] OPC Unified Architecture Part 21: Device Provisioning (in preparation). s.l. : OPC Foundation, 2022. |
You might also be interested in
Securely wired and plugged in
When developing the M12 push-pull quick connector in accordance with IEC 61076-2-010, the aim was to retain proven features and add innovative ones. As a result, the familiar features of the M12 connector are combined with the functions of push-pull...
read more...From Edge to AI
In the run-up to SPS Connect, Ulrich Leidecker, Chief Operating Officer at Phoenix Contact, reviewed 2020. And gave an outlook on developments in the new year.
read more...New Automation Management Board strengthened
New Automation, the training association for industrial companies in the field of automation technology, has expanded its board and set up new projects for young talent.
read more...Monitor and protect DC microgrids
Sustainable production using renewable energies begins with the establishment of an industrial DC grid. A multifunctional DC switching device is responsible for switching, protecting, monitoring and precharging DC sectors.
read more...The e-paper of issue 08/2024
How can data centers be cooled for AI? How successful is malware programmed with WormGPT? And how can virtualized control systems be integrated into production using TSN? Computer&Automation issue 08/2024 provides answers to these questions and...
read more...Frank Stührenberg hands over to Dirk Görlitzer
Frank Stührenberg will hand over the chairmanship of the Phoenix Contact management board to Dirk Görlitzer at the end of the year. Until then, there will be dual leadership.
read more...Frank Stührenberg hands over to Dirk Görlitzer
At the end of the year, Frank Stührenberg will hand over the position of CEO of Phoenix Contact to Dirk Görlitzer. Until then, there will be dual leadership.
read more...New production facility in Mexico
In order to meet the growth potential of the North American market, Phoenix Contact is planning a new building for electronic and electromechanical production in Mexico. Production is scheduled to start after the first construction phase at the end...
read more...The top articles in April 2024
The most-read articles in April demonstrate the innovative strength of the automation industry and its ability to adapt new technologies.
read more...