Cyber Security

Practical considerations for implementing IEC 62351

Frank Hohlbaum, Markus Braendle, Fernando Alvarez
ABB
frank.hohlbaum@ch.abb.com
Switzerland
1. Introduction
Two trends are currently changing substation automation systems: IEC 61850 and the need for
increased cyber security. IEC 61850 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 61850 based communications, has been one of the goals of the recently published technical
specification IEC 62351.
In the authors view IEC 62351 is overall a good starting point and will be the future standard to help
secure IEC 61850 communication. However, there are some shortcomings of the current standard and
some challenges that need to be addressed before IEC 62351 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 61850 real-time specifications. The major difficulties are to reach
the performance defined in IEC 61850 for GOOSE and SV data with todays proposed technical
specification defined for IEC 62351 part 6.
In chapter 2, we will give a short overview about the structure of IEC 61850 as well as the detailed
performance requirements for the various data types. Chapter 3 will present an introduction of the IEC
62351 standard including the used methods to secure the IEC 61850 communication. Chapter 4 will
then show the major implementation issues of IEC 62351 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 61850 Overview

IEC 61850 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 61850 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 61850 should be available by end of 2010. Due to the fact that the
technical specification IEC 62351 is not jet finalized, security is not finally addressed in IEC 61850
Edition II but it will come in a later step.
A key feature of IEC 61850 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.

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 IEC61850-5 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 61850 clients have to receive several hundreds of event from the various protection and control
IEDs.
Any security standard that attempts to secure IEC 61850 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
62351 addresses them.

3. Introduction to IEC 62351

The scope of the IEC 62351 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 60870-5 series, the IEC 60870-6 series, the IEC
61850 series, the IEC 61970 series, and the IEC 61968 series.
The IEC 62351 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
1
2
3
4
5
6
7
8

Title
Communication network and system
Introduction to security issues
Glossary of terms
Security for profiles including TCP/IP
Profiles including MMS

security

Status
TS

Security for IEC 60870-5 and derivatives

Security for IEC 61850
Network and system management (NSM) data object
models
Role-Based Access Control
Key Management (Certificate Handling)
Security Architecture
Table 1: Overview of IEC 62351 standard series

TS
TS
TS
TS
TS
CDTS
ACDV
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 61850 based communications.

As discussed in the previous section IEC 61850 communications can be divided into client server (i.e.
MMS) and real time (i.e. GOOSE and Sample Values) communications. IEC 62351 provides different
methods for securing the different communication types:

MMS (IEC 61850-8-1): 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 62351 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
1
recommended cipher suites to be used, at a minimum TLS_DH_DSS_WITH_AES_256_SHA
2
and TLS_DH_RSA_WITH_AES_128_SHA 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.

Specified in IEC 62351-4

Specified in IEC 62315-6

Protocol extensions to the affected communication standards are required in order to actually be able
to implement IEC 62351. IEC 61850 does not yet include these necessary extensions in its current
release. The upcoming Edition II will also not completely cover this because IEC 62351 is not yet
finalized.

4. Performance issues in IEC 62351 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 62315 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 62351 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 todays existing IEDs 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 Intel Core 2 Duo @ 2.2 GHz

(1GB RAM)
(2 GB RAM)
1024
6.8 ms
4 ms
512
3.9 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

needed 3 milliseconds or more to perform an RSA signature with a key length of 1024 bits using
FPGA.

FPGA
Clock
100 MHz
200 MHz

GOOSE sending

GOOSE Receiving

Total Processing

3.748 ms
0.155 ms
3.903 ms
1.917 ms
0.129 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 62351 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 62351 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 todays embedded devices, even without
considering cost. A hardware implementation today would not meet SV real-time requirements.
Protection and control IEDs must handle between 100 and 300 GOOSE packets per second while
receiving SV packets at the same time (4000 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 62351-6 will now be revised accordingly, with a first draft targeted for the first
half of 2010.

5. 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 62351 addresses

this
by
mandating
support
of
TLS_DH_DSS_WITH_AES_256_SHA
TLS_DH_RSA_WITH_AES_128_SHA at a minimum.

and

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 62351 specifies that for securing MMS
traffic security mechanisms can be disabled for devices for the purpose of compatibility. This allows
IEC 62351 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 62351. First,
receiving devices that do not support IEC 62351 can simply ignore the security extensions of IEC
62351 in the PDUs and process messages as before. If the receiving device supports IEC 62351 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 62351 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
IEDs 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 authors view, it would be a big and important step that increases the
acceptance and usability of IEC 62351.

7. Summary
TC57 WG15 has started to address the security issues for communication protocols defined by IEC
TC 57, specifically the IEC 60870-5 series, the IEC 60870-6 series, the IEC 61850 series, the IEC
61970 series, and the IEC 61968 series. Some parts of this technical specification are finalized while
work on others has just stared.
The performance evaluation done for IEC 62351 part 6 showed that both software as well hardware
solutions could not satisfy the performance requirements defined in IEC 61850 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 62351 can gain wide acceptance. The

very good initiative of TC57 WG15 must be driven further, addressing the raised issues, so that
security can become an integrated part of IEC 61850.
While this paper focused on IEC 62351 to help secure IEC 61850 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 61850 - Communication Networks and Systems in Substations, 14 parts: IEC 61850-x-y
IEC: 2003-2005, www.iec.ch
[2] ISO/IEC 8650-1- 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 61850 and the need for
increased cyber security. IEC 61850 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 61850 based communications, has been one of the goals of the recently published technical
specification IEC 62351. The acceptance of IEC 62351 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 62351 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.

Frank Hohlbaum,
Global Security Manager Power System Substations, ABB
Frank is globally responsible for all aspects of cyber security within ABBs 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 ABBs 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.