中國工商銀行銀企互連系統(tǒng)企業(yè)開發(fā)手冊(初稿)_第1頁
中國工商銀行銀企互連系統(tǒng)企業(yè)開發(fā)手冊(初稿)_第2頁
中國工商銀行銀企互連系統(tǒng)企業(yè)開發(fā)手冊(初稿)_第3頁
中國工商銀行銀企互連系統(tǒng)企業(yè)開發(fā)手冊(初稿)_第4頁
中國工商銀行銀企互連系統(tǒng)企業(yè)開發(fā)手冊(初稿)_第5頁
已閱讀5頁,還剩10頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認領(lǐng)

文檔簡介

1、第1章概述銀企互聯(lián)面向大的集團客戶,提供與企業(yè)ERP系統(tǒng)直連的平臺,銀企互聯(lián)面向大的集團客戶,提供與企業(yè)ERP系統(tǒng)直連的平臺,為工行的現(xiàn)金管理服務提供多渠道和客戶化支 持。企業(yè)ERP系統(tǒng)通過HTTPS協(xié)議與工行系統(tǒng)進行連接并向銀企互聯(lián)前置發(fā)送數(shù)據(jù),數(shù) 據(jù)的接口格式使用標準的 xml數(shù)據(jù)格式,但雙方通訊的過程中則需要遵守下文描述的規(guī)定。 銀企互聯(lián)前置接到企業(yè)數(shù)據(jù)后進行一系列的檢查后完成交易,并將處理結(jié)果以企業(yè)便于處 理的形式返回給企業(yè)。在安全保證方面,通訊層的安全保證是HTTPS協(xié)議。企業(yè)如需使用銀企互聯(lián)系統(tǒng),要辦理有關(guān)注冊手續(xù),并審領(lǐng)證書。企業(yè)進行結(jié)算類交易時,如果涉及到授權(quán)過程,企業(yè)需要在企

2、業(yè)網(wǎng)銀系統(tǒng)中完成相關(guān) 授權(quán)動作。銀企互連系統(tǒng)將企業(yè)提交的支付指令或者授權(quán)成功后的指令當作最終轉(zhuǎn)賬指 令,根據(jù)提交指令的證書ID檢查收付方帳號等合法性,以保證所提交指令在權(quán)限允許范圍內(nèi)進行操作。第2章總體方案介紹2.1 總體網(wǎng)絡(luò)結(jié)構(gòu)圖銀企互聯(lián)系統(tǒng)上圖企業(yè)ERP系統(tǒng)1采用的是非NC方式接入的客戶;企業(yè) ERP系統(tǒng)2采用的是NC方式 接入的客戶;2.2 企業(yè)端安全服務器簡介它有兩個可以配置的端口分別用于加密和簽名/驗簽服務,如下圖所示(假設(shè)1為加密端口,2為簽名/驗簽端口)。1 (加密)https交易請求包NetSafe Client2 (簽名/驗簽)1 . http交易請求包 .2 .交易結(jié)果1

3、.簽名/驗簽請求 .2 .簽名/驗簽結(jié)果具體使用時,企業(yè)應用向工行提交交易請求時,可以依照http協(xié)議向NetSafe Client的端口 1發(fā)送請求。接到請求后,NetSafe Client使用企業(yè)證書將 http請求包轉(zhuǎn)換成https請求包發(fā)往工行端服務器;如果需要對某些交易數(shù)據(jù)進行簽名,則企業(yè)應用需要與簽名端口建立Socket連接并將待簽名數(shù)據(jù)發(fā)往端口 2 ,然后接收端口 2的簽名結(jié)果,之后再將包含簽 名信息的交易請求發(fā)往端口1而完成整個交易請求過程。對簽名還是驗簽名請求的區(qū)分則是通過http包頭來進行。Content-Type: INFOSEC_SIGN/1.0 和 Content-T

4、ype: INFOSEC_VERIFY_SIGN/1.0 分別用于標識簽名請求 和驗簽名請求,而 Content-Type: INFOSEC_SIGN_RESULT/1.0 和 Content-Type: INFOSEC_VERIFY_SIGN_RESULT/1.0 分另用于標識簽名和驗簽名的返回結(jié)果。為方便起見,可以將 NetSafe Client的兩個服務端口邏輯地稱為兩臺服務器,NetSafeClient的加密服務器和簽名服務器。2.3安全控制介紹對于NC方式接入的客戶企業(yè)向工行提交的交易數(shù)據(jù),必須通過企業(yè)方的NetSafe Client進行與工行服務器的連接,接口確定需要簽名的數(shù)據(jù)也必

5、須由NetSafe Client的簽名服務器簽名后組成規(guī)定的數(shù)據(jù)包格式后,通過 NetSafe Client提交工行,這樣可以保證企業(yè) 數(shù)據(jù)以及相關(guān)信息不被惡意篡改。數(shù)據(jù)全部由NetSafe Client負責轉(zhuǎn)發(fā),使NetSafe Client成為架設(shè)在企業(yè)現(xiàn)場的工 行接入服務器。而企業(yè)與工行之間安全的連接,由NetSafe Client和工行安全代理服務器NetSafe 保證; 工行接收到企業(yè)提交過來的部分關(guān)鍵交易數(shù)據(jù)后,需要解密并驗證企業(yè)的數(shù)字簽名,以防止第三方假冒企業(yè)的行為。對于非 NC 方式接入的客戶企業(yè)向工行提交交易數(shù)據(jù)時的安全控制企業(yè) ERP 與銀企互連系統(tǒng)之間使用HTTPS 協(xié)議

6、通訊。企業(yè)可以選擇是否對交易數(shù)據(jù)進行對稱加密,目前系統(tǒng)支持的算法有DES 與3DES。進行對稱加密可以防止第三方截獲交易的信息。而加密中需要用到的密鑰由企業(yè)與工行共同約定。(加密功能暫不支持)企業(yè)需要對其發(fā)送的指令數(shù)據(jù)進行數(shù)字簽名,簽名中使用的證書可以是企業(yè)證書也可以是工行證書,其中簽名使用的算法是SHA1withRSA 。進行數(shù)字簽名可以防止第三方假冒企業(yè)的行為。工行向企業(yè)發(fā)送結(jié)果信息時的安全控制企業(yè) ERP 與銀企互連系統(tǒng)之間使用HTTPS 協(xié)議通訊。企業(yè)可選擇是否對返回數(shù)據(jù)進行對稱加密,方法與上文相同。工行對部分關(guān)鍵交易返回信息進行數(shù)字簽名。第 3 章 重點說明所有的交易請求包中“包序列

7、 ID”字段(PackagelD)由企業(yè)產(chǎn)生,產(chǎn)生規(guī)則為當前日期 (北京時間,格式為 yyyyMMdd ) 7位序列號(例如 200212230000001 , 為 2002年 12 月 23 日發(fā)送的一個交易請求包的包序列ID ) 。 在一個企業(yè)代碼下當日包序列ID必須唯一。工行處理完畢之后將該字段原值返回,即所有的交易返回包中 “包序列ID”字段( PackageID) 。轉(zhuǎn) 帳交易請求包中“簽名時間”字段(SignTime) ,格式為yyyyMMddhhmmssSSS (例如 20021223092710568,表示2002 年 12 月 23 日 9 點 27 分 10 秒 568 毫

8、秒) 。簽名時間應為北京時間。簽名時間如果與交易請求到達工行服務器時的北京標準時間誤差過大(暫定為15 分鐘) ,交易將無法進行。此措施將可以有效地防止黑客采用重放攻擊進行干擾帳務活動的行為。同一筆交易如果因為網(wǎng)絡(luò)不正常等因素需要重新提交時,要修改轉(zhuǎn)賬交易請求包的“簽名時間字段”并重新簽名。所 有請求包和返回包中備用字段的使用主要是出于對今后擴展的考慮,如果以后需要增加企業(yè)上送的項目或者返回給企業(yè)的信息,不必再改變交易包格式。目前對企業(yè)請求包來說這些備用字段的值可以送空;企業(yè)對銀行返回包中的備用字段也不必作處理。請求包中的備用字段標簽為“ ReqReserved*",返回包中的備用字

9、段標簽為“RepReserved*"(其中*為1、2、3或4,詳見接口說明文檔)。查 詢歷史明細返回數(shù)據(jù)包中交易時間(<Trans_time></Trans_time> )數(shù)值如為空,則說明該筆指令是銀行的計息交易明細。支 付查詢指令接口,方便企業(yè)對可疑、有疑問 (如網(wǎng)絡(luò)中斷,交易長時間沒有返回等)或處理完畢的轉(zhuǎn)帳指令進行查詢。企業(yè)提交要查詢的結(jié)算請求的包序列ID, 工行返回該筆轉(zhuǎn)帳指令的基本信息和狀態(tài)。本 接口說明中所有涉及金額的字段都是以分為單位(不帶小數(shù)點)。如 企業(yè)系統(tǒng)需要代理匯兌功能則企業(yè)應用需同步開發(fā)網(wǎng)點信息下載交易,以便為代理匯兌交易中收方為它行

10、情況時提供工行網(wǎng)點名稱。否則, 無需開發(fā)網(wǎng)點信息下載交易。在 網(wǎng)點信息下載功能中,由于下載數(shù)據(jù)過大且數(shù)據(jù)不會經(jīng)常更新,所以此交易控制了企業(yè)每日下載次數(shù)。目前暫定次數(shù)為每日2 次。個 人聯(lián)名卡簽權(quán)指令只支持幣種是人民幣的賬號/卡號。企 業(yè)端傳輸數(shù)據(jù)時,指定xml 編碼方式為GB2312。銀 企互聯(lián)提交包中包含“<SignTime> 簽名時間(yyyyMMddhhmmssSS) S </SignTime> ”此標簽的,說明該交易需要進行簽名處理。企 業(yè)端的程序需要對銀行返回的數(shù)據(jù)有可擴展性,以便適應今后業(yè)務的不斷發(fā)展。銀 企互連系統(tǒng)支持兩種接入方式,客戶可以任何選擇一種。第

11、一種:使用第三方NC軟件方式接入銀企互連系統(tǒng);第二種:使用非NC 方式企業(yè)直接接入銀企互連系統(tǒng);下面將區(qū)分兩類客戶分別對接入方式等相關(guān)信息進行說明。第4章銀企互聯(lián)一一NC方式接入客戶4.1 企業(yè)端系統(tǒng)環(huán)境要求4.1.1 軟 件環(huán)境對企業(yè)的ERP 系統(tǒng)無要求;工行企業(yè)端證書服務器軟件NetSafe Client 需安裝在一臺PC 機上。4.1.2 網(wǎng)絡(luò)環(huán)境企業(yè)財務系統(tǒng)通過局域網(wǎng)與工商銀行提供的NetSafe Client 連接;企業(yè)端的NetSafe Client 可以通過專線或INTERNET 與中國工商銀行銀企互連系統(tǒng)互聯(lián)。4.1.3 企業(yè)開發(fā)過程描述 企業(yè)提交交易請求數(shù)據(jù)過程

12、企業(yè)提交的交易分為兩大類:查詢類和結(jié)算類(需要進行簽名處理)。1、 查詢類:( 1 ) 企業(yè)按照工行提供的xml 包格式進行打包,在局域網(wǎng)內(nèi)通過http 協(xié)議以 POST 方式將交易包發(fā)送到NetSafe Client 的安全 http 協(xié)議服務器。http請求格式:action="http:客戶端NetSafe Client的地址和加密端口 號 /servlet/ICBCCMPAPIReqServlet?userID= 證書 ID &PackageID= 包序 列 ID &SendTime= 請求時間”請求數(shù)據(jù)格式(post方式):Version=版本號(區(qū)分版本時

13、間,暫定)&TransCode= 交易代碼(區(qū)分交易類型,每個交易固定)&BankCode=客戶的歸屬單位 &GroupCIS=客戶的歸屬編碼 &ID=客戶的證書ID (無 證書客戶可空)&PackageID=客戶的指令包序列號 (由客戶ERP系統(tǒng)產(chǎn)生,不可重復)&Cert= 客戶的證書公鑰信息(進行BASE64 編碼; NC客戶送空) &reqData= 客戶的 xml 請求數(shù)據(jù)其中:包序列ID、證書ID應根據(jù)實際情況進行更改,請求時間為企業(yè)發(fā)出該交易請求包的當前系統(tǒng)時間。post 方式最后不允許有回車等其 他 亂 字 符

14、 , TransCode交 易 名 稱 應 與xml 包 內(nèi)標 簽<TransCode></TransCode> 中 的 值 一 致 , action 中 的 證 書ID 、PackageID 與請求數(shù)據(jù)格式中的證書ID、 PackageID 、 xml 包中的證書 ID、 PackageID 的值三者相一致。(2) NetSafe Client將xml包加密后按照https協(xié)議,通過互聯(lián)網(wǎng)/專線發(fā)送 到銀行端的 NetSafe Server。(本步由NetSafe Client完成,企業(yè)無需處 理);(3) NetSafe Server將交易請求送銀企互連系統(tǒng)進行處理

15、。2、結(jié)算類:(1)企業(yè)按照工行提供的xml包格式進行打包,在局域網(wǎng)內(nèi)與 NetSafeClient的簽名端口建立 Socket連接,通過此連接向簽名端口發(fā)送http數(shù)據(jù)包。http 包頭中需包含"Content-Length"和"Content-Type”兩個屬性。其中“ Content-Length: "后面是需要簽名的二進制數(shù)據(jù)包的長度,"Content-Type:"后面是需要簽名的標記,為INFOSEC_SIGN/1.0 。(注意大小寫)http請求格式:action="http:客戶端NetSafe Client的

16、地址和簽名端口生請求數(shù)據(jù)格式:結(jié)算類請求提交的xml包NetSafe Client對xml包進行簽名后,通過http協(xié)議將簽名結(jié)果返回給企業(yè)系統(tǒng)。如簽名成功<sign>標簽與</sign>標簽之間的部分為簽名結(jié)果。NetSafe Client返回的簽名包如下:<html><head><title> 簽名Z果 </title><result>0</result></head><body><sign>MIIIXAYJKovcNAQcCo .0BlLdSgw= <

17、/sign></body></html>(2) 企業(yè)按照工行提供的 xml包格式進行打包,在局域網(wǎng)內(nèi)通過http協(xié)議以POST方式將交易包發(fā)送到 NetSafe Client的安全http協(xié)議服務器。http請求格式:action="http:客戶端NetSafe Client的地址和加密端口號/servlet/ICBCCMPAPIReqServlet?userID=證書 ID &PackageID=包序列ID &SendTime=請求時間”請求數(shù)據(jù)格式(post方式):Version=版本號(區(qū)分版本時間,暫定)&

18、TransCode=交易代碼(區(qū)分交易類型,每個交易固定)&BankCode=客戶的歸屬單位 &GroupCIS=客戶的歸屬編碼 &ID=客戶的證書ID (無證書客戶可空)&PackageID=客戶的指令包序列號 (由客戶ERP系統(tǒng)產(chǎn)生,不可重復)&Cert=客戶的證書公鑰信息(進行 BASE64編碼;NC客戶送空)&reqData=客戶的xml請求數(shù)據(jù)其中:包序列ID、證書ID應根據(jù)實際情況進行更改,請求時間為企業(yè)發(fā)出該交易請求包白當前系統(tǒng)時間。post方式最后不允許有回車等其他亂字符,TransCode 交易名稱應與 xml包內(nèi)標簽<T

19、ransCode></TransCode> 中的值一致,action 中 的證書 ID、PackageID 與請求數(shù)據(jù)格式中的證書ID、PackageID、xml包中的證書ID、PackageID 的值三者相一致。(3) NetSafe Client將企業(yè)送來的簽名包加密后按照https協(xié)議,通過互聯(lián)網(wǎng)/專線發(fā)送到工行端的 NetSafe Server,再發(fā)往工行網(wǎng)銀進行處理。(本步由NetSafe Client完成,企業(yè)無需處理)。 企業(yè)接收交易響應數(shù)據(jù)過程企業(yè)接收到數(shù)據(jù)包的格式 :reqData=交易返回包或6。2。6=錯誤代碼步驟:判斷返回數(shù)據(jù)中是否是er

20、rorCode:( 1 )如果是:根據(jù)錯誤代碼做相應處理,結(jié)束。錯誤代碼的含義參見接口說明文檔 中的附錄。( 2)如果否:企業(yè)接收到數(shù)據(jù)包的格式:reqData=交易結(jié)果包;企業(yè)根據(jù)先進行BASE64解碼,簽名返回包按照格式拆分出明文和密文,驗簽正確后對明文按工行提供的xml 包格式進行解包。對于單筆提交類指令(即存在文件級返回包的指令),返回的xml 包格式按照指令級返回包格式來處理,多筆則按照文件級返回包格式來處理。 企業(yè)接收銀行主動返回過程http請求格式:action="http:客戶ERP服務器的地址和端口號 ”請求數(shù)據(jù)格式(post方式):Version=版

21、本號(區(qū)分版本時間,暫定)&TransCode= 交易代碼(區(qū)分交易類型,每個交易固定)&BankCode=客戶的歸屬單位 &GroupCIS=客戶的歸屬編碼 &ID=客戶的證書ID (無 證書客戶可空)&PackageID=客戶的指令包序列號 (由客戶ERP系統(tǒng)產(chǎn)生,不可重復)&Cert= 客戶的證書公鑰信息(進行BASE64 編碼; NC客戶送空) &reqData= 客戶的 xml 請求數(shù)據(jù)reqData 數(shù)據(jù)格式:如果需要簽名,格式為:數(shù)字字符串:長度10 位,代表明文數(shù)據(jù)長度,不足10 位左補 0;明文: xml

22、明文,長度可變,需要上面的數(shù)據(jù)指明,雙字節(jié)字符(漢字)算作1 位長度;分隔符:ICBCCMP ;如果不需要簽名,則直接送xml 明文;以上數(shù)據(jù)經(jīng)過拼接后,再進行BASE64 編碼(僅reqData 項) 、URLEncode 編碼(全部參數(shù)項)得到最終的reqData 數(shù)據(jù)。按照以上格式將請求數(shù)據(jù)發(fā)送到企業(yè);第5章銀企互聯(lián)一一非NC方式接入客戶5.1 企業(yè)端系統(tǒng)環(huán)境要求5.1.1 軟件環(huán)境對企業(yè)的ERP 系統(tǒng)無要求;5.1.2 網(wǎng)絡(luò)環(huán)境企業(yè)財務系統(tǒng)可以通過專線與中國工商銀行銀企互連系統(tǒng)互聯(lián)。5.1.3 企業(yè)開發(fā)過程描述 企業(yè)提交交易請求數(shù)據(jù)過程( 1 ) 企業(yè)按照工行提供的xml

23、 包格式進行打包,在局域網(wǎng)內(nèi)通過http 協(xié)議以 POST 方式將交易包發(fā)送到NetSafe Client 的安全 http 協(xié)議服務器。http請求格式:action="http:客戶端NetSafe Client的地址和加密端口 號 /servlet/ICBCCMPAPIReqServlet?userID= 證書 ID &PackageID= 包序 列 ID &SendTime= 請求時間”請求數(shù)據(jù)格式(post方式):Version=版本號(區(qū)分版本時間,暫定)&TransCode= 交易代碼(區(qū)分交易類型,每個交易固定)&Bank

24、Code= 客戶的歸屬單位 &GroupCIS=客戶的歸屬編碼 &ID=客戶的證書ID (無證書客戶可空)&PackageID=客戶的指令包序列號 (由客戶ERP系統(tǒng)產(chǎn)生,不可重復)&Cert= 客戶的證書公鑰信息(進行BASE64 編碼; NC客戶送空) &reqData= 客戶的 xml 請求數(shù)據(jù)其中:包序列ID、證書ID應根據(jù)實際情況進行更改,請求時間為企業(yè)發(fā)出該交易請求包的當前系統(tǒng)時間。post 方式最后不允許有回車等其 他 亂 字 符 , TransCode 交 易 名 稱 應 與 xml 包 內(nèi) 標 簽 <TransCode>&l

25、t;/TransCode> 中 的 值 一 致 , action 中 的 證 書ID 、PackageID 與請求數(shù)據(jù)格式中的證書ID、 PackageID 、 xml 包中的證書ID、 PackageID 的值三者相一致。reqData 數(shù)據(jù)格式:如果需要簽名:數(shù)字字符串:長度10 位,代表明文數(shù)據(jù)長度,不足10 位左補0;明文: xml 明文,長度可變,需要上面的數(shù)據(jù)指明,雙字節(jié)字符(漢字)算作1 位長度;分隔符:ICBCCMP ;密文:明文經(jīng)過簽名后的數(shù)據(jù)并做BASE64 編碼;如果不需要簽名,則直接送xml 明文;以上數(shù)據(jù)經(jīng)過拼接后,再進行 BASE64 編碼得到最終的reqDa

26、ta 數(shù)據(jù)。按照以上格式將請求數(shù)據(jù)發(fā)送到工行; 企業(yè)接收交易響應數(shù)據(jù)過程企業(yè)接收到數(shù)據(jù)包的格式:reqData=交易返回包或errorCode=錯誤代碼reqData=交易返回包結(jié)構(gòu):如果交易返回包進行了簽名,則結(jié)構(gòu)為:數(shù)字字符串:長度10位,代表明文數(shù)據(jù)長度,不足10位左補0;明文:長度可變,需要上面的數(shù)據(jù)指明,雙字節(jié)字符(漢字)算作1 位長度;分隔符:ICBCCMP ;密文:明文經(jīng)過簽名后的數(shù)據(jù);如果交易返回包沒有簽名,則結(jié)構(gòu)為:明文;不論是否簽名,交易返回包均進行了BASE64編碼;步驟:判斷返回數(shù)據(jù)中是否是“ errorCode= "打頭:( 1 )如果是:根據(jù)

27、錯誤代碼做相應處理,結(jié)束。錯誤代碼的含義參見接口說明文檔中的附錄。( 2)如果否:企業(yè)接收到數(shù)據(jù)包的格式:reqData=交易結(jié)果包企業(yè)根據(jù)先進行BASE64解碼,簽名返回包按照格式拆分出明文和密文,驗簽正確后對明文按工行提供的xml包格式進行解包。對于單筆提交類指令(即存在文件級返回包的指令),返回的xml包格式按照指令級返回包格式來處理,多筆則按照文件級返回包格式來處理。 企業(yè)接收銀行主動返回過程http請求格式:action="http:客戶ERP服務器的地址和端口號 ”請求數(shù)據(jù)格式(post方式):Version=版本號(區(qū)分版本時間,暫定)&am

28、p;TransCode= 交易代碼(區(qū)分交易類型,每個交易固定)&BankCode=客戶的歸屬單位 &GroupCIS=客戶的歸屬編碼 &ID=客戶的證書ID (無證書客戶可空)&PackageID=客戶的指令包序列號 (由客戶ERP系統(tǒng)產(chǎn)生,不可重復)&Cert= 客戶的證書公鑰信息(進行BASE64 編碼; NC客戶送空) &reqData= 客戶的 xml 請求數(shù)據(jù)reqData 數(shù)據(jù)格式:如果需要簽名,格式為:數(shù)字字符串:長度10 位,代表明文數(shù)據(jù)長度,不足10 位左補0;明文: xml 明文,長度可變,需要上面的數(shù)據(jù)指明,雙字節(jié)字符(漢

29、字)算作1 位長度;分隔符:ICBCCMP ;密文:明文經(jīng)過簽名后的數(shù)據(jù)并做BASE64 編碼;如果不需要簽名,則直接送xml 明文;以上數(shù)據(jù)經(jīng)過拼接后,再進行BASE64 編碼(僅reqData 項) 、URLEncode 編碼(全部參數(shù)項)得到最終的reqData 數(shù)據(jù)。按照以上格式將請求數(shù)據(jù)發(fā)送到企業(yè);企業(yè)簽名驗簽過程在銀企互聯(lián)中,對于指令體的簽名與驗簽工作由純java 版工行簽名驗簽接口完成的。本文檔對在專業(yè)版銀企互聯(lián)中使用的接口作出描述。同時提供了一套純java 版的從企業(yè)發(fā)送指令到工行系統(tǒng)和從工行系統(tǒng)接收處理結(jié)果的例子程序。從企業(yè)發(fā)送指令到工行系統(tǒng)的例子中包括了兩方面的內(nèi)容:用企業(yè)

30、的數(shù)據(jù)層私鑰對數(shù)據(jù)進行簽名,然后用工行的通訊層公鑰進行通訊認證;從工行系統(tǒng)接收處理結(jié)果的例子中包括了兩方面的內(nèi)容:用企業(yè)的通訊層私鑰要求通訊認證,然后用工行的數(shù)據(jù)層公鑰進行數(shù)據(jù)的驗簽。企業(yè)簽名驗簽方法總體介紹接口包含icbc.jar、 InfosecCrypto_Java1_02_JDK14.jar 、 org.mortbay.jetty.jar 、 tools.jar 四個文件,使用時需要把這四個文件放置到j(luò)ava 的 classpath 目錄中。該接口建議的JDK 版本為1.4.2。 (不要使用JDK1.5 版本或者比1.4 更低版本)接口使用的詳細說明Sign(對原始數(shù)據(jù)進行數(shù)字簽名的函

31、數(shù))public static bytesign (byte src,int len,byteprivateKey,charkeyPass)Description用 rsa 算法對一段消息簽名Parameters:privateKey -為口令保護的私鑰src - 為待簽名消息len - 為待簽名消息的長度 keyPass - 為私鑰保護口令Returns:如果成功返回簽名結(jié)果, 如果失敗返回nullThrows:NoSuchProviderException -NoSuchAlgorithmException -InvalidKeyException -SignatureException -verifySign (對數(shù)字簽名進行驗簽的函數(shù))public static int verifySign (byte src,int len,bytecert,bytesign)Description 用 rsa 算法對一段簽名進行驗證Parameters:cert - 為證書src -為被簽名的消息len -為被簽名消息的長度sign - 為簽名的結(jié)果Returns:如果成功返回0, 如果其它則失敗Throws:SignatureException -NoSuchAlgorit

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
  • 6. 下載文件中如有侵權(quán)或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論