工业级数据分发服务DDS之安全篇

引出问题

在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域免受外来者的攻击。其二是域内安全防护。

域级安全

域级安全是一个相当简单的模型，将安全范围控制在域内，由开发者或维护者决定域的成员，被包含在域内的成员在域内允许执行任何被授权的操作。域内成员对topic的访问权限也由其域身份所决定。但是站在域的内部看，域内就像是一个没有经过安全防护的网络。此安全协议的目标是防止出现未经授权的域参与者的出现（在不考虑域内访问控制规则的情况下）。

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

域内安全

域内安全遵循最小权限原则(Principle of Least Privilege)，提供了更高级的保护类型，这意味着参与者为了完成任务，不能做未经授权的事情。最小权限原则基于每个主题和分区的读写访问规则。在定义这些访问规则之后，安全插件将约束对每个topic和partition的读、写权限。

上面图，其中三个参与者(P1、P2和P3)拥有发布和订阅蓝色主题的权限，而只有P1对红色Topic有发布和订阅权限——P2对蓝色主题有订阅权限，但P3没有访问它的权限。这个场景表明，域内部的保护适用于特定的主题和分区，并不是每个DomainParticipant都被允许发布或订阅每个主题或分区。可以分别为每个主题或者分区设置访问规则，进而实现机密性和完整性的要求。因此，对于每个域，都可以根据需要在每个主题或每个分区上配置不同的防护规则。

基于RTPS协议的安全

为了防止在域中出现未经授权的操作，DDS安全规范对RTPS协议进行了安全增强。由于开放的网络，任何人都可以加入其中并开始接收数据，因此惟一可用的保护机制是保护RTPS消息本身。
安全插件将添加信息并修改RTPS消息以保护它们。在RTPS级别应用的所有保护都基于对称加密，这是一次性加密一对多分发所必需的。因此，发送方和接收方都需要知道密钥。身份验证过程结束后，参与者交换密钥，使用Diffie-Hellman（一种确保共享KEY安全 穿越 不安全网络的方法，它是OAKLEY的一个组成部分。）建立共享秘密。对于身份验证，参与者使用非对称密码学。

• 完整性保护
  通过向原始消息追加消息验证码(MAC)来保护消息的完整性。默认情况下，该代码的长度为16字节。MAC的内容取决于原始消息的内容以及密钥。您需要密钥来创建和验证MAC。因此，发送方和接收方都需要知道密钥。发送方和所有接收方都使用相同的密钥。如果在接收端验证MAC失败，就意味着数据完整性遭到了破坏。
  

• 机密性保护
  MAC提供完整性保护，因此攻击者将无法篡改数据，因为对数据的修改将被检测为未能通过MAC验证。然而，MAC本身不保护机密性。如果需要保密，则必须在数据通过网络发送之前对其进行加密。加密字节由消息和密钥生成。因此，发送方和接收方都需要知道相同的密钥。

  加密本身并不能保证数据的完整性。因此，安全插件计算经过加密的数据的MAC，并将其包含在结果消息中。在实践中，DDS安全规范定义了完整性保护和机密性以及完整性保护。

  遵循OMG数据分发服务(DDS)标准的理念，DDS安全规范遵循以数据为中心的模型，其中所有内容都是分布式的。这意味着所有加入DDS域的合法参与者都将执行所需的保护。这就是它们彼此之间可以进行通信的方式(它们执行相同类型的保护)，同时阻止外部人员参与(因为这种保护)。换句话说，如果一个参与者不执行所需的保护，它将无法与安全域中的其他参与者通信。

• 来源认证保护
  还可以强制数据源身份验证。例如，如果您有一个与多个datareader匹配的DataWriter，那么所有的读取器都从同一个写入器接收数据。因此，所有的读取器都需要知道用于加密和解密数据以及计算和验证MAC的相同的秘密密钥。如果这个秘密密钥在数百个读取器之间共享，那么所有这些读取器都拥有重现MAC的加密和计算的知识，因为该密钥与写入器使用的密钥相同。换句话说，读取器可以冒充写入器，从而破坏访问控制机制。如果读者之间互不信任，您可以设置来源身份验证保护。

  这种类型的保护需要在系统中使用额外的密钥。更具体地说，除了发送方密钥之外，每个发送方-接收方对还将有一个特定于接收方的密钥。注意，datawriter和datareader都可以充当发送方和接收方。此外，RTPS消息和子消息将附加额外的mac(每个接收器一个)。

  在前面的例子中，DataWriter将附加一个包含额外的特定于接收器的MAC的列表到通用MAC。然后，在常规的通用MAC验证之后，每个DataReader必须在该列表中找到它的特定于接收器的MAC，并验证特定于接收器的MAC是用它专门为自己和DataWriter之间使用而创建的秘密密钥计算的。通过验证公共MAC, DataReader可以相信数据没有被任何没有发送方密钥的人篡改过，因为生成公共MAC需要这个密钥。通过验证接收方特定MAC, DataReader可以验证发送数据的匹配DataWriter，因为它是与接收方特定密钥共享的唯一实体。

RTI方案

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

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

安全插件的特性

• 解耦插件来解决不同的安全问题，例如OMG DDS安全规范中定义的身份验证、访问控制、加密、消息身份验证、数字签名、日志记录和数据标记等。
• 安全插件理论上可以在任何传输协议上运行，当然包括内置的UDP多播传输协议和TCP传输协议。
• 安全多播支持将数据高效且可扩展地分发给多个订阅者。
• 支持自定义安全插件，以适应专有的或FIPS 140-2兼容的加密解决方案，利用自定义安全硬件或者以多种方式更改插件的行为。安全插件SDK能够自定义安全插件以满足系统的安全需求。
• OMG 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标准