The Publisher or Subscriber use keys provided by an SKS to secure messages exchanged via the Message Oriented Middleware. The handshake to pull the keys from a SKS is shown in Figure 10. The handshake to push the keys from an SKS to Publishers and Subscribers is shown in Figure 11.

Figure 10 – Handshake used to pull keys from SKS

To pull keys, the Publisher or Subscriber creates an encrypted connection and provides credentials that allow it access to the SecurityGroup. Then it passes the identifier of the SecurityGroup to the GetSecurityKeys Method that verifies the identity and returns the keys used to secure messages for the PubSubGroup. The GetSecurityKeys Method is defined in 8.3.2.

The access to the GetSecurityKeys Method may use SessionlessInvoke Service calls. These calls typically use an Access Token that is retrieved from an Authorization Service. Both concepts are defined in OPC 10000-4.

Figure 11 – Handshake used to push keys to Publishers and Subscribers

To push keys, the SKS creates an encrypted connection to a Publisher or Subscriber and provides credentials that allow it to provide keys for a SecurityGroup. Then it passes the identifier of the SecurityGroup and the keys used to secure messages for the SecurityGroup to the SetSecurityKeys Method. The SetSecurityKeys Method is defined in 9.1.3.3.

If the initial pull or push fails, the affected PubSub components like WriterGroup or DataSetReader stay in the PreOperational state. If the updates fail and the PubSub components do not have up to date key material, the state of the affected components change to Error. For both pull and push, the Client executing the key exchange needs to retry the key exchange at a faster rate than the key lifetime.