📚 课程目录第2章安全策略（SecurityPolicy）基础

安全策略（SecurityPolicy）基础：三大内置策略的加密与签名差异

聊 OPC UA 安全，绕不开 SecurityPolicy。说白了，它就是一套「加密 + 签名」的组合套餐。你选哪个套餐，直接决定了通信的保密强度和性能开销。

我记得刚接触 OPC UA 那会儿，看到 Basic128Rsa15、Basic256、Basic256Sha256 这三个名字，第一反应是：这不就是密钥长度不一样吗？后来踩了坑才明白——事情没那么简单。

三大策略的核心差异

我们先看一张总览表，把它们的加密算法、签名算法、密钥长度一次性说清楚。

策略名称	对称加密算法	对称密钥长度	签名算法	签名哈希算法	非对称密钥长度
Basic128Rsa15	AES-128-CBC	128 bit	RSA-PSS-SHA1	SHA-1	1024/2048 bit
Basic256	AES-256-CBC	256 bit	RSA-PSS-SHA1	SHA-1	1024/2048 bit
Basic256Sha256	AES-256-CBC	256 bit	RSA-PSS-SHA256	SHA-256	2048/4096 bit

看到没？Basic128Rsa15 和 Basic256 的签名算法都是 SHA-1，只有 Basic256Sha256 升级到了 SHA-256。这是关键区别。

逐策略拆解

1. Basic128Rsa15——老当益壮的入门级

这个策略是 OPC UA 规范最早定义的。加密用 AES-128，签名用 RSA-PSS 配合 SHA-1。我个人习惯把它叫做「兼容性之王」。

为什么？因为几乎所有 OPC UA 栈都支持它。你在老旧 PLC 或嵌入式设备上，大概率只能选它。我在一个汽车焊装车间项目里遇到过，现场有一批 2015 年的控制器，固件锁死只支持 Basic128Rsa15。没办法，整个产线都得迁就它。

⚠️ 注意： SHA-1 在密码学上已被认为不够安全。2020 年之后，很多安全审计会直接标记 SHA-1 为高风险。如果客户有等保或 GDPR 合规要求，尽量别用这个策略。

2. Basic256——加密升级，签名没变

这个策略有点「偏科」。对称加密从 128 升级到 256，但签名算法还是 SHA-1。你想想看，加密强度上去了，可签名这扇门还是老锁。攻击者如果伪造签名，加密再强也没用。

我在一个能源管理系统里见过这种配置。甲方要求「必须用 256 位加密」，但实施方没注意签名算法，直接配了 Basic256。后来第三方安全测试报告出来，SHA-1 签名被列为中危漏洞，又花了两周整改。

💡 我的建议： 除非有明确的兼容性限制，否则不要选 Basic256。它处于一个「比上不足、比下有余」的尴尬位置。要么选 Basic128Rsa15 保兼容，要么直接上 Basic256Sha256 保安全。

3. Basic256Sha256——当前推荐的安全基线

这是目前 OPC UA 安全策略里的「优等生」。加密 AES-256，签名 SHA-256，非对称密钥最低 2048 bit。三个环节都踩在了当前业界公认的安全线上。

我参与过的几个欧盟项目，客户直接写死：只允许 Basic256Sha256。其他策略一概拒绝连接。一开始觉得有点苛刻，后来想想，人家是对的——与其留一堆策略让配置人员选错，不如一刀切。

  🔑 核心结论： 新项目默认选 Basic256Sha256。如果遇到老设备不兼容，再降级到 Basic128Rsa15，但要做好风险评估记录。

签名算法：SHA-1 vs SHA-256 到底差在哪？

我经常被问到：「SHA-1 和 SHA-256 不就是摘要长度不同吗？一个 160 位，一个 256 位，能有多大区别？」

区别大了。SHA-1 的抗碰撞性已经被实际攻破。2017 年 Google 和 CWI 研究所就演示了 SHA-1 碰撞攻击（SHAttered 攻击）。说白了，攻击者可以构造两个不同的数据，让它们产生相同的 SHA-1 摘要。签名就失去了「唯一性」保证。

而 SHA-256 目前还没有已知的可行碰撞攻击。在量子计算机成熟之前，它足够安全。

加密算法：AES-CBC 模式要注意什么？

三个策略都用了 AES-CBC 模式。CBC 模式有个特点：它需要初始化向量（IV）。每次加密的 IV 必须随机生成，不能重复。

我在一个水处理 SCADA 项目里遇到过一个问题：某品牌的 OPC UA 服务器在重连时，IV 生成逻辑有 bug，导致两次会话用了相同的 IV。结果被安全扫描工具检测出「IV 重用」漏洞。虽然没造成实际数据泄露，但整改报告写了好几页。

⚠️ 避坑指南： 我曾经在测试中发现，某些轻量级 OPC UA 栈对 IV 的随机性实现不严谨。如果你用的是非主流 SDK，建议做一次 IV 随机性测试——连续建立 1000 次会话，检查 IV 是否有重复。

非对称密钥长度：1024 vs 2048 vs 4096

Basic128Rsa15 和 Basic256 允许 1024 bit 的 RSA 密钥，Basic256Sha256 要求最低 2048 bit。1024 bit 的 RSA 在 2023 年之后已经被 NIST 明确弃用。很多安全合规框架（如 IEC 62443）也要求不低于 2048 bit。

但 4096 bit 就一定更好吗？不一定。密钥越长，握手时的非对称加解密耗时越长。我在一个高频交易场景里测过：2048 bit 握手大约 5-8ms，4096 bit 直接飙到 20-30ms。对于毫秒级响应的系统，这个开销不可忽视。

💡 经验之谈： 工业现场一般选 2048 bit 就够了。除非客户有明确的合规要求（比如某些政府项目要求 4096），否则没必要为了「看起来更安全」牺牲性能。

策略选择决策流程

下面这张图是我自己总结的选型逻辑，你可以直接拿去用。

实际配置示例

下面是一个 OPC UA 服务器端配置 SecurityPolicy 的代码片段（以 C# 为例）。

// 创建服务器实例
ApplicationInstance server = new ApplicationInstance();

// 配置安全策略列表
server.SecurityPolicies = new List<SecurityPolicy>()
{
    SecurityPolicy.Basic256Sha256,   // 首选
    SecurityPolicy.Basic128Rsa15     // 降级兼容
};

// 注意：不要同时启用 Basic256
// 它既不安全也不高效

客户端连接时，会从服务器发布的策略列表里选一个双方都支持的。如果客户端只支持 Basic256Sha256，服务器只支持 Basic128Rsa15，那连接就会失败。这就是策略协商失败——我在现场调试时见过太多次了。

💡 调试技巧： 连接失败时，先抓包看 Server Endpoint 的 SecurityPolicyUri。用 Wireshark 过滤 opcua 协议，找到 Server 发布的策略列表，一眼就能看出问题。

小结

三个策略，本质上是安全强度与兼容性的权衡。Basic128Rsa15 保兼容，Basic256Sha256 保安全，Basic256 尽量别碰。选型时先看设备年代，再看合规要求，最后看性能约束。按这个顺序走，基本不会出错。

嗯，这一章就到这里。记住一句话：安全策略不是越强越好，而是「够用且兼容」才是最好。