我试图找出最有效的数据使用方法来保护我们的CoAP API。 DTLS似乎是正确的方法，但是看看握手需要多少数据（以及对需要发生的频率做出一些不明确的假设）似乎DTLS与X.509证书使CoAP的实际数据使用相形见绌本身。
最明显的解决方案是使用在工厂编程的对称密钥，但我不认为我喜欢强加的安全风险。据我所知，除了在所有设备上手动安装新密钥外，无法从服务器端入侵中恢复。
我想提出的解决方案基本上是两者的混合，通过安全的CA分发设备，让设备进行标准握手并建立一个临时的＆＃34;对称密钥。然后为了节省设备的带宽，我将该密钥（会话？）存储在数据库中，以便设备一次持续数月或数年，但如果我们发现任何已经获得的设备仍然能够使密钥到期进行。
我知道我可以使用标准会话恢复握手来恢复会话，但我不确定是否需要，因为DTLS是无连接的，我可以假装＆＃34;连接＆＃34;永远是开放的。如果我可以避免重复握手，这会降低数据消耗，也可能会降低服务器负载。
我不知道的事情是：DTLS是否定义了会话保持打开的时间限制？或者是否存在超时，在一段时间不活动后必须删除会话？如果没有，DTLS的实现是否自己定义了一个？
对于为什么这不起作用，还有什么我可能会忽略的事情吗？还是有一些我没想到的直截了当的东西？
答案 0 :(得分：2)
超时是特定于应用程序的，您可以根据需要将它们设置得尽可能高，或者尽可能长时间地保持连接（例如，使用固定数量的可用连接，当新的连接出现时，最近最少使用的超时一个是打开的）。
只要双方同意恢复数据仍然良好（例如，没有基础证书已过期），就可以保留会话恢复数据。会话恢复应该至少与手动安装的对称密钥一样便宜。
因此，一个明智的方法似乎是，如果发送方仍然打开会话，则尝试继续会话，在出错时退回到会话恢复，如果这不起作用，则再次进行完整的握手。不一定需要就任何时间达成一致。
答案 1 :(得分：1)
（并对需要发生的频率做出一些不知情的假设）
我的感觉是，假设在一个安静的时期后 ip 地址会发生变化。如果假设是这样，则“DTLS 会话超时”是 ip-route 上“NAT(like)s”的超时。并且 NAT 超时仍然（太频繁）30 秒。 如果您的 ip-route 上没有“NAT(like)”，因此对等方能够通过它们的静态（未更改）ip-地址和端口交换 ip-message，那么就没有这样的 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 重新成为“必须考虑”的技术！