摘要：机器人操作系统的安全性是机器人系统安全性的重要组成部分。本文以《软件学报》2024年发表的《机器人操作系统ROS安全性研究综述》为核心蓝本，系统解析了ROS的四大安全缺陷、三种安全增强路径以及ROS2的DDS-Security机制。在此基础之上，本文进一步锚定启元机器人（PRIMEBOT）的生态定位，从开发者生态代码安全的角度，探讨了ROS安全技术对启元基于ROS2 + FastDDS的SDK架构、RPK技能开发以及AtomGit开源社区的借鉴价值。

本文关键词：ROS安全性；机器人操作系统；开发者生态；代码安全；启元机器人

引

诸位技术同仁：

本系列将系统精读的方式，深入剖析计算机科学顶级期刊/会议论文，聚焦前沿突破的核心机理与工程实现。

通过严谨的学术剖析，解耦研究范式、技术方案及实证方法，揭示创新本质。我们重点关注理论-工程交汇点的技术跃迁，提炼可迁移的方法论锚点，助力诸位的技术实践与复杂问题攻坚，共推领域持续演进。

文献来源

DOI: 10.13328/j.cnki.jos.006943

软件学报,2024, 35(2):1010–1027.

已标明出处，如有侵权请联系笔者。

一、引言——机器人"不安全"这件事，比你想的严重

1.1 机器人的安全威胁从哪来

过去几年，机器人逐渐走进家庭服务、医疗健康、公共安全等领域。论文在引言中给出了几组数据：国际机器人联合会发布的报告显示，2010-2019年工业机器人的年安装量增加了3倍多；2018-2019年，专业服务机器人的全球销售额增长了32%，达到112亿美元。

但机器人越多，安全问题就越突出。论文明确指出，机器人系统面临的安全威胁种类更多，安全问题所引起的后果也更严重。

为什么？因为机器人主要由计算系统、感知系统和执行系统构成，是机械域与信息域一体化的产物。这意味着机器人不仅面临传统计算平台的安全威胁（信息空间攻击、物理空间攻击），还面临额外的安全隐患——攻击者可以通过向传感器传递虚假环境信息，扰乱和控制机器人行为；一旦掌握了带机械臂或行走装置的机器人的控制权，很可能对人类及周围环境带来直接的物理伤害。

1.2 ROS为什么"天生不安全"

ROS是当前机器人领域事实上的标准操作系统。但论文指出了一个关键事实：ROS最初是为科研服务的，开发者在进行ROS架构设计时并没有充分考虑系统的安全性。

这直接导致ROS中隐藏着很多潜在的安全隐患。论文系统梳理了ROS的四大安全问题：

问题	具体表现	潜在后果
明文通信	节点之间通信不加密	攻击者可拦截和破译消息内容
模块化安全隐患	使用不安全TCP端口，缺乏身份验证	中间人攻击、系统破坏
弱授权方案	不验证发送方，不检查数据完整性	任意用户可向机器人发送指令
不提供QoS	节点各自管理通信，无压缩机制	网络延迟和阻塞问题无法及时解决

这四个问题，本质上是同一个根源：ROS在设计之初，把“好用”排在了“安全”前面。

值得注意的是，启元机器人的SDK并没有直接沿用老旧的ROS1，而是基于 ROS2 Humble + FastDDS 构建。FastDDS去中心化的发现机制，从底层网络架构上避免了ROS1中Master节点单点故障带来的系统性风险，并且原生支持更现代的传输层安全配置，为开发者的二次开发划定了一条更安全的起跑线。

1.3 为什么从开发者生态角度切入

本文选择从开发者生态代码安全的角度来解读这篇综述，有三个原因：

第一，启元官方社区明确表示"我们将技能（Skills）、SDK与工具链开源于AtomGit"。这意味着启元的开发者生态会涉及大量的代码共享和工具链复用，而代码安全是整个生态建设的基石。

第二，ROS安全性综述系统梳理了通信加密、身份认证、访问控制等方案，这些方案对启元AtomGit社区的安全建设有直接的参考价值。

第三，论文中关于ROS2的DDS-Security机制的分析，可以为启元生态的技术选型提供参考。

1.4 本文脉络

本文以《机器人操作系统ROS安全性研究综述》为核心蓝本，系统拆解ROS的四大安全缺陷、三种安全增强路径以及ROS2的DDS-Security机制。在此基础之上，本文从开发者生态代码安全的角度，探讨ROS安全技术对启元AtomGit社区的借鉴价值。

二、基础地基——ROS架构与安全缺陷

2.1 ROS简介

ROS是一个开源机器人操作系统，提供了硬件抽象、设备驱动、函数库、可视化工具、消息传递和软件包管理等功能。

从软件架构角度看，ROS是一种基于匿名发布/订阅机制和消息传递通信的分布式多进程框架。节点间的消息通信分为三种：

• 话题（topic）：单向消息发送/接收
• 服务（service）：双向消息请求/响应
• 动作（action）：双向消息目标/结果/反馈

这种松耦合的通信机制，是ROS灵活性的来源，也是ROS安全缺陷的根源。

2.2 ROS四大安全缺陷深度拆解

论文在第3节系统梳理了ROS的四大安全问题，本节逐一拆解。

（1）明文通信

ROS中节点之间的通信为明文通信。未加密的文本在易于使用、方便调试、不过多消耗系统性能等方面有诸多优势，但攻击者可以利用恶意节点轻易拦截和破译消息内容，监听话题并趁机将虚假消息注入机器人系统。

（2）模块化特性暗藏安全隐患

ROS使用不安全的TCP端口，并且缺乏身份验证机制。攻击者可能会利用这些缺陷对系统进行中间人攻击，甚至破坏机器人系统。

（3）弱授权方案

ROS不进行消息发送方验证，不检查数据的完整性和真实性，也不定义访问级别。如果任何用户都可以向机器人发送任意指令，机器人系统将面临巨大的安全威胁。

（4）不提供服务质量（QoS）

每个节点负责管理自己的通信，类似的消息没有被压缩，也没有任何减少网络通信的努力。这可能导致网络延迟和网络阻塞等网络安全问题得不到及时解决。

三、核心技术深度拆解——ROS安全增强的三条路径

论文将ROS安全性解决方案按OSI模型分层，主要集中在应用层、传输层和网络层。

3.1 应用层安全加固

应用层安全加固的核心思路是不修改ROS框架，将ROS视为黑盒，在ROS之上实现安全措施。

（1）数据加密

Lera等人使用3DES加密算法对ROS进程间的通信数据进行了加密，并增加了两个独立的节点分别负责完成加密和解密任务。实验结果表明，数据加密会显著增加机器人系统的CPU性能开销和通信负载。

Portugal等人使用了比3DES更快的AES加密算法。Rodriguez-Lera等人研究了3种加密算法（3DES、AES和Blowfish）对ROS节点间交换的TCPROS消息进行加密。

（2）身份验证与授权**

Dieber等人首次提出并实现了在应用层增强ROS安全性的解决方案。作者实现了一个专用的身份验证服务器，该服务器可以跟踪哪些ROS节点可以订阅或发布到某个话题，还负责管理节点的身份验证，并生成针对特定话题的加密密钥。

这种“访问控制与授权”的思想，在启元机器人的工程实践中演化为了极其严密的输入源仲裁机制。启元SDK提供了 SetMcInputSource 服务，开发者必须注册合法的 source（如 rc、pnc、interaction、sdk_rpc），并分配优先级（如系统级 100-80，SDK级 39-20）。如果未注册的低优先级代码试图下发运动指令，会直接被底层的Watchdog（超时脱锁机制）拦截，这从根本上防止了恶意节点或未授权代码对机器人的非法操纵。

（3）运行时验证

Huang等人提出了ROSRV运行时验证框架。该框架具有轻量级、表达性和透明性等特性，使用正式的规范语言定义系统中的安全属性，并根据规范自动生成监视器。当检测到对机器人系统具有潜在威胁的消息时，它会立即干预并拒绝该消息的传输和执行。

3.2 传输层安全加固

传输层安全加固的核心思路是修改ROS核心，在通信层实现安全机制。

（1）SROS

SROS是ROS官方社区推出的安全性增强项目，主要包含两个方面：

• 通过公钥基础设施为每个ROS节点提供X.509证书，实现对所有数据传输使用传输层安全（TLS）进行加密。
• 为话题、服务、参数和XMLRPC调用提供访问控制机制、身份验证和授权。

论文指出，SROS是经过测试的最安全的方案之一，但仍有一些不足：仅保护TCP通信通道，没有考虑UDP通信通道；仅为Python实现，不考虑C++实现的节点。

（2）基于MQTT的安全通信

Mukhandi等人提出了一种将ROS与消息队列遥测传输协议相结合的新方法。MQTT具有利用SSL/TLS的内置安全特性，将ROS与轻量级MQTT协议相集成，促使MQTT成为客户机与机器人之间连接的桥梁，从而隔离远程用户对ROS的直接访问。

3.3 网络层安全加固

网络层安全加固的核心思路是在更底层的网络层实现监控和防护。

（1）ROS-Defender

Rivera等人专门为ROS设计了一个名为ROS-Defender的网络层监控和安全工具。它基于安全事件管理系统、入侵防御系统和机器人防火墙，可以使用软件定义网络在网络层保护ROS免受大规模攻击。但使用ROS-Defender会带来很大的性能成本。

（2）ROS-FM

Rivera等人后续利用eBPF防火墙组件和XDP技术构建了一个高性能内联网络监控框架ROS-FM。通过将ROS-FM建立在eBPF防火墙组件上，作者为依赖于4.5层路由的系统提供了第1个eBPF防火墙，通过访问控制提高ROS中数据传输的机密性和完整性。

3.4 ROS2：从架构层面解决安全问题

论文在3.2.5节介绍了ROS2。ROS2在设计之初就考虑了安全通信，在其传输层中采用了DDS的行业标准，通过集成DDS-Security规范进行动态数据保护。

DDS-Security规范定义了5个SPI，ROS2的安全性目前只使用了其中3种：

• 身份验证：使用公钥基础设施，每个参与者需要公钥和私钥，并将公钥绑定到特定名称的X.509证书。
• 访问控制：对通过认证的参与者可以执行的DDS相关操作进行限制。
• 加密：提供使用高级加密标准的认证加密。

论文在表1中对各种ROS安全性解决方案进行了全面对比：

OSI分层	解决方案	解决的ROS安全问题	保证CIA
应用层	ROS-3DES-ENCRYPTION	传输数据未加密	机密性
应用层	ROS-AES-ENCRYPTION	传输数据未加密	机密性
应用层	SECURE-ROS-TRANSPORT	未加密、未验证	机密性、完整性
应用层	ROSVR	未访问控制	机密性、完整性
传输层	SROS	未加密、未验证、未访问控制	机密性、完整性
传输层	SECURE ROS With MQTT	未加密、未验证、未访问控制	机密性、完整性
传输层+应用层	Security for ROS	未加密、未验证、未访问控制	机密性、完整性
传输层+应用层	Secure ROS	未加密、未验证、未访问控制	机密性、完整性、可用性
—	ROS2	全部解决	机密性、完整性、可用性

从表中可以看出：ROS2在机密性、完整性、可用性方面为机器人系统提供了强有力的安全保障，是目前最全面的解决方案。

四、启元生态专属锚定与展望

4.1 启元开发者生态的代码安全红线

启元机器人作为一款面向真实场景的具身智能体，其开发者生态建设中，安全问题有着明确的物理边界。在官方SDK的《友好用户使用声明》中，极其罕见且坦诚地列出了三大硬件风险，这也是开发者代码安全必须死守的底线：

• 直控风险与硬件损毁：SDK允许开发者绕过预设保护逻辑直接控制硬件（如 aima/hal/joint/command 接口）。《声明》明确警告，过大的增益或超限位置增量会导致“剧烈震颤、机械碰撞或不可逆的硬件损毁”。文档中甚至做了硬性限制：单帧位置增量绝对值禁止超过 0.2 rad。
• 系统冲突（指令竞态）：开发者需严格遵守调用规范（如低层控制前必须关闭高层运控模块）。因违反调用顺序或并行指令冲突（例如同时调用 McAction 和底层伺服流）导致的系统崩溃，由开发者承担全部责任。
• 网络暴露风险：开启“开发者模式”及相关通讯接口（如 ROS2 DDS）可能会降低系统原有的网络安全防护等级。开发者必须确保机器人在封闭局域网（如直连 10.1.1.100）内运行，严禁直接暴露于公网。

4.2 从ROS2底层架构看启元的安全建设

再看启元在AtomGit上的开源布局，其SDK架构本身就在通信和业务层实现了严格的隔离。借鉴ROS安全性综述中的方案，启元AtomGit社区在以下层面构建了安全机制：

安全层面	启元真实技术实现	防范的安全威胁
通信隔离	基于 ROS2 FastDDS，开发板/大脑板网络分离	防止外部节点嗅探或恶意注入运动指令
状态机保护	SetMcAction 严格的状态拓扑（如未站立不许走跑）	防止非法的越级动作切换导致机器人摔倒
防指令冲突	输入源仲裁（优先级抢占） + 超时脱锁（1000ms）	防止多端并发操作（如App与SDK同时控制）
物理限幅	JointCommand 限制单帧 < 0.2 rad	防止电机扭矩过激导致减速器崩齿
网络边界	仅限安全局域网（10.1.1.100），避免公网暴露	防止未经授权的第三方远程操控

4.3 从ROS安全看启元的技术选型

论文在最后部分提出了一个关键问题：ROS2未来是否会取代ROS？对于启元来说，这个问题的答案已经是确定的。

启元的SDK不仅全面拥抱了 ROS2 Humble，还通过自定义的 aimdk_msgs 接口包（包含36个 .msg 话题和18个 .srv 服务），将机器人的全量能力封装。在这个过程中，启元通过 RPK（Robot Package） 规范，将技能分发的权限收拢。开发者在AtomGit上提交的代码，不再是直接操控硬件的裸流，而是需要通过规范接口和状态机校验的合法指令。这种从“通信层”到“接口层”再到“技能包层”的三级防护，正是ROS2安全理念在启元生态中最彻底的落地。

五、总结与展望

本文以《机器人操作系统ROS安全性研究综述》为核心蓝本，系统拆解了ROS安全性的技术全景：

• 四大安全缺陷：明文通信、模块化安全隐患、弱授权方案、不提供QoS。
• 三条增强路径：应用层安全加固、传输层安全加固、网络层安全加固。
• ROS2的DDS-Security机制：身份验证、访问控制、加密三大SPI。

在此基础之上，本文从开发者生态代码安全的角度，探讨了：

• 启元开发者生态的通信安全、Skill安全执行、工具链安全需求。
• AtomGit社区如何在通信加密、身份验证、访问控制、代码审计、运行时监控五个层面构建安全机制。
• 从ROS安全看启元的技术选型。

机器人操作系统的安全性，不仅是技术问题，更是生态问题。对于启元机器人来说，AtomGit社区的代码安全建设，将是从"开源"走向"可信开源"的关键一步。

尾

本期技术解构至此。

论文揭示的方法论范式对跨领域技术实践具有普适参考价值。下期将聚焦其他前沿成果，深入剖析其的突破路径。敬请持续关注，共同深挖工程实现脉络，淬炼创新底层逻辑，在学术与工程融合中洞见技术演进规律，推动领域范式持续进化。

启元机器人开发者社区：https://dev.primebot.com/