專利名稱：一種電子簽名的身份驗證方法
技術(shù)領(lǐng)域：
本發(fā)明涉及電子簽名領(lǐng)域，尤其涉及一種電子簽名的身份驗證方法。
背景技術(shù)：
現(xiàn)有數(shù)字簽名的過程為首先，將待簽名文件按雙方約定的哈希算法計算得到一段代碼，即數(shù)字摘要，在數(shù)學(xué)上保證，只要改動報文中任何一位，重新計算出的數(shù)字摘要值就會與原先的值不相符，這樣就保證了待簽名文件的不可更改性；其次，將該數(shù)字摘要值用發(fā)送者的私人密鑰加密，然后連同原待簽名文件一起發(fā)送給接收者，而產(chǎn)生的數(shù)字摘要即稱數(shù)字簽名；最后，接收方收到數(shù)字簽名后，用同樣的哈希算法對報文計算摘要值，然后與用發(fā)送者的公開密鑰進(jìn)行解密解開的報文摘要值相比較，如相等則說明報文確實來自所稱的發(fā)送者。
可見，在上述的過程中，簽名人的身份是否被盜用，或者說對所述待簽名文件進(jìn)行電子簽名的簽名者是否就是該簽名的本人，這一點上述過程無法保證，即無法保證該簽名文件所生成的簽名人就是該對該簽名文件進(jìn)行簽名人，也就是無法保證簽名人的唯一性。這是因為，在上述的簽名體系中，簽名者的身份只在申請數(shù)字證書時才被驗證，而數(shù)字證書和公私鑰都是是一串?dāng)?shù)字符號，不太可能被記憶，因此，一般只能保存在磁盤上，而這就存在證書被盜的可能，因而也就出現(xiàn)身份被冒用進(jìn)行簽名的可能。
所以，現(xiàn)有的電子簽名體系無法解決身份被冒用的問題。另外，從數(shù)字簽名技術(shù)也無法得知是否一個數(shù)字簽名是在簽名人神志清醒時進(jìn)行的，是否是在被脅迫下進(jìn)行的和是否是由其他人代簽。這些疑問均可導(dǎo)致電子簽名的法律效力上的缺陷。因此，亟待出現(xiàn)一種能夠?qū)灻叩恼鎸嵣矸莺驼鎸嵑灻庠高M(jìn)行驗證的方法。

發(fā)明內(nèi)容
本發(fā)明要解決的技術(shù)問題在于提供一種對電子簽名的簽名用戶的身份的真實性進(jìn)行驗證的方法。
為了解決上述問題，本發(fā)明提出了一種電子簽名的身份驗證方法，其包括以下步驟
a、服務(wù)器向接收方發(fā)出確認(rèn)請求；b、接收方根據(jù)所述確認(rèn)請求進(jìn)行驗證并產(chǎn)生驗證結(jié)果；c、服務(wù)器根據(jù)所述驗證結(jié)果確定是否為真實簽名。
其中，所述步驟a具體為根據(jù)預(yù)留方式向電子簽名的簽名用戶發(fā)出確認(rèn)請求。
優(yōu)選的，所述預(yù)留方式包括以下方式中的至少一種電子郵件、固定電話、移動電話、互聯(lián)網(wǎng)即時通訊工具、人工方式。
其中，步驟b具體為所述簽名用戶根據(jù)所述確認(rèn)請求對所述電子簽名的真實性進(jìn)行驗證并產(chǎn)生肯定或否定的驗證結(jié)果。
優(yōu)選的，所述確認(rèn)請求至少包括下述信息中的一種簽名時間、簽名地點、簽名文件標(biāo)題、簽名文件摘要、所述簽名文件唯一性標(biāo)識。
另外，所述確認(rèn)請求為對所述電子簽名的身份驗證通知，其發(fā)送至驗證人員。
其中，步驟b具體為所述驗證人員根據(jù)所述驗證通知進(jìn)行驗證并產(chǎn)生肯定或否定的驗證結(jié)果。
優(yōu)選的，所述驗證人員至少按照下述各種方式中的一種進(jìn)行驗證人工電話驗證、人工移動電話驗證、生物樣本驗證。
優(yōu)選的，所述驗證通知至少包括下述信息中的一種簽名時間、簽名地點、簽名文件標(biāo)題、簽名文件摘要、所述簽名文件唯一性標(biāo)識。
其中，步驟c具體為若步驟b產(chǎn)生肯定的驗證結(jié)果，則認(rèn)為所述電子簽名為有效簽名；若步驟b產(chǎn)生否定的驗證結(jié)果，則認(rèn)為所述電子簽名為無效簽名。
實施本發(fā)明能夠?qū)崿F(xiàn)對電子簽名的用戶的身份的真實性的驗證，而且確定是否是所述簽名的簽名者的真實意愿的簽名，以確保簽名的真實性即簽名人的唯一性。


圖1是本發(fā)明所基于的系統(tǒng)的一個實施例的網(wǎng)絡(luò)結(jié)構(gòu)框圖；圖2是基于圖1所示的網(wǎng)絡(luò)結(jié)構(gòu)的工作過程的一個實施例的流程圖；圖3是圖2中步驟20的具體注冊過程的一個實施例的流程圖；圖4是圖2中步驟21的具體電子簽名過程的一個實施例的流程圖；圖5是目標(biāo)簽名頁添加邊框的示意圖；圖6是添加簽名信息后的簽名頁的示意圖；
圖7是圖2中步驟21的具體電子簽名過程的另一個實施例的流程圖；圖8是圖2中步驟22的具體驗證過程的一個實施例的流程圖；圖9是圖2中步驟22的具體驗證過程的另一個實施例的流程圖；圖10是圖2中步驟22的具體驗證過程的再一個實施例的流程圖；圖11是圖2中步驟21的具體電子簽名過程的再一個實施例的流程圖。
具體實施例方式
下面將結(jié)合附圖系統(tǒng)地闡述本發(fā)明的整個過程。
參考圖1，圖示了本發(fā)明所基于的系統(tǒng)的一個實施例的網(wǎng)絡(luò)結(jié)構(gòu)框圖。如圖所示，本實施例中所述系統(tǒng)采用SOA(Service Oriented Architecture，面向服務(wù)架構(gòu))網(wǎng)絡(luò)架構(gòu)實現(xiàn)，其具體包括客戶端10，用于根據(jù)用戶的要求對待簽名文件進(jìn)行電子簽名，并進(jìn)行用戶注冊過程。；服務(wù)器11，用于根據(jù)客戶端10的請求提供簽名信息，并接收包括已簽名文件及相關(guān)信息的文件記錄，同時在注冊過程中收集用戶信息，以及完成身份驗證的過程；數(shù)據(jù)庫12，用于存儲服務(wù)器11所接收的包括已簽名的文件及相關(guān)信息的文件記錄，以及客戶端用戶資料。
其中，服務(wù)器11首先通過注冊過程13收集客戶端10的用戶資料并存儲于數(shù)據(jù)庫12中，所述用戶資料包括身份驗證信息及用戶登記信息，該用戶登記信息包括客戶端登陸用戶名、登陸密碼，所述身份驗證信息包括能夠唯一確定該登記用戶的信息，例如該用戶對某問題的唯一答案、身份證號碼、手印或其它生物樣本等信息，還包括用戶的聯(lián)系信息，例如電話號碼、手機(jī)號碼、電子郵件地址等，或者還包括另一個只在身份驗證時用到的驗證密碼等。其中，所述服務(wù)器10與客戶端11之間可以采用以太網(wǎng)連接通信，例如國際互聯(lián)網(wǎng)等，或采用無線通信方式通信，例如GPRS(Gerneral Packer Radio Service，通用無線分組業(yè)務(wù))數(shù)據(jù)傳輸方式等。
參考圖2，圖示了基于圖1所示的網(wǎng)絡(luò)結(jié)構(gòu)的工作過程的一個實施例的流程圖。如圖所示，包括以下步驟步驟20，客戶端用戶向服務(wù)器端的系統(tǒng)管理員進(jìn)行注冊登記；步驟21，客戶端根據(jù)用戶需求對待簽名文件進(jìn)行電子簽名并將相關(guān)文件記錄上傳至服務(wù)器端的數(shù)據(jù)庫中保存；步驟22，服務(wù)器端對客戶端簽名用戶的身份進(jìn)行驗證；
步驟23，結(jié)束整個工作過程。
參考圖3，圖示了圖2中步驟20的具體注冊過程的一個實施例的流程圖。在本實施例中采用客戶端用戶登錄服務(wù)器的WEB注冊頁面進(jìn)行注冊操作的方式。如圖所示，包括以下步驟步驟201，客戶端用戶發(fā)出注冊請求；即客戶端用戶向服務(wù)器端的系統(tǒng)管理員發(fā)起注冊請求，請求方式不僅可以采用WEB的表單的形式向所述系統(tǒng)管理員所在的主機(jī)發(fā)送請求，也可以采用人工的通過電子郵件的方式等；步驟202，服務(wù)器端系統(tǒng)管理員接受所述請求并通知所述客戶端用戶發(fā)送個人資料；所述的個人資料包括用戶身份驗證信息及用戶登記信息，該用戶登記信息包括用于客戶端登陸的用戶名、相應(yīng)的登陸密碼，所述身份驗證信息包括能夠唯一確定該登記用戶的信息，例如身份證號碼、手印或其它生物樣本(例如聲音片斷)等信息，還包括用戶的聯(lián)系信息，例如電話號碼、手機(jī)號碼、電子郵件地址等，或者還包括另一個只在身份驗證時用到的驗證密碼等。
步驟203，客戶端用戶收到所述系統(tǒng)管理員發(fā)出的上載個人資料的通知后便按照所述個人資料的需求發(fā)送個人資料至系統(tǒng)管理員；步驟204，系統(tǒng)管理員收到所述個人資料后，判斷所述的個人資料有無非法資料；例如，身份證號碼、手機(jī)號碼、電子郵件地址是否符合規(guī)定，是否與已登記的用戶的個人資料有沖突，手印、聲音片斷等生物樣本資料是否清晰清楚符合要求，以及判斷該用戶的是否是該系統(tǒng)所面向的用戶，例如對一個企業(yè)來說，則判斷該用戶是否是企業(yè)的員工，或者判斷該用戶的權(quán)限是否符合要求等等；若合法則執(zhí)行步驟205，否則執(zhí)行步驟207；步驟205，為該客戶端用戶創(chuàng)建用戶名、初始登陸密碼并將其發(fā)送至客戶端用戶。這里為了安全的原因，可以采用電子郵件的方式，或者手機(jī)短信的方式發(fā)送至用戶，或者仍然采用WEB方式發(fā)送；步驟206，將所述客戶端用戶的個人資料及步驟205中創(chuàng)建的用戶名及密碼存儲至服務(wù)器端的數(shù)據(jù)庫的對應(yīng)字段中，然后執(zhí)行步驟208。
步驟207，結(jié)束注冊過程并向客戶端用戶報錯。即結(jié)束本次注冊，并將出錯原因發(fā)送至用戶；這一點類似于電子郵件帳號的注冊過程出現(xiàn)錯誤時的報錯方式；步驟208，該客戶端用戶的本次注冊過程結(jié)束。
上述實施例只是采用了WEB注冊的方式，這里還可以采用Email注冊的方式，或者通過客戶端的注冊界面進(jìn)行注冊的方式等，本發(fā)明不限于此。
參考圖4，圖示了圖2中步驟21的具體電子簽名過程的一個實施例的流程圖。在闡述本實施例之前，首先描述兩種電子簽名的含義真實圖像框簽，是指簽名頁與簽名信息及相應(yīng)的邊框作為一個圖片被存儲；虛擬圖像框簽，是指簽名頁與簽名信息被分開存儲，并不合成為一個圖片進(jìn)行存儲，這樣最大的好處是可以節(jié)省存儲空間。
本實施例中以待簽名文件為文本格式，并以其一部分或全部轉(zhuǎn)換為圖片格式作為目標(biāo)簽名頁為例進(jìn)行說明，這種簽名方式實際上為真實圖像框簽的一種情況。如圖所示，包括以下步驟步驟210，獲得待簽名文件。所述待簽名文件是指需要進(jìn)行簽名操作的文檔，例如公文、審批單等等，獲得這些待簽名文件的方法可以通過網(wǎng)絡(luò)下載相關(guān)的文件，或者簽名者本人自行輸入文字或圖像材料等等。
步驟211，生成目標(biāo)簽名頁。因為待簽名文件為文本格式，因此將所述待簽名文件在屏幕上顯示，并利用截屏工具將所述的文本格式的待簽名文件轉(zhuǎn)換為圖片格式作為目標(biāo)簽名頁，若所述文本格式的待簽名文件無法在屏幕上一屏完全顯示，可以通過多次截屏并將截屏后的圖片合成的方式來生成一個完整的目標(biāo)簽名頁，或者如果還有其他已存儲的圖片文件可以打開該文件并將其與所截取的圖片合成為目標(biāo)簽名頁，或者也可以僅選取所述待簽名文件的一部分轉(zhuǎn)換為圖片格式作為目標(biāo)簽名頁，剩余部分與所述目標(biāo)簽名頁合并作為目標(biāo)簽名文件；其中，將多個圖片合成為一個圖片的技術(shù)可以通過簡單2D圖像處理工具合成(客戶端程序提供了2D簽名頁圖像的合成工具，用戶也可選用第三方的工具例如photoshop，firework等等)，通過調(diào)用2D圖形函數(shù)(例如，Java 2D圖像函數(shù)庫中的drawImage函數(shù))來實現(xiàn)，由于是公知技術(shù)在此不進(jìn)行詳細(xì)的描述。
步驟212，獲得簽名信息。其具體過程為，首先客戶端的用戶通過輸入用戶名、密碼來向服務(wù)器發(fā)出請求，請求下載所述簽名信息；然后，服務(wù)器接收到所述請求并核對所述用戶名和密碼是否匹配，若匹配，則將簽名信息下傳至客戶端用戶；所述用戶名和密碼為上述注冊過程中所分配，所述簽名信息包括用戶姓名、簽名時間、簽名操作所在的位置(例如所述客戶端所位于的域，或者所在主機(jī)的IP地址、MAC(media access control，媒體接入控制)地址、處理器ID等)、服務(wù)器的URL(Uniform Resource Location，統(tǒng)一資源定位符)地址等信息；其中，所述簽名操作所在的位置首先由用戶所在的客戶端在本地主機(jī)上獲取，然后將該位置信息上傳至服務(wù)器，并由服務(wù)器對所述位置信息的真?zhèn)芜M(jìn)行驗證，當(dāng)然，這里也可以不進(jìn)行驗證。
步驟213，為目標(biāo)簽名頁添加邊框。所述的邊框為在所述目標(biāo)簽名頁周圍的環(huán)形的矩形框，根據(jù)其在所述目標(biāo)簽名頁的不同的位置又分為上邊框、下邊框、左邊框、右邊框，其中所述下邊框的面積最大，具體情形可以參考圖5，圖中虛線框為所述的邊框；當(dāng)然，這僅為一個實施方式，所述各個邊框的大小取決于步驟212中所獲得的簽名信息的多少以及下述步驟214中將所述簽名信息添加至哪個邊框中來決定。其中，所述邊框的添加方法可以參考下面所述(假設(shè)目標(biāo)簽名頁的的寬度為X，長度為Y)首先，使用2D圖像函數(shù)工具生成一個空白圖像，其寬度為X加上左右邊框的寬度的2倍，其長度為Y加上上邊框的寬度和下邊框的寬度；所述的左右邊框的寬度，上下邊框的寬度可以根據(jù)需要進(jìn)行設(shè)定；其次，使用2D圖像函數(shù)工具按設(shè)計的位置將所述目標(biāo)簽名頁復(fù)制到所述空白圖像上；這里可以以不同圖層的方式來實現(xiàn)，所述按設(shè)計的位置是指上一步中所定義的上、下、左、右邊框的寬度；最后，生成新的目標(biāo)簽名頁；即，可以通過合并圖層的方式實現(xiàn)。
步驟214，將所述簽名信息添加至所述邊框生成簽名頁?？蛻舳死?D圖像函數(shù)工具(例如，Java 2D圖像函數(shù)庫中的drawstring函數(shù)等)將所述簽名信息以圖片的形式寫入所述邊框中，具體可添加至下邊框中，詳細(xì)情形可以參考圖6所示。另外，用戶可以根據(jù)個人需要選擇是否添加備注信息等。本步驟完成后，所述目標(biāo)簽名頁和邊框及邊框上的內(nèi)容即一起作為簽名頁。
步驟215，判斷所述待簽名文件有無附件，若有則執(zhí)行步驟216，否則執(zhí)行步驟220。
步驟216，生成目標(biāo)簽名文件。當(dāng)步驟211中所述文本格式的待簽名文件被全部轉(zhuǎn)換為圖片格式作為目標(biāo)簽名頁，并最終轉(zhuǎn)換為簽名頁時，則將所述簽名頁與所述附件合并一個文件作為目標(biāo)簽名文件；當(dāng)步驟211中所述文本格式的待簽名文件被部分轉(zhuǎn)換為圖片格式作為目標(biāo)簽名頁，并最終轉(zhuǎn)換為簽名頁時，則將所述簽名頁、剩余的所述待簽名文件以及所述附件合并作為目標(biāo)簽名文件。其中，合并為一個文件的過程可以采用以下方法客戶端程序使用ZIP(一種常用的壓縮格式)工具或其自帶的高級語言包(例如Java語言包)中的ZIP Library(ZIP庫)將所述簽名頁與所述附件合并為單一的ZIP文檔文件作為目標(biāo)簽名文件，或者是將所述附件繼續(xù)添加至原來的目標(biāo)簽名文件的ZIP文檔中。
步驟217，生成數(shù)字摘要或使用PKI(Public Key Infrastructure，公鑰基礎(chǔ)設(shè)施)技術(shù)生成數(shù)字簽名。所述生成數(shù)字摘要的過程為以所述目標(biāo)簽名文件的二進(jìn)制代碼為對象利用單向加密Hash算法(哈希算法)生成一段代碼，所述單向加密Hash算法(哈希算法)可以采用MD5算法、SHA-1算法等。若使用PKI數(shù)字簽名，則將所述數(shù)字簽名模塊集成至客戶端中以供調(diào)用，此時，簽名用戶要人工輸入私鑰，或事先將私鑰保存在當(dāng)?shù)刂鳈C(jī)上(如U盤上)，由客戶端讀取，或者也可以調(diào)用外部數(shù)字簽名模塊進(jìn)行操作。由于PKI數(shù)字簽名技術(shù)是已經(jīng)相當(dāng)成熟的現(xiàn)有技術(shù)，在此不再進(jìn)行進(jìn)一步的闡述。
需要說明的是，由于所述目標(biāo)簽名文件中包含了簽名信息，而該簽名信息中又包括簽名時間、簽名操作所在的位置信息、用戶姓名，而且所述簽名時間信息從服務(wù)器獲得，所述簽名操作所在的位置信息從簽名操作所在主機(jī)獲得并由服務(wù)器驗證、所述用戶姓名也從服務(wù)器獲得。因此再將包含上述簽名信息的目標(biāo)簽名文件進(jìn)行PKI(Public Key Infrastructure，公鑰基礎(chǔ)設(shè)施)數(shù)字簽名，或者直接生成數(shù)字摘要，便可以保證PKI數(shù)字簽名的結(jié)果以及直接生成的數(shù)字摘要具有基于所述簽名時間的時間上的唯一性、具有基于所述簽名操作所在位置的空間上的唯一性；并且，通過步驟22的身份驗證過程可保證所述用戶(即簽名人)的簽名人的唯一性，防止其他人頂替簽名或者逼迫簽名人違背其真正意志進(jìn)行簽名。步驟22的具體過程可以參考后續(xù)的描述。所述時間唯一性是指即使是同一用戶在同一地點對同一文件進(jìn)行兩次簽名其結(jié)果也是不一樣的，因為兩次簽名的時間不同；所述空間唯一性是指同一用戶在同一時間在不同的地點對同一文件進(jìn)行簽名其結(jié)果也是不同的；所述簽名人唯一性是指即使是不同的用戶對同一文件在同一地點、同一時間進(jìn)行簽名其結(jié)果是不同的，簽名人唯一性本來是不應(yīng)該有疑問的，但由于身份失竊和找人代簽的問題，簽名文件的簽名人究竟是否就是所聲稱的簽名人就存在了疑問，因此通過步驟22的身份驗證過程便可以保證簽名人的唯一性。
步驟218，生成文件記錄。即將步驟217中所使用的簽名方法(使用單向加密算法生成數(shù)字摘要，或PKI數(shù)字簽名等)、簽名結(jié)果(即所述數(shù)字摘要或PKI數(shù)字簽名結(jié)果)以及所述目標(biāo)簽名文件中的內(nèi)容保存至文件記錄中。這里，所述的文件記錄的結(jié)構(gòu)可以看作數(shù)據(jù)庫中的數(shù)據(jù)表的一條記錄的結(jié)構(gòu)，結(jié)構(gòu)中包括若干不同的字段用以存儲上述信息。
步驟219，上載至服務(wù)器端的數(shù)據(jù)庫存儲并轉(zhuǎn)向步驟223執(zhí)行。即將所述文件記錄上載至服務(wù)器端的數(shù)據(jù)庫中存儲。
步驟220，生成數(shù)字摘要或使用PKI(Public Key Infrastructure，公鑰基礎(chǔ)設(shè)施)技術(shù)生成數(shù)字簽名。所述生成數(shù)字摘要的過程為以所述簽名頁的二進(jìn)制代碼為對象利用單向加密Hash算法(哈希算法)生成一段代碼，所述單向加密Hash算法(哈希算法)可以采用MD5算法或SHA-1算法等等。若使用PKI數(shù)字簽名，則將所述數(shù)字簽名模塊集成至客戶端中以供調(diào)用，此時，簽名用戶要人工輸入私鑰，或事先將私鑰保存在當(dāng)?shù)刂鳈C(jī)上(如U盤上)，由客戶端讀取，或者也可以調(diào)用外部數(shù)字簽名模塊進(jìn)行操作，。由于PKI數(shù)字簽名技術(shù)是已經(jīng)相當(dāng)成熟的現(xiàn)有技術(shù)，在此不再進(jìn)行進(jìn)一步的闡述。
需要說明的是，由于所述簽名頁中包含了簽名信息，而該簽名信息中又包括簽名時間、簽名操作所在的位置信息、用戶姓名，而且所述簽名時間信息從服務(wù)器獲得，所述簽名操作所在的位置信息從簽名操作所在主機(jī)獲得并由服務(wù)器驗證、所述用戶姓名也從服務(wù)器獲得。因此再將包含上述簽名信息的簽名頁進(jìn)行PKI數(shù)字簽名，或者直接生成數(shù)字摘要，便可以保證PKI數(shù)字簽名的結(jié)果以及直接生成的數(shù)字摘要具有基于所述簽名時間的時間上的唯一性、具有基于所述簽名操作所在位置的空間上的唯一性；并且，通過步驟22的身份驗證過程可保證所述用戶(即簽名人)的簽名人的唯一性，防止其他人頂替簽名或者逼迫簽名人違背其真正意志進(jìn)行簽名。步驟22的具體過程可以參考后續(xù)的描述。所述時間唯一性是指即使是同一用戶在同一地點對同一文件進(jìn)行兩次簽名其結(jié)果也是不一樣的，因為兩次簽名的時間不同；所述空間唯一性是指同一用戶在同一時間在不同的地點對同一文件進(jìn)行簽名其結(jié)果也是不同的；所述簽名人唯一性是指即使是不同的用戶對同一文件在同一地點、同一時間進(jìn)行簽名其結(jié)果是不同的，簽名人唯一性本來是不應(yīng)該有疑問的，但由于身份失竊和找人代簽的問題，簽名文件的簽名人究竟是否就是所聲稱的簽名人就存在了疑問，因此通過步驟22的身份驗證過程便可以保證簽名人的唯一性。
步驟221，生成文件記錄。即將步驟220中所使用的簽名方法(使用單向加密算法生成數(shù)字摘要，或PKI數(shù)字簽名等)、簽名結(jié)果(即所述數(shù)字摘要或PKI數(shù)字簽名結(jié)果)以及所述目標(biāo)簽名文件中的內(nèi)容保存至文件記錄中，若無所述目標(biāo)簽名文件(即將待簽名文件的一部分轉(zhuǎn)換為簽名頁，而該待簽名文件又沒有附件的情況)，則將所述簽名頁保存至文件記錄中。
步驟222，上載至服務(wù)器端的數(shù)據(jù)庫存儲并轉(zhuǎn)向步驟223執(zhí)行。即將所述文件記錄上載至服務(wù)器端的數(shù)據(jù)庫中存儲。
步驟223，結(jié)束本次電子簽名的流程。
參考圖7，圖示了圖2中步驟21的具體電子簽名過程的另一個實施例的流程圖。本實施例中以待簽名文件可以為音頻、視頻或多媒體格式，或者是文本或圖片格式等，其通過用戶選取任意的圖片或輸入文字，或者選取名片模版作為目標(biāo)簽名頁，這種簽名方式也為真實圖像框簽的一種。如圖所示，包括以下步驟步驟2100，獲得待簽名文件。所述待簽名文件是指需要進(jìn)行簽名操作的文檔，例如一段音頻資料或視頻資料等等，獲得這些待簽名文件的方法可以通過網(wǎng)絡(luò)下載相關(guān)的文件，或者簽名者本人自行錄入音頻或視頻信息等等。
步驟2101，判斷有無名片模版，若有則執(zhí)行步驟2102，否則執(zhí)行步驟2103。其中，所述名片模版為用戶事先準(zhǔn)備的與該用戶相關(guān)的信息，其可以是圖片格式或是文字格式等。
步驟2102，調(diào)用所述名片模版，然后執(zhí)行步驟2104。即將所述用戶事先準(zhǔn)備好的名片模版調(diào)出，可以是將其顯示在屏幕上。
步驟2103，用戶選取任意的圖片或文字作為模版。所述的文字可以由用戶直接在文檔編輯窗口中輸入，并顯示在屏幕上。
步驟2104，生成目標(biāo)簽名頁。無論是步驟2102中所述的名片模版，還是步驟2103中所述的用戶選取的任意的圖片或文字，若不是圖片格式均可經(jīng)過截圖轉(zhuǎn)換為圖片格式(其具體如何實現(xiàn)可參考步驟211中相關(guān)信息)，并作為目標(biāo)簽名頁，若是圖片格式則直接作為目標(biāo)簽名頁；或者，也可以直接將用戶選取的任意圖片或文字不轉(zhuǎn)換為圖片格式，直接作為目標(biāo)簽名頁。二者最大的區(qū)別在于，若轉(zhuǎn)換為圖片格式，則可能會占用較大的存儲空間，對于是否轉(zhuǎn)換可以由簽名用戶決定。
步驟2105，將所述待簽名文件與所述目標(biāo)簽名頁作為目標(biāo)簽名文件。即，將所述待簽名文件以附件的形式附屬于所述目標(biāo)簽名頁，本步驟可以通過將目標(biāo)簽名頁與所述待簽名文件打包為ZIP壓縮文件來實現(xiàn)。
步驟2106，獲得簽名信息。本步驟的具體實現(xiàn)可以參考步驟212中的相關(guān)描述。
步驟2107，為所述目標(biāo)簽名頁添加邊框。本步驟的具體實現(xiàn)可以參考步驟213中的相關(guān)描述。
步驟2108，將所述簽名信息添加至所述邊框并生成簽名頁。本步驟的具體實現(xiàn)可以參考步驟214中的相關(guān)描述。
步驟2109，判斷所述待簽名文件有無附件，若有則執(zhí)行步驟2110，否則執(zhí)行步驟2114。
步驟2110，生成目標(biāo)簽名文件。即將原目標(biāo)簽名文件中簽名頁、待簽名文件，以及所述附件合并為新的目標(biāo)簽名文件，本步驟的具體實現(xiàn)可以參考步驟216中的相關(guān)描述。
步驟2111，生成數(shù)字摘要或使用PKI(Public Key Infrastructure，公鑰基礎(chǔ)設(shè)施)技術(shù)生成數(shù)字簽名。本步驟的具體實現(xiàn)可以參考步驟217中的相關(guān)描述。
步驟2112，生成文件記錄。同樣，本步驟的具體實現(xiàn)可以參考步驟218中的相關(guān)描述，。
步驟2113，上載至服務(wù)器端的數(shù)據(jù)庫存儲并轉(zhuǎn)向步驟2117執(zhí)行。即將所述文件記錄上載至服務(wù)器端的數(shù)據(jù)庫中存儲。
步驟2114，生成數(shù)字摘要或使用PKI(Public Key Infrastructure，公鑰基礎(chǔ)設(shè)施)技術(shù)生成數(shù)字簽名。本步驟的具體過程可以參考步驟220中的相關(guān)描述。
步驟2115，生成文件記錄。本步驟的具體過程與實現(xiàn)可以參考步驟218中的相關(guān)描述。
步驟2116，上載至服務(wù)器端的數(shù)據(jù)庫存儲。本步驟的具體過程可以參考步驟222中的相關(guān)描述。
步驟2117，結(jié)束本次電子簽名的流程。
參考圖11，圖示了圖2中步驟21的具體電子簽名過程的再一個實施例的流程圖。本實施例中，所述的待簽名文件可以是任何格式的文件。本實施例實際為虛擬圖像框簽的一種情況，如圖所示，包括以下步驟步驟2300，獲得待簽名文件；所述待簽名文件是指需要進(jìn)行簽名操作的文檔，例如公文、審批單、音視頻會議記錄等等，獲得這些待簽名文件的方法可以通過網(wǎng)絡(luò)下載相關(guān)的文件，或者簽名者本人自行輸入文字或圖像材料等等。
步驟2301，判斷有無名片模版，若有，則執(zhí)行步驟2302，否則執(zhí)行步驟2303；其中，所述名片模版為用戶事先準(zhǔn)備的與該用戶相關(guān)的信息，其可以是圖片格式或是文字格式等，或者是用戶隨機(jī)準(zhǔn)備的信息等，本發(fā)明不受此限制。
步驟2302，調(diào)用所述名片模版，然后執(zhí)行步驟2304。即將所述用戶事先準(zhǔn)備好的名片模版調(diào)出，可以是將其顯示在屏幕上，例如所述客戶端的窗口中。
步驟2303，用戶選取任意的圖片或文字作為模版。所述的文字可以由用戶直接在文檔編輯窗口中輸入，并顯示在屏幕上，例如所述客戶端的窗口中。
步驟2304，將所述模版作為簽名頁；即，無論是名片模版還是用戶臨時準(zhǔn)備的模版，都將其看作簽名頁；所述簽名頁與所述模版在本質(zhì)上并無變化，本步驟是為了理解上的方便并與前文統(tǒng)一名稱。
步驟2305，獲得簽名信息；本步驟的具體過程可以參考步驟213中的相關(guān)描述，在此不進(jìn)行重復(fù)。
步驟2306，顯示簽名頁和簽名信息，并將所述簽名頁、簽名信息、待簽名文件作為目標(biāo)簽名文件；即，在得到所述簽名信息后便將所述簽名信息添加到所述簽名頁中并在屏幕上顯示，具體的實現(xiàn)可以采用圖4所示實施例中生成一個邊框并將所述簽名信息添加到該邊框的形式，相關(guān)內(nèi)容可以參考圖4實施例中的相關(guān)描述。同時，將所述簽名頁、簽名信息、待簽名文件作為目標(biāo)簽名文件，具體可以通過ZIP壓縮來實現(xiàn)。
本實施例與圖4所示實施例的最大的不同在于，圖4所示的實施例中將生成的邊框及該邊框上的簽名信息都作為所述簽名頁的一部分，也就是說所述簽名頁是包括目標(biāo)簽名頁、邊框及簽名信息的一個圖像文件，其存儲也是作為圖像格式來存儲；而本實施例中，僅是根據(jù)所述簽名頁和簽名信息臨時生成一個如步驟214中的簽名頁并顯示于屏幕上，并且所述的簽名信息不與所述簽名頁作為一個整體的圖像文件來存儲，而是分開存儲。這樣做可以節(jié)省存儲空間，因為圖片格式的簽名頁將占用較大的存儲空間。
步驟2307，判斷所述待簽名文件有無附件，若有，則執(zhí)行步驟2308，否則執(zhí)行步驟2312；步驟2308，生成目標(biāo)簽名文件；即將原目標(biāo)簽名文件中簽名頁、簽名信息、待簽名文件，以及所述附件合并為新的目標(biāo)簽名文件，本步驟的具體實現(xiàn)可以參考步驟216中的相關(guān)描述。
步驟2309，生成數(shù)字摘要或PKI數(shù)字簽名；所述生成數(shù)字摘要的過程為以所述目標(biāo)簽名文件的二進(jìn)制代碼為對象利用單向加密Hash算法(哈希算法)生成一段代碼，所述單向加密Hash算法(哈希算法)可以采用MD5算法或SHA-1算法等等。若使用PKI數(shù)字簽名，則將所述數(shù)字簽名模塊集成至客戶端中以供調(diào)用，此時，簽名用戶要人工輸入私鑰，或事先將私鑰保存在當(dāng)?shù)刂鳈C(jī)上(如U盤上)，由客戶端讀取，或者也可以調(diào)用外部數(shù)字簽名模塊進(jìn)行操作。由于PKI數(shù)字簽名技術(shù)是已經(jīng)相當(dāng)成熟的現(xiàn)有技術(shù)，在此不再進(jìn)行進(jìn)一步的闡述。
需要說明的是，由于所述目標(biāo)簽名文件中包含了簽名信息，而該簽名信息中又包括簽名時間、簽名操作所在的位置信息、用戶姓名，而且所述簽名時間信息從服務(wù)器獲得，所述簽名操作所在的位置信息從簽名操作所在主機(jī)獲得并由服務(wù)器驗證、所述用戶姓名也從服務(wù)器獲得。因此再將包含上述簽名信息的目標(biāo)簽名文件進(jìn)行PKI數(shù)字簽名，或者直接生成數(shù)字摘要，便可以保證PKI數(shù)字簽名的結(jié)果以及直接生成的數(shù)字摘要具有基于所述簽名時間的時間上的唯一性、具有基于所述簽名操作所在位置的空間上的唯一性；并且，通過步驟22的身份驗證過程可保證所述用戶(即簽名人)的簽名人的唯一性，防止其他人頂替簽名或者逼迫簽名人違背其真正意志進(jìn)行簽名。步驟22的具體過程可以參考后續(xù)的描述。所述時間唯一性是指即使是同一用戶在同一地點對同一文件進(jìn)行兩次簽名其結(jié)果也是不一樣的，因為兩次簽名的時間不同；所述空間唯一性是指同一用戶在同一時間在不同的地點對同一文件進(jìn)行簽名其結(jié)果也是不同的；所述簽名人唯一性是指即使是不同的用戶對同一文件在同一地點、同一時間進(jìn)行簽名其結(jié)果是不同的，簽名人唯一性本來是不應(yīng)該有疑問的，但由于身份失竊和找人代簽的問題，簽名文件的簽名人究竟是否就是所聲稱的簽名人就存在了疑問，因此通過步驟22的身份驗證過程便可以保證簽名人的唯一性。
步驟2310，生成文件記錄；即將步驟2309中所使用的簽名方法(使用單向加密算法生成數(shù)字摘要，或PKI數(shù)字簽名等)、簽名結(jié)果(即所述數(shù)字摘要或PKI數(shù)字簽名結(jié)果)以及所述目標(biāo)簽名文件中的內(nèi)容保存至文件記錄中。這里，所述的文件記錄的結(jié)構(gòu)可以看作數(shù)據(jù)庫中的數(shù)據(jù)表的一條記錄的結(jié)構(gòu)，結(jié)構(gòu)中包括若干不同的字段用以存儲上述信息。
步驟2311，上載至服務(wù)器端的數(shù)據(jù)庫存儲并轉(zhuǎn)向步驟2315執(zhí)行。即將所述文件記錄上載至服務(wù)器端的數(shù)據(jù)庫中存儲。
步驟2312，生成數(shù)字摘要或PKI數(shù)字簽名；本步驟的具體過程可以參考步驟2308中的相關(guān)描述。
步驟2313，生成文件記錄；本步驟的具體過程可以參考步驟2310中的相關(guān)描述。
步驟2314，上載至服務(wù)器端的數(shù)據(jù)庫存儲并轉(zhuǎn)向步驟2315執(zhí)行。即將所述文件記錄上載至服務(wù)器端的數(shù)據(jù)庫中存儲。
步驟2315，結(jié)束本次電子簽名的過程。
在圖2中步驟21的具體電子簽名過程的又一個實施例中，所述待簽名文件為已經(jīng)經(jīng)過簽名的文件，即該實施例具體為一種再簽名的方法。下面將簡要闡述這種方法第一步，要進(jìn)行再簽名的用戶向服務(wù)器提交查詢文件記錄的請求。本步驟的目的在于，使該用戶找到他須要進(jìn)行再次簽名的文件記錄；第二步，服務(wù)器響應(yīng)所述請求，并在所述用戶的客戶端顯示文件記錄。所述文件記錄中包括簽名頁、附件、簽名結(jié)果(數(shù)字摘要或是PKI數(shù)字簽名結(jié)果)、簽名方法(形成數(shù)字摘要或是PKI數(shù)字簽名)，還可以包括簽名信息等等；第三步，所述用戶對所述文件記錄進(jìn)行鑒別判斷是否有問題。在這里，其一是對所述電子簽名的真實性進(jìn)行判斷，其二是所述用戶判斷是否同意簽署該文件；對于電子簽名的真實性判斷，可以通過對該文件重復(fù)所述文件記錄中的簽名方法得到簽名結(jié)果，并將所述簽名結(jié)果與所述文件記錄中的簽名結(jié)果進(jìn)行比對是否一致；第四步，若所述用戶對該文件無異議，則對其進(jìn)行電子簽名。所述電子簽名的過程相對于圖4和圖7所示的實施例的過程較為簡單，因為這里的目標(biāo)簽名頁即來自所述文件記錄中的簽名頁，簽名的對象還包括所述文件記錄中的附件(原始的部分或全部待簽名文件，以及該待簽名文件的附件等)。因此，其具體過程可以參考圖4中步驟212以后的過程，或圖7中步驟2106以后的過程，為了避免重復(fù)，對于具體過程不作進(jìn)一步闡述，這里僅就其需要注意的地方進(jìn)行說明本實施例中，該進(jìn)行再次簽名的用戶在電子簽名后也需要將所述簽名結(jié)果、簽名方法等信息追加至所述文件記錄中，對于虛擬圖像框簽來說，還需要將該進(jìn)行再次簽名的用戶的簽名信息追加至所述文件記錄中。系統(tǒng)還可以為再次簽名用戶創(chuàng)建單獨(dú)的文件記錄，該文件記錄只需要保存再簽名信息和包含原始簽名文件的文件記錄標(biāo)識號。
需要說明的是，所述的簽名信息記錄區(qū)域并不限于所述的邊框，還可以是僅位于簽名頁下方的區(qū)域，可以是任意的形狀，本發(fā)明不受此限制。
另外，本具體實施方式
中的進(jìn)行圖像合成或顯示等的操作并不限于2D圖像工具，還可以采用更為先進(jìn)的3D圖像工具等。
參考圖8，圖示了圖2中步驟22的具體驗證過程的一個實施例的流程圖。如圖所示，包括以下步驟步驟2210，根據(jù)預(yù)留方式發(fā)送確認(rèn)請求。即服務(wù)器端接收到所述簽名文件后，便根據(jù)預(yù)留的方式向所述簽名的簽名用戶發(fā)送確認(rèn)簽名的請求。其中，所述預(yù)留的方式為所述注冊過程20中由用戶或系統(tǒng)管理員所提供，其至少包括下述方式中的一種電子郵件、固定電話、移動電話、互聯(lián)網(wǎng)即時通訊工具、人工方式；所述電子郵件方式是指由服務(wù)器端向用戶在注冊過程20中所留下的電子郵件地址發(fā)送確認(rèn)請求，所述固定電話方式是指由服務(wù)器端向用戶在注冊過程20中所留下的固定電話語音留言確認(rèn)請求，所述移動電話方式是指由服務(wù)器端向用戶在注冊過程20中所留下的移動電話號碼發(fā)送短信息形式的確認(rèn)請求或語音留言式的確認(rèn)請求，所述互聯(lián)網(wǎng)即時通訊工具方式是指由服務(wù)器端向用戶在注冊過程20中所留下互聯(lián)網(wǎng)即時通訊工具(例如OICQ、ICQ、MSN等等)的ID發(fā)出確認(rèn)請求消息，所述人工方式是指由系統(tǒng)中的另一用戶(具有身份確認(rèn)權(quán)限的用戶，例如系統(tǒng)管理員或聘請的公證員等)在注冊過程20中所留下的可能的通信方式，例如打電話的方式，人工傳達(dá)所述確認(rèn)請求。
另外，所述確認(rèn)請求中的內(nèi)容至少包括下述信息中的一種簽名時間、簽名地點、簽名文件標(biāo)題、簽名文件摘要、所述簽名文件唯一性標(biāo)識等。
步驟2211，用戶收到所述確認(rèn)請求。此時，用戶即為所述接收方。
步驟2212，所述用戶根據(jù)上一步驟中所接收的確認(rèn)請求判斷所述簽名是否為自己真實意愿的簽名。其中，所述用戶可以根據(jù)所述簽名文件唯一性標(biāo)識(例如該文件在數(shù)據(jù)庫中的記錄號等等)在所述服務(wù)器端查找到所述簽名文件，從而判斷是否為自己真實意愿的簽名，或者僅根據(jù)所述簽名時間、簽名地點、簽名文件標(biāo)題、簽名文件摘要等做出判斷。
若所述用戶最終判斷所述簽名是自己真實意愿的簽名，則執(zhí)行步驟2215，否則執(zhí)行步驟2213。
步驟2213，用戶報告身份失竊。即用戶向服務(wù)器端上報有人偽造簽名，其可以通過電話的方式向系統(tǒng)管理員報告，或者通過網(wǎng)頁表單上報等等。
步驟2214，服務(wù)器端接收到所述身份失竊的上報信息后，便將所述電子簽名視為無效簽名，因而對應(yīng)的簽名文件也不具有法律效力。本步驟后執(zhí)行步驟2217。
步驟2215，所述用戶上報確認(rèn)所述簽名。該過程可以是顯式的上報，例如通過網(wǎng)頁，或者電話等上報，或者為隱式的上報，即服務(wù)器端可以設(shè)定為若在一定的時間內(nèi)沒有接收到來自該用戶的確認(rèn)簽名或否認(rèn)簽名的報告，則認(rèn)為該用戶確認(rèn)所述簽名為其真實意愿的簽名。
步驟2216，服務(wù)器端接收到所述顯式上報或推定為隱式上報后，則將所述簽名視為有效簽名，相應(yīng)的文件也具有相應(yīng)的法律效力。
步驟2217，結(jié)束本次簽名的驗證過程。
參考圖9，圖示了圖2中步驟22的具體驗證過程的另一個實施例的流程圖。如圖所示，包括以下步驟步驟2220，根據(jù)預(yù)留方式發(fā)送確認(rèn)請求。即服務(wù)器端接收到所述簽名文件后，便根據(jù)預(yù)留的方式向所述簽名的簽名用戶發(fā)送確認(rèn)簽名的請求。其中的具體過程及實現(xiàn)可以參考步驟2210中的相關(guān)闡述。
步驟2221，用戶收到所述確認(rèn)請求。此時，用戶即為所述接收方。
步驟2222，所述用戶根據(jù)上一步驟中所接收的確認(rèn)請求判斷所述簽名是否為自己真實意愿的簽名，若是，則執(zhí)行步驟2223，否則執(zhí)行步驟2225。其中，所述用戶可以根據(jù)所述簽名文件唯一性標(biāo)識(例如該文件在數(shù)據(jù)庫中的記錄號等等)在所述服務(wù)器端查找到所述簽名文件，從而判斷是否為自己真實意愿的簽名，或者僅根據(jù)所述簽名時間、簽名地點、簽名文件標(biāo)題、簽名文件摘要等做出判斷。
步驟2223，用戶發(fā)送驗證信息。即通過上一步判斷后，所述用戶認(rèn)為所述電子簽名為自己的真實意愿的簽名，則該用戶可以向所述服務(wù)器端發(fā)送在所述注冊過程20中留下的確認(rèn)簽名的驗證碼或是回答留下的問題等，該過程同樣可以通過人工的方式和非人工的方式來實現(xiàn)，人工的方式可以通過直接與系統(tǒng)管理員進(jìn)行溝通告知驗證碼或所述問題的答案等，非人工的方式可以通過網(wǎng)頁表單傳輸驗證碼或所述問題的答案等。
該過程還可以是一個互動的過程，由系統(tǒng)自動地與簽名人互動而確認(rèn)簽名人的身份，例如在確認(rèn)請求中，簽名人用戶被要求登陸系統(tǒng)進(jìn)行身份驗證，用戶登陸后，系統(tǒng)可以提示用戶輸入身份確認(rèn)密碼以便驗證身份；或者系統(tǒng)提示用戶讀一段文字，系統(tǒng)錄音采集聲音樣本與數(shù)據(jù)庫中所儲存的該用戶樣本相比較而確認(rèn)身份。
步驟2224，服務(wù)器端判斷所述驗證信息是否正確，若正確，則執(zhí)行步驟2226，否則執(zhí)行步驟2225。對于所述驗證碼方式來說只需驗證與注冊過程預(yù)留的驗證碼是否一致，若一致則認(rèn)為是正確的，否則反之。對于所述回答問題的方式來說，只需判斷用戶所提供的答案是否與注冊過程中所留下的答案一致，若一致則認(rèn)為是正確的，否則反之。
步驟2225，服務(wù)器端將所述電子簽名視為無效，因而對應(yīng)的簽名文件也不具有法律效力并轉(zhuǎn)向步驟2227執(zhí)行。
步驟2226，服務(wù)器端將所述電子簽名視為有效。
步驟2227，結(jié)束本次簽名驗證過程。
參考圖10，圖示了圖2中步驟22的具體驗證過程的再一個實施例的流程圖。如圖所示，包括以下步驟步驟2230，發(fā)送驗證通知至驗證人員。此過程由服務(wù)器端來完成，可以通過電話通知的方式，或電子郵件的方式等。所述驗證通知至少包括下述信息中的一種簽名時間、簽名地點、簽名文件標(biāo)題、簽名文件摘要、所述簽名文件唯一性標(biāo)識。
步驟2231，驗證人員接收所述驗證通知。此時，驗證人員即為所述接收方。
步驟2232，所述驗證人員根據(jù)所述驗證通知判斷所述簽名是否為所述用戶的真實意愿的簽名，若是，則執(zhí)行步驟2234，否則執(zhí)行步驟2233。這里由于是人工進(jìn)行驗證，所以可以采用的方式很靈活，比如直接找所述用戶進(jìn)行面談確認(rèn)，或者親自打電話詢問，或者根據(jù)在注冊過程20中所留下的生物樣本(例如聲音、指紋等)進(jìn)行驗證等等。例如，該過程可以是一個人工互動的過程，有身份確認(rèn)權(quán)限的用戶(例如第三方的具有公證員資格的用戶)可以使用多種互動的方式進(jìn)行身份確認(rèn)，該用戶還起到簽名過程目擊和公證的作用，從而使該電子簽名可以滿足更高的法律要求，該用戶可使用本文所述的再框簽過程進(jìn)行電子簽名而留下目擊和公證記錄。
步驟2233，服務(wù)器端將所述電子簽名視為無效簽名，因而對應(yīng)的簽名文件也不具有法律效力。本步驟后執(zhí)行步驟2235。
步驟2234，服務(wù)器端將所述電子簽名視為有效簽名。
步驟2235，結(jié)束本次簽名驗證流程。
本具體實施方式
中接收方均為人工，但是還可以是計算機(jī)等等。
總之，不同的身份確認(rèn)方式解決電子簽名中的不同問題，這也是用戶和系統(tǒng)管理員在設(shè)置身份確認(rèn)方式時要考慮的。如果身份確認(rèn)方式為隱式電子郵件和短信的方式，這可以解決身份失竊的問題；如果身份確認(rèn)方式為顯式互動的方式，不僅可以解決身份失竊的問題，而且可以確定簽名人是否是自愿的或是否是在神智清醒地情況下簽名，這是因為●簽名人用戶如果是在被脅迫下而非志愿地進(jìn)行的簽名和身份確認(rèn)，該用戶可以故意答錯互動的問題或身份密碼，系統(tǒng)會向有關(guān)系統(tǒng)管理員示警，系統(tǒng)管理員將會采取相應(yīng)措施。
●簽名人用戶如果是在非神智清醒地情況，該用戶不能答對互動中的問題●簽名人用戶參與身份確認(rèn)并答對互動的問題，特別是包裹使用了聲音樣本對比方法的互動可排除由其他人代簽的可能，那么該用戶的身份就可得以確認(rèn)，系統(tǒng)視簽名記錄為有效，該電子簽名符合傳統(tǒng)簽名的所有法律要求。它除具有不可篡改性外，還具有不可抵賴性。
以上所揭露的僅為本發(fā)明一種較佳實施例而已，當(dāng)然不能以此來限定本發(fā)明之權(quán)利范圍，因此依本發(fā)明權(quán)利要求所作的等同變化，仍屬本發(fā)明所涵蓋的范圍。
權(quán)利要求
1.一種電子簽名的身份驗證方法，其包括以下步驟a、服務(wù)器向接收方發(fā)出確認(rèn)請求；b、接收方根據(jù)所述確認(rèn)請求進(jìn)行驗證并產(chǎn)生驗證結(jié)果；c、服務(wù)器根據(jù)所述驗證結(jié)果確定是否為真實簽名。
2.如權(quán)利要求1所述的方法，其特征在于，所述步驟a具體為根據(jù)預(yù)留方式向電子簽名的簽名用戶發(fā)出確認(rèn)請求。
3.如權(quán)利要求2所述的方法，其特征在于，所述預(yù)留方式包括以下方式中的至少一種電子郵件、固定電話、移動電話、互聯(lián)網(wǎng)即時通訊工具、人工方式。
4.如權(quán)利要求2所述的方法，其特征在于，步驟b具體為所述簽名用戶根據(jù)所述確認(rèn)請求對所述電子簽名的真實性進(jìn)行驗證并產(chǎn)生肯定或否定的驗證結(jié)果。
5.如權(quán)利要求1、2、3、4中任一項所述的方法，其特征在于，所述確認(rèn)請求至少包括下述信息中的一種簽名時間、簽名地點、簽名文件標(biāo)題、簽名文件摘要、所述簽名文件唯一性標(biāo)識。
6.如權(quán)利要求1所述的方法，其特征在于，所述確認(rèn)請求為對所述電子簽名的身份驗證通知，其發(fā)送至驗證人員。
7.如權(quán)利要求6所述的方法，其特征在于，步驟b具體為所述驗證人員根據(jù)所述驗證通知進(jìn)行驗證并產(chǎn)生肯定或否定的驗證結(jié)果。
8.如權(quán)利要求7所述的方法，其特征在于，所述驗證人員至少按照下述各種方式中的一種進(jìn)行驗證身份確認(rèn)密碼驗證、人工電話驗證、人工移動電話驗證、生物樣本驗證。
9.如權(quán)利要求7所述的方法，其特征在于，所述驗證通知至少包括下述信息中的一種簽名時間、簽名地點、簽名文件標(biāo)題、簽名文件摘要、所述簽名文件唯一性標(biāo)識。
10.如權(quán)利要求4或7所述的方法，其特征在于，步驟c具體為若步驟b產(chǎn)生肯定的驗證結(jié)果，則認(rèn)為所述電子簽名為有效簽名；若步驟b產(chǎn)生否定的驗證結(jié)果，則認(rèn)為所述電子簽名為無效簽名。
全文摘要
本發(fā)明公開了一種電子簽名的身份驗證方法，其包括以下步驟a.服務(wù)器向接收方發(fā)出確認(rèn)請求；b.接收方根據(jù)所述確認(rèn)請求進(jìn)行驗證并產(chǎn)生驗證結(jié)果；c.服務(wù)器根據(jù)所述驗證結(jié)果確定是否為真實簽名。實施本發(fā)明能夠根據(jù)實際地需要而設(shè)計預(yù)留使用不同的方法，實現(xiàn)對電子簽名的用戶的身份的真實性的驗證，從而確定是否是所述簽名的簽名者的身份是否失竊，是否是真實意愿的簽名和是否是由其他人代簽，以確保簽名人身份的真實性和簽名的不可抵賴性。
文檔編號H04L9/32GK101090320SQ20071001686
公開日2007年12月19日 申請日期2007年7月13日 優(yōu)先權(quán)日2007年7月13日
發(fā)明者王少波, 馬修·梅葉 申請人:王少波