一种增强的 DTLS 密钥交换协议

近年来像视频会议、Internet 电话和在线游戏等使用用户数据报（User Datagram Protocol，UDP）协议传输的应用程序越发流行。这些应用不仅延迟敏感，并且有安全传输需求。数据报安全传输（Datagram Transport Layer Security，DTLS）协议，提供了 UDP传输场景下的安全解决方案，能解决消息被窃听、篡改和身份冒充等问题 [2]。DTLS 协议在 UDP 提供的套接字（socket）之上实现了客户端与服务器双方的握手连接，并利用 cookie 验证机制和证书等实现了通信双方的身份认证，此外，通过在报文段头部加上序号，缓存乱序到达的报文段和重传机制实现了可靠传送 。DTLS 提供了椭圆曲线迪菲 - 赫尔曼（Elliptic Curve Diffie–Hellman，ECDH）和预共享密钥（Pre-Shared Key，PSK）两种密钥交换协议 。ECDH 密钥交换协议有效地防止了前向安全和后向安全攻击，但是涉及非对称计算和证书传输时，该协议对设备性能和网络带宽有较高要求 。PSK 密钥交换协议具备轻量、高效的优点，但是每次计算结果固定，一旦 PSK 泄露将丧失对信息的安全保护能力。本文提出了一种增强的密钥交换协议，即通信双方将 PSK 存储在密钥池中，使用时通过身份标识动态选取，使用后采取相同变换方式滚动更新PSK。该增加协议不仅具备了 PSK 密钥交换协议的优点，而且还实现了前向安全和后向安全，为应用数据在 UDP 上提供了安全可靠的传输保障。

１背景知识

1.1　DTLS 简介

DTLS 设计思想是构建数据报传输之上的传输层安全性协议（Transport Layer Security，TLS），具备与 TLS 同样的安全机制和防护等级。DTLS 的优势：在握手和数据传输过程中均采用 UDP 通道，使应用程序能轻松地管理套接字；采用一种简单轻量级重传机制实现会话建立的可靠性；提供公正、保密的数据传输通道保证数据的机密性和完整性，能够检测出被替代的数据包；部署在用户空间，不依赖于操作系统；语义上借鉴 TLS 优点，接口上模仿 UDP API；集成 TLS 特性，尽量避免引入未知脆弱性 。

如图 1 所示，DTLS 协议分为两层：上层包括握手、警告和应用数据 3 种协议；下层为记录层，该层承载上层协议信息。

图 1 DTLS 协议层次

记录层从上层接收数据后，首先进行分片、压缩、添加头部构成完整记录报文段，其次根据头部数据类型判断是否计算消息认证码（Message Authentication Code，MAC）和加密，最后调用 UDP的 socket 接口发送给对方。记录层仅对应用数据加密保护，因此，接收方在收到消息后，应先判断头部数据类型是否为应用数据：如果是，则进行解密并校验成功后再将明文数据传送到上层协议进行处理；如果不是，则直接将数据传送到上层协议进行处理。

1.2　DTLS 握手流程

DTLS 握手流程和 TLS 基本上保持一致。与之相比，DTLS 面临如下问题：（1）握手消息必须按照定义好的顺序传输和接收，任何一步没有跟上步调都会导致失败，这是因为 DTLS 运行在不可靠的数据报通信之上，不能保证数据传输过程中的按序接收和不丢失。（2）握手消息的长度可能超过传输的最大传输单元（Maximum Transmission Unit，MTU）值，将导致在 IP 层分片；（3）相对传输控制协议（Transmission Control Protocol，TCP）来说，UDP 连接对拒绝服务（Denial of Service，DoS）攻击更加敏感 。

为了解决这些问题，DTLS 提供的防护机制具体如下文所述。

1.2.1　超时和重传

DTLS 采用了简单的重传机制来确保握手消息正确到达对方，消息可以整合到一系列消息航程（Flight）中。虽然每次消息航程的传送可能由多个消息组成，但在超时和重传的角度上，它们应当被看作一个整体。例如，客户端第一次传输ClientHello 消息完毕后，就等待接收来自服务器的HelloVerifyRequest，如果服务器发送的消息丢失，客户端就知道 ClientHello 或 HelloVerifyRequest 丢失了，必须进行重传，当服务器收到重传的消息时，它必须重传自身发送的 HelloVerifyRequest。服务器方不主动进行超时和重传，因为这样需要维护多个客户端的状态，会加重服务器的负担。

1.2.2　重排序

为保证握手消息按序传输，每个握手消息包含了一个序列号 message_seq，当对端收到一个握手消息时，它能快速确定这个消息是否是所期望接收的下一个消息。如果是，它会进行处理；如果不是，它会将其放入队列中，在将来收到所有缺失的消息后再进行处理。

1.2.3　消息分片与重组

理论上一个握手消息可能接近字节， 而 UDP 传输数据量往往限制于 MTU 大小，一般为1 500 字节。DTLS 通过在握手格式中增加 fragment_offset 和 fragment_length 实现对握手消息分段处理。握手消息如果没有分片时，fragment_offset=0，fragment_length=length；如果分片，每个分片使用相同的 message_seq。其中，fragment_offset 包含以前分片的长度，fragment_length 表示本分片的数据长度，接收方必须要实现数据包的缓存和重组。

1.2.4　DoS 攻击

DTLS 采用和密钥交换协议（Internet Key Exchange，IKE） 一 样 的 无 状 态 cookie 技 术， 并 且 增 加HelloVerifyRequest 用于服务器对客户端的二次校验，避免 DoS 攻击。当客户端首次给服务端发送ClientHello 时，携带的 cookie 为空值；然后，服务器接收到 ClientHello，检验报文段中的 cookie 值是否为空，如果为空，则说明之前没有建立过连接，服务器根据客户端的 IP 地址通过哈希方法随机生成一个 cookie，并填入 HelloVerifyRequest 中发送给客户端，此时服务器不会执行分配缓冲区等操作；接 着 客 户 端 将接 收 到 的 cookie 值 填 入 ClientHello中，再次向服务器发送该报文；最后服务器检验ClientHello 里面的 cookie 值是否和之前发给该客户端的 cookie 值完全相同，若是，则通过 cookie 验证，继续进行握手连接，若不是，则拒绝建立连接。

２现有密钥交换协议

2.1　基于 ECDH 的密钥交换协议

ECDH 密钥交换协议可以使通信双方在完全没有对方任何预先信息的条件下，通过不安全的信道创建一个密钥。即使密钥交换过程中被全程偷窥，攻击者也无法知道双方协商出的密钥。它虽然可以对抗偷窥，却无法对抗篡改，自然也就无法对抗中间人攻击（Man-in-the-MiddleAttack，MITM）。为了避免遭遇此类攻击，ECDH 需要与 RSA、DSA、ECDSA 等签名算法配合，来进行身份认证。密钥交换流程如图 2 所示。

图 2 基于 ECDH 的密钥交换流程

（1）服务器先在 Certificate 报文中填写自己的证书；然后生成一个随机数作为自己的临时私钥并计算出临时公钥，在 ServerKeyExchange 报文段中填写所选用的椭圆曲线参数和临时公钥，用摘要算法对 ServerKeyExchange 报文段计算摘要，并用私钥和ECDSA 算法进行数字签名，将签名结果写入该报文段的末尾；最后将 Certificate、ServerKeyExchange、ClientCertificateRequest 和 ServerHelloDone 发送给客户端。（2）客户端从 Certificate 报文段中提取证书并验证服务器身份；从 ServerKeyExchange 报文段中提取出签名结果，用服务器证书公钥进行 ECDSA签名验证：若两次验证通过，继续进行握手连接；若没有验证通过，则终止握手连接。（3）客户端生成一个随机数作为自己的临时私钥并计算出临时公钥；在 ClientKeyExchange 报文段中填写自己的临时公钥。（4）客户端使用自己的临时公 / 私钥、自己的证书公 / 私钥、服务器证书公钥和服务器临时公钥计算预主密钥；使用伪随机函数（Pseudo Random Function，PRF），以预主密钥和双方产生的随机数为参数计算会话密钥。（5）客户端将 Certificate（包含有自己的证书）、ClientKeyExchange 和 Finished 报文发送给服务器。（6） 服 务 器 从 Certificate 报 文 段 中 提 取 证书 并 验 证 客 户 端 身 份：若 验 证 通 过， 继 续 进 行握 手 连 接；若 不 是， 则 终 止 握 手 连 接。然 后 从ClientKeyExchange 中提取出客户端临时公钥；使用自己的临时公 / 私钥、自己的证书公 / 私钥、客户端公钥、客户端临时公钥计算预主密钥；以相同方式计算会话密钥；验证客户端 Finished 报文成功后再发送自己的 Finished 报文。

2.2　基于 PSK 的密钥交换协议

PSK 方式是最古老的一种密钥交换和认证方式。它预先让通信双方共享一些密钥。这些密钥在DTLS 连接尚未建立之前，就已经部署在通信双方的系统内了。对于 PSK 密钥交换协议来说，验证对方的通信身份非常关键。所以通信双方会在本地存取对方的身份标识，如 psk_id、psk_id_length，并通过比较收到的报文段中的 psk_id 和 psk_id_length 与本地存储的是否完全一致来进行身份的验证。密钥交换流程如图 3 所示。

图 3 基于 PSK 的密钥交换流程

（1）服务器在 ServerKeyExchange 报文段填写自己的 psk_id 和 psk_id_length 后发送给客户端。（2）客户端在 ClientKeyExchange 报文段填写自己的 psk_id 和 psk_id_length 后发送给服务器。（3）客户端和服务器分别验证对方身份，只有 psk_id 和 psk_id_length 与本地存储的完全一致才会进行后面的通信。（4）双方以 PSK 和双方各自产生的随机数为参数计算预主密钥，使用 PRF，再以双方随机数和预主密钥为参数计算会话密钥。（5）双方通过 Finished 报文完成身份验证，验证成功才会进行后面的业务数据通信。

2.3　两种密钥交换协议

分析在面临网络偷窥攻击时，ECDH 方式网络上传输的是 ECDH 算法参数、双方证书和临时公钥。攻击者可以通过监视网络得到这些信息，但是由于无法推算出双方私钥，也就无法推算出会话密钥。PSK 方式网络上传输的是 PSK 身份标识，攻击者即使监视了全过程，也无法知晓 PSK 密钥数据。因此，这两种方式都有效地防范了信息被偷窥。

在面临篡改攻击时，如果攻击者在 ECDH 方式的 ServerKeyExchange 报文中篡改了算法参数或服务器临时公钥 , 会被客户端发现，这是因为这些信息已经由服务器的证书私钥签名。如果攻击者在ECDH 方式的 ClientKeyExchange 报文中篡改了客户端临时公钥，虽然这一步没有进行客户端证书私钥签名，服务端收到数据后暂时不会发现信息被篡改，但是，攻击者的篡改会导致服务端与客户端生成的会话密钥不一致，在后续的 Finished 步骤中验证失败。如 果攻击者在 PSK 方式的 ClientKeyExchange报文中篡改了身份标识（psk_id，psk_id_length），服务端要么发现 ID 无效，要么得到的 ID 与客户端不一致，在后续的 Finished 步骤中验证失败。因此，这两种方式都有效地防范了信息被篡改。在面临前向和后向攻击时，ECDH 方式的通信双方都临时产生了一对临时公 / 私钥，并且自己的临时公 / 私钥和对方的临时公钥都作为了 ECDH 算法参数，所以每次产生的预主密钥均不一样，且各个计算结果之间没有相关性。因此，ECDH 方式能够抵御对前向和后向攻击。PSK 方式的通信双方共享的 PSK 数据长期稳定不变。如果攻击者拿到了 PSK，就可以用这个密钥得到会话密钥，然后用会话密钥加解密整个会话阶段的应用数据。因此，PSK 方式无法解决前向和后向攻击问题。一旦 PSK泄露，历史的通信数据将面临严重的安全风险。如果攻击者持续进行网络监听，未来的通信数据也将完全暴露于攻击者。在性能和资源消耗方面，ECDH 方式的通信双方需要传输各自的证书，如果该证书存在多级根证书的话，就需要传输根证书，这将导致传输开销非常大，此外，ECDH 算法和签名算法由于其复杂性，不仅运行速度慢而且对 CPU 性能要求高。ECDH 方式适用于安全级别高、网络带宽大和设备性能好的场景。PSK 方式的服务器为客户端预置了密钥，仅凭一个 ID 信息便可快速完成信息交换和身份认证，极大简化了密钥交换过程。PSK 方式节省了设备运行和数据传输开销，具备一定的通用性，适用于对资源要求低或者耗时敏感的场景。

３增强的密钥交换协议

本文在 PSK 密码交换协议基础上，考虑在通信双方部署不同的 PSK 密钥池，客户端动态选取 PSK与服务器完成身份认证和密钥交换，通信双方对每次使用后的 PSK 采用相同的变换方式产生新的密钥数据。该增强的密钥交换协议既有效地防范了网络偷窥、身份假冒等攻击，又具备 CPU 耗时少、网络资源占用小的特点。

3.1　增强密钥交换流程

增强的密钥交换流程如图 4 所示。和基于 PSK 的密钥交换协议相比，该协议在如下几个方面有所增强：（1）服务器在 ServerKeyExchange 报文段填写支持的身份标识列表后发送给客户端；（2）客户端提取出服务器身份标识列表，与自己密钥池进行比较验证服务器身份，验证成功后，在服务器身份列表中动态选取一个 PSK，将其身份标识填写到 ClientKeyExchange 报文段中后发送给服务器；（3）客户端和服务器双方在计算出会话密钥后，采用相同的方式滚动变换 PSK 密钥数据。

图 4 增强的密钥交换流程

3.2　密钥池存储

为了防止密钥池中的数据被窃取和篡改，需要进行加密和完整性保护。一般情况下，采用对称算法实现加密，采用杂凑算法实现完整性功能。对称算法最早有电子密码本（Electronic Code Book，ECB）、密码分组链接（Cipher Block Chaining，CBC）、密码反馈（Cipher Feed Back mode，CFB）、输出反馈（Output Feed Back Mode, OFB）等几种分组模式，但都陆续被发现有安全漏洞，现在基本都不再使用。最新的分组模式被称为带有关联数据的认证加密（Authenticated Encryption with Associated Data，AEAD），在加密的同时增加了认证功能，常用的 是 伽 罗 华 / 计 数 器 模 式（Galois/Counter Mode，GCM）、密码块链消息认证码（Counter with Cipher Block Chaining-Message Authentication Code，CCM）和 Poly1305。通信双方可以使用对称算法的AEAD 模式对密钥池进行加密认证，这样既节省了再次使用杂凑算法带来的开销，又避免了 BEAST、Lucky 13 和 POODLE 等攻击，具备较强的安全性。用于密钥池加密认证的密钥 Key 只有客户端和服务器知道。服务器可以为不同的客户端设置不同的Key，这样即使某个客户端 Key 发生泄露，只会对该客户端 PSK 信息造成安全隐患，这种隐患不会波及整个密钥池。如果客户端与用户绑定，可以通过用户指纹、面容等生理特征产生密钥 Key；如果客户端与设备绑定，可以通过设备硬盘序列号、网口介质访问控制（Media Access Control，MAC）地址等特征产生密钥 Key。该密钥 Key 只能在使用时产生，不能保存在本地，且只能用于密钥池加密，不能再有其他用途。

3.3　PSK 动态选取

在密钥交换过程中，客户端动态选取该次连接使用的 PSK。动态选用应该做到随机性和平均性。rand 函数可以用来产生随机数，但是这不是真正意义上的随机数，是根据一个随机种子为基准以某个递推公式推算出来的一系列数。当这个系列数很大的时候，就符合正态分布，从而相当于产生了随机数。但这是个伪随机数，当取数的次数大于随机数周期时，得到的结果就会重复出现。为了增加随机性，可以先使用当前时钟为参数调用 srand 函数产生不同的随机种子，因为每次运行程序的时间都不相同。无论什么时候，都可以给 srand 提供一个新的种子，从而进一步随机化 rand 输出结果。客户端为每个 PSK 增加使用次数属性，首先通过时钟、srand 和 rand 函数产生 PSK 在密钥池中的索引，其次查看该索引对应的密钥使用次数，判断该密钥是否被频繁使用：如果是，则重新产生索引；如果不是，就使用该密钥，使用次数加 1。

3.4　PSK 滚动更新

每次计算出会话密钥后，客户端和服务器将以相同的方式对 PSK 密钥数据进行滚动变换，将变换后的数据保存在密钥池中。由于 UDP 数据报对时间敏感，滚动变换过程不能过于复杂，需要满足耗时少、开销小的要求。因此，可以使用当前的 PSK密钥数据、握手信息和特定盐值为参数，调用不可逆函数 PRF 进行计算，截取部分结果作为新密钥。

3.5　安全性分析

假设攻击者窃取了某次连接的 PSK 和存储了通信的历史数据，包括握手阶段和业务通信阶段的数据。若两次连接选用了不同的预置密钥（身份标识ID 不相同），则他无法通过手中的 PSK 得到历史PSK，也就无法解密历史数据；若两次连接选用了相同的预置密钥（身份标识 ID 相同），由于他手中的 PSK 是历史 PSK 通过不可逆函数计算得来的，反向推算出历史 PSK 的可能性很小，仍然无法解密历史数据。因此，该增强密钥交换协议实现了先前安全性。假设攻击者窃取了某次连接的 PSK 且继续进行网络窃听，在某次新连接中，客户端和服务器采用了与失泄连接相同 ID 的预置密钥。由于新连接的PSK 已经在失泄连接的 PSK 基础上进行了滚动变换，只要特定盐值（SALT）不丢失，攻击者手中的PSK 就无法计算出正确的新 PSK，也就无法解密新连接中的通信数据。因此，该增强密钥交换协议降低了后向安全攻击的风险，具有一定的后向安全性。

４结　语

DTLS 是用于 UDP 传输过程的加密协议，保证了采用数据报传输的应用程序间的数据安全性。本文详细描述了基于 ECDH 和 PSK 两种密钥交换协议，分析了这两种协议在安全性和适用性方面的优缺点，虽然它们都能够有效地防止偷窥、身份假冒攻击，但是都存在一些缺陷。基于 ECDH 密钥交换协议在预主密钥计算中引入了随机数，因而具有前向安全和后向安全性；但是涉及非对称计算和证书传输，因而速率慢、资源消耗大。基于 PSK 密钥交换协议仅交换身份标识，因而速度快、资源消耗小；但是密钥数据长期不变，无法防范前向和后向安全攻击。本文提出的增强密钥交换协议具备了 PSK 密钥交换协议的优势，同时采取了密钥池存储多个PSK、使用时动态随机选取和使用后滚动更新的措施，解决了前向安全和后向安全攻击问题。由于本协议对服务器存储能力有较高要求，可以在下一步的工作中解决密钥池高效存储问题。

引用本文：黄劲松 , 代霞 . 一种增强的 DTLS 密钥交换协议 [J]. 通信技术 ,2022,55(2):229-235.