2、安全信道建立：Hello 与 OpenSecureChannel 消息详解
好，咱们接着聊。上一章我们把 OPC UA 的安全体系轮廓画了一遍，这一章要钻进最关键的握手环节——安全信道建立。
说白了，客户端和服务器要开始说悄悄话，总得先对个暗号、拉个手吧？这个“拉手”的过程，就是通过 Hello 和 OpenSecureChannel 这两条消息完成的。我当年第一次抓包分析 OPC UA 握手时，看着这两条消息的二进制流，说实话有点懵。后来理清了，其实就那么几件事。
2.1 握手全景：从 Hello 到 SecureChannel
先看整体流程。客户端和服务器建立 TCP 连接后，应用层的握手就开始了。整个过程可以拆成两步：
- Hello 消息：客户端告诉服务器“我来了，这是我的能力清单”。
- OpenSecureChannel 消息：双方协商加密参数，生成会话密钥，建立安全信道。
注意，OpenSecureChannel 本身是有安全模式的。如果选择 None，那就是裸奔；如果选择 Sign 或 SignAndEncrypt，那这条消息本身就已经被保护了。嗯，这里有个鸡生蛋蛋生鸡的问题——还没建立信道，怎么加密？
答案是：OpenSecureChannel 请求使用预先协商好的安全策略（SecurityPolicy）进行签名/加密，而密钥材料则通过非对称加密（RSA）来交换。说白了，第一次握手用的是证书公钥来保护，后续通信才用对称密钥。
核心要点：Hello 消息是明文，OpenSecureChannel 请求/响应是半保护状态（用非对称加密），后续的 OPC UA 报文才用对称加密。这个分层设计，我称之为“渐进式安全握手”。
下面这张图把整个流程串起来了，我建议你多看两眼：
2.2 Hello 消息：能力宣告
Hello 消息是客户端发出的第一条应用层消息。它的作用很简单：告诉服务器“我支持什么版本、我的缓冲区多大、我最大能收多少报文”。
我记得第一次看 OPC UA 二进制协议时，发现 Hello 消息里居然有 13 个字段，当时觉得好复杂。后来做项目多了才明白，这些字段其实就三类：
- 协议版本：客户端和服务器必须版本一致，否则直接断开。
- 缓冲区大小：双方协商一个都能接受的缓冲区尺寸。
- 端点信息：客户端期望连接的服务器端点 URL。
来看一个典型的 Hello 消息结构：
MessageType: HEL (0x48454C)
ChunkType: F (Final)
MessageSize: 56
SecureChannelId: 0 (首次为0)
HelloMessage:
ProtocolVersion: 0
ReceiveBufferSize: 65536
SendBufferSize: 65536
MaxMessageSize: 0 (无限制)
MaxChunkCount: 0 (无限制)
EndpointUrl: "opc.tcp://192.168.1.100:4840"
避坑指南：我曾经遇到过一个案例，客户端设置的 ReceiveBufferSize 是 8192，但服务器默认是 65536。结果服务器回复的 Acknowledge 消息里直接用了 8192，导致后续大报文被截断。所以，客户端一定要根据服务器回复的缓冲区大小来调整自己的发送策略，别想当然。
服务器收到 Hello 后，会回复一个 Acknowledge 消息。这个回复里，服务器会告诉客户端它实际能支持的参数。如果客户端要求的参数服务器无法满足，服务器会直接拒绝连接。
2.3 OpenSecureChannel 消息：密钥协商
Hello 握手完成后，真正的重头戏来了——OpenSecureChannel。这条消息负责建立安全信道，说白了就是双方商量好用什么算法、用什么密钥来保护后续通信。
OpenSecureChannel 分为请求和响应两个阶段。请求由客户端发起，响应由服务器返回。
2.3.1 请求消息结构
OpenSecureChannel 请求消息包含以下关键字段：
| 字段 | 说明 | 我的经验 |
|---|---|---|
| ClientProtocolVersion | 客户端协议版本 | 通常为 0，兼容所有版本 |
| RequestType | Issue (0) 或 Renew (1) | 首次用 Issue，续约用 Renew |
| SecurityMode | None / Sign / SignAndEncrypt | 生产环境必须用 SignAndEncrypt |
| ClientNonce | 32 字节随机数 | 用于生成对称密钥，必须真随机 |
| ClientCertificate | 客户端证书（DER 格式） | 如果 SecurityMode 不是 None，必须提供 |
| RequestedLifetime | 信道生命周期（毫秒） | 我一般设 3600000（1小时） |
这里有个细节：ClientNonce 是生成对称密钥的关键材料。客户端生成一个随机数，服务器也会生成一个随机数（ServerNonce），然后双方用这两个随机数通过密钥派生函数（KDF）生成对称密钥。
警告：ClientNonce 必须使用密码学安全的随机数生成器（CSPRNG）生成。我曾经见过一个项目，开发人员用 rand() 函数生成 Nonce，结果每次连接都生成相同的随机数序列。这等于把密钥拱手送人。记住：随机数不随机，安全就是空谈。
2.3.2 响应消息结构
服务器收到请求后，会验证客户端证书（如果 SecurityMode 不是 None），然后生成自己的 ServerNonce，计算对称密钥，最后返回响应：
| 字段 | 说明 |
|---|---|
| ServerProtocolVersion | 服务器协议版本 |
| SecurityMode | 与请求一致，或降级（如果服务器不支持） |
| ServerNonce | 32 字节随机数 |
| ChannelId | 分配的安全信道 ID |
| RevisedLifetime | 服务器实际接受的生命周期 |
响应消息同样使用非对称加密保护。服务器用客户端的公钥加密 ServerNonce，客户端用自己的私钥解密。这样，只有真正的客户端才能拿到 ServerNonce，进而计算出对称密钥。
2.4 密钥派生：从 Nonce 到 SessionKey
双方都拿到对方的 Nonce 后，如何生成对称密钥？OPC UA 用的是 PSHA1（Pseudo-Random Function based on SHA-1）算法。具体流程如下：
- 将 ClientNonce 和 ServerNonce 拼接在一起。
- 使用 PSHA1 算法，以拼接后的 Nonce 作为种子，生成指定长度的密钥材料。
- 从密钥材料中截取：
- SigningKey（签名密钥，用于 HMAC）
- EncryptingKey（加密密钥，用于 AES）
- InitializationVector（初始化向量，用于 CBC 模式）
嗯，这里要注意：签名密钥和加密密钥是分开的。签名用 HMAC-SHA256，加密用 AES-256-CBC。两者用不同的密钥，即使加密密钥泄露，攻击者也无法伪造签名。
关键点：密钥派生过程完全在本地完成，不通过网络传输。网络只传输 Nonce（随机数），而 Nonce 本身不包含密钥信息。这就是“密钥协商”的精髓——双方各自计算，从不直接传输密钥。
2.5 安全信道生命周期管理
安全信道不是永久的。它有一个生命周期（Lifetime），到期后必须续约（Renew）。续约过程与首次建立类似，但不需要重新验证证书。
我建议你注意以下几点：
- 续约时机：在生命周期还剩 25% 时发起续约，避免信道突然断开。
- 续约频率：不要过于频繁，否则增加服务器负担。我一般设 1 小时续约一次。
- 异常处理：如果续约失败，客户端应该重新建立完整的安全信道（包括证书验证）。
避坑指南：我曾经遇到一个场景，客户端在续约时使用了错误的 ChannelId，导致服务器返回 Bad_SecureChannelIdInvalid。排查了半天才发现，原来是客户端在重连时没有清除旧的 ChannelId。所以，续约前一定要确认当前信道的状态，别拿过期 ID 去碰运气。
2.6 小结
这一章我们拆解了安全信道建立的两个核心步骤：Hello 消息负责能力协商，OpenSecureChannel 消息负责密钥协商。说白了，Hello 是“打招呼”，OpenSecureChannel 是“对暗号”。
Hello 消息虽然简单，但缓冲区大小这个参数经常坑人，我建议你在实现时多做边界测试。OpenSecureChannel 的 Nonce 生成一定要用真随机数，别偷懒用伪随机。密钥派生过程虽然复杂，但 OPC UA 规范已经定义好了，照着实现就行。