Secure Channel

Ensures that data in transit cannot be read by unauthorized parties through symmetric encryption. Once the Secure Channel is established, all message payloads are encrypted using algorithms defined by the negotiated Security Policy.

• Uses symmetric ciphers like AES-256 for bulk data encryption
• Encryption keys are unique to each Secure Channel and derived during the handshake
• Protects sensitive process data, recipes, and intellectual property from network sniffing
• Applies to both request and response messages in the Client-Server communication

Guarantees that messages have not been altered or corrupted during transmission using cryptographic signing. Each message carries a digital signature computed over the entire payload.

• Employs HMAC-SHA256 or similar algorithms to generate message authentication codes
• Detects any tampering, replay, or accidental corruption of data in transit
• The receiver verifies the signature before processing any message content
• Prevents man-in-the-middle attacks that attempt to inject malicious commands into the industrial control stream

Verifies the identity of both communicating applications using X.509 Certificates before any data is exchanged. This mutual trust establishment prevents rogue applications from connecting to industrial systems.

• Each OPC UA application instance has a unique Application Instance Certificate
• Certificates are exchanged and validated during the OpenSecureChannel service request
• Supports certificate chains and trust lists managed by administrators
• Enables mutual authentication where both Client and Server prove their identity
• Revocation checking ensures compromised certificates are rejected

The Secure Channel operates as a transport-layer construct that is logically separate from the application-level Session. Multiple Sessions can be multiplexed over a single Secure Channel, or a Session can survive the teardown and re-establishment of its underlying channel.

• A Secure Channel is identified by a unique SecurityToken with a finite lifetime
• Token renewal happens transparently without interrupting active Sessions
• If a Secure Channel fails, the Session can be recovered on a new channel within its timeout period
• This separation allows for network resilience without losing application state or subscriptions

Prevents attackers from capturing valid encrypted messages and retransmitting them later to cause unintended operations. The Secure Channel enforces strict sequence numbering on every message.

• Each message carries a monotonically increasing SequenceNumber
• The receiver tracks the last received sequence and rejects any duplicates or out-of-order messages
• Combined with the SecurityToken lifetime, this bounds the window of vulnerability
• Critical for preventing replay of commands like emergency stops or parameter changes

The Client and Server agree on a specific Security Policy during channel establishment by matching their configured capabilities. This defines the exact cryptographic algorithms and key lengths used for the channel's lifetime.

• Policies include profiles like Basic256Sha256 and Aes256-Sha256-RsaPss
• The Server exposes supported policies through its Endpoints
• The Client selects the strongest mutually supported policy during the handshake
• No fallback to weaker policies is permitted, preventing downgrade attacks
• Key derivation functions generate unique symmetric keys from the shared secret

A Security Policy is a named, immutable set of cryptographic algorithms and key lengths that defines exactly how a Secure Channel will be protected. It specifies the algorithms for symmetric encryption (e.g., AES-256), message signing (e.g., SHA-256), and key derivation (e.g., P-SHA-256). During the OpenSecureChannel handshake, the Client proposes a policy, and the Server either accepts or rejects it. Common policies include:

• Basic256Sha256: Widely used, provides 256-bit encryption and SHA-256 signing.
• Aes256-Sha256-RsaPss: A more modern profile using RSA-PSS for asymmetric operations.
• None: No security applied; used only in isolated, trusted networks and strictly discouraged for production.

An X.509 Certificate is the digital identity card used by OPC UA Applications to prove their identity before a Secure Channel is established. Each Application Instance has a unique certificate containing its public key, a distinguished name (subject), and a digital signature from a trusted Certificate Authority (CA). During the handshake, certificates are exchanged and validated. The Application URI embedded in the certificate must match the one declared in the session, preventing impersonation. OPC UA uses Certificate Trust Lists stored locally on each host to decide whether to accept a remote application's certificate.

A Session is a long-lived logical connection that rides on top of a Secure Channel. While the Secure Channel handles encryption and integrity at the transport level, the Session manages user authentication, continuity of service calls, and state recovery. If the underlying Secure Channel breaks due to a network interruption, the Session can survive for a configurable timeout period, allowing the Client to re-establish a new Secure Channel and re-attach the existing Session without losing subscriptions or state. This decoupling is critical for resilient industrial communication.

An Endpoint is a network address and security configuration bundle exposed by an OPC UA Server. It describes a specific way for a Client to connect. Each Endpoint URL specifies the transport protocol (e.g., opc.tcp://), the host address, and the port. Critically, the Endpoint also advertises the Security Policy and Message Security Mode (Sign, SignAndEncrypt, or None) that the Server requires for that connection path. A Client discovers Endpoints by calling the GetEndpoints service, then selects one that matches its own security capabilities to initiate the Secure Channel.

UA Binary Encoding is the compact, high-performance serialization format used to encode OPC UA messages before they are encrypted and sent over a Secure Channel. It converts structured data types—like NodeIds, Variants, and ExtensionObjects—into a binary stream optimized for minimal overhead. This encoding is mandatory for the opc.tcp transport and is designed for industrial environments where bandwidth efficiency and low CPU utilization are paramount. The binary stream is then passed to the cryptographic layer for signing and encryption according to the negotiated Security Policy.

Reverse Connect is an OPC UA connectivity mechanism that inverts the traditional Client-Server connection flow to simplify secure network traversal. In a standard setup, the Client initiates the TCP connection to the Server. With Reverse Connect, the Server—often located behind a firewall or NAT—initiates an outbound connection to a known Client endpoint. Once the TCP socket is established, the Client then initiates the Secure Channel handshake over this pre-existing connection. This eliminates the need to open inbound firewall ports on the Server side, significantly reducing the attack surface for edge-deployed systems.