DTLS与使用JKS / JCE加密UDP数据报相比

Question

我需要Java中的加密UDP连接。 我知道DTLS，但是在Java中是有问题的。 因此，我更喜欢使用JKS或JCE进行自己的加密。 为什么要使用UDP？ 一些丢失的数据包或重新排序与我无关，但延迟却与我无关。 到目前为止，我有这个概念：

服务器创建一个临时的对称加密密钥（对于会话是唯一的），并使用客户端的公钥对其进行加密（非对称加密），并将其发送给他。 会话的其余部分仅与使用对称密钥加密的数据报通信。

与DTLS相比，使用此方法有什么缺点？ 速度？ 安全？

Answer 1

主要缺点是您自己想到了它。 通常，除非实际上是密码学家，否则永远不要在密码学相关问题上变得“聪明”或“创新”。 缺乏有关工具，算法和攻击媒介的全面经验，确保密码强度的最佳方法是使用经过良好测试的标准化工具。 这意味着DTLS。

在这种情况下，假设服务器尚未知道所有客户端的公钥，那么一个问题似乎就是对MITM攻击的敏感性。 根据对称算法和数据报的内容，它也可能容易受到已知明文攻击或选择密文攻击。 再说一遍，这些是您应该阅读的东西，会感到害怕，意识到这不是您想要花费的时间，然后继续使用DTLS。

Answer 2

听起来好像您正在尝试重新发明DTLS。 您说的是DTLS有问题，但这为什么呢？

从理论上讲，您的逻辑是正确的。 它让我想起了使用RSA密钥交换的DTLS：

• 客户端-> ClientHello（共享ClientRandom ）
• 服务器-> ServerHello（Share ServerRandom ）
• 服务器->证书（共享证书，其中包含服务器公钥）
• 客户端-> KeyExchange（使用服务器公钥加密的共享Pre-Master Secret ）

现在，双方都拥有： ClientRandom ， ServerRandom它们是公共知识）和Pre-Master Secret仅通过非对称加密在网络上共享）。 只有证书的所有者才知道从网络通信中解密Pre-Master Secret所需的私钥，因此客户端验证服务器发送的证书非常重要。

DTLS确定用于产生方法Master Secret从Pre-Master Secret ， ClientRandom和ServerRandom并从对称加密/ MAC密钥Master Secret 。 DTLS使用Pre-Master Secret而不是直接共享Master Secret以获得模块化。 从安全角度出发，直接共享Master Secret应该同样安全。 从技术ClientRandom ， ClientRandom和ServerRandom在密钥生成中用作盐。 这保证了两个参与者在盐的密码安全性上都有发言权。

生成对称加密密钥后，参与者在结束握手之前会进一步验证他们可以使用它们进行通信。

使用CBC时，加密的数据包本身具有以下形式：

[ IV ] + encrypted( [ Data blocks ] [ HMAC ] [ Padding ] )

与每个数据包一起发送初始化向量会增加传输开销，但可以防御某些选定的明文攻击。 但是，这只是针对不同攻击的安全措施之一。 有效（D）TLS实施有很多不同的细微差别：忽略或隐藏错误情况，确保操作即使失败也会花费固定的时间，等等。

因此，虽然DTLS的安全思想可以概括为“与一个参与者共享公共密钥。通过非对称加密传输对称密钥。使用对称密钥对通信进行加密”，但还有很多小细节可以确保其安全性。 当人们发明自己的安全措施时，这些小细节通常会失败。

通过验证证书可以减少有效的MITM攻击-当然，在上述握手过程中，只有客户端才能验证服务器身份。 如果您需要服务器验证客户端身份，则客户端也需要发送自己的证书，依此类推。