Analysis of DTLS Implementations Using Protocol State Fuzzing

一、背景

IoT物联网设备数量大幅增加，这些设备间通信大部分使用UDP协议，但是UDP是无连接不可靠的，如何保证安全性呢？DTLS协议出现，这是一种适应UDP的安全协议。

大量设备上的软件采用DTLS协议工作，如何测试这些使用DTLS协议的软件呢？

二、贡献

1. 使用DTLS功能扩展TLS-Attacker，并使用它为DTLS服务器实现协议状态模糊化平台。
2. 为十三个DTLS服务器实现（包括最常用的DTLS服务器实现）提供Mealy机器模型，并提供探索大多数密钥交换算法和客户端证书身份验证设置的模型。
3. 分析学习到的模型，并报告DTLS实现中的几个不一致性错误和一些安全漏洞。其中一些漏洞也会影响这些库的TLS部分。

三、相关知识点

1. UDP

传输层协议，不可靠服务，优势：

• UDP无连接，时间上不存在建立连接需要的时延。空间上，TCP需要在端系统中维护连接状态，需要一定的开销。此连接装入包括接收和发送缓存，拥塞控制参数和序号与确认号的参数。UCP不维护连接状态，也不跟踪这些参数，开销小。空间和时间上都具有优势。

DNS如果运行在TCP之上而不是UDP，那么DNS的速度将会慢很多。HTTP使用TCP而不是UDP，是因为对于基于文本数据的Web网页来说，可靠性很重要。

• 分组首部开销小，TCP首部20字节，UDP首部8字节。
• UDP没有拥塞控制，应用层能够更好的控制要发送的数据和发送时间，网络中的拥塞控制也不会影响主机的发送速率。某些实时应用要求以稳定的速度发送，能容忍一些数据的丢失，但是不能允许有较大的时延（比如实时视频，直播等）
• UDP提供尽最大努力的交付，不保证可靠交付。所有维护传输可靠性的工作需要用户在应用层来完成。没有TCP的确认机制、重传机制。如果因为网络原因没有传送到对端，UDP也不会给应用层返回错误信息
• UDP是面向报文的，对应用层交下来的报文，添加首部后直接乡下交付为IP层，既不合并，也不拆分，保留这些报文的边界。对IP层交上来UDP用户数据报，在去除首部后就原封不动地交付给上层应用进程，报文不可分割，是UDP数据报处理的最小单位。

UDP常用一次性传输比较少量数据的网络应用，如DNS,SNMP等，因为对于这些应用，若是采用TCP，为连接的创建，维护和拆除带来不小的开销。UDP也常用于多媒体应用（如IP电话，实时视频会议，流媒体等）数据的可靠传输对他们而言并不重要，TCP的拥塞控制会使他们有较大的延迟

2. TLS

特点：无状态性和固有的不可靠性(122条消息) TLS 详解_summer_west_fish的博客-CSDN博客_tls

3. DTLS

DTLS协议由两层组成: Record 协议 和 Handshake 协议

Record 协议: 使用对称密钥对传输数据进行加密，并使用 HMAC 对数据进行完整性校验，实现了数据的安全传输。

Handshake 协议：使用非对称加密算法，完成 Record 协议使用的对称密钥的协商。

TCP之上的应用可以用TLS来保证安全，但是TLS不能用来保证UDP的安全。其提供了UDP 传输场景下的安全解决方案，能防止消息被窃听、篡改、身份冒充等问题。

DTLS是TLS的一个改编版本，用于数据报传输层协议。它目前有两个版本：DTLS 1.0，基于TLS 1.1; DTLS 1.2，基于TLS 1.2。

TLS 建立于TCP可靠的传输机制之上，而DTLS基于UDP，必须自建保障机制： 
DTLS 必须检测MTU大小，当应用层数据包超过时报错； 
为防止握手的IP数据包超载导致丢失，DTLS 针对握手消息实现fragment处理。

TLS 在传输出错时会中断连接，而DTLS需兼容多种出错场景，出错时往往直接丢弃处理；

 

DTLS和TLS都有两个主要模块

（1）握手handshake负责协商会话密钥和加密算法，并且密钥协商基于公钥加密（标准情况）或基于预共享密钥。要使用的算法集在密码套件中指定。(2)记录层将接收到的明文数据流拆分为DTLS记录。握手消息也作为记录（通常未加密）发送，在握手中发送ChangeCipherSpec消息后，所有后续记录的内容都使用协商的会话密钥加密，其中两个通信方使用不同的密钥。

DTLS握手中数据可能超过UDP限制的1500bytes，所以DTLS引入分段机制。

本文的DTLS测试框架扩展了TLS-Attacker，支持DTLS 1.0和DTLS 1.2。此扩展允许TLSAttacker生成、发送和接收DTLS数据包，更广泛地说，允许TLSAttacker执行有效和无效的DTLS流。我们的实施涉及几个变化，其中我们提到：i）增加了对DTLS握手消息分段的支持; ii）用于存储服务器cookie的客户端你好消息的新字段; iii）TLS上下文的新字段，一个用于存储接收到的cookie，其它字段用于跟踪记录历元和消息序列号（在章节5.2中解释了如何更新这些字段）;以及iv）用于重传和分段处理的新选项。

4.Mapper

下图中的MAPPER充当将输入符号从学习算法已知的有限字母表变换为发送到SUT的实际协议消息的测试工具，还将来自SUT的输出翻译成学习算法已知的输出符号的字母表。MAPPER还保持对学习算法隐藏的状态，但是需要提供消息参数;这可以包括序列号、约定的加密密钥等。输入字母表的选择和映射器的设计需要关于被测试协议的域特定知识。一旦实现了映射器，模型学习就完全自动地进行。

5. HandShake协议

 

DTLS握手。加密的消息在大括号内。可选消息位于方括号内。特定于DTLS的消息显示为蓝色。

客户端通过发送ClientHello来启动通信，ClientHello包括支持的最高DTLS版本号、随机现时数、客户端支持的密码套件以及可选扩展。在DTLS中，服务器使用HelloVerifyRequest消息进行响应，该消息包含一个无状态cookie。此消息提示客户端重新发送ClientHello消息，然后该消息将包含无状态Cookie，并尝试防止拒绝服务攻击

6. Record Layer

DTLS中的所有消息都被包装在所谓的记录中。在第一次DTLS握手期间，记录层在时期0操作。此epoch编号包含在DTLS记录的标题中。如果加密密钥已经通过发送ChangeCipherSpec被协商和激活，则记录层将epoch编号增加到1，这指示实际记录的内容被加密。由于握手可以重复几次（重新协商），所以epoch编号也可以进一步增加。

TLS具有隐式序列号，而DTLS具有显式序列号。这是必需的，TLS协议不保证消息到达，因此不能保证隐式计数器同步。在每个epoch开始时，序列号被重置为0，并且对于每个新记录，序列号增加。由于UDP数据包丢失而重新发送记录仍然会增加序列号。

7. Merly Machine

Mealy机是具有有限字母表的输入和输出符号的有限状态自动机。它们被广泛用于对协议实体的行为进行建模。从初始状态开始，它们一次处理一个输入符号。每个输入符号触发输出符号的生成，并使机器进入新的状态。

本文中为了推断实现的Mealy机器模型，使用模型学习，只需知道输入和输出，文章中使用TTT算法。

模型学习算法以两个交替的阶段操作：假设构建和假设验证。在假设构造期间，所选输入符号序列被发送到SUT，观察响应时生成了哪些输出符号序列。输入序列的选择取决于观察到的对先前序列的响应。当满足一定的收敛准则时，学习算法构造一个假设，该假设是与迄今为止记录的观测一致的最小确定性Mealy机。这意味着对于已经发送到SUT的输入序列，该假设产生与从SUT观察到的输出相同的输出。对于其它输入序列，该假设通过从记录的观测值外推来预测输出。为了验证这些预测与SUT的行为一致，学习然后移动到验证阶段，其中SUT经受一致性测试算法，该一致性测试算法旨在验证SUT的行为与假设一致。如果一致性测试发现了反例，即：如果SUT和假设在输入序列上不一致，则重新进入假设构建阶段，以便构建更精确的假设，该假设也考虑所发现的反例。如果没有找到反例，学习终止并返回当前假设。这不是SUT符合假设的绝对保证，尽管许多一致性测试算法在一些技术假设下提供了这样的保证。如果假设构造和验证的循环没有终止，则这指示SUT的行为不能被有限Mealy机器捕获，该有限Mealy机器的大小和复杂性在所采用的学习算法的范围内。

 

SUT，是一个DTLS服务器实现

MAPPER，将这些输入转换成完整的DTLS记录，并通过数据报连接将它们发送到SUT。然后映射器捕获SUT的回答，将其翻译成输出符号的字母表中的符号，并将它们传递回学习器。

learner，使用从交换的输入和输出符号序列中获得的信息来生成Mealy机。

图2中的MAPPER充当将输入符号从学习算法已知的有限字母表变换为发送到SUT的实际协议消息的测试工具，还将来自SUT的输出翻译成学习算法已知的输出符号的字母表。MAPPER还保持对学习算法隐藏的状态，但是需要提供消息参数;这可以包括序列号、约定的加密密钥等。输入字母表的选择和映射器的设计需要关于被测试协议的域特定知识。一旦实现了映射器，模型学习就完全自动地进行。

三、挑战

复杂：DTLS基于UDP无连接协议工作，因此DTLS必须自己实现重发机制、为消息丢失、乱序和分段提供支持。

连接：不能简单通过关闭连接来终止正在进行的DTLS交互。DTLS允许接收到意外消息后也继续工作，因为消息可能是无序的，可以在中间重新开始并且成功完成。

相比TLS添加额外消息交换功能：用来抵御DoS攻击

四、方法

文章通过两种方式改善和避免一些复杂性：1）我们的测试工具不使用重新排序和分段，因此这不是我们学习模型的一部分。2)我们修改MAPPER以使握手能够“重新启动，”这具有减小学习模型的大小的附加副作用，因为成功的重新启动通常表现为向常规握手状态的反向转换.

实验

平台：13个不同的针对IoT或WebRTC设计的成熟通用库（我们提到它们中的一些是没有TLS组件的DTLS库，在此之前从未应用过状态模糊。）

内容：对于每个实现，我们将检查许多（通常是所有）受支持的密钥交换和客户端证书身份验证配置的组合

五、成果

1. JSSE的客户端身份认证旁路

JSSE中的完全客户端身份验证旁路，JSSE是Java标准版平台的默认TLS/DTLS库。该漏洞允许攻击者通过发送特殊的乱序DTLS消息向JSSE服务器验证自己，而无需向服务器证明他们知道所传输证书的私钥。这个错误尤其具有破坏性，因为它还影响到JSSE的TLS库。这大大增加了它的影响，因为JSSE的TLS库经常用于在网站或Web服务中使用智能卡对用户进行身份验证。

2. Scandium框架中的一个状态机错误

Scandium框架中的一个状态机错误允许我们在不发送ChangeCipherSpec消息的情况下完成DTLS握手。这导致服务器接受明文消息，即使协商的加密机制另有指示。请注意，这个bug类似于TLS JSSE实现中发现的EarlyFinished bug。

3. PionDTLS（WebRTC的Go实现）。

对这个错误的调查发现了一个更严重的问题，即一旦握手完成，PionDTLS服务器就会自由地处理未加密的应用程序数据

4. TinyDTLS（一个面向物联网设备的轻量级DTLS实现）中有三个已确认的功能缺陷。

六、总结

本文提出了第一个DTLS协议状态模糊化测试框架，开发了一个基于TLS-Attacker的DTLS测试框架，包括显式序列号、对cookie管理的支持等。本文发现了由有效握手消息序列触发的状态机错误，没有进行重新排序reorder和分割fragmentation。

下一步方向：

（i）探索记录层功能，例如分段和重新排序。由于这些功能应该由记录层透明地处理，我们可以直接使用我们已经学习的模型作为规范。

（ii）学习的模型可以用来支持无效输入消息的系统测试，如协议模糊器中所做的那样。

（iii）当前对学习模型的分析是手动执行的；下一步要研究模型检查技术的自动化方法。

github地址：assist-project/dtls-fuzzer: Protocol state machine learner and fuzzer for DTLS servers and clients (github.com)