【ROS2原理15】ROS2与DDS协议

发布于:2023-01-10 ⋅ 阅读:(1423) ⋅ 点赞:(1)

一、提要

        机器人技术充满了实验:评估不同的硬件和软件,推进可行的,剔除不可行的。 ROS 被设计为灵活地进行此实验;允许现有组件轻松与新组件组合或与其他组件交换。在 ROS 1 中,这种灵活性的价值高于一切,但以安全为代价。凭借在 DDS 之上设计的优点,ROS 2 能够保持这种灵活性,同时获得通过适当利用 DDS-Security 规范来保护的能力。本文介绍了 ROS 2 如何与 DDS-Security 集成。

        DDS-Security 规范扩展了 DDS 规范,通过定义服务插件接口 (SPI) 架构、一组 SPI 的内置实现以及 SPI 强制执行的安全模型来增加安全性。具体来说,定义了五个 SPI:

  • 身份验证:验证给定域参与者的身份。
  • 访问控制:对经过身份验证的域参与者可以执行的 DDS 相关操作实施限制。
  • 加密:处理所有必需的加密、签名和散列操作。
  • 日志记录:提供审计 DDS-Security 相关事件的能力。
  • 数据标记:提供向数据样本添加标记的能力。

        ROS 2 的安全功能目前仅使用前三个。这是因为,为了符合 DDS 安全规范(参见第 2.3 节),既不需要记录也不需要数据标记,因此并非所有 DDS 实现都支持它们。让我们进一步研究前三个插件。

二、验证

        身份验证插件(参见 DDS-Security 规范的第 8.3 节)是整个 SPI 架构的核心,因为它提供了已确认身份的概念,没有它就不可能进一步执行(例如,很难确保给定的如果无法安全地确定它是哪个身份,ROS 身份只能访问特定主题)。

        SPI 架构允许许多潜在的身份验证方案,但 ROS 2 使用内置身份验证插件(称为“DDS:Auth:PKI-DH”,参见 DDS-Security 规范的第 9.3 节),该插件使用经过验证的公钥基础设施(PKI)。它需要每个域参与者的公钥和私钥,以及将参与者的公钥绑定到特定名称的 x.509 证书。每个 x.509 证书必须由插件配置为信任的特定证书颁发机构 (CA) 签名(或具有签名链)。

        使用内置插件而不是其他任何东西的理由是双重的:

        这是规范中详细描述的唯一方法。
        所有兼容的 DDS 实现都必须以互操作方式支持它(参见 DDS-Security 规范的第 2.3 节),这使得 ROS 2 安全功能可以轻松地跨供应商工作。
访问控制

三、访问控制

        访问控制插件(参见 DDS-Security 规范的第 8.4 节)处理对给定域参与者的 DDS 相关功能的定义和实施限制。例如,它允许用户将特定的参与者限制在特定的 DDS 域中,或者只允许参与者读取或写入特定的 DDS 主题等。

        再次,SPI 架构允许插件如何完成此任务具有一定的灵活性,但 ROS 2 使用内置访问控制插件(称为“DDS:Access:Permission”,参见 DDS-Security 规范的第 9.4 节),它再次使用 PKI .每个域参与者需要两个文件:

        治理文件:一个签名的 XML 文档,指定应如何保护域。
权限文件:包含域参与者权限的已签名 XML 文档,绑定到由身份验证插件定义的参与者名称(正如我们刚刚讨论的那样,通过 x.509 证书完成)。
这两个文件都必须由插件配置为信任的 CA 签名。这可能是身份验证插件信任的同一个 CA,但这不是必需的。

        使用内置插件而不是其他任何东西的基本原理与身份验证插件相同:

        这是规范中详细描述的唯一方法。
所有兼容的 DDS 实现都必须以互操作方式支持它(参见 DDS-Security 规范的第 2.3 节),这使得 ROS 2 安全功能可以轻松地跨供应商工作。


四、密码学

        加密插件(参见 DDS-Security 规范的第 8.5 节)是处理所有与加密相关的操作的地方:加密、解密、签名、散列等。身份验证和访问控制插件都利用加密插件的功能来验证签名等。这也是加密 DDS 主题通信的功能所在。

        虽然 SPI 架构再次允许多种可能性,但 ROS 2 使用内置加密插件(称为“DDS:Crypto:AES-GCM-GMAC”,参见 DDS-Security 规范的第 9.5 节),它使用 Advanced 提供经过身份验证的加密伽罗瓦计数器模式 (AES-GCM) 中的加密标准 (AES)。

        使用内置插件而不是其他任何插件的基本原理与其他插件相同:

        这是规范中详细描述的唯一方法。
        所有兼容的 DDS 实现都必须以互操作方式支持它(参见 DDS-Security 规范的第 2.3 节),这使得 ROS 2 安全功能可以轻松地跨供应商工作。

五、DDS-Security 与 ROS 2 的集成:SROS 2

        现在我们已经对 DDS 中如何支持安全性建立了一些共同的理解,让我们讨论如何在 ROS 2 中公开这种支持。默认情况下,ROS 2 中没有启用任何 DDS 的安全功能。用于启用它们的 ROS 2 统称为“安全 ROS 2”(SROS 2)。

5.1 ROS 客户端库 (RCL) 中的功能

        大多数面向用户的 SROS 2 运行时支持都包含在 ROS 客户端库中。一旦满足其要求,它就会为每个受支持的 DDS 实现配置中间件支持。 RCL 包括 SROS 2 的以下功能:

  • 支持每个域参与者的安全文件。
  • 支持宽松和严格的安全执行。
  • 支持所有 SROS 2 功能的主“开/关”开关。
  • 让我们依次讨论这些。

5.2 每个域参与者的安全文件

        如前所述,DDS-Security 插件需要每个域参与者的一组安全文件(例如密钥、治理和权限文件等)。域参与者映射到 ROS 2 中进程内的上下文,因此每个进程都需要一组这些文件。 RCL 支持以两种不同的方式指向包含安全文件的目录:

所有安全文件的目录树。
手动规范。
让我们进一步研究这些。

所有安全文件的目录树
        RCL 支持在保留 enclaves 子文件夹内的一个目录中查找安全文件,该目录位于根密钥库中,对应于每个 enclave 的完全限定路径。例如,对于 /front/camera 飞地,目录结构如下所示:

<root>
├── enclaves
│   └── front
│       └── camera
│           ├── cert.pem
│           ├── key.pem
│           ├── ...
└── public
    ├── ...

每个 enclave 实例目录中预期的文件集是:

  • identity_ca.cert.pem:身份验证插件信任的 CA 的 x.509 证书(“身份”CA)。
  • cert.pem:此 enclave 实例的 x.509 证书(由 Identity CA 签名)。
  • key.pem:此 enclave 实例的私钥。
  • permissions_ca.cert.pem:访问控制插件信任的 CA 的 x.509 证书(“权限”CA)。
  • Governance.p7s:向访问控制插件指定如何保​​护域的 XML 文档(由 Permissions CA 签名)。
  • permissions.p7s:指定此特定 enclave 实例对访问控制插件(也由 Permissions CA 签名)的权限的 XML 文档。

这可以通过将 ROS_SECURITY_KEYSTORE 环境变量设置为指向密钥库目录树的根目录来指定,然后使用 --ros-args 运行时参数 -e、--enclave 指定 enclave 路径,例如:

export ROS_SECURITY_KEYSTORE="/home/bob/.ros/sros2_keystore"
ros2 run <package> <executable> --ros-args --enclave="/front/camera"

5.3 手册规格

        RCL 还支持为需要使用覆盖环境变量启动的进程指定 enclave 路径。这可以通过将 ROS_SECURITY_ENCLAVE_OVERRIDE 环境变量设置为密钥库中的备用飞地路径来完成。请注意,此设置优先于带有 --enclave 的 ROS_SECURITY_KEYSTORE。

请注意,以下两个示例从之前演示的相同 enclave 路径加载:

export ROS_SECURITY_KEYSTORE="/home/bob/.ros/sros2_keystore"
export ROS_SECURITY_ENCLAVE_OVERRIDE="/front/camera"
ros2 run <package> <executable>
export ROS_SECURITY_KEYSTORE="/home/bob/.ros/sros2_keystore"
export ROS_SECURITY_ENCLAVE_OVERRIDE="/front/camera"
ros2 run <package> <executable> --ros-args --enclave="/spam"

5.5 支持许可和严格的安全执行

        启用了安全功能的参与者不会与没有启用安全功能的参与者进行通信,但是如果有人试图启动一个没有可识别飞地的参与者,RCL 应该怎么做?它有两个选项:

  • 许可模式:尝试查找安全文件,如果找不到,则在不启用任何安全功能的情况下启动参与者。这是默认行为。
  • 严格模式:尝试查找安全文件,如果找不到,则运行参与者失败。

        所需的模式类型可以通过将 ROS_SECURITY_STRATEGY 环境变量设置为“强制”(区分大小写)来指定严格模式,以及其他任何允许模式。

5.6 支持所有 SROS 2 功能的主“开/关”开关

        除了刚刚讨论的受支持功能外,RCL 还支持安全功能的主关闭功能,以便于实验。如果关闭(默认),则不会启用上述任何安全功能。

为了启用 SROS 2,请将 ROS_SECURITY_ENABLE 环境变量设置为“true”(区分大小写)。要禁用,请设置为任何其他值。

六、SROS 2 CLI 中的功能

        在 RCL 中将 ROS 2 系统配置为安全涉及许多新技术(PKI、DDS 治理和权限文件及其语法等)。如果用户对这些技术感到满意,那么上述信息应该是正确锁定事物所必需的。但是,SROS 2 CLI 应该包含一个工具 ros2 security 来帮助那些不想自己设置的人,包括以下功能:

  • 创建身份和权限 CA。
  • 创建包含所有安全文件的目录树。
  • 为给定的 enclave 创建一个新身份,生成一个密钥对并使用 Identity CA 签署其 x.509 证书。
  • 创建一个治理文件,默认情况下将加密所有 DDS 流量。
  • 支持以熟悉的 ROS 术语指定 enclave 权限,然后自动转换为低级 DDS 权限。
  • 支持从正在运行的 ROS 系统中自动发现所需的权限。

网站公告

今日签到

点亮在社区的每一天
去签到

热门文章