0

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

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

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

4

2 回答 2

1

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

理论上你的逻辑是合理的。它让我想起了带有 RSA 密钥交换的 DTLS：

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

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

DTLS 确定从 生成的Master Secret方法Pre-Master Secret，ClientRandom以及ServerRandom从Master Secret. DTLS 使用Pre-Master Secret而不是直接共享Master Secretfor 模块化。从安全的角度来看，Master Secret直接共享应该同样安全。ClientRandom和ServerRandom在技术上用作密钥生成中的盐。这保证了两个参与者在盐的加密安全方面都有发言权。

一旦生成了对称加密密钥，参与者将在握手之前进一步验证他们是否可以使用它们进行通信。

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

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

随每个数据包发送初始化向量会增加一些传输开销，但可以防御某些选择的明文攻击。然而，这只是针对不同攻击的安全措施之一。有效的 (D)TLS 实施有很多不同的细微差别：忽略或隐藏错误条件，确保操作即使失败也需要恒定的时间等。

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

通过验证证书可以减少有效的 MITM 攻击——当然，在上述握手中，只有客户端验证服务器身份。如果您需要服务器验证客户端身份，则客户端还需要发送自己的证书等。

于 2015-04-20T23:09:46.383 回答
1

主要的缺点是你自己想到的。一般来说，除非一个人实际上是密码学家，否则永远不要试图在密码学相关的事情上变得“聪明”或“创新” 。在工具、算法和攻击向量方面缺乏全面的经验，确保加密强度的最佳方法是使用经过良好测试的标准化工具。这意味着 DTLS。

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

于 2014-08-20T13:47:19.360 回答