PROSAGA码农传奇-区块链扩展技术-DTLS与使用JKS / JCE加密UDP数据报

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

作者: 荧惑
发布时间: 2025-02-06 12:20:15 (21天前)
转自：

<div class =“post-text”itemprop =“text”>
  
    这几乎听起来像是在尝试重新发明DTLS。你说DTLS有问题，但为什么会这样？
  
  
    从理论上讲，你的逻辑是合理的。它让我想起DTLS与RSA密钥交换：
  
  <UL>
    <LI>
      客户 - ＆gt; ClientHello（分享
       <code>
 ClientRandom
 </code>
      ）
    </LI>
    <LI>
      服务器 - ＆gt; ServerHello（分享
       <code>
 ServerRandom
 </code>
      ）
    </LI>
    <LI>
      服务器 - ＆gt;证书（共享证书，包含服务器公钥等）
    </LI>
    <LI>
      客户 - ＆gt; KeyExchange（分享
       <code>
 Pre-Master Secret
 </code>
       用服务器公钥加密）
    </LI>
  </UL>
  
    现在双方都有：
     <code>
 ClientRandom
 </code>
    ，
     <code>
 ServerRandom
 </code>
     这是公共知识和
     <code>
 Pre-Master Secret
 </code>
     仅通过非对称加密在网络上共享。只有证书的所有者知道解密所需的私钥
     <code>
 Pre-Master Secret
 </code>
     从网络通信，因此客户端验证服务器发送的证书是很重要的。
  
  
    DTLS确定生成方法
     <code>
 Master Secret
 </code>
     从
     <code>
 Pre-Master Secret
 </code>
    ，
     <code>
 ClientRandom
 </code>
     和
     <code>
 ServerRandom
 </code>
     和来自的对称加密/ MAC密钥
     <code>
 Master Secret
 </code>
    。 DTLS使用
     <code>
 Pre-Master Secret
 </code>
     而不是直接分享
     <code>
 Master Secret
 </code>
     用于模块化。从安全角度来看，分享应该同样安全
     <code>
 Master Secret
 </code>
     直。该
     <code>
 ClientRandom
 </code>
     和
     <code>
 ServerRandom
 </code>
     在技术上用作密钥生成中的盐。这保证了两个参与者在盐的加密安全性方面有发言权。
  
  
    生成对称加密密钥后，参与者在结束握手之前进一步验证他们是否可以使用它们进行通信。
  
  
    使用CBC时，加密数据包本身的形式为：
  
   <pre>
 <code>
 [ IV ] + encrypted( [ Data blocks ] [ HMAC ] [ Padding ] )

</code>
 </pre>
  
    向每个数据包发送初始化向量会增加传输的开销，但可以抵御某些选定的明文攻击。然而，这只是针对不同攻击的安全措施之一。有效（D）TLS实现中存在许多不同的细微差别：忽略或隐藏错误条件，确保操作即使失败也需要持续时间等。
  
  
    因此，尽管DTLS的安全理念可以概括为“向一个参与者共享公钥。使用非对称加密传输对称密钥。使用对称密钥加密通信”，还有更多小细节使其安全。当人们发明自己的安全措施时，这些小细节通常会失败。
  
  
    通过验证证书可以减少有效的MITM攻击 - 当然在上述握手中，只有客户端验证服务器身份。如果您需要服务器验证客户端身份，客户端也需要发送自己的证书等。
  
</DIV>