3

我试图找出最有效的数据使用方式来保护我们的 CoAP API。DTLS 似乎是正确的方法，但看看握手需要多少数据（并对需要发生的频率做出一些不知情的假设）似乎带有 X.509 证书的 DTLS 使 CoAP 的实际数据使用相形见绌本身。

最明显的解决方案是只使用在工厂编程的对称密钥，但我认为我不喜欢强加的安全风险。据我了解，除了在所有设备上手动安装新密钥外，没有办法从服务器端入侵中恢复。

我正在考虑提出的解决方案基本上是两者的混合，使用安全 CA 分发设备，让设备进行标准握手并建立“临时”对称密钥。然后为了节省设备的带宽，我将该密钥（会话？）存储在数据库中，以便设备一次持续数月或数年，但如果我们发现任何密钥已经泄露，仍然可以使密钥过期。

我知道我可以只使用标准会话恢复握手来恢复会话，但我不确定这是必需的，因为 DTLS 是无连接的，我可以假装“连接”总是打开的。如果我可以避免重复握手，这将降低数据消耗并可能降低服务器负载。

我不知道的是：DTLS 是否定义了会话可以保持打开状态的限制？或者是否存在超时，在一段时间不活动后必须删除会话？如果没有，DTLS 的实现是否自己定义了一个？

关于为什么这不起作用，我可能会忽略其他任何事情吗？还是有什么更简单的我没有想到的？

4

2 回答 2

2

超时是特定于应用程序的，您可以根据需要将它们设置得尽可能高，或者尽可能长时间地保持连接（例如，使用固定数量的可用连接，在打开新连接时超时最近最少使用的连接）。

只要双方同意恢复数据仍然良好（例如，没有基础证书过期），会话恢复数据就可以保留。会话恢复应该至少与手动安装的对称密钥一样便宜。

因此，一个明智的方法似乎是，如果发送方仍然打开会话，则尝试继续会话，如果出现错误，则回退到会话恢复，如果这不起作用，则再次进行完整的握手。不一定需要就其中任何一个达成一致的时间。

于 2021-05-03T09:07:30.467 回答
1

（并对需要发生的频率做出一些不知情的假设）

我的感觉是，假设在一段安静的时期后 IP 地址发生变化。如果这样假设，“DTLS 会话超时”是您的 ip-route 上“NAT(like)s”的超时。而且 NAT 超时仍然（过于频繁）30 秒。如果您的 ip-route 上没有“NAT(like)”，因此对等方能够通过其静态（不更改）ip-address 和 port 交换 ip-messages，则不存在此类 DTLS 超时。除非，正如已经回答的那样，您的应用程序需要这样做。出于某些安全原因，在交换连接密钥时，IETF 中也有一些讨论。但是这个数字相当高（除非你想使用 AES128_CCM8）。

因为 DTLS 是无连接的

DTLS 需要具有主密钥和“关联密钥”（TLS“连接密钥”）的上下文。该主密钥分配给 DTLS 会话 ID，而“关联密钥”通常分配给 IP 地址和端口。然后在地址可能改变的场景中使用 DTLS 会话恢复（例如，因为“NAT(like)s”，或者因为对等方正在进入睡眠模式并在唤醒时获得新的 IP 地址）。通过这种 ip 地址更改，DTLS 会话恢复用于刷新“关联密钥”与新地址的分配。DTLS 恢复更多，它也使用新的“关联密钥”，但主要是为了克服地址更改。

最明显的解决方案是只使用对称密钥

在 PSK 和 x509 之间，还有RPK，它提供与 x509 类似的安全性，但使用的数据更少。PSK_ECDHE 密码套件也可能是一种选择。

并且希望DTLS CID将使 CoAP/DTLS 更高效。至少在我过去 2 年的测试、实验和使用中，这就是将 CoAP 带回“必须考虑”的技术！

于 2021-05-03T18:33:41.917 回答