Skip to main content

9. Securing CoAP (保护CoAP安全)

本节定义了CoAP的DTLS绑定.

在配置阶段, 为CoAP设备提供其所需的安全信息, 包括密钥材料和访问控制列表. 本规范在第9.1.3.2.1节中定义了RawPublicKey模式的配置. 在配置阶段结束时, 设备将处于四种安全模式之一, 并具有给定模式的以下信息. NoSec和RawPublicKey模式是本规范的强制实现模式.

NoSec: 没有协议级安全性 (DTLS已禁用). 在适当时应该使用替代技术来提供较低层安全性. [IPsec-CoAP]中讨论了IPsec的使用. 与受限节点一起使用的某些链路层也提供链路层安全性, 这在适当的密钥管理下可能是合适的.

PreSharedKey: DTLS已启用, 有一个预共享密钥列表[RFC4279], 每个密钥包括一个可用于通信的节点列表, 如第9.1.3.1节中所述. 在极端情况下, 此CoAP节点需要与之通信的每个节点可能有一个密钥 (1:1节点/密钥比率). 相反, 如果两个以上的实体共享特定的预共享密钥, 则此密钥仅使实体能够作为该组的成员进行身份验证, 而不是作为特定对等方进行身份验证.

RawPublicKey: DTLS已启用, 设备具有没有证书的非对称密钥对 (原始公钥), 该密钥对使用带外机制[RFC7250]进行验证, 如第9.1.3.2节中所述. 设备还具有从公钥计算的身份以及可与之通信的节点的身份列表.

Certificate: DTLS已启用, 设备具有X.509证书[RFC5280]的非对称密钥对, 该证书将其绑定到其主题并由一些公共信任根签名, 如第9.1.3.3节中所述. 设备还具有可用于验证证书的根信任锚列表.

在"NoSec"模式下, 系统只是通过IP上的普通UDP发送数据包, 并由"coap"方案和CoAP默认端口指示. 该系统仅通过阻止攻击者能够从具有CoAP节点的网络发送或接收数据包来保护; 有关此方法的其他复杂性, 请参见第11.5节.

其他三种安全模式使用DTLS实现, 并由"coaps"方案和DTLS保护的CoAP默认端口指示. 结果是可用于身份验证 (在安全模型的限制内) 并基于此身份验证授权通信伙伴的安全关联. CoAP本身不提供用于身份验证或授权的协议原语; 在需要的地方, 它可以由通信安全性 (即, IPsec或DTLS) 或对象安全性 (在有效载荷内) 提供. 需要对某些操作进行授权的设备预期需要这两种形式的安全性之一. 必然地, 在涉及中介的情况下, 通信安全性仅在该中介是信任关系的一部分时才有效. CoAP不提供一种方法来将客户端可能与中介具有的不同授权级别转发到进一步的中介或源服务器 -- 因此可能需要在第一个中介执行所有授权.

9.1. DTLS-Secured CoAP (DTLS保护的CoAP)​

就像HTTP使用TCP上的传输层安全性 (TLS) 进行保护一样, CoAP使用UDP上的数据报TLS (DTLS) [RFC6347]进行保护 (见图13). 本节定义了CoAP到DTLS的绑定, 以及适合受限环境的最小强制实现配置. 绑定由对单播CoAP的一系列增量定义. 实际上, DTLS是具有附加功能的TLS, 用于处理UDP传输的不可靠性质.

                     +----------------------+
                     |      Application     |
                     +----------------------+
                     +----------------------+
                     |  Requests/Responses  |
                     |----------------------|  CoAP
                     |       Messages       |
                     +----------------------+
                     +----------------------+
                     |         DTLS         |
                     +----------------------+
                     +----------------------+
                     |          UDP         |
                     +----------------------+

         图 13: DTLS保护的CoAP的抽象分层

在某些受限节点 (有限的闪存和/或RAM) 和网络 (有限的带宽或高可扩展性要求) 中, 并且取决于使用的特定密码套件, DTLS的所有模式可能并不适用. 某些DTLS密码套件可能会增加显著的实现复杂性以及设置安全关联时所需的一些初始握手开销. 一旦初始握手完成, DTLS会为每个数据报添加大约13字节的有限开销, 不包括任何初始化向量/nonce (例如, TLS_PSK_WITH_AES_128_CCM_8 [RFC6655]为8字节), 完整性检查值 (例如, TLS_PSK_WITH_AES_128_CCM_8 [RFC6655]为8字节), 以及密码套件所需的填充. 是否使用给定的DTLS模式适用于基于CoAP的应用应该仔细权衡, 考虑可能适用的特定密码套件, 会话维护是否使其与应用流兼容, 以及受限节点上是否有足够的资源以及添加的网络开销. (对于使用DTLS的某些模式, 本规范标识了强制实现的密码套件. 这是一个实现要求, 以在这些密码套件确实适当的情况下最大化互操作性. 应用程序的特定安全策略可能确定可以使用的实际密码套件集.) DTLS不适用于组密钥管理 (组播通信); 但是, 它可能是未来组密钥管理协议的一个组件.

(由于篇幅限制，第9章的其余部分省略详细内容)

Last updated on