 |
High Performance OPC UA Server SDK
1.7.1.383
|
|
High Performance OPC UA Server SDK
1.7.1.383
|
This section describes how to configure the UA server securely.
One of the key features of OPC UA is security. It is also possible to disable security completely, for small embedded devices, but for every device wich has the computing power to use security it should be enabled.
The security consists of the following features:
To make effective use of OPC UA Security, all insecure options should be disabled by default. The vendor is responsible to provide sane defaults. To user should take care, that there are no alternative insecure ways (e.g. field buses) to access the data, which would annul OPC UA Security.
Endpoint/Security policy: Each endpoint makes use of one application certificate. This certificate is identified by the certificate group it belongs to and it's certificate type. A certificate group may contain several certificates, but only one certificate of one type.
Mapping of certificate types:
If the application supports the Basic256Sha256 the certificate shall be of type UA_RSA_256_TYPE.
If the application supports the Basic128Rsa15 or Basic256 profile the certificate shall be of type UA_RSA_MIN_TYPE.
The RSA key length for a UA_RSA_MIN_TYPE certificate must be 1024 or 2048 bits.
The RSA key length for a UA_RSA_MIN_TYPE certificate must be 2048, 3072 or 4906 bits.
The certificate group node in the address space specifies which certificate types are allowed for the certificates of this group.
This dependencies are defined in the settings file.
Set the certificate group and the certificate type in the settings of the security policy:
[endpoint] security_policies/0/policy_id = http://opcfoundation.org/UA/SecurityPolicy#Basic256Sha256 security_policies/0/cagroupid = DefaultApplicationGroup security_policies/0/certificate_type_id = UA_RSA_256_TYPE
Define the certificate group
cagroupid: The name of the certificate group, referenced by the security policy.
certificate_group_id: The node id of the certificate group in the address space.
store_index: The index of the associated pki store. Here is the trust list and the application certificate stored.
certificates: Index of the certificates in the certificates section of the certificates belonging to this certificate group.
[cagroup] cagroups/size = 1 cagroups/0/cagroupid = DefaultApplicationGroup cagroups/0/certificate_group_id = "ns=0;i=14156" cagroups/0/store_index = 0 cagroups/0/certificates = 0, 1
Define the certificates
certificate_type_id: The type of the certificate.
Currently supported are UA_RSA_256_TYPE and UA_RSA_MIN_TYPE.
[certificates] certificates/size = 2 certificates/0/certificate = store://server4k certificates/0/key = store://server4k certificates/0/store = 0 certificates/0/certificate_type_id = UA_RSA_256_TYPE certificates/1/certificate = store://server2k certificates/1/key = store://server2k certificates/1/store = 0 certificates/1/certificate_type_id = UA_RSA_MIN_TYPE
"server4k" and "server2k" are the names of the certificates.
At the time of writing the following SecurityPolicies are supported by the SDK:
| Policy | Status | Remarks |
|---|---|---|
| http://opcfoundation.org/UA/SecurityPolicy#None | Active | No security. Should not be used. |
| http://opcfoundation.org/UA/SecurityPolicy#Basic128Rsa15 | Deprecated | Should not be used anymore. |
| http://opcfoundation.org/UA/SecurityPolicy#Basic256 | Deprecated | Should not be used anymore. |
| http://opcfoundation.org/UA/SecurityPolicy#Basic256Sha256 | Active | This is secure. |
| http://opcfoundation.org/UA/SecurityPolicy#Aes256_Sha256_RsaPss | Active | This is secure. |
AnonymousUserIdentyToken should be disabled. See User Authentication Configuration for more information.
The UA application should run under a non-privileged user, which has no permissions to the system, only to its own files, which are required by the UA application. This user does not require any login shell, so you can disable logins for this user.
Linux example:
sudo groupadd opcua sudo useradd --system -g opcua -d /var/lib/opcua -s /sbin/nologin opcua
All files should be owned but the dedicated opcua user and group. All others should not have any access. The next example assumes that the configuration files are stored in /etc/opcua.
Linux example:
chown -R opcua:opcua /etc/opcua/ chmod -R o-rwx /etc/opcua
The PKI stores should have correct file permissions as well. All files and folders should only be writable by the OPC UA user. It is important that nobody else is able to tamper with the trust lists and revocation lists.
The private key should only be readable by the OPC UA user.
Linux example:
chown -R opcua:opcua pki_store_0 chmod -R o-rwx pki_store_0 chmod 600 pki_store_0/own/private/server.key
Interactive application can additionally password protect the private key, but this is not possible for unattended applications, because it requires to enter the password when the server gets started and loads the private key. Storing the password in another file, even if it's obfuscated, does not really improve security.
Se we need to rely on file system security and the potential attacker gets not physical access to the machine.
There exists special hardware like Secure Elements or TPMs. This hardware allows protecting your private keys. A private key can be stored on the security chip, or can even be generated in such a device, but can never be read out again. It can be used by the application to decrypt data or to sign data with the private key.
It is possible to integrate such devices using OpenSSL engines. Two possibilities are the PKCS11 engine or the TPM engine.
Features and limitations:
This prevents from stealing of private keys and cloning identity. It can not protect from malware, which using the security chip in the same way as the UA application itself. The access to the security chip can be password or PIN protected, but this creates the same problem as with file based private keys. You would need to store the PIN somewhere so that the UA Application can used it. In this case the malware can do the same.
Mitigation: You need to prevent that malware gets executed on the same machine using additional measures like e.g. SecureBoot.
Smartcards exist for quite a long time. Traditionally a smartcard was a real card which required an additional smartcard reader to access to security chip on the smartcard. Today there exist modern variants of security hardware like e.g. the Yubikey, which integrates smartcard functionality next to many other features. This is a simple USB device that can be plugged into any USB port and emulates a smartcard reader as well as the smartcard itself. This makes it easier to use and cheaper. In the same way as a TPM can protect an application's private key, this smart card can protect a user's private key. When the user wants to login into a server he can plug in his smartcard and the UA Client can create the user token signature using the smartcard. This typically will require the user to enter a PIN to allow this access. In this scenario entering a PIN is no problem, because a real user going to login.