Cyber Security Practical considerations for implementing IEC 62351

Transcription

1 1. Introduction Cyber Security Practical considerations for implementing IEC Frank Hohlbaum, Markus Braendle, Fernando Alvarez ABB Switzerland Two trends are currently changing substation automation systems: IEC and the need for increased cyber security. IEC has gained global acceptance by both vendors as well as customers. Cyber security on the other hand has quickly become one of the most dominant topics for control systems in general and electrical utilities in particular. The combination of the two, securing IEC based communications, has been one of the goals of the recently published technical specification IEC In the authors view IEC is overall a good starting point and will be the future standard to help secure IEC communication. However, there are some shortcomings of the current standard and some challenges that need to be addressed before IEC can be implemented and gain wide acceptance. This paper will highlight the challenge of addressing secure communication in the substation real-time environment, complying with the IEC real-time specifications. The major difficulties are to reach the performance defined in IEC for GOOSE and SV data with today s proposed technical specification defined for IEC part 6. In chapter 2, we will give a short overview about the structure of IEC as well as the detailed performance requirements for the various data types. Chapter 3 will present an introduction of the IEC standard including the used methods to secure the IEC communication. Chapter 4 will then show the major implementation issues of IEC part 6. Chapters 5 and 6 highlight two of the main remaining challenges: interoperability and manageability of security solutions. This paper focuses on IEC61850 based systems, security, however, must be addressed for all computer systems and communication. Most of the challenges mentioned in this paper are not limited to IEC61850 based systems, but are general in nature. Even system based on serial communications can not work properly without any security measures. 2. IEC Overview IEC is the first and only global standard that considers all communication needs within the substation automation environment. The standard defines strict interoperability rules between functions and devices, independent of the device manufacturer, providing protection, monitoring, control and automation. IEC was published as a standard by IEC in fourteen parts between 2003 and 2005 [1]. In the meantime this standard has gained global acceptance and several thousands of substations worldwide have been energized. The standardization activity has reached a next step and the Edition II of IEC should be available by end of Due to the fact that the technical specification IEC is not jet finalized, security is not finally addressed in IEC Edition II but it will come in a later step. A key feature of IEC is that it separates the application from the communication by means of an abstract interface. A domain-specific, object oriented function and device model describes the application data with all services needed. The functions can be allocated freely to different devices. As shown in Figure 1 the stack, selected from mainstream communication technology, comprises MMS (Manufacturing Message Specification) over TCP/IP and Ethernet. The object model is mapped in a standardized way to the MMS application layer, but time critical messages pass directly to the link layer of Ethernet. Specific performance classes are defined for the different communication methods.

2 Figure 1: IEC61850 Communication Services Overview Goose messages like trip, interlocking and inter-trip signals belong to the fast messages which should be transmitted within 10ms (Performance Class P1). For some signals event within 3ms (Performance Class P2/3) are specified. For Sampled Values (SV) the IEC standard defines several performance classes for raw data messages from digitizing transducers and digital instrument transformers. Figure 2: Performance classes for raw data messages used for metering As show in Figure 2 the performance classes starts with class M1 (sample rate of 1,5 khz) refers to revenue metering with accuracy class 0.5, performance class M2 (sample rate of 4 khz) refers to revenue metering with accuracy class 0.2 and performance class M3 (sample rate of 12 khz) refers to quality metering. Therefore the devices have to process the raw data each 666 us in performance class M1, each 250 us in performance class M2 and each 83 us in performance class M3. For Client - Server communication there are no explicit timing requirements defined but nevertheless IEC clients have to receive several hundreds of event from the various protection and control IED s. Any security standard that attempts to secure IEC based traffic must take these performance requirements into account. The fast response times that are required for some of the communication types coupled with the limited processing capabilities of some of the device (e.g. IEDs) present a clear challenge. We will look at these challenges in the following sections and analyze if and how IEC addresses them.

3 3. Introduction to IEC The scope of the IEC series is information security for power system control operations. Its primary objective is to undertake the development of standards for security of the communication protocols defined by IEC TC 57, specifically the IEC series, the IEC series, the IEC series, the IEC series, and the IEC series. The IEC standard is currently divided into 8 parts. As shown in Table 1 parts 1-6 are officially categorized as TS (technical specification) and released by IEC. Parts 7 and 8 are currently under development, with the current state of part 7 being Circulated Draft Technical Specification (CDTS) and Part 8 being Draft approved for Committee Draft with Vote (ACDV). In addition two new work item proposals (NWP) exist to address "Key management (certificate handling) and Security Architecture. Part Title Status 1 Communication network and system security Introduction to security issues 2 Glossary of terms TS 3 Security for profiles including TCP/IP TS 4 Profiles including MMS TS 5 Security for IEC and derivatives TS 6 Security for IEC TS 7 Network and system management (NSM) data object models TS CDTS 8 Role-Based Access Control ACDV Key Management (Certificate Handling) Security Architecture Table 1: Overview of IEC standard series NWP NWP In this paper we will focus mainly on parts 3, 4, and 6, with an emphasis on part 6 because it defines specific requirements for IEC based communications. As discussed in the previous section IEC communications can be divided into client server (i.e. MMS) and real time (i.e. GOOSE and Sample Values) communications. IEC provides different methods for securing the different communication types: MMS (IEC ): securing MMS traffic is done on the application and the transport level. Peer authentication is performed on the application level by carrying authentication information in the ACSE AARQ and AARE PDUs [2]. Authentication information comprises a X.509 encoded certificate, a time stamp and the digitally signed time value. For security on the transport layer IEC refers to TLS [4]. It specifies to us port 3782 for secure communications instead of standard port 102. It also specifies a set of mandatory and recommended cipher suites to be used, at a minimum TLS_DH_DSS_WITH_AES_256_SHA 1 and TLS_DH_RSA_WITH_AES_128_SHA 2 must be supported. GOOSE / Sampled Values: security of real-time traffic is limited to message authentication, i.e. use encryption is not specified. Message authentication is defined by extending the GOOSE / SV PDUs with an authentication value that is calculated by signing a SHA256 hash using RSA [3]. Certificate exchange is not done as part of the messages; X.509 encoded certificates must be pre-installed on the receiving nodes. 1 Specified in IEC Specified in IEC

4 Protocol extensions to the affected communication standards are required in order to actually be able to implement IEC IEC does not yet include these necessary extensions in its current release. The upcoming Edition II will also not completely cover this because IEC is not yet finalized. 4. Performance issues in IEC Part 6 Performance impacts should always be considered for any communication infrastructure before introducing encryption and / or message authentication. This is particularly true if asymmetric cryptography, real-time traffic or systems with limited resources are involved. In case of securing GOOSE and SV using IEC all three constraints apply: Embedded devices such as Protection & Control IEDs or RTUs typically have little computational power (as compared to personal computers or servers) and only a (small) portion can be made available to functionality other than protection and control. In addition, changing or upgrading hardware is not an easy task for embedded devices that potentially have a very long lifetime. Security solutions for embedded devices should therefore not require major hardware changes. For both GOOSE and SV strict real-time constraints exist 3ms response time for GOOSE and sampling rates up to 12 khz for Sampled Values. IEC 62351, as of today, specifies the use of digital signatures (asymmetric cryptography using RSA) to authenticate broadcast GOOSE and SV packets We focus our attention in this discussion on the performance impact on securing real-time traffic as specified in IEC part 6, in particular the signing of the hash value using the RSA algorithm. The calculation of the SHA256 hash value as well as the verification of the digital signature is considerably less CPU intense and therefore omitted for the moment. In a first step implementing digital signatures in software was analyzed. The first results quickly showed that a software implementation of digital signatures would not meet the real-time requirements with today s existing IED s hardware. Table 2 shows the performance results of implementing RSA signing on two different platforms using C. The reader will notice that even though the processor and memory available on both platforms are exceeding those of typical embedded devices the times needed for a single digital signature are at least 1.5 milliseconds, i.e. half of the minimum response time for GOOSE messages. For a key length of 1024 bits, which can be considered minimum best practice, calculating the signature took at least 4 milliseconds. Key-size Pentium M 1.7 GHz (1GB RAM) Intel Core GHz (2 GB RAM) ms 4 ms ms 1.5 ms Table 2: Time use for RSA signature operations A more promising approach that has been followed after the first study was to base cryptographic operations on special purpose hardware. However, the results from the hardware implementation could not meet the strict real-time constraints of GOOSE and SV. Even with an increment of several hundred dollars in hardware production costs per device the real-time performance of 3ms for GOOSE massages and the support for 12 khz SV sampling rates remain very difficult to achieve. FPGA Platforms Table 3 shows a summary of the performance measures using FPGA based solutions. The overhead for message authentication (i.e. calculation of the hash and RSA signing by sender, calculation of hash and verification of signature by recipient) is between 2 and 4 milliseconds. Although at a first glance, 2 milliseconds seem to be acceptable using two thirds of the overall allowed response time is not adequate considering the time that would be left for other calculations. Additionally the 12 khz sampling rate for SV requires messages to be processed within 83 microseconds, more than an order of magnitude less than needed for sending of messages (Note that the processing times for signing GOOSE and SV messages are the same). Our results where confirmed by [5] and others that all

5 needed 3 milliseconds or more to perform an RSA signature with a key length of 1024 bits using FPGA. FPGA GOOSE sending GOOSE Receiving Total Processing Clock 100 MHz ms ms ms 200 MHz ms ms 2.036ms Table 3: Time measurement for securing GOOSE with FPGA ASIC Platforms ASIC platforms are as expected significantly faster than FPGA. However, only a handful of solutions exist today that are capable of meeting the requirements. The three best solutions that were found calculate a 1024 bit private key RSA signature in 0.16, 0.34, respectively 0.95 milliseconds, making only two of them real options for applying IEC part 6 to GOOSE. Since none of them are capable of dealing with the maximum sampling rate of 12 khz for SV and since these top solutions come at a significant cost ASIC platform can currently not be considered a feasible solution for implementing IEC part 6. RSA crypto chips The last hardware solution that was evaluated were specialized crypto-chips. The top in class chips that were looked at are capable of calculating a single RSA signature with a key length of 1024 bits in as little as 23.8 microseconds, which in theory would even allow supporting 12 khz sampling rates. However, integrating such crypto-chips would require a major redesign of the overall hardware, including possibly dedicated external memory, complex interface glue logic or cooling systems. For future systems this is certainly possible, but for short or mid-term solutions not feasible. Based on the evaluation the conclusions are clear: authentication of GOOSE and SV broadcast messages using digital signatures is not feasible with today s embedded devices, even without considering cost. A hardware implementation today would not meet SV real-time requirements. Protection and control IED s must handle between 100 and 300 GOOSE packets per second while receiving SV packets at the same time (4 000 Packets / sec), and while running their protection algorithms and doing other tasks such as refreshing user interfaces, logging, time synchronization etc. These findings have been presented to TC 57 WG 15 in October 2009 and convinced the working group that another approach is needed. A solution using symmetric cryptography (using of HMACs) was suggested and IEC will now be revised accordingly, with a first draft targeted for the first half of Interoperability One of the most important aspects for the acceptance of IEC 62351, and any other security standard, is interoperability - interoperability between implementations of different vendors as well as interoperability of new solutions with the installed base, i.e. backward compatibility. While the first, interoperability of implementations of different vendors, might seem trivial with having a standard there are some considerations that must be made. Backward compatibility on the other hand seems difficult at a first look because security mechanisms such as encryption seem to require all entities to support the new functionality. Interoperability of vendor implementations Achieving interoperability with security related standards imposes new challenges extending beyond pure definition and implementation of communication protocols and interfaces. Interoperability of security protocols is also depending on the use of standardized cryptographic algorithms. Implementations of SSL / TLS for example, while being fully compliant with the standard itself, are only capable of setting up a secure session if the same crypto suites are supported. IEC addresses

6 this by mandating support of TLS_DH_DSS_WITH_AES_256_SHA and TLS_DH_RSA_WITH_AES_128_SHA at a minimum. Backward compatibility Introducing new technologies can be facilitated be allowing for backward compatibility and thus by allowing a stepwise introduction of the new technology. IEC specifies that for securing MMS traffic security mechanisms can be disabled for devices for the purpose of compatibility. This allows IEC compliant devices to be installed in an existing infrastructure without the use of security. Therefore, legacy equipment can be replaced by new devices gradually without having to replace or upgrade the whole system at once. However, it is clear that unless all devices support IEC 62351, encryption cannot be used. The obvious risk of never using security features must be taken seriously, especially if no governmental standard explicitly demands these features. For securing GOOSE and SV backward compatibility has also been addressed by IEC First, receiving devices that do not support IEC can simply ignore the security extensions of IEC in the PDUs and process messages as before. If the receiving device supports IEC but the sending device does not, then the recipient can be configured to accept unauthenticated messages from the particular sender. 6. Manageability Besides the interoperability of devices the second major hurdle to overcome is the usability and manageability of security. Experience has shown that security is often compromised if it cannot be used, managed and maintained easily. Personnel responsible for the operation of automation and control systems are typically not security experts and they will likely find workarounds if security presents too much of a challenge. Examples are default passwords that are not changed or firewalls that are not configured correctly and not properly maintained. In the case of IEC the main challenge for the use of asymmetric cryptography is the handling of certificates and certificate revocation lists. While the standard defines in technical detail how certificates shall be used and what format they shall have, the management of them is (currently) not addressed. It starts with generating and installing certificates. End-users often do not have the knowhow and / or infrastructure (i.e. a certificate authority) to generate certificates for all individual devices. Major providers of certificates have so far not been much involved with the electric industry and do not have a business model for it, i.e. addressing the issue of needing thousands of certificates within a single organization. Once the certificates have been installed technical solutions are needed to prevent certificate expiration, which could have severe consequences. End-users must thus receive automated notifications in due time before a certificate expires. Finally yet importantly, proper use of certificates also depends on technical solutions for handling certificate revocation lists (CRL). With IED s typically not being directly connected to external networks updating CRLs is not trivial and endusers must be presented with solutions and architectures that allow a timely handling of any changes in CRLs. [6] describes in detail the major challenges associated with certificate handling in industrial automation and control systems. The two new work item proposals "Key management (certificate handling) and Security Architecture currently under discussion in TC57 WG15 will hopefully address the issues of using, managing and maintaining certificates. In the author s view, it would be a big and important step that increases the acceptance and usability of IEC Summary TC57 WG15 has started to address the security issues for communication protocols defined by IEC TC 57, specifically the IEC series, the IEC series, the IEC series, the IEC series, and the IEC series. Some parts of this technical specification are finalized while work on others has just stared. The performance evaluation done for IEC part 6 showed that both software as well hardware solutions could not satisfy the performance requirements defined in IEC for GOOSE and SV data. TC57 WG15 has accepted these findings and is now looking at a new approach, which will likely use symmetric cryptography. TC57 WG15 is currently also addressing certificate handling, which in the authors view is a key challenge to overcome before IEC can gain wide acceptance. The

7 very good initiative of TC57 WG15 must be driven further, addressing the raised issues, so that security can become an integrated part of IEC While this paper focused on IEC to help secure IEC based substations there are many other security mechanisms that can and must be used to improve the overall security architecture of modern substation automation systems. The fact that IEC61850 uses mainstream communication technology, i.e. Ethernet and TCP/IP, makes a wide variety of solutions available. Firewalls for examples can protect the security perimeter and VPN technology can build up secure channels to remote centers. Access to systems and devices can and must be further protected by using individual user authentication and authorization coupled with detailed logging of all user activity. Literature [1] IEC Communication Networks and Systems in Substations, 14 parts: IEC x-y IEC: , [2] ISO/IEC Information technology -- Open Systems Interconnection -- Connection-oriented protocol for the Association Control Service Element: Protocol specification, 1996, ISO [3] Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1,RFC 3447, February 2003 [4] The TLS Protocol Version 1.0, RFC 2246, 1999 [5] D. Amanor, C. Paar, J. Pelzl, V. Bunimov, M. Schimmler Efficient hardware architectures for modular multiplication on FPGAs, International Conference on Field Programmable Logic and Applications, 2005 [6] S. Obermeier, Hadeli, R. Schierholz, R. Enderlein, Certificate Management for Embedded Industrial Devices, ICSJWG, 2009 Abstract Two trends are currently changing substation automation systems: IEC and the need for increased cyber security. IEC has gained global acceptance by both vendors as well as customers. Cyber security on the other hand has quickly become one of the most dominant topics for control systems in general and electrical utilities in particular. The combination of the two, securing IEC based communications, has been one of the goals of the recently published technical specification IEC The acceptance of IEC will largely depend on its impact on interoperability, performance, and manageability. This paper will present performance evaluations that show the limitations on the technical feasibility of the current IEC documents. The authors will also give insights on how interoperability and manageability are affected. Finally the paper will show how some of the current shortcomings should be addressed in the future. Authors Information Markus Braendle Division Cyber Security Manager, Power Systems Division, ABB Markus is globally responsible for all aspects of cyber security within ABB's Power Systems division. He heads the Power Systems Security Council which defines, develops, and implements the security strategy for all products and systems within the Power Systems division. Markus is an active member of several security standardization efforts and working groups, e.g., IEEE PSRC H13, Cigre B5.38, ICSJWG or NIST SmartGrid CSCTG, and a recognized member in the industrial control system security community. Markus holds a doctoral degree in Computer Science from the Federal Institute for Technology in Zurich, Switzerland.

8 Frank Hohlbaum, Global Security Manager Power System Substations, ABB Frank is globally responsible for all aspects of cyber security within ABB s Power System Substations and drives the security activities in this business unit. He is an active member of the Power System Security Council and represents the business unit Power System Substations. Frank Hohlbaum joined ABB Inc. in 1996 and has 14 years of experience in substation automation. He graduated from University in Furtwangen (Germany) with Bachelor of Sciences concentrated in software and electrical technologies. Additionally he did post graduated studies in business administration at the University in Zurich (Switzerland). Fernando Alvarez Technical Security Architect, Power Systems Substations, ABB Fernando is the chief architect for defining security architecture and development strategies for ABB s Power Systems Substations. As a Security expert, he leads the technical group related to security for Substation Automation Products. Fernando is an active member of TC57 WG15. A technologist with vast experience in software and system design and implementation, he graduated from California State University, Long Beach with Bachelors in Computer Science Engineering.