目录

• • 引出问题
  • 分析问题
  • • 未授权订阅者
    • 未授权发布者
    • 截胡篡改
    • 跨域攻击
  • 解决问题
  • 官方标准
  • DDS的安全特性
  • • 基于域的安全保护
    • 域内保护
  • RTI方案
  • • RTI安全插件的特性
    • DDS支持的加解密算法
    • • 用于数据流保护的密码算法
      • 用于密钥交换的密码算法
      • 用于数字签名的密码算法
      • RTPS-HMAC-Only插件用于数据流保护的加密算法
  • 参考声明

引出问题

在DDS系统中，我们在以数据为中心的发布-订阅模型中有一组发布者和订阅者。例如，让我们分析下图所示的系统，其中我们有以下节点:

• Alice：发布Topic-T的合法应用程序，允许发布信息。
• Bob：订阅Topic-T的合法应用程序，允许访问信息。
• Eve：未经授权订阅Topic-T的窃听者，执行未经授权的订阅（1）。
• Trudy：未经授权发布数据的入侵者，执行未经授权的发布（2）。
• Mallory：一个恶意的内部人员(例如，被授权订阅数据但不能发布)，试图执行篡改和重播（3）。
• Trent：合法订阅和发布数据的监控服务。
  

因为AliceBob和Trent是合法的应用程序，所以它们应该能够按照设计的方式进行通信。而对于非法程序Eve和Trudy，他们是不能执行任何操作的。但是这里面的Mallory是系统内部人士，只有有限权限，那么他就不能做未经授权的操作。

分析问题

未授权订阅者

未经授权的订阅(又称窃听)意味着能够在未经授权的情况下读取敏感数据。
首先以Eve为原型，解释未经授权的窃听者，说明Eve能够在未经授权的情况下读取到敏感数据。假设Eve是系统之外的一个节点，他本不应该出现，也不应该获取到系统中的任何数据，但是在一个不安全的网络中，Eve和Alice可以实现发布订阅。由于DDS和RTPS标准没有专门解决安全性问题，所以没有定义任何机制来验证Eve是否被授权订阅Topic-T。

窃听有时候并不会造成严重的后果，但是当Topic-T携带非常敏感的数据时，就必须对他进行保护，防止窃听。

未授权发布者

未经授权发布是指未经授权将数据发布到DDS系统中。
以Trudy为原型，一个可以发布Topic-T数据的发布节点。在一个不安全的场景中，Trudy和Bob会互相发现对方，然后Trudy会开始向Bob发送数据。因此Bob会收到Alice的数据，也会收到Trudy的数据，这样的系统存在很大的安全隐患。

截胡篡改

篡改包括在将数据发送给合法订阅者之前拦截和修改数据。
当系统中存在敏感信息时，Mallory可以截胡消息，并对其进行修改，然后再发不出去，由于Bob分不清消息的来源是否可靠，造成严重的问题。
当Mallory订阅系统中的主题Topic-T，那么他就可以将消息以高频率发不出去，造成Bob严重的资源消耗，甚至是宕机。

跨域攻击

如果监控服务加入一个被恶意domainparticipant攻击的域，上述所有威胁都可能跨越DDS域。

解决问题

引入安全插件：

• 安全插件提供了保护数据机密性的机制，保证只有经过授权的订阅者才能订阅Topic-T并解析发布给它的数据。
• 安全插件提供了认证发布者和订阅者应用程序的机制，防止来自外部的未经授权的发布。此外，安全插件设置了访问控制机制，以防止未经授权的发布者。
• 安全插件设置了保护数据完整性的机制，从而可以防止篡改和攻击。

官方标准

为了解决DDS安全的问题，OMG定义了DDS安全规范标准，该规范为符合DDS的实现定义了安全模型和服务插件接口(Service Plugin Interface)服务体系框架。DDS安全模型是通过DDS实现调用服务插件接口来实现的。
规范中服务插件接口，支持即插即用的安全性，并且能够实现DDS应用程序之间互操作。
服务插件接口允许用户自定义DDS框架中用于信息保证的行为和技术，例如，自定义身份验证、访问控制、加密、消息身份验证、数字签名、日志记录和数据标记等。

• 认证服务插件，认证DDS应用程序，包括在参与者之间执行相互身份验证和建立共享秘密的功能。
• 访问控制服务插件，对域、主题等实施访问控制。
• 加密服务插件，维护数据的完整性和机密性，包括加密、解密、哈希、数字签名等。
• 日志服务插件，支持审计所有DDS安全相关的事件。
• 数据标记服务插件，提供向数据添加标记的方法。

DDS的安全特性

DDS安全特性包含两个大的方面，一方面，DDS提供域级别的安全保护；另一方面，保护手段的粒度也可以细化到域内部。（本文提到的DDS安全特性均指的是RTI DDS的安全特性，除非明确提到OMG DDS）

基于域的安全保护

由开发者或维护者决定域的成员，被包含在域内的成员具备在域内执行任何允许的操作。域内成员对topic的访问权限也由其域身份所决定。从域的内部来看，就是一个没有经过安全防护的网络（在不考虑域内访问控制规则的情况下）。

基于域的安全防护可以达到如下效果：
1）检测针对消息的篡改和注入，即完整性保护;
2）保护消息的机密性。
关于域级别的安全防护需要明确的一点是，域级别的安全防护一般通过TLS 或 DTLS来实现，即通过传输层的安全特性来实现安全域。

域内保护

域内粒度的保护基于最小权限原则制定，约束对每个topic和partition的读、写权限。

RTI方案

RTI DDS通过安全插件的机制实现诸如认证、加密等安全功能。安全插件支持可插拔的方式满足数据总线安全要求，每个安全插件覆盖不同的安全范围,主要包含以下几个方面：

• 身份认证：提供针对调用DDS接口的应用程序或用户的身份认证。还包括通信双方相互认证和共享密钥的基础设施；
• 访问控制：提供针对DDS实体可执行操作的访问控制决策；
• 数据加解密：实现加解密算法、hash算法、签名算法等。还包括从共享密钥衍生密钥的算法；
• 日志记录：审计所有安全相关的事件，以此增强系统的透明度，保证系统的可用性。
  

RTI安全插件的特性

• 解耦插件来解决不同的安全问题，例如OMG DDS安全规范中定义的身份验证、访问控制、加密、消息身份验证、数字签名、日志记录和数据标记等。
• 安全插件理论上可以在任何传输协议上运行，当然包括内置的UDP多播传输协议和TCP传输协议。
• 安全多播支持将数据高效且可扩展地分发给多个订阅者。
• 支持自定义安全插件，以适应专有的或FIPS 140-2兼容的加密解决方案，利用自定义安全硬件或者以多种方式更改插件的行为。安全插件SDK能够自定义安全插件以满足系统的安全需求。
• OMG DDS安全规范定义了一对多并且以数据为中心的方式解决通信的安全问题，使应用程序能够根据共享数据的性质定义不同的安全策略。这与DDS去中心化目标相一致，因此也具有以下优势：
  • 无单点故障。
  • 高性能、可扩展

DDS支持的加解密算法

RTI安全插件实现了多种加解密算法，包括OMG DDS安全规范中定义的所有加解密算法，以满足安全的多方面要求。下面介绍所有支持的加解密算法。

用于数据流保护的密码算法

• 针对数据完整性：
  算法：AES-GCM, used in GMAC mode (not configurable)
  密钥大小：128, 192 or 256 bits (selectable via configuration)
• 针对数据保密性和完整性：
  算法：AES-GCM (not configurable)
  密钥大小：128, 192 or 256 bits (selectable via configuration)
• 数据源认证
  算法：AES-GCM, used in GMAC mode (not configurable)
  密钥大小：256 (not configurable)

用于密钥交换的密码算法

• Shared secret agreement:
  • Support for Diffie-Hellman in ephemeral mode (DHE), with 2048-bit MODP Group parameters as specified in RFC 3526 (not configurable)
  • Support for EC Diffie-Hellman in ephemeral mode (ECDHE), with secp256r1 as specified in FIPS PUB 186-4 1 as its curve (not configurable)
  • Selection between DHE and ECDHE happens via configuration
• Key derivation:
  • HMAC-based Key Derivation Function (HKDF) with SHA-256 as specified in RFC5869 (not configurable)
• Key exchange confidentiality, which includes integrity:
  • AES-GCM with 256 bits key (not configurable)

用于数字签名的密码算法

• Builtin support for RSA keypairs with SHA-256
  • RTI Security Plugins allow any RSA keypair supported by OpenSSL
  • Support for PKCS#1 PSS padding and PKCS#1 standard padding (selectable)
  • The only key size tested for the Security Plugins is 2048 bits due to the DDS Security specification (version 1.1) calling out this specific key size
• Builtin support for EC keypairs (ECDSA) with SHA-256
  • RTI Security Plugins allow any EC keypair supported by OpenSSL
  • The only curve tested for the Security Plugins is secp256r1 due to the DDS Security specification (version 1.1) calling out this specific curve

RTPS-HMAC-Only插件用于数据流保护的加密算法

• Data integrity:
  • Algorithms: HMAC-SHA256 (not configurable)
  • Key sizes: 256 bits (not configurable)
• Data confidentiality:
  • None
• Data source authentication:
  • None

参考声明

• rti_connext_dds-6.1.1安全手册
• DDS-Security v1.1标准