2. ROS2安全基础

ROS2 的通信底座是 DDS（Data Distribution Service），因此 ROS2 的安全能力并不是从零构建，而是建立在 DDS Security 规范之上。理解这一点非常关键：SROS2 并不是一套独立于 DDS 的加密协议，而是 ROS2 对 DDS Security 的工程化封装，它把复杂的证书、权限、密钥配置转化为可被 ros2 security 命令和构建系统管理的目录结构与策略文件。要真正掌握 ROS2 安全部署，必须先看清 DDS 安全模型、SROS2 的组成，以及认证与加密在发布/订阅链路中的实际作用位置。

一、DDS 安全模型：五个插件，各司其职

DDS Security 规范定义了一个可插拔的安全架构，核心由五个插件构成，它们分别覆盖“身份、权限、加密、认证、日志”五个维度：

• Authentication（认证插件）：验证参与者的身份，通常基于 PKI 证书体系，确认“你是谁”。
• Access Control（访问控制插件）：在身份确认后，判断该参与者是否有权加入某个域、发布或订阅某个主题，回答“你能做什么”。
• Cryptographic（密码学插件）：负责密钥交换、数据加解密、消息认证码计算，回答“数据如何被保护”。
• Logging（日志插件）：记录安全相关事件，如认证失败、权限拒绝，用于审计与排障。
• Data Tagging（数据标签插件）：为数据附加安全标签，支持更细粒度的分类保护。

这五个插件共同构成一个“先认证、再授权、后加密”的信任链。任何一环缺失，安全强度都会明显下降。例如只启用加密而不启用访问控制，攻击者仍可能通过合法证书加入域并订阅敏感话题。

二、SROS2：把 DDS Security 变成可操作的工程结构

SROS2 是 ROS2 官方提供的安全工具链与运行时支持，它把 DDS Security 的配置抽象为“安全 enclave（安全区）”。一个 enclave 对应一组密钥、证书和权限策略，通常以目录形式存在。典型结构如下：

ros2_security/
├── enclaves/
│   └── talker/
│       ├── cert.pem
│       ├── key.pem
│       ├── governance.p7s
│       ├── identity_ca.cert.pem
│       ├── permissions.p7s
│       └── permissions_ca.cert.pem
└── policies/
    ├── governance.xml
    └── permissions.xml

其中 governance.xml 定义域级别的安全策略，例如是否强制加密、是否允许未认证参与者；permissions.xml 定义具体节点可以发布/订阅哪些主题、调用哪些服务。SROS2 通过 ros2 security create_keystore、create_enclave、generate_artifacts 等命令生成这些文件，并在启动节点时通过环境变量 ROS_SECURITY_KEYSTORE 和 ROS_SECURITY_ENCLAVE_OVERRIDE 指定使用哪个 enclave。

三、认证与加密的基本原理

ROS2 的安全通信建立在非对称加密与对称加密的混合体系上。认证阶段使用非对称加密：每个参与者持有由 CA 签发的证书和私钥，通过挑战-应答机制证明自己持有私钥，从而确认身份。身份确认后，参与者之间通过密钥交换协商出对称会话密钥，后续的数据传输使用对称加密，因为对称加密在吞吐和延迟上更适合高频的传感器数据流。

具体到发布/订阅链路，安全保护体现在三个层面：

1. 身份认证：参与者加入域时，必须出示有效证书，否则无法完成发现（discovery）。
2. 访问控制：即使认证通过，若权限策略未授权其发布 /cmd_vel，该发布行为会被拒绝。
3. 数据保护：授权通过后，消息内容可被加密，并附带消息认证码，防止窃听与篡改。

下面这张图展示了 ROS2 安全通信中从发现到数据保护的关键路径，以及各插件在其中的作用位置：

四、常见安全威胁与防护目标

在机器人系统中，安全威胁并非抽象概念，而是会直接导致物理世界后果。常见威胁与对应防护目标如下表所示：

威胁类型	典型场景	防护目标	对应机制
窃听	攻击者抓取 /camera/image 或 /cmd_vel 数据	机密性	对称加密 + 安全发现
篡改	伪造速度指令或传感器读数	完整性	消息认证码（MAC）
冒充	未授权节点伪装成控制节点	真实性	PKI 证书认证
重放	重复发送历史合法指令	新鲜性	序列号 + 时间戳
越权访问	低权限节点订阅高敏感话题	授权	访问控制策略
拒绝服务	大量虚假参与者耗尽资源	可用性	认证前置 + 日志审计

五、案例与复盘：一个典型的安全部署检查清单

假设我们要部署一个“安全遥操作”场景：操作端发布 /cmd_vel，机器人端订阅并执行。安全部署可按以下清单逐项确认：

1. 为操作端和机器人端分别创建独立 enclave，不共用密钥。
2. 在 permissions.xml 中仅允许操作端发布 /cmd_vel，机器人端仅允许订阅 /cmd_vel，禁止其他主题。
3. 在 governance.xml 中强制启用加密与认证，禁止未认证参与者加入域。
4. 启动节点时设置 ROS_SECURITY_KEYSTORE 指向密钥库，并确认 ROS_SECURITY_ENCLAVE_OVERRIDE 指向正确 enclave。
5. 检查私钥文件权限为 600，证书目录不可被其他用户写入。
6. 通过 ros2 topic echo 在未授权节点上验证订阅失败，确认访问控制生效。

export ROS_SECURITY_KEYSTORE=~/ros2_security/keystore
export ROS_SECURITY_ENCLAVE_OVERRIDE=/talker
export ROS_SECURITY_STRATEGY=Enforce
ros2 run demo_nodes_cpp talker

复盘时最常发现的问题是：策略文件生成了但未重新签名，或环境变量指向了错误的 enclave，导致节点实际以“无安全”模式运行。因此，部署后必须通过日志和实际订阅测试验证安全策略是否真正生效，而不是仅凭“命令执行成功”就认为安全已落地。