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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

17、戶端。由于驗證簽名包時包含了完整的證書驗證功能，從而可以完成身份認證功能。 圖－4基于簽名、驗簽實現系統用戶身份認證流程 三、基于簽名/驗簽實現數據傳輸的完整性和防抵賴 基于簽名/驗簽能夠實現系統間數據傳輸的完整性的防抵賴。系統A在發(fā)送數據時，將擬發(fā)送的數據進行數據簽名，并將簽名數據和擬發(fā)送的數據等一同發(fā)送給系統B。系統B基于系統A發(fā)送過來的數據進行驗簽，驗證書數據在傳輸過程中的完整性，實現數據傳輸過程中的防抵賴和完整性安全需求。 四、基于數字信封實現數據傳輸的保密性 數字信封是對稱加密和非對稱加密相結合的CA應用，實現系統間數據傳輸的保密性。在進行數據傳輸時，通過生成隨機數，作

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

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

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

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

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

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

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

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

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

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

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

29、2. 參與部門及工作流程 第一步：一、項目建設部門領取CA應用開發(fā)包。 (一) 人民銀行內部 項目建設部門首先從金電公司獲取符合系統開發(fā)需要的CA開發(fā)包。 (二) 外聯機構 （1） 京外外聯機構從當地人民銀行科技處獲取CA應用開發(fā)包。 （2） 在京外聯機構從金電公司獲取開發(fā)包。 （3） 外聯機構簽署開發(fā)包使用承諾書。 第二步：二、項目建設部門完成編碼工作。 第三步：三、在開發(fā)中如果需要，項目建設部門可從金電公司獲取CA應用技術支持。 3.5. 測試階段 3.5.1. 工作內容 對開發(fā)完成CA應用的系統進行聯調測試。 3.5.2. 參與部門及工作流程 第一步：一、項目

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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內各字段內容均不得使用。 補充說明 ● 1）在DN中，可以使用除專用字符和特殊字符外的所有ASCII字符。專用字符為反斜杠

62、（“\”）和雙引號(“"”)，由于在DN中有特殊含義，不能用在DN中。另外，不允許在cn中包含特殊字符（“，” 、“=” 、“+” 、“#” 、“<” 、“>” 、“;” ） 由于存在不可見的ASCII字符，不便于用戶使用，下面給出本規(guī)則中所有可用的ASCII字符列表（ASCII值為十進制數值）： 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è)務系統使用漢字字符集的多樣性，在人民銀行內網CA/DN規(guī)則中不使用漢字。 ● 3)證書DN總長不超過255位字符。 42