Security
OPC UA security protects three things (Part 2, Security Model):
- Application authentication: client and server identify each other with application instance certificates.
- Message security: messages on the secure channel are signed, or signed and encrypted.
- User authentication and authorization: the server checks the user when the session is activated, then allows or denies access node by node.
Security policies
Section titled “Security policies”A security policy is the set of algorithms a secure channel uses. Part 7 defines the URI and algorithms of each policy. PDComm supports these policies:
| Security policy | Asymmetric signature | Asymmetric encryption | Symmetric encryption | Symmetric signature |
|---|---|---|---|---|
| None | None | None | None | None |
| Basic256Sha256 | RSA PKCS#1 v1.5, SHA-256 | RSA-OAEP (SHA-1) | AES-256-CBC | HMAC-SHA256 |
| Aes128_Sha256_RsaOaep | RSA PKCS#1 v1.5, SHA-256 | RSA-OAEP (SHA-1) | AES-128-CBC | HMAC-SHA256 |
| Aes256_Sha256_RsaPss | RSA-PSS, SHA-256 | RSA-OAEP (SHA-256) | AES-256-CBC | HMAC-SHA256 |
A policy URI is http://opcfoundation.org/UA/SecurityPolicy# followed by the policy name; Aes256_Sha256_RsaPss, for example, is http://opcfoundation.org/UA/SecurityPolicy#Aes256_Sha256_RsaPss. RSA keys must be 2048 to 4096 bits long. The deprecated Basic128Rsa15 and Basic256 policies aren’t supported.
The PDComm SDK defaults to Aes256_Sha256_RsaPss. These are the C constants and .NET values:
| Security policy | C constant | .NET value |
|---|---|---|
| None | PDCOMM_OPCUA_POLICY_NONE |
SecurityPolicy.None |
| Basic256Sha256 | PDCOMM_OPCUA_BASIC256SHA256 |
SecurityPolicy.Basic256Sha256 |
| Aes128_Sha256_RsaOaep | PDCOMM_OPCUA_AES128SHA256RSAOAEP |
SecurityPolicy.Aes128Sha256RsaOaep |
| Aes256_Sha256_RsaPss | PDCOMM_OPCUA_AES256SHA256RSAPSS |
SecurityPolicy.Aes256Sha256RsaPss |
Security modes
Section titled “Security modes”The security mode (MessageSecurityMode) decides how much of the policy applies:
| Security mode | Value | Meaning |
|---|---|---|
| None | 1 | No signing and no encryption. Used only with security policy None. |
| Sign | 2 | Messages are signed: readable, but tamper-evident. |
| SignAndEncrypt | 3 | Messages are signed and encrypted. The PDComm SDK default. |
A server advertises one endpoint per policy and mode combination. The PDComm simulator gives its endpoints a security level of 0 for None, 20 for Sign and 30 for SignAndEncrypt; clients usually pick the endpoint with the highest level.
If the server doesn’t advertise the requested policy and mode, the PDComm SDK client refuses to connect instead of falling back to another combination. The error text is Requested OPC UA endpoint not advertised. To use policy None, both client and server must set the PDCOMM_OPCUA_ALLOW_NONE flag.
Application instance certificates
Section titled “Application instance certificates”Every installed instance of an OPC UA application has its own X.509 v3 certificate and private key (Part 6, application instance certificate). When a secure channel opens, both sides exchange certificates and validate the peer’s. PDComm checks the following:
| Item | Requirement |
|---|---|
| Key | RSA, 2048 to 4096 bits |
| Signature algorithm | RSA with SHA-256, SHA-384 or SHA-512 |
| Subject | CN and O aren’t empty |
| subjectAltName URI | Exactly one, equal to the application’s ApplicationUri |
| subjectAltName DNS or IP | At least one in a server certificate, matching the host the client puts in the endpoint URL |
| keyUsage | digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment, plus keyCertSign when self-signed |
| extendedKeyUsage | serverAuth for a server, clientAuth for a client |
| Validity | The current time is between notBefore and notAfter |
The ApplicationUri identifies the application. PDComm defaults to urn:pdcomm:opcua:client for clients and urn:pdcomm:opcua:server for servers. If the certificate’s URI differs from the ApplicationUri in the connection options, you get CertificateUriInvalid.
A well-formed certificate is still rejected if it isn’t trusted. Part 4 defines how to decide trust and in which order to validate (the certificate validation section, Table 100). PDComm checks the structure, builds the certificate path, then checks signatures, security policy requirements, the trust list, the validity period, the host name (server certificates only), the URI, the key usage and revocation, in that order.
PDComm trusts nothing automatically; you configure trust explicitly:
| Component | Trust setting |
|---|---|
| SDK client | The one server certificate in trusted_server_der (.NET TrustedServerDer) |
| SDK server | The one client certificate in trusted_client_der (.NET TrustedClientDer) |
| Simulator server | The server.trust list in its configuration (DER or PEM files), plus the simulator’s own client certificate |
| Simulator client | The client.trust list, plus the certificate of the server running in the same simulator |
Large plants manage certificates and trust lists with a certificate authority and a Global Discovery Server (Part 12). The PDComm examples create a self-signed certificate per application and trust the peer’s certificate directly. You’ll practice this in PKI and trust setup.
User identity tokens
Section titled “User identity tokens”The ActivateSession request that activates a session carries a user identity token (Part 4, the UserIdentityToken parameter). For each endpoint, the server advertises the token types it accepts as user token policies.
| Token | Description |
|---|---|
| AnonymousIdentityToken | Doesn’t identify a user. |
| UserNameIdentityToken | Sends a user name and password; the password is encrypted with the server certificate’s public key. |
| X509IdentityToken | Sends a user certificate and a signature. |
| IssuedIdentityToken | Sends a token issued by an external authorization service. |
The PDComm SDK client and the simulator use AnonymousIdentityToken and UserNameIdentityToken; the SDK server accepts AnonymousIdentityToken.
Passwords use one of two encrypted formats. Passwords up to 64 bytes go in the legacy RSA-encrypted token format; longer ones use the EncryptedSecret format. To leave the token’s encryptionAlgorithm empty in the EncryptedSecret format, set the PDCOMM_OPCUA_USER_SECRET_HEADER_POLICY_ONLY flag, but only for servers that expect that form.
A PDComm client never sends a password over a secure channel with policy None, and the simulator server advertises only the anonymous token on its None endpoint.
Authorization and lockout
Section titled “Authorization and lockout”After the user is authenticated, access still depends on the node. PDComm servers divide variables into public variables and variables for authenticated users only. When an anonymous session reads or writes a restricted variable, the item result is BadUserAccessDenied (0x801F0000).
After five consecutive failed user authentications from the same client (its certificate, or its IP address on an unsecured connection), a PDComm server locks that client out for 10 minutes. While locked, even the right password is rejected with BadUserAccessDenied. Restarting the simulator’s server clears the lockout.