Control of multicast requests in the IEC 61850 standard

Multicast communication is widely used at the process level, since it fulfils the operational requirements and facilitates peer-to-peer communication, where the destination of the message need not be known to the sender. Multicast messages play a crucial role in electricity grid systems. IEC 61850, used for the design and configuration of the automation in a substation, sets out two multicast protocols: Generic Object-Oriented Substation Events (GOOSE) and Sampled Measured Value (SMV or SV). These protocols are used to collect information about the status of the network in real time, to update the status of Intelligent Electric Devices (IED) and to retransmit control commands.

Security and integrity in these communications is a challenge in the electricity grid, mainly for the following reasons:

• The system's complex design makes necessary to integrate ownership configuration tools from different manufacturers and, at the same time, implement standard security protocols. This is a complex and error-prone task in the provision of group keys and policies. A poor configuration could lead to a violation of security policies, such as the delivery of sensitive data information to a non-legitimate device.
• Several requirements imposed by the IEEE Substation Committee involve changes in latency in security protocols. There are messages that need to be delivered in a short space of time, defined according to the functionalities of a substation, such as GOOSE messages, which have to be delivered within 2 to 10 ms. The IEC 62351-6 standard provides for authentication of GOOSE messages through public key signatures; it does not guarantee the time requirements due to latency derived from the signatures.
• A feasible and integrated key management is necessary for security in the multicast system of the electricity grid.
• A balance between efficiency, feasibility and cost must be found.

Within an electrical substation there may be hundreds of IED devices, which are connected via the Ethernet to transmit data and management commands among them or to the control centre. IEC 61850 provides a series of guidelines for implementing these communications, which allow object-oriented data modelling so that equipment such as IED or RTU transmit information related to supervision and control functions.

- Operation of a multicast system -

Security elements in a multicast system

A multicast security system consists of a series of data objects, a group of data owners, a set of data clients, publishers, subscribers and controllers. The components that are related to data objects are called entities, so the data owners and clients, among others, are in turn entities.

There are four types of entities in the multicast model:

• Data owner: an entity that owns or hosts a series of data objects. Any electronic device with access to a data object is an owner.
• Data client: a user who needs a data object to operate, such as electrical manoeuvring equipment.
• Publisher: publishes data objects through multicast, such as a protective relay that issues commands to the switches. A publisher does not have to be the owner of the data objects.
• Subscriber: entity that subscribes to a publisher's data objects. It may be a switch that executes the commands that a relay issues. An entity can be a publisher and subscriber at the same time, for example, a protection relay that sends a TRIP command behaves as a publisher, but when the status of the switches is reported it behaves as a subscriber.

The multicast model contains the role of group controller, which provides group membership and group key management service. The tasks he/she carries out are:

• Authorising group access privileges based on groups of members derived from system configurations.
• Generating, distributing and updating shared group keys.
• Revoking member groups based on configuration changes.

Problem with the IEC 61850 multicast model

There is a series of problems related to multicast messages that result in a series of anomalies.

• Ownership anomaly: it happens when a publisher publishes a data group consisting of a set of data objects he does not own. This anomaly happens if, for example, an IED is configured to take data attributes it does not own as part of the GOOSE message payload.
• Redundant publication: it happens when a publisher publishes a data group but there is no entity that consumes or subscribes to it. There are two types of redundant publication:
  • Total redundancy: no data object is required by a consumer.
  • Partial redundancy: there are consumers who use some data object.
• Provenance anomaly: a subscriber applies to subscribe to a data group published by a publisher that no longer exists in the system. This could happen if a publisher is removed or withdraws from the system.
• Data dissatisfaction: this type of anomaly appears when a consumer requests a subscription to a data group but there is no publication that provides all the required data objects. There are two types of data dissatisfaction:
  • Hard dissatisfaction: one or more data objects in the group are not published by the publisher.
  • Soft dissatisfaction: one or more objects in the group are not published by the publisher in a specific publication but are found in other publications.

Safe design of the multicast model

To detect possible failures there is a series of algorithms that are based on the comparison of a series of keys. These keys are generated by all the entities involved in the system to detect the anomalies and report the error.

An appropriate way to achieve an effective and safe multicast model is by implementing a design called Security Extended Configuration, based on:

• Demanding credentials for the exchange of group keys.
• Additional network entities, which facilitate communication security, such as a group key server.

A series of measures are set out in the design of the multicast model, based on the Internet Protocol security (IPsec) protocol, to protect the multicast packets:

• Group Policy Engine (GPE), which transforms the multicast model into a group authorisation policy and traffic policy.
  • The authorisation policy specifies what body or IED may join the group and share the group keys. It is used by group controllers to manage group membership.
  • The traffic policy is used to enforce the security services in individual packets such as signature and signature verification.
• Group Internet Key Exchange (GIKE) is a protocol that is used for management of group membership authorisation and management of group keys.

Conclusion

With the new global change in the decentralisation of energy generation and the implementation of smart grids, optimisation and safety in electrical substations becomes necessary. Many pieces of electrical system infrastructure were designed decades ago without taking into account vulnerabilities and threats that currently represent a problem for guaranteeing the electricity supply.

An effective design in the multicast model would prevent many of the problems that the IEC 61850 model did not take into account when it was drafted.