IEC 61850 GOOSE and sampled values (SV) travel at layer 2, in multicast and with millisecond timing, so they cannot use TLS as MMS or IEC 104 do. IEC 62351-6 protects them with a message authentication code calculated with a key shared by the publisher and its subscribers: the subscriber discards anything that does not come from the authorized sender or was altered. Group keys are distributed by a key distribution center using the GDOI protocol, under IEC 62351-9.
Why GOOSE and SV are a special case
A GOOSE message carries trips, blocks and interlocks between relays. A sampled values stream carries the digitized currents and voltages that protections use. Both are published as layer 2 multicast, with no IP address, and must arrive in milliseconds. A fake GOOSE can open a breaker; an altered SV stream can make a differential see a fault that does not exist, or miss a real one.
That is why the tools of TCP/IP protocols do not work. TLS needs a session between two endpoints, and GOOSE and SV have no session: a publisher sends to a group of subscribers. The IEC 62351 series gives them two parts: part 6, which defines message security, and part 9, which manages the keys.
What IEC 62351-6 does
IEC 62351-6 covers the security of IEC 61850: GOOSE, sampled values and configuration files. For layer 2 messages, the main goal is authentication and integrity:
- The publisher calculates a message authentication code (MAC) with a symmetric key that it shares with its subscribers, and adds it to the message.
- Each subscriber recalculates the code with the same key. If it does not match, the message was altered or does not come from a member of the group, and the subscriber discards it.
- Confidentiality, meaning that nobody can read the content, is not the main goal for these messages. What matters is that nobody can inject or modify.
That choice has an engineering reason. A symmetric-key authentication code is much faster to calculate than a public-key signature, and time is the constraint that rules in a GOOSE trip.
What IEC 62351-9 does: group keys
If all members of a group share a key, someone has to generate it, deliver it only to the authorized members and change it periodically. That is what IEC 62351-9:2023 defines for group communication. A key distribution center (KDC) delivers the keys with the GDOI protocol, an IETF protocol extended for IEC 61850 (RFC 8052).
- Publisher or subscriber relay in service
- Phase 1. The relay and the KDC authenticate with certificates and open a secure channel
- Key request. The relay asks for the key of the GOOSE or SV stream it publishes or subscribes to
- Is the relay authorized for that stream? Yes: continue; No: The KDC does not deliver the key.
- Key delivery. The group key and its validity arrive over the secure channel
- The relay authenticates or verifies each message with that key
The standard provides two ways of delivery: the device requests the key (GROUPKEY-PULL) or the KDC sends it to the members (GROUPKEY-PUSH), for example when renewing it. The 2023 edition, which replaced the 2017 one, updated GDOI with the findings of interoperability tests and added operational considerations. It included GDOI support for PTP time synchronization of the power profile. It also added security event logging with its mapping to IEC 62351-14. How the origin and integrity of SCL files are protected is explained in IEC 62351-11: Securing XML and SCL Files.
Part 9 also covers the life cycle of the certificates with which each device authenticates to the KDC: issuing, verification and revocation.
What changes in system engineering
GOOSE and SV security is not a setting switched on at the end; it touches the whole IEC 61850 engineering:
- Key groups consistent with the SCD. Each GOOSE or SV stream has its subscribers in the SCD file (substation configuration description). The key groups must reflect exactly those subscriptions. A change of subscriptions without updating the groups makes the subscriber discard legitimate messages.
- Public key infrastructure. Someone issues the certificates of the IEDs and the KDC, sets their validity and publishes revocations.
- KDC availability. If it is not available when keys are renewed, streams can be left without a valid key. Its redundancy and its location in the network are design decisions.
- Reliable time. The validity of keys and certificates depends on time synchronization.
- Processing time. Calculating and verifying the code adds work to the IED. The manufacturer must state the performance with security active, and the timing test of GOOSE trips is repeated with it enabled. There is no single reference value: it depends on the device.
- Routable variants. When GOOSE or SV leave the substation over IP, as in R-GOOSE between substations, they cross shared networks and authentication becomes even more necessary.
When the equipment does not support it
Many IEDs in service do not implement IEC 62351-6. For them, protection comes from the network and the procedure, as IEC 62443 asks:
- The station bus and the process bus in their own zones, with no direct connection to external networks.
- VLANs and multicast filtering in the switches, so that each GOOSE reaches only the ports that need it.
- Unused ports disabled and control of the laptops and test equipment that connect, which grid cybersecurity guidelines treat as transient cyber assets.
- Intrusion detection that knows the baseline: which publishers exist, with what identifiers and at what rate. A new GOOSE or one with a state counter that jumps is an alert. See intrusion detection in substation networks.
- Supervision at the subscriber: relays already detect message loss and invalid quality, and that supervision must lead to a safe state.
What is tested
- The subscriber discards an altered GOOSE or one without the correct code and raises an event.
- Keys are renewed without losing legitimate messages.
- The behavior on KDC failure is the one planned in the design.
- Trip times by GOOSE with security enabled stay within what is specified; see protection tests with GOOSE.
- Security events reach the central server with the correct time.
We configure your IEC 61850 engineering
At Tiza Group we do the IEC 61850 engineering of substations: GOOSE and SV subscriptions, SCD, network segmentation and configuration of the security functions your IEDs support, within our specialties in IEC 61850 and substation and plant cybersecurity. We also configure relays remotely with remote relay configuration. Write to us with the equipment and architecture of your project. The domains and the placement of security controls are explained in IEC TR 62351-10.
Related guides
- IEC 61850 GOOSE
- IEC 61850 Sampled Values
- IEC 62351: cybersecurity for IEC 61850, 104 and DNP3
- GOOSE between substations: R-GOOSE
- GOOSE that does not arrive or arrives late
- Sampled Values and GOOSE bandwidth
- Substation and plant cybersecurity: standards and map
- Network and IED monitoring: IEC 62351-7
- IEC TR 62351-10: Security Architecture Guidelines
- IEC 62351-11: Securing XML and SCL Files
References
- IEC 62351-6:2020, Security for IEC 61850.
- IEC 62351-9:2023, ed. 2.0, Cyber security key management for power system equipment.
- IETF RFC 8052, Group Domain of Interpretation (GDOI) Protocol Support for IEC 62351 Security Services.
- IEC 62351-14, security event logging (in preparation).
- IEC 61850-8-1 and IEC 61850-9-2, mapping of GOOSE and sampled values.
- IEC 62443-3-3:2013, system security requirements.
Frequently asked questions
Why is GOOSE not encrypted like MMS traffic?
Because the main risk with a GOOSE is that someone injects or alters a message that opens a breaker or blocks a protection, not that someone reads it. The goal is therefore to authenticate the origin and integrity without adding delay, and TLS does not apply to layer 2 multicast messages.
What happens to GOOSE if the key server goes down?
Devices keep using the current key as long as it has not expired. The risk appears if the server is unavailable when the key must be renewed. That is why availability and redundancy of the key distribution center are part of the design, and its behavior on failure must be tested at commissioning.
If my relays do not support IEC 62351-6, how do I protect GOOSE?
With network measures: the station bus and process bus in their own zones, with no direct connection to external networks, VLANs and multicast filtering in the switches, unused ports disabled, control of the laptops that connect, and an intrusion detection system that knows the GOOSE baseline.