《中國人民銀行信息系統(tǒng)電子認證應(yīng)用指引(V1.0).doc》由會員分享，可在線閱讀，更多相關(guān)《中國人民銀行信息系統(tǒng)電子認證應(yīng)用指引(V1.0).doc（45頁珍藏版）》請在裝配圖網(wǎng)上搜索。

1、內(nèi)部資料 注意保管 中國人民銀行信息系統(tǒng) 電子認證應(yīng)用指引 （征求意見稿） 中國人民銀行 2010年1月  目 錄 1 概況 1 1.1. 編寫目的 1 1.2. 適用范圍 1 1.3. 指引內(nèi)容簡介 1 1.4. 術(shù)語定義 1 2 CA系統(tǒng)及應(yīng)用簡介 4 2.1. 生產(chǎn)系統(tǒng) 5 2.2. 測試系統(tǒng) 6 2.3. CA應(yīng)用現(xiàn)狀 6 2.3.1. CA系統(tǒng)與CA應(yīng)用的關(guān)系 6 2.3.2. CA應(yīng)用類型與模式 8 2.3.2.1. CA應(yīng)用類型 8 2.3.2.2

2、. 應(yīng)用模式 10 3 應(yīng)用流程和工作分工 14 3.1. CA應(yīng)用總體流程 14 3.2. 需求階段 17 3.2.1. 工作內(nèi)容 17 3.2.2. 參與部門與工作流程 17 3.3. 設(shè)計階段 17 3.3.1. 工作內(nèi)容 17 3.3.2. 參與部門與工作流程 17 3.4. 開發(fā)階段 18 3.4.1. 工作內(nèi)容 18 3.4.2. 參與部門及工作流程 18 3.5. 測試階段 18 3.5.1. 工作內(nèi)容 18 3.5.2. 參與部門及工作流程 19 3.6. 上線實施階段 20 3.6.1. 工作內(nèi)容 20 3.6.2. 參與部門及工作流程 20

3、 3.7. 運維階段 20 3.7.1. 工作內(nèi)容 20 3.7.2. 參與部門及工作內(nèi)容 20 4 CA應(yīng)用設(shè)計和實現(xiàn)的內(nèi)容 20 4.1. 確定CA應(yīng)用需求類型 21 4.2. 確定實現(xiàn)方式 21 4.2.1. 軟件方式 21 4.2.2. 硬件方式 22 4.3. 其他內(nèi)容 22 4.3.1. 撤銷列表下載方式 22 4.3.2. 交叉認證 23 4.3.3. 多應(yīng)用加載的環(huán)境 23 4.4. 應(yīng)用策略 23 4.4.1. 實現(xiàn)方式 23 4.4.2. 撤銷列表下載方式 24 4.4.3. CA應(yīng)用模式實現(xiàn)方式 24 4.4.3.1. B/S模式實現(xiàn)方式

4、 24 4.4.3.2. C/S模式實現(xiàn)方式 25 4.4.3.3. S/S模式實現(xiàn)方式 25 4.4.3.4. 混合模式實現(xiàn)方式 26 4.4.4. 其他情況 26 4.5. CA應(yīng)用模板 26 5 附錄 28 5.1. CA應(yīng)用開發(fā)包獲取方式 28 5.2. 人民銀行CA系統(tǒng)DN規(guī)則 33 III 1 概況 1.1. 編寫目的 本指引是人民銀行信息系統(tǒng)電子認證應(yīng)用（以下簡稱“CA應(yīng)用”）的指導(dǎo)性文件。CA應(yīng)用貫穿信息系統(tǒng)建設(shè)的設(shè)計、開發(fā)、測試、上線實施及運行維護的各個階段，通過該指引規(guī)范CA應(yīng)用的工作流程，以便各相關(guān)部門（業(yè)務(wù)部門、管理部門、建設(shè)部門、運維部門

5、）明確職責(zé)、保證CA應(yīng)用的順利進行。 本指引解釋權(quán)歸屬人民銀行總行科技司。 1.2. 適用范圍 本指引適用于人民銀行內(nèi)部及與人民銀行有信息系統(tǒng)互聯(lián)的外部機構(gòu)。其中人民銀行內(nèi)部各部門包括系統(tǒng)管理部門、業(yè)務(wù)部門、系統(tǒng)建設(shè)部門、系統(tǒng)運維部門等；外部機構(gòu)的使用范圍根據(jù)互聯(lián)機構(gòu)的具體情況由人民銀行業(yè)務(wù)主管部門和科技司共同決定。 使用CA安全認證服務(wù)的機構(gòu)、部門和個人，都需要嚴格遵守本指引。 1.3. 指引內(nèi)容簡介 本指引在簡單介紹人民銀行CA系統(tǒng)基本情況的基礎(chǔ)上，重點介紹了CA應(yīng)用涉及的工作內(nèi)容、應(yīng)用策略、應(yīng)用流程和工作分工，并在附錄中給出與CA應(yīng)用有關(guān)的管理制度和技術(shù)文檔。 1.4. 術(shù)

6、語定義 PKI：Public Key Infrastructure即公開密鑰基礎(chǔ)設(shè)施，是以公鑰（非對稱）密碼學(xué)為基礎(chǔ)，為信息系統(tǒng)提供安全認證服務(wù)，構(gòu)建網(wǎng)絡(luò)信任體系的安全基礎(chǔ)平臺。 CA：Certification Authority即認證中心。CA是PKI的核心，受信任的第三方，生成用戶的數(shù)字證書，解決公鑰體系中公鑰的合法性問題。本指引中CA專指人民銀行內(nèi)部CA系統(tǒng)。 RA：Registration Authority即注冊機構(gòu)，數(shù)字證書注冊審批機構(gòu)。負責(zé)完成證書的發(fā)放、撤銷、更新、恢復(fù)、凍結(jié)和解凍等管理功能。本指引中RA專指人民銀行RA系統(tǒng)。 LRA：Local Registrati

7、on Authority即證書注冊審核受理點，RA的組成部分，作為證書發(fā)放受理點，直接面向用戶。 KMC：Key Management Centre密鑰管理中心，提供加密密鑰的產(chǎn)生、存儲、更新、分發(fā)、查詢、撤消、歸檔、備份及恢復(fù)等管理功能。 LDAP：Lightweight Directory Access Protocol 目錄服務(wù)器，用以存儲和發(fā)布用戶的證書信息、證書撤銷列表，用戶在使用證書時通過訪問目錄服務(wù)器，驗證證書的有效性。 CRL：Certificate Revocation List證書撤消列表，通過查詢CRL用以驗證證書的使用狀態(tài)是否為撤消或凍結(jié)，判斷證書的有效性。 O

8、CSP：Online Certificate Status Protocoal即在線證書狀態(tài)協(xié)議，與CRL以及證書狀態(tài)相結(jié)合，能為用戶提供高效、實時的證書狀態(tài)查詢服務(wù)。 TSA：Time Stamp Authority即時間戳服務(wù)，負責(zé)對所有請求時間戳服務(wù)的請求進行簽發(fā)處理，并對時間戳進行相應(yīng)的管理。 數(shù)字證書：由CA認證中心發(fā)放的，能進行身份驗證的一種權(quán)威性文件，用戶通過數(shù)字證書來證明自己的身份和識別對方的身份。數(shù)字證書是一段包含用戶或服務(wù)器身份信息、公鑰信息以及身份驗證機構(gòu)數(shù)字簽名的文件，人民銀行CA證書格式及證書內(nèi)容遵循X.509標準。 數(shù)字簽名：數(shù)字簽名是指用戶用自己的私鑰對業(yè)務(wù)

9、操作數(shù)據(jù)、數(shù)據(jù)傳輸?shù)认嚓P(guān)信息的哈希摘要用非對稱密碼算法進行加密所得的數(shù)據(jù)，實現(xiàn)對業(yè)務(wù)操作數(shù)據(jù)及數(shù)據(jù)發(fā)送者的身份認證，防止抵賴，保證數(shù)據(jù)的完整性。 數(shù)字信封：結(jié)合對稱密碼和非對成密碼技術(shù)，用以保證數(shù)據(jù)傳輸安全的加密方法。 個人證書：向個人使用者發(fā)放的數(shù)字證書，用以實現(xiàn)應(yīng)用系統(tǒng)中個人操作所需的安全服務(wù)。個人證書的保管使用由使用者本人負責(zé)。人民銀行CA個人證書分為：RA管理員證書、LRA管理員證書、LRA操作員證書、個人單密鑰證書。其中RA管理員證書、LRA管理員證書、LRA操作員證書均可用于管理或使用LRA系統(tǒng)；個人單密鑰證書為個人普通證書。 服務(wù)器證書：發(fā)放給應(yīng)用系統(tǒng)中服務(wù)器的數(shù)字證書，用

10、以建立服務(wù)器和客戶端之間的安全信任關(guān)系。 設(shè)備證書：發(fā)放給網(wǎng)絡(luò)設(shè)備的數(shù)字證書，用以實現(xiàn)該設(shè)備所需的安全服務(wù)。 機構(gòu)證書：向與應(yīng)用系統(tǒng)互聯(lián)的外部機構(gòu)發(fā)放的證書，該證書的使用對象為機構(gòu)。它解決的是人民銀行信息系統(tǒng)與外部機構(gòu)系統(tǒng)互聯(lián)時，對所連接的機構(gòu)實體進行認證的問題，而不針對這個機構(gòu)中的具體操作人員，這也是業(yè)務(wù)數(shù)據(jù)交換的延伸超出了管轄范圍情況下的一種解決辦法。機構(gòu)證書在應(yīng)用系統(tǒng)中的具體表現(xiàn)形式為服務(wù)器證書。 證書責(zé)任人：個人證書的證書責(zé)任人是證書持有（使用）人；服務(wù)器、設(shè)備證書責(zé)任人是證書申請部門為該證書指定的證書管理責(zé)任人。 SSL：Security Socket Layer即安全套接層

11、協(xié)議，通信雙方通過數(shù)字證書，建立數(shù)據(jù)傳輸安全通道的協(xié)議。 身份認證：驗證一個主體身份的過程，即驗證者根據(jù)被驗證者提供的或擁有的身份鑒別信息用以確認其身份是否真實的過程。 數(shù)據(jù)機密性：信息具有的一種內(nèi)在性質(zhì)，這一性質(zhì)要求信息不泄露給非授權(quán)的個人、實體或進程，不為其所用。 數(shù)據(jù)完整性：信息具有的一種內(nèi)在性質(zhì)，這一性質(zhì)表明信息沒有遭受以非授權(quán)方式所作的篡改或破壞。 數(shù)據(jù)不可否認性：信息具有的一種內(nèi)在性質(zhì)，確保個人或設(shè)備不能否認其發(fā)送過的信息及交易，也稱抗抵賴性。 2 CA系統(tǒng)及應(yīng)用簡介 人民銀行內(nèi)部CA系統(tǒng)（以下簡稱“CA系統(tǒng)”）作為人民銀行的安全基礎(chǔ)設(shè)施，為人民銀行信息系統(tǒng)提供身份認證

12、、防抵賴、完整性和保密性的安全服務(wù)。 根據(jù)CA系統(tǒng)運行和CA應(yīng)用的實際需要，CA系統(tǒng)分為生產(chǎn)系統(tǒng)和測試系統(tǒng)兩部分，下面對兩個系統(tǒng)分別進行介紹。 2.1. 生產(chǎn)系統(tǒng) CA生產(chǎn)系統(tǒng)的體系結(jié)構(gòu)如下圖所示： 從目錄服務(wù)器 圖－1 人民銀行CA生產(chǎn)系統(tǒng) 其中： l CA生產(chǎn)系統(tǒng)分為CA中心和RA證書注冊系統(tǒng)。 l 其中CA中心作為后臺系統(tǒng)生產(chǎn)證書，并提供證書及撤銷列表的查詢服務(wù)。目前CA中心部署在金電公司，由金電公司負責(zé)CA中心運維和CA應(yīng)用的技術(shù)支持工作。 l RA系統(tǒng)作為證書發(fā)放系統(tǒng)面向用戶，負責(zé)證書申請的審核和發(fā)放。RA系統(tǒng)部署在總行信管中心，由總行信管中心負責(zé)運維，

13、總行信管中心和上?？偛?營管部/分行/省會中支的管理員、操作員通過Web界面登陸RA系統(tǒng)進行證書相關(guān)操作。 2.2. 測試系統(tǒng) 測試系統(tǒng)的體系結(jié)構(gòu)圖如下： 圖－2 人民銀行CA測試系統(tǒng) 其中： l 測試系統(tǒng)整體部署在金電公司，由金電公司服務(wù)運維。 l 金電公司的工作包括測試證書的生產(chǎn)、發(fā)放。 l 提供CA應(yīng)用測試技術(shù)支持。 2.3. CA應(yīng)用現(xiàn)狀 2.3.1. CA系統(tǒng)與CA應(yīng)用的關(guān)系 CA系統(tǒng)作為人民銀行的安全基礎(chǔ)設(shè)施，提供數(shù)字證書簽發(fā)、密鑰管理、證書查詢等功能，應(yīng)用系統(tǒng)根據(jù)CA應(yīng)用工具（開發(fā)包或硬件設(shè)備），通過接口開發(fā)實現(xiàn)自身的簽名、驗簽名等功能模塊，從而滿足

14、應(yīng)用系統(tǒng)身份認證、防抵賴、完整性、保密性的安全需求。 CA系統(tǒng)及CA應(yīng)用的現(xiàn)狀如下圖所示： 圖－3 CA系統(tǒng)及CA應(yīng)用現(xiàn)狀示意圖 其中： l 圖中左半部分為CA系統(tǒng)示意圖，右半部分為應(yīng)用系統(tǒng)的CA實現(xiàn)示意圖。 l 圖中虛線為RA系統(tǒng)面向用戶離線方式的證書申請、發(fā)放。 個人證書 申請證書時，USBKey產(chǎn)生密鑰對，私鑰駐留USBKey中，不可導(dǎo)出，實現(xiàn)對私鑰的硬件級保護，同時在應(yīng)用中數(shù)字簽名的密碼運算在USBKey內(nèi)完成。 服務(wù)器證書 服務(wù)器證書的申請、發(fā)放，根據(jù)確定的CA應(yīng)用方式有所不同。如果是軟件方式，則服務(wù)器的管理員需要使用專用工具產(chǎn)生密鑰對及證書申請文件，提交

15、給發(fā)證終端LRA，由CA中心生產(chǎn)簽名證書后，返給系統(tǒng)管理員，管理員用該工具將本地保存的私鑰和簽名證書一起轉(zhuǎn)換為系統(tǒng)所需的證書文件。如果是硬件方式，需要硬件支持申請證書。 l 圖中黑色加粗線條表示在CA應(yīng)用中，應(yīng)用系統(tǒng)在線（或離線）查詢證書撤銷列表（CRL），驗證證書的有效性。 l 根據(jù)具體應(yīng)用系統(tǒng)的需求，在客戶端和服務(wù)器端分別部署所需的CA應(yīng)用安全套件。安全套件的內(nèi)容包括開發(fā)包、硬件設(shè)備、根證書、用戶證書、撤銷列表。 2.3.2. CA應(yīng)用類型與模式 2.3.2.1. CA應(yīng)用類型 隨著CA應(yīng)用的推廣，我行應(yīng)用系統(tǒng)數(shù)據(jù)集中以及資源整合的不斷深入，根據(jù)不同的安全需求，可將CA應(yīng)用分為如

16、下幾種不同類型。 一、安全需求說明 基于CA應(yīng)用，應(yīng)用系統(tǒng)能夠?qū)崿F(xiàn)系統(tǒng)用戶身份認證和系統(tǒng)數(shù)據(jù)傳輸安全等安全需求，其中數(shù)據(jù)傳輸安全包括數(shù)據(jù)防抵賴、完整性和保密性需求。 二、基于CA應(yīng)用實現(xiàn)信息系統(tǒng)用戶身份認證 （一） 基于SSL協(xié)議雙向認證實現(xiàn)系統(tǒng)用戶身份認證 基于SSL協(xié)議雙向認證，能夠?qū)崿F(xiàn)系統(tǒng)服務(wù)器和用戶認證，加密數(shù)據(jù)并防止數(shù)據(jù)中途被竊取，維護數(shù)據(jù)的完整性，確保數(shù)據(jù)在傳輸過程中不被改變。 （二） 基于簽名、驗簽實現(xiàn)系統(tǒng)用戶身份認證 首先在客戶端調(diào)用數(shù)字簽名的接口完成數(shù)字簽名，并生成簽名包，然后將該簽名包傳遞給服務(wù)器端，服務(wù)器端調(diào)用驗簽的接口對簽名包進行驗證，并將驗證結(jié)果返回給客

17、戶端。由于驗證簽名包時包含了完整的證書驗證功能，從而可以完成身份認證功能。 圖－4基于簽名、驗簽實現(xiàn)系統(tǒng)用戶身份認證流程 三、基于簽名/驗簽實現(xiàn)數(shù)據(jù)傳輸?shù)耐暾院头赖仲? 基于簽名/驗簽?zāi)軌驅(qū)崿F(xiàn)系統(tǒng)間數(shù)據(jù)傳輸?shù)耐暾缘姆赖仲?。系統(tǒng)A在發(fā)送數(shù)據(jù)時，將擬發(fā)送的數(shù)據(jù)進行數(shù)據(jù)簽名，并將簽名數(shù)據(jù)和擬發(fā)送的數(shù)據(jù)等一同發(fā)送給系統(tǒng)B。系統(tǒng)B基于系統(tǒng)A發(fā)送過來的數(shù)據(jù)進行驗簽，驗證書數(shù)據(jù)在傳輸過程中的完整性，實現(xiàn)數(shù)據(jù)傳輸過程中的防抵賴和完整性安全需求。 四、基于數(shù)字信封實現(xiàn)數(shù)據(jù)傳輸?shù)谋Ｃ苄? 數(shù)字信封是對稱加密和非對稱加密相結(jié)合的CA應(yīng)用，實現(xiàn)系統(tǒng)間數(shù)據(jù)傳輸?shù)谋Ｃ苄?。在進行數(shù)據(jù)傳輸時，通過生成隨機數(shù)，作

18、為對稱加密密鑰，實現(xiàn)擬發(fā)送數(shù)據(jù)的對稱加密；通過非對稱加密實現(xiàn)對稱加密密鑰的傳輸。 2.3.2.2. 應(yīng)用模式 CA應(yīng)用模式包括以下三種：B/S模式，即瀏覽器/服務(wù)器架構(gòu)下的證書應(yīng)用；C/S模式，即客戶端/服務(wù)器架構(gòu)下的證書應(yīng)用；S/S模式，即服務(wù)器/服務(wù)器架構(gòu)下的證書應(yīng)用，多為系統(tǒng)互聯(lián)。下面對這三種結(jié)構(gòu)進行詳細說明。 一、B/S結(jié)構(gòu) B/S結(jié)構(gòu)是目前普遍的應(yīng)用系統(tǒng)結(jié)構(gòu)，即客戶端以瀏覽器登錄服務(wù)器，實現(xiàn)業(yè)務(wù)操作的應(yīng)用模式。 目前主流的Web服務(wù)器和主流瀏覽器都支持SSL協(xié)議，因此身份認證可以基于SSL實現(xiàn)。但由于SSL不能有效實現(xiàn)交易/行為的抗抵賴性和關(guān)鍵數(shù)據(jù)的保密性，所以還

19、需要在瀏覽器端和服務(wù)器端增加加解密/簽名驗證模塊，來真正實現(xiàn)交易/行為的抗抵賴性和關(guān)鍵數(shù)據(jù)的保密性。 具體實現(xiàn)中，需要在瀏覽器端需要配置個人證書，服務(wù)器端需要配置服務(wù)器證書。 針對IE瀏覽器，需要在客戶端安裝CSP模塊，加解密/簽名驗證模塊可以采用ActiveX技術(shù)實現(xiàn)；針對非IE瀏覽器如Netscape等，需要在瀏覽器端安裝Pkcs#11模塊，加解密/簽名驗證模塊可以采用Plugin或XPCOM技術(shù)實現(xiàn)。圖示如下： 瀏覽器 內(nèi)置SSL模塊 Web服務(wù)器 內(nèi)置SSL模塊 CSP模塊 加解密/簽名驗證模塊 證書/私鑰介質(zhì) CSP模塊 加解密/簽名驗證模塊 證書/私鑰介質(zhì)

20、 證書身份認證 交易/行為抗抵賴性 關(guān)鍵數(shù)據(jù)保密性 圖－5 CA應(yīng)用B/S結(jié)構(gòu)圖 二、C/S結(jié)構(gòu) C/S是以前比較流行的應(yīng)用系統(tǒng)結(jié)構(gòu)，即需要在客戶端部署客戶端軟件，用戶通過客戶端軟件登錄服務(wù)器，進行業(yè)務(wù)操作。 C/S結(jié)構(gòu)一般都不支持PKI證書機制，為了實現(xiàn)證書應(yīng)用，提高系統(tǒng)安全性，必須在客戶端和服務(wù)器端增加PKI安全模塊。 （一）安全代理方式 對于安全性要求不高或無法進行開發(fā)改造的C/S系統(tǒng)，可以采用安全代理技術(shù)，實現(xiàn)證書應(yīng)用，提高身份鑒別的強度和數(shù)據(jù)傳輸?shù)陌踩?，如下圖所示： 客戶端 C 服務(wù)器端 S 證書身份認證 數(shù)據(jù)傳輸保密性 證書/私鑰介質(zhì) 證書/私

21、鑰介質(zhì) 安全代理 客戶端 安全代理 服務(wù)器 圖－6 CA應(yīng)用C/S結(jié)構(gòu)圖（1） 采用安全代理技術(shù)，需要在客戶端部署安全代理客戶端，在服務(wù)器端部署安全代理服務(wù)器，由安全代理客戶端/服務(wù)器負責(zé)實現(xiàn)PKI證書機制，對原有的客戶端和服務(wù)器端沒有影響；客戶端/服務(wù)器與安全代理客戶端/服務(wù)器之間通過TCP/IP協(xié)議進行通信。 （二）2、API接口開發(fā)方式 對于安全性要求較高且能夠進行開發(fā)改造的C/S系統(tǒng)，可以采用API接口技術(shù)進行開發(fā)，實現(xiàn)證書應(yīng)用，提高身份認證的強度，同時保證數(shù)據(jù)保密性、完整性以及交易/行為的抗抵賴性，如下圖所示： API接口包 客戶端 C 服務(wù)器端 S

22、數(shù)據(jù)完整性 交易/行為抗抵賴性 證書/私鑰介質(zhì) API接口包 證書/私鑰介質(zhì) 證書身份認證 數(shù)據(jù)保密性 圖－7 CA應(yīng)用C/S結(jié)構(gòu)圖（2） 采用API接口開發(fā)方式，需要分別在客戶端和服務(wù)器端利用API接口開發(fā)包進行接口開發(fā)改造，在客戶端/服務(wù)器端的業(yè)務(wù)處理邏輯中通過函數(shù)調(diào)用方式，調(diào)用證書API接口來實現(xiàn)PKI證書機制。 在客戶端需要配置個人證書，在服務(wù)器端需要配置服務(wù)器證書。 三、S/S結(jié)構(gòu) S/S結(jié)構(gòu)即兩個服務(wù)器之間的數(shù)據(jù)交換，一般為不同應(yīng)用系統(tǒng)之間的交換。S/S結(jié)構(gòu)一般都不支持PKI證書機制，為了實現(xiàn)證書應(yīng)用，提高系統(tǒng)安全性，必須在服務(wù)器兩端增加PKI安全模塊。

23、 1、（一）安全代理方式 對于安全性要求不是很高或無法進行開發(fā)改造的S/S系統(tǒng)，可以采用安全代理技術(shù)，實現(xiàn)證書應(yīng)用，提高身份認證的強度和數(shù)據(jù)傳輸?shù)陌踩?，如下圖所示： 服務(wù)器端 S 服務(wù)器端 S 證書身份認證 數(shù)據(jù)傳輸保密性 證書/私鑰介質(zhì) 證書/私鑰介質(zhì) 安全代理 服務(wù)器 安全代理 服務(wù)器 圖－8 CA應(yīng)用S/S結(jié)構(gòu)圖（1） 采用安全代理技術(shù)，需要在服務(wù)器兩端都部署安全代理服務(wù)器，由安全代理服務(wù)器負責(zé)實現(xiàn)PKI證書機制，對原有的服務(wù)器端沒有影響，服務(wù)器與安全代理服務(wù)器之間通過TCP/IP協(xié)議進行通信。 在服務(wù)器兩端均需要配置服務(wù)器證書。 （二）2、API

24、接口開發(fā)方式 對于安全性要求很高且能夠進行開發(fā)改造的S/S系統(tǒng)，可以采用API接口技術(shù)進行開發(fā)，實現(xiàn)證書應(yīng)用，提高身份認證的強度，同時保證數(shù)據(jù)保密性、完整性以及交易/行為的抗抵賴性，如下圖所示： API接口包 服務(wù)器端 C 服務(wù)器端 S 數(shù)據(jù)完整性 交易/行為抗抵賴性 證書/私鑰介質(zhì) API接口包 證書/私鑰介質(zhì) 證書身份認證 數(shù)據(jù)保密性 圖－9 CA應(yīng)用S/S結(jié)構(gòu)圖（2） 采用API接口開發(fā)方式，需要分別在服務(wù)器兩端利用API接口開發(fā)包進行接口開發(fā)改造，在服務(wù)器兩端的業(yè)務(wù)處理邏輯中通過函數(shù)調(diào)用方式，調(diào)用證書API接口來實現(xiàn)PKI證書機制。 在服務(wù)器兩端均需

25、要配置服務(wù)器證書。 3 應(yīng)用流程和工作分工 首先通過流程圖從整體上介紹CA應(yīng)用流程，其次根據(jù)整體流程分階段介紹工作內(nèi)容和參與部門的職責(zé)。 3.1. CA應(yīng)用總體流程 CA應(yīng)用總體流程根據(jù)CA應(yīng)用實現(xiàn)過程涉及的不同階段來確定，包括CA應(yīng)用需求提出、確認，制定CA應(yīng)用方案，方案審核確認，CA應(yīng)用開發(fā)實現(xiàn)，測試，證書發(fā)放、實施及運行維護幾個階段。詳細內(nèi)容如下： 第一步：業(yè)務(wù)部門提出CA應(yīng)用需求。 第二步：在項目管理部門協(xié)助下，由建設(shè)部門細化CA應(yīng)用需求，提交業(yè)務(wù)部門確認，建設(shè)部門根據(jù)業(yè)務(wù)部門的要求完善需求，若業(yè)務(wù)部門認可CA應(yīng)用需求，則進入第三步。 第三步：建設(shè)部門制定CA應(yīng)用方案。

26、 第四步：建設(shè)部門提交CA應(yīng)用方案到項目管理部門。 第五步：項目管理部門組織審核確認CA應(yīng)用方案。 第六步：建設(shè)部門根據(jù)項目管理部門審核意見進一步完善方案，若方案審核通過，則進入第七步。 第七步：建設(shè)部門獲取CA應(yīng)用開發(fā)包，完成CA應(yīng)用開發(fā)工作。 第八步：建設(shè)部門進行CA應(yīng)用測試。 第九步：證書發(fā)放管理部門實現(xiàn)CA數(shù)字證書發(fā)放工作。 第十步：建設(shè)部門進行CA應(yīng)用實施。 第十一步：運行部門進行系統(tǒng)運行。實施 建設(shè)部門 數(shù)字證書發(fā)放 證書發(fā)放管理部門 提出應(yīng)用需求 業(yè)務(wù)部門 細化需求 建設(shè)部門 確認需求 業(yè)務(wù)部門 制定方案 建設(shè)部門 Y N

27、 金電公司 技術(shù)支持 方案審核確認 管理部門 編碼實現(xiàn) 建設(shè)部門 測試 建設(shè)部門 運維部門 運維 圖－10 CA應(yīng)用總體流程圖 以下根據(jù)總體流程分階段的詳細描述各階段的工作內(nèi)容及參與的部門。 3.2. 需求階段 3.2.1. 工作內(nèi)容 提出CA應(yīng)用的明確需求。 3.2.2. 參與部門與工作流程 第一步：由業(yè)務(wù)部門提出身份認證、防抵賴、完整性和保密性的安全需求。 第二步：業(yè)務(wù)部門將初步的安全需求提交項目建設(shè)部門進行細化，明確在業(yè)務(wù)系統(tǒng)中，具體那些業(yè)務(wù)需要進行數(shù)字簽名。 第三步：項目建設(shè)部門將細化的需求提交業(yè)務(wù)部門進行確認。 3.3. 設(shè)計階段 3

28、.3.1. 工作內(nèi)容 基于該指引，制定CA應(yīng)用方案。 3.3.2. 參與部門與工作流程 第一步：項目建設(shè)部門根據(jù)業(yè)務(wù)部門確認的CA應(yīng)用需求及本指引，制定CA應(yīng)用方案。 第二步：項目建設(shè)部門將制定的CA應(yīng)用方案提交項目管理部門。 第三步：項目管理部門組織審核確認項目建設(shè)部門提交的CA應(yīng)用方案。 第四步：項目建設(shè)部門根據(jù)項目管理部門審核意見進一步修改完善CA應(yīng)用方案。 第五步：項目管理部門將CA應(yīng)用相關(guān)的測試、發(fā)證、技術(shù)支持等工作任務(wù)下達給金電公司和證書發(fā)放等部門。 3.4. 開發(fā)階段 3.4.1. 工作內(nèi)容 獲取CA應(yīng)用開發(fā)包，完成在應(yīng)用系統(tǒng)中的CA應(yīng)用編碼實現(xiàn)。 3.4.

29、2. 參與部門及工作流程 第一步：一、項目建設(shè)部門領(lǐng)取CA應(yīng)用開發(fā)包。 (一) 人民銀行內(nèi)部 項目建設(shè)部門首先從金電公司獲取符合系統(tǒng)開發(fā)需要的CA開發(fā)包。 (二) 外聯(lián)機構(gòu) （1） 京外外聯(lián)機構(gòu)從當(dāng)?shù)厝嗣胥y行科技處獲取CA應(yīng)用開發(fā)包。 （2） 在京外聯(lián)機構(gòu)從金電公司獲取開發(fā)包。 （3） 外聯(lián)機構(gòu)簽署開發(fā)包使用承諾書。 第二步：二、項目建設(shè)部門完成編碼工作。 第三步：三、在開發(fā)中如果需要，項目建設(shè)部門可從金電公司獲取CA應(yīng)用技術(shù)支持。 3.5. 測試階段 3.5.1. 工作內(nèi)容 對開發(fā)完成CA應(yīng)用的系統(tǒng)進行聯(lián)調(diào)測試。 3.5.2. 參與部門及工作流程 第一步：一、項目

30、建設(shè)單位向金電公司申請測試證書，并獲取測試用CA配置文件。 （一）個人測試證書申請流程 1.證書申請者向金電公司申請個人測試證書。 2.金電公司批準申請。 3.金電公司發(fā)放USBKey為介質(zhì)的測試個人證書。 4.證書申請者從金電公司領(lǐng)取測試用個人證書、測試CRL和測試根證書，并辦理領(lǐng)取登記手續(xù)。 （二）服務(wù)器測試證書（機構(gòu)測試證書）申請流程 1.證書申請部門使用專用工具生成證書申請文件，以郵件方式發(fā)送給金電公司。 2.金電公司將做好的測試證書、測試CRL和測試根證書發(fā)給申請者。 3.申請者將接收到的證書轉(zhuǎn)換為所需的PFX證書。 二、第二步：在聯(lián)調(diào)測試環(huán)境中，項目建設(shè)部門

31、完成測試證書和其他CA配置文件的系統(tǒng)配置。 第三步：三、項目建設(shè)部門進行聯(lián)調(diào)測試。 四、第四步：金電公司對聯(lián)調(diào)測試中出現(xiàn)的問題進行技術(shù)支持。 第五步：五、測試結(jié)束后，項目建設(shè)部門給出測試報告。 3.6. 上線實施階段 3.6.1. 工作內(nèi)容 配合應(yīng)用系統(tǒng)完成系統(tǒng)上線的工程實施工作。 3.6.2. 參與部門及工作流程 第一步：一、業(yè)務(wù)部門上線前一個月向證書發(fā)放管理部門申請生產(chǎn)證書。具體內(nèi)容和工作流程參照《中國人民銀行內(nèi)網(wǎng)電子認證證書管理辦法（試行）》（銀辦發(fā)[2006]153號）執(zhí)行。 第二步：二、項目建設(shè)單位從金電公司獲取生產(chǎn)系統(tǒng)CA應(yīng)用配置文件。 第三步：三、項目建設(shè)單位

32、完成系統(tǒng)關(guān)于生產(chǎn)證書和其他配置文件的系統(tǒng)配置。 3.7. 運維階段 3.7.1. 工作內(nèi)容 系統(tǒng)運維工作中，對與CA應(yīng)用相關(guān)的問題進行技術(shù)支持。 3.7.2. 參與部門及工作內(nèi)容 第一步：一、系統(tǒng)運維部門從建設(shè)單位獲取與CA應(yīng)用有關(guān)的配置文件及配置文檔。 第二步：二、明確生產(chǎn)證書的有效期，在證書到期前一個月向證書發(fā)放管理部門申請證書更新。 第三步：三、在系統(tǒng)運維中出現(xiàn)與CA有關(guān)的問題，可以從建設(shè)單位和金電公司獲取技術(shù)支持。 4 CA應(yīng)用設(shè)計和實現(xiàn)的內(nèi)容 這部分內(nèi)容主要是針對CA應(yīng)用設(shè)計和實現(xiàn)的內(nèi)容進行詳細介紹。 4.1. 確定CA應(yīng)用需求類型 CA應(yīng)用需求類型根據(jù)應(yīng)用系統(tǒng)

33、的安全需求確定是以下一種或幾種的組合。 一、證書有效性的身份認證 二、數(shù)字簽名及驗簽的身份認證、防抵賴、數(shù)據(jù)完整性 三、傳輸?shù)谋Ｃ苄? 4.2. 確定實現(xiàn)方式 4.2.1. 軟件方式 一、 軟件實現(xiàn)方式內(nèi)容 軟件實現(xiàn)方式即應(yīng)用系統(tǒng)根CA應(yīng)用開發(fā)包及開發(fā)文檔，通過API接口調(diào)用開發(fā)實現(xiàn)CA應(yīng)用。 二、 軟件版本 目前CA應(yīng)用開發(fā)包包括如下版本： （一）Java版 跨平臺應(yīng)用的開發(fā)包，不受硬件平臺、操作類型的限制。 （二）C版 1、.COM版 Windows平臺下的C語言版。 2、.C語言版 （1）AIX 32位平臺下的C語言版； （2）AIX 64位平臺下的C語

34、言版； （3）C語言源碼：對于其他操作系統(tǒng)和平臺類型環(huán)境，提供C語言源碼程序，開發(fā)單位在其環(huán)境進行編譯后使用。 三、 開發(fā)包獲取方式 參照附錄1獲取CA應(yīng)用開發(fā)包。 4.2.2. 硬件方式 一、 硬件實現(xiàn)方式內(nèi)容 通過專用的硬件設(shè)備實現(xiàn)簽名、驗簽，提高簽名私鑰的安全性，解決服務(wù)器端高并發(fā)簽名、驗簽名的性能瓶頸問題。 二、 硬件接口版本 （一）JAVA接口 （二）C接口 4.3. 其他內(nèi)容 4.3.1. 撤銷列表下載方式 目前存在兩種撤銷列表（CRL）的下載方式，自動方式和手工方式。 一、自動方式 一般服務(wù)器端認證的對象數(shù)量多，為保證證書有效性，需要實時或定期更新CR

35、L，通過查詢以確定當(dāng)前所驗證證書的有效性。 由金電公司提供撤銷列表下載工具，在應(yīng)用系統(tǒng)安裝該工具：JIT Cinas CRL 1.0.8.4 for Aix Release或JIT Cinas CRL 1.0.8.4 for Windows Release，從CA中心自動下載更新應(yīng)用系統(tǒng)本地的CRL。 二、手工方式 如果驗證的對象數(shù)量比較少，這樣不需要對CRL進行實時或定期更新，根據(jù)驗證對象證書的變化情況，通過手工更新撤銷列表，以便提供證書及撤銷列表的查詢服務(wù)。 4.3.2. 交叉認證 人民銀行與外部機構(gòu)互聯(lián)時，如果雙方分別使用各自的CA體系，那么就需要進行不同CA域的交叉認證實現(xiàn)兩

36、家CA的互通，為雙方聯(lián)網(wǎng)系統(tǒng)建立安全信任關(guān)系，保障數(shù)據(jù)傳輸安全。 在實現(xiàn)交叉認證時，雙方基于標準的簽名結(jié)果格式進行數(shù)據(jù)交換，以便實現(xiàn)數(shù)據(jù)傳輸?shù)耐暾院头赖仲嚒? 4.3.3. 多應(yīng)用加載的環(huán)境 這種情況的CA應(yīng)用和以上情況是一致的，只是在服務(wù)器證書申請時需使用服務(wù)器域名的方式，不能再使用服務(wù)器IP地址。 4.4. 應(yīng)用策略 應(yīng)用策略的內(nèi)容明確了CA應(yīng)用中需要明確的應(yīng)用類型、實現(xiàn)方式、撤銷列表下載方式、是否需要進行交叉認證，然后確定CA應(yīng)用模式。 4.4.1. 實現(xiàn)方式 一、如果服務(wù)器端既需要驗簽名、還要簽名，或服務(wù)器端并發(fā)業(yè)務(wù)量大，軟件方式無法滿足性能需求，從簽名私鑰的安全保護和性

37、能需求上考慮，需要使用硬件方式實現(xiàn)CA應(yīng)用。 二、如果服務(wù)器端只是驗簽，并發(fā)量不大，軟件方式能滿足系統(tǒng)的性能需求，則使用軟件方式實現(xiàn)，需要選擇適合的開發(fā)包類型。 4.4.2. 撤銷列表下載方式 一、一般服務(wù)器端面向大量客戶端做驗簽認證客戶端身份，需要查詢撤銷列表，驗證客戶端證書是否被撤銷。這種情況需要安裝下載工具，自動下載并更新本地的撤銷列表。 二、如果需要驗證簽名的對象數(shù)量很少，為減少系統(tǒng)壓力和不必要的網(wǎng)絡(luò)資源消耗，在被驗證的證書發(fā)生變化時，通知驗證方，采用手工方式下載并更新本地的CRL。 4.4.3. CA應(yīng)用模式實現(xiàn)方式 應(yīng)用系統(tǒng)的結(jié)構(gòu)類型決定了其CA應(yīng)用的實現(xiàn)模式，應(yīng)用系統(tǒng)

38、本身的結(jié)構(gòu)類型如果為B/S、C/S或S/S，則CA應(yīng)用對應(yīng)相應(yīng)的模式。 以下的實現(xiàn)模式主要是基于目前我行應(yīng)用系統(tǒng)本身的結(jié)構(gòu)體系及CA應(yīng)用的實際模式總結(jié)的常見幾種情況。 4.4.3.1. B/S模式實現(xiàn)方式 B/S是目前比較流行的應(yīng)用結(jié)構(gòu)。這種模式下為服務(wù)器和瀏覽器之間通過配置SSL協(xié)議，建立安全通道，實現(xiàn)數(shù)據(jù)傳輸?shù)谋Ｃ苄?，并通過服務(wù)器端的CA應(yīng)用接口開發(fā)、在瀏覽器安裝簽名/驗簽控件，實現(xiàn)身份認證、抗抵賴及數(shù)據(jù)完整性。 具體內(nèi)容如下： 一、建立SSL安全通道。 二、開發(fā)單位利用CA應(yīng)用開發(fā)包，在服務(wù)器端實現(xiàn)CA應(yīng)用中驗簽名的接口開發(fā)功能，客戶端（瀏覽器）需要安裝CA應(yīng)用的OCX控件，

39、實現(xiàn)簽名功能。 三、向客戶端發(fā)放載體為USBKey的個人證書。 四、服務(wù)器端配置根證書和證書撤銷列表（CRL）。 五、服務(wù)器端需要安裝CRL下載工具，下載并更新本地的CRL。 這種模式為常用模式，典型應(yīng)用為“貨幣金銀信息管理系統(tǒng)”。 4.4.3.2. C/S模式實現(xiàn)方式 C/S是以前比較流行的應(yīng)用系統(tǒng)結(jié)構(gòu)，目前很少應(yīng)用。這種應(yīng)用模式下服務(wù)器是可信的，服務(wù)器只對客戶端進行認證。利用數(shù)字簽名技術(shù)，服務(wù)器對客戶端進行身份認證，并防止關(guān)鍵業(yè)務(wù)的防抵賴操作，保證數(shù)據(jù)的完整性。具體內(nèi)容如下： 一、開發(fā)單位利用CA應(yīng)用開發(fā)包，在服務(wù)器端和客戶端進行接口開發(fā)，在服務(wù)器端實現(xiàn)驗簽的功能，在客戶端實

40、現(xiàn)簽名功能。 二、向客戶端發(fā)放載體為USBKey的個人證書。 三、服務(wù)器端配置根證書和證書撤銷列表（CRL）。 四、服務(wù)器端需要安裝CRL下載工具，下載并更新本地的CRL。 這種模式目前人民銀行還沒有應(yīng)用案例。 4.4.3.3. S/S模式實現(xiàn)方式 這種模式為服務(wù)器對服務(wù)器的模式,即交互雙方互為客戶端和服務(wù)器。兩端服務(wù)器互不信任，利用數(shù)字簽名技術(shù)實現(xiàn)雙向的身份認證、防抵賴和數(shù)據(jù)的完整性。具體內(nèi)容如下： 一、兩端服務(wù)器所部署的應(yīng)用系統(tǒng)開發(fā)單位要在分別完成各自的CA應(yīng)用開發(fā)（兩端的開發(fā)單位可能不同），根據(jù)各自的CA應(yīng)用開發(fā)包，在兩端分別實現(xiàn)CA應(yīng)用中簽名和驗簽名的接口開發(fā)功能。

41、二、向兩端服務(wù)器端發(fā)放服務(wù)器證書或簽名硬件設(shè)備證書。 三、兩端都要配置根證書和證書撤銷列表（CRL）。 四、是否需要安裝CRL下載工具，根據(jù)本服務(wù)器驗證的證書數(shù)量及實施的方便性決定。 這種應(yīng)用模式的典型案例為國庫信息處理系統(tǒng)（TIPS）中人民銀行與外部機構(gòu)之間數(shù)據(jù)交換中實現(xiàn)的CA應(yīng)用。 4.4.3.4. 混合模式實現(xiàn)方式 混合模式指在一個應(yīng)用系統(tǒng)中，CA實現(xiàn)的集中模式會同時出現(xiàn)兩種或兩種以上。 TIPS的CA應(yīng)用為B/S和S/S的混合模式。 4.4.4. 其他情況 隨著技術(shù)更新和新的系統(tǒng)體系架構(gòu)的出現(xiàn)，可能還會出現(xiàn)新的CA應(yīng)用模式，需要在應(yīng)用中進行總結(jié)。 4.5. CA應(yīng)用模

42、板 CA應(yīng)用模板以圖表的形式總括說明CA應(yīng)用實現(xiàn)的三種情況。 模板 類型 條件及 策略 B/S模板 C/S模板 S/S模板 備注 應(yīng)用系統(tǒng) 結(jié)構(gòu)類型 瀏覽器/服務(wù)器結(jié)構(gòu) 客戶端/服務(wù)器結(jié)構(gòu) 應(yīng)用系統(tǒng)之間的服務(wù)器/服務(wù)器結(jié)構(gòu) 信任關(guān)系 服務(wù)器可信，客戶端不可信的單向認證 服務(wù)器可信，客戶端不可信的單向認證 兩端互不信任，雙向認證 實現(xiàn) 方式 服 務(wù) 器 根據(jù)性能需要選擇： 1、軟件方式（接口或代理均可） 2、硬件方式（需要服務(wù)器與專用硬件之間開發(fā)CA應(yīng)用的通信接口） 根據(jù)性能需要選擇： 1、軟件方式（接口或代理均可） 2、硬件

43、方式（需要服務(wù)器與專用硬件之間開發(fā)CA應(yīng)用的通信接口） 硬件方式（需要服務(wù)器與專用硬件之間開發(fā)CA應(yīng)用的通信接口） 客 戶 端 安裝CA應(yīng)用控件 軟件方式（接口或代理均可） CRL下載 安裝工具，自動下載 安裝工具，自動下載 自動或手動，根據(jù)驗證方需驗證的證書數(shù)量確定 證書使用 服 務(wù) 器 1、配置根證書； 2、（如果還需要進行交叉認證，還需配置對方CA的根證書）。 1、配置根證書； 2、如果還需要進行交叉認證，還需配置對方CA的根證書。 1、配置根證書 2、如果還需要進行交叉認證，還需配置對方CA的根證書； 3、申請服務(wù)器證書 客

44、 戶 端 申請個人證書 申請個人證書 應(yīng)用情況 常用,貨金系統(tǒng)、TCBS、財務(wù)系統(tǒng)、紀檢系統(tǒng)、TIPS個人用戶的CA應(yīng)用。 不常用，人民銀行沒有案例。 常用,TIPS與外聯(lián)機構(gòu)互聯(lián)的CA應(yīng)用。 28 5 附錄 5.1. CA應(yīng)用開發(fā)包獲取方式 一、CA應(yīng)用開發(fā)包獲取流程 CA應(yīng)用開發(fā)包相關(guān)材料已下發(fā)省級數(shù)據(jù)中心，項目建設(shè)單位應(yīng)根據(jù)應(yīng)用系統(tǒng)自身實際情況選用不同的CA應(yīng)用接口實現(xiàn)方式，CA應(yīng)用流程如下： 閱讀“CA接口實現(xiàn)方式說明” 選擇CA實現(xiàn)方式 購買專用簽名服務(wù)器 硬件方式 簽署開發(fā)包使用承諾書，并領(lǐng)取開發(fā)包 軟件方式 通信接口開發(fā) 簽名驗

45、簽功能模塊開發(fā) 聯(lián)調(diào)測試：簽名服務(wù)器測試證書申請、測試環(huán)境配置、進行測試 聯(lián)調(diào)測試：生產(chǎn)系統(tǒng)服務(wù)器測試證書申請、測試環(huán)境配置、進行測試 系統(tǒng)上線：簽名服務(wù)器生產(chǎn)證書申請、生產(chǎn)環(huán)境配置、上線運行 系統(tǒng)上線：生產(chǎn)系統(tǒng)服務(wù)器生產(chǎn)證書申請、生產(chǎn)環(huán)境配置、上線運行 運行維護 針對以上流程的詳細解釋如下： 第一步：第一步：通過閱讀CA接口實現(xiàn)方式說明，項目建設(shè)單位根據(jù)自身情況選定使用軟件還是硬件方式實現(xiàn)CA應(yīng)用。 第二步：第二步：接口開發(fā) （一）獲取開發(fā)工具 1.軟件方式免費獲取開發(fā)包 人民銀行提供免費CA應(yīng)用開發(fā)包，項目建設(shè)單位需要和人民銀行簽署開發(fā)包使用承諾書，以避免開發(fā)

46、包因免費提供，在使用中出現(xiàn)商務(wù)糾紛，特別是用戶購買第三方開發(fā)服務(wù)導(dǎo)致的非授權(quán)使用。 在京的項目建設(shè)單位從人民銀行總行科技司或金電公司領(lǐng)取所需的開發(fā)包及證書申請工具KeyTool，京外項目建設(shè)單位從當(dāng)?shù)厝嗣胥y行省級機構(gòu)科技處領(lǐng)取所需的開發(fā)包和證書申請工具KeyTool。各項目建設(shè)單位應(yīng)根據(jù)自己的應(yīng)用環(huán)境領(lǐng)取適合自己的開發(fā)包。 開發(fā)包類型有JAVA、COM、C版三大類。其中C版開發(fā)包提供AIX（64）環(huán)境的開發(fā)包，其他平臺環(huán)境的C版開發(fā)包需要外聯(lián)機構(gòu)根據(jù)C版源碼編譯獲取所需開發(fā)包。 2.使用硬件方式。 根據(jù)數(shù)字簽名驗證服務(wù)器產(chǎn)品及供應(yīng)商基本要求，選擇CA簽名服務(wù)器供應(yīng)商。 （二）CA應(yīng)用

47、接口開發(fā) 1.軟件方式接口開發(fā) 項目建設(shè)單位領(lǐng)取開發(fā)包后，其開發(fā)團隊或第三方開發(fā)服務(wù)通過閱讀開發(fā)包中提供的開發(fā)文檔及開發(fā)示例，逐步完成CA應(yīng)用接口開發(fā)，實現(xiàn)簽名、驗簽等功能模塊。 2.硬件方式接口開發(fā) 購買簽名服務(wù)器硬件設(shè)備后，項目建設(shè)單位只需要基于CA簽名服務(wù)器的接口，實現(xiàn)簽名、驗簽等功能。 第三步第三步：：聯(lián)調(diào)測試 （一）軟件方式 1.需要使用專用工具（KeyTool）申請測試用服務(wù)器證書； 2.將開發(fā)環(huán)境的CA配置文件替換為測試對應(yīng)的配置文件進行聯(lián)調(diào)測試。 （二）硬件方式 1.用CA簽名服務(wù)器自帶的證書申請功能完成測試證書申請； 2.完成CA簽名服務(wù)器測試環(huán)

48、境CA配置，進行聯(lián)調(diào)測試； 第四步：第四步：系統(tǒng)上線 （一）軟件方式 1.需要使用專用工具申請上線用服務(wù)器證書； 2.將測試環(huán)境的CA配置文件替換為生產(chǎn)環(huán)境對應(yīng)的配置文件上線。 （二）硬件方式 1.用CA簽名服務(wù)器自帶的證書申請功能完成生產(chǎn)證書申請； 2.完成對簽名服務(wù)器生產(chǎn)環(huán)境CA配置，上線運行。 第五步： 第五步：運行維護 二、軟硬件CA應(yīng)用接口實現(xiàn)方式的比較 為方便選擇CA應(yīng)用接口實現(xiàn)，現(xiàn)對軟硬件CA應(yīng)用接口實現(xiàn)方式從安全性與性能、開發(fā)測試及價格幾個方面進行比較。 （一）安全性、性能比較 1、安全性 在軟件方式中，簽名私鑰以證書文件形式存儲在硬盤上，用口令保護；

49、而且簽名驗簽運算在前置主機上實現(xiàn)，需要讀出證書文件中的私鑰進行簽名驗簽，這樣私鑰在內(nèi)存中駐留，安全性相對要低。 在硬件方式中，私鑰保存在CA簽名服務(wù)器的專用硬件中，簽名驗簽運算在簽名服務(wù)器硬件中實現(xiàn)，只將簽名、驗簽結(jié)果返給前置系統(tǒng)，私鑰不出硬件，安全性更高。 2、性能 軟件方式由于簽名驗簽?zāi)K與前置系統(tǒng)共享主機資源，且簽名驗簽是CPU密集型運算，過多消耗主機資源，系統(tǒng)整體性能低。 硬件方式由于簽名服務(wù)器硬件獨立實現(xiàn)簽名驗簽，不占用主機資源，性能可實現(xiàn)數(shù)量級提高。 （二）開發(fā)、測試比較 軟件方式要在前置主機系統(tǒng)上基于開發(fā)包實現(xiàn)簽名驗簽功能，屬于緊耦合模式。 硬件方式由CA簽名服務(wù)器

50、獨立完成簽名驗簽功能，前置服務(wù)器只需要完成與簽名服務(wù)器的通信接口開發(fā)，避免了由于軟件方式緊耦合模式及應(yīng)用環(huán)境導(dǎo)致的各種問題。 （三）價格比較 軟件方式的開發(fā)包免費獲得，進行接口開發(fā)的投入相對較少；硬件方式的簽名服務(wù)器價格相對較高。 注：根據(jù)以上提供的CA接口實現(xiàn)方式說明，項目建設(shè)單位結(jié)合自身的實際情況自主選擇使用軟件或者硬件方式實現(xiàn)CA應(yīng)用。 四、技術(shù)支持 趙義斌：010-63568866-6305，13671398408，ybzhao@ 尚蕾：010-63568866-6303，shanglei@ 33 5.2. 人民銀行CA系統(tǒng)DN規(guī)則 DN組成 DN的具體內(nèi)容依

51、次由C、O、OU、CN幾部分組成。其中C用來表示國家；O用來表示組織機構(gòu)，在一般的PKI DN標準中，它可表示為發(fā)放該證書的CA名稱;OU用來表示次級組織機構(gòu)，為體現(xiàn)證書持有者的多種不同次級屬性，OU可分為兩級，即OU[1]和OU[2]來表示；CN用來表示用戶名。 人民銀行內(nèi)網(wǎng)CA DN的組成包括：C、O、OU[1]、OU[2]、CN五部分。 C定義 在DN中，C一般表示國家代碼。在人民銀行內(nèi)網(wǎng)CA中DN規(guī)則仍沿用國際慣例，定義為：C=CN;CN為中國的英文代碼。 O定義 在證書DN標準中，O一般表示組織機構(gòu)。由于人民銀行內(nèi)網(wǎng)CA為CFCA根CA的子CA，遵循CFCA的O定義規(guī)則，

52、在人民銀行內(nèi)網(wǎng)CA DN規(guī)則中，定義為：O=PBC CA，表示該證書用戶為人民銀行CA的用戶。 OU[1]定義 OU在DN標準中一般表示為證書持有者所屬的次級組織機構(gòu)。在人民銀行內(nèi)網(wǎng)CA DN規(guī)則中，OU[1]體現(xiàn)發(fā)放證書的RA系統(tǒng)和LRA機構(gòu)。 RA系統(tǒng)使用RA系統(tǒng)編碼表示。RA系統(tǒng)編號為1位字符，從“1”開始編碼，每新增RA系統(tǒng)時依次遞增，具體如下： RA系統(tǒng) RA系統(tǒng)編碼 信管中心RA系統(tǒng) 1 LRA機構(gòu)使用LRA所在組織的組織機構(gòu)編碼表示。 OU[1]具體定義為：LRA組織機構(gòu)編碼@RA系統(tǒng)編碼。LRA組織機構(gòu)編碼與RA系統(tǒng)編碼之間以分隔符“@”分隔。 OU[1]示

53、例： OU[1]=113101000@1 表示為人行內(nèi)網(wǎng)CA信管中心RA系統(tǒng)河北石家莊中心支行LRA受理點所發(fā)證書 OU[2]定義 OU在DN標準中一般表示為證書持有者從屬的次級組織機構(gòu)。人民銀行內(nèi)網(wǎng)CA DN規(guī)則中，將OU[2]定義為發(fā)放的不同證書類型，包括人員類和設(shè)備類兩個大類，具體而言包括以下五種子類： ● 個人單密鑰證書，名稱為：Operator 個人單密鑰證書，是頒發(fā)給人行工作人員的單密鑰證書，屬于人員類證書。所謂單密鑰證書，即證書持有者只有一張數(shù)字證書，使用該證書來完成相應(yīng)的證書安全應(yīng)用操作。 示例：OU[2]=Operator ● 個人雙密鑰證書，名稱為：Advan

54、ced Operator 個人雙密鑰證書，是頒發(fā)給人行工作人員的雙密鑰證書，屬于人員類證書。所謂雙密鑰證書，即證書持有者擁有加密、簽名兩張數(shù)字證書，加密證書用于加密目的、簽名證書用于簽名目的。 示例：OU[2]=Advanced Operator ● 服務(wù)器證書，名稱為：Server 服務(wù)器證書，是特指頒發(fā)給通用WEB服務(wù)器（如IIS、Apache等）和應(yīng)用服務(wù)器（如Weblogic、Websphere）的證書，屬于設(shè)備類證書。 示例：OU[2]= Server ●設(shè)備證書，名稱為：Equipment 設(shè)備證書，是指頒發(fā)給硬件設(shè)備和軟件系統(tǒng)的證書，其適用范圍除前述適用服務(wù)器證書以

55、外的所有設(shè)備和軟件系統(tǒng)。在本DN規(guī)則中，設(shè)備證書目前僅適用網(wǎng)絡(luò)設(shè)備。 示例：OU[2]= Equipment ● RA操作員證書，名稱為：Ra Operator RA操作員證書，特指頒發(fā)給RA系統(tǒng)所有操作員和管理員的數(shù)字證書，它屬于人員類證書。 示例：OU[2]=Ra Operator 描述證書類型的每個英文單詞，第一個字母大寫，其余小寫。 根據(jù)業(yè)務(wù)系統(tǒng)的實際需要，可以擴充更多的證書類型，如：代碼簽名證書等等。 CN定義 CN的組成 CN是證書持有者的通用名（common name），它用以表征證書持有者的個體特性。它包括以下幾個字段： ● ☆主版本號：DN規(guī)則的主版本號，

56、目前為“01” ● ☆次版本號：DN規(guī)則的次版本號，目前為“0” ● ☆證件類型：表征證書持有者的證件類型，具體見0 ● ☆證件號碼: 表征證書持有者的證件的號碼。 ● ☆組織機構(gòu)類別：證書持有者所屬的組織機構(gòu)類別代碼。 ● ☆組織機構(gòu)編碼：證書持有者所屬的組織機構(gòu)編碼。 ● ☆擴展內(nèi)容：可自定義的擴展內(nèi)容。 ● ☆證書持有者順序號：表示該證書為證書持有者的第幾張證書，長度為1位字符，目前為“1”。 證件類型 DN中所包含的證件類型通過一位字符的編碼形式來體現(xiàn)，目前人民銀行CA系統(tǒng)只允許使用身份證作為證件，具體編碼規(guī)則如下： 證件類型 證件類型編碼 身份證 0 設(shè)備

57、類證書，目前已知包括服務(wù)器和網(wǎng)絡(luò)設(shè)備。其證件類型編碼規(guī)則為： 證件類型編碼 服務(wù)器證書 6 設(shè)備證書 M 證件號碼 證件號碼域填寫符合對應(yīng)的證件類型的證件號碼內(nèi)容，具體規(guī)則如下： 證書類型 證件類型 證件號碼 證件號碼的解釋說明 個人單密鑰證書、個人雙密鑰證書、RA操作員證書 0、1、B、C、E、F、G 證件號碼 如申請證書時使用身份證，則“證件號碼”填身份證號碼 服務(wù)器證書 6 IP地址或域名 設(shè)備證書 M 網(wǎng)絡(luò)設(shè)備名稱，長度為3位字符 網(wǎng)絡(luò)設(shè)備名稱的編碼規(guī)則，見附件二《人民銀行內(nèi)網(wǎng)統(tǒng)一CA認證基礎(chǔ)設(shè)施建設(shè)數(shù)字證書DN網(wǎng)絡(luò)設(shè)備編碼規(guī)則》。

58、 證件類型及證件號碼示例： ● 0110101197201203264：表示證書持有者，是持身份證申請人員類數(shù)字證書，該證書持有者身份證號為“110101197201203264”。 ● 611.28.1.1：表示該張服務(wù)器證書持有者為一臺服務(wù)器，其IP地址為11.28.1.1。 ● M03：表示該設(shè)備證書持有者，為編號“03”的一臺路由器。 組織機構(gòu)類別 組織機構(gòu)類別由3位字符編碼表示，具體表示如下： 組織機構(gòu)類別 編碼 中國人民銀行 489 根據(jù)中組部代碼手冊，人民銀行代碼為“489”。根據(jù)業(yè)務(wù)系統(tǒng)需要，有人民銀行以外單位需要使用數(shù)字證書時，組織機構(gòu)類別編碼表可以進

59、行擴充。 組織機構(gòu)編碼 組織機構(gòu)編碼為6位或9位字符編碼表示。 擴展內(nèi)容 擴展內(nèi)容包括為由業(yè)務(wù)系統(tǒng)或用戶自行定義內(nèi)容，該內(nèi)容為非標準內(nèi)容。 對于人員證書，該部分內(nèi)容包括：人員拼音名和自定義內(nèi)容。具體定義為： 字段名 長度 解釋說明 拼音名長度 1字符位 標識拼音名的長度 拼音名 由”拼音名長度”定義其長度 人員的姓名全拼，使用小寫字母 自定義內(nèi)容 只受DN總長約束 用戶或業(yè)務(wù)系統(tǒng)自行定義，可為空 對于設(shè)備證書，該內(nèi)容為自定義內(nèi)容，也可為空。 CN規(guī)則示例 字段名 （長度） RA操作員證書 個人單密鑰、雙密鑰證書 設(shè)備證書 服務(wù)器證書 主版本號

60、 （2位） 01 01 01 01 次版本號 （1位） 0 0 0 0 @ 分隔符號 證件類型 （1位） 0：居民身份證 0：居民身份證 M：設(shè)備 6：服務(wù)器 證件號碼 相應(yīng)的證件號碼 相應(yīng)的證件號碼 網(wǎng)絡(luò)設(shè)備名稱 IP地址或域名 @ 分隔符號 組織機構(gòu)類別（3位） 489：中國人民銀行 組織機構(gòu)編碼（6或9位） 組織機構(gòu)編碼 @ 分隔符號 擴展內(nèi)容 姓名長度＋姓名全拼音+可由LRA自定義內(nèi)容 姓名長度＋姓名全拼音+可由LRA自定義內(nèi)容 可由LRA自定義內(nèi)容（可以是英文/拼音名） 可由LRA自定義內(nèi)容

61、（可以是英文/拼音名） @ 分隔符號 證書持有者順序號 （1位） 證書持有者的證書順序號，目前為“1” cn實例 010@0110101197201203264@489111000@bliuxiaogang@1 010@0110101197201203264@489111000@bliuxiaogang@1 010@M03@489111000@ @1 010@6210.73.40.41@489111000 @@1 注： 分隔符（@）為保留字符，CN內(nèi)各字段內(nèi)容均不得使用。 補充說明 ● 1）在DN中，可以使用除專用字符和特殊字符外的所有ASCII字符。專用字符為反斜杠

62、（“\”）和雙引號(“"”)，由于在DN中有特殊含義，不能用在DN中。另外，不允許在cn中包含特殊字符（“，” 、“=” 、“+” 、“#” 、“<” 、“>” 、“;” ） 由于存在不可見的ASCII字符，不便于用戶使用，下面給出本規(guī)則中所有可用的ASCII字符列表（ASCII值為十進制數(shù)值）： ASCII值 字符 032 空格 033 ! 036 $ 037 % 038 & 039 ‘ 040 ( 041 ) 042 * 045 - 046 . 047 / 048~057 0~9 058 : 065 ? 065~090 A~Z 091 [ 093 ] 094 ^ 095 — 096 ` 097~122 a~z 123 { 125 } 126 ~ ● 2）考慮到人民銀行業(yè)務(wù)系統(tǒng)使用漢字字符集的多樣性，在人民銀行內(nèi)網(wǎng)CA/DN規(guī)則中不使用漢字。 ● 3)證書DN總長不超過255位字符。 42