Reasoning on Adopting OPC UA for an IoT-Enhanced Smart Energy System from a Security Perspective

by   Stefan Marksteiner, et al.
Joanneum Research

Smart Services using Industrial Internet of Things (IIoT) applications are on the rise, but still more often than not, traditional industrial protocols are used to interconnect the entities of the resulting systems. These protocols are mostly not intended for functioning in such a highly interconnected environment and, therefore, often lack even the most fundamental security measures. To address this issue, this paper reasons on the security of a communications protocol, intended for Machine to machine (M2M) communications, namely the Open Platform Communications Unified Architecture (OPC UA) and exemplifies, on a smart energy system, its capability to serve as a secure communications architecture by either itself or in conjunction with traditional protocols.


Missed Opportunities: Measuring the Untapped TLS Support in the Industrial Internet of Things

The ongoing trend to move industrial appliances from previously isolated...

PropFuzz – An IT-Security Fuzzing Framework for Proprietary ICS Protocols

Programmable Logic Controllers are used for smart homes, in production p...

IoT based Smart Access Controlled Secure Smart City Architecture Using Blockchain

Standard security protocols like SSL, TLS, IPSec etc. have high memory a...

Smart-Lock Security Re-engineered using Cryptography and Steganography

After the rise of E-commerce, social media and messenger bots, rapid dev...

An Overview of Wireless IoT Protocol Security in the Smart Home Domain

While the application of IoT in smart technologies becomes more and more...

RadIoT: Radio Communications Intrusion Detection for IoT - A Protocol Independent Approach

Internet-of-Things (IoT) devices are nowadays massively integrated in da...

DTLS Performance - How Expensive is Security?

Secure communication is an integral feature of many Internet services. T...

I Introduction and Motivation

This paper aims on reasoning on the security of the Open Platform Communications Unified Architecture (OPC UA) for the use in a smart energy system (a controller and its managed devices). Concretely, it discusses whether using OPC UA is an appropriate method to secure communications for an Internet of Things (IoT)-based architecture that allows for advanced algorithms in low voltage distribution grids to improve efficiency and hosting capability. The original idea to provide this communications was via the in the industry widely proliferated protocol Modbus/TCP [1]. This protocol, however, is known to have severe security deficiencies [2]. It has therefore to be replaced or security-enhanced by another protocol. Both tasks could be achieved by OPC UA, as it both provides a standalone architecture for Machine-to-Machine Communication (M2M) and there is work to run OPC UA with Modbus [3]. The reason why OPC UA is deemed a suitable candidate for this type of communications is its standardization, proliferation and also its semantic interoperability [4]. This advanced flexibility and control will then facilitate the advanced use of renewable energy, as well as new service-based business models in the energy domain. Assuring the security of these communications, however, is a fundamental prerequisite for this intended technology to work without generating the risk of large-scale cyberattacks and the protocol’s capabilities in that matter are therefore . Another goal of this paper is to extend the author’s previous work on the security of IoT protocols [5] by adding a higher-level, industrial-use specification that allows for industry 4.0 and energy domain use cases.

Ii Related Work

There is a security analysis of OPC UA commissioned by the German Federal Office for Information Security (BSI) [6]. This work, however, was conducted over the course of the year 2015 and does therefore not take into account newer developments (see Section IV-B). In any case, as this work is quite comprehensive, it servers as a starting point for this paper, apart from the official OPC UA specifications in particular the security model [7] and the profiles [8].

Iii Protocol Description

The Open Platform Communications Unified Architecture (OPC UA) is a system architecture that is designed to exchange command and control information between industrial sensors, actuators, control systems, Manufacturing Execution Systems (MES) and Enterprise Resource Planning (ERP) Systems [9]. It therefore operates on all of the four upper layers of the IEC 62264 Enterprise-control system integration norms [10]. The architecture specifies the following [9]:

  • The information model to represent structure, behaviour and semantics;

  • The message model to interact between applications;

  • The communication model to transfer the data between end-points;

  • The conformance model to guarantee interoperability between systems.

In order to provide a platform-independent infrastructure logic to flexibilize host services for the Industrial Internet of Things (IIoT), enabling Machine-to-Machine Communication (M2M), it provides both a Client-Server and a Publisher-Subscriber (PubSub) model. To model the actual data it defines three encodings:

  • The Extensible Markup Language (XML) [11];

  • The JavaScript Object Notation (JSON) [12];

  • A native, binary encoding (UA Binary).

It further defines some protocols to transfer the modeled data:

  • OPC UA via the Transmission Control Protocol (TCP);

  • Via the Hypertext Transfer Protocol Secure (HTTPS);

  • Via WebSockets.

The architecture is an advancement of the Open Platform Communications (OPC), formerly called OLE for Process Control model [9]. The latter historically derives from the Microsoft Object Linking and Embedding (OLE)/Component Object Model (COM) [13]. The protocol has been internationally standardized as IEC/TR 62541 [14] by the International Electrotechnical Commission (IEC). Therefore, it enjoys widespread use.

Potential Process Crash or Stop for Managed Device Denial Of Service
Data Flow Downstream Is Potentially Interrupted Denial Of Service
Potential Process Crash or Stop for smart energy controller Denial Of Service
Data Flow Upstream Is Potentially Interrupted Denial Of Service
Elevation Using Impersonation Elevation Of Privilege
Elevation Using Impersonation Elevation Of Privilege
Managed Device May be Subject to Elevation of Privilege Using Remote Code Execution Elevation Of Privilege
Elevation by Changing the Execution Flow in Managed Device Elevation Of Privilege
smart energy controller May be Subject to Elevation of Privilege Using Remote Code Execution Elevation Of Privilege
Elevation by Changing the Execution Flow in smart energy controller Elevation Of Privilege
Weak Authentication Scheme Information Disclosure
Downstream Data Flow Sniffing Information Disclosure
Upstream Data Flow Sniffing Information Disclosure
Potential Data Repudiation by Managed Device Repudiation
Potential Data Repudiation by smart energy controller Repudiation
Spoofing the smart energy controller Process Spoofing
Spoofing the Managed Device Process Spoofing
Spoofing the smart energy controller Process Spoofing
Replay Attacks Tampering
Collision Attacks Tampering
Potential Lack of Input Validation for Managed Device Tampering
Potential Lack of Input Validation for smart energy controller Tampering
TABLE I: Threat Overview

Iv Security Analysis

This section contains a threat model description to determine the security properties deemed necessary for the current application, followed by an analysis of the OPC UA profiles for their general security and their features countering the identified threats.

Iv-a Thread Model

An adversary targeting the smart energy controller may have many potential goals (the list is non-exhaustive):

  • Extract information to draw conclusions on power consumptions, user behavior and billing information;

  • Extract information to achieve credentials to administrative accounts;

  • Manipulate values to achieve altered billings;

  • Take over the device to alter power flows;

  • Issue commands that stop the device from functioning;

  • Manipulate values to evoke illegal conditions that damage the device.

Technique to achieve this can be categorized into the following (according to the STRIDE methodology [15]):

  • Spoofing of user identity;

  • Tampering;

  • Repudiation;

  • Information disclosure (privacy breach or data leak);

  • Denial of service (DoS);

  • Elevation of privilege.

To analyze OPC UA an unsecured bidirectional communication line between an assumed intelligent energy manager and a managed device was modeled in the Microsoft Threat Modeling Tool 2016 [15], using generic data flows (see the graphical representation in Figure 1). This yielded in 5 DoS threats, 6 in privilege elevation, 3 in information disclosure, 2 in repudiation, 3 in spoofing an 4 in tampering (see Table I for details). The next sections will reason on the possibility to counter these threats using OPC UA.

Fig. 1: Graphic Threat Model Representation

Iv-B Analysis

IoT connections for industrial usage should provide at minimum the same level of security as the IEC 62351 standard [16]. This standard, however, does not necessarily assure end-to-end security [17]. Therefore, additional measures have to be taken to secure to provide a thoroughly secured connection. As stated in Section I, the OPC UA is deemed a suitable candidate to fulfill this requirement and moreover provide end-to-end security. It provides three cipher suites, all of which use the Advanced Encryption Standard (AES) for symmetric encryption, Rivest-Shamir-Adleman (RSA)-based asymmetric encryption with

Optimal asymmetric encryption padding (OAEP)

and Secure Hash Algorithm 2 (SHA2)-based systems for message signing. All of these suites have a signature length of 256 bits, channel nonce lengths of 32 bytes and asymmetric key lengths between 2048 and 4096 bits , as well as they are using the Cipher Block Chaining (CBC) mode of operation [8]. These combination of algorithms is currently deemed secure [18]. The only exception to the algorithms stated above is the use of the Secure Hash Algorithm 1 (SHA1) in the RSA-OAEP-SHA1 operation used for asymmetric encryption, which is, however, not regarded as a security issue, as RSA-OAEP only requires a hash function that has a neglectable possibility of producing all-zero sequences, which SHA1 fulfills111These are, however, only the necessary, not the sufficient security properties. There is yet no formal security proof for RSA-OAEP-SHA1.[19]. The underlying RSA-OAEP possesses a formal security proof [20]. A survey from the German Federal Office for Information Security (BSI) regarded Basic256Sha256 as the most secure of these suites [6]. This, however, referred to a previous version (1.2), whereas in the current (1.4) the Aes256-Sha256-RsaPss profile has been added. This profile differs from the former in that it replaces SHA1 with SHA2 in asymmetric encryption and the RSA Signature Algorithm Public-Key Cryptography Standards (RSASSA-PKCS) version 1.5 with the Probabilistic Signature Scheme (RSASSA-PSS) for asymmetric signatures. As the latest version of the defining standard [21] both recommends using SHA2 and requires using RSASSA-PSS for robustness reasons, the newer profile Aes256-Sha256-RsaPss is deemed superior over the one favored by the BSI. Furthermore, the IEC standard from 2015 [22] defines TLS 1.0, 1.1 and 1.2 as means to secure communications, although the newer technical specification by the OPC foundation only provides TLS 1.2 as single choice. This standard provides three choices for TLS, AES256 with RSA key exchange or AES128 and AES256 with Diffie-Hellman Ephemeral (DHE) key exchange, each using SHA256 for hashing and the CBC mode. Further principally defined algorithms are AES-CTR (symmetric encryption), RSA-PKCS15 (asymmetric encryption) and RSA-PKCS15-SHA1(signature) and P-SHA1 (key derivation), but these are not used in any profiles and therefore regarded as if not supported [8]. Table II provides an overview of the cryptographic algorithms used in the different OPC UA profiles.

In conclusion, using the Aes256-Sha256-RsaPss profile does mitigate the threats to information disclosure. It does also mitigate collision attacks and should, by specification, prevent replay attacks in conjunction with a sequence number. However, the BSI found out in its analysis that the provided reference implementation deviated from this specification, as the sequence number was not evaluated [6]. Other tampering-related attacks are in the devices’ scopes rather than in the protocol’s. This is similar to privilege elevation attacks; impersonation attacks can be mitigated by providing proper message authentication provided by the secure signatures in the profile, albeit, the other attacks of this category are in the clients’ scopes which also applies for client-based impersonation (which must be mitigated by secure client authentication, e.g. via secure passwords and/or second factors). Also, spoofing of processes has to countered on the client. The threats regarding DoS are infrastructural and, thus, need external counter measures, except for message flooding, which can be partially mitigated by rate limiting through artificial delays [6]. The repudiation is not explicitly stated, but non-repudiation for sent messages is in general, as far the communications protocol is concerned, provided by the usage of secure public key authentication and for received ones an issue of thorough logging, which is out of the protocol’s scope.

Name Aes128-Sha256-RsaOaep Basic256Sha256 Aes256-Sha256-RsaPss TLS_RSA_AES_256_CBC_SHA256 TLS_DHE_RSA_AES_nnn_CBC_SHA256
Symmetric Encryption AES128-CBC AES256-CBC AES256-CBC AES256-CBC AES128/256-CBC
Symmetric Signature HMAC-SHA2-256 HMAC-SHA2-256 HMAC-SHA2-256 HMAC-SHA2-256 HMAC-SHA2-256
Asymmetric Encryption RSA-OAEP-SHA1 RSA-OAEP-SHA1 RSA-OAEP-SHA2-256 RSA -
Asymmetric Signature RSA-PKCS15-SHA2-256 RSA-PKCS15-SHA2-256 RSA-PSS15-SHA2-256 RSASSA-PKCS15 RSASSA-PKCS15
Certificate Signing RSA-PKCS15-SHA2-256 RSA-PKCS15-SHA2-256 RSA-PKCS15-SHA2-256 RSASSA-PKCS15 RSASSA-PKCS15
Key Derivation P-SHA2-256 P-SHA2-256 P-SHA2-256 RSASSA-PKCS15 DHE
TABLE II: Currently Valid OPC UA Security Profiles

V Conclusion and Outlook

This paper showed that, in principle, OPC UA is suitable to serve as a secure architecture for a smart energy controller and its managed devices, either standalone or by designing Modbus applications using OPC UA (for an example see [3]). This allows for securing the application at a higher level, for with the most secure options being the Aes256-Sha256-RsaPss profile or TLS with TLS_DHE_RSA with AES_256_CBC_SHA256. Complimentary to this, it is advisable to implement additional external measures to secure the solution against attacks targeting the clients, provide rigorous logging facilities and implement external anti-flooding provisions. This could be achieved by segregating the M2M networks from traditional ICT networks (and the Internet, except where a Virtual Private Network (VPN) runs over the former) and also from each other. This follows the principle of least privilege, where an entity has only access to the particular resources it needs and adds an additional layer of access protection as well as, through this, protection against flooding-based and other DoS attacks. In general, the approach of defense-in-depth should be applied [23], making the best effort to security on any point of the system, for which using a secure distributed system architecture is the first step.


  • [1] IEC TR, “Industrial communication networks - Profiles - Part 2: Additional fieldbus profiles for real-time networks based on ISO/IEC 8802-3 ,” International Electrotechnical Commission, Tech. Rep., 2014.
  • [2] Y. Mo, T. H. J. Kim, K. Brancik, D. Dickinson, H. Lee, A. Perrig, and B. Sinopoli, “Cyber-physical security of a smart grid infrastructure,” Proceedings of the IEEE, vol. 100, no. 1, pp. 195–209, Jan 2012.
  • [3] N. T. T. Tu and H. Q. Thang, “Design and development of the air conditioning system by using opc ua specifications and modbus protocol,” in 2013 IEEE 8th Conference on Industrial Electronics and Applications (ICIEA), June 2013, pp. 1727–1732.
  • [4] A. Veichtlbauer, M. Ortmayer, and T. Heistracher, “Opc ua integration for field devices,” in 2017 IEEE 15th International Conference on Industrial Informatics (INDIN), July 2017, pp. 419–424.
  • [5] S. Marksteiner, V. J. Expósito Jiménez, H. Vallant, and H. Zeiner, “An Overview of Wireless IoT Protocol Security in the Smart Home Domain,” in 2017 Internet of Things Business Models, Users, and Networks, Nov 2017, pp. 1–8.
  • [6] Damm, Gappmeier, Zugfil, Plöb, Fiat, and Störtkuhl, “OPC UA Security Analysis,” Bundesamt für Sicherheit in der Informationstechnik, Tech. Rep., 2017. [Online]. Available:
  • [7] OPC Foundation, “OPC Unified Architecture - Part 2: Security Model,” OPC Foundation, Tech. Rep. Release 1.03, 2015.
  • [8] ——, “OPC Unified Architecture - Part 7: Profiles,” OPC Foundation, Tech. Rep. Release 1.04, 2017.
  • [9] ——, “OPC Unified Architecture - Part 1: Overview and Concepts,” OPC Foundation, Tech. Rep. Release 1.04, 2017.
  • [10] IEC TR, “Enterprise-control system integration – Part 1: Models and terminology,” International Electrotechnical Commission, Tech. Rep., 2013.
  • [11] T. Bray, J. Paoli, C. M. Sperberg-McQueen, E. Maler, and F. Yergeau, “Extensible markup language (xml) 1.0 (fifth edition),” World Wide Web Consortium, W3C Recommendation 26 November 2008 26 November 2008, 2008.
  • [12] T. Bray, “The JavaScript Object Notation (JSON) Data Interchange Format,” Internet Requests for Comments, Internet Engineering Task Force, RFC 8259, 2017.
  • [13] L. Zheng and H. Nakagawa, “Opc (ole for process control) specification and its developments,” in Proceedings of the 41st SICE Annual Conference. SICE 2002., vol. 2, Aug 2002, pp. 917–920 vol.2.
  • [14] IEC TR, “OPC Unified Architecture - Part 2: Security Model,” International Electrotechnical Commission, Tech. Rep., 2010.
  • [15] B. Potter, “Microsoft sdl threat modelling tool,” Network Security, vol. 2009, no. 1, pp. 15–18, 2009.
  • [16] International Electrotechnical Commission, “Communication network and system security - Introduction to security issues,” Technical Specification, International Electrotechnical Commission, TS ”62351-1”, 2007.
  • [17] S. Fries, H. J. Hof, and M. Seewald, “Enhancing IEC 62351 to Improve Security for Energy Automation in Smart Grid Environments,” in Internet and Web Applications and Services (ICIW), 2010 Fifth International Conference on.   Internet and Web Applications and Services (ICIW), 2010 Fifth International Conference on, may 2010, pp. 135–142.
  • [18] E. Barker and A. Roginsky, “Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths (Revision 1),” NIST Special Publication, National Institute of Standards and Technology, SP 800-131A, 2015.
  • [19] D. R. L. Brown, “What Hashes Make RSA-OAEP Secure?” Cryptology ePrint Archive, Report 2006/223, 2006. [Online]. Available:
  • [20] E. Fujisaki, T. Okamoto, D. Pointcheval, and J. Stern, “Rsa-oaep is secure under the rsa assumption,” Journal of Cryptology, vol. 17, no. 2, pp. 81–104, Mar 2004. [Online]. Available:
  • [21] K. Moriarty, B. Kaliski, J. Jonsson, and A. Rusch, “PKCS #1: RSA Cryptography Specifications Version 2.2,” Internet Requests for Comments, Internet Engineering Task Force, RFC 8017, 2016.
  • [22] IEC TR, “OPC Unified Architecture - Part 7: Profiles,” International Electrotechnical Commission, Tech. Rep., 2015.
  • [23] NSA Information Assurance Solutions Group, “Defense in Depth - A practical strategy for achieving Information Assurance in today’s highly networked environments,” National Security Agency, Tech. Rep., 2010, retrieved: 2017-03-20. [Online]. Available: