Securing GOOSE Communication in a Power Grid Substation
The GOOSE (Generic Object Oriented Substation Event) protocol is a communication model defined by the IEC 61850 standard, which uses fast and reliable mechanisms to group any format of data (status, value) into a data set and transmit it across communication networks within 4 milliseconds.
It is most used for data exchanges between IEDs (IED – Intelligent Electronic Device) in electrical substations over Ethernet.
How does GOOSE works …?
The general concept of GOOSE communication is that the publisher periodically sends messages and when an event happens (e.g. tripping signal, circuit breaker closing), it sends a burst of messages with new data. Because the protocol is based on a publisher/subscriber mechanism, there is no confirmation that the sent message is correctly received by the subscriber, the message is retransmitted to prevent the loss of packets and inform newly connected devices of the current state.
The subscriber receives all messages from the system, but only filters and parses the messages carrying the topic it has subscribed to.
Figure – Example where GOOSE is used to prevent a fault from being propagated.
In the example above, a protective relay multicasts a TRIP command to two circuit breakers to disconnect the circuits upon detecting a fault. The logical node PDIS represents a protection scheme by the data object Op, and the logical node PTRC represents a protection trip conditioning by the data object Tr. Usually, the values of these two data objects, i.e., the TRIP, must be transmitted within a few milliseconds. It is common to quote a benchmark of 4 ms for this threshold. The 4 ms threshold is easily and reliably met by ethernet multicast on commodity hardware at the load levels seen in power substations.
Security Concerns with GOOSE
As there is no Authentication & Integrity check between the Publisher & Subscriber of GOOSE messages, these messages can be spoofed, replayed and manipulated by a bad actor. A malicious actor can generate a GOOSE frame like one observed on the network, but with manipulated values. Decoupling Critical Devices and False Data Injection are two attack scenarios that can be executed by manipulating GOOSE messages. (ref-1)
Securing GOOSE and IEC-62351-6
Taking into account the criticality of GOOSE communications within a substation, IEC-62351-6 came up with a set of recommendations to secure GOOSE messages using MAC (Message Authentication Code), the standard mandates Authentication & Integrity check while Message Encryption is Optional.
In order to understand how to secure GOOSE, let’s take a look at MAC.
What is MAC and how is it used in Securing GOOSE message
A message authentication code or MAC is a cryptographic code that is generated from a message and then appended to the same message before being sent by the sender to the receiver for providing message authentication and integrity verification.
A MAC algorithm takes the message to be transmitted & a secret key that is known only to the sender of the message and the receiver of the message & produces a MAC as an output. By using the same MAC algorithm, a receiver can calculate the MAC of the received message and check the integrity of the message & authenticity of the message i.e., whether it is coming from the correct sender or not.
The sender and receiver share the same secret key to compute the MAC. This generated MAC is appended to the message and sent to the receiver. At the receiving end, the receiver also generates MAC with the same shared key which is compared with the MAC generated by the sender. If both the MACs are equal, then the message is valid and coming from the correct sender.
Hash Based Message Authentication Code (HMAC)
IEC-62351-6 recommends to use HMAC variant of the Message Authentication Code (MAC) for securing the GOOSE messages. HMAC uses Cryptographic Hash function and Shared Secret key to generate the MAC value (HMAC uses Symmetric keys). As with any MAC, HMAC is used to simultaneously verify both the data integrity and authenticity of a message.
The HMAC function with SHA-256, mixes a secret key with the message data, hashes the result with the hash function, mixes that hash value with the secret key again, and then applies the hash function a second time. The output hash is 256 bits in length.
IEC-62351-6 mandates implementing HMAC with SHA-256 for Securing GOOSE messages.
Message Encryption & Decryption
There are two types of Encryption technologies that are used in the industry:
- Symmetric key encryption
- Asymmetric key encryption
In Asymmetric encryption, the Subscriber has a key pair (Public Key + Private key) and it provides the Public Key to the Publisher, when the Publisher Encrypts the message to be sent with Subscriber’s Public key, the Subscriber is able to Decrypt the message with its Private key. This works well for a peer-to-peer client-server relationships, but there is difficulty to scale it with Multicast traffic because all the Subscriber’s would then need the same Private key and the Private key should never be shared.
There is another technology called Symmetric key encryption, where there is a Group Key that is managed and which is distributed to all the members of the Publication group. The Publisher, encrypts the message with the Group key and publishes the message, any member that is provided with the Group key can now decrypt the message. Because the same Group Key can be used by multiple Publishers and Subscribers that are part of the same Group, this mechanism of encryption & decryption can be used for Secure GOOSE message encryption.
However, there would be a need for secure distribution of this Group Key. This is done by the Key Distribution Centre or KDC.
Key Distribution Centre – KDC
As can be seen from the description above, implementation of security on GOOSE (Authentication, Integrity checks and Encryption) requires that a symmetric Key be distributed to all members of a Security Group and Publisher/Subscriber of the GOOSE messages have to be part of this Security Group. The function or device that delivers the Symmetric key to the members is known as a Key Distribution Centre or KDC. Membership in a Security Group is authenticated through validation of Digital Certificates held by Group Members and the KDC. Thus, each device would have to produce a Digital Certificate which has been issued by a trusted Certificate Authority to become a part of a Security Group.
The communication process starts with the establishment of a secure, authenticated channel for communication between the KDC server and IED device, which is also referred as the Phase 1 of the process.
Although there are two mechanisms of authentication allowed by GDOI (Group Domain of Interpretation), IEC 62351-9 mandates the use of certificate credentials exchanged at connection time. All IED’s obtain the digital certificate prior to establishing the connection with the KDC server. This certificate needs to be issued by a trusted CA. IED Device and the KDC perform mutual authentication, so the IED sends its own certificate and requests KDC’s certificate. Once the certificate from KDC is received, the IED verifies that the certificate is valid.
GDOI uses IKE Phase 1 exchanges defined in RFC 2409 to protect the Phase 2 exchanges for establishment of a security association and download of session keys to be used for signing data and optionally encryption.
Phase 2 starts with the IED identifying the group it requests keys for. The KDC server checks if the IED requesting keys is a member of the group it is servicing. If it is, the KDC server responds to this request with the policies it intends to use (Ex: encryption and signature algorithms). The policies are returned as part of a security association message. If the client supports the policies, it acknowledges it and a key download exchange follows, in which the KDC server sends the actual keys. If the client does not support the policies, it ends the connection, while issuing an event and setting an alarm.
With Symmetric Key now available, the device publishing GOOSE messages, adds a signature with the GOOSE message which is provided using symmetric keys being applied to create a secure HMAC. The signature is added at the end of the packet, after the payload and it is used for authentication and integrity check. Additionally, the key can be used for Encrypting the GOOSE data exchange.
This is a high level overview of Layer-2 Security Wrappers for Multicast GOOSE. Encrypting GOOSE messages is not recommended because of the CPU and latency that gets introduced when every packet has to be encrypted and decrypted.
A high level architecture of a Substation with KDC is shown in the diagram below. KDC can serve multiple substations and also be configured in a High Availability to provide resilience. Although, IEC-62351 standard for Key Distribution allows last known good Key to be used in the event the KDC is not reachable.
As a first step, all the devices that participate in Secure GOOSE communication should get a Digital Certificate from a Certificate Authority that is trusted by all the parties involved in this communication.
In the second step, Publishing & Subscribing IED’s would Authenticate to KDC and get the Symmetric Key.
And in the third and final step, depending upon the Policy, the Publisher of Secure GOOSE message would append Signature and/or Encrypt the GOOSE payload as it publishes this message on the network.
Let’s now take a look at a few packet captures of GOOSE traffic with:
- No Security
- Secure GOOSE with Authentication & Integrity Check
- Secure GOOSE with Authentication, Integrity check and Encryption
– GOOSE packet details without Security
This is a packet capture of Layer-2 GOOSE communication (without security) and as can be seen, the entire data flow is in clear text.
– Secure GOOSE Packet with Signature & without encryption details
This is a packet capture of Secure GOOSE communication with Signature of the Publisher. With the Symmetric Key (provided by KDC to Publisher & Subscriber), Subscriber can verify the signature of the Publisher.
– Secure GOOSE Packet with Signature & with Encryption details
This is a packet capture of Secure GOOSE communication with Signature of the Publisher & Encryption of the data. With the Symmetric Key (provided by KDC to Publisher & Subscriber), Subscriber can verify the signature and decrypt the data.
In conclusion, the argument that GOOSE messages are contained within a Substation doesn’t hold good in the context of present-day threats. Since natively GOOSE doesn’t support basic security such as Authentication & Integrity verification, the protocol is prone to spoofing and manipulation. IEC-62351-6 defines measures to Secure GOOSE communication and in this post I have shown how this could be accomplished.
Disclaimer: “The views expressed in this post are my own and do not necessarily reflect the views or positions of my organization.”
