## 5 Communication Dependability
### Cybersecurity for IEC61850 Multicast Communication in Wide-Area Applications
#### 5.2.1 Secured Messages
In a GDOI security mechanism (Table 4), there are three [19; 37] types of keying: Pairwise Key (PK), Key Encryption Key (KEK), and Traffic Encryption Key (TEK). Each group member (IED) is assigned a specific PK that is established in phase 1 during authentication of the IED to the KDC. The PK is used for securing communication in phase 2 during GROUPKEY-PULL when any authenticated IED acquires security policies and keying material (KEK and TEK) from the KDC. KEK is a symmetric cipher-key using for securing GROUPKEY-PUSH messages containing updates, i.e., new security policies and new keying material (new KEK and/or new TEK). TEK is a symmetric cipher-key that is used for securing (signing or encrypting) messages communicated among group members, i.e., the IEDs. Therefore, TEK can be the Authentication Key (AK) or the Encryption Key (EK) depending on its use; AK for authentication/signature calculation and EK for message encryption. Figure 8 represents the communication of secured R-SV/R-GOOSE messages between authenticated IEDs while security policies and keys are frequently updated by a single KDC in the centralized security architecture. During GROUPKEY-PULL, the Sender and Receiver IEDs request KDC for the security policies and key materials. KDC replies and provides security keys (KEK and TEK) and their policies to the IEDs. All the messages exchanged during GROUPKEY-PULL are encrypted with PK. Then, the IEDs use the received TEK for securing (signing and/or encrypting) R-SV/R-GOOSE messages based on the received security policy. Additionally, the IEDs use KEK for securing communication related to receiving updates from KDC. According to GDOI, the security policies and keys have a defined validity time and should be updated frequently. Therefore, KDC periodically replaces them (rekeys) and pushes the updates (new policies as well as new KEK and new TEK) via a single GROUPKEY-PUSH message. This message is encrypted with the current KEK and is sent from KDC to the IEDs. Thereafter, the IEDs periodically receive fresh security keys (KEK and TEK) as well as their security policies. IEC62351-9 [39] describes mechanisms for exchanging security keys provided by KDC and methods for the security policy and keying materials. The scenario depicted in Figure 8 is based on a centralized security architecture in which only one KDC that is responsible for the security of the whole system is used. In contrast, Figure 9 depicts distributed KDCs in a decentralized security architecture. In Figure 9, authors propose two possibilities for decentralized security architectures: Fully Connected and Hierarchical architectures. In the Fully Connected architecture, any redundant KDCs are connected to each other and have the same level of functionality needed to provide complete redundancy. Each KDC is responsible for the authentication of the GMs in its own substation. However, it also informs all the external KDCs about updates such as registered GMs and group memberships. The KDCs are numerically prioritized as an ordered list, which is provided to all the GMs for registration. In this list, the first one functions as the Primary KDC, and the rest are rega  
Figure 8: Communication of secured R-SV/R-GOOSE within centralized security architecture. in standby mode. The Primary KDC is responsible for delivering security policies and key materials to the registered IEDs via GROUPKEY-PULL and GROUPKEY-PUSH. If the Primary KDC fails, the GMs search the ordered list and register the next KDC on the list, which becomes the Primary KDC from that moment onward. In Hierarchical architecture, there are two types of KDCs: the upper level KDC and the lower level KDCs. The upper level KDC distributes security policies and key materials to all the lower level KDCs that use the received materials for GROUPKEY-PULL and GROUPKEY-PUSH with their local GMs. The lower level KDCs are responsible for authentication of their local GMs but they must also update their upper level KDC about the registered GMs.