楊揚(yáng)，馬躍北京郵電大學(xué)計(jì)算機(jī)科學(xué)與技術(shù)學(xué)院，北京（100876）E-mail ：摘 要：SSL 作為目前流行的保障信息安全的協(xié)議，具有保密性、消息完整性和端點(diǎn)認(rèn)證等特性。本文使用SCEP 模塊為SS

楊揚(yáng)，馬躍

北京郵電大學(xué)計(jì)算機(jī)科學(xué)與技術(shù)學(xué)院，北京（100876）

E-mail ：

摘 要：SSL 作為目前流行的保障信息安全的協(xié)議，具有保密性、消息完整性和端點(diǎn)認(rèn)證等特性。本文使用SCEP 模塊為SSL 提供端點(diǎn)認(rèn)證的特性，它作為路由器上的一個(gè)模塊，向CA 服務(wù)器提出請(qǐng)求，為通信雙方提供身份認(rèn)證。

關(guān)鍵詞：SCEP ，SSL ，CA 服務(wù)器，CRL

中圖分類(lèi)號(hào)：TP393

1. 引言

SCEP [1]（Simple Certificate Enrollment Protocol）是一種證書(shū)解決方案，目前廣泛應(yīng)用于PKI client和CA 實(shí)現(xiàn)。SCEP 中有三種實(shí)體：終端實(shí)體、數(shù)字證書(shū)認(rèn)證中心（CA ）和審核授權(quán)部門(mén)（RA ）。終端實(shí)體是指在證書(shū)的subject name域或者在X.509 V3[2]擴(kuò)展版本中subjectAltName 域中定義名字的實(shí)體。它的功能是產(chǎn)生一對(duì)非對(duì)稱(chēng)RSA 密鑰，發(fā)起證書(shū)申請(qǐng)或者證書(shū)查詢(xún)請(qǐng)求。CA 是證書(shū)的頒發(fā)機(jī)構(gòu)，是PKI 的核心，職責(zé)是接收終端用戶(hù)的申請(qǐng)，決定是否為其頒發(fā)證書(shū)；處理證書(shū)的更新請(qǐng)求；處理證書(shū)的查詢(xún)請(qǐng)求；發(fā)布CRL 等。RA 協(xié)助CA 負(fù)責(zé)為已授權(quán)的證書(shū)申請(qǐng)者制作、發(fā)放和管理證書(shū)，在RA 存在的情況下，終端實(shí)體通過(guò)RA 提出證書(shū)申請(qǐng)，此時(shí)終端實(shí)體除了獲得CA 自簽名證書(shū)外，還要獲得由CA 頒發(fā)的RA 證書(shū)。

SCEP 模塊模塊

SSL 模塊

TCP 模塊

圖1 SCEP模塊在路由器中的位置

在建立SSL 連接的過(guò)程中，有兩處需要提供證書(shū)服務(wù)。一處是SSL 服務(wù)器向客戶(hù)端發(fā)送證書(shū)來(lái)證明自己的身份時(shí)，這就需要SSL 服務(wù)器擁有自己的數(shù)字證書(shū)；另外一處是如果SSL 服務(wù)器選擇了客戶(hù)端認(rèn)證，那么它在獲得客戶(hù)端證書(shū)時(shí)就需要認(rèn)證客戶(hù)端證書(shū)的可靠性。由于驗(yàn)證證書(shū)需要耗費(fèi)大量的時(shí)間，如果一個(gè)SSL 服務(wù)器同時(shí)為多個(gè)客戶(hù)端服務(wù)，驗(yàn)證每個(gè)客戶(hù)端的證書(shū)將耗費(fèi)大量的服務(wù)器時(shí)間，降低了服務(wù)器的效率。因此，對(duì)客戶(hù)端身份的驗(yàn)證往往不使用證書(shū)，而是通過(guò)其他的方式完成，比如用戶(hù)名/口令等。所以本文只討論SCEP 為SSL 申請(qǐng)數(shù)字證書(shū)的情況，SCEP 模塊在系統(tǒng)中的位置可以用圖1表示。

2. 為SSL 服務(wù)器申請(qǐng)證書(shū)

SSL 連接中進(jìn)行服務(wù)器驗(yàn)證，首先要保證服務(wù)器擁有數(shù)字證書(shū)，申請(qǐng)證書(shū)的過(guò)程由SCEP 模塊完成，申請(qǐng)成功后將證書(shū)送至SSL 信箱，SSL 模塊可以將證書(shū)存儲(chǔ)在內(nèi)存中，啟動(dòng)SSL 模塊時(shí)自動(dòng)加載證書(shū)，而無(wú)需每次重新申請(qǐng)證書(shū)。

SCEP 在申請(qǐng)證書(shū)前需要具備以下兩個(gè)前提條件：具有一對(duì)RSA 密鑰；已知CA 服務(wù)器

- 1 -

圖2

網(wǎng)路拓?fù)浣Y(jié)構(gòu)圖

SCEP 在獲取數(shù)字證書(shū)之前，必須先獲得CA 服務(wù)器證書(shū)（若RA 存在，還需獲得RA 證書(shū)），而此時(shí)SCEP 和CA 之間沒(méi)有公鑰交換，不能進(jìn)行加密通信，因此使用HTTP 協(xié)議來(lái)獲得證書(shū)。獲取CA 服務(wù)器證書(shū)的過(guò)程可以用兩條消息完成：SCEP 請(qǐng)求者發(fā)送給CA 服務(wù)器的GetCACert [1]消息和CA 服務(wù)器返回的CertRep [1]消息，如圖3所示。

圖3 SCEP 請(qǐng)求CA 服務(wù)器的證書(shū)

2.1 GetCACert

路由器R 與myca 建立TCP 連接之后， SCEP發(fā)送HTTP GET：

一旦接收到CA 證書(shū)，SCEP 必須使用“指紋”[1]來(lái)驗(yàn)證證書(shū)是否可信?！爸讣y”是對(duì)整個(gè)

- 2 -

驗(yàn)證過(guò)CA 證書(shū)之后，SCEP 就可以為SSL 服務(wù)器注冊(cè)證書(shū)了。證書(shū)注冊(cè)過(guò)程由兩條消息構(gòu)成，一條是SCEP 發(fā)送給CA 服務(wù)器的PKCSReq [1]消息，另外一條是CA 服務(wù)器返回的CertRep [1]消息，如圖4所示。

圖4 SCEP 向CA 服務(wù)器請(qǐng)求CA 證書(shū)

2.1.1 PKCSReq消息

PKCSReq 消息的內(nèi)容是添加了簽名的PKCS 證書(shū)請(qǐng)求。PKCSReq 的生成過(guò)程（如圖5所示）如下：

1．終端實(shí)體（本文中是路由器R 上的SCEP 模塊）創(chuàng)建一個(gè)自簽名的證書(shū)，包括的主

題名、主題公鑰信息和屬性等信息，然后使用與主題公鑰相對(duì)應(yīng)的私鑰對(duì)證書(shū)請(qǐng)求進(jìn)行簽名，簽名后的證書(shū)請(qǐng)求組成了證書(shū)請(qǐng)求信封的信息部分。

2．使用隨機(jī)生成的內(nèi)容加密密鑰key 來(lái)加密這個(gè)PKCS ＃10證書(shū)請(qǐng)求，再把這個(gè)內(nèi)

容加密密鑰key 用用于加密的RA 密鑰加密后放在接收者信息域中，就形成了PKCS ＃7證書(shū)請(qǐng)求信封。

3．生成一個(gè)唯一的字符串作為操作ID 。此ID 標(biāo)識(shí)一個(gè)PKI 操作，在同一次PKI 操作

中，終端實(shí)體和CA 交換的信息中的操作ID 都是相同的。

4．生成一個(gè)16字節(jié)的隨機(jī)數(shù)作為SenderNonce ，防止重放攻擊。

5．使用選定的消息摘要算法計(jì)算添加信封后的PKCS 注冊(cè)請(qǐng)求的消息摘要。

6．在簽名數(shù)據(jù)中添加請(qǐng)求者的自簽名證書(shū)和簽名者信息。將操作ID 、SenderNonce 和

上一步產(chǎn)生的摘要組成鑒定屬性，用終端實(shí)體的私鑰簽名，添加到簽名數(shù)據(jù)中，就完成了SignedData 。

7．使用ContentInfo 指明這個(gè)SignedData 對(duì)象，就組成了完整的PKCSReq PKI消息。 SCEP 終端實(shí)體生成PKCSReq 消息之后，先后用DER 和Base64編碼方式編碼，假設(shè)編碼后的內(nèi)容是msg ，然后發(fā)送HTTP GET ：

- 3 -

圖5 證書(shū)請(qǐng)求消息PKCSReq 的生成過(guò)程

2.1.2 CertRep

CA 服務(wù)器收到PKCSReq 消息之后，會(huì)驗(yàn)證請(qǐng)求者的身份，這里有兩種驗(yàn)證方式：手工驗(yàn)證和自動(dòng)驗(yàn)證。Windows2003服務(wù)器支持這兩種驗(yàn)證方式，可以在服務(wù)器中設(shè)置。先介紹一下人工驗(yàn)證方式，在CA 服務(wù)器管理員通過(guò)請(qǐng)求之前，證書(shū)請(qǐng)求信息會(huì)出現(xiàn)在CA 服務(wù)器的掛起請(qǐng)求列表中，并且CA 服務(wù)器會(huì)返回一個(gè)CertRep 消息返回給SCEP 。此時(shí)的CertRep 消息的pkiStatus 域?yàn)镻ENDING ，表示尚未通過(guò)管理員驗(yàn)證，此時(shí)登陸CA 服務(wù)器可以看到證書(shū)請(qǐng)求的狀態(tài)，處在“掛起的申請(qǐng)”列表中，如圖6所示，申請(qǐng)ID 為4的證書(shū)請(qǐng)求出現(xiàn)在“掛起的請(qǐng)求列表中”：

圖6 尚未通過(guò)手工驗(yàn)證的證書(shū)請(qǐng)求的狀態(tài)

圖7 手工驗(yàn)證證書(shū)請(qǐng)求的過(guò)程

- 4 -

1．FAILURE 消息

此消息表示驗(yàn)證過(guò)程中出現(xiàn)了錯(cuò)誤，請(qǐng)求被拒絕，證書(shū)請(qǐng)求出現(xiàn)在“失敗的申請(qǐng)”列表中。此時(shí)消息中的失敗信息中會(huì)給出失敗原因，一般有以下幾種：

badAlg ：使用了不能識(shí)別或者不支持的算法

badMessageCheck ：對(duì)消息完整性的驗(yàn)證失敗

badrequest:不被允許或者不支持的交易

badTime ：消息時(shí)間與系統(tǒng)時(shí)間不符

badCertId ：找不到匹配的證書(shū)

2．SUCCESS 消息

若請(qǐng)求者通過(guò)了驗(yàn)證，則證書(shū)請(qǐng)求會(huì)出現(xiàn)在“頒發(fā)的證書(shū)”列表中，如圖8所示：

[1][1]

圖8 已經(jīng)通過(guò)CA 管理員驗(yàn)證的證書(shū)請(qǐng)求的狀態(tài)

圖9 CertRep消息的格式

從圖8可以看出，申請(qǐng)ID 為4的證書(shū)請(qǐng)求已經(jīng)移到了“頒發(fā)的證書(shū)”列表中。而此時(shí)SCEP 也會(huì)收到一個(gè)CertRep 消息，消息的信息部分就是一個(gè)包含所請(qǐng)求的證書(shū)的退化的PKCS ＃7數(shù)據(jù)，此數(shù)據(jù)包括在PKCS ＃7信封中，除此之外還包括CA 服務(wù)器證書(shū)和簽名信息。證

- 5 - [4]

如果服務(wù)器使用自動(dòng)驗(yàn)證方式，則不會(huì)收到PENDING 類(lèi)型的CertRep 消息，也無(wú)須周期性發(fā)送GetInitialCert 了。自動(dòng)驗(yàn)證是基于對(duì)pre-share secret的檢驗(yàn)，pre-share secret是CA 服務(wù)器為每一個(gè)終端實(shí)體頒發(fā)的唯一的share secret，這個(gè)密鑰對(duì)應(yīng)該終端實(shí)體的注冊(cè)請(qǐng)求，只有該終端實(shí)體知道這個(gè)密鑰，當(dāng)終端實(shí)體提出注冊(cè)請(qǐng)求時(shí)，要將這個(gè)密鑰填進(jìn)PKCS#10屬性域，再經(jīng)過(guò)PKCS ＃7的封裝，加密發(fā)送給CA 服務(wù)器。CA 服務(wù)器提取密鑰并與自己保存的密鑰進(jìn)行比較，從而鑒別終端實(shí)體的身份。

到目前為止，SCEP 已經(jīng)成功的從CA 證書(shū)服務(wù)器取得了一個(gè)證書(shū)，它將這個(gè)證書(shū)提取出來(lái)之后，發(fā)到SSL 信箱中，SSL 就可以直接使用，在Certificate 消息中發(fā)送這個(gè)證書(shū)。 [5]

3. SCEP提供的其他服務(wù)

SCEP 除了完成證書(shū)請(qǐng)求的功能外，還可以提出證書(shū)查詢(xún)，請(qǐng)求CRL ，下面簡(jiǎn)單地介紹一下這兩個(gè)功能。

3.1證書(shū)查詢(xún)

證書(shū)查詢(xún)[1]有兩個(gè)用途：有些客戶(hù)端沒(méi)有存儲(chǔ)證書(shū)的能力，這時(shí)CA 服務(wù)器會(huì)替客戶(hù)存儲(chǔ)這些證書(shū)，客戶(hù)需要時(shí)可以向CA 服務(wù)器提出證書(shū)查詢(xún)，查詢(xún)自己的證書(shū)；另外一個(gè)用途是客戶(hù)可以使用證書(shū)查詢(xún)功能來(lái)查詢(xún)其他客戶(hù)的證書(shū)。證書(shū)查詢(xún)有兩種方式：使用LDAP 協(xié)議存取或者向CA 服務(wù)器發(fā)送查詢(xún)請(qǐng)求，我們這里介紹第二種方式。查詢(xún)過(guò)程有兩條消息組成：GetCert 和CertRep 。GetCert 消息的構(gòu)成和GetCACert 消息的組成類(lèi)似，只是此時(shí)GetCert 信封中被加密的內(nèi)容變成了要查詢(xún)的證書(shū)的頒發(fā)者和序列號(hào)（如圖10所示），這是因?yàn)樽C書(shū)使用其頒發(fā)者和序列號(hào)來(lái)唯一地標(biāo)識(shí)自己。在生成了GetCert 消息之后，再對(duì)其使用DER 和Base64編碼方式編碼，假設(shè)編碼后的內(nèi)容是msg ，使用HTTP GET：

摘要算法

數(shù)據(jù)類(lèi)型標(biāo)識(shí)

用CA 公鑰加密后的key

加密算法

用key 加密的證書(shū)序列號(hào)和頒發(fā)者名字

終端實(shí)體證書(shū)

簽名信息 [2]

圖10 證書(shū)查詢(xún)消息GetCert 的格式

3.2 請(qǐng)求CRL

我們知道SSL 另外一個(gè)用到證書(shū)服務(wù)的地方是驗(yàn)證客戶(hù)端證書(shū)，雖然我們?cè)趯?shí)際應(yīng)用中沒(méi)有用到這個(gè)服務(wù)，但SCEP 還是可以為SSL 提供這個(gè)服務(wù)的，這個(gè)功能的實(shí)現(xiàn)需要向CA 服務(wù)器請(qǐng)求CRL [1]，如果客戶(hù)端證書(shū)出現(xiàn)在CRL 中，說(shuō)明這個(gè)客戶(hù)端證書(shū)無(wú)效，可能證書(shū)過(guò)期或者用戶(hù)吊銷(xiāo)了證書(shū)，這是SSL 可以取消連接建立過(guò)程，否則，說(shuō)明客戶(hù)端證書(shū)可

- 6 -

證書(shū)的Certificate 消息，這時(shí)SSL 服務(wù)器可以繼續(xù)建立連接或者取消連接返回失敗信息。 CRL 是由CA 發(fā)行者的名字和CA 證書(shū)序列號(hào)標(biāo)識(shí)的，因此在請(qǐng)求CRL 時(shí)，必須提供這兩個(gè)信息。

SCEP 對(duì)CRL 的請(qǐng)求同樣通過(guò)兩條消息完成：GetCRL 消息和CertRep 。本文的環(huán)境中，若是請(qǐng)求CA 服務(wù)器test 的CRL ，則要在生成GetCRL 消息之后，使用HTTP GET http:/13.1.1.1/CertEnrolll/test.crl/發(fā)送CRL 請(qǐng)求（注意這里使用的HTTP GET與前面的有所不同）。這里的CertRep 消息返回的是撤銷(xiāo)證書(shū)列表[2]，列表中的每項(xiàng)由用戶(hù)證書(shū)序列號(hào)和撤銷(xiāo)日期組成，其格式如圖11所示。

[5]

圖11 CRL 格式

4. 結(jié)論

本文以SSL 服務(wù)器獲取證書(shū)為例討論了SCEP 的一些功能，其實(shí)SCEP 還可以為其他需

要證書(shū)的模塊提供服務(wù)，如IPSEC 等。SCEP 解決了建立安全通道時(shí)驗(yàn)證通信雙方身份的問(wèn)題，使用PKCS ＃10、PKCS ＃7協(xié)議與數(shù)據(jù)加密和數(shù)字簽名相結(jié)合，從而在證書(shū)注冊(cè)和頒發(fā)證書(shū)時(shí)，隱藏身份信息，抵抗中間人攻擊。

參考文獻(xiàn)

Yang Yang，Ma Yue

College of Computer Science & Technology，Beijing University of Posts and

Telecommunications ，Beijing (100876)

Abstract

SSL has characters of safety, message integrity and end authentication as a popular protocol ensuring information secure. This title uses SCEP module to offer end authentication for SSL, it is a module on router, send request to CA server, makes SSL server able to prove its identification.

Keywords ：SCEP ，SSL ，CA Server，CRL

- 8 -