程 震， 程 雷

(1.山東理工大學 計算機科學與技術學院， 山東 淄博 255049；2.淄博職業(yè)學院 會計學院， 山東 淄博 255314)

一種新的數(shù)字證書驗證方案

程 震1， 程 雷2

(1.山東理工大學 計算機科學與技術學院， 山東 淄博 255049；2.淄博職業(yè)學院 會計學院， 山東 淄博 255314)

數(shù)字證書是PKI技術的核心，而PKI是網(wǎng)絡安全建設的基礎.標準的驗證數(shù)字證書是否有效的過程非常繁雜，對此提出一種新的方案——數(shù)字證書的集中式驗證方案.方案的基本思想是設置驗證服務器，證書使用者作為驗證客戶向服務器提交請求，由服務器集中驗證證書，然后將結(jié)果簽名發(fā)送給客戶，完成驗證.利用ASN.1語法給出方案的詳細描述和安全性分析，并在手機網(wǎng)絡環(huán)境下與標準的數(shù)字證書驗證方案進行了性能比較.

數(shù)字證書；集中式驗證；驗證服務器；網(wǎng)絡開銷；驗證策略

1 數(shù)字證書驗證方案

數(shù)字證書[1-2]是PKI技術的核心，證書包括一般的公鑰證書，也包括屬性證書.證書在使用之前必須經(jīng)過有效性驗證.驗證是一個復雜的處理過程，包括以下內(nèi)容：

1)證書頒發(fā)者(CA)的公開密鑰是否有效，是否可以用來驗證證書上的數(shù)字簽名.

2)證書是否包含一個有效的數(shù)字簽名，這可利用其頒發(fā)者(CA)的公鑰來驗證.

3)當前時間是否在證書的有效期內(nèi).

4)證書或其密鑰是否用于最初簽發(fā)它的目的.

5)利用OCSP協(xié)議[3]，驗證證書是否被撤銷.

6)使用其他驗證策略.

只有這些過程全部無誤，才說明這個證書是有效的，可以使用.由于CA的公鑰在CA的證書中，因此首先要驗證CA的證書是否有效，然后再驗證本證書是否有效，這是一個遞歸的過程.CA證書也許是另一個CA頒發(fā)的，如此直到根CA，這樣會形成一個證書鏈.在實際應用中，證書鏈中的證書一般有2～5個.

標準的證書驗證方案是客戶自行驗證證書鏈中的所有證書.由于使用OCSP協(xié)議，客戶與驗證服務器會有多次數(shù)據(jù)往返，網(wǎng)絡開銷較大，特別是在網(wǎng)速慢于有線網(wǎng)絡的手機網(wǎng)絡中[4].另外，由客戶自行驗證證書時，會使用自己的驗證策略，而在高密級的環(huán)境中，如銀行等單位，需要所有客戶使用統(tǒng)一的驗證策略，如確定一些信任的根CA作為信任錨，確定允許的證書及密鑰的用法等.

除上述標準的證書驗證方案外，目前已有多種改進方案.代理OCSP方案[5]可以減少客戶的驗證開銷，但無法使用統(tǒng)一的驗證策略.開放式PKI身份認證模型[6]加強了驗證策略的管理，但客戶開銷較大.自驗證方案[7]大大減輕了客戶的開銷，但安全性不高，不適合應用于高密級環(huán)境.

本文提出一種新的證書集中式驗證方案，既能減少客戶驗證證書的網(wǎng)絡開銷，又能使用統(tǒng)一的驗證策略.

2 方案概述

本方案的基本思想是設置一臺驗證服務器(以下簡稱服務器)，證書使用者作為驗證客戶(以下簡稱客戶)向服務器提交請求，由服務器集中地驗證證書，然后將結(jié)果作為響應發(fā)送給客戶.服務器可以提供兩類服務：

1)服務器驗證證書，將驗證結(jié)果發(fā)送給客戶(以下簡稱驗證服務).當客戶完全信任服務器時，應該使用驗證服務.

2)服務器不驗證證書，僅將驗證證書的相關信息發(fā)送給客戶(以下簡稱信息服務).這些信息包括與驗證證書相關的證書鏈、OCSP響應.當客戶不愿或無法使用其他方法獲取此類信息時，可以使用信息服務.由于這些信息都是經(jīng)過發(fā)布者簽名的，所以此時客戶不需要信任服務器.

客戶可以對請求簽名，也可以不簽名.簽名與驗證簽名需要一定的開銷，服務器可以認證客戶的身份，并可在某種程度上抵御拒絕服務攻擊.不簽名相對簡單、開銷較小，但服務器無法安全地認證客戶的身份.可以根據(jù)需要選用.

服務器對響應一定要簽名，以保證響應的真實性和完整性.客戶必須能夠獨立地驗證服務器的證書，而不能再由服務器驗證.

客戶只需向服務器提交需要驗證的證書，服務器則需要根據(jù)該證書生成證書鏈，再逐一驗證.為提高效率，服務器應事先存儲盡可能多的CA證書.若未事先存儲某CA證書，需要時從該CA服務器下載即可，同時存儲以便下次再用.由于國內(nèi)主要CA也就幾十個，國際知名的CA最多也不過數(shù)百個，因此事先存儲并不難做到.當一臺服務器無法驗證時，還可向另一臺服務器轉(zhuǎn)發(fā)請求，共同配合完成服務.

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′和非負實數(shù)ε，若對于任意S?Range(A)，都有

--policyParameters是策略的參數(shù).

CertID ::= SEQUENCE {

issuerName GeneralName,

serialNumber CertSerialNumber }

--issuerName是頒發(fā)該證書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是該響應的產(chǎn)生時間.

--responseNonce是響應現(xiàn)時值，該項的值必須與請求中的相同.

SingleResponse ::= SEQUENCE {

responseCert CertID,

serviceType ServiceType,

policy OBJECT IDENTIFIER OPTIONAL,

policyParameters PolicyParameters OPTIONAL,

responseResult ResponseResult,

singleExtensions Extensions OPTIONAL }

--responseCert標識了響應對應的證書.

--serviceType標識了服務的種類.

--policy指明了驗證時實際使用的策略.

--policyParameters是策略的參數(shù).

--responseResult是服務器的處理結(jié)果.

ResponseResult ::= CHOICE {

certStatus CertStatus,

ocspResponse BIT STRING,

certChain SEQUENCE OF Cert }

--結(jié)果有3種：證書驗證狀態(tài)、與該證書相關的OCSP響應、證書鏈.

CertStatus ::= ENUMERATED {

valid(0),

invalid(1),

unknown(2)}

--證書驗證狀態(tài)有有效、無效、無法確定3種.

除以上請求與響應外客戶還可以發(fā)出另一種請求，獲得服務器的驗證策略列表.此處不再討論.

4 安全性分析

由于服務器已對響應簽名，因此響應的真實性與完整性完全有保障，并可以抵御中間人攻擊.采用傳輸過程加密的方法保證數(shù)據(jù)的機密性.對于拒絕服務攻擊，服務器可以屏蔽同一來源的短時間內(nèi)的多次請求，并可以部署防火墻進行更好的防范.

對于重放攻擊，最好的辦法是使用現(xiàn)時值(requestNonce)來抵御.或者客戶檢查響應中的producedAt項，保證該響應足夠新.檢查producedAt項要求客戶必須有足夠精確的時鐘；由于響應中的時間均為格林威治時間，客戶還需要所在時區(qū)的信息.用戶必須正確設置時間和時區(qū)，錯誤的時間或時區(qū)信息是非常危險的.

5 傳輸方式

為順利通過防火墻和NAT網(wǎng)關等網(wǎng)絡設備，并考慮到安全因素，采用HTTPS協(xié)議傳輸數(shù)據(jù)，而不采用普通的套接字編程.HTTPS協(xié)議是在普通的HTTP協(xié)議基礎增加了SSL/TLS[8]保護，既能順利通過防火墻和NAT網(wǎng)關等網(wǎng)絡設備，也有較高的安全性.HTTPS請求由于數(shù)據(jù)量較多，應該使用POST方法.HTTPS響應首部中的MIME媒體類型應為application，并應使用一個新的MIME子類型.

6 比較與對比實驗

與標準的證書驗證方案及其他改進方案相比，本方案能有效減少客戶驗證證書的網(wǎng)絡開銷.

從方案的詳細描述可以看出，無論證書鏈中有多少證書，客戶只需向服務器請求一次即可完成驗證，證書鏈中的證書全部是由服務器進行驗證的.如果按照標準的證書驗證方案，客戶自行使用OCSP協(xié)議驗證，雖然OCSP協(xié)議允許一次請求多個證書，但由于證書鏈中的證書是由不同CA簽發(fā)的，因此需要使用多次OCSP協(xié)議，需要多次數(shù)據(jù)往返，造成較大時延.

雖然客戶仍必須獨立地驗證服務器的證書，但由于僅限于該特定的證書，可以使用緩存的方法，驗證一次后在一定時間內(nèi)多次使用.可見本方案較好地減少了驗證證書的網(wǎng)絡開銷，這在手機網(wǎng)絡中尤為重要.3G網(wǎng)絡已經(jīng)在國內(nèi)廣泛使用，4G網(wǎng)絡也在部分地區(qū)開通，但手機網(wǎng)絡的數(shù)據(jù)傳輸速率仍無法與有線網(wǎng)絡相比.

為進行對比實驗，根據(jù)以上描述，編寫程序?qū)崿F(xiàn)了本方案的核心部分.程序由服務器端程序與手機端APP兩部分組成.

服務器端程序運行于驗證服務器，基于Linux操作系統(tǒng)，使用Java語言開發(fā).密碼操作部分(包括ASN.1編解碼)則調(diào)用了符合JCE標準的開源軟件包Bouncy Castle.手機端APP運行于Android手機，能夠向驗證服務器發(fā)送驗證請求并接收驗證響應，同時記錄完成驗證所需的時間.為消除各種干擾，在相同條件下進行對比，開發(fā)了一個對比APP，該APP將使用標準的驗證方法，利用OCSP協(xié)議逐一驗證證書鏈中的證書.

選擇多個證書進行實驗，其中最具有代表性的是支付寶網(wǎng)站的證書(*.alipay.com).該證書由Symantec Class 3 Secure Server CA - G4簽發(fā)，該CA證書則由根CA VeriSign Class 3 Public Primary Certification Authority - G5簽發(fā).

手機網(wǎng)絡使用中國聯(lián)通的3G數(shù)據(jù)連接，驗證服務器也接入與手機同一城市的中國聯(lián)通網(wǎng)絡.在不同時間段、不同手機信號質(zhì)量下，交替運行兩個APP，對15個證書進行多次驗證，記錄了近千組完成驗證所需時間的數(shù)據(jù).限于篇幅，這些數(shù)據(jù)不再詳細描述.經(jīng)統(tǒng)計分析，使用本方案APP的驗證時間，平均是對比APP驗證時間的41.6%.

另外，本方案還可以使全部客戶使用統(tǒng)一的證書驗證策略，當一個機構使用本方案時，通過在服務器上設立全機構統(tǒng)一的驗證策略，提高應用系統(tǒng)的安全性.

7 結(jié)束語

綜上所述，本文提出的證書集中式驗證方案，既能減少客戶驗證證書的網(wǎng)絡開銷，又能使用統(tǒng)一的驗證策略.因此特別適用于手機網(wǎng)絡等網(wǎng)速一般的環(huán)境和如銀行等高密級環(huán)境.

[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]李福祥,關龍,趙金娜,等. 基于數(shù)字證書的移動支付協(xié)議[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數(shù)字證書有效性自驗證方案研究[J]. 西安工業(yè)大學學報， 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