CoAP协议学习笔记可点此查看。
1 前言
在 CoAP 协议 RFC7252 的第9章 Securing CoAP ，即是本译文内容。
2 协议翻译
9.1 DTLS加密
正如使用TCP上的传输层加密协议（TLS）保护HTTP一样，CoAP使用UDP上的数据报TLS协议（DTLS）RFC6347来进行加密。 本节定义了对DTLS的CoAP绑定，以及适用于受限环境的最小必须执行的配置。绑定由基于单播CoAP的一系列的增量来定义。 在实践中，DTLS是在TLS基础上，还对UDP传输不可靠特性进行额外的处理。
代码语言：javascript复制 ----------------------
| Application |
----------------------
----------------------
| Requests/Responses |
|----------------------| CoAP
| Messages |
----------------------
----------------------
| DTLS |
----------------------
----------------------
| UDP |
---------------------- 图.DTLS加密的抽象分层
在一些受限制的节点（有限的Flash或RAM）和网络（有限的带宽或高可扩展性要求）中，并且取决于正在使用的加密套件，DTLS的所有模式可能不适用。一些DTLS加密套件可能会增加重要的实现复杂性，并且在设置安全关联时需要一些初始握手开销。一旦初始握手完成后，DTLS增加了一个有限的每个数据报的开销大约为13个字节，不包括任何初始化矢量/随机数（例如 TLS_PSK_WITH_AES_128_CCM_8 占用8个字节 RFC6655），还有完整性校验值（例如 TLS_PSK_WITH_AES_128_CCM_8 占用8个字节 RFC6655）以及密码套件所需的字节填充。给定模式的DTLS是否适用于CoAP应用，需要重点考虑具体可用的密码套件，会话的维护是否兼容应用程序流，资源是否满足受限节点和增加的网络开销。（对于某些使用DTLS的模式，本规范确定了一个强制实施的密码套件，这是一个实现要求，以便在这些密码套件确实合适的情况下实现互操作性的最大化。应用程序的特定安全策略可以确定实际可以使用的密码套件组）。DTLS不适用于组密钥（多播通信）;但是，它可能是未来组密钥管理协议中的组件。
9.1.1 消息层 Messaging Layer
充当CoAP客户端的端点也应该充当DTLS客户端。它应该在适当的端口上向服务器启动一个会话。 当DTLS握手完成时，客户端可以发起第一个CoAP请求。所有的CoAP消息务必作为DTLS“应用数据”发送。
添加以下规则以将 Acknowledgement 消息或 Reset 消息与 Confirmable 消息或针对 Non-confirmable 消息的 Reset 消息进行匹配：DTLS 会话必须相同，并且 epoch 必须相同。
在相同的DTLS会话 和 同一个时间段内发送并具有相同的消息ID时，认为消息是相同的。
注意：当 Confirmable 消息重传的时候，每次尝试需要使用新的 DTLS 序列号，即使 CoAP Message ID 保持一致。因此接收端要做下去重处理。在跨时间段epoch后，不能执行重传。
RawPublicKey 和 Certificate 模式中的DTLS连接使用相互认证来建立，以便它们可以保持并重复用于未来在任何方向上的消息交换。 设备可以在需要恢复资源时关闭DTLS连接，但通常它们应该尽可能长时间保持连接。 每次CoAP消息交换后关闭DTLS连接效率非常低。
9.1.2. 请求/回复层 Request/Response Layer
添加以下规则以匹配对请求的响应：DTLS会话必须相同，并且时间段epoch必须相同。 这意味着对DTLS安全请求的响应必须始终使用相同的安全会话和时期进行DTLS安全保护。 任何尝试提供对DTLS请求的NoSec响应都不符合请求，因此必须被拒绝（除非它确实匹配不相关的NoSec请求）。
9.1.3. 端点ID Endpoint Identity
设备应该支持服务器名称指示（SNI），以在RFC6066的第3节中定义的SNI主机名字段中指示其权限。 这是必需的，以便当充当多个权威的虚拟服务器的主机接收到新的DTLS连接时，它知道哪些密钥用于DTLS会话。
9.1.3.1. Pre-Shared Keys
9.1.3.2. Raw Public Key Certificates
9.1.3.3. X.509 Certificates
Implementations in Certificate Mode MUST support the mandatory-toimplement cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 as specified in RFC7251, RFC5246, and RFC4492. Namely, the certificate includes a SubjectPublicKeyInfo that indicates an algorithm of id-ecPublicKey with namedCurves secp256r1 RFC5480; the public key format is uncompressed RFC5480; the hash algorithm is SHA-256; if included, the key usage extension indicates digitalSignature. Certificates MUST be signed with ECDSA using secp256r1, and the signature MUST use SHA-256. The key used MUST be ECDSA capable. The curve secp256r1 MUST be supported RFC4492; this curve is equivalent to the NIST P-256 curve. The hash algorithm is SHA-256. Implementations MUST use the Supported Elliptic Curves and Supported Point Formats Extensions RFC4492; the uncompressed point format MUST be supported; RFC6090 can be used as an implementation method.
证书模式下的实现必须支持RFC7251，RFC5246和RFC4492中规定的强制实现密码套件TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8。 即，证书包括SubjectPublicKeyInfo，其指示具有namedCurves secp256r1 RFC5480的id-ecPublicKey的算法; 公钥格式是未压缩的RFC5480; 散列算法是SHA-256; 如果包含，则密钥使用扩展指示digitalSignature。 证书务必使用secp256r1使用ECDSA进行签名，签名必须使用SHA-256。 使用的密钥必须是ECDSA的能力。 曲线secp256r1务必支持RFC4492; 这条曲线相当于NIST P-256曲线。 散列算法是SHA-256。 实现必须使用支持的椭圆曲线和支持点格式扩展RFC4492; 未压缩的点格式必须被支持; RFC6090可以用作实现方法。
The subject in the certificate would be built out of a long-term unique identifier for the device such as the EUI-64 EUI64. The subject could also be based on the Fully Qualified Domain Name (FQDN) that was used as the Host part of the CoAP URI. However, the device’s IP address should not typically be used as the subject, as it would change over time. The discovery process used in the system would build up the mapping between IP addresses of the given devices and the subject for each device. Some devices could have more than one subject and would need more than a single certificate.
证书中的主题将由设备的长期唯一标识符构成，例如EUI-64 EUI64。 主题也可以基于用作CoAP URI主机部分的完全限定域名（FQDN）。 但是，设备的IP地址通常不应该用作主题，因为它会随着时间而改变。 系统中使用的发现过程将建立给定设备的IP地址与每个设备的主题之间的映射。 有些设备可能有多个主题，需要的不止一个证书。
When a new connection is formed, the certificate from the remote device needs to be verified. If the CoAP node has a source of absolute time, then the node SHOULD check that the validity dates of the certificate are within range. The certificate MUST be validated as appropriate for the security requirements, using functionality equivalent to the algorithm specified in Section 6 of RFC5280. If the certificate contains a SubjectAltName, then the authority of the request URI MUST match at least one of the authorities of any CoAP URI found in a field of URI type in the SubjectAltName set. If there is no SubjectAltName in the certificate, then the authority of the request URI MUST match the Common Name (CN) found in the certificate using the matching rules defined in RFC3280 with the exception that certificates with wildcards are not allowed.
当新连接形成时，需要验证来自远程设备的证书。 如果CoAP节点有绝对时间源，那么节点应该检查证书的有效日期是否在范围内。 必须根据安全要求验证证书，使用与RFC5280第6节中规定的算法等效的功能。 如果证书包含SubjectAltName，那么请求URI的权限必须至少匹配SubjectAltName集合中URI类型字段中找到的任何CoAP URI的权限之一。 如果证书中没有SubjectAltName，则请求URI的权限必须与使用RFC3280中定义的匹配规则的证书中的Common Name（CN）匹配，但不允许使用带有通配符的证书。
CoRE support for certificate status checking requires further study. As a mapping of the Online Certificate Status Protocol (OCSP) RFC6960 onto CoAP is not currently defined and OCSP may also not be easily applicable in all environments, an alternative approach may be using the TLS Certificate Status Request extension (Section 8 of RFC6066; also known as “OCSP stapling”) or preferably the Multiple Certificate Status Extension (RFC6961), if available.
CoRE支持证书状态检查需要进一步研究。 由于在线证书状态协议（OCSP）RFC6960到CoAP的映射目前尚未定义，并且OCSP也可能不容易适用于所有环境，因此另一种方法可能是使用TLS证书状态请求扩展（第8 RFC6066;也称为“OCSP装订”）或优选多证书状态扩展（RFC6961）（如果可用）。
If the system has a shared key in addition to the certificate, then a cipher suite that includes the shared key such as TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA RFC5489 SHOULD be used.
如果系统除了证书之外还有共享密钥，则应使用包含共享密钥（例如TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA RFC5489）的密码套件。
