本申請屬于網絡技術領域，具體地說，涉及一種業(yè)務處理方法及裝置。

背景技術：

銀企直聯(lián)是指企業(yè)端通過企業(yè)財務系統(tǒng)直接與銀行端的銀行系統(tǒng)聯(lián)接的一種方式，企業(yè)端通過企業(yè)財務系統(tǒng)可以直接向銀行系統(tǒng)發(fā)起交易請求，實現(xiàn)對企業(yè)銀行賬戶中資金的管理和調動，完成查詢、轉賬等業(yè)務處理操作。通過銀企直聯(lián)雖然可以方便企業(yè)完成與銀行有關的交易，但是面臨的最大的問題即是安全性問題，企業(yè)身份如果被盜用，就會導致安全隱患，影響業(yè)務處理的安全性。

為了提高業(yè)務處理的安全性，現(xiàn)有技術中，通常是在企業(yè)財務系統(tǒng)中部署前置機，通過硬證書方式對企業(yè)身份進行安全認證。企業(yè)財務系統(tǒng)向銀行系統(tǒng)發(fā)起的業(yè)務請求報文，先由前置機利用硬證書進行數字簽名之后，再提交至銀行系統(tǒng)。

但是，由于硬證書經常會出現(xiàn)過熱等問題，需要手工插拔、重啟等運維操作，操作很不便利，且隨著越來越多的小微企業(yè)參與銀企直聯(lián)，小微企業(yè)的企業(yè)財務系統(tǒng)通常不是企業(yè)自創(chuàng)的，而是租用的諸如saas(software-as-a-service，軟件即服務)型的軟件系統(tǒng)，如果采用現(xiàn)有技術的這種硬證書的方式，硬證書則需設置在租用的服務器上，而租用的服務器通常部署在距離企業(yè)較遠的專有機房上，一旦硬證書出現(xiàn)問題，那么運維操作就會更加不便利，增加了安全認證的復雜性。

技術實現(xiàn)要素：

有鑒于此，本申請所要解決的技術問題是提供了一種業(yè)務處理方法及裝 置，在保證業(yè)務處理安全性的前提下，提高了安全認證的便利性。

為了解決上述技術問題，本申請公開了一種業(yè)務處理方法，包括：

客戶端將用戶提交的口令請求報文，利用第一軟證書進行簽名之后發(fā)送至服務端；由所述服務端將所述口令請求報文提交至銀行系統(tǒng)，使所述銀行系統(tǒng)對所述口令請求報文進行簽名驗證，并在簽名驗證通過之后，向所述用戶提供口令信息；

將所述用戶提交的攜帶所述口令信息的業(yè)務請求報文，利用所述第一軟證書進行簽名之后發(fā)送至所述服務端，由所述服務端將所述業(yè)務請求報文提交至所述銀行系統(tǒng)，使得所述銀行系統(tǒng)對所述業(yè)務請求報文進行簽名驗證以及對所述口令信息進行口令校驗，并在簽名驗證和口令校驗均通過之后，根據所述業(yè)務請求報文進行業(yè)務處理。

優(yōu)選地，所述客戶端將用戶提交的口令請求報文，利用第一軟證書進行簽名后發(fā)送至服務端，由所述服務端將所述口令請求報文提交至銀行系統(tǒng)，使所述銀行系統(tǒng)對所述口令請求報文進行簽名驗證，并在簽名驗證通過之后，向所述用戶提供口令信息包括：

所述客戶端將用戶提交的口令請求報文，利用第一軟證書進行簽名后發(fā)送至服務端，由所述服務端將所述口令請求報文利用第二軟證書進行簽名后提交至銀行系統(tǒng)，使所述銀行系統(tǒng)對所述口令請求報文進行簽名驗證，并在簽名驗證通過之后，向所述用戶提供口令信息；

所述將用戶提交的攜帶所述口令信息的業(yè)務請求報文，利用所述第一軟證書進行簽名后發(fā)送至所述服務端，由所述服務端將所述業(yè)務請求報文提交至所述銀行系統(tǒng)，使得所述銀行系統(tǒng)對所述業(yè)務請求報文進行簽名驗證以及對所述口令信息進行口令校驗，并在簽名驗證和口令校驗均通過之后，根據所述業(yè)務請求報文進行業(yè)務處理包括：

所述將用戶提交的攜帶所述口令信息的業(yè)務請求報文，利用所述第一軟證書進行簽名后發(fā)送至所述服務端，由所述服務端將所述業(yè)務請求報文利用所述第二軟證書進行簽名后提交至所述銀行系統(tǒng)，使得所述銀行系統(tǒng)對所述業(yè)務請求報文進行簽名驗證以及對所述口令信息進行口令校驗，并在簽名驗 證和口令校驗均通過之后，根據所述業(yè)務請求報文進行業(yè)務處理。

一種業(yè)務處理方法，包括：

服務端接收用戶通過客戶端提交的口令請求報文，其中，所述口令請求報文為所述客戶端使用第一軟證書進行簽名的報文；

將所述口令請求報文提交至銀行系統(tǒng)，使所述銀行系統(tǒng)對所述口令請求報文進行簽名驗證，并在簽名驗證通過之后，向所述用戶提供口令信息；

接收所述客戶端發(fā)送的業(yè)務請求報文，其中，所述業(yè)務請求報文為所述客戶端使用所述第一軟證書進行簽名后的報文，所述業(yè)務請求報文中攜帶所述口令信息；

將所述業(yè)務請求報文提交至所述銀行系統(tǒng)，使所述銀行系統(tǒng)對所述業(yè)務請求報文進行簽名驗證以及對所述口令信息進行口令校驗，并在簽名驗證和口令校驗均通過之后，根據所述業(yè)務請求報文進行業(yè)務處理。

優(yōu)選地，所述將所述口令請求報文提交至銀行系統(tǒng)包括：

將所述口令請求報文利用第二軟證書進行簽名后提交至所述銀行系統(tǒng)；

所述將所述業(yè)務請求報文提交至所述銀行系統(tǒng)包括：

將所述業(yè)務請求報文使用所述第二軟證書進行簽名后提交至所述銀行系統(tǒng)。

一種業(yè)務處理方法，包括：

銀行系統(tǒng)接收服務端提交的口令請求報文；其中，所述口令請求報文為客戶端將用戶提交的口令請求報文利用第一軟證書進行簽名后發(fā)送至所述服務端的；

對所述口令請求報文進行簽名驗證，并在簽名驗證通過之后，向所述用戶提供口令信息；

接收所述服務端提交的業(yè)務請求報文；其中，所述業(yè)務請求報文為所述客戶端將用戶提交的攜帶所述口令信息的業(yè)務請求報文利用所述第一軟證書進行簽名后發(fā)送至所述服務端；

對所述業(yè)務請求報文進行簽名驗證以及對所述口令信息進行口令校驗， 并在簽名驗證和口令校驗均通過之后，根據所述業(yè)務請求報文進行業(yè)務處理。

優(yōu)選地，所述銀行系統(tǒng)接收服務端提交的口令請求報文包括：

所述銀行系統(tǒng)接收服務端提交的利用第二軟證書進行簽名后的口令請求報文；

所述接收所述服務端提交的業(yè)務請求報文包括：

接收所述服務端提交的利用所述第二軟證書進行簽名后的業(yè)務請求報文。

一種業(yè)務處理裝置，包括：

第一簽名模塊，用于將用戶提交的口令請求報文，利用第一軟證書進行簽名之后發(fā)送至服務端；由所述服務端將所述口令請求報文提交至銀行系統(tǒng)，使所述銀行系統(tǒng)對所述口令請求報文進行簽名驗證，并在簽名驗證通過之后，向所述用戶提供口令信息；

第二簽名模塊，用于將所述用戶提交的攜帶所述口令信息的業(yè)務請求報文，利用所述第一軟證書進行簽名之后發(fā)送至所述服務端，由所述服務端將所述業(yè)務請求報文提交至所述銀行系統(tǒng)，使得所述銀行系統(tǒng)對所述業(yè)務請求報文進行簽名驗證以及對所述口令信息進行口令校驗，并在簽名驗證和口令校驗均通過之后，根據所述業(yè)務請求報文進行業(yè)務處理。

優(yōu)選地，所述口令請求報文具體由所述服務端將利用第二軟證書進行簽名后提交至銀行系統(tǒng)，使所述銀行系統(tǒng)對所述口令請求報文進行簽名驗證，并在簽名驗證通過之后，向所述用戶提供口令信息；

所述業(yè)務請求報文具體由所述服務端利用所述第二軟證書進行簽名后提交至所述銀行系統(tǒng)，使得所述銀行系統(tǒng)對所述業(yè)務請求報文進行簽名驗證以及對所述口令信息進行口令校驗，并在簽名驗證和口令校驗均通過之后，根據所述業(yè)務請求報文進行業(yè)務處理。

一種業(yè)務處理裝置，包括：

第一接收模塊，用于接收用戶通過客戶端提交的口令請求報文，其中，所述口令請求報文為所述客戶端使用第一軟證書進行簽名的報文；

第一發(fā)送模塊，用于將所述口令請求報文提交至銀行系統(tǒng)，使所述銀行系統(tǒng)對所述口令請求報文進行簽名驗證，并在簽名驗證通過之后，向所述用戶提供口令信息；

第二接收模塊，用于接收所述客戶端發(fā)送的業(yè)務請求報文，其中，所述業(yè)務請求報文為所述客戶端使用所述第一軟證書進行簽名后的報文，所述業(yè)務請求報文中攜帶所述口令信息；

第二發(fā)送模塊，用于將所述業(yè)務請求報文提交至所述銀行系統(tǒng)，使所述銀行系統(tǒng)對所述業(yè)務請求報文進行簽名驗證以及對所述口令信息進行口令校驗，并在簽名驗證和口令校驗均通過之后，根據所述業(yè)務請求報文進行業(yè)務處理。

優(yōu)選地，所述第一發(fā)送模塊具體用于將所述口令請求報文利用第二軟證書進行簽名后提交至所述銀行系統(tǒng)；

所述第二發(fā)送模塊具體用于將所述業(yè)務請求報文使用所述第二軟證書進行簽名后提交至所述銀行系統(tǒng)。

一種業(yè)務處理裝置，包括：

第三接收模塊，用于接收服務端提交的口令請求報文；其中，所述口令請求報文為客戶端將用戶提交的口令請求報文利用第一軟證書進行簽名后發(fā)送至所述服務端的；

第一驗證模塊，用于對所述口令請求報文進行簽名驗證，并在簽名驗證通過之后，向所述用戶提供口令信息；

第四接收模塊，用于接收所述服務端提交的業(yè)務請求報文；其中，所述業(yè)務請求報文為所述客戶端將用戶提交的攜帶所述口令信息的業(yè)務請求報文利用所述第一軟證書進行簽名后發(fā)送至所述服務端；

第二驗證模塊，用于對所述業(yè)務請求報文進行簽名驗證以及對所述口令信息進行口令校驗，并在簽名驗證和口令校驗均通過之后，根據所述業(yè)務請求報文進行業(yè)務處理。

優(yōu)選地，所述第三接收模塊具體用于接收接收服務端提交的利用第二軟證書進行簽名后的口令請求報文；

所述第四接收模塊，具體用于接收所述服務端提交的利用所述第二軟證書進行簽名后的業(yè)務請求報文。

與現(xiàn)有技術相比，本申請可以獲得包括以下技術效果：

本申請實施例中，用戶通過客戶端首先向服務端提交口令請求報文，并由客戶端利用軟證書對口令請求報文進行簽名，從而銀行系統(tǒng)接收到服務端提交的口令請求報文，對口令請求報文進行簽名驗證，確認用戶身份，并在驗證通過之后，向用戶提供口令信息；從而用戶通過客戶端向服務端提交攜帶口令信息的業(yè)務請求報文，并由客戶端利用軟證書對業(yè)務請求報文進行簽名，銀行系統(tǒng)接收到業(yè)務請求報文之后，不僅進行簽名驗證還需要進行口令驗證，在簽名驗證以及口令驗證均通過之后，再根據業(yè)務請求報文進行業(yè)務處理，通過軟證書和口令信息，對用戶進行了雙重認證，保證了業(yè)務處理安全性，且采用軟證書同時提高了安全認證的便利性。

當然，實施本申請的任一產品必不一定需要同時達到以上所述的所有技術效果。

附圖說明

此處所說明的附圖用來提供對本申請的進一步理解，構成本申請的一部分，本申請的示意性實施例及其說明用于解釋本申請，并不構成對本申請的不當限定。在附圖中：

圖1是本申請實施例的一種業(yè)務處理方法一個實施例的流程圖；

圖2是本申請實施例的一種業(yè)務處理方法又一個實施例的信令流程圖；

圖3是本申請實施例的一種業(yè)務處理裝置一個實施例的結構示意圖；

圖4是本申請實施例的一種業(yè)務處理裝置又一個實施例的結構示意圖；

圖5是本申請實施例的一種業(yè)務處理裝置又一個實施例的結構示意圖；

圖6是本申請實施例的一種業(yè)務處理系統(tǒng)一個實施例的結構示意圖。

具體實施方式

以下將配合附圖及實施例來詳細說明本申請的實施方式，藉此對本申請如何應用技術手段來解決技術問題并達成技術功效的實現(xiàn)過程能充分理解并據以實施。

本申請的技術方案主要適用于銀企直聯(lián)的應用場景中。在銀企直連中，由于業(yè)務處理需要跨域銀行端以及企業(yè)端，現(xiàn)有技術通常采用部署前置機，以硬證書進行安全認證的方式來業(yè)務處理的安全性，但是硬證書操作并不便利，容易增加安全認證的復雜性。特別是隨著越來越多的小微企業(yè)參與銀企直聯(lián)，小微企業(yè)的企業(yè)財務系統(tǒng)通常不是企業(yè)自創(chuàng)的，而是租用的諸如saas(software-as-a-service，軟件即服務)型的軟件系統(tǒng)，如果采用硬證書的方式，硬證書則需設置在租用的服務器上，而租用的服務器通常部署在距離企業(yè)較遠的專有機房上，一旦硬證書出現(xiàn)問題，那么運維操作就會更加不便利，使得安全認證更加復雜性。

為了在保證業(yè)務處理安全性的同時，提高安全認證的便利性，發(fā)明人經過一系列研究，提出本申請的技術方案，在本申請實施例中，由用戶通過客戶端向服務端提交口令請求報文；其中，口令請求報文利用軟證書進行簽名，銀行系統(tǒng)接收到服務端提交的口令請求報文，對口令請求報文先進行簽名驗證，驗證通過之后，向用戶提供口令信息；從而發(fā)起業(yè)務請求時，需要通過客戶端向服務端提交攜帶口令信息的業(yè)務請求報文，業(yè)務請求報文同樣利用軟證書進行簽名，銀行系統(tǒng)接收到業(yè)務請求報文之后，不僅進行簽名驗證還需要進行口令驗證，在簽名驗證以及口令驗證均通過之后，再根據業(yè)務請求報文進行業(yè)務處理，通過軟證書和口令信息，對用戶進行了雙重認證，保證了業(yè)務處理安全性，且同時提高了安全認證的便利性。

下面將結合附圖對本申請技術方案進行詳細描述。

圖1為本申請實施例提供的一種業(yè)務處理方法一個實施例的流程圖，該方法可以包括以下幾個步驟：

101：客戶端將用戶提交的口令請求報文，利用第一軟證書進行簽名之后發(fā)送至服務端。

本申請實施例中，企業(yè)財務系統(tǒng)采用客戶端+服務端的方式進行部署，用戶可以通過客戶端向服務端發(fā)起請求，通過服務端可以與銀行系統(tǒng)進行聯(lián)接通信。

企業(yè)財務系統(tǒng)可以是b/s(browser/server，瀏覽器/服務器)架構或者c/s(client/server，客戶機/服務器)架構。

因此，客戶端可以為客戶機或瀏覽器。

本申請實施例中，采用軟證書對報文進行簽名。在客戶端為瀏覽器時，具體可以是通過調用設置于瀏覽器中的簽名控件，利用軟證書對報文進行簽名。

軟證書是一種數字證書，是一種權威性的電子文檔,由權威公正的第三方機構頒發(fā)，用以證明自己的身份和識別對方的身份。軟證書以文件作為存儲介質，以電子文件形式存放的。軟證書無需進行復雜的運維操作，使得安全認證更加便利。

為了方便描述區(qū)分，客戶端進行簽名使用的軟證書，描述為第一軟證書。

在銀企直聯(lián)場景中，所述用戶也即企業(yè)用戶，客戶端設置在企業(yè)端，位于企業(yè)內網，第一軟證書用于驗證用戶身份，也即用于驗證企業(yè)身份。

口令請求報文用于請求口令信息。用戶通過客戶端請求進行業(yè)務處理時，首先向銀行系統(tǒng)提交口令請求報文。

102：服務端將所述口令請求報文提交至銀行系統(tǒng)。

客戶端將進行簽名的口令請求報文提交至服務端，服務端即可以將口令請求報文提交至銀行系統(tǒng)。

其中，服務端可以設置在企業(yè)端，為企業(yè)服務器。

當然，在企業(yè)采用saas型軟件系統(tǒng)時，服務端可以是指saas服務器。

103：銀行系統(tǒng)對所述口令請求報文進行簽名驗證，并在簽名驗證通過之后，向所述用戶提供口令信息。

銀行系統(tǒng)對口令請求報文進行簽名驗證。銀行系統(tǒng)利用第一軟證書的公鑰對口令請求報文進行簽名驗證，以確認用戶身份。

如果簽名驗證通過，即可以向用戶提供口令信息。

其中，所述口令信息可以是指一次性口令，是指只能使用一次的密碼，為每間隔預設時間，生成的一個不可預測的隨機數字組合。

其中，銀行系統(tǒng)向用戶提供口令信息，可以是通過通信信息的形式發(fā)送，比如短消息或者來電通話等，銀行系統(tǒng)可以利用所述用戶的用戶終端標識，與所述用戶終端建立通信連接；基于所述通信連接，向所述用戶終端傳輸攜帶所述口令信息的通信信息。用戶終端例如可以是指手機等便攜式設備，用戶終端標識可以是指手機號碼等通訊號碼。

104：客戶端將用戶提交的攜帶所述口令信息的業(yè)務請求報文，利用所述第一軟證書進行簽名之后發(fā)送至所述服務端。

用戶獲得口令信息之后，即可以向客戶端提交攜帶所述口令信息的業(yè)務請求報文，例如用戶可以在客戶端通過輸入口令信息，觸發(fā)業(yè)務請求報文。

105：服務端將所述業(yè)務請求報文提交至所述銀行系統(tǒng)。

客戶端首先利用所述第一軟證書進行簽名之后，再發(fā)送至服務端，即由服務端提交至銀行系統(tǒng)。

106：銀行系統(tǒng)對所述對所述業(yè)務請求報文進行簽名驗證以及對所述口令信息進行口令校驗，并在簽名驗證和口令校驗均通過之后，根據所述業(yè)務請求報文進行業(yè)務處理。

銀行系統(tǒng)不僅對業(yè)務請求報文進行簽名驗證，還需要對口令信息進行校驗。

銀行系統(tǒng)可以利用第一軟證書的公鑰，驗證業(yè)務請求報文的簽名；可以利用保存的向用戶發(fā)送的口令信息，對業(yè)務請求報文攜帶的口令信息進行口令校驗。僅在簽名驗證和口令校驗均通過之后，根據所述業(yè)務請求報文進行業(yè)務處理。

在本實施例中，由用戶通過客戶端向服務端提交口令請求報文；口令請求報文首先由客戶端利用第一軟證書進行簽名，銀行系統(tǒng)接收到服務端提交的口令請求報文，對口令請求報文先進行簽名驗證，驗證通過之后，向用戶提供口令信息；用戶通過客戶端向服務端提交業(yè)務請求報文，同時攜帶該口 令信息；攜帶口令信息的業(yè)務請求報文由客戶端利用第一軟證書進行簽名；銀行系統(tǒng)接收到業(yè)務請求報文之后，不僅進行簽名驗證還需要進行口令驗證，在簽名驗證以及口令驗證均通過之后，再根據業(yè)務請求報文進行業(yè)務處理，通過軟證書和口令信息，對用戶進行了雙重認證，保證了業(yè)務處理安全性，且采用軟證書方式，同時提高了安全認證的便利性。

作為又一個實施例，為了進一步提高業(yè)務處理的安全性，服務端也需要進行安全認證，服務端同樣可以采樣軟證書方式進行身份認證。

特別是在服務端為租用的諸如saas服務器時，也即企業(yè)財務系統(tǒng)并非企業(yè)自創(chuàng)的時，由于租用的服務器部署在專有機房，企業(yè)通過租用的方式使用，此時的服務端并非位于企業(yè)內網，用戶通過客戶端提交的口令請求報文或者業(yè)務請求報文，需要發(fā)送至位于企業(yè)外網的服務端，因此也有必要對服務端進行安全認證，以保證軟件身份也為銀行系統(tǒng)授權的，以進一步保證業(yè)務處理的安全性。

具體的，可以是服務端接收到客戶端提交的口令請求報文時，可以利用第二軟證書進行簽名之后再提交至銀行系統(tǒng)。同樣業(yè)務請求報文也由服務端利用第二軟證書進行簽名之后提交銀行系統(tǒng)。

從而銀行系統(tǒng)對口令情況報文以及業(yè)務請求報文的進行簽名驗證可以包括利用第一軟證書的公鑰對使用第一軟證書進行的簽名進行驗證，以確認企業(yè)身份；利用第二軟證書的公鑰對使用第二軟證書的簽名進行驗證，以確認軟件身份。

下面結合一個實際應用，以服務端為saas服務器為例，對本申請技術方案進行詳細描述，如圖2所示，為本申請實施例提供的一種業(yè)務處理方法又一個實施例的信令流程圖，該方法可以包括以下幾個步驟：

201：客戶端接收用戶提交的口令請求報文。

用戶可以在客戶端錄入業(yè)務交易，并請求獲取口令信息，發(fā)起口令請求報文。

202：客戶端利用第一軟證書將所述口令請求報文進行簽名后發(fā)送至 saas服務器。

此外，作為又一個實施例，在該實際應用中，客戶端也可以采用硬證書對口令請求報文簽名。

203：saas服務器利用第二軟證書將所述口令請求報文進行簽名后提交至銀行系統(tǒng)。

204：銀行系統(tǒng)對所述口令請求報文進行簽名驗證，并在簽名驗證通過之后，向所述用戶提供口令信息。

銀行系統(tǒng)對口令請求報文的簽名驗證包括對客戶端以及saas服務器分別進行的簽名進行的驗證，以確認企業(yè)身份以及軟件身份，使得只有被授權的企業(yè)和軟件能夠實現(xiàn)業(yè)務處理。

205：客戶端接收用戶提交的攜帶所述口令信息的業(yè)務處理報文。

206：客戶端利用第一軟證書將所述業(yè)務請求報文進行簽名后發(fā)送至saas服務器。

207：saas服務器利用第二軟證書將所述口令請求報文進行簽名后提交至銀行系統(tǒng)。

208：：銀行系統(tǒng)對所述對所述業(yè)務請求報文進行簽名驗證以及對所述口令信息進行口令校驗，并在簽名驗證和口令校驗均通過之后，根據所述業(yè)務請求報文進行業(yè)務處理。

銀行系統(tǒng)對業(yè)務請求報文的簽名驗證包括對客戶端以及saas服務器分別進行的簽名進行的驗證。

在本實施例中，通過軟證書和口令信息，對用戶進行了雙重認證，能夠有效避免因軟證書可能被復制冒用帶來的安全性問題。保證了業(yè)務處理安全性，且分別在客戶端以及服務端對口令請求報文以及業(yè)務請求報文進行簽名，進一步保證了業(yè)務處理的安全性。且采用軟證書方式，同時提高了安全認證的便利性。

此外，作為又一個實施例，在服務端位于企業(yè)內網，為企業(yè)服務器時，對口令請求報文以及業(yè)務請求報文利用第一軟證書進行的簽名，也可以是在 服務端執(zhí)行的，由于服務端位于企業(yè)內網，因此可以利用企業(yè)申請的第一軟證書進行簽名，也可以實現(xiàn)對企業(yè)身份的認證，并不局限于在客戶端利用第一軟證書對口令請求報文以及業(yè)務請求報文進行簽名的方式。

圖3為本申請實施例提供的一種業(yè)務處理裝置一個實施例的結構示意圖，該裝置在實際應用中可以配置為客戶端，該裝置可以包括：

第一簽名模塊301，用于將用戶提交的口令請求報文，利用第一軟證書進行簽名之后發(fā)送至服務端；由所述服務端將所述口令請求報文提交至銀行系統(tǒng)，使所述銀行系統(tǒng)對所述口令請求報文進行簽名驗證，并在簽名驗證通過之后，向所述用戶提供口令信息；

第二簽名模塊302，用于將所述用戶提交的攜帶所述口令信息的業(yè)務請求報文，利用所述第一軟證書進行簽名之后發(fā)送至所述服務端，由所述服務端將所述業(yè)務請求報文提交至所述銀行系統(tǒng)，使得所述銀行系統(tǒng)對所述業(yè)務請求報文進行簽名驗證以及對所述口令信息進行口令校驗，并在簽名驗證和口令校驗均通過之后，根據所述業(yè)務請求報文進行業(yè)務處理。

作為又一個實施例，為了進一步提高業(yè)務處理的安全性，服務端也需要進行安全認證，服務端同樣可以采樣軟證書方式進行身份認證。因此，所述口令請求報文可以具體由所述服務端將利用第二軟證書進行簽名后提交至銀行系統(tǒng)，使所述銀行系統(tǒng)對所述口令請求報文進行簽名驗證，并在簽名驗證通過之后，向所述用戶提供口令信息；

所述業(yè)務請求報文可以具體由所述服務端利用所述第二軟證書進行簽名后提交至所述銀行系統(tǒng)，使得所述銀行系統(tǒng)對所述業(yè)務請求報文進行簽名驗證以及對所述口令信息進行口令校驗，并在簽名驗證和口令校驗均通過之后，根據所述業(yè)務請求報文進行業(yè)務處理。

圖4為本申請實施例提供的一種業(yè)務處理裝置又一個實施例的結構示意圖，該裝置在實際應用中可以配置在服務端，所述服務端可以為設置企業(yè)內網中的企業(yè)服務器，或者設置在企業(yè)外網的租用服務器，該裝置可以包括：

第一接收模塊401，用于接收用戶通過客戶端提交的口令請求報文，其中，所述口令請求報文為所述客戶端使用第一軟證書進行簽名的報文；

第一發(fā)送模塊402，用于將所述口令請求報文提交至銀行系統(tǒng)，使所述銀行系統(tǒng)對所述口令請求報文進行簽名驗證，并在簽名驗證通過之后，向所述用戶提供口令信息；

第二接收模塊403，用于接收所述客戶端發(fā)送的業(yè)務請求報文，其中，所述業(yè)務請求報文為所述客戶端使用所述第一軟證書進行簽名后的報文，所述業(yè)務請求報文中攜帶所述口令信息；

第二發(fā)送模塊404，用于將所述業(yè)務請求報文提交至所述銀行系統(tǒng)，使所述銀行系統(tǒng)對所述業(yè)務請求報文進行簽名驗證以及對所述口令信息進行口令校驗，并在簽名驗證和口令校驗均通過之后，根據所述業(yè)務請求報文進行業(yè)務處理。

作為又一個實施例，為了進一步提高業(yè)務處理的安全性，服務端也需要進行安全認證，服務端同樣可以采樣軟證書方式進行身份認證。因此，所述第一發(fā)送模塊可以具體用于將所述口令請求報文利用第二軟證書進行簽名后提交至所述銀行系統(tǒng)。

所述第二發(fā)送模塊可以具體用于將所述業(yè)務請求報文使用所述第二軟證書進行簽名后提交至所述銀行系統(tǒng)。

圖5為本申請實施例提供的一種業(yè)務處理裝置又一個實施例的結構示意圖，該裝置在實際應用中可以配置在銀行系統(tǒng)中，該裝置可以包括：

第三接收模塊501，用于接收服務端提交的口令請求報文；其中，所述口令請求報文為客戶端將用戶提交的口令請求報文利用第一軟證書進行簽名后發(fā)送至所述服務端的；

第一驗證模塊502，用于對所述口令請求報文進行簽名驗證，并在簽名驗證通過之后，向所述用戶提供口令信息；

第四接收模塊503，用于接收所述服務端提交的業(yè)務請求報文；其中，所述業(yè)務請求報文為所述客戶端將用戶提交的攜帶所述口令信息的業(yè)務請 求報文利用所述第一軟證書進行簽名后發(fā)送至所述服務端；

第二驗證模塊504，用于對所述業(yè)務請求報文進行簽名驗證以及對所述口令信息進行口令校驗，并在簽名驗證和口令校驗均通過之后，根據所述業(yè)務請求報文進行業(yè)務處理。

其中，在所述口令請求報文是具體由所述服務端將利用第二軟證書進行簽名后提交至銀行系統(tǒng)時，所述第三接收模塊也即具體用于接收接收服務端提交的利用第二軟證書進行簽名后的口令請求報文；

第一驗證模塊對口令請求報文的簽名驗證包括對客戶端以及saas服務器分別進行的簽名進行的驗證，以確認企業(yè)身份以及軟件身份，使得只有被授權的企業(yè)和軟件能夠實現(xiàn)業(yè)務處理。

具體的可以是利用第一軟證書的公鑰對使用第一軟證書進行的簽名進行驗證，以確認企業(yè)身份；利用第二軟證書的公鑰對使用第二軟證書的簽名進行驗證，以確認軟件身份。

所述業(yè)務請求報文可以具體由所述服務端利用所述第二軟證書進行簽名后提交至所述銀行系統(tǒng)時，所述第四接收模塊，也即具體用于接收所述服務端提交的利用所述第二軟證書進行簽名后的業(yè)務請求報文。

第二驗證模塊對業(yè)務請求報文的簽名驗證包括對客戶端以及saas服務器分別進行的簽名進行的驗證。

具體的可以是利用第一軟證書的公鑰對使用第一軟證書進行的簽名進行驗證，以確認企業(yè)身份；利用第二軟證書的公鑰對使用第二軟證書的簽名進行驗證，以確認軟件身份。

本申請實施例還提供一種業(yè)務處理系統(tǒng)，該業(yè)務處理系統(tǒng)可以包括客戶端、服務端以及銀行系統(tǒng)。

客戶端與服務端，在銀企直聯(lián)場景中，即構成企業(yè)財務系統(tǒng)、

如圖6所示，為本申請實施例提供的業(yè)務處理系統(tǒng)一個實施例的結構示意圖，該業(yè)務處理系統(tǒng)部署在企業(yè)內網中，包括客戶端601、服務端602以及銀行系統(tǒng)603。

客戶端601可以配置有如圖3所示的業(yè)務處理裝置，服務端602可以配置有如圖4所示的業(yè)務處理裝置，銀行系統(tǒng)可以配置由如圖5所示的業(yè)務處理裝置。

在用戶需要進行業(yè)務處理時，通過客戶端601提交口令請求報文，客戶端601對口令請求報文利用第一軟證書進行簽名后提交至服務端602。服務端602將口令請求報文提交至銀行系統(tǒng)603，也可以利用第二軟證書進行簽名后再提交至銀行系統(tǒng)603。銀行系統(tǒng)603對口令請求報文進行簽名驗證，驗證通過之后，向用戶提交口令信息。

接收到口令信息的用戶，可以通過客戶端就601提交攜帶口令信息的業(yè)務請求報文，客戶端601對業(yè)務請求報文利用第一軟證書進行簽名后提交至服務端602。服務端602將業(yè)務請求報文提交至銀行系統(tǒng)603，也可以利用第二軟證書進行簽名后再提交至銀行系統(tǒng)603。銀行系統(tǒng)603對業(yè)務請求報文進行簽名驗證以及對口令信息進行口令校驗，在簽名驗證以及口令校驗均通過之后，即可以根據業(yè)務請求報文進行業(yè)務處理。

通過本申請實施例的業(yè)務處理系統(tǒng)，通過軟證書和口令信息，對用戶進行了雙重身份認證，保證了業(yè)務處理安全性，進一步的可以在服務端進行再次簽名驗證，錦衣保證業(yè)務處理的安全性，而采用軟證書方式，提高了安全認證的便利性。因此，本申請實施例在保證業(yè)務處理安全性的同時，提高安全認證才便利性。

需要說明的是，本申請的技術方案不僅適用于銀企直聯(lián)這種場景中，任何需要跨系統(tǒng)進行業(yè)務處理的領域或場景中，均可以采用本申請的技術方案進行安全認證，以保證業(yè)務處理的安全性，因此對于采用本申請技術，用于保證任何跨系統(tǒng)進行業(yè)務處理的安全性的方式，均應在本申請的保護范圍。

在一個典型的配置中，計算設備包括一個或多個處理器(cpu)、輸入/輸出接口、網絡接口和內存。

內存可能包括計算機可讀介質中的非永久性存儲器，隨機存取存儲器(ram)和/或非易失性內存等形式，如只讀存儲器(rom)或閃存(flashram)。內存是計算機可讀介質的示例。

計算機可讀介質包括永久性和非永久性、可移動和非可移動媒體可以由任何方法或技術來實現(xiàn)信息存儲。信息可以是計算機可讀指令、數據結構、程序的模塊或其他數據。計算機的存儲介質的例子包括，但不限于相變內存(pram)、靜態(tài)隨機存取存儲器(sram)、動態(tài)隨機存取存儲器(dram)、其他類型的隨機存取存儲器(ram)、只讀存儲器(rom)、電可擦除可編程只讀存儲器(eeprom)、快閃記憶體或其他內存技術、只讀光盤只讀存儲器(cd-rom)、數字多功能光盤(dvd)或其他光學存儲、磁盒式磁帶，磁帶磁磁盤存儲或其他磁性存儲設備或任何其他非傳輸介質，可用于存儲可以被計算設備訪問的信息。按照本文中的界定，計算機可讀介質不包括非暫存電腦可讀媒體(transitorymedia)，如調制的數據信號和載波。

如在說明書及權利要求當中使用了某些詞匯來指稱特定組件。本領域技術人員應可理解，硬件制造商可能會用不同名詞來稱呼同一個組件。本說明書及權利要求并不以名稱的差異來作為區(qū)分組件的方式，而是以組件在功能上的差異來作為區(qū)分的準則。如在通篇說明書及權利要求當中所提及的“包含”為一開放式用語，故應解釋成“包含但不限定于”?！按笾隆笔侵冈诳山邮盏恼`差范圍內，本領域技術人員能夠在一定誤差范圍內解決所述技術問題，基本達到所述技術效果。此外，“耦接”一詞在此包含任何直接及間接的電性耦接手段。因此，若文中描述一第一裝置耦接于一第二裝置，則代表所述第一裝置可直接電性耦接于所述第二裝置，或通過其他裝置或耦接手段間接地電性耦接至所述第二裝置。說明書后續(xù)描述為實施本申請的較佳實施方式，然所述描述乃以說明本申請的一般原則為目的，并非用以限定本申請的范圍。本申請的保護范圍當視所附權利要求所界定者為準。

還需要說明的是，術語“包括”、“包含”或者其任何其他變體意在涵蓋非排他性的包含，從而使得包括一系列要素的商品或者系統(tǒng)不僅包括那些要素，而且還包括沒有明確列出的其他要素，或者是還包括為這種商品或者系統(tǒng)所固有的要素。在沒有更多限制的情況下，由語句“包括一個……”限定的要素，并不排除在包括所述要素的商品或者系統(tǒng)中還存在另外的相同要素。

上述說明示出并描述了本申請的若干優(yōu)選實施例，但如前所述，應當理解本申請并非局限于本文所披露的形式，不應看作是對其他實施例的排除， 而可用于各種其他組合、修改和環(huán)境，并能夠在本文所述申請構想范圍內，通過上述教導或相關領域的技術或知識進行改動。而本領域人員所進行的改動和變化不脫離本申請的精神和范圍，則都應在本申請所附權利要求的保護范圍內。