基于改进无证书公钥密码的轻量级DTLS协议设计

许国栋 刘光杰 乔森 陆赛杰 赵华伟

0 引言

随着万物互联时代的到来,物联网技术正深刻改变着世界．指数级增长的物联网设备,在给人们带来便利的同时,也面临着众多威胁和安全挑战[1]．物联网安全逐渐引起了工程界和学术研究者的广泛关注．在众多物联网安全问题中,协议安全是实现点到点和端到端安全通信的基石,因此也成为了物联网安全研究的热点．网络协议研究者起初设计网络协议时主要考虑了可用性,而忽略了安全性问题．作为传输层协议典型代表的TCP、UDP协议本身也不具备安全性．SSL/TLS协议在TCP协议之上提供数据的加密传输服务,而DTLS协议(DatagramTLS)扩展自TLS协议架构,为UDP协议提供端到端的安全通道．DTLS协议也可与物联网相关应用层协议结合来实现安全通信．例如,CoAP协议[2]经DTLS加密后形成的CoAPs协议,被广泛应用于物联网的端到端安全通信中[3-4]．

握手是DTLS协议完成身份认证和秘钥协商的必要机制.然而,传统DTLS协议的握手过程更多是基于公钥证书,但基于证书的公钥密码体系在证书管理、身份认证与加密等方面存在不足．一方面,证书管理包括证书的撤销、发放和存储等环节,增加了系统的开销;另一方面,身份认证与加密包括通信终端的身份合法性认证、基于公钥的传输数据加密等过程,增加了计算开销．因此,本文主要研究基于无证书公钥密码的DTLS握手协议.针对该问题,研究者们也探索了诸多无证书[5]的解决方案．2003年,Boneh等[6]构建了第一个基于身份的加密方案(Identity Based Encryption,IBE)．然而,IBE方案使用双线性对运算，且用户的私钥完全由私钥生成器(Private Key Generator,PKG)生成,这不仅造成更高的计算代价,还引发出私钥托管问题．文献[7]实现了基于身份标识(Identify-Based Cryptography,IBC)的DTLS协议,但此方案中的用户私钥仍完全由PKG产生．若PKG节点遭受攻击,恶意节点将获取用户私钥,进而窃听合法用户间的通信内容．文献[8]提出了一种用户私钥生成方案来解决密钥托管问题,首先使用系统私钥生成初始秘钥值,再叠加上一个随机数,构成一部分用户私钥,但此方案在安全性证明方面还存在不足．文献[9]提出了一种双密钥对的方案,即PKG随机选取两个秘钥值作为系统私钥,并将其中一个秘钥值加上仅通过系统私钥产生的一部分用户私钥作为用户最终的部分私钥,但与文献[8]相比又增加了部分计算量,降低了方案的实现效率,难以满足计算成本受限型节点的安全通信需求．

针对上述问题,本文改进了产生用户部分私钥的运算方法,提出了一种基于离散对数运算的无证书公钥加密(Discrete Logarithm based Certificate-Less Public Key Cryptography,DL-CL-PKC)方案,此方案主要有两个优势:一是规避了基于身份标识的方案中双线性映射带来的运算复杂度;二是此方案中私钥生成器只需要生成一对系统密钥值,节省了一对密钥值的生成过程和后续的存储空间．最后设计并实现了基于DL-CL-PKC的DTLS协议．改进的DTLS协议不仅简化了握手过程,并且可以在不使用证书情况下实现安全加密通信．

1 改进的无证书公钥密码体制

本文改进的无证书方案是基于离散对数运算而设计的,该体制主要包括密钥管理方案设计和密钥更新方案设计．下面将依次介绍离散对数数学难题的定义以及无证书方案中的密钥管理和密钥更新．

1.1 离散对数难题

本文主要是基于离散对数数学难题,设计了新的用户部分私钥生成算法．离散对数难题描述为:对于给定的m,x和p,通过公式y=mxmodq很容易计算得出y,但是若给定参数y,a和p想计算出x则极其困难．目前来说离散对数的计算难度与RSA算法中大整数因数分解的难度相同,因此并没有有效的方法可以计算出模为素数的离散对数问题．本文基于离散对数难题重新设计DTLS握手协议主要基于两个原因:一方面RSA算法的加解密过程是非对称的且存在大量的模幂运算,本文采用对称加解密,提高了无证书方案的计算效率;另一方面RSA算法的加密公钥存储在证书中,不符合本文方案基于无证书的原则,无法达到降低系统开销的目的．基于离散对数难题,也衍生出一些相关密码体制,如ElGmal加密体制[10]、Diffe-Hellman密钥交换方法[11]以及Schnorr数字签名方法[12]．离散对数难题与大整数因数分解的安全性分析如下:

2)大整数因数分解.第一步选择两个大素数p,q;第二步计算模数n=p×q和L=φ(n)=(p-1)(q-1),选择满足gcd(e,L)=1的e,并计算出满足d·e≡1modL的d(1

1.2 密钥管理

科研人员一直致力于密钥管理的简化研究．著名密码学专家Shamir[13]率先提出了基于身份的密码体制的概念,作为其核心组成的私钥生成器(Private Key Generator,PKG),也是本文设计的无证书公钥密码体制中的重要组成部分．PKG产生无证书公钥加密方案中用户的部分私钥,省略证书参与用户身份验证的步骤．

无证书公钥加密方案中密钥管理如图1所示．由于PKG单独生成IBE加密方案中的用户私钥存在安全隐患,所以本文提出将用户私钥的产生过程分为两个阶段：首先用户向PKG节点请求生成部分私钥;其次则由用户根据PKG节点发送的系统参数随机生成另一部分私钥,并对PKG节点和其他用户不可见．然后用户公布自己的公钥．密钥管理包括以下几个方面:

图1 DL-CL-PKC密钥管理方案Fig.1 Key management scheme for DL-CL-PKC

1)PKG节点初始化之后,监听两个通信终端的部分私钥生成请求;

2) PKG节点将产生的系统参数和公私钥发送给监听到请求的两个通信终端;

3) PKG节点将根据客户端或服务端的ID产生相应的部分私钥发送给客户端或服务端;

4)客户端或服务端通过系统参数再随机选取一个秘密值作为另一部分私钥,并通过这两部分私钥计算出完全的私钥．

下面根据上述描述给出具体方案．

1)系统参数生成

公开系统参数param:{a,b,g,x,y,H1,H2}．

2)部分私钥提取

假设用户A的身份为IDA,PKG节点计算用户A的部分私钥,步骤如下:

① 计算hA=H1(IDA);

3)完整公私钥生成

4)加密(cl-encrypt)

用户B将消息发送给用户A,步骤执行如下:

③ 用户B将C=(N,M)发送给给用户A．

5)解密(cl-decrypt)

当用户A接收到用户B发送来的加密报文C,用户A计算m=M⨁H2(NSA)恢复出明文信息．解密过程如下验证推导所示:

1.3 密钥更新

密钥是加密通信的关键,因此为了保证系统的安全性,必须在一定周期内进行更新(主要是对用户私钥的更新)．基于无证书公钥加密方案中的密钥更新过程主要包括以下两个步骤:

1)预先设定密钥更新周期,时间周期设置得越短则系统安全性越高．为了让密钥更新的周期更加合理,可根据网络动态和需求,实时恰当地调整更新周期．

1.4 安全性分析

在本文设计的加密体制中,主要考虑以下两种攻击类型:

第一种攻击.假设攻击者获取了系统私钥,就会带来安全威胁,即攻击者利用获取的系统私钥去生成用户的部分私钥,这里攻击者作为不可信的PKG节点．但是由于此方案中用户完全私钥的部分是由用户自己生成的,并且不对外公开,因此不可信的PKG节点无法获取用户完全的私钥,也就无法去监听与其他用户之间的通信内容．

第二种攻击.假设攻击者作为一个不合法的用户,获取的是某个合法用户完整的私钥,但是由于此方案采用了离散对数运算,不合法的用户无法通过合法用户的私钥去倒推出系统私钥,也不可能去生成其他合法用户的私钥,因此它只能与其他用户之间进行通信,是无法监听到甚至解密其他用户之间的通信内容的．

这样在系统更新用户私钥时,不合法的用户在向PKG节点申请部分私钥时就无法通过PKG节点的身份认证,原先获取的私钥也就失效了．

2 基于改进无证书公钥密码的DTLS协议设计

本文设计的基于无证书公钥加密的DTLS协议主要针对握手协议进行改进．由于目前DTLS握手协议双方在进行通信认证时仍然需要加载证书,增加了握手过程的复杂性和成功建立通信连接所占用的时间．因此,在DTLS协议中引入改进的无证书公钥密码体制,设计新的握手协议,可有效避免证书的交换和验证的过程,减少通信双方需要传递的信息量和交互的回合数,从而缩短通信连接建立的时间．

2.1 DTLS握手协议

DTLS协议建立在传输层协议之上、应用层协议之下,在完成加密算法、密钥协商、服务器端认证后,即可建立应用层协议的通信．因此,后续应用层协议发送的数据都会进行加密处理,以保证网络通信中数据的安全．图2a给出的是一次完整的DTLS握手流程．DTLS v1.2中ClientHello和ServerHello消息序列中包含一个预共享密钥(pre_shared_key),DTLS v1.3的ClientHello和ServerHello在DTLS v1.2基础上又增加了一个密钥共享(key_share)的扩展部分．关于握手消息序列,文献[14]进行了较为详尽的介绍,因此本文不在此赘述．

图2 传统DTLS握手消息序列与改进DTLS握手消息序列Fig.2 Traditional DTLS handshake message sequences (a) and improved DTLS handshake message sequences (b)

2.2 改进DTLS握手协议设计

本文提出的改进DTLS握手协议通过+key_share*扩展在Client端与Server端间交换公钥信息,并将其重命名为+publickey_share*．而Client端和Server端的私钥,一部分由私钥生成器根据两者的ID生成,另一部分由自身根据系统参数随机生成．本文所设计的握手协议如图2b所示,握手过程如下:

1)Client端向Server端发送一个没有携带cookie值的ClientHello报文,以确认Server端已经启用．

2)Server端收到此报文后,回复携带cookie值的HelloRetryRequest给Client端．

3)Client端从HelloRetryRequest报文中取出cookie值,放入新的ClientHello报文中发送,扩展+publickey_share*中附带自身的公钥信息．

4)Server端验证Client端发送的ClientHello报文中携带的cookie值,选择合适的加密算法(本文设计为DTLS_PKC_WITH_AES_128_CBC_SHA512)和压缩算法,并生成随机数,通过ServerHello报文发送到Client端,扩展中携带自身的公钥信息．

5)Server端发送ChangeCipherSpec报文告知Client端密码规范已发生改变,接下来将利用协商相同的安全密钥来保障数据的安全传输．Server端通过密钥交换算法生成预主密钥,预主密钥通过与随机数进行伪随机运算生成主密钥以及会话密钥．

预主密钥生成过程如下:

(gSS)SCmodq=gSSSCmodq=

(gSC)SSmodq=(gSCmodq)SSmodq=

6)Server端利用协商好的算法和密钥,将Finished报文加密后发送给Client端．此报文用于验证密钥交换是否成功．

7)Client端在收到Server端发送的ServerHello、ChangeCipherSpec和Finished报文后计算出相应的会话密钥,解密Finished报文并对其数据进行验证．验证通过发送ChangeCipherSpec报文告知Server端接下来使用协商相同的安全密钥来保障数据的安全传输．

8)Client端利用协商的算法和密钥,加密Finished报文后发送给Server端,Server端解密此报文并验证,验证通过后,两者即可正式建立连接．

对比图2a与2b可以发现,与传统的DTLS握手过程相比,本文在握手消息ClientHello和ServerHello中使用扩展+publickey_share*交换公钥信息,并省略了握手过程中与证书相关的交互报文．

2.3 无证书公钥加密算法及握手协议实现

握手协议中的无证书公钥加密算法(Discrete Logarithm based Certificate-Less Public Key Cryptography,DL-CL-PKC)可以通过GMP库[15]来实现.GMP库是一种高精度的算术运算库,可支持对浮点数、有符号整数等数据类型进行相关算术运算．它旨在为所有需要更高精度的应用程序提供最快的算法．DL-CL-PKC算法主要分为PKG节点初始化函数、部分私钥生成函数、完全私钥生成函数、用户公钥生成函数以及加密和解密函数．为了程序后续的调用,将主要算法进行了封装．主要函数接口如表1所示.

表1 DL-CL-PKC算法函数接口Table 1 Function interfaces for the DL-CL-PKC algorithm

通过上述封装的算法,可以在wolfSSL[16]库中实现基于该算法的DTLS握手协议,具体可分为以下两个步骤:

1)定义新的加密套件

DTLS握手过程所涉及的多种算法(密钥交换、认证、对称加密及哈希算法),都是通过加密套件进行定义的．测试程序会根据选择的加密套件去执行相应算法,本文所定义的加密套件是DTLS_PKC_WITH_AES_128_CBC_SHA512,此加密套件表明密钥协商算法是DL-CL-PKC,对称加密算法采用128位的AES[17]算法,加密模式采用CBC模式,哈希算法采用SHA512．

2)密钥协商

Client端和Server端互换公钥信息后,Client端使用密钥交换算法计算预主密钥,并加密发送给Server端,Server端解密得到预主密钥,接着Server端通过预主密钥结合随机数做伪随机算法后得到主密钥和后续会话的密钥．

通过以上两个步骤,双方即可在省略证书加载和认证过程的情况下正式建立连接．

3 实验分析

本文分别在 Ubuntu 18.04.3、CentOS 3.10.0和Deepin 5.4.50系统上实现基于无证书公钥密码的DTLS协议．Client端将本文定义的加密套件通过ClientHello报文发送给Server端,Server端选择此加密套件,实施本文提出的握手方法.如果Server端没有选择此加密套件也可以跳转到其他加密套件,本文以PSK和ECDHE为两个备用套件．

实验环境为戴尔台式机,处理器是Core(TM) i7-9700,拥有内存32 GB,虚拟机类型为VMware Workstation Pro,虚拟机分配虚拟内存为4 GB,虚拟机系统为Ubuntu 18.04.3、CentOS 3.10.0和Deepin 5.4.50．

通过将本文设计的基于DL-CL-PKC算法的DTLS握手协议与DTLS两个备用套件PSK[18]、ECDHE[19]和基于身份标识的DTLS握手协议方案[7]进行对比,通过比较它们的消息传输开销和连接时延来检验本文所设计方案的性能．

3.1 消息传输开销

通过wireshark分别抓取4种方案交互传输的报文,对比4种握手过程中产生的信息字节数,结果如表2所示.首先可以看出DTLS备用的2个套件的交互次数都是6次,而本文提出的方案与基于身份标识的DTLS握手协议方案都将交互次数减少了1次;其次在这些交互过程中由于剔除证书发送和验证过程,使本文设计的方案和基于身份标识的DTLS握手协议方案所需传输的握手消息数量也有所减少,相比PSK,发送的消息数减少了3条,而相比ECDHE,减少了8条,大大降低了握手过程中的通信流量,且本文所提方案的握手消息字节略小于基于身份标识的DTLS握手协议方案．

表2 4种方案消息传输开销Table 2 Messaging overhead for the four schemes

3.2 连接时间

分别测出4种方案在以linux为内核的3种操作系统中的连接时间,测量方法是记录发送第一个报文开始到建立连接所用的时间,并且对这4种方案的连接时延进行多次测量,最后求出平均值,结果如图3所示．由于PSK是直接以双方事先就已经约定好的密钥为基础来进行加密通信的,所以此方案节省了在握手过程中计算密钥所花费的时间,并且PSK方案[18]也不需要进行证书的认证,同样节省了连接时间,最终都可以在较小时延下完成连接,但是PSK方案安全性较低.ECDHE方案[19]需要解析证书以作认证,所以花费时间较多,完成连接的时延最大.PBC方案[7]同样实现了基于无证书的DTLS握手过程,节省了连接时间,但此方案没有考虑到PKG节点遭受攻击造成系统私钥和合法用户私钥泄露的问题.而本文所提方案在考虑安全性的前提下,省去证书验证环节,也可以在相对较小的时延下建立连接．和ECDHE方案[19]相比,本文所提的方案将连接时延降低了40%以上;和PBC方案[7]采用双线性对运算获取共享密钥和后续会话密钥相比,本文采用运算速度更快的离散对数运算,因此握手连接时间更短．

图3 3种操作系统下的4种方案连接时间对比Fig.3 Comparison of connection time between four schemes under three operating systems

4 结束语

本文利用离散对数运算,实现了DL-CL-PKC算法,设计并实现基于改进离散对数运算的无证书公钥密码的DTLS握手协议,此方案可将Client端和Server端产生的公钥通过扩展+publickey_share分别发送到对端,参与后续会话密钥的生成,简化了握手过程,减少了交互次数,节省了通信开销．实验结果表明,本文在不降低原先DTLS安全性的基础上,很大程度地缩短了连接建立时间．下一步工作将从物联网应用层协议入手,将本文设计的无证书方案与应用层协议集成起来并实现基于无证书DTLS协议的应用层协议的加密．