Whitepaper

Cyber Security
Practical considerations for implementing IEC 62351
Cybersecurity for Substation Automation Systems

1. Introduction Application
Data Model (Objects, Services)
Two trends are currently changing substation automation systems:
IEC 61850 and the need for increased cyber security. IEC 61850 Client Server Sampled
GOOSE*
has gained global acceptance by both vendors as well as Communication Values

customers. Cyber security on the other hand has quickly become Abstract
Communication
one of the most dominant topics for control systems in general Services
Interface (ACSI)
Mapping (split data model from communication)
and electrical utilities in particular. The combination of the two, Stack
Interface
securing IEC 61850 based communications, has been one of the
goals of the recently published technical specification IEC 62351. MMS

Realtime Priority
communication
In the authors‟ view IEC 62351 is overall a good starting TCP

point and will be the future standard to help secure IEC 61850 ISO/OSI-Stack IP
Hierarchical set of rules how
communication. However, there are some shortcomings of the information is coded for transmission Ethernet Link Layer
According to state-of-the art
current standard and some challenges that need to be addressed communication technology Ethernet Physical Layer with Priority tagging (100 Mbit/s)

before IEC 62351 can be implemented and gain wide acceptance. *Generic Object Oriented Stack selection according to the state-of-the-art
Substation Event Communication technology

This paper will highlight the challenge of addressing secure Figure 1: IEC61850 Communication Services Overview
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 today’s 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
cannot 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.

Accuracy classes Resolution (Bits)
Data type Class
and harmonics Amplitude
Voltage
Class 0.5 (IEC 62053-22)
M1 Class 0.2 (IEC 60044-8)
Current Up to 5th harmonic
Voltage
Class 0.2 (IEC 62053-22)
M2 Class 0.1 (IEC 60044-8)
Current Up to 13th harmonic
Voltage
Class 0.1
M3 (not defined by IEC)
Current Up to 40th harmonic
Figure 2: Performance classes for raw data messages used for metering
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.
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.
As show in Figure 2 the performance classes start 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 events
from the various protection and control IED‟s.
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.
Rate
Part Title Status
(Samples/s)
Frequency
Communication network and system security –
12 1 TS
Introduction to security issues
1500
2 Glossary of terms TS
14
3 Security for profiles including TCP/IP TS
14 4 Profiles including MMS TS
4000 5 Security for IEC 60870-5 and derivatives TS
16 6 Security for IEC 61850 TS
Network and system management (NSM) data
7 CDTS
16 object models
12000 8 Role-Based Access Control ACDV
18 Key Management (Certificate Handling) NWP
Security Architecture NWP
Table 1: Overview of IEC 62351 standard series
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”.
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 recommended cipher suites to
be used, at a minimum TLS_DH_DSS_WITH_AES_256_SHA1 and
TLS_DH_RSA_WITH_AES_128_SHA2 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.
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 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.
Pentium M 1.7 GHz Intel Core 2 Duo @ 2.2 GHz
Key-size
(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 were 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
GOOSE sending GOOSE Receiving Total Processing
Clock
100 MHz 3.748 ms 0.155 ms 3.903 ms
200 MHz 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 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 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
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 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 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 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 Fernando Alvarez

Division Cyber Security Manager,
Power Systems Division, Hitachi Energy
Markus is globally responsible for all aspects of cyber security
within Hitachi Energy’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.
Technical Security Architect, Power Systems
Substations, Hitachi Energy
Fernando is the chief architect for defining security architecture
and development strategies for Hitachi Energy’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.

Frank Hohlbaum,
Global Security Manager Power System
Substations, Hitachi Energy
Frank is globally responsible for all aspects of cyber security
within Hitachi Energy’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 Hitachi Energy 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 graduate studies in business
administration at the University in Zurich (Switzerland).

Hitachi Energy We reserve the right to make technical changes or modify the
© 2023 Hitachi Energy. All rights reserved. contents of this document without prior notice. With regard
1MRG006973 to purchase orders, the agreed particulars shall prevail. Hitachi
Energy Ltd. does not accept any responsibility whatsoever for
www.hitachienergy.com potential errors or possible lack of information in this document.
We reserve all rights in this document and in the subject matter
and illustrations contained therein. Any reproduction, disclosure
to third parties or utilization of its contents – in whole or in parts
– is forbidden without prior written consent of Hitachi Energy Ltd.