167   Replay attack for GOOSE and SV

Created: 20 May 2026

Status: Triage

Part: Part 6 (2020, Edition 1)

Links:

Page: 15 and 19

Clause: 6.2.1.2 and 6.2.2.3.1

Paragraph: N/A

Issue

In the replay state processing requirements described in clause 6.2.1.3 and 6.2.2.3.2 and illustrated in figures 2 and 3, the replay states are only checked when the current replay state is not invalid (i.e. when the current replay state has been initialized and is currently tracking a value). However, for both GOOSE and SV a mechanism exists in which that state can be re-initialized to an invalid value (i.e uninitialized) by triggering multicast association loss detection (steps 11-12-13 in both figure 2 and 3). This can be achieved by an attacker by intercepting and dropping or delaying packets for a time greater than the configured timeout delay to reinitialize the value. At that point, an attacker can replay previously recorded packets, even if they are encrypted or authenticated (assuming the key has not changed) and they would not be rejected by the replay state machine.

Proposal

In clauses 6.2.1.2 and 6.2.2.3.1 (security check protection requirements), add an additional security validation in which data timestamps (e.g. timestamp value in APDU) are checked against the absolute value of the receiver clock to ensure the timestamp values are greater or equal to the current value of the receiver clock and lesser or equal to the current value of the receiver clock plus a configurable delta. This requires that the clocks or the sender(s) and the receiver(s) are synchronized. The data timestamps are protected by encryption and/or authentication and cannot be modified by an attacker without knowledge of the key. As such, replaying the contents of a secured GOOSE or SV message would have timestamps in the past, which would fail the proposed additional data integrity check.