How to Use OPC UA for Secure Communications

OPC UA has been widely touted as a secure industrial communications technology for Industrial Internet of Things (IIoT) and Industrie 4.0 applications. In fact, Plattform Industrie 4.0—developer of the Industrie 4.0 reference architecture model (RAMI)—cites OPC UA as the approved standard for RAMI’s communication layer.

To help industrial end users, system integrators, device vendors and OEMs better understand OPC UA’s role in securing industrial communications systems and how to apply the technology, the OPC Foundation has released a white paper “detailing practical guidelines for the secure configuration and use of OPC UA in industry.”

The paper was developed following the OPC Foundation’s establishment of a security user group. Led by Uwe Pohlmann, a research fellow at the Fraunhofer Institute for Mechatronic Systems Design (IEM), and Axel Sikora, an electrical engineering professor at the University of Applied Sciences Offenburg, the group includes representatives from Ascolab, Beckhoff Automation, DS Interoperability, exceet Secure Solutions, Fraunhofer IEM, Hochschule Offenburg, Microsoft Corp., Software AG, Sparhawk Software Inc., and TE Connectivity.

In support of this group’s efforts, the German government-sanctioned Intelligent Technical Systems’ OstWestfalenLippe organization to supply the group with key use cases and requirements to ensure that output from the group addresses the needs of industrial end users.

A seemingly obvious, but critical point is that, although OPC UA is secure by design, “you have to use the security features it provides to reap the benefits,” says Erich Barnstedt, principal software engineering lead, Azure Industrial IoT at Microsoft. “The security configuration task can be simplified dramatically when an OPC UA server is secure by default; that is, all security features are already turned on when the customer takes the server out of the box for the first time. It is also important for device vendors to make the security configuration as simple as possible, for example, by providing wizards and easy-to-understand guidelines. We can’t expect OPC UA server users to be security experts.”

The white paper details six specific factors on how to secure industrial communications with OPC UA, including:

• Security Mode: According to the white paper, the OPC UA Security Mode “should be [set to] ‘Sign’ or ‘SignAndEncrypt’. This ensures that authentication at the application level is forced. Security Mode ‘SignAndEncrypt’ must be used if integrity and confidentiality of data has to be protected.”
• Selection of cryptographic algorithms: “At a minimum, the Security Policy ‘Basic256Sha256’ should be chosen…[if] any existing client the server needs to interact with also supports this policy. Weaker security policies use outdated algorithms and should not be used. For example, SHA-1 is no longer secure and should not be used.”
• User authentication: The white paper cautions that the identifier ‘anonymous’ should be used “only for accessing non-critical UA server resources as it does not provide any protection. It is not possible to trace who has changed the data or configuration on the server side when this generic identifier is used. Also, an attacker could use this identifier to read or write data in an unauthorized manner if no adequate restriction of the rights of the identifier ‘anonymous’ was configured.”
• Certificate and private key storage: “Never store private keys or the corresponding certificate files on an unencrypted file system. Use the dedicated certificate stores of your operating system and use operating system capabilities for setting the access rights.”
• Using certificates: Connections that do not provide trusted certificates should not be accepted, according to the white paper. The document further notes that “self-signed certificates should not be trusted automatically, which means without an additional verification. If the certificates are not self-signed, a Certificate Authority (CA), e.g., for all OPC UA applications of a company, is required.” This means that “the certificates of the CA are either self-signed or signed by another CA.”
• Managing and maintaining certificates: “Use certificate trust lists and certificate revocation lists to manage valid certificates. Only trusted users or processes should be allowed to write these lists. The lists should be updated regularly.”

Explaining the need for this white paper, Eric Bodden, professor of software engineering at Paderborn University and director of software engineering at Fraunhofer IEM, says, “Currently, users and developers are overwhelmed with making security decisions during their daily job. Incorrect use of security features causes many security vulnerabilities due to difficulties using software [applications] and a lack of security knowledge. Documentation, tutorials and good examples are often missing.”

The OPC Foundation has already announced that a second whitepaper presenting best practices and selected use cases for a secure implementation and operation of OPC UA is planned for release in 2018.