IEC 62351-Compliant MAC Scheme

Updated 2 December 2025

The IEC 62351-compliant MAC scheme is a cryptographic framework employing AES-GMAC-128 with a pre-shared 128-bit key to authenticate and ensure the integrity of GOOSE messages.
It appends MAC extensions to existing Layer-2 frames without altering core GOOSE fields, maintaining backwards compatibility and compliance with IEC 61850 protocols.
Testbed implementations show sub-millisecond average latency for MAC verification, meeting stringent real-time and mission-critical substation automation requirements.

IEC 62351-Compliant Message Authentication Code (MAC) Scheme defines the cryptographic framework underpinning real-time authentication and tamper detection in digital substations, specifically addressing GOOSE (Generic Object Oriented Substation Event) messaging per IEC 61850. The IEC 62351-6:2020 standard mandates symmetric-key MACs to ensure message integrity and authenticity, embedding cryptographic extensions into Layer-2 frames without altering core protocol semantics. These schemes are intended to meet stringent latency and reliability constraints typical of mission-critical substation automation while supporting future extensibility and compliance with evolving cybersecurity regulation (Herath et al., 24 Nov 2025).

1. Cryptographic Algorithm Specification

The IEC 62351-compliant MAC scheme employs AES-GMAC-128 as its cryptographic primitive. The configuration is characterized by:

Keying: A 128-bit symmetric key $K$ is pre-shared between communicating IEDs (Intelligent Electronic Devices).
Initialization Vector: Each GOOSE message (PDU) uses a unique IV (initialized per message, randomly or sequentially), appended in plaintext.
MAC Computation: Let $P$ denote the GOOSE PDU (excluding security extensions), and IV the per-message initialization vector; the tag is:

$\mathrm{tag} = \mathrm{AES\mathchar`-GMAC}_K(\mathrm{IV}~\|~P)$

The IV, a key ID (to select the correct entry in a local key table), and the resulting tag are appended as extension fields in the outgoing frame (Herath et al., 24 Nov 2025).

2. Message Structure, Protocol Embedding, and Backwards Compatibility

The MAC extension is appended to (not embedded within) the GOOSE application data, preserving original field semantics such as APPID, stNum, sqNum, datSet, and timeAllowedToLive. The appended IEC 62351-6 extension fields comprise:

Field	Typical Size	Purpose
Reserved1	16 bits	Reserved for future use
IV	96–128 bits	Per-message initialization vector
Reserved2	16 bits	Reserved for future use
Key ID	8 bits	Key selection among pre-distributed set
MAC tag	128 bits	AES-GMAC authentication tag

These are encoded in ASN.1/BER as a TLV sequence, appended transparently at the protocol’s lower layers. The technique leaves pre-existing GOOSE semantics unchanged, enabling incremental deployment and backwards compatibility (Herath et al., 24 Nov 2025).

3. Key Management and Distribution

Key management relies on a set of pre-shared symmetric keys, with operational procedures comprising:

Offline generation: Keys are distributed out-of-band during commissioning or through subsequent secure updates.
In-device storage: Each IED maintains a key table indexed by key ID, with the relevant key selected dynamically per message.
Rollover procedures: Key refresh operations follow guidelines in IEC 62351-6, including rolling key IDs and secure re-distribution. Key-management servers or strictly-controlled manual procedures are recommended to maintain compliance.
Security mandates: Keys and key IDs in packets are managed in accordance with IEC 62351-6:2020, ensuring that only authenticated nodes share valid cryptographic material (Herath et al., 24 Nov 2025).

4. Implementation, Measured Performance, and Integration

The scheme was prototyped using a simulated IED platform (Ubuntu Linux, 4 GB RAM), Mininet for virtualized networking, and a Ryu OpenFlow controller for programmable packet filtering. MAC computation leveraged Python’s Crypto.Cipher.AES and Scapy for frame manipulation.

In realistic testbed conditions—mixed steady-state and burst GOOSE traffic—the following performance metrics were observed:

Technique	Avg latency (ms)	Max latency (ms)
AES-GMAC-128 verification	0.38	0.64
Rule-based IDS checks	0.25	0.40
Hybrid (MAC + IDS)	0.54	0.88

All averaged and maximal latency figures for the cryptographic MAC and combined techniques remained well below the 3 ms budget mandated for Type 1A GOOSE events. The deployment involved no special hardware acceleration or optimized crypto libraries, establishing the practicality of the approach with default infrastructure (Herath et al., 24 Nov 2025).

5. Security Properties and Attack Coverage

Security and functional evaluation focused on four main attack classes:

Replay Attack: Undetected in pure MAC mode, as the tag validates any captured (tag, IV, PDU) tuple. Hybrid MAC plus rule-based IDS, using stNum/sqNum sequence checking as per IEC 62351-6, provides replay mitigation.
Masquerade Attack (Message Tampering): Any modification of PDU fields yields a MAC mismatch and is dropped.
Flooding DoS (Denial-of-Service): All malicious packets fail MAC verification, imposing negligible processing or bandwidth load.
Packet-Drop DoS: Not mitigated; the MAC mechanism cannot restore integrity or availability if legitimate packets are simply lost in transit.

Attack coverage summary:

Attack Type	MAC-only	Rule-based IDS	MAC + IDS (Hybrid)
Replay	No	Yes	Yes (IDS detects)
Masquerade (field tampering)	Yes	No	Yes (MAC detects)
DoS (flood)	Yes	Partial	Yes (early drop)
Packet-drop	No	Partial	Partial

Authenticity and integrity of GOOSE messages are cryptographically guaranteed. Replay resistance is achieved only in hybrid deployments or with protocol-specific sequence checking. DoS flooding resilience is strong in MAC-verified nodes, but availability under packet-drop attacks is an open challenge (Herath et al., 24 Nov 2025).

6. Known Limitations and Future Directions

Several technical limitations and research directions are identified:

Packet-drop DoS remains fundamentally unmitigated by cryptographic means; solutions would require augmented network-layer controls or path redundancy such as SDN/OpenFlow traffic policing or PRP/HSR redundant topologies.
Key management automation (e.g., PKI, KMS integration) is not implemented in current testbeds, representing a necessary evolution for large-scale real-world adoption.
Hardware acceleration using dedicated AES-GMAC units (FPGA/ASIC) and optimized crypto libraries is posited to further decrease verification latency, supporting expansion toward bandwidth-intensive applications like sampled values (SV).
The separation of core protocol data from MAC extension fields ensures minimal operational impact but may necessitate future updates as threat models and interoperability requirements evolve (Herath et al., 24 Nov 2025).

7. Comparative Approaches and Standards Context

While the IEC 62351-compliant scheme targets Layer-2 GOOSE and SV message authentication, alternative and complementary MAC designs exist, such as the TMAC+UID construction employing time-dependent HMACs and unique message identifiers for replay resistance (Gupta, 2016). TMAC+UID introduces rotating time windows and per-message unpredictability at the application layer, demonstrating that HMAC- and AES-GMAC-based approaches both offer computational security, tunable overhead, and protocol-mappable deployment models. The choice of primitive and integration strategy is guided by field-level latency constraints, security policy, and protocol extensibility requirements defined by IEC 62351 and its allied substation automation standards.