E.5 Interaction with an SKS

The usage of SecurityGroups is defined by OPC 10000-14 as follows:

  1. The SKS is responsible for generating keys for its configured SecurityGroups. The SKS may expose the SecurityGroups in its Information Model.
  2. A Publisher uses the current key to sign or sign and encrypt NetworkMessages, and Subscriber(s) to authenticate or authenticate and decrypt NetworkMessages. The past key, current key and a requested number of future keys are distributed from the SKS to the Publisher and the Subscriber(s) using the push or pull model. How past, current and future keys are stored and organized on the Publisher and Subscriber(s) is vendor-specific.

In the push model, the set of keys is pushed by the SKS to the AutomationComponents using SetSecurityKeys. In the pull model, the set of keys is pulled by the AutomationComponents from the SKS using GetSecurityKeys.

The SecurityGroupId links the key generation side (i.e., the SKS) and the key usage side (i.e., Publisher, Subscriber). If an AutomationComponent calls GetSecurityKeys on the SKS or an SKS calls SetSecurityKeys on the AutomationComponent with a specific SecurityGroupId, all WriterGroups and DataSetReaders utilizing the SecurityGroupId on the AutomationComponent will get the new set of keys.

PubSubKeyPushTargets are used on the SKS to manage the distribution of the keys for the push model. They have no equivalent on the key usage side. The SKS may expose the PubSubKeyPushTargets in its Information Model.

The SKS responsible for generating the security keys related to a ConnectionConfigurationSet is indicated in the ConnectionConfigurationSet by the SecurityKeyServer configuration. In addition, the SecurityKeyServer indicates whether to use the push or pull model for the distribution of the security keys.

Every UAFX implementation compliant with the “http://opcfoundation.org/UA-Profile/UAFX-Controller-Profile” supports the SKS push model. An AutomationComponent indicates support for the pull model by the Facets it includes in its ServerProfileArray (“http://opcfoundation.org/UA-Profile/Publisher/MessageSecurity” for a Publisher and “http://opcfoundation.org/UA-Profile/Subscriber/MessageSecurity” for a Subscriber). The ServerProfileArray may be retrieved online or from the Descriptor.

ConnectionManager and SKS may be located on the same Server. In this case, the ConnectionManager may use vendor-specific means to configure the SKS. If the ConnectionManager and SKS are located on different Servers, the SKS exposes its configuration model. A ConnectionManager may wish to optimize its communication with the external SKS. These examples illustrate this communication.

image142.png

Figure E.22 – Building the desired configuration for the SKS

As illustrated in Figure E.22, the ConnectionManager constructs the desired configuration for the SKS from the set of SecurityGroups and PubSubKeyPushTargets in the ConnectionConfigurationSet Object and PubSubCommunicationModelConfigurations of all AutomationComponentConfigurations in the ConnectionConfigurationSet (see 6.16.3 and Figure E.6). It is recommended that only the ConnectionConfigurationSet Object is used for holding the desired SKS configuration.

image143.png

Figure E.23 – Updating the SKS to configure a push model

Figure E.23 illustrates the configuration of the SKS for the push model.

The ConnectionManager applies the desired configuration on the SKS:

The SKS will not return an error if the SecurityGroup or the PubSubKeyPushTarget (with the same parameters) is added multiple times.

After the SKS configuration is finished, the SKS will start to periodically push the keys to the AutomationComponents registered with the push targets. A push target will accept keys only if they are from an SKS that is trusted and the SecurityGroupId is known. SecurityGroupIds (for a Publisher in the WriterGroup and for a Subscriber in the ReaderGroup/DataSetReader) are configured by the ConnectionManager on the AutomationComponent as part of the EstablishConnections Call. If a push target rejects SetSecurityKeys, the SKS will continue to retry at RetryInterval. If a push target accepts SetSecurityKeys, the SKS will repeat pushing keys at a period of half KeyLifetime (see OPC 10000-14).

For a push model configuration, it is recommended that the ConnectionManager establishes the Connections on the AutomationComponents before updating the SKS. It is recommended to perform as much configuration as possible in parallel, which may mean that the SKS configuration completes before all of the Subscribers and Publishers are configured (each configuration is processed in a separate thread).

image144.png

Figure E.24 – Updating the SKS to configure a pull model

Figure E.24 illustrates the configuration of the SKS for the pull model.

The ConnectionManager applies the desired configuration on the SKS:

SecurityKeyServer and SecurityGroupIds (for a Publisher in the WriterGroup and for a Subscriber in the ReaderGroup/DataSetReader) are configured by the ConnectionManager on the AutomationComponent as part of the EstablishConnections Call. After the AutomationComponent configuration is finished, the Publisher/Subscriber periodically accesses the SKS and pulls keys. The Publisher/Subscriber would have to have Client capabilities. The SKS will return keys only if it trusts the Client making the connection and the SecurityGroupId is known. The pull can be triggered on the Subscriber by the reception of a NetworkMessage using a new key from the Publisher. The Subscriber keeps a certain number of future keys, and when a new one is used by the Publisher, it is already cached and available.

For a pull model configuration, it is recommended that the ConnectionManager establishes the Connections on the AutomationComponents after updating the SKS. If the SKS rejects GetSecurityKeys (e.g., SecurityGroups have not yet been added to the SKS), the next GetSecurityKeys is repeated by the AutomationComponent using vendor-specific retry logic.

It is important to understand that end-to-end communication will not occur until all parties (Publisher, Subscriber, and SKS) have been configured by the ConnectionManager and current keys have been distributed to Publishers and Subscribers. For the push model, the SKS continues to retry pushing keys using SetSecurityKeys at the RetryInterval if an AutomationComponent is not yet configured. For the pull model, the AutomationComponent continues to retry pulling keys using GetSecurityKeys using vendor-specific retry logic if the SKS is not yet configured. Retry intervals can affect how fast communication starts for a Connection. Typically, a retry interval should be short enough to not delay communication but not so short that they overload network traffic or the Server. See OPC 10000-14 for additional details on SecurityKeyServices.