作者：京东安全 Dawn Security Lab
原文链接：https://dawnslab.jd.com/rossec02/#more

ROS 安全方案

ROS 1.0 安全方案

在上一期文章中，我们介绍了 ROS 安全研究的多个阶段。在第二阶段，ROS 1.0 的安全风险充分暴露，业界涌现了众多安全方案，主要解决身份认证、加密通信、访问控制等风险。在各方案中，SROS 安全特性相对全面，同时具备较好的易用性（部署工具/脚本），是 ROS 社区推荐方案。（需要说明的是，因ROS 本身演进规划，ROS 1.0 无官方安全方案。ROS 社区未来更多聚焦在 ROS 2.0）

方案

rosauth

【目的】解决远程客户端访问 ROS 身份认证问题
【实现】ROS 系统运行在隔离网络域内；远程客户端在通过 SSL 在外部 Authenticator 进行身份鉴权并获取 token；远程客户端使用 token，通过 SSL访问 ROS；ROS 校验 token，允许或拒绝访问。
【不足】未解决身份认证后的 Authorization 问题

ROSRV

【目的】实现 ROS 通信实时监控管理
【实现】ROS Runtime Verification 使用 Man-in-the-Middle 技术，通过增加 RVMaster 节点，实时监控 ROS 1.0 内部消息，同时可配置访问控制策略进行访问控制。
【不足】访问控制基于 IP，RVMaster 中心化设计在节点数过多时的 scalability 问题

Secure ROS Transport

【目的】解决 ROS 通信安全与访问控制
【方案 1】应用层方案，使用外部 Authentication Server 实现 publisher-subscriber 之间的身份认证与加密通信。优点是无需改动 ROS，缺点是应用层实现，无法阻止类似 DoS 攻击。
【方案 2】通信层方案，使用证书+TLS 解决节 点间身份认证、加密通信、访问控制问题。缺 点是没有解决 master 节点安全问题。

Secure ROS

【目的】解决 ROS 通信安全与访问控制
【方案】基于 IPSec 实现身份认证与加密通信，使用系统配置文件实现集中式访问控制。优点是安装方便，不足是访问控制等基于IP 粒度。

SROS

【目的】解决 ROS 通信安全与访问控制
【方案】基于 TLS+证书机制解决身份认证、加密通信、访问控制问题。使用经过证书签名的配置文件进行集中式访问控制，细粒度。不足是需要源码安装及相关配置。

ROS 2.0 安全方案

ROS 2.0 阶段，因组件 DDS 自带安全特性原因，安全方案有了统一框架，并形成 SROS 2。命名 SROS 2是为继承和区分 SROS 方案，但不同于 SROS，SROS2 是 ROS2 官方标准并集成在主线中。

SROS2 具体来说，指在 ROS 2 基础上为使能 DDS-Security 所做的特性适配和工具集，故

SROS 2 = ROS 2 + DDS-Security Enable

ROS 2 适配修改主要有两个，一个是 RCL（ROS Client Library）层修改，一个是 SROS 2 utilities 工具 集。RCL 修改主要是安全特性开关和策略配置，具体如ROS_SECURITY_ENABLE (true/false)、ROS_SECURITY_STRATEGY (Enforce/Permissive)、 ROS_SECURITY_KEYSTORE (key files directory) 等参数实现和支持。SROS 2 utilities 工具主要解决 PKI 秘钥证书和控制策略文件的管理，具体如 CA 和KEYSTORE 根目录管理、节点公私钥和证书创建部署、访问控制策略文件（Governance/Permission）创建部署等。

如上图所示，SROS 2 通过 PKI 机制，解决节点间通信安全，包括身份认证、加密通信；通过策略配置文件（Governance、Permission，证书签名），实现集中式访问控制。

关于访问控制，首先，Governance 文件限制 domain 域的整体访问控制策略，如节点访问控制（是否允许未授权节点访问，是否允许被发现），以及 domain 内部 topic 访问控制（是否允许被发现、是否允许未授权读写）等。其次，每个节点的 Permission 限制自己的访问权限，如是否允许对某 topic 读写。

因 DDS 是标准规范且有开源、商业不同实现，ROS 2 增加了 DDS 抽象适配层 RMW，如上图所示。

机器人安全趋势

ROS 是目前最主流的机器人操作系统框架，ROS 安全经过多年研究和发展，在风险分析和安全方案维度已有不小进步，ROS 2 中已有了基于 DDS 的统一安全框架。但是对于 ROS 甚至整个机器人系统来说，在安全标准与规范、DDS 标准与实现差异、DDS 安全与性能、全系统方案等维度，还有很多工作可以改进。

安全标准

自动驾驶领域已经有相对完整、成熟的安全标准，包括功能安全（Functional Safety）标准 ISO26262、网络安全（Cyber Security）标准 ISO 21434。但在机器人领域，现有工业机器人标准 ISO10218、ISO 20218、ISO/TS 15066、服务机器人标准 ISO 13482、ISO 23482 等主要面向功能安全，尚无权威的网络安全标准。但是，随着服务机器人应用推广、机器人网络安全研究、及产业联盟的推动，机器人网络安全标准是必然趋势。

安全方案

在安全方案维度，针对现有方案的问题或盲点，后续可见的研究趋势有：

一是 DDS 本身的成熟度演进。一方面，当前开源或商业 DDS 实现与 DDS 标准规范还存在差异，例如DDS-Security 标准规定了 5 大安全特性（Authentication、Access Control、Cryptographic、Logging、DataTagging），而多数方案仅实现前 3 种强制特性；另一方面，开源 DDS 实现目前还存在性能、稳定性问题，质量成熟度不高。

二是基于 DDS-Security 安全方案的性能调优。一方面，在安全研究第三阶段，已有很多论文对 DDS-Security 方案的性能进行过深入分析，如加密算法对通信性能影响、DDS-Security 使能及 Governance 配置对整体性能影响等，但仍缺乏相对全面、精细的性能调优实践、指导。而 ROS 系统中不同节点、不同消息的安全需求并不完全一致，面向性能优化的安全策略对方案实施有积极意义。另一方面，社区中 DDS-Security 使能对应的 demo 样例相对简单、对应安全文档匮乏，用户学习和配置困难，不利于方案推广。

三是安全研究从 ROS 框架扩展到机器人全系统。在 SROS/SROS2 聚焦解决 ROS 本身安全问题后，作为 ROS 执行环境、存储载体的 Host OS 的安全和风险受到更多关注。例如 SROS 2 中秘钥证书默认明文存储在 Host OS 指定目录下，无额外安全措施。业界 libddssec 方案通过 TEE 技术（ARM Trustzone）解决秘钥证书安全存储问题，为机器人系统提供了可信计算和可信根能力，提升系统整体安全性。除软硬件安全能力应用外，一些研究倾向借用传统安全方案如 IDS（Intrusion Detection System）部署缓解 Host 风险，一些研究倾向于在机器人全系统中实施零信任方案，如 Zero Trust in Robotics。

本文由 Seebug Paper 发布，如需转载请注明来源。本文地址：https://paper.seebug.org/1800/