一种新的数字证书验证方案

程 震， 程 雷

(1.山东理工大学 计算机科学与技术学院， 山东 淄博 255049；2.淄博职业学院 会计学院， 山东 淄博 255314)

一种新的数字证书验证方案

程 震1， 程 雷2

(1.山东理工大学 计算机科学与技术学院， 山东 淄博 255049；2.淄博职业学院 会计学院， 山东 淄博 255314)

数字证书是PKI技术的核心，而PKI是网络安全建设的基础.标准的验证数字证书是否有效的过程非常繁杂，对此提出一种新的方案——数字证书的集中式验证方案.方案的基本思想是设置验证服务器，证书使用者作为验证客户向服务器提交请求，由服务器集中验证证书，然后将结果签名发送给客户，完成验证.利用ASN.1语法给出方案的详细描述和安全性分析，并在手机网络环境下与标准的数字证书验证方案进行了性能比较.

数字证书；集中式验证；验证服务器；网络开销；验证策略

1 数字证书验证方案

数字证书[1-2]是PKI技术的核心，证书包括一般的公钥证书，也包括属性证书.证书在使用之前必须经过有效性验证.验证是一个复杂的处理过程，包括以下内容：

1)证书颁发者(CA)的公开密钥是否有效，是否可以用来验证证书上的数字签名.

2)证书是否包含一个有效的数字签名，这可利用其颁发者(CA)的公钥来验证.

3)当前时间是否在证书的有效期内.

4)证书或其密钥是否用于最初签发它的目的.

5)利用OCSP协议[3]，验证证书是否被撤销.

6)使用其他验证策略.

只有这些过程全部无误，才说明这个证书是有效的，可以使用.由于CA的公钥在CA的证书中，因此首先要验证CA的证书是否有效，然后再验证本证书是否有效，这是一个递归的过程.CA证书也许是另一个CA颁发的，如此直到根CA，这样会形成一个证书链.在实际应用中，证书链中的证书一般有2～5个.

标准的证书验证方案是客户自行验证证书链中的所有证书.由于使用OCSP协议，客户与验证服务器会有多次数据往返，网络开销较大，特别是在网速慢于有线网络的手机网络中[4].另外，由客户自行验证证书时，会使用自己的验证策略，而在高密级的环境中，如银行等单位，需要所有客户使用统一的验证策略，如确定一些信任的根CA作为信任锚，确定允许的证书及密钥的用法等.

除上述标准的证书验证方案外，目前已有多种改进方案.代理OCSP方案[5]可以减少客户的验证开销，但无法使用统一的验证策略.开放式PKI身份认证模型[6]加强了验证策略的管理，但客户开销较大.自验证方案[7]大大减轻了客户的开销，但安全性不高，不适合应用于高密级环境.

本文提出一种新的证书集中式验证方案，既能减少客户验证证书的网络开销，又能使用统一的验证策略.

2 方案概述

本方案的基本思想是设置一台验证服务器(以下简称服务器)，证书使用者作为验证客户(以下简称客户)向服务器提交请求，由服务器集中地验证证书，然后将结果作为响应发送给客户.服务器可以提供两类服务：

1)服务器验证证书，将验证结果发送给客户(以下简称验证服务).当客户完全信任服务器时，应该使用验证服务.

2)服务器不验证证书，仅将验证证书的相关信息发送给客户(以下简称信息服务).这些信息包括与验证证书相关的证书链、OCSP响应.当客户不愿或无法使用其他方法获取此类信息时，可以使用信息服务.由于这些信息都是经过发布者签名的，所以此时客户不需要信任服务器.

客户可以对请求签名，也可以不签名.签名与验证签名需要一定的开销，服务器可以认证客户的身份，并可在某种程度上抵御拒绝服务攻击.不签名相对简单、开销较小，但服务器无法安全地认证客户的身份.可以根据需要选用.

服务器对响应一定要签名，以保证响应的真实性和完整性.客户必须能够独立地验证服务器的证书，而不能再由服务器验证.

客户只需向服务器提交需要验证的证书，服务器则需要根据该证书生成证书链，再逐一验证.为提高效率，服务器应事先存储尽可能多的CA证书.若未事先存储某CA证书，需要时从该CA服务器下载即可，同时存储以便下次再用.由于国内主要CA也就几十个，国际知名的CA最多也不过数百个，因此事先存储并不难做到.当一台服务器无法验证时，还可向另一台服务器转发请求，共同配合完成服务.

3 方案详细描述

3.1 请求描述

请求使用ASN.1语法描述如下：

CVSRequest ::= SEQUENCE {

basicRequest BasicRequest,

signature Signature OPTIONAL }

--客户可以对其请求签名，也可以不签名.

Signature ::= SEQUENCE {

algorithm AlgorithmIdentifier,

signature BIT STRING,

certs SEQUENCE OF Cert OPTIONAL }

--certs是客户的证书链.

BasicRequest ::= SEQUENCE {

version INTEGER,

requestorName GeneralName OPTIONAL,

responderName GeneralName OPTIONAL,

requestList SEQUENCE OF SingleRequest,

requestNonce OCTET STRING OPTIONAL,

extensions Extensions OPTIONAL }

--requestorName标识了客户.

--responderName标识了服务器.

SingleRequest ::= SEQUENCE {

request CertCertID,

serviceType ServiceType,

policy OBJECT IDENTIFIER OPTIONAL,

policyParameters PolicyParameters OPTIONAL,

singleExtensions Extensions OPTIONAL }

--requestCert标识了请求的证书.

--serviceType标识了服务的种类.

--policy标识了验证时希望使用的策略，但服务器也可以使用其他策略.

定义3 ε-差分隐私.给定值域为Range(A)的随机算法A:Rn×m→Rn×m，当输入两个相邻的评分矩阵R、R′和非负实数ε，若对于任意S⊂Range(A)，都有

--policyParameters是策略的参数.

CertID ::= SEQUENCE {

issuerName GeneralName,

serialNumber CertSerialNumber }

--issuerName是颁发该证书CA的名字.

--serialNumber是该证书的序列号.

ServiceType ::= ENUMERATED {

validation(0),

ocspResponse(1),

certChain(2)}

--服务类型有3种：验证证书、OCSP响应、证书链.

3.2 响应描述

响应使用ASN.1语法描述如下：

CVSResponse ::= SEQUENCE {

basicResponse BasicResponse,

signature Signature }

--signature是服务器对响应的签名.

BasicResponse ::= SEQUENCE {

version INTEGER,

requestorName GeneralName OPTIONAL,

responderName GeneralName OPTIONAL,

producedAt GeneralizedTime,

responseList SEQUENCE OF SingleResponse,

responseNonce OCTET STRING OPTIONAL,

extensions Extensions OPTIONAL }

--requestorName标识了客户，与请求中的相同.

--responderName标识了服务器，与请求中的相同.

--producedAt是该响应的产生时间.

--responseNonce是响应现时值，该项的值必须与请求中的相同.

SingleResponse ::= SEQUENCE {

responseCert CertID,

serviceType ServiceType,

policy OBJECT IDENTIFIER OPTIONAL,

policyParameters PolicyParameters OPTIONAL,

responseResult ResponseResult,

singleExtensions Extensions OPTIONAL }

--responseCert标识了响应对应的证书.

--serviceType标识了服务的种类.

--policy指明了验证时实际使用的策略.

--policyParameters是策略的参数.

--responseResult是服务器的处理结果.

ResponseResult ::= CHOICE {

certStatus CertStatus,

ocspResponse BIT STRING,

certChain SEQUENCE OF Cert }

--结果有3种：证书验证状态、与该证书相关的OCSP响应、证书链.

CertStatus ::= ENUMERATED {

valid(0),

invalid(1),

unknown(2)}

--证书验证状态有有效、无效、无法确定3种.

除以上请求与响应外客户还可以发出另一种请求，获得服务器的验证策略列表.此处不再讨论.

4 安全性分析

由于服务器已对响应签名，因此响应的真实性与完整性完全有保障，并可以抵御中间人攻击.采用传输过程加密的方法保证数据的机密性.对于拒绝服务攻击，服务器可以屏蔽同一来源的短时间内的多次请求，并可以部署防火墙进行更好的防范.

对于重放攻击，最好的办法是使用现时值(requestNonce)来抵御.或者客户检查响应中的producedAt项，保证该响应足够新.检查producedAt项要求客户必须有足够精确的时钟；由于响应中的时间均为格林威治时间，客户还需要所在时区的信息.用户必须正确设置时间和时区，错误的时间或时区信息是非常危险的.

5 传输方式

为顺利通过防火墙和NAT网关等网络设备，并考虑到安全因素，采用HTTPS协议传输数据，而不采用普通的套接字编程.HTTPS协议是在普通的HTTP协议基础增加了SSL/TLS[8]保护，既能顺利通过防火墙和NAT网关等网络设备，也有较高的安全性.HTTPS请求由于数据量较多，应该使用POST方法.HTTPS响应首部中的MIME媒体类型应为application，并应使用一个新的MIME子类型.

6 比较与对比实验

与标准的证书验证方案及其他改进方案相比，本方案能有效减少客户验证证书的网络开销.

从方案的详细描述可以看出，无论证书链中有多少证书，客户只需向服务器请求一次即可完成验证，证书链中的证书全部是由服务器进行验证的.如果按照标准的证书验证方案，客户自行使用OCSP协议验证，虽然OCSP协议允许一次请求多个证书，但由于证书链中的证书是由不同CA签发的，因此需要使用多次OCSP协议，需要多次数据往返，造成较大时延.

虽然客户仍必须独立地验证服务器的证书，但由于仅限于该特定的证书，可以使用缓存的方法，验证一次后在一定时间内多次使用.可见本方案较好地减少了验证证书的网络开销，这在手机网络中尤为重要.3G网络已经在国内广泛使用，4G网络也在部分地区开通，但手机网络的数据传输速率仍无法与有线网络相比.

为进行对比实验，根据以上描述，编写程序实现了本方案的核心部分.程序由服务器端程序与手机端APP两部分组成.

服务器端程序运行于验证服务器，基于Linux操作系统，使用Java语言开发.密码操作部分(包括ASN.1编解码)则调用了符合JCE标准的开源软件包Bouncy Castle.手机端APP运行于Android手机，能够向验证服务器发送验证请求并接收验证响应，同时记录完成验证所需的时间.为消除各种干扰，在相同条件下进行对比，开发了一个对比APP，该APP将使用标准的验证方法，利用OCSP协议逐一验证证书链中的证书.

选择多个证书进行实验，其中最具有代表性的是支付宝网站的证书(*.alipay.com).该证书由Symantec Class 3 Secure Server CA - G4签发，该CA证书则由根CA VeriSign Class 3 Public Primary Certification Authority - G5签发.

手机网络使用中国联通的3G数据连接，验证服务器也接入与手机同一城市的中国联通网络.在不同时间段、不同手机信号质量下，交替运行两个APP，对15个证书进行多次验证，记录了近千组完成验证所需时间的数据.限于篇幅，这些数据不再详细描述.经统计分析，使用本方案APP的验证时间，平均是对比APP验证时间的41.6%.

另外，本方案还可以使全部客户使用统一的证书验证策略，当一个机构使用本方案时，通过在服务器上设立全机构统一的验证策略，提高应用系统的安全性.

7 结束语

综上所述，本文提出的证书集中式验证方案，既能减少客户验证证书的网络开销，又能使用统一的验证策略.因此特别适用于手机网络等网速一般的环境和如银行等高密级环境.

[1]RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List(CRL) Profile[EB/OL][2016-05-10]. http://www.ietf.org/rfc.html.

[2]RFC 6818: Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile[EB/OL][2016-05-10]. http://www.ietf.org/rfc.html.

[3]RFC 6960: X.509 Internet Public Key Infrastructure Online Certificate Status Protocol-OCSP[EB/OL][2016-05-10]. http://www.ietf.org/rfc.html.

[4]李福祥,关龙,赵金娜,等. 基于数字证书的移动支付协议[J]. 计算机科学, 2012, 39(11A): 19-23.

[5]程震. WPKI中证书撤销验证的代理OCSP方案[J]. 计算机工程与应用, 2006, 42(25): 123-125.

[6]周晓斌,许勇,张凌.一种开放式PKI身份认证模型的研究[J]. 国防科技大学学报， 2013, 35(1): 169-174.

[7]刘宝龙,陈桦.X.509数字证书有效性自验证方案研究[J]. 西安工业大学学报， 2012, 32(7): 541-544.

[8]RFC5246: The Transport Layer Security (TLS) Protocol Version 1.2[EB/OL] [2016-05-10]. http://www.ietf.org/rfc.html.

(编辑：刘宝江)

A new validation solution for digital certificate

CHENG Zhen1，CHENG Lei2

(1. School of Computer Science and Technology, Shandong University of Technology, Zibo 255049, China;2.Accounting Institute, Zibo Vocational Institute, Zibo 255314, China)

Digital certificate is the core of PKI,but PKI is the foundation of network security. The standard validation solution for digital certificate is very complex. A new solution is proposed, which is called central validation solution. The main idea of this new solution is that a validation server is established which can centrally validate clients′ certificates. Certificate users submit a request to the validation server as validation clients, and the validation server sends the signed validation results to clients after validating certificates centrally. Detailed description with ASN.1 of the solution is given. Its security is analyzed, and the performance difference between the new solution and the standard solution in mobile phone network is given.

digital certificate; central validation; validation server; network overhead; validation policies

2016-07-13

程震, 男,chengzhen@sdut.edu.cn

1672-6197(2017)04-0057-04

TP

A