Standards Development

Scope

This document specifies stand-alone MACsec profiles for the enablement and use of confidentiality via low-latency cryptographic methods for protocols based on the IEC 61850 series of standards. It focuses on the use of IEEE 802.1AE-2018 MACsec as a data-plane encryption mechanism which complements the methods already described in IEC 62351-6. In fact, MACsec can utilize the same message authentication (AES-GMAC) and confidentiality (GCM-AES) algorithms described in that standard with the primary difference being where in the network stack the individual device implements hardware-accelerated cryptographic computations.

The differences between IEC 62351-6 and this document are summarized here:

IEC 62351-6: cryptographic integrity and confidentiality controls are specified for OSI Layer 7 (L7; the application layer). This allows the implementation to be truly end-to-end across network routers, network-address translation (NAT) devices, protocol proxies, gateways, and message-level communication brokers. Cryptographic acceleration at L7 generally requires either software, firmware, or FPGA-supported cryptographic acceleration methods, or a combination of software and firmware plus general-purpose computational processor cryptographic acceleration to secure communication flows. This method may contribute to per-frame latency when encrypting Layer 2 GOOSE or Sampled Values for some embedded devices. IEC 62351-16 (MACsec): the cryptographic integrity or confidentiality controls are specified for OSI Layer 2 (L2; the data-link layer). This limits the implementation to being either hop-by-hop (where network switch elements are involved in the MACsec system) or end-to-end only across the OSI Layer 2 system (where network switch elements take no part in the MACsec system), since MACsec cannot be successfully converted to routable or NAT-based networks without additional tunnelling methods. However, numerous PHY and ASIC vendors provide widely-available cryptographic acceleration options at L2 that are able to minimize latency to the point of being negligible to power system protection. In this scenario device firmware and software can offload the computationally intensive cryptographic functions for Layer 2 GOOSE and Sampled Values to Ethernet-level silicon.

Switches and routers that constitute modern Ethernet infrastructure elements commonly implement IEEE-standard MACsec to support high-speed Ethernet traffic flows at line-rates. Like the existing cryptographic methods specified in IEC 62351-6, MACsec features a simple symmetric cryptographic key design featuring a natural resistance to quantum cryptanalytic attacks. When combined with IEEE 802.1X-2020 MACsec Key Agreement (MKA) or IEC 62351-9 GDOI key management methods, the primary benefit of a MACsec implementation is to secure protocols based on IEC 61850 for years or decades without requiring changes in cryptographic cipher suites or algorithms.

IEC 62351-16 complements IEC 62351-6 by providing the following features:

Enable the use of MACsec to provide line-rate encryption for Layer 2 GOOSE and Sampled Values via common Ethernet cryptographic accelerators. In most cases this will require support for MACsec-supporting Ethernet PHYs via the network interface component of the implementing IED. Enable the use of MACsec to optionally provide Ethernet Layer 2 “wrapper” or “bump-in-the-wire” capabilities by encrypting and authenticating all IEC 61850 protocols traversing Ethernet layer zone interconnects simultaneously at the same time as IEC 61850-9-3 (PUP) critical timing functions and IEC 62439-3 PRP/HSR redundancy mechanisms. MACsec can be terminated either at OSI layer 2 zone interconnects or at the individual IED. Expand GDOI protocol as developed in IEC 62351-9 to support MACsec key distribution as a payload.

Additional considerations in this document encompass interoperability with non-MACsec devices, real-time traffic inspection methods, and end-to-end enablement over an OSI L2 domain in cases where the network elements (switches) are not trusted.

This document does not specify or mandate the following:

Network access control (NAC) authorization policy. This document integrates portions of IEEE Std 802.1X-2020 Clause 9 (MKA), which may be used as a NAC mechanism, but does not mandate or give guidance for the decisions that determine whether a device is admitted to the network. NAC architecture guidance is given in IEC TR 62351-10. Ethernet Data Encryption device (EDE) operation. The Layer 2 wrapper / bump-in-the-wire deployment of this document is realized by terminating MACsec at the zone interconnect under Profile A (hop-by-hop); the EDE types defined in IEEE Std 802.1AE-2018 (originally IEEE Std 802.1AEcg-2017) for transparent MACsec across provider bridged and provider backbone networks are not used by this document. MAC privacy protection. MAC privacy (IEEE Std 802.1AEdk-2023) is permitted but not required; its mechanisms (MAC Privacy Protection PDUs and Privacy Channels) are not further specified here. This document relies on IEEE Std 802.1AEdk-2023 only for the SecY MIB revisions of 7.3 (the related threat evaluation is in Clause 4).

MACsec requires the use of GCM-AES as its default cryptographic cipher suite for properties related to authenticated encryption with associated data (AEAD). However, the MACsec protocol itself contains provisions that allow for alternative cipher suites of various key sizes. For example, IEEE 802.1AE-2006 MACsec originally supported only GCM-AES-128 with a 32-bit packet number but was later expanded to support GCM-AES-256 (IEEE Std 802.1AEbn-2011, still with a 32-bit packet number) and the GCM-AES-XPN cipher suites with 64-bit packet numbers (IEEE Std 802.1AEbw-2013), both consolidated in IEEE 802.1AE-2018.

As of February 2023, the Ascon AEAD algorithm family has been selected by NIST for lightweight cryptography standardization, published as NIST SP 800-232. Ascon is the winner of the 2019 CAESAR cipher competition and produced in part by Graz University (AT) and Radboud University (NL) and was specifically designed for secure and efficient implementation on constrained devices. Ascon can be considered superior to GCM-AES in some circumstances due to its efficiency and low-resource consumption, which makes it particularly suitable for resource-constrained devices such as those used in Power and Energy System (PES) applications. In this document we propose a solution to expand MACsec to integrate the Ascon cipher suite.

Note well that if GCM-AES used by MACsec is accelerated in software rather than hardware, then the latency and overhead would be similar to the existing methods outlined in IEC 62351-6:2020. However, the intent of this document is to enable readily available hardware-accelerated cryptographic components (Ethernet PHYs) rather than software-based cryptographic components. Furthermore, the development of Ascon for MACsec associated with the Part 16 effort should make software-only implementations more feasible for resource-constrained devices.