动态主机设置协议（DHCP, dynamic host configuration protocol）简化了访问网络的配置过程，方便了网络管理员对IP地址的管理，有效缓解了由于IPv4地址不足所导致的问题，但DHCP所受到的安全威胁也越来越严重，它在设计之初并未充分考虑安全问题。当互联网呈现高移动特性时，需由配套的安全协议来保障DHCP安全，其中防范中间人攻击成为DHCP 安全保障体系中最重要的问题^[1-2]。中间人攻击是指敌手隐藏在 2 个或多个受害者之间，利用欺骗、冒充等手段截取信道中的数据，破坏数据的机密性、完整性和可用性^[3]。如图1所示，当2个受害者开始传输公钥M₁和M₂而被敌手截获并替换成M'₁和M'₂时，敌手冒充受害者参与通信。这种类型的攻击由来已久，理论上可以发生在每一次的信息交互中，既可以独立的攻击方式造成危害，也可作为实施更高级攻击之前的准备。例如在当前快速发展的 5G 或 6G 网络时代，自动驾驶和车路协同应用场景网络部署具有广泛密集与异构融合的特点，相关设备均具有高移动性，将会在不同制式的开放网络下频繁切换配置信息，这对DHCP的安全性和效率都提出了更高的要求。

为此，本文研究一种轻量化的DHCP安全方案，防止恶意的第三方攻击，同时考虑效率和开销并兼容原有协议，做到在原有基础设施上的有效部署和运行。随着互联网协议第6版（IPv6, Internet protocol version 6）应用进程，所提方案可兼容IPv6的部分场景，实现DHCP第4版（DHCPv4）到DHCP第6版（DHCPv6）的平滑演进。所提方案分为2个部分：执行协议前的实体认证与密钥协商，以及协议主体中的消息认证。前者利用密码学理论进行身份认证并产生会话密钥，后者通过密钥生成相关签名以保证消息的完整性和可用性。此外，所提方案在提供目标安全的前提下考虑协议执行效率，以达到轻量化的目的。本文的主要贡献总结如下。

1) 提出一种轻量级的安全DHCP，实体间的双向认证可以抵抗中间人攻击，数字签名可以确保消息的完整性和合法性。此外，该协议可以同时兼容DHCPv4与DHCPv6设置。

2) 分析协议安全性，经分析该协议可以有效抵御中间人攻击、参数窃取攻击，并能防止前后密钥泄露。实验结果表明，该协议相较于现有方案具有更高的执行效率。

DHCP所面临的中间人攻击通常是恶意的服务器给出错误的配置信息，使客户机所得到的服务降级，或是重定向流量为更高级的攻击做准备；也可以是恶意的客户机非法占用服务器的网络资源，使合法客户机无法进行正常的网络活动。国际互联网工程任务组在DHCP中加入了身份验证选项^[4]，为DHCP身份验证提供了2种方法：延迟身份认证和配置令牌，但是前者容易受到拒绝服务攻击且不能用于域间认证，后者存在大量的密钥管理问题且未得到广泛使用。文献[5]提出 S-DHCP 方案来强化DHCP的安全性，通过综合运用椭圆曲线密码技术、单向哈希函数与数字签名技术，提供消息认证和实体认证，但该方案基于一个预共享的秘密，与延迟认证没有本质区别，同样存在密钥的管理问题，还需配合传统安全信道，影响效率与增加成本，并且在密钥协商阶段缺少服务器对发起者的身份验证以及对消息新鲜性的检测，容易遭受重放攻击及其带来的拒绝服务攻击。文献[6]提出应用椭圆加密曲线提高DHCP保护程度的方法，包括密钥协商算法、消息验证码和消息令牌来保证完整性、防止重放攻击。文献[7]的安全认证模型OTP_SAM结合当前系统时间来计算一次性密钥，利用哈希算法生成消息认证码，通过验证Option字段中的认证码进行安全认证；该模型具有良好的兼容性，不用修改原数据分组长度，客户机可以自主选择是否开启该模块功能，但是基于时间的会话密钥要求客户机与服务器的时钟同步，其实现条件较高。

另一类 DHCP 安全方案不采用 DHCP 验证选项。如文献[8]提出基于公钥密码学和数字证书的认证方案，使用不同的密钥长度配合不同的证书类型测试通信开销和处理时间，但客户机无法检测服务器的证书撤销状态。文献[9]提出针对耗竭攻击的检测方案，通过收集正常时段DHCP请求的概率分布作为标准来检测异常情况，但对异常数据敏感，易出现误报现象。文献[10]收集和标记DHCP欺骗产生的网络流量，为定量分析提供了数据支持，并讨论若干欺骗攻击行为引起的流量异常表现。文献[11]提出一种基于隐马尔可夫模型的恶意域名检测方案，配合Baum-Welch算法和 Viterbi 算法的马尔可夫模型可以快速准确分类未知域名，从而实现有效检测，然而，因训练数据的随机性和不确定性，建模过程中容易产生误差。

综上所述，现有方案普遍存在难以部署、与原始协议不兼容以及密钥管理等问题，本文方案将针对这些问题展开研究，并在满足目标安全性的前提下提升方案效率，以达到轻量化的目的。

本节主要描述方案的威胁模型和设计目标。首先，本文方案考虑4种类型的安全威胁。

1) 恶意服务器攻击。敌手假冒合法的DHCP，服务器向客户机提供虚假的网络配置，从而使客户机服务降级，无法正常享受网络服务；或借此重定向客户机流量到非法的钓鱼网站，为进一步的攻击做准备。

2) 恶意客户机攻击。敌手假冒合法的客户机向DHCP服务器请求配置相关参数，从而非法占用网络服务；或进一步发动耗竭攻击耗尽服务器有限的IP地址，使合法客户机无法享受网络服务。

3) 参数窃取攻击。敌手攻击服务器并窃取数据库中的客户端信息，例如网络标识、密码与验证参数等，最后尝试使用这些信息冒充合法客户机。

4) 前/后向安全威胁。对应到本文场景指的是，当会话密钥泄露时，敌手以此推算出上一个会话密钥或下一个会话密钥，同时获得受其保护的内容。

其次，本文方案旨在实现3个方面的设计目标。

1) 安全目标。方案要能抵御威胁模型中定义的攻击类型。

2) 效率目标。在达到安全目标的前提下，较同类型方案具有更高的执行效率。

3) 兼容目标。方案要与 DHCP 原始协议具有良好的兼容性，具体表现在：①满足协议基本格式要求；②不引入新的状态、消息类型和参与方；③方案部署后可选择是否启用。

本节主要构造一种防范DHCP攻击的密钥协商算法，包括系统初始化、客户机注册和密钥协商等过程。在此之前，介绍该算法涉及的主要符号和含义，如表1所示。

1) 系统初始化

① 椭圆曲线初始化。选定2个大素数p和q，构造有限域F_p上的椭圆曲线y²= x³+ ax + b，其中a、b满足4a³+27b²≠0(mod p)，选定阶为q的基点 P 构成加法循环群 G，选择单向函数$H_i:\{0,1\}*\times G\to Z_q^{*}$。

② 系统参数初始化。选择服务器S_i的私钥$S_s\in Z_q^{*}$，计算公钥S_p。

2) 客户机注册

① 客户机发出注册申请。客户机或网络管理员为客户机U_i选择网络标识ID_i，客户机选择部分私钥$x_i\in Z_q^{*}$，计算部分公钥 X_i以及${\beta }_{U_i}$，并将$\left\{{\text{ID}}_i\text{,}\mathrm{MAC}\text{,}{\beta }_{U_i}\right\}$发送给服务器S_i，其中 MAC 是设备的物理地址。客户机可以通过广播同时向多个服务器注册，也可以按照优先级向指定的服务器注册。

② 服务器验证注册信息。服务器收到消息后先判断是否注册过，有则跳过，没有则选择随机数$c_1\in Z_q^{*}$，并计算$A_{U_i}$和$M_{U_i}$ ，存储$\{{\mathrm{ID}}_i,\mathrm{MAC}\text{,}{c}_1\}$，同时将$\left\{S_i\text{,}{M}_{U_i}\text{,}{A}_{U_i}\right\}$发送给客户机。

③ 客户机对服务器进行反向验证。客户机在收到回复后首先判断$A_{U_i}$是否是新鲜的，接着验证等式$M_{U_i}P=H_2(A_{U_i},\beta {}_{U_i})S_p\mathrm{mod}q+A_{U_i}$ 是否成立，若验证失败，则重新申请；若验证成功，则结合2个部分私钥计算客户机的完整私钥d_i和公钥D_i，存储$\left\{S_i\text{,}{A}_{U_i}\right\}$注册成功。

客户机注册过程如图2所示。

3) 密钥协商

① 客户机发起协商申请。客户机选择随机数$c_2\in Z_q^{*}$，计算参数 cd、$F_{U_i}$ 以及 k₁，同时将${\text{ID}}_i\text{,MAC,cd,}{F}_{U_i}$发送给服务器。

② 服务器验证客户机信息。服务器在收到客户机的协商请求后首先判断$F_{U_i}$是否是新鲜的，接着验证等式$\text{cd}P=D_i+F_{U_i}$是否成立，若不成立，则拒绝；若成立，则接收并计算k₂，同时选择随机数$c_3\in Z_q^{*}$，并计算Auth₁，存储${\text{{ID}}_i\text{,MAC,}{F}_{U_i}\text{}}$，然后将$\text{{}{S}_i\text{,}{c}_3{\text{,Auth}}_1\text{}}$发送给客户机。

③ 客户机对服务器进行反向验证。客户机在接收到服务器发来的信息后，首先验证${\mathrm{Auth}}_1=c_2{c}_3{S}_p$是否成立，若不成立，则重新发起申请；若成立，则计算sk _A以及Auth₂，并将{Auth₂}发送给服务器。

④ 服务器进行最后确认。服务器验证${\text{Auth}}_2=H_3(1,{\text{ID}}_i,S_i,k_2)$是否成立，若不成立，则拒绝；若成立，则计算sk_B。协商完成，协商所产生的会话密钥为${\text{sk}}_A{\text{=sk}}_B$。

协商过程如图3所示。

为使新的方案能够匹配现行 DHCP，需遵循RFC 3118中定义的认证选项格式^[4]，因此，在本文方案应用时将Protocol字段置为6，并将Algorithm置为8，同时将验证信息附加在options180中，采用默认RDM（replay detection method）字段值，RD （replay detection）字段使用计数器模式来抵抗重放攻击。此外，设置签名默认长度为256 B，满足DHCP长度限制^[12,13,14]。

出于兼容DHCPv4与DHCPv6的考虑，方案应遵循RFC 3315中的相关定义。DHCPv6是DHCP针对 IPv6 的改进，IPv6 地址分配方式大致可以分为 2种：无状态地址自动配置和有状态地址自动配置^[15]。DHCPv6 是一种有状态地址自动配置协议^[16]，在配置过程中服务器分配一个完整的 IPv6地址给主机，并提供 DNS 服务器地址等其他配置信息，将分配的地址与客户机进行绑定，从而增强了网络的可管理性。DHCPv6协议下客户机与服务器的交互分为4步交互与2步快速交互，其报文与DHCPv4类似，具有对应关系^[17]。

当客户机与服务器完成第4节的注册与密钥协商过程，生成sk _A与sk_B后便可发起 DHCP 服务，如图4所示，详述过程如下。

① 客户机发起 DHCP 请求。客户机发送Discover/Solicit 报文，并在报文的相关字段中表明启用本文方案，要求服务器进行消息认证；如果客户机启用2步快速分配，则还需在报文中携带Rapid Commit选项（仅在DHCPv6中）。

② 服务器处理客户机请求。收到报文的服务器首先判断客户机选择的请求方案，如果采用本文方案，则先验证RD字段是否符合标准，不符合则跳过，符合则开始准备Offer/Advertise报文；若消息中携带有Rapid Commit选项，并且服务器支持快速分配过程，则跳到步骤④开始构建Reply报文，否则继续。Offer/Advertise 报文中包含提供给客户机的IP地址、租赁期以及默认网关等配置信息，同时更新RD字段。此外，为了认证消息，需要将服务器的签名附加在 Offer/Advertise 报文的options180 字段中，签名为SS₁=H ₄(ID _i, S_i,sk _B, MAC,IP,GW,RD₁)，其中 MAC 是设备的物理地址，此外，还包含之前协商的会话密钥以及主要配置信息，同时加入RD值保证消息的新鲜性。

③ 客户机验证服务器。收到 Offer/Advertise消息的客户机首先检测 RD 值是否严格高于旧的RD 值，若不满足，则丢弃；若满足，则提取报文中的配置信息，并计算 CS₁=H ₄(ID_i, S_i,sk _A, MAC,IP,GW,RD₁)，验证CS₁=SS₁是否成立，若不成立，则丢弃；若成立，则开始准备 Request报文。Request报文是客户机用来确认所要申请的具体 IP 地址以及其他网络参数，其主要内容与Offer/Advertise报文类似，同时更新RD值，并计算CS₂=H ₄(ID_i, S_i,sk _A, MAC,IP, GW, RD₂)，附加在Request报文中，发送给服务器。

④ 服务器验证客户机。服务器收到消息后首先验证RD是否符合要求，同时提取报文中的配置信息计算SS₂=H ₄(ID_i,S_i,sk _B,MAC,IP, GW,RD₂)，验证SS₂=CS₂是否成立，若不成立，则丢弃；若成立，则用相同的方法构建 ACK/Reply 报文，发送给客户机。

⑤ 客户机最后确认。客户机在接收到ACK/Reply报文后用相同的方法进行验证，若验证失败，则丢弃；若验证成功，则开始配置相关网络参数。

对DHCPv6，上述过程和图4中SS₁、CS₁、CS₂和SS₂的计算是将ID_i和S_i分别替换为客户机设备唯一标识符 DUIDc 和服务器设备唯一标识符DUIDs。另外，在实际应用中会有更多的状态和过程，都可以用相同的方式制作签名。

本文方案的安全性体现在2个方面：密钥协商过程的安全性以及DHCP认证过程中签名的不可伪造性，而后者的安全性依赖于前者的会话密钥安全，故本节主要对协商算法进行安全分析。

BAN逻辑是一种形式化的分析方法，普遍用来分析协议的正确性和安全性。本节将使用 BAN 逻辑对密钥协商算法进行形式化分析。现将符号表示如下：C和S表示主体，K_ij表示主体i和 j之间共享的密钥，K_i和$K_i{}^{-1}$分别表示i的公钥与私钥。

1) 定义安全目标

G ₁： $C|\equiv C\stackrel{K_{CS}}{\leftrightarrow }S$

G ₂： $S|\equiv C\stackrel{K_{CS}}{\leftrightarrow }S$

G ₃： $C|\equiv S|\equiv C\stackrel{K_{CS}}{\leftrightarrow }S$

G ₄： $S|\equiv C|\equiv C\stackrel{K_{CS}}{\leftrightarrow }S$

2) 定义初始状态假设

A ₁： $C|\equiv \stackrel{K_S}{\mapsto }S$

A ₂： $S|\equiv \stackrel{K_C}{\mapsto }C$

A ₃：$C|\equiv \#(c_1)$

A ₄：$S|\equiv \#(c_2)$

A ₅：$C|\equiv S\Rightarrow A_U$

A ₆：$S|\equiv C\Rightarrow F_U$

3) 描述理想化协议

M ₁：$C\to S:\left\{\text{ID,MAC,}{\beta }_U\right\}$

M ₂：$S\to C:\{A_U=c_{1}P\text{,}(A_U\text{,}{\beta }_U){}_{K_S^{-1}}\}$

M ₃：C计算会话密钥$K_{CS}=f(A_U)$

M ₄： $C\to S:\{F_U=c_{2}P\text{,}(F_U){}_{K_C^{-1}}\}$

M ₅：S计算会话密钥$K_{CS}=f(F_U)$

4) 基于BAN逻辑的形式化证明

根据M₂可得

P ₁：$S|\equiv c_1$

P ₂：$S|\equiv \text{\#}(c_1)$

P ₃： $C⊲A_U\text{,{}{A}_U\text{,}{\beta }_U\text{}}{}_{K_S^{-1}}$

根据P₃和接收消息规则，可得

P ₄： $C⊲\text{{}{A}_U\text{,}{\beta }_U\text{}}{}_{K_S^{-1}}$

根据P₄、A₁和消息含义规则，可得

P ₅： $C|\equiv S~(A_U\text{,}{\beta }_U)$

根据P₅、A₃和消息新鲜性规则，可得

P ₆： $C|\equiv \text{\#}(A_U\text{,}{\beta }_U)$

根据P₅、P₆和临时验证规则，可得

P ₇： $C|\equiv S\text{|}\equiv (A_U\text{,}{\beta }_U)$

根据P₇和信念规则，可得

P ₈： $C|\equiv S\text{|}\equiv A_U$

根据P₈、A₅和管辖规则，可得

P ₉： $C|\equiv A_U$

根据M₄可得

P₁₀： $C|\equiv c_2$

P₁₁： $C|\equiv \text{\#}(c_2)$

P₁₂：$S⊲F_U\text{,{}{F}_U\text{}}{}_{K_C^{-1}}$

根据P₁₂和接收消息规则，可得

P₁₃： $S⊲\text{{}{F}_U\text{}}{}_{K_C^{-1}}$

根据P₁₃、A₂和消息含义规则，可得

P₁₄： $S|\equiv C~F_U$

根据P₁₄、A₄和消息新鲜性规则，可得

P₁₅： $S|\equiv \text{\#}(F_U)$

根据P₁₄、P₁₅和临时验证规则，可得

P₁₆： $S|\equiv C\text{|}\equiv F_U$

根据P₁₆、A₆和管辖规则，可得

P₁₇： $S|\equiv F_U$

根据M₃、P₁₁和消息新鲜性规则，可得

P₁₈： $C|\equiv \text{\#}(K_{CS})$

根据P₈、P₁₈和会话密钥规则，可得

P₁₉： $C|\equiv C\stackrel{K_{CS}}{\leftrightarrow }S$

由于协议具有对称的结构，因此C相信S一定也能得出相同的信仰，即

P₂₀： $C|\equiv S|\equiv C\underset{}{\overset{K_{CS}}{\leftrightarrow }}S$

根据M₅、P₁和消息新鲜性规则，可得

P₂₁： $S|\equiv \text{\#}(K_{CS})$

根据P₁₆、P₂₁和会话密钥规则，可得

P₂₂： $S|\equiv C\stackrel{K_{CS}}{\leftrightarrow }S$

P₂₃： $S|\equiv C|\equiv C\stackrel{K_{CS}}{\leftrightarrow }S$

根据以上推理，得出全部4个安全目标，达到本文方案预期目的。

1) 抗恶意服务器攻击

在客户机注册阶段，客户机U_i首先通过检查参数$A_{U_i}$ 的新鲜性来抵抗重放攻击；接着通过参数$M_{U_i}$ 来检测参数$A_{U_i}$ 是否被篡改，同时验证服务器的身份，敌手若想伪造$M_{U_i}$ ，需捕获参数$A_{U_i}$ 和参数${\beta }_{U_i}$，通过服务器的公钥S_p，利用 $S_p=S_{s}P$反解出私钥S_s，为椭圆曲线上的离散对数问题；在密钥协商阶段，客户机通过参数Auth₁来检测参数c₃是否被篡改，同时验证服务器的身份，敌手若想伪造Auth₁，需捕获参数c ₃和参数F_{U i}，以同样的方法求解私钥S_s，这在计算上是不可行的^[18-19]。

2) 抗恶意客户机攻击证明

在密钥协商阶段，服务器S_i为首次验证客户机，通过检查参数$F_{U_i}$的新鲜性来抵抗重放攻击；接着通过参数cd来检测参数$F_{U_i}$是否被篡改，同时验证客户机的身份，敌手若想伪造cd，需要捕获参数c₂和客户机私钥d_i，但这2个参数都未在信道中传输过，只能通过$F_{U_i}=c_{2}P$ 和D_i =d_i P进行反解，也是离散对数问题；在密钥协商阶段，服务器S_i第二次验证客户机是通过参数Auth₂来判断客户机身份，敌手若想伪造Auth₂，需要同时捕获参数ID_i和参数S_i，以计算私钥d_i是不可行的。

3) 抗参数窃取攻击证明

服务器中存有客户机的ID_i和MAC，但缺少客户机私钥则无法完美冒充合法客户机，客户机私钥由客户机自身和服务器两部分选取产生，只窃取一部分则无法计算出完整私钥。

4) 防前/后向安全威胁证明

会话密钥中除客户机、服务器的各自私钥外，还包含客户机与服务器各自选择的随机数，而随机数的选取依赖于所使用的伪随机数算法，如果客户机与服务器采用不同的伪随机数算法，敌手想要同时破解难度很大；即使敌手以极小的概率猜测出随机数变化的规律，想要影响前/后安全性还需要同时获得客户机与服务器的私钥，所以认为会话密钥的产生是动态变化的，即使敌手获得某一时刻的密钥也不会造成前/后向的安全威胁。

本文实验分析利用开放密码库 OpenSSL 测试方案的性能^[20]，在2.6 GHz处理器和8 GB内存的Windows 10环境上运行。忽略前期的密钥协商，对比方案主体部分与原始DHCP的时间开销。从图5中可以看出，加入数字签名和验证给协议带来一定的时延。虽然本文方案在原始协议的基础上会引入一些安全开销，但与此同时也提供了可靠的安全性，数字签名与消息摘要的加入使参与方可以进行实体认证与消息认证，安全分析也表明其能有效缓解中间人攻击的威胁，并且其带来的额外开销是轻量的。

本文方案与文献[5]的 CA、S-DHCP 方案和文献[2]的DSec方案的仿真数据如图6所示。从图6可以看出，本文方案在性能上要明显优于另外3种方案，且随着客户机数量的增加而越来越明显。从这些方案的安全性上看，本文方案与S-DHCP方案默认使用基于椭圆曲线的256 bit长度的密钥，CA方案与DSec方案默认使用基于RSA的3 072 bit长度的密钥，两者的密钥安全性相当^[21-22]，然而 CA方案中的证书长度很容易超出DHCP限制，需将消息分段传输，因而增加了遭遇中间人攻击的风险；S-DHCP方案在密钥协商阶段缺少服务器对发起者的身份验证和消息新鲜性的检测，容易遭受重放攻击及其带来的拒绝服务攻击；DSec与S-DHCP方案的前提都是基于一个预共享的秘密，与延迟认证同样存在密钥的管理问题。

综上所述，本文方案能够有效缓解中间人攻击的威胁，且在性能表现上优于同类型方案，是更加轻量的安全方案。

本文针对互联网中普遍存在的中间人攻击问题，以DHCP为背景，提出安全快速的交互方案，旨在缓解有关网络攻击和安全威胁，即通过实体认证与密钥协商，结合数字签名与摘要进行消息认证。协商算法结构紧凑，通过双向认证防范攻击行为，有较高的执行效率；使用协商后的会话密钥构造数字签名，签名包含配置参数保持消息关联性，且容易附着在常规协议中对信息进行完整性和可靠性验证；遵循格式规范，不引入新的状态与参与方，使方案可以同时兼容DHCPv4与DHCPv6；通过安全性分析本文方案防御攻击的能力，通过性能分析其执行效率的提高程度。下一步工作是研究在保证安全性的前提下如何减少参与方之间的交互次数。