Reasoning on Adopting OPC UA for an IoT-Enhanced Smart Energy System from a Security Perspective
©©2018 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in anycurrent or future media, including reprinting/republishing this material for advertising or promotional purposes, creating newcollective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in otherworks.The final, published version of this paper is available under: S. Marksteiner, ”Reasoning on Adopting OPC UA for anIoT-Enhanced Smart Energy System from a Security Perspective,” ,Vienna, Austria, 2018, pp. 140-143. doi: 10.1109/CBI.2018.10060. URL: https://ieeexplore.ieee.org/document/8453946/ a r X i v : . [ c s . CR ] S e p easoning on Adopting OPC UA for anIoT-Enhanced Smart Energy System from aSecurity Perspective (Workshop Paper) Stefan Marksteiner
DIGITAL - Institute for Informationand Communication TechnologiesJOANNEUM RESEARCH GmbH
Graz, AustriaEmail: [email protected]
Abstract —Smart Services using
Industrial Internet of Things(IIoT) applications are on the rise, but still more often thannot, traditional industrial protocols are used to interconnect theentities of the resulting systems. These protocols are mostlynot intended for functioning in such a highly interconnectedenvironment and, therefore, often lack even the most fundamentalsecurity measures. To address this issue, this paper reasons onthe security of a communications protocol, intended for
Machineto machine (M2M) communications, namely the
Open PlatformCommunications Unified Architecture (OPC UA) and exemplifies,on a smart energy system, its capability to serve as a securecommunications architecture by either itself or in conjunctionwith traditional protocols.
Index Terms —IoT, Security, Smart Energy, Protocols, Industry4.0, M2M, OPC UA, Smart Services
I. I
NTRODUCTION AND M OTIVATION
This paper aims on reasoning on the security of the
OpenPlatform Communications Unified Architecture (OPC UA) forthe use in a smart energy system (a controller and its manageddevices). Concretely, it discusses whether using OPC UA is anappropriate method to secure communications for an Internetof Things (IoT)-based architecture that allows for advancedalgorithms in low voltage distribution grids to improve effi-ciency and hosting capability. The original idea to provide thiscommunications was via the in the industry widely proliferatedprotocol
Modbus/TCP [1]. This protocol, however, is knownto have severe security deficiencies [2]. It has therefore to bereplaced or security-enhanced by another protocol. Both taskscould be achieved by OPC UA, as it both provides a standalonearchitecture for
Machine-to-Machine Communication (M2M) and there is work to run OPC UA with Modbus [3]. Thereason why OPC UA is deemed a suitable candidate for thistype of communications is its standardization, proliferationand also its semantic interoperability [4]. This advancedflexibility and control will then facilitate the advanced useof renewable energy, as well as new service-based business
This work has received funding from the European Unions Horizon 2020research and innovation programme under grant agreement No 773715, ProjectRESOLVD (LCE-01-2016-2017). models in the energy domain. Assuring the security of thesecommunications, however, is a fundamental prerequisite forthis intended technology to work without generating the risk oflarge-scale cyberattacks and the protocol’s capabilities in thatmatter are therefore . Another goal of this paper is to extendthe author’s previous work on the security of IoT protocols[5] by adding a higher-level, industrial-use specification thatallows for industry 4.0 and energy domain use cases.II. R
ELATED W ORK
There is a security analysis of OPC UA commissioned bythe
German Federal Office for Information Security (BSI) [6].This work, however, was conducted over the course of theyear 2015 and does therefore not take into account newerdevelopments (see Section IV-B). In any case, as this workis quite comprehensive, it servers as a starting point forthis paper, apart from the official OPC UA specifications inparticular the security model [7] and the profiles [8].III. P
ROTOCOL D ESCRIPTION
The
Open Platform Communications Unified Architecture(OPC UA) is a system architecture that is designed to exchangecommand 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
IEC62264 Enterprise-control system integration norms [10]. Thearchitecture specifies the following [9]: • The information model to represent structure, behaviourand semantics; • The message model to interact between applications; • The communication model to transfer the data betweenend-points; • The conformance model to guarantee interoperabilitybetween systems.In order to provide a platform-independent infrastructure logicto flexibilize host services for the
Industrial Internet of Things(IIoT) , enabling
Machine-to-Machine Communication (M2M) ,t provides both a
Client-Server and a
Publisher-Subscriber(PubSub) model. To model the actual data it defines threeencodings: • 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 PlatformCommunications (OPC) , formerly called
OLE for ProcessControl model [9]. The latter historically derives from theMicrosoft
Object Linking and Embedding (OLE)/ComponentObject Model (COM) [13]. The protocol has been interna-tionally standardized as IEC/TR 62541 [14] by the
Interna-tional Electrotechnical Commission (IEC) . Therefore, it enjoyswidespread use. IV. S
ECURITY A NALYSIS
This section contains a threat model description to deter-mine the security properties deemed necessary for the currentapplication, followed by an analysis of the OPC UA profilesfor their general security and their features countering theidentified threats.
A. Thread Model
An adversary targeting the smart energy controller may havemany potential goals (the list is non-exhaustive): • Extract information to draw conclusions on power con-sumptions, user behavior and billing information; • Extract information to achieve credentials to administra-tive 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 damagethe device.Technique to achieve this can be categorized into thefollowing (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 communi-cation line between an assumed intelligent energy managerand a managed device was modeled in the
Microsoft ThreatModeling Tool 2016 [15], using generic data flows (see thegraphical representation in Figure 1). This yielded in 5 DoSthreats, 6 in privilege elevation, 3 in information disclosure,2 in repudiation, 3 in spoofing an 4 in tampering (see TableI for details). The next sections will reason on the possibilityto counter these threats using OPC UA.
Fig. 1. Graphic Threat Model Representation
B. Analysis
IoT connections for industrial usage should provide atminimum 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 betaken to secure to provide a thoroughly secured connection. Asstated in Section I, the OPC UA is deemed a suitable candidateto fulfill this requirement and moreover provide end-to-endsecurity. It provides three cipher suites, all of which use the
Advanced Encryption Standard (AES) for symmetric encryp-tion,
Rivest-Shamir-Adleman (RSA) -based asymmetric encryp-tion with
Optimal asymmetric encryption padding (OAEP) and
Secure Hash Algorithm 2 (SHA2) -based systems for messagesigning. All of these suites have a signature length of 256 bits,channel nonce lengths of 32 bytes and asymmetric key lengthsbetween 2048 and 4096 bits , as well as they are using the
Cipher Block Chaining (CBC) mode of operation [8]. Thesecombination of algorithms is currently deemed secure [18].The only exception to the algorithms stated above is the useof 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 onlyrequires a hash function that has a neglectable possibility ofproducing all-zero sequences, which SHA1 fulfills [19]. The These are, however, only the necessary , not the sufficient security proper-ties. There is yet no formal security proof for RSA-OAEP-SHA1.ABLE IT
HREAT O VERVIEW
Potential Process Crash or Stop for Managed Device Denial Of ServiceData Flow Downstream Is Potentially Interrupted Denial Of ServicePotential Process Crash or Stop for smart energy controller Denial Of ServiceData Flow Upstream Is Potentially Interrupted Denial Of ServiceElevation Using Impersonation Elevation Of PrivilegeElevation Using Impersonation Elevation Of PrivilegeManaged Device May be Subject to Elevation of Privilege Using Remote Code Execution Elevation Of PrivilegeElevation by Changing the Execution Flow in Managed Device Elevation Of Privilegesmart energy controller May be Subject to Elevation of Privilege Using Remote Code Execution Elevation Of PrivilegeElevation by Changing the Execution Flow in smart energy controller Elevation Of PrivilegeWeak Authentication Scheme Information DisclosureDownstream Data Flow Sniffing Information DisclosureUpstream Data Flow Sniffing Information DisclosurePotential Data Repudiation by Managed Device RepudiationPotential Data Repudiation by smart energy controller RepudiationSpoofing the smart energy controller Process SpoofingSpoofing the Managed Device Process SpoofingSpoofing the smart energy controller Process SpoofingReplay Attacks TamperingCollision Attacks TamperingPotential Lack of Input Validation for Managed Device TamperingPotential Lack of Input Validation for smart energy controller Tampering underlying RSA-OAEP possesses a formal security proof [20].A survey from the
German Federal Office for InformationSecurity (BSI) regarded
Basic256Sha256 as the most secure ofthese 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 inthat it replaces SHA1 with SHA2 in asymmetric encryptionand the
RSA Signature Algorithm Public-Key CryptographyStandards (RSASSA-PKCS) version 1.5 with the
ProbabilisticSignature Scheme (RSASSA-PSS) for asymmetric signatures.As the latest version of the defining standard [21] bothrecommends using SHA2 and requires using RSASSA-PSSfor 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 TLS1.0, 1.1 and 1.2 as means to secure communications, althoughthe newer technical specification by the OPC foundation onlyprovides TLS 1.2 as single choice. This standard providesthree choices for TLS, AES256 with RSA key exchange orAES128 and AES256 with
Diffie-Hellman Ephemeral (DHE) key exchange, each using SHA256 for hashing and the CBCmode. Further principally defined algorithms are AES-CTR(symmetric encryption), RSA-PKCS15 (asymmetric encryp-tion) and RSA-PKCS15-SHA1(signature) and P-SHA1 (keyderivation), but these are not used in any profiles and thereforeregarded as if not supported [8]. Table II provides an overviewof the cryptographic algorithms used in the different OPC UAprofiles.In conclusion, using the Aes256-Sha256-RsaPss profile doesmitigate the threats to information disclosure. It does also mitigate collision attacks and should, by specification, pre-vent replay attacks in conjunction with a sequence number.However, the BSI found out in its analysis that the providedreference implementation deviated from this specification, asthe sequence number was not evaluated [6]. Other tampering-related attacks are in the devices’ scopes rather than inthe protocol’s. This is similar to privilege elevation attacks;impersonation attacks can be mitigated by providing propermessage authentication provided by the secure signatures inthe profile, albeit, the other attacks of this category are in theclients’ scopes which also applies for client-based imperson-ation (which must be mitigated by secure client authentication,e.g. via secure passwords and/or second factors). Also, spoof-ing of processes has to countered on the client. The threatsregarding DoS are infrastructural and, thus, need externalcounter measures, except for message flooding, which can bepartially mitigated by rate limiting through artificial delays [6].The repudiation is not explicitly stated, but non-repudiationfor sent messages is in general, as far the communicationsprotocol is concerned, provided by the usage of secure publickey authentication and for received ones an issue of thoroughlogging, which is out of the protocol’s scope.V. C
ONCLUSION AND O UTLOOK
This paper showed that, in principle, OPC UA is suitable toserve as a secure architecture for a smart energy controller andits managed devices, either standalone or by designing Modbusapplications using OPC UA (for an example see [3]). This al-lows for securing the application at a higher level, for with themost secure options being the Aes256-Sha256-RsaPss profileor TLS with TLS DHE RSA with AES 256 CBC SHA256.
ABLE IIC
URRENTLY V ALID
OPC UA S
ECURITY P ROFILES
Name Aes128-Sha256-RsaOaep Basic256Sha256 Aes256-Sha256-RsaPss TLS RSA AES 256 CBC SHA256 TLS DHE RSA AES nnn CBC SHA256Symmetric Encryption AES128-CBC AES256-CBC AES256-CBC AES256-CBC AES128/256-CBCSymmetric Signature HMAC-SHA2-256 HMAC-SHA2-256 HMAC-SHA2-256 HMAC-SHA2-256 HMAC-SHA2-256Asymmetric 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-PKCS15Certificate Signing RSA-PKCS15-SHA2-256 RSA-PKCS15-SHA2-256 RSA-PKCS15-SHA2-256 RSASSA-PKCS15 RSASSA-PKCS15Key Derivation P-SHA2-256 P-SHA2-256 P-SHA2-256 RSASSA-PKCS15 DHE
Complimentary to this, it is advisable to implement addi-tional external measures to secure the solution against attackstargeting the clients, provide rigorous logging facilities andimplement external anti-flooding provisions. This could beachieved by segregating the M2M networks from traditionalICT networks (and the Internet, except where a
Virtual PrivateNetwork (VPN) runs over the former) and also from eachother. This follows the principle of least privilege, where anentity has only access to the particular resources it needsand adds an additional layer of access protection as well as,through this, protection against flooding-based and other DoSattacks. In general, the approach of defense-in-depth should beapplied [23], making the best effort to security on any pointof the system, for which using a secure distributed systemarchitecture is the first step.R
EFERENCES[1] IEC TR, “Industrial communication networks - Profiles - Part 2: Addi-tional 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, andB. 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 theair conditioning system by using opc ua specifications and modbusprotocol,” in , June 2013, pp. 1727–1732.[4] A. Veichtlbauer, M. Ortmayer, and T. Heistracher, “Opc ua integrationfor field devices,” in , July 2017, pp. 419–424.[5] S. Marksteiner, V. J. Exp´osito Jim´enez, H. Vallant, and H. Zeiner,“An Overview of Wireless IoT Protocol Security in the Smart HomeDomain,” in , Nov 2017, pp. 1–8.[6] Damm, Gappmeier, Zugfil, Pl¨ob, Fiat, and St¨ortkuhl, “OPC UA SecurityAnalysis,” Bundesamt f¨ur Sicherheit in der Informationstechnik, Tech.Rep., 2017. [Online]. Available: https://opcfoundation.org/security[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 andterminology,” 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 WebConsortium, W3C Recommendation 26 November 2008 26 November2008, 2008.[12] T. Bray, “The JavaScript Object Notation (JSON) Data InterchangeFormat,” Internet Requests for Comments, Internet Engineering TaskForce, RFC 8259, 2017.[13] L. Zheng and H. Nakagawa, “Opc (ole for process control) specifica-tion and its developments,” in
Proceedings of the 41st SICE AnnualConference. SICE 2002. , vol. 2, Aug 2002, pp. 917–920 vol.2. [14] IEC TR, “OPC Unified Architecture - Part 2: Security Model,” Interna-tional 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 networkand system security - Introduction to security issues,” Technical Specifi-cation, International Electrotechnical Commission, TS ”62351-1”, 2007.[17] S. Fries, H. J. Hof, and M. Seewald, “Enhancing IEC 62351 to ImproveSecurity for Energy Automation in Smart Grid Environments,” in
Inter-net and Web Applications and Services (ICIW), 2010 Fifth InternationalConference 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 Transi-tioning the Use of Cryptographic Algorithms and Key Lengths (Revision1),” NIST Special Publication, National Institute of Standards andTechnology, SP 800-131A, 2015.[19] D. R. L. Brown, “What Hashes Make RSA-OAEP Secure?”Cryptology ePrint Archive, Report 2006/223, 2006. [Online]. Available:https://eprint.iacr.org/2006/223[20] E. Fujisaki, T. Okamoto, D. Pointcheval, and J. Stern, “Rsa-oaep is secure under the rsa assumption,”