TimeOfCurrentKey – The standard does not specify the reference point from which a publisher must start TimeOfCurrentKey. IEC 61850-8-1 Ed.?2.1 merely defines it as “the time at which the current HMAC and encryption key was first used.”
Consequently, it is unclear which moment the publisher should report in the following situations:
1. Initial key download – When the publisher first receives keys (K0), it publishes TimeOfCurrentKey using its own time stamp.
2. Automatic transition – When K1’s ATD expires, the publisher switches to K1. At that moment, TimeOfCurrentKey should again be the publisher’s time when the first sample with K1 is sent.
3. Subsequent GDOI pull – During the next GDOI PULL, the publisher receives two keys (K1 as the new K0 and K2 as the new K1). It is unclear which time value should be reported for TimeOfCurrentKey in this case.
TimeOfNextKey – The standard does not provide a detailed explanation for this field. IEC 61850-8-1 Ed.?2.1 defines it as: "A relative time that indicates the time before another key is put into use for the HMAC and encryption."
Furthermore, as TimeToNextKey is defined as a signed integer, the KDC's shall ensure that key rotation is supported up to the maximum allowable value for TimeToNextKey.
Proposal
To ensure consistency between the publisher and subscriber, we recommend the following approach:
TimeOfCurrentKey
Definition for Implementation:
TimeOfCurrentKey should reflect the publisher's local time when it first uses the key in actual data transmission, regardless of when the key was received via GDOI.
Handling for Different Scenarios:
1. Initial Key Load (K0):
When the publisher receives K0 for the first time and begins publishing with it, the timestamp when the first valid message is sent should be recorded as TimeOfCurrentKey.
2. Automatic Key Transition (K1 after K0 ATD expiry):
When the publisher switches to K1 after K0's ATD expires, the time when the first message is sent using K1 must be recorded as TimeOfCurrentKey.
3. Subsequent GDOI PULL (e.g., receiving K1 as new K0, K2 as new K1):
In this case, TimeOfCurrentKey should not be updated, since K1 was already used earlier. The publisher should retain the original TimeOfCurrentKey from scenario 2 (i.e., when K1 was first used in transmission). This approach ensures proper synchronization between publisher and subscriber, and avoids unnecessary re-alignment of key usage states.
By consistently using the first transmission time of a given key as the basis for TimeOfCurrentKey, both publisher and subscriber maintain a shared reference point for key usage, even across re-keying events.
TimeOfNextKey
Definition for Implementation:
TimeOfNextKey represents the remaining time before the publisher starts using the next key. It is a relative duration indicating how long the current key will continue to be used before a key transition.
Handling for Different Scenarios
Initial Key Load (K0)
When the publisher receives K0 for the first time and begins publishing with it, TimeOfNextKey should be set to the ATD
of K1. The countdown begins from the moment K0 is first used for publishing.
Automatic Key Transition (K1 after K0 ATD expiry)
When the publisher transitions to K1 after K0's ATD expires, TimeOfNextKey shall be set to -1, indicating that no next key is currently available at this moment.
Subsequent GDOI PULL (e.g., receiving K1 as new K0, K2 as new K1)
In this scenario, TimeOfNextKey follows the logic of scenario 1. After receiving new keys via GDOI—where K1 becomes the new K0 and K2 becomes the new K1—TimeOfNextKey should be set to the ATD of the newly received K2, starting its countdown from when K1 is first used.