The Publisheror Subscriberuse 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 Publishersand Subscribersis shown in Figure 11.

image013.png

Figure 10– Handshake used to pull keys from SKS

To pull keys, the Publisheror Subscribercreates an encrypted connection and provides credentials that allow it access to the SecurityGroup. Then it passes the identifier of the SecurityGroupto the GetSecurityKeys Methodthat verifies the identity and returns the keys used to secure messages for the PubSubGroup. The GetSecurityKeys Methodis defined in 8.3.2.

The access to the GetSecurityKeys Methodmay use SessionlessInvoke Servicecalls. These calls typically use an Access Tokenthat is retrieved from an Authorization Service. Both concepts are defined in OPC 10000-4.

image014.png

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

To push keys, the SKS creates an encrypted connection to a Publisheror Subscriberand provides credentials that allow it to provide keys for a SecurityGroup. Then it passes the identifier of the SecurityGroupand the keys used to secure messages for the SecurityGroupto the SetSecurityKeys Method. The SetSecurityKeys Methodis defined in 9.1.3.3.

If the initial pull or push fails, the affected PubSubcomponents like WriterGroupor DataSetReaderstay in the PreOperationalstate. If the updates fail and the PubSubcomponents do not have up to date key material, the state of the affected components change to Error. For both pull and push, the Clientexecuting the key exchange needs to retry the key exchange at a faster rate than the key lifetime.