專利名稱：對移動中數(shù)據(jù)進行保護的系統(tǒng)和方法
技術領域：
本發(fā)明一般涉及用于通過將信任分布到多個認證機構中對通信進行保護的系統(tǒng)和方法?？梢耘c在共同擁有的美國專利N0.7391865和在2005年10月25日提交的共同擁有的美國專利申請N0.11/258839、2006年11月20日提交的美國專利申請N0.11/602667、2007年11月7日提交的美國專利申請N0.11/983355、2007年12月5日提交的美國專利申請N0.11/999575、2008年4月18提交的美國專利申請N0.12/148365、2008年9月12提交的美國專利申請N0.12/209703,2009年I月7提交的美國專利申請N0.12/349897和2009年2月23提交的美國專利申請N0.12/391025中描述的其它系統(tǒng)和方法結合地使用本文所述的系統(tǒng)和方法，上述所有的美國專利和專利申請的全部內容通過引用并入本文。
背景技術：
在當今社會中，個人和企業(yè)通過計算機系統(tǒng)進行越來越多的活動。這些計算機系統(tǒng)包括專有和非專有的計算機網絡，常常存儲、存檔和發(fā)送所有類型的敏感信息。因此，日益需要確保通過這些系統(tǒng)進行存儲和發(fā)送的數(shù)據(jù)不會被讀取或以其它方式被泄露。一種方案是使用認證機構的密鑰來保護數(shù)據(jù)。認證機構可以由發(fā)放數(shù)字證書的受信任的第三方組織或公司運行，所述數(shù)字證書諸如為VeriSign、Baltimore、Entrust等。數(shù)字證書證明該證書的命名主體對公鑰的所有權。這允許他人依靠通過與認證的公鑰對應的私鑰進行的簽名或斷言?？梢酝ㄟ^數(shù)字證書協(xié)議(諸如PKCS10)進行對數(shù)字證書的請求。響應于該請求，認證機構將以許多不同的協(xié)議(諸如PKCS7)發(fā)放證書。可以基于發(fā)放的證書在裝置之間交換消息。如果認證機構受到危害，那么對于認證機構正在認證公鑰和身份之間的聯(lián)系的每個用戶而言，系統(tǒng)的安全性喪失。例如，攻擊者可以通過誘導認證機構發(fā)放假稱代表一實體的證書來危害該認證機構。攻擊者將具有與認證機構的證書關聯(lián)的私鑰。攻擊者于是能夠使用該證書向用戶發(fā)送經數(shù)字簽名的消息，并欺騙該用戶使之相信該消息來自于信任實體。用戶可以對經數(shù)字簽名的消息進行相應，攻擊者會使用私鑰對其進行解密。因此，用戶對于認證機構的信任會受到危害。

發(fā)明內容
基于上述內容，需要提供一種安全代理服務，該安全代理服務包括通過在一組認證機構之中分布信任來保護通信的系統(tǒng)。因此，本發(fā)明提供在一組認證機構之中分布信任的兩種方案。這兩種方案是同等安全的。在每種方案中，可以將安全數(shù)據(jù)解析器與任何合適的加密技術整合。應該理解，在一些實施例中，可以通過將安全數(shù)據(jù)解析器與全傳輸層安全(Transport LayerSecurity, “TLS”)協(xié)議,與安全套接字層(Secure Sockets Layer, SSL)協(xié)議,與 SSL 和全TLS協(xié)議整合，或者在不使用SSL和/或全TLS的情況下實現(xiàn)安全數(shù)據(jù)解析器，可以實現(xiàn)安全代理服務。另外，應該理解，在一些實施例中，可以結合利用認證機構來確保交換消息的保密性、完整性和真實性的任何合適協(xié)議來實現(xiàn)安全代理服務。
因此，本發(fā)明的一個方案提供了使用安全數(shù)據(jù)解析器在裝置之間的連接的初始協(xié)商期間(例如密鑰建立階段)在一組認證機構之中分布信任的方法和系統(tǒng)。認證機構的唯一性可以在于，每個認證機構發(fā)放的證書具有不同的公鑰和私鑰對。這提供了以下保證:如果某些(但少于定額的)認證機構已被危害，仍能建立連接，并且可以在不破壞通信的保密性或完整性的情況下交換消息。
該方案的一個方面是提供用于計算共享加密密鑰的方法和系統(tǒng)。該共享加密密鑰的計算可以是裝置間的安全通信的密鑰建立階段的一部分?？梢援a生秘密信息，可以從唯一的認證機構獲得公鑰。該秘密信息可被分散到任意數(shù)量的秘密信息份(Share)中。每個秘密信息份可以基于與多個唯一的認證機構中的不同一個關聯(lián)的證書的公鑰進行加密?？蛇x地，每個秘密信息份可以基于密鑰包裝(keywrap)進行加密。密鑰包裝可以基于工作組密鑰。在一些實施例中，各份可被重新組合，并且可以基于重新組合的份來發(fā)送數(shù)據(jù)。
在一些實施例中，可以產生一組隨機數(shù)?？梢曰谠摻M隨機數(shù)和原始秘密信息計算第一共享加密密鑰?？梢曰谠摻M隨機數(shù)和重新組合的份計算第二共享加密密鑰?？梢曰诘谝缓偷诙蚕砑用苊荑€發(fā)送數(shù)據(jù)。在一些實施例中，可以比較第一和第二共享加密密鑰。可以基于該比較來確定是否發(fā)送數(shù)據(jù)，并且可以基于該確定發(fā)送數(shù)據(jù)。
本發(fā)明的另一個方案提供使用安全數(shù)據(jù)解析器來預處理數(shù)據(jù)包的方法和系統(tǒng)。預處理的數(shù)據(jù)然后可被分散到多個份中。可以使用由唯一的認證機構發(fā)放的證書在通信信道內建立一組隧道，在該建立期間形成的密鑰可用于對每個隧道的數(shù)據(jù)進行加密，可以在各個隧道上發(fā)送數(shù)據(jù)的各個份。因此，在第二方案中，可以在通信信道自身的結構中在一組認證機構之中分布信任。
該方案的一個方面提供用于保護移動中數(shù)據(jù)的方法和系統(tǒng)。移動中數(shù)據(jù)可包括原始數(shù)據(jù)包?？梢越踩ㄐ判诺??？梢曰谠诙鄠€唯一認證機構之中分布的信任在該安全通信信道內建立任意數(shù)量的安全通信隧道。在一些實施例中，可以使用由多個唯一的認證機構中的不同一個發(fā)放的證書建立各個安全通信隧道。每個原始數(shù)據(jù)包可以準備基于在一組認證機構之中分布的信任和多因素秘密共享，在安全通信隧道上發(fā)送。在一些實施例中，基于多因素秘密共享，每個原始數(shù)據(jù)包可被分散到多個份中?？蛇x地，該分散可基于N中取M密碼術分裂?？梢曰谂c安全通信隧道中的不同一個的建立關聯(lián)的密鑰來加密這些份。在一些實施例中，每個加密的份可以在用于對該份加密的安全通信隧道上發(fā)送。
在一些實施例中，每個安全通信隧道可以基于與多個唯一的認證機構中的不同一個關聯(lián)的證書來建立。在一些實施例中，每個安全通信隧道可以與由多個唯一的認證機構之一發(fā)放的證書關聯(lián)，其中安全通信隧道是在這些認證機構下建立的。例如，在多個唯一的認證機構之一的證書和安全通信隧道之間可以存在一一對應關系。在一些實施例中，這些關聯(lián)可以是動態(tài)的。在一些實施例中，通過重新組合至少定額的份，可以恢復這些份。
在一些實施例中，每個加密的份可以在各自的安全通信隧道上被接收?？梢曰谂c安全通信隧道的建立關聯(lián)的密鑰對每個份進行解密?？梢曰诶缍嘁蛩孛孛芄蚕韥砘謴驮紨?shù)據(jù)包。在一些實施例中，可以產生認證機構層級。認證機構層級可包括一組根認證機構、一組次要認證機構、或者這兩者。該組認證機構可包括產生的認證機構層級中的該組根認證機構、該組次要認證機構、或者這兩者。在一些實施例中，N個安全通信隧道中的每個可以在不同的物理傳輸介質上建立。在一些實施例中，這些物理傳輸介質中的至少一個可能發(fā)生故障，但是仍可在不損失數(shù)據(jù)完整性的情況下恢復原始數(shù)據(jù)包。在一些實施例中，一部分的份被指定在故障的物理傳輸介質中的至少一個上傳輸，但是一些物理傳輸介質是可工作的。在這樣的實施例中，可以在至少一個可工作的物理傳輸介質內建立另外的安全通信隧道。可以在該另外的安全通信隧道上傳輸指定在至少一個故障的物理傳輸介質上傳輸?shù)哪遣糠值姆?。在一些實施例中，可以以任何合適的方式組合這兩種方案。例如，可以使用第一方案的密鑰建立技術建立第二方案中的任意數(shù)量的安全通信隧道。


在下文中結合附圖更加詳細描述本發(fā)明，這些附圖旨在例示而非限制本發(fā)明，在附圖中:圖1示出了根據(jù)本發(fā)明的實施例的各方面的密碼系統(tǒng)的框圖；圖2示出了根據(jù)本發(fā)明的實施例的各方面的圖1的信任引擎的框圖；圖3示出了根據(jù)本發(fā)明的實施例的各方面的圖2的事務引擎的框圖；圖4示出了根據(jù)本發(fā)明的實施例的各方面的圖2的儲存器(depository)的框圖；圖5示出了根據(jù)本發(fā)明的實施例的各方面的圖2的認證引擎的框圖；圖6示出了根據(jù)本發(fā)明的實施例的各方面的圖2的密碼引擎的框圖；圖7示出了根據(jù)本發(fā)明的另一個實施例的各方面的儲存器系統(tǒng)的框圖；圖8示出了根據(jù)本發(fā)明的實施例的各方面的數(shù)據(jù)分裂過程的流程圖；圖9A示出了根據(jù)本發(fā)明的實施例的各方面的登記過程的數(shù)據(jù)流；圖9B示出了根據(jù)本發(fā)明的實施例的各方面的互用性過程的流程圖；圖10示出了根據(jù)本發(fā)明的實施例的各方面的認證過程的數(shù)據(jù)流；圖11示出了根據(jù)本發(fā)明的實施例的各方面的簽名過程的數(shù)據(jù)流；圖12示出了根據(jù)本發(fā)明的另一個實施例的各方面的加密/解密過程的數(shù)據(jù)流；圖13示出了根據(jù)本發(fā)明的另一個實施例的各方面的信任引擎系統(tǒng)的簡化框圖；圖14示出了根據(jù)本發(fā)明的另一個實施例的各方面的信任引擎系統(tǒng)的簡化框圖；圖15示出了根據(jù)本發(fā)明的實施例的各方面的圖14的冗余模塊的框圖；圖16示出了根據(jù)本發(fā)明的一個方面的評估認證的過程；圖17示出了根據(jù)本發(fā)明的如在圖16中所示的一個方面向認證分配值的過程；圖18示出了在如圖17所示的本發(fā)明的一個方面中執(zhí)行信任仲裁的過程；以及圖19示出了根據(jù)本發(fā)明的實施例的各方面的用戶與賣方之間的樣本事務，其中，初始基于web的合同導致由雙方簽名的銷售合同。圖20示出了具有向用戶系統(tǒng)提供安全性功能的密碼服務提供商模塊的樣本用戶系統(tǒng)。
圖21示出了在加密以及加密主密鑰與數(shù)據(jù)存儲在一起的情況下解析、分裂和/或分離數(shù)據(jù)的過程。
圖22示出了在加密以及加密主密鑰與數(shù)據(jù)分離地存儲的情況下解析、分裂和/或分離數(shù)據(jù)的過程。
圖23示出了在加密以及加密主密鑰與數(shù)據(jù)存儲在一起的情況下解析、分裂和/或分離數(shù)據(jù)的中間密鑰過程。
圖24示出了在加密以及加密主密鑰與數(shù)據(jù)分離地存儲的情況下解析、分裂和/或分離數(shù)據(jù)的中間密鑰過程。
圖25示出了小工作組對本發(fā)明的密碼方法和系統(tǒng)的利用。
圖26是采用根據(jù)本發(fā)明的一個實施例的安全數(shù)據(jù)解析器的例示性物理令牌安全性系統(tǒng)的框圖。
圖27是根據(jù)本發(fā)明的一個實施例的將安全數(shù)據(jù)解析器集成到系統(tǒng)中的例示性布置的框圖。
圖28是根據(jù)本發(fā)明的一個實施例的例示性移動中數(shù)據(jù)系統(tǒng)的框圖。
圖29是根據(jù)本發(fā)明的一個實施例的另一個例示性移動中數(shù)據(jù)系統(tǒng)的框圖。
圖30-32是根據(jù)本發(fā)明的一個實施例的集成了安全數(shù)據(jù)解析器的例示性系統(tǒng)的框圖。
圖33是根據(jù)本發(fā)明的一個實施例的解析和分裂數(shù)據(jù)的例示性過程的處理流程圖。
圖34是根據(jù)本發(fā)明的一個實施例的將數(shù)據(jù)部分恢復成原始數(shù)據(jù)的例示性過程的處理流程圖。
圖35是根據(jù)本發(fā)明的一個實施例的以比特級分裂數(shù)據(jù)的例示性過程的處理流程圖。
圖36是根據(jù)本發(fā)明的一個實施例的例示性步驟和特征的處理流程圖。
圖37是根據(jù)本發(fā)明的一個實施例的例示性步驟和特征的處理流程圖。
圖38是根據(jù)本發(fā)明的一個實施例的在份內存儲密鑰和數(shù)據(jù)成分的簡化框圖。
圖39是根據(jù)本發(fā)明的一個實施例的使用工作組密鑰在份內存儲密鑰和數(shù)據(jù)成分的簡化框圖。
圖40A和40B是根據(jù)本發(fā)明的一個實施例的針對移動中數(shù)據(jù)的首標產生和數(shù)據(jù)分裂的簡化和例示性處理流程圖。
圖41是根據(jù)本發(fā)明的一個實施例的例示性份格式的簡化框圖。
圖42是根據(jù)本發(fā)明的一個實施例的簡化和例示性的認證機構的層級。
圖43_47、48A和48B是根據(jù)本發(fā)明的一個實施例的安全代理服務的例示性步驟和特征的處理流程圖。
圖48C是根據(jù)本發(fā)明的一個實施例的在通信信道的結構中在一組認證機構之中分布信任的安全代理服務的簡化框圖。
圖49和50是根據(jù)本發(fā)明的一個實施例的在通信信道的結構中在一組認證機構之中分布信任的安全代理服務的例示性步驟和特征的處理流程圖。
具體實施例方式本發(fā)明的一個方面是提供一種密碼系統(tǒng)，在該密碼系統(tǒng)中，一個或多個安全服務器或信任引擎存儲密碼密鑰和用戶認證數(shù)據(jù)。用戶通過對信任引擎的網絡訪問，訪問傳統(tǒng)密碼系統(tǒng)的功能，然而，信任引擎沒有發(fā)布實際密鑰和其它認證數(shù)據(jù)，因此這些密鑰和數(shù)據(jù)仍是安全的。密鑰和認證數(shù)據(jù)的這種服務器中心存儲提供了用戶無關的安全性、移植性、可用性和直率性。因為用戶能夠確信或信任密碼系統(tǒng)來執(zhí)行用戶和文檔認證以及其它密碼功能，所以多種多樣的功能可以包括在該系統(tǒng)內。例如，通過例如對協(xié)議參與者進行認證，代表或針對參與者對該協(xié)議進行數(shù)字簽名，并且存儲由每個參與者數(shù)字簽名的協(xié)議的記錄，信任引擎提供商可以確保不會出現(xiàn)協(xié)議抵賴。此外，該密碼系統(tǒng)可以監(jiān)視協(xié)議并且例如基于價格、用戶、賣方、地理位置、使用地點等來確定應用不同程度的認證。為了便于完全理解本發(fā)明，具體實施方式
的其余部分參照附圖描述本發(fā)明，其中，相同元素始終由相同標號進行表示。圖1示出了根據(jù)本發(fā)明的實施例的各方面的密碼系統(tǒng)100的框圖。如圖1所示，密碼系統(tǒng)100包括通過通信鏈路125進行通信的用戶系統(tǒng)105、信任引擎110、認證機構115和賣方系統(tǒng)120。根據(jù)本發(fā)明的一個實施例，用戶系統(tǒng)105包括具有一個或多個微處理器(例如，基于Intel的處理器)的傳統(tǒng)通用計算機。此外，用戶系統(tǒng)105包括適當?shù)牟僮飨到y(tǒng)，例如能夠包括圖形或窗口的操作系統(tǒng)(例如，Windows、Unix、Linux等)。如圖1所示,用戶系統(tǒng)105可以包括生物測定裝置107。生物測定裝置107可以有利地獲取用戶的生物測定并且將獲取的生物測定傳送給信任引擎110。根據(jù)本發(fā)明的一個實施例，生物測定裝置可有利地包括具有與在以下文獻中公開的類似的屬性和特征的裝置:1997年9月5日提交的題目為“RELIEF OBJECT IMAGE GENERATOR”的美國專利申請 N0.08/926277、2000 年 4 月 26 日提交的題目為“IMAGING DEVICE FOR A RELIEF OBJECT AND SYSTEM AND METHOD OF USING THEIMAGE DEVICE”的美國專利申請N0.09/558634、1999年11月5日提交的題目為“RELIEFOBJECT SENSOR ADAPTOR”的美國專利申請N0.09/435011和2000年I月5日提交的題目為“PLANAR OPTICAL IMAGE SENSOR AND SYSTEM FOR GENERATING AN ELECTRONIC IMAGE OFARELIEF OBJECT FOR FINGERPINT READING”的美國專利申請 N0.09/477943，上述所有的美國專利申請由當前受讓人擁有并且通過引用并入本文。此外，用戶系統(tǒng)105可以通過傳統(tǒng)的服務提供商(例如，撥號、數(shù)字用戶線(DSL)、線纜調制解調器、光纖連接等)連接到通信鏈路125。根據(jù)另一個實施例，用戶系統(tǒng)105通過網絡連接性(例如，局域網或廣域網)連接通信鏈路125。根據(jù)一個實施例，操作系統(tǒng)包括TCP/IP棧，該TCP/IP棧處理在通信鏈路125上傳遞的所有的出入消息通信。盡管參照上述實施例公開了用戶系統(tǒng)105，但是本發(fā)明不限于此。相反，熟練技術人員從這里的公開可以識別用戶系統(tǒng)105的大量的替代實施例，包括能夠發(fā)送或從另一個計算機系統(tǒng)接收信息的幾乎任何計算裝置。例如，用戶系統(tǒng)105可以包括但不限于能夠與通信鏈路125進行交互的計算機工作站、交互式電視、交互亭、個人移動計算裝置(例如，數(shù)字助理、移動電話、膝上型電腦等)、個人聯(lián)網設備(諸如家庭路由器、網絡存儲裝置(“NAS”)、個人熱點等)、或者無線通信裝置、智能卡、嵌入式計算裝置等。在這些替代系統(tǒng)中，操作系統(tǒng)很可能不同并且針對特定裝置進行改動。然而，根據(jù)一個實施例，操作系統(tǒng)有利地繼續(xù)提供與通信鏈路125建立通信所需的適當?shù)耐ㄐ艆f(xié)議。
圖1示出了信任引擎110。根據(jù)一個實施例，信任引擎110包括用于訪問和存儲敏感信息的一個或多個安全服務器，敏感信息可以是任何類型或形式的數(shù)據(jù)，例如是但不限于文本、音頻、視頻、用戶認證數(shù)據(jù)以及公共和私有密碼密鑰。根據(jù)一個實施例，認證數(shù)據(jù)包括被設計為唯一識別密碼系統(tǒng)100的用戶的數(shù)據(jù)。例如，認證數(shù)據(jù)可以包括用戶識別號、一個或多個生物測定、以及由信任引擎110或用戶產生但是在登記時由用戶初始回答的一系列提問和回答。上述提問可以包括人口數(shù)據(jù)(例如，出生地、地址、周年紀念等)、個人數(shù)據(jù)(例如，母親未婚時的名字、喜歡的冰激凌等)、或被設計為唯一識別用戶的其它數(shù)據(jù)。信任引擎110將與當前事務關聯(lián)的用戶的認證數(shù)據(jù)與先前(例如在登記時)設置的認證數(shù)據(jù)進行比較。信任引擎110可以有利地要求用戶在每次事務時生成認證數(shù)據(jù)，或者信任引擎110可以有利地允許用戶定期地(例如，在一串事務的開始時或者在登錄到特定賣方網站時)生成認證數(shù)據(jù)。
根據(jù)用戶生成生物測定數(shù)據(jù)的實施例，用戶向生物測定裝置107提供身體特征，例如但不限于面部掃描、手掃描、耳掃描、虹膜掃描、視網膜掃描、血管模式、DNA、指紋、筆跡或語音。生物測定裝置有利地生成身體特征的電子模式或生物測定。為了登記或認證，電子模式通過用戶系統(tǒng)105傳送至信任引擎110。
—旦用戶生成了適當?shù)恼J證數(shù)據(jù)并且信任引擎110確定該認證數(shù)據(jù)(當前認證數(shù)據(jù))與在登記時設置的認證數(shù)據(jù)(登記認證數(shù)據(jù))之間的明確匹配，信任引擎110向用戶提供完整的密碼功能。例如，正確認證的用戶可以有利地采用信任引擎110執(zhí)行哈希處理、數(shù)字簽名、加密和解密(?？偡Q為加密)、建立或分布數(shù)字證書等等。然而，密碼功能中使用的私有密碼密鑰在信任引擎110之外將不可用，從而確保了密碼密鑰的完整性。
根據(jù)一個實施例，信任引擎110產生并存儲密碼密鑰。根據(jù)另一個實施例，至少一個密碼密鑰與每個用戶關聯(lián)。此外，當密碼密鑰包括公鑰技術時，在信任引擎110內產生但不從其發(fā)放與用戶關聯(lián)的每個私鑰。因此，只要用戶可以訪問信任引擎110，用戶就可以使用他或她的私鑰或公鑰執(zhí)行密碼功能。有利的是，這種遠程訪問使用戶可以通過實際任何互聯(lián)網連接(例如，蜂窩和衛(wèi)星電話、信息亭、膝上型電腦、賓館房間等)保持完全移動并訪問密碼功能。
根據(jù)另一個實施例，信任引擎110使用針對信任引擎110產生的密鑰對，執(zhí)行密碼功能。根據(jù)這個實施例，信任引擎110首先對用戶進行認證，并且在用戶正確地生成與登記認證數(shù)據(jù)匹配的認證數(shù)據(jù)后，信任引擎110使用它自身的密碼密鑰對，代表認證的用戶執(zhí)行密碼功能。
熟練技術人員將從這里的公開認識到，密碼密鑰可以有利地包括對稱密鑰、公鑰和私鑰的全部或一些。此外，熟練技術人員將從這里的公開認識到，可以采用可從商業(yè)技術獲得的大量的算法(例如，RSA, ELGAMAL等)來實現(xiàn)上述密鑰。
圖1還示出了認證機構115。根據(jù)一個實施例，認證機構115可有利地包括發(fā)放數(shù)字證書的信任第三方組織或公司，例如VeriSign、Baltimore、Entrust等。信任引擎110可有利地通過一個或多個傳統(tǒng)的數(shù)字證書協(xié)議(例如，PKCS10)向認證機構115發(fā)送對數(shù)字證書的請求。作為響應，認證機構115將發(fā)放多個不同協(xié)議中的一個或多個(例如，PKCS7)的數(shù)字證書。根據(jù)本發(fā)明的一個實施例，信任引擎110從幾個或所有的主要認證機構115請求數(shù)字證書，從而使得信任引擎110可訪問與任何請求方的證書標準對應的數(shù)字證書。根據(jù)另一個實施例，信任引擎110在內部執(zhí)行證書發(fā)放。在這個實施例中，當證書被請求時(例如，在密鑰產生時)或者在請求時請求的證書標準中，信任引擎110可以訪問用于產生證書的證書系統(tǒng)和/或可以在內部產生證書。在下文中將更加詳細地公開信任引擎110。圖1還示出了賣方系統(tǒng)120。根據(jù)一個實施例，賣方系統(tǒng)120有利地包括Web服務器。典型的Web服務器通常使用幾個互聯(lián)網標記語言或文檔格式標準(例如，超文本標記語言(HTML)或可擴展標記語言(XML))之一在互聯(lián)網上提供內容。Web服務器從如Netscape和Internet Explorer的瀏覽器接受請求,然后返回適當?shù)碾娮游臋n。多個服務器或客戶端技術能夠用于提高Web服務器的能力以超越它的傳遞標準電子文檔的能力。例如，這些技術包括公共網關接口(CGI)腳本、SSL安全性和動態(tài)服務器頁面(ASP)。賣方系統(tǒng)120可有利地提供與商業(yè)、個人、教育或其它事務有關的電子內容。盡管參照上述實施例公開了賣方系統(tǒng)120，但是本發(fā)明不限于此。相反，熟練技術人員將從這里的公開認識到，賣方系統(tǒng)120可有利地包括參照用戶系統(tǒng)105描述的裝置中的任何一個或者它們的組合。圖1還示出了連接用戶系統(tǒng)105、信任引擎110、認證機構115和賣方系統(tǒng)120的通信鏈路125。根據(jù)一個實施例，通信鏈路125優(yōu)選包括互聯(lián)網。本文所用的互聯(lián)網是計算機的全球網絡。本領域普通技術人員公知的互聯(lián)網的結構包括網絡骨干和從骨干分支的網絡。這些分支繼而具有從它們分支的網絡，如此類推。路由器在網絡級之間移動信息包，然后從網絡到網絡移動信息包，直到包到達它的目的地附近。目的地網絡的主機將信息包從該目的地導向適當?shù)慕K端或節(jié)點。在一個有利的實施例中，互聯(lián)網路由集線器包括使用現(xiàn)有技術公知的傳輸控制協(xié)議/互聯(lián)網協(xié)議(TCP/IP)的域名系統(tǒng)(DNS)服務器。路由集線器經由高速通信鏈路連接到一個或多個其它路由集線器?；ヂ?lián)網的一個流行部分是萬維網。萬維網包含不同的計算機，這些計算機存儲能夠顯示圖形和文本信息的文檔。在萬維網上提供信息的計算機通常稱作“網站”。網站由具有關聯(lián)的電子頁面的互聯(lián)網地址定義。電子頁面能夠通過統(tǒng)一資源定位符(URL)進行識另O。通常，電子頁面是組織文本、圖形圖像、音頻、視頻等的呈現(xiàn)的文檔。盡管在針對其優(yōu)選實施例公開了通信鏈路125，但是本領域普通技術人員將從這里的公開認識到，通信鏈路125可以包括各種交互通信鏈路。例如，通信鏈路125可以包括交互電視網絡、電話網絡、無線數(shù)據(jù)傳輸系統(tǒng)、雙向線纜系統(tǒng)、定制的私有或公共計算機網絡、交互亭網絡、自動柜員機網絡、直接鏈路、衛(wèi)星或蜂窩網絡等。圖2示出了根據(jù)本發(fā)明的實施例的各方面的圖1的信任引擎110的框圖。如圖2所示，信任引擎110包括事務引擎205、儲存器210、認證引擎215和密碼引擎220。根據(jù)本發(fā)明的一個實施例，信任引擎110還包括海量存儲器225。進一步如圖2所示，事務引擎205與儲存器210、認證引擎215和密碼引擎220以及海量存儲器225進行通信。此外，儲存器210與認證引擎215、密碼引擎220和海量存儲器225進行通信。此外，認證引擎215與密碼引擎220進行通信。根據(jù)本發(fā)明的一個實施例，上述通信中的一些或全部可有利地包括將XML文檔發(fā)送至與接收裝置對應的IP地址。如上所述，有利的是，XML文檔使設計者可以建立他們自己定制的文檔標記，從而實現(xiàn)應用之間以及組織之間的數(shù)據(jù)的定義、傳輸、驗證和解釋。此外，上述通信中的一些或全部可包括傳統(tǒng)的SSL技術。根據(jù)一個實施例,事務引擎205包括例如可從Netscape、Microsoft、Apache等獲得的傳統(tǒng)Web服務器的數(shù)據(jù)路由裝置。例如，Web服務器可以有利地從通信鏈路125接收輸入數(shù)據(jù)。根據(jù)本發(fā)明的一個實施例，輸入數(shù)據(jù)被尋址至信任引擎110的前端安全系統(tǒng)。例如，前端安全系統(tǒng)可以有利地包括防火墻、搜索已知攻擊概況的入侵檢測系統(tǒng)、和/或病毒掃描器。在通過了前端安全系統(tǒng)后，數(shù)據(jù)由事務引擎205接收并且被路由至儲存器210、認證引擎215、密碼引擎220和海量存儲器225之一。此外，事務引擎205監(jiān)視來自認證引擎215和密碼引擎220的輸入數(shù)據(jù)，并且通過通信鏈路125將該數(shù)據(jù)路由至特定系統(tǒng)。例如，事務引擎205可有利地向用戶系統(tǒng)105、認證機構115或賣方系統(tǒng)120路由該數(shù)據(jù)。根據(jù)一個實施例，使用傳統(tǒng)的HTTP路由技術，例如采用URL或統(tǒng)一資源指示符(URI)來路由數(shù)據(jù)。URI與URL類似，然而，URI通常指示文件或動作(例如，可執(zhí)行文件、腳本等)的源。因此，根據(jù)一個實施例，用戶系統(tǒng)105、認證機構115、賣方系統(tǒng)120和信任引擎210的部件有利地包括通信URL或URI內的充足數(shù)據(jù)，以供事務引擎205在整個密碼系統(tǒng)內正確地路由數(shù)據(jù)。盡管參照其優(yōu)選實施例公開了數(shù)據(jù)路由，但是熟練技術人員將認識到大量的可能的數(shù)據(jù)路由方案或策略。例如，XML或其它數(shù)據(jù)包可以有利地進行拆包并且通過它們的格式、內容等進行識別，從而使得事務引擎205可以在整個信任引擎110內正確地路由數(shù)據(jù)。此外，熟練技術人員將認識到，有利的是，例如當通信鏈路125包括局域網時，數(shù)據(jù)路由可進行改動以適應符合特定網絡系統(tǒng)的數(shù)據(jù)傳輸協(xié)議。根據(jù)本發(fā)明的另一個實施例，事務引擎205包括傳統(tǒng)的SSL加密技術，從而在特定通信期間，通過事務引擎205，上述系統(tǒng)可以對它們自身進行認證，反之亦然。本發(fā)明中使用的術語“1/2SSL”是指服務器(但客戶機不必)進行SSL認證的通信，術語“全SSL”是指客戶機和服務器均進行SSL認證的通信。當本公開使用術語“SSL”時，通信可以包括1/2SSL或全SSL。由于事務引擎205將數(shù)據(jù)路由至密碼系統(tǒng)100的各個部件，所以事務引擎205可有利地建立審計索引(audit trail)。根據(jù)一個實施例，審計索引包括在整個密碼系統(tǒng)100內由事務引擎205進行路由的數(shù)據(jù)的至少類型和格式的記錄。這種審計數(shù)據(jù)可有利地存儲在海量存儲器225中。圖2還示出了儲存器210。根據(jù)一個實施例，儲存器210包括一個或多個數(shù)據(jù)存儲設施，例如目錄服務器、數(shù)據(jù)庫服務器等。如圖2所示，儲存器210存儲密碼密鑰和登記認證數(shù)據(jù)。密碼密鑰可有利地對應于信任引擎110或者密碼系統(tǒng)100的用戶(例如，用戶或賣方)。登記認證數(shù)據(jù)可有利地包括被設計用于唯一識別用戶的數(shù)據(jù)，例如用戶ID、口令、提問的回答、生物測定數(shù)據(jù)等。有利的是，可以在用戶登記時或者在另一個替代的以后時間獲取這個登記認證數(shù)據(jù)。例如，信任引擎110可以包括登記認證數(shù)據(jù)的周期性或其它的更新或重新發(fā)放。根據(jù)一個實施例，從事務引擎205到認證引擎215和密碼引擎220的通信以及從認證引擎215和密碼引擎220到事務引擎205的通信包括安全通信(例如，傳統(tǒng)的SSL技術)。此外，如上所述，可以使用URL、UR1、HTTP或XML文檔傳送到達和來自儲存器210的通信的數(shù)據(jù)，有利地在上述任何一個內部嵌入了數(shù)據(jù)請求和格式。
如上所述，儲存器210可有利地包括多個安全數(shù)據(jù)存儲設施。在這種實施例中，安全數(shù)據(jù)存儲設施可被構造為使得對一個個體數(shù)據(jù)存儲設施的安全性的危害將不會危害存儲在其中的密碼密鑰或認證數(shù)據(jù)。例如，根據(jù)這個實施例，密碼密鑰和認證數(shù)據(jù)被進行數(shù)學運算，從而在統(tǒng)計學上充分地對存儲在每個數(shù)據(jù)存儲設施中的數(shù)據(jù)進行隨機化。根據(jù)一個實施例，個體數(shù)據(jù)存儲設施的數(shù)據(jù)的隨機化使得該數(shù)據(jù)無法被破譯。因此，對個體數(shù)據(jù)存儲設施的危害僅僅生成隨機化的無法譯解的數(shù)字，并且不會危害作為整體的任何密碼密鑰或認證數(shù)據(jù)的安全性。
圖2還示出了包括認證引擎215的信任引擎110。根據(jù)一個實施例，認證引擎215包括數(shù)據(jù)比較器，該數(shù)據(jù)比較器被構造為將來自事務引擎205的數(shù)據(jù)與來自儲存器210的數(shù)據(jù)進行比較。例如，在認證過程中，用戶將當前認證數(shù)據(jù)提供給信任引擎110從而事務引擎205接收當前認證數(shù)據(jù)。如上所述，事務引擎205識別優(yōu)選在URL或URI中的數(shù)據(jù)請求，并且將認證數(shù)據(jù)路由至認證引擎215。此外，當被請求時，儲存器210將與用戶對應的登記認證數(shù)據(jù)轉發(fā)至認證引擎215。因此，認證引擎215具有當前認證數(shù)據(jù)和登記認證數(shù)據(jù)以進行比較。
根據(jù)一個實施例，到達認證引擎的通信包括安全通信(例如，SSL技術)。此外，安全性(例如，使用公鑰技術的超級加密)可以設置在信任引擎110部件內。例如，根據(jù)一個實施例，用戶用認證引擎215的公鑰對當前認證數(shù)據(jù)進行加密。此外，儲存器210還用認證引擎215的公鑰對登記認證數(shù)據(jù)進行加密。這樣，僅有認證引擎的私鑰能夠用于對傳輸進行解密。
如圖2所示，信任引擎110還包括密碼引擎220。根據(jù)一個實施例，密碼引擎包括密碼處理模塊，該模塊被構造為有利地提供傳統(tǒng)的密碼功能(例如，公鑰基礎設施(PKI)功能)。例如，密碼引擎220可以有利地向密碼系統(tǒng)100的用戶發(fā)放公鑰和私鑰。以這種方式，在密碼引擎220處產生密碼密鑰并且將其轉發(fā)至儲存器210，從而在信任引擎110之外至少無法獲得私有密碼密鑰。根據(jù)另一個實施例，密碼引擎220至少對私有密碼密鑰數(shù)據(jù)進行隨機化和分裂，從而僅僅存儲隨機化的分裂數(shù)據(jù)。與登記認證數(shù)據(jù)的分裂類似，分裂過程確保在密碼引擎220之外無法獲得存儲的密鑰。根據(jù)另一個實施例，密碼引擎的功能可以與認證引擎215組合并且由認證引擎215執(zhí)行。
根據(jù)一個實施例，到達和來自密碼引擎的通信包括安全通信，諸如SSL技術。此夕卜，可有利地采用XML文檔以傳送數(shù)據(jù)和/或進行密碼功能請求。
圖2還示出了具有海量存儲225的信任引擎110。如上所述，事務引擎205保持與審計索引對應的數(shù)據(jù)并且將這個數(shù)據(jù)存儲在海量存儲器225中。類似地，根據(jù)本發(fā)明的一個實施例，儲存器210保持與審計索引對應的數(shù)據(jù)并且將這個數(shù)據(jù)存儲在海量存儲裝置225中。由于審計索引數(shù)據(jù)包括由儲存器210接收到的請求的記錄及其響應，所以儲存器審計索引數(shù)據(jù)與事務引擎205的審計索引數(shù)據(jù)類似。此外，海量存儲器225可用于存儲在內部包含了用戶的公鑰的數(shù)字證書。
盡管參照其優(yōu)選實施例和替代實施例公開了信任引擎110，但是本發(fā)明不限于此。相反，熟練技術人員將從這里的公開中認識到信任引擎110的大量替代。例如，信任引擎110可有利地僅僅執(zhí)行認證，或者僅僅執(zhí)行例如數(shù)據(jù)加密和解密的一些或所有的密碼功能。根據(jù)這些實施例，可有利地去除認證引擎215和密碼引擎220之一，從而為信任引擎110建立更加簡單的設計。此外，密碼引擎220還可以與認證機構進行通信從而在信任引擎110內實現(xiàn)認證機構。根據(jù)另一個實施例，信任引擎110可以有利地執(zhí)行認證以及例如數(shù)字簽名的一個或多個密碼功能。圖3示出了根據(jù)本發(fā)明的實施例的各方面的圖2的事務引擎205的框圖。根據(jù)這個實施例，事務引擎205包括具有處理線程和偵聽線程的操作系統(tǒng)305。有利的是，操作系統(tǒng)305可與在例如可從Apache得到的Web服務器的傳統(tǒng)高容量服務器中發(fā)現(xiàn)的操作系統(tǒng)類似。偵聽線程針對輸入數(shù)據(jù)流，監(jiān)視來自通信鏈路125、認證引擎215和密碼引擎220之一的輸入通信。處理線程識別輸入數(shù)據(jù)流的特定數(shù)據(jù)結構(例如，上述數(shù)據(jù)結構)，從而將輸入數(shù)據(jù)路由至通信鏈路125、儲存器210、認證引擎215、密碼引擎220或海量存儲器225之一。如圖3所示，有利的是，通過例如SSL技術可以保護輸入和輸出數(shù)據(jù)。圖4示出了根據(jù)本發(fā)明的實施例的各方面的圖2的儲存器210的框圖。根據(jù)這個實施例，儲存器210包括一個或多個輕量目錄訪問協(xié)議(LDAP)服務器?？梢詮母鞣N制造商(例如，Netscape、ISO等)獲得LDAP目錄服務器。圖4還示出了目錄服務器優(yōu)選存儲與密碼密鑰對應的數(shù)據(jù)405和與登記認證數(shù)據(jù)對應的數(shù)據(jù)410。根據(jù)一個實施例，儲存器210包括單個邏輯存儲結構，用于將認證數(shù)據(jù)和密碼密鑰數(shù)據(jù)索引至唯一用戶ID。該單個邏輯存儲結構優(yōu)選包括確保存儲在其中的數(shù)據(jù)的高度信任或安全性的機制。例如，儲存器210的物理位置可有利地包括大量的傳統(tǒng)安全性措施，諸如受限雇員訪問、現(xiàn)代監(jiān)視系統(tǒng)等。除了物理安全性以外或者替代物理安全性，計算機系統(tǒng)或服務器可以有利地包括保護存儲的數(shù)據(jù)的軟件方案。例如，儲存器210可有利地建立并存儲與采取的動作的審計索引對應的數(shù)據(jù)415。此外，有利的是，可以用與傳統(tǒng)的SSL技術結合的公鑰加密，對輸入和輸出通信進行加密。根據(jù)另一個實施例，儲存器210可以包括不同的且物理分離的數(shù)據(jù)存儲設施，如進一步參照圖7所公開的。圖5示出了根據(jù)本發(fā)明的實施例的各方面的圖2的認證引擎215的框圖。與圖3的事務引擎205類似，認證引擎215包括操作系統(tǒng)505，操作系統(tǒng)505至少具有傳統(tǒng)的Web服務器(例如，可從Apache獲得的Web服務器)的變型版本的偵聽和處理線程。如圖5所示，認證引擎215包括對至少一個私鑰510的訪問。有利的是，私鑰510可用于例如對來自事務引擎205或儲存器210的數(shù)據(jù)進行解密，該數(shù)據(jù)用認證引擎215的對應公鑰進行了加
LU O圖5還示出了包括比較器515、數(shù)據(jù)分裂模塊520和數(shù)據(jù)組裝模塊525的認證引擎215。根據(jù)本發(fā)明的優(yōu)選實施例，比較器515包括能夠比較與上述生物測定認證數(shù)據(jù)有關的潛在復雜模式的技術。該技術可以包括用于模式比較(例如，表示指紋模式或語音模式的模式比較)的硬件、軟件或者組合方案。此外，根據(jù)一個實施例，認證引擎215的比較器515可有利地比較文檔的傳統(tǒng)哈希值以呈現(xiàn)比較結果。根據(jù)本發(fā)明的一個實施例，比較器515包括對該比較應用啟發(fā)法(heuristics) 530。有利的是，啟發(fā)法530可以應對圍繞認證嘗試的境況(例如，時間、IP地址或子網掩碼、購買概況、電子郵件地址、處理器序列號或ID等)。此外，生物測定數(shù)據(jù)比較的性質會導致從當前生物測定認證數(shù)據(jù)與登記數(shù)據(jù)的匹配產生變化的置信度。例如，與可僅僅返回肯定或否定匹配的傳統(tǒng)口令不同，指紋可被確定為部分匹配，例如90%匹配、75%匹配或10%匹配，而非簡單地為正確或不正確。諸如聲紋(voice print)分析或面部識別的其它生物測定識別法會共有這個概率認證的屬性，而非絕對認證。
當利用這種概率認證進行工作時或者在認為認證低于絕對可靠的其它情況下，期望應用啟發(fā)法530以確定設置的認證的置信水平是否高到足夠對正在進行的事務進行認證。
有時候存在如下情況:談及的事務是相對低值事務，其中，它可以較低的置信水平被接受而得到認證。這可以包括具有與之關聯(lián)的低貨幣值(例如，$10購買)的事務或者低風險的事務(例如，進入會員制網站)。
相反，為了對其它事務進行認證，會期望在允許事務進行之前要求高的認證置信度。這些事務可以包括大貨幣值的事務(例如，簽署幾百萬美元供貨合同)或者在發(fā)生不正確認證的情況下具有高風險的事務(例如，遠程登錄政府計算機)。
如下文所述，與置信水平和事務值組合的啟發(fā)法530的使用可用于允許比較器提供動態(tài)的上下文敏感認證系統(tǒng)。
根據(jù)本發(fā)明的另一個實施例，比較器515可有利地跟蹤特定事務的認證嘗試。例如，當事務失敗時，信任引擎110可以請求用戶重新輸入他或她的當前認證數(shù)據(jù)。認證引擎215的比較器515可有利地利用嘗試限制器535以限制認證嘗試的次數(shù)，由此禁止假扮用戶的認證數(shù)據(jù)的暴力嘗試。根據(jù)一個實施例，嘗試限制器535包括監(jiān)視事務的重復認證嘗試并且例如將給定事務的認證嘗試限制為三次的軟件模塊。因此，嘗試限制器535例如將用于假扮個人的認證數(shù)據(jù)的自動嘗試限制為僅三次“猜測”。當三次失敗時，嘗試限制器535可有利地拒絕另外的認證嘗試。有利的是，例如通過不管正在發(fā)送的當前認證數(shù)據(jù)如何比較器515都返回否定結果，而實現(xiàn)這種拒絕。另一方面，事務引擎205可有利地阻止屬于三次嘗試先前已經失敗的事務的任何另外的認證嘗試。
認證引擎215還包括數(shù)據(jù)分裂模塊520和數(shù)據(jù)組裝模塊525。數(shù)據(jù)分裂模塊520有利地包括具有對各種數(shù)據(jù)進行數(shù)學運算從而充分地將數(shù)據(jù)隨機化并分裂成多個部分的能力的軟件、硬件、或組合模塊。根據(jù)一個實施例，不可以從個體部分重建原始數(shù)據(jù)。數(shù)據(jù)組裝模塊525有利地包括被構造為對上述充分隨機化的部分進行數(shù)學運算從而使它們的組合提供原始譯解數(shù)據(jù)的軟件、硬件或組合模塊。根據(jù)一個實施例，認證引擎215利用數(shù)據(jù)分裂模塊520將登記認證數(shù)據(jù)隨機化并分裂成多個部分，并且利用數(shù)據(jù)組裝模塊525將這些部分重新組裝成可用的登記認證數(shù)據(jù)。
圖6示出了根據(jù)本發(fā)明的一個實施例的各方面的圖2的信任引擎200的密碼引擎220的框圖。與圖3的事務引擎205類似，密碼引擎220包括操作系統(tǒng)605，操作系統(tǒng)605至少具有傳統(tǒng)的Web服務器(例如，可從Apache得到的Web服務器)的變型版本的偵聽和處理線程。如圖6所示，密碼引擎220包括功能與圖5中類似的數(shù)據(jù)分裂模塊610和數(shù)據(jù)組裝模塊620。然而，根據(jù)一個實施例，與上述的登記認證數(shù)據(jù)不同，數(shù)據(jù)分裂模塊610和數(shù)據(jù)組裝模塊620處理密碼密鑰數(shù)據(jù)。但是，熟練技術人員將從這里的公開認識到，數(shù)據(jù)分裂模塊910和數(shù)據(jù)分裂模塊620可以與認證引擎215的相應模塊進行組合。
密碼引擎220還包括密碼處理模塊625，密碼處理模塊625被構造為執(zhí)行大量的密碼功能中的一個、一些或全部。根據(jù)一個實施例，密碼處理模塊625可以包括軟件模塊或程序、硬件或二者。根據(jù)另一個實施例，密碼處理模塊625可以執(zhí)行數(shù)據(jù)比較、數(shù)據(jù)解析、數(shù)據(jù)分裂、數(shù)據(jù)分離、數(shù)據(jù)哈希法、數(shù)據(jù)加密或解密、數(shù)字簽名驗證或創(chuàng)建、數(shù)字證書產生、存儲、或請求、密碼密鑰產生等等。此外，熟練技術人員將從這里的公開認識到，密碼處理模塊825可有利地包括公鑰基礎設施，諸如良好隱私(PGP)、基于RSA的公鑰系統(tǒng)、或者大量的替代密鑰管理系統(tǒng)。此外，密碼處理模塊625可以執(zhí)行公鑰加密、對稱密鑰加密或二者。除了上述以外，密碼處理模塊625可以包括用于執(zhí)行無縫、透明的互用性功能的一個或多個計算機程序或模塊、硬件或二者。熟練技術人員還將從這里的公開認識到，密碼功能可以包括一般與密碼密鑰管理系統(tǒng)有關的大量或多樣的功能。圖7示出了根據(jù)本發(fā)明的實施例的各方面的儲存器系統(tǒng)700的簡化框圖。如圖7所示，儲存器系統(tǒng)700有利地包括多個數(shù)據(jù)存儲設施，例如，數(shù)據(jù)存儲設施D1、D2、D3和D4。然而，本領域普通技術人員容易理解，儲存器系統(tǒng)可以僅僅具有一個數(shù)據(jù)存儲設施。根據(jù)本發(fā)明的一個實施例，數(shù)據(jù)存儲設施Dl到D4中的每個可以有利地包括參照圖4的儲存器210公開的一些或全部部件。與儲存器210類似，數(shù)據(jù)存儲設施Dl到D4優(yōu)選通過傳統(tǒng)SSL與事務引擎205、認證引擎215和密碼引擎220進行通信。通信鏈路例如傳送XML文檔。來自事務引擎205的通信可有利地包括對數(shù)據(jù)的請求，其中，該請求被有利地廣播至每個數(shù)據(jù)存儲設施Dl到D4的IP地址。另一方面，事務引擎205可以基于大量的標準(例如，響應時間、服務器負載、維護時間表等)，向特定數(shù)據(jù)存儲設施廣播請求。響應于來自事務引擎205的對數(shù)據(jù)的請求，儲存器系統(tǒng)700有利地將存儲的數(shù)據(jù)轉發(fā)至認證引擎215和密碼引擎220。相應的數(shù)據(jù)組裝模塊接收轉發(fā)的數(shù)據(jù)并且將該數(shù)據(jù)組裝成可用格式。另一方面，從認證引擎215和密碼引擎220到數(shù)據(jù)存儲設施Dl到D4的通信可以包括要存儲的敏感數(shù)據(jù)的傳輸。例如，根據(jù)一個實施例，認證引擎215和密碼引擎220可有利地利用它們各自的數(shù)據(jù)分裂模塊，將敏感數(shù)據(jù)劃分成多個不可譯解的部分，然后將敏感數(shù)據(jù)的一個或多個不可譯解的部分發(fā)送至特定數(shù)據(jù)存儲設施。根據(jù)一個實施例，每個數(shù)據(jù)存儲設施Dl到D4包括分立且獨立的存儲系統(tǒng)(例如，目錄服務器)。根據(jù)本發(fā)明的另一個實施例，儲存器系統(tǒng)700包括多個在地理上分離的獨立數(shù)據(jù)存儲系統(tǒng)。通過將敏感數(shù)據(jù)分布到不同且獨立的存儲設施Dl到D4(存儲設施Dl到D4中的一些或全部可有利地在地理上分離)，儲存器系統(tǒng)700提供冗余連同附加的安全措施。例如，根據(jù)一個實施例，為了對敏感數(shù)據(jù)進行譯解和重新組裝，僅需要來自多個數(shù)據(jù)存儲設施Dl到D4中的兩個的數(shù)據(jù)。因此，四個數(shù)據(jù)存儲設施Dl到D4中的兩個可以由于維護、系統(tǒng)故障、電源故障等而不工作，這不會影響信任引擎110的功能。此外，根據(jù)一個實施例，由于存儲在每個數(shù)據(jù)存儲設施中的數(shù)據(jù)被隨機化并且不可譯解，所以對任何個體數(shù)據(jù)存儲設施的危害不會必然危害敏感數(shù)據(jù)。此外，在具有地理分離的數(shù)據(jù)存儲設施的實施例中，對多個地理遠離的設施的危害變得愈加困難。實際上，即使是無良雇員，想要破壞所需的多個獨立的地理遠離的數(shù)據(jù)存儲設施也是具有極大挑戰(zhàn)的。盡管參照其優(yōu)選和替代實施例公開了儲存器系統(tǒng)700，但是本發(fā)明并不限于此。相反，熟練技術人員將從這里的公開認識到儲存器系統(tǒng)700的大量的替代物。例如，儲存器系統(tǒng)700可以包括一個、兩個或更多個數(shù)據(jù)存儲設施。此外，可對敏感數(shù)據(jù)進行數(shù)學運算，從而使得為了對敏感數(shù)據(jù)進行重新組裝和譯解，需要來自兩個或更多的數(shù)據(jù)存儲設施的部分。
如上所述，認證引擎215和密碼引擎220分別包括數(shù)據(jù)分裂模塊520和610，用于分裂任何類型或形式的敏感數(shù)據(jù)(例如，文本、音頻、視頻、認證數(shù)據(jù)和密碼密鑰數(shù)據(jù))。圖8示出了根據(jù)本發(fā)明的實施例的各方面的數(shù)據(jù)分裂模塊執(zhí)行的數(shù)據(jù)分裂過程800的流程圖。如圖8所示，當認證引擎215或密碼引擎220的數(shù)據(jù)分裂模塊接收到敏感數(shù)據(jù)“S”時，數(shù)據(jù)分裂過程800在步驟805開始。優(yōu)選地，在步驟810，數(shù)據(jù)分裂模塊產生充分隨機數(shù)、值、或者比特串或集“A”。例如，可以以本領域普通技術人員可獲得的用于生成適用于密碼應用的高質量隨機數(shù)的大量的不同傳統(tǒng)技術，產生隨機數(shù)A。此外，根據(jù)一個實施例，隨機數(shù)A包括可為任何適當長度的比特長度，例如，短于、長于或等于敏感數(shù)據(jù)S的比特長度。
此外，在步驟820中，數(shù)據(jù)分裂過程800產生另一個統(tǒng)計隨機數(shù)“C”。根據(jù)優(yōu)選實施例，有利的是，可以并行完成統(tǒng)計隨機數(shù)A和C的產生。數(shù)據(jù)分裂模塊然后將數(shù)A和C與敏感數(shù)據(jù)S進行組合以產生新的數(shù)“B”和“D”。例如，數(shù)B可以包括A XOR S的二進制組合，數(shù)D可以包括C XOR S的二進制組合。XOR函數(shù)或“異或”函數(shù)對于本領域普通技術人員是公知的。優(yōu)選地，分別在步驟825和830中分別發(fā)生上述組合，并且根據(jù)一個實施例，上述組合也可以并行發(fā)生。數(shù)據(jù)分裂過程800然后進行到步驟835，在步驟835中，對隨機數(shù)A和C以及數(shù)B和D進行配對以使得這些配對均不包含通過它們自身可以重新組織并譯解原始敏感數(shù)據(jù)S的充分數(shù)據(jù)。例如，這些數(shù)可以如下配對:AC、AD、BC和BD。根據(jù)一個實施例，上述配對中的每個被分布至圖7的儲存器Dl到D4之一。根據(jù)另一個實施例，上述配對中的每個被隨機分布至儲存器Dl到D4之一。例如，在第一數(shù)據(jù)分裂過程800期間，配對AC可以例如通過D2的IP地址的隨機選擇而發(fā)送至儲存器D2。然后，在第二數(shù)據(jù)分裂過程800期間，配對AC可以例如通過D4的IP地址的隨機選擇而發(fā)送至儲存器D4。此外，這些配對可以全部存儲在一個儲存器上，并且可以存儲在所述儲存器的分離的位置上。
基于上面的描述，有利的是，數(shù)據(jù)分裂過程800將敏感數(shù)據(jù)的各部分安置在四個數(shù)據(jù)存儲設施Dl到D4的每個中，從而使得沒有單個數(shù)據(jù)存儲設施Dl到D4包括用于重建原始敏感數(shù)據(jù)S的充足的加密數(shù)據(jù)。如上所述,通過將數(shù)據(jù)隨機化成個體不可用的加密部分，提高了安全性并且即使數(shù)據(jù)存儲設施Dl到D4之一受到危害仍可以保持數(shù)據(jù)的信任。
盡管參照其優(yōu)選實施例公開了數(shù)據(jù)分裂過程800，但是本發(fā)明不限于此。相反，熟練技術人員將從這里的公開認識到數(shù)據(jù)分裂過程800的大量替代。例如，數(shù)據(jù)分裂過程可有利地將數(shù)據(jù)分裂成兩個數(shù)，例如，隨機數(shù)A和數(shù)B，并且通過兩個數(shù)據(jù)存儲設施隨機分布A和B。此外，通過產生附加的隨機數(shù)，數(shù)據(jù)分裂過程800可有利地在大量的數(shù)據(jù)存儲設施之間分裂數(shù)據(jù)。數(shù)據(jù)可被分裂成任何希望的、選擇的、預定的或者隨機指定的大小單元，包括但不限于一個比特、多個比特、字節(jié)、千字節(jié)、兆字節(jié)或更大、或者大小的任何組合或序列。此外，改變從分裂過程得到的數(shù)據(jù)單元的大小，可以使數(shù)據(jù)更加難于恢復成可用形式，由此提高了敏感數(shù)據(jù)的安全性。本領域普通技術人員易于理解，分裂數(shù)據(jù)單元大小可以是多種多樣的數(shù)據(jù)單元大小或大小的模式或者大小的組合。例如，數(shù)據(jù)單元大小可被選擇或預定為都具有相同大小、不同大小的固定集合、大小的組合，或者隨機產生大小。類似地，根據(jù)固定或預定的數(shù)據(jù)單元大小、數(shù)據(jù)單元大小的模式或組合、或者隨機產生的每份的數(shù)據(jù)單元大小，數(shù)據(jù)單元可被分布成一份或多份。
如上所述，為了重建敏感數(shù)據(jù)S，需要對數(shù)據(jù)部分進行去隨機化和重新組織。該過程可以有利地分別在認證引擎215和密碼引擎220的數(shù)據(jù)組裝模塊525和620中執(zhí)行。數(shù)據(jù)組裝模塊(例如，數(shù)據(jù)組裝模塊525)從數(shù)據(jù)存儲設施Dl到D4接收數(shù)據(jù)部分，并且將數(shù)據(jù)重新組裝成可用形式。例如，根據(jù)數(shù)據(jù)分裂模塊520采用圖8的數(shù)據(jù)分裂過程800的一個實施例，數(shù)據(jù)組裝模塊525使用來自數(shù)據(jù)存儲設施Dl到D4中的至少兩個的數(shù)據(jù)部分重建敏感數(shù)據(jù)S。例如，對AC、AD、BC和BD的配對被分布為任何兩個提供A和B或者C和D之一。要注意，S=AXOR B或者S=C XOR D指示當數(shù)據(jù)組裝模塊接收到A和B或者C和D之一時，數(shù)據(jù)組裝模塊525可有利地重新組裝敏感數(shù)據(jù)S。因此，當例如響應于信任引擎110的組裝請求，數(shù)據(jù)組裝模塊525從數(shù)據(jù)存儲設施Dl到D4中的至少前兩個接收到數(shù)據(jù)部分時，數(shù)據(jù)組裝部分525可以組裝敏感數(shù)據(jù)S?；谝陨蠑?shù)據(jù)分裂和組裝過程，可用格式的敏感數(shù)據(jù)S僅僅存在于信任引擎110的有限區(qū)域內。例如，當敏感數(shù)據(jù)S包括登記認證數(shù)據(jù)時，可用的非隨機化的登記認證數(shù)據(jù)僅在認證引擎215中可獲得。同樣地，當敏感數(shù)據(jù)S包括私有密碼密鑰數(shù)據(jù)時，可用的非隨機化的私有密碼密鑰數(shù)據(jù)僅在密碼引擎220中可獲得。盡管參照其優(yōu)選實施例公開了數(shù)據(jù)分裂和組裝過程，但是本發(fā)明不限于此。相反，熟練技術人員將從這里的公開認識到用于分裂和重新組裝敏感數(shù)據(jù)S的大量替代。例如，公鑰加密可用于進一步保護數(shù)據(jù)存儲設施Dl到D4中的數(shù)據(jù)。此外，本領域普通技術人員易于理解，本文所述的數(shù)據(jù)分裂模塊也是可納入、進行組合或以其它形式成為任何預先存在的計算機系統(tǒng)、軟件套裝、數(shù)據(jù)庫或其組合的一部分的本發(fā)明的獨立且不同的實施例，或者本發(fā)明的其它實施例，諸如這里公開和描述的信任引擎、認證引擎和事務引擎。圖9A示出了根據(jù)本發(fā)明的實施例的各方面的登記過程900的數(shù)據(jù)流。如圖9A所示，當用戶希望向密碼系統(tǒng)100的信任引擎110登記時，登記過程900在步驟905開始。根據(jù)這個實施例，用戶系統(tǒng)105有利地包括例如基于Java的詢問用戶輸入登記數(shù)據(jù)(例如，人口數(shù)據(jù)和登記認證數(shù)據(jù))的客戶機側Java小程序(applet)。根據(jù)一個實施例，登記認證數(shù)據(jù)包括用戶ID、口令、生物測定等等。根據(jù)一個實施例，在詢問過程中，客戶機側Java小程序優(yōu)選與信任引擎110進行通信以確保選擇的用戶ID是唯一的。當用戶ID不是唯一時，信任引擎110可有利地建議一個唯一用戶ID?？蛻魴C側Java小程序收集登記數(shù)據(jù)并且例如通過XML文檔將登記數(shù)據(jù)傳輸至信任引擎110，具體地講傳輸至事務引擎205。根據(jù)一個實施例，用認證引擎215的公鑰對該傳輸進行編碼。根據(jù)一個實施例，用戶在登記過程900的步驟905中執(zhí)行單次登記。例如，用戶將他或她自己作為特定人員(例如，Joe User)登記。當Joe User希望作為Joe User (Mega公司的CEO)進行登記時，根據(jù)這個實施例，Joe User登記第二次，接收第二唯一用戶ID并且信任引擎110不將這兩個身份進行關聯(lián)。根據(jù)本發(fā)明的另一個實施例，登記過程900為一個用戶ID提供多個用戶身份。因此，在以上例子中，信任引擎110將有利地將Joe User的兩個身份進行關聯(lián)。熟練技術人員從這里的公開應該明白，一個用戶可以具有許多身份，例如Joe User (戶主)、Joe User (慈善基金成員)等。即使用戶可以具有多個身份，根據(jù)這個實施例，信任引擎110優(yōu)選僅僅存儲一組登記數(shù)據(jù)。此外，有利的是，用戶可以在需要時添加、編輯/更新或刪除身份。盡管參照其優(yōu)選實施例公開了登記過程900，但是本發(fā)明不限于此。相反，熟練技術人員將從這里的公開認識到用于收集登記數(shù)據(jù)(具體地為登記認證數(shù)據(jù))的大量替代。例如，Java小程序可以是基于公共對象模型(COM)的Java小程序等。
另一方面，登記過程可包括分級登記。例如，在最低的登記等級，用戶可以經由通信鏈路125進行登記而不生成關于他或她的身份的文檔。根據(jù)提高的登記等級，用戶使用信任第三方(例如，數(shù)字公證人)進行登記。例如，用戶可以親自到信任第三方，生成證明(例如，出生證明、駕照、軍官證等)，并且信任第三方可有利地將例如它們的數(shù)字簽名包括在登記提交中。信任第三方可以包括真實公證人、政府機構(例如，郵局或機動車部門)、大公司中招募雇員的人力資源人員等。熟練技術人員從這里的公開應該明白，在登記過程900期間可以進行大量的不同等級的登記。
在接收到登記認證數(shù)據(jù)后，在步驟915，事務引擎205使用傳統(tǒng)的全SSL技術將登記認證數(shù)據(jù)轉發(fā)至認證引擎215。在步驟920中，認證引擎215使用認證引擎215的私鑰對登記認證數(shù)據(jù)進行解密。此外，認證引擎215利用數(shù)據(jù)分裂模塊對登記認證數(shù)據(jù)進行數(shù)學運算從而將該數(shù)據(jù)分裂成至少兩個獨立不可譯解的隨機數(shù)。如上所述，至少兩個數(shù)可以包括統(tǒng)計隨機數(shù)和二進制異或數(shù)。在步驟925中，認證引擎215將隨機數(shù)的每個部分轉發(fā)至數(shù)據(jù)存儲設施Dl到D4之一。如上所述，有利的是，認證引擎215還可以對哪些部分傳送到哪個儲存器進行隨機化。
在登記過程900中，用戶常常還希望發(fā)放數(shù)字證書使得他或她可以從密碼系統(tǒng)100之外的其它人接收加密的文檔。如上所述，認證機構115通常根據(jù)幾個傳統(tǒng)標準中的一個或多個發(fā)放數(shù)字證書。通常，數(shù)字證書包括每人皆知的用戶或系統(tǒng)的公鑰。
不管在登記時或者在另一個時間用戶是否請求了數(shù)字證書，該請求都通過信任引擎110傳送到認證引擎215。根據(jù)一個實施例，該請求包括例如具有用戶的正確名稱的XML文檔。根據(jù)步驟935，認證引擎215將該請求傳送給密碼引擎220以指示密碼引擎220產生密碼密鑰或密鑰對。
在被請求時，在步驟935，密碼引擎220產生至少一個密碼密鑰。根據(jù)一個實施例，密碼處理模塊625產生密鑰對，其中，一個密鑰用作私鑰，一個密鑰用作公鑰。密碼引擎220存儲私鑰，并且根據(jù)一個實施例存儲公鑰的副本。在步驟945中，密碼引擎220向事務引擎205發(fā)送對數(shù)字證書的請求。根據(jù)一個實施例，該請求有利地包括例如嵌入在XML文檔內的諸如PKCSlO的標準化請求。對數(shù)字證書的請求可有利地對應于一個或多個認證機構以及這些認證機構要求的一個或多個標準格式。
在步驟950中，事務引擎205將這個請求轉發(fā)至認證機構115,在步驟955中，認證機構115返回數(shù)字證書。有利的是，返回數(shù)字證書可以是例如PKCS7的標準化格式或者是一個或多個認證機構115的專有格式。在步驟960中，數(shù)字證書由事務引擎205接收，副本被轉發(fā)至用戶并且副本由信任引擎110存儲。信任引擎110存儲證書的副本從而使得信任引擎110將不需要依賴于認證機構115的可用性。例如，當用戶希望發(fā)送數(shù)字證書或者第三方請求用戶的數(shù)字證書時，對數(shù)字證書的請求通常被發(fā)送至認證機構115。然而，如果認證機構115正在進行維護或者成為故障或安全危害的犧牲品，則無法獲得數(shù)字證書。
在發(fā)放密碼密鑰后的任何時間，密碼引擎220可有利地利用上述的數(shù)據(jù)分裂過程800從而使得密碼密鑰被分裂成獨立不可譯解的隨機數(shù)。與認證數(shù)據(jù)類似，在步驟965中，密碼引擎220將隨機數(shù)傳送給數(shù)據(jù)存儲設施Dl到D4。
熟練技術人員將從這里的公開認識到，用戶可以在登記后的任何時間請求數(shù)字證書。此外，系統(tǒng)之間的通信可有利地包括全SSL或公鑰加密技術。此外，登記過程可以發(fā)放來自多個認證機構(包括信任引擎110內部或外部的一個或多個專有認證機構)的多個數(shù)字證書。如在步驟935到步驟960中所公開的，本發(fā)明的一個實施例包括對最終存儲在信任引擎110上的證書的請求。根據(jù)一個實施例，由于密碼處理模塊625發(fā)放由信任引擎110使用的密鑰，所以每個證書對應于一個私鑰。因此，信任引擎110通過監(jiān)視用戶擁有的或與用戶關聯(lián)的證書，可以有利地提供互用性。例如，當密碼引擎220接收對密碼功能的請求時，密碼處理模塊625可以調查請求用戶擁有的證書以確定該用戶是否擁有與該請求的屬性匹配的私鑰。當存在這種證書時，密碼處理模塊625可以使用該證書或者與之關聯(lián)的公鑰或私鑰執(zhí)行被請求的功能。當不存在這種證書時，密碼處理模塊625可以有利并透明地執(zhí)行多個動作以嘗試補救適當密鑰的缺失。圖9B示出了互用性過程970的流程圖，根據(jù)本發(fā)明的實施例的各方面，它公開了上述步驟以確保密碼處理模塊625使用適當密鑰執(zhí)行密碼功能。如圖9B所示，互用性過程970在步驟972開始，在步驟972中，密碼處理模塊925確定希望的證書的類型。根據(jù)本發(fā)明的一個實施例，有利的是，在對密碼功能的請求或者由請求者提供的其它數(shù)據(jù)中指定證書的類型。根據(jù)另一個實施例，證書類型可以通過該請求的數(shù)據(jù)格式進行確定。例如，密碼處理模塊925可以有利地識別與特定類型對應的請求。根據(jù)一個實施例，證書類型可以包括一個或多個算法標準，例如，RSA、ELGAMAL等。此外，證書類型可以包括一個或多個密鑰類型，例如，對稱密鑰、公鑰、例如256比特密鑰的強加密密鑰、較不安全的密鑰等。此外，證書類型可以包括一個或多個上述算法標準或密鑰、一個或多個消息或數(shù)據(jù)格式、一個或多個數(shù)據(jù)封裝或編碼方案(例如，Base 32或Base64)的升級或替換。證書類型還可以包括與一個或多個第三方密碼應用或接口、一個或多個通信協(xié)議或者一個或多個證書標準或協(xié)議的兼容性。熟練技術人員將從這里的公開認識至IJ，在證書類型中可存在其它差別，并且可以如本文公開地執(zhí)行從或到這些差別的翻譯。一旦密碼處理模塊625確定了證書類型，互用性過程970進行到步驟974，并且在步驟974中確定用戶是否擁有與確定的類型匹配的證書。當用戶擁有匹配的證書時，例如，信任引擎110通過例如其先前存儲可訪問該匹配的證書，加密處理模塊825知道匹配的私鑰也存儲在信任引擎110內。例如，匹配的私鑰可存儲在儲存器210或儲存器系統(tǒng)700內。有利的是，密碼處理模塊625可以請求從例如儲存器210組裝匹配的私鑰，然后在步驟976中，使用該匹配的私鑰執(zhí)行密碼操作或功能。例如，如上所述，密碼處理模塊625可以有利地執(zhí)行哈希法、哈希比較、數(shù)據(jù)加密或解密、數(shù)字簽名驗證或建立等。當用戶不擁有匹配的證書時，互用性過程970進行到步驟978，在步驟978，密碼處理模塊625確定用戶是否擁有交叉認證的證書。根據(jù)一個實施例，當?shù)谝徽J證機構確定信任來自第二認證機構的證書時，出現(xiàn)認證機構之間的交叉認證。換言之，第一認證機構確定來自第二認證機構的證書滿足特定質量標準，由此可被“認證”為與第一認證機構自身的證書等效。當認證機構例如發(fā)放具有信任等級的證書時，交叉認證變得更加復雜。例如，第一認證機構通?；诘怯涍^程的可靠度可以向特定證書提供三個等級的信任，而第二認證機構可以提供七個等級的信任。有利的是，交叉認證可以跟蹤來自第二認證機構的哪些等級和哪些證書可替代來自第一認證機構的哪些等級和哪些證書。當在兩個認證機構之間正式公開地完成上述交叉認證時，證書和等級的彼此映射通常稱作“鏈鎖(chaining)”。
根據(jù)本發(fā)明的另一個實施例，有利的是，密碼處理模塊625可以開發(fā)由認證機構達成一致的交叉認證之外的交叉認證。例如，密碼處理模塊625可以訪問第一認證機構的證書操作聲明(CPS)或者其它公布的政策聲明，并且例如使用特定信任等級要求的認證令牌(token )，將第一認證機構的證書與另一個認證機構的證書進行匹配。
當在步驟978中密碼處理模塊625確定用戶擁有交叉認證的證書時，互用性過程970進行到步驟976，并且使用交叉認證的公鑰、私鑰或二者執(zhí)行密碼操作或功能。另選地，當密碼處理模塊625確定用戶不擁有交叉認證的證書時，互用性過程970進行到步驟980，在步驟980，密碼處理模塊625選擇向其發(fā)放被請求的證書類型或者交叉認證的證書的認證機構。在步驟982中，密碼處理模塊625確定上面討論的用戶登記認證數(shù)據(jù)是否滿足選擇的認證機構的認證要求。例如，如果用戶例如通過回答人口和其它提問經由網絡登入，則與提供生物測定數(shù)據(jù)并且出現(xiàn)在第三方(例如，公證人)前的用戶相比，提供的認證數(shù)據(jù)可以建立較低等級的信任。根據(jù)一個實施例，有利的是，可以在選擇的認證機構的CPS中提供上述認證要求。
當用戶已經向信任引擎110提供滿足選擇的認證機構的要求的登記認證數(shù)據(jù)時，互用性過程970進行到步驟984，在步驟984，密碼處理模塊825從選擇的認證機構獲取證書。根據(jù)一個實施例，密碼處理模塊625通過登記過程900的下面的步驟945到960獲取證書。例如，密碼處理模塊625可有利地利用密碼引擎220已經可獲得的一個或多個密鑰對中的一個或多個公鑰，從認證機構請求證書。根據(jù)另一個實施例，密碼處理模塊625可有利地產生一個或多個新密鑰對，并且使用與之對應的公鑰從認證機構請求證書。
根據(jù)另一個實施例，信任引擎110可有利地包括能夠發(fā)放一個或多個證書類型的一個或多個證書發(fā)放模塊。根據(jù)這個實施例，證書發(fā)放模塊可以提供上述證書。當密碼處理模塊625獲取證書時，互用性過程970進行到步驟976，并且使用與獲取的證書對應的公鑰、私鑰或二者執(zhí)行密碼操作或功能。
當在步驟982中用戶沒有向信任引擎110提供滿足選擇的認證機構的要求的登記認證數(shù)據(jù)時，在步驟986中密碼處理模塊625確定是否存在具有不同的認證要求的其它認證機構。例如，密碼處理模塊625可以尋找具有更低的認證要求但是仍發(fā)放選擇的證書或其交叉認證的認證機構。
當上述具有更低要求的認證機構存在時，互用性過程970進行到步驟980并且選擇該認證機構。另選地，當不存在這種認證機構時，在步驟988中信任引擎110可以從用戶請求另外的認證令牌。例如，信任引擎110可以請求包括例如生物測定數(shù)據(jù)的新的登記認證數(shù)據(jù)。另外，信任引擎110可以請求用戶出現(xiàn)在信任第三方前并且提供適當?shù)恼J證證明(例如，出現(xiàn)在針對駕照、社會保險卡、銀行卡、出生證明、軍官證等等的公證前)。當信任引擎110接收到更新的認證數(shù)據(jù)時，互用性過程970進行到步驟984并且獲取上述選擇的證書。
通過上述互用性過程970，密碼處理模塊625有利地在不同的密碼系統(tǒng)之間提供無縫透明的翻譯和轉換。熟練技術人員將從這里的公開認識到上述互用系統(tǒng)的大量的優(yōu)點和實施方式。例如，互用性過程970的上述步驟986可有利地包括信任仲裁的方面(下文更加詳細討論)，其中，認證機構可以在特殊境況下接受較低等級的交叉認證。此外，互用性過程970可以包括確保標準證書撤銷之間的互用性以及標準證書撤銷的利用，例如，利用證書撤銷列表(CRL)、在線證書狀態(tài)協(xié)議(OCSP)等。圖10示出了根據(jù)本發(fā)明的實施例的各方面的認證過程1000的數(shù)據(jù)流。根據(jù)一個實施例，認證過程1000包括從用戶收集當前認證數(shù)據(jù)并且將它與用戶的登記認證數(shù)據(jù)進行比較。例如，認證過程1000在步驟1005開始，在步驟1005，用戶希望與例如賣方執(zhí)行事務。這種事務例如可包括選擇購買選項、請求訪問賣方系統(tǒng)120的限制區(qū)或裝置、等等。在步驟1010中，賣方向用戶提供事務ID和認證請求。事務ID可有利地包括192比特量(32比特時間戳，串連128比特隨機量或“現(xiàn)時(nonce)”，再串連32比特賣方特定常數(shù))。這種事務ID唯一識別事務從而使信任引擎110能夠拒絕假冒事務。認證請求可有利地包括針對特定事務需要什么等級的認證。例如，賣方可以指定談及的事務要求的特定置信等級。如果不能夠使得認證達到這個置信等級，則如下文所述，在用戶沒有進一步認證以提升置信等級或者賣方與服務器之間的認證條款沒有變化的情況下，將不會發(fā)生事務。在下文中更加完整地討論這些問題。根據(jù)一個實施例，有利的是，可由賣方側Java小程序或其它軟件程序產生事務ID和認證請求。此外,事務ID和認證數(shù)據(jù)的傳輸可以包括使用傳統(tǒng)的SSL技術(例如，1/2SSL或換言之賣方側認證的SSL)加密的一個或多個XML文檔。在用戶系統(tǒng)105接收到事務ID和認證請求后，用戶系統(tǒng)105從用戶收集潛在包括當前生物測定信息的當前認證數(shù)據(jù)。在步驟1015，用戶系統(tǒng)105用認證引擎215的公鑰至少對當前認證數(shù)據(jù)“B”和事務ID進行加密，并且將該數(shù)據(jù)傳送到信任引擎110。所述傳輸優(yōu)選包括至少用傳統(tǒng)的1/2SSL技術進行加密的XML文檔。在步驟1020中，事務引擎205接收該傳輸，優(yōu)選識別URL或URI中的數(shù)據(jù)格式或請求，并且將該傳輸轉發(fā)至認證引擎215。在步驟1015和1020中，賣方系統(tǒng)120在步驟1025使用優(yōu)選的全SSL技術向信任引擎110轉發(fā)事務ID和認證請求。該通信還可以包括賣方ID，盡管還可以通過事務ID的非隨機部分傳送賣方標識。在步驟1030和1035，事務引擎205接收該通信，建立審計索引的記錄，并且產生對要從數(shù)據(jù)存儲設施Dl到D4進行組裝的用戶的登記認證數(shù)據(jù)的請求。在步驟1040，儲存器系統(tǒng)700向認證引擎215傳送與用戶對應的登記認證數(shù)據(jù)的部分。在步驟1045，認證引擎215使用它的私鑰對該傳輸進行解密并且將該登記認證數(shù)據(jù)與由用戶提供的當前認證數(shù)據(jù)進行比較。步驟1045的比較可有利地應用啟發(fā)式上下文敏感認證(上文提及并且在下文更加詳細討論)。例如，如果接收到的生物測定信息沒有完美匹配，則得到較低置信匹配。在特定實施例中，認證的置信等級針對事務的性質以及用戶和賣方二者的期望進行平衡。在下文對此進行更加詳細的討論。在步驟1050，認證引擎215在認證請求內填入步驟1045的比較的結果。根據(jù)本發(fā)明的一個實施例，認證請求填充有認證過程1000的是/否或者真/假結果。在步驟1055，被填充的認證請求返回到賣方以由賣方遵照行事，例如允許用戶完成發(fā)起該認證請求的事務。根據(jù)一個實施例，確認消息被傳遞至用戶?；谏厦娴拿枋觯欣氖?，認證過程1000使敏感數(shù)據(jù)保持安全并且生成被構造為維護敏感數(shù)據(jù)的完整性的結果。例如，僅僅在認證引擎215內組裝敏感數(shù)據(jù)。例如，登記認證數(shù)據(jù)在通過數(shù)據(jù)組裝模塊在認證引擎215內進行組裝前是不可譯解的，并且當前認證數(shù)據(jù)在通過傳統(tǒng)的SSL技術和認證引擎215的私鑰進行展開(unwrap)前是不可譯解的。此夕卜，發(fā)送至賣方的認證結果不包括敏感數(shù)據(jù)，并且用戶甚至無法知道是否他或她生成了有效的認證數(shù)據(jù)。盡管參照其優(yōu)選和替代實施例公開了認證過程1000，但是本發(fā)明不限于此。相反，熟練技術人員將從這里的公開認識到認證過程1000的大量替代。例如，有利的是，賣方可由幾乎任何請求應用(甚至是駐留在用戶系統(tǒng)105內的應用)替代。例如，在對文檔進行解鎖之前，客戶機應用(例如，Microsoft Word)可使用應用程序接口(API)或密碼API (CAPI)請求認證。另選地，郵件服務器、網絡、蜂窩電話、個人或移動計算裝置、工作站等都可以形成能夠通過認證過程1000進行填充的認證請求。實際上，在提供上述信任的認證過程1000后，請求應用或裝置可以訪問或使用大量的電子或計算機裝置或系統(tǒng)。此外，在認證失敗的情況下，認證過程1000可以采用大量的替代過程。認證失敗可以保持用戶重新輸入他或她的當前認證數(shù)據(jù)的相同事務ID和請求。如上所述，使用相同的事務ID使認證引擎215的比較器可以監(jiān)視并限制針對特定事務的認證嘗試的數(shù)目，由此建立更加安全的密碼系統(tǒng)100此外，有利的是，認證過程1000可用于開發(fā)一流的單登錄方案(例如，對敏感數(shù)據(jù)倉庫(vault)進行解鎖)。例如，成功或肯定認證可以向認證的用戶提供自動訪問幾乎無限數(shù)目的系統(tǒng)和應用的任何數(shù)目的口令的能力。例如，用戶的認證可以向用戶提供對與多個在線賣方關聯(lián)的口令、登錄、金融證明等、局域網、各種個人計算裝置、互聯(lián)網服務提供商、拍賣商、投資經紀商等的訪問。通過采用敏感數(shù)據(jù)倉庫，用戶可以選擇真正大的和隨機的口令，這是因為他們不再需要通過關聯(lián)來記住它們。而且，認證過程1000提供對它們的訪問。例如，用戶可以選擇長度為20多位的隨機字母數(shù)字串，而非與可記憶數(shù)據(jù)、名稱等關聯(lián)的字母數(shù)字串。根據(jù)一個實施例，有利的是，與給定用戶關聯(lián)的敏感數(shù)據(jù)倉庫可以存儲在儲存器210的數(shù)據(jù)存儲設施內，或者被分裂并存儲在儲存器系統(tǒng)700內。根據(jù)這個實施例，在肯定的用戶認證后，信任引擎110將被請求的敏感數(shù)據(jù)(例如，適當?shù)目诹?提供給請求應用。根據(jù)另一個實施例，信任引擎110可以包括用于存儲敏感數(shù)據(jù)倉庫的單獨系統(tǒng)。例如，信任引擎110可以包括孤立的軟件引擎，用于執(zhí)行數(shù)據(jù)倉庫功能并且形象化地駐留在信任引擎110的上述前端安全系統(tǒng)的“后方”。根據(jù)這個實施例，在軟件引擎從信任引擎110接收到指示肯定的用戶認證的信號后，軟件引擎提供被請求的敏感數(shù)據(jù)。在另一個實施例中，數(shù)據(jù)倉庫可由第三方系統(tǒng)實現(xiàn)。與軟件引擎實施例類似，有利的是，在第三方系統(tǒng)從信任引擎110接收到指示肯定的用戶認證的信號后，第三方系統(tǒng)可以提供被請求的敏感數(shù)據(jù)。根據(jù)另一個實施例，數(shù)據(jù)倉庫可以在用戶系統(tǒng)105上實現(xiàn)。在從信任引擎110接收到指示肯定的用戶認證的信號后，用戶側軟件引擎可以有利地提供上述數(shù)據(jù)。盡管參照替代實施例公開了上述數(shù)據(jù)倉庫，但是熟練技術人員將從這里的公開認識到它的大量的另外實施方式。例如，特定數(shù)據(jù)倉庫可以包括一些或所有的上述實施例中的方面。此外，任何的上述數(shù)據(jù)倉庫可以在不同的時刻采用一個或多個認證請求。例如，任一數(shù)據(jù)倉庫可以對于每一個或多個事務定期地要求認證，對于每一個或多個會話以及對一個或多個網頁或網站的每次訪問要求認證，以一個或多個其它指定間隔等要求認證。
圖11示出了根據(jù)本發(fā)明的實施例的各方面的簽名過程1100的數(shù)據(jù)流。如圖11所示，簽名過程1100包括與在上文參照圖10描述的認證過程1000類似的步驟。根據(jù)本發(fā)明的一個實施例，簽名過程1100首先對用戶進行認證，然后執(zhí)行幾個數(shù)字簽名功能中的一個或多個(在下文進行更加詳細的描述)。根據(jù)另一個實施例，有利的是，簽名過程1100可以存儲與之相關的數(shù)據(jù)，例如，消息或文檔的哈希值等。有利的是，這個數(shù)據(jù)可用于審計或任何其它事件，例如，當參與方嘗試抵賴事務時。
如圖11所示，在認證步驟中，用戶和賣方可以有利地對消息(例如，合同)達成一致。在簽名過程中，有利的是，簽名過程1100確保由用戶簽名的合同與由賣方提供的合同相同。因此，根據(jù)一個實施例，在認證過程中，賣方和用戶在發(fā)送至認證引擎215的數(shù)據(jù)中包括消息或合同的各自副本的哈希值。通過僅僅采用消息或合同的哈希值，信任引擎110可有利地存儲明顯減小的數(shù)據(jù)量，從而提供更高效且成本效益高的密碼系統(tǒng)。此外，有利的是，存儲的哈希值可與討論的文檔的哈希值進行比較，以確定討論的文檔是否與由任一方簽名的文檔匹配。確定文檔是否和與事務相關的一個文檔相同的能力提供了附加證據(jù)，其能夠用于對抗由一方對事務抵賴的主張。
在步驟1103，認證引擎215組裝登記認證數(shù)據(jù)，并且將它與由用戶提供的當前認證數(shù)據(jù)進行比較。當認證引擎215的比較器指示登記認證數(shù)據(jù)與當前認證數(shù)據(jù)匹配時，認證引擎215的比較器還將由賣方提供的消息的哈希值與由用戶提供的消息的哈希值進行比較。因此，有利的是，認證引擎215確保用戶同意的消息與賣方同意的消息相同。
在步驟1105中，認證引擎215向密碼引擎220發(fā)送數(shù)字簽名請求。根據(jù)本發(fā)明的一個實施例，該請求包括消息或合同的哈希值。然而，熟練技術人員將從這里的公開認識至IJ，密碼引擎220實際上可以對任何類型的數(shù)據(jù)(包括但不限于視頻、音頻、生物測定、圖像或文本)進行加密以形成期望的數(shù)字簽名。返回到步驟1105，數(shù)字簽名請求優(yōu)選包括通過傳統(tǒng)的SSL技術傳送的XML文檔。
在步驟1110中，認證引擎215向數(shù)據(jù)存儲設施Dl到D4的每個發(fā)送請求，從而使得數(shù)據(jù)存儲設施Dl到D4的每個發(fā)送它們各自的與簽名方對應的一個或多個密碼密鑰的部分。根據(jù)另一個實施例，密碼引擎220采用上文所述的互用性過程970的一些或所有的步驟，從而使得密碼引擎220首先確定簽名方要從儲存器210或儲存器系統(tǒng)700請求的一個或多個適當密鑰，并且采取行動以提供適當?shù)钠ヅ涿荑€。根據(jù)另一個實施例，有利的是，認證引擎215或密碼引擎220可以請求與簽名方關聯(lián)并存儲在儲存器210或儲存器系統(tǒng)700中的一個或多個密鑰。
根據(jù)一個實施例，簽名方包括用戶和賣方之一或二者。在這種情況下，有利的是，認證引擎215請求與用戶和/或賣方對應的密碼密鑰。根據(jù)另一個實施例，簽名方包括信任引擎110。在這個實施例中，信任引擎110在證明認證過程1000正確地認證了用戶、賣方或二者。因此，認證引擎215請求信任引擎110的密碼密鑰(例如，屬于密碼引擎220的密鑰)以執(zhí)行數(shù)字簽名。根據(jù)另一個實施例，信任引擎110執(zhí)行數(shù)字公證類功能。在這個實施例中，簽名方包括連同信任引擎110的用戶、賣方或二者。因此，信任引擎110提供用戶和/或賣方的數(shù)字簽名，然后用它自身的數(shù)字簽名指示用戶和/或賣方得到正確認證。在這個實施例中，有利的是，認證引擎215可以請求與用戶、賣方或二者對應的密碼密鑰的組裝。根據(jù)另一個實施例，有利的是，認證引擎215可以請求與信任引擎110對應的密碼密鑰的組裝。根據(jù)另一個實施例，信任引擎110執(zhí)行授權書類功能。例如，信任引擎110可以代表第三方對消息進行數(shù)字簽名。在這種情況下，認證引擎215請求與第三方關聯(lián)的密碼密鑰。根據(jù)這個實施例，有利的是，簽名過程1100可以包括在允許授權書類功能之前對第三方進行認證。此外，認證過程1000可以包括對第三方約束(例如，規(guī)定何時以及在什么境況下可使用特定的第三方的簽名的商業(yè)邏輯等)的檢查?；谏厦娴拿枋?，在步驟1110中，認證引擎從與簽名方對應的數(shù)據(jù)存儲設施Dl到D4請求密碼密鑰。在步驟1115中，數(shù)據(jù)存儲設施Dl到D4將它們各自的與簽名方對應的密碼密鑰的部分傳輸至密碼引擎220。根據(jù)一個實施例,上述傳輸包括SSL技術。根據(jù)另一個實施例，有利的是，上述傳輸可用密碼引擎220的公鑰進行超級加密。在步驟1120中，密碼引擎220組裝簽名方的上述密碼密鑰并且用其對消息進行加密，從而形成數(shù)字簽名。在簽名過程1100的步驟1125中，密碼引擎220向認證引擎215發(fā)送該數(shù)字簽名。在步驟1130中，認證引擎215將填充了的認證請求連同哈希處理的消息的副本以及數(shù)字簽名發(fā)送至事務引擎205。在步驟1135中，事務引擎205將包括事務ID、認證是否成功的指示以及數(shù)字簽名的收據(jù)傳輸至賣方。根據(jù)一個實施例，有利的是，上述傳輸可以包括信任引擎110的數(shù)字簽名。例如，信任引擎110可以用它的私鑰對該收據(jù)的哈希值進行加密，從而形成要附加到至賣方的傳輸?shù)臄?shù)字簽名。根據(jù)一個實施例，事務引擎205還向用戶發(fā)送確認消息。盡管參照其優(yōu)選和替代實施例公開了簽名過程1100，但是本發(fā)明不限于此。相反，熟練技術人員將從這里的公開認識到簽名過程1100的大量替代。例如，可以用諸如電子郵件應用的用戶應用替換賣方。例如，用戶可能希望利用他或她的數(shù)字簽名對特定電子郵件進行數(shù)字簽名。在這種實施例中，有利的是，整個簽名過程1100中的傳輸可以僅僅包括消息的哈希值的一個副本。此外，熟練技術人員將從這里的公開認識到，大量的客戶機應用可以請求數(shù)字簽名。例如，客戶機應用可以包括字處理器、電子數(shù)據(jù)表、電子郵件、語音郵件、對限制系統(tǒng)區(qū)域的訪問等。此外，熟練技術人員將從這里的公開認識到，有利的是，簽名過程1100的步驟1105到1120可以采用圖9B的互用性過程970的一些或所有的步驟，從而提供例如需要處理不同簽名類型下的數(shù)字簽名的不同密碼系統(tǒng)之間的互用性。圖12示出了根據(jù)本發(fā)明的實施例的各方面的加密/解密過程1200的數(shù)據(jù)流。如圖12所示，通過使用認證過程1000對用戶進行認證，開始解密過程1200。根據(jù)一個實施例，認證過程1000在認證請求中包括同步會話密鑰。例如，在傳統(tǒng)的PKI技術中，熟練技術人員明白，使用公鑰和私鑰的加密或解密的計算強度大并且可能要求大量的系統(tǒng)資源。然而，在對稱密鑰密碼系統(tǒng)或消息的發(fā)送方和接收方共享用于對消息進行加密和解密的一個公同密鑰的系統(tǒng)中，數(shù)學運算明顯更簡單并更快速。因此，在傳統(tǒng)的PKI技術中，消息的發(fā)送方將產生同步會話密鑰并且使用更簡單更快速的對稱密鑰系統(tǒng)對消息進行加密。然后，發(fā)送方用接收方的公鑰對會話密鑰進行加密。加密的會話密鑰將附加到同步加密的消息并且這兩個數(shù)據(jù)都被發(fā)送至接收方。接收方使用他或她的私鑰對會話密鑰進行解密，然后使用會話密鑰對消息進行解密。基于上面的描述，更簡單更快速的對稱密鑰系統(tǒng)用于大部分的加密/解密處理。因此，在解密過程1200中，解密有利地假定已利用用戶的公鑰對同步密鑰進行了加密。因此，如上所述，加密的會話密鑰包括在認證請求中。返回到解密過程1200，在步驟1205中用戶已經得到認證后，認證引擎215將加密的會話密鑰轉發(fā)至密碼引擎220。在步驟1210中，認證引擎215向數(shù)據(jù)存儲設施Dl到D4的每個轉發(fā)請求用戶的密碼密鑰數(shù)據(jù)的請求。在步驟1215中，每個數(shù)據(jù)存儲設施Dl到D4將密碼密鑰的它們各自的部分傳輸至密碼引擎220。根據(jù)一個實施例，用密碼引擎220的公鑰對上述傳輸進行加密。在解密過程1200的步驟1220中，密碼引擎220組裝密碼密鑰并且用其對會話密鑰進行解密。在步驟1225中，密碼引擎將會話密鑰轉發(fā)至認證引擎215。在步驟1227中，認證引擎215填充包括解密的會話密鑰的認證請求，并且將填充了的認證請求發(fā)送至事務引擎205。在步驟1230中，事務引擎205將認證請求連同會話密鑰轉發(fā)至請求應用或賣方。然后，根據(jù)一個實施例，請求應用或賣方使用會話密鑰對加密的消息進行解密。盡管參照其優(yōu)選和替代實施例公開了解密過程1200，但是熟練技術人員將從這里的公開認識到解密過程1200的大量替代。例如，解密過程1200可以在同步密鑰加密之前并且依賴于全公鑰技術。在這種實施例中，請求應用可以將整個消息發(fā)送至密碼引擎220，或者可以采用一些類型的壓縮或可逆哈希法以將消息發(fā)送至密碼引擎220。熟練技術人員從本文公開還將認識到上述通信可有利地包括以SSL技術打包的XML文檔。加密/解密過程1200還提供文檔或其它數(shù)據(jù)的加密。因此，在步驟1235中，請求應用或賣方可有利地向信任引擎110的事務引擎205發(fā)送對用戶的公鑰的請求。請求應用或賣方產生這個請求，因為請求應用或賣方例如使用用戶的公鑰對將用于對文檔或消息進行加密的會話密鑰進行加密。如在登記過程900中所述，事務引擎205例如將用戶的數(shù)字證書的副本存儲在海量存儲器225中。因此，在加密過程1200的步驟1240中，事務引擎205從海量存儲器225請求用戶的數(shù)字證書。在步驟1245中，海量存儲器225將與用戶對應的數(shù)字證書發(fā)送至事務引擎205。在步驟1250中，事務引擎205將數(shù)字證書發(fā)送至請求應用或賣方。根據(jù)一個實施例，加密過程1200的加密部分不包括用戶的認證。這是因為請求賣方僅需要用戶的公鑰，而不請求任何敏感數(shù)據(jù)。熟練技術人員將從這里的公開認識到，如果特定用戶沒有數(shù)字證書，信任引擎110可采用一些或全部的登記過程900以為該特定用戶產生數(shù)字證書。然后，信任引擎110可啟動加密/解密過程1200，并由此提供適當?shù)臄?shù)字證書。此外，熟練技術人員將從這里的公開認識到，加密/解密過程1200的步驟1220和1235到1250可有利地采用圖9B的互用性過程的一些或所有的步驟，從而提供例如可能需要處理加密的不同密碼系統(tǒng)之間的互用性。圖13示出了根據(jù)本發(fā)明的另一個實施例的各方面的信任引擎系統(tǒng)1300的簡化框圖。如圖13所示，信任引擎系統(tǒng)1300包括多個不同的信任引擎1305、1310、1315和1320。為了便于更加全面理解本發(fā)明，圖13示出了具有事務引擎、儲存器和認證引擎的每個信任引擎1305、1310、1315和1320。然而，熟練技術人員認識到，每個事務引擎可有利地包括參照圖1到圖8公開的部件和通信通道中的一些、組合或全部。例如，一個實施例可有利地包括具有一個或多個事務引擎、儲存器以及密碼服務器或它們的任何組合的信任引擎。根據(jù)本發(fā)明的一個實施例，信任引擎1305、1310、1315和1320的每個在地理上分離，從而例如信任引擎1305可以駐留在第一位置，信任引擎1310可以駐留在第二位置，信任引擎1315可以駐留在第三位置，信任引擎1320可以駐留在第四位置。有利的是，上述地理分離減小了系統(tǒng)響應時間同時提高整個信任引擎系統(tǒng)1300的安全性。
例如，當用戶登錄到密碼系統(tǒng)100時，用戶可能離第一位置最近并且可能希望得到認證。如參照圖10所述，為了得到認證，用戶提供當前認證數(shù)據(jù)(例如，生物測定等等)，并且當前認證數(shù)據(jù)被與該用戶的登記認證數(shù)據(jù)進行比較。因此，根據(jù)一個例子，有利的是，用戶向地理上最近的信任引擎1305提供當前認證數(shù)據(jù)。信任引擎1305的事務引擎1321然后將當前認證數(shù)據(jù)轉發(fā)至也駐留在第一位置的認證引擎1322。根據(jù)另一個實施例，事務引擎1321將當前認證數(shù)據(jù)轉發(fā)至信任引擎1310、1315或1320的認證引擎中的一個或多個。
事務引擎1321還向例如信任引擎1305到1320的每個的儲存器請求登記認證數(shù)據(jù)的組裝。根據(jù)這個實施例，每個儲存器將它的登記認證數(shù)據(jù)部分提供給信任引擎1305的認證引擎1322。認證引擎1322然后利用例如來自前兩個儲存器的加密的數(shù)據(jù)部分進行響應，并且將登記認證數(shù)據(jù)組裝成譯解的形式。認證引擎1322將登記認證數(shù)據(jù)與當前認證數(shù)據(jù)進行比較并且將認證結果返回到信任引擎1305的事務引擎1321。
基于以上內容，信任引擎系統(tǒng)1300采用多個地理分離的信任引擎1305到1320中的最接近的一個執(zhí)行認證過程。根據(jù)本發(fā)明的一個實施例，有利的是，可以在在用戶系統(tǒng)105、賣方系統(tǒng)120或認證機構115中的一個或多個上執(zhí)行的客戶機側Java小程序處執(zhí)行到最接近的事務引擎的信息路由。根據(jù)一個替代實施例，可以采用更加精密的判斷過程以從信任引擎1305到1320進行選擇。例如，該判斷可以基于給定信任引擎的可用性、操作性、連接速度、負載、性能、地理接近、或者它們的組合。
這樣，信任引擎系統(tǒng)1300降低它的響應時間，同時保持與地理上遠離的數(shù)據(jù)存儲設施(例如，參照圖7描述的那些數(shù)據(jù)存儲設施，其中，每個數(shù)據(jù)存儲設施存儲敏感數(shù)據(jù)的隨機化部分)關聯(lián)的安全性優(yōu)點。例如，在例如信任引擎1315的儲存器1325處的安全危害不一定危害信任引擎系統(tǒng)1300的敏感數(shù)據(jù)。這是因為儲存器1325僅僅包含不可譯解的隨機化數(shù)據(jù)，在沒有更多數(shù)據(jù)的情況下它們是完全無用的。
根據(jù)另一個實施例，有利的是，信任引擎系統(tǒng)1300可以包括與認證引擎類似地布置的多個密碼引擎。密碼引擎可有利執(zhí)行密碼功能，例如，參照圖1到圖8公開的那些密碼功能。根據(jù)另一個實施例，信任引擎系統(tǒng)1300可有利地用多個密碼引擎替代多個認證引擎，從而執(zhí)行諸如參照圖1到圖8公開的密碼功能的密碼功能。根據(jù)本發(fā)明的另一個實施例，信任引擎系統(tǒng)1300可以用具有在上文公開的認證引擎、密碼引擎或它們二者的一些或所有的功能的引擎，來替代各多個認證引擎。
盡管參照其優(yōu)選和替代實施例公開了信任引擎系統(tǒng)1300，但是熟練技術人員將認識到，信任引擎系統(tǒng)1300可以包括信任引擎1305到1320的部分。例如，信任引擎系統(tǒng)1300可以包括一個或多個事務引擎、一個或多個儲存器、一個或多個認證引擎、一個或多個密碼引擎、或者它們的組合。
圖14示出了根據(jù)本發(fā)明的另一個實施例的各方面的信任引擎系統(tǒng)1400的簡化框圖。如圖14所示，信任引擎系統(tǒng)1400包括多個信任引擎1405、1410、1415和1420。根據(jù)一個實施例，信任引擎1405、1410、1415和1420的每個包括參照圖1到圖8公開的信任引擎110的一些或所有的部件。根據(jù)這個實施例，當用戶系統(tǒng)105、賣方系統(tǒng)120或認證機構115的客戶機側Java小程序與信任引擎系統(tǒng)1400進行通信時，這些通信被發(fā)送至信任引擎1405到1420的每個的IP地址。另外，信任引擎1405、1410、1415和1420的每個的每個事務引擎的行為與參照圖13公開的信任引擎1305的事務引擎1321的行為類似。例如，在認證過程中，信任引擎1405、1410、1415和1420的每個的每個事務引擎將當前認證數(shù)據(jù)發(fā)送至它們各自的認證引擎并且發(fā)送對存儲在信任引擎1405到1420的每個的每個儲存器中的隨機化數(shù)據(jù)進行組裝的請求。圖14沒有示出所有這些通信，因為這種圖示將變得極度復雜。從認證過程繼續(xù)，儲存器的每個然后將它的隨機化數(shù)據(jù)的部分發(fā)送至信任引擎1405到1420的每個的每個認證引擎。信任引擎的每個的每個認證引擎利用它的比較器確定當前認證數(shù)據(jù)是否與由信任引擎1405到1420的每個的儲存器提供的登記認證數(shù)據(jù)匹配。根據(jù)這個實施例，由每個認證引擎進行的比較的結果然后被發(fā)送至其它三個信任引擎的冗余模塊。例如，來自信任引擎1405的認證引擎的結果被發(fā)送至信任引擎1410、1415和1420的冗余模塊。因此，信任引擎1405的冗余模塊同樣地從信任引擎1410、1415和1420接收認證引擎的結果。圖15示出了圖14的冗余模塊的框圖。該冗余模塊包括比較器，該比較器被構造為從三個認證引擎接收認證結果并且將該結果發(fā)送至第四個信任引擎的事務引擎。該比較器對來自三個認證引擎的認證結果進行比較，并且如果這些結果中的兩個一致，則比較器得出認證結果應該與兩個一致認證引擎的認證結果匹配。這個結果然后被發(fā)送回與不與所述三個認證引擎關聯(lián)的信任引擎對應的事務引擎?；谏厦娴拿枋?，冗余模塊從來自優(yōu)選與該冗余模塊的信任引擎在地理上遠離的認證引擎接收的數(shù)據(jù)，確定認證結果。通過提供這種冗余功能，信任引擎系統(tǒng)1400確保對信任引擎1405到1420之一的認證引擎的危害不足以危害該特定信任引擎的冗余模塊的認證結果。熟練技術人員將認識到，信任引擎系統(tǒng)1400的冗余模塊功能還可以應用到信任引擎1405到1420的每個的密碼引擎。然而，在圖14中沒有示出這種密碼引擎通信以避免復雜性。此外，熟練技術人員將認識到，針對圖15的比較器的大量的替代認證結果沖突解決算法適用于本發(fā)明。根據(jù)本發(fā)明的另一個實施例，有利的是，信任引擎系統(tǒng)1400在密碼比較步驟內利用冗余模塊。例如，有利的是，可以在特定事務期間由一方或多方提供的文檔的哈希比較過程中實現(xiàn)參照圖14和圖15公開的一些或所有的上述冗余模塊。盡管針對特定的優(yōu)選和替代實施例描述了上述發(fā)明，但是基于這里的公開本領域普通技術人員將想到其它實施例。例如，信任引擎110可以發(fā)放短期證書，其中，私有密碼密鑰發(fā)布給用戶達到預定時長。例如，當前證書標準包括可以設置為在預定時間量后過期的有效性字段。因此，信任引擎Iio可以向用戶發(fā)布私鑰，其中，該私鑰例如在24小時內有效。根據(jù)這種實施例，有利的是，信任引擎110可以發(fā)放與特定用戶關聯(lián)的新的密碼密鑰對，然后發(fā)布該新的密碼密鑰對的私鑰。然后，一旦發(fā)布了私有密碼密鑰，信任引擎110使這種私鑰的任何內部有效使用立即過期，這是因為它不再能由信任引擎110保護。此外，熟練技術人員將認識到，密碼系統(tǒng)100或信任引擎110可以包括識別任何類型的裝置(例如但不限于膝上型電腦、蜂窩電話、網絡、生物測定裝置等)的能力。根據(jù)一個實施例，這種識別可來自在對特定服務的請求(例如，對導致訪問或使用的認證的請求、對密碼功能的請求等)中提供的數(shù)據(jù)。根據(jù)一個實施例，上述請求可以包括唯一裝置標識符，例如，處理器ID。另選地，該請求可以包括特定可識別數(shù)據(jù)格式的數(shù)據(jù)。例如，移動和衛(wèi)星電話常常不包括對全X509.v3重加密證書的處理能力，因此不請求它們。根據(jù)這個實施例，信任引擎110可以識別提供的數(shù)據(jù)格式的類型，并且僅僅以同樣方式進行回應。
在上述的系統(tǒng)的附加方面中，可以使用將在下文描述的各種技術提供上下文敏感認證。例如如圖16所示的上下文敏感認證提供不僅評估當用戶嘗試認證自身時由用戶發(fā)送的實際數(shù)據(jù)還評估圍繞該數(shù)據(jù)的產生和傳遞的境況的可能性。這些技術還可以支持用戶與信任引擎110之間或者賣方與信任引擎110之間的事務特定信任仲裁，這將在下面描述。
如上所述，認證是證明用戶是他說他是的那個人的過程。通常，認證要求向認證管理機構展示一些事實。本發(fā)明的信任引擎110代表用戶必須向其認證自己的機構。用戶必須通過以下方式向信任引擎110展示他就是他說他是的那個人:知道僅該用戶應該知道的事物(基于知識的認證)，具有僅該用戶應該具有的事物(基于令牌的認證)，或者通過成為僅該用戶應該是的事物(基于生物測定的認證)。
基于知識的認證的例子包括但不限于口令、PIN碼或者密碼鎖?；诹钆频恼J證的例子包括但不限于房屋鑰匙、物理信用卡、駕照或者特定電話號碼?；谏餃y定的認證的例子包括但不限于指紋、筆跡分析、面部掃描、手掃描、耳掃描、虹膜掃描、血管模式、DNA、語音分析或者視網膜掃描。
每種類型的認證具有特定的優(yōu)點和缺點，并且均提供不同的安全等級。例如，與偷聽某人的口令并且重復它相比，建立與他人的指紋匹配的假指紋一般更加困難。每種類型的認證還要求認證機構知道不同類型的數(shù)據(jù)從而使用該形式的認證來驗證某人。
本文所用的“認證”廣義地是指驗證某人的身份為他說他是的那個人的全部過程?！罢J證技術”是指基于特定知識、物理令牌、或者生物測定讀數(shù)的特定類型的認證。“認證數(shù)據(jù)”是指發(fā)送至或以其它方式向認證機構進行展示以建立身份的信息?！暗怯洈?shù)據(jù)”是指初始提交給認證機構以建立與認證數(shù)據(jù)進行比較的基線的數(shù)據(jù)。“認證實例”是指與根據(jù)認證技術進行認證的嘗試關聯(lián)的數(shù)據(jù)。
參照以上圖10描述了對用戶進行認證的過程中涉及的內部協(xié)議和通信。在如圖10的步驟1045所示的比較步驟內發(fā)生這個過程的進行上下文敏感認證的部分。這個步驟在認證引擎215內發(fā)生，并且涉及對從儲存器210取回的登記數(shù)據(jù)410進行組裝并且將由用戶提供的認證數(shù)據(jù)與它進行比較。在圖16中示出并且在下文描述這個過程的一個特定實施例。
在圖16的步驟1600中，認證引擎215接收由用戶提供的當前認證數(shù)據(jù)和從儲存器取回的登記數(shù)據(jù)。這兩組數(shù)據(jù)可以包含與不同的認證技術有關的數(shù)據(jù)。在步驟1605中，認證引擎215將與每個個體認證實例關聯(lián)的認證數(shù)據(jù)進行分離。這是必要的，從而將認證數(shù)據(jù)與用戶的登記數(shù)據(jù)的適當子集進行比較(例如，指紋認證數(shù)據(jù)應該與指紋登記數(shù)據(jù)而非口令登記數(shù)據(jù)進行比較)。
通常，對用戶進行認證涉及一個或多個個體認證實例，這取決于用戶可使用哪些認證技術。這些方法受到在用戶的登記過程內由用戶提供的登記數(shù)據(jù)的限制(如果用戶當?shù)怯洉r沒有提供視網膜掃描，則他將不能夠使用視網膜掃描認證自己)以及受到用戶當前可用的裝置的限制(例如，如果用戶在他的當前位置沒有指紋讀取器，則指紋認證是不實際的)。在一些情況下，單個認證實例足以對用戶進行認證，然而，在某些境況下，可以使用多個認證實例的組合從而對于特定事務對用戶進行更確信的認證。
每個認證實例包括與特定認證技術(例如，指紋、口令、智能卡等)有關的數(shù)據(jù)以及針對該特定技術的圍繞數(shù)據(jù)的捕捉和傳遞的境況。例如，嘗試經由口令進行認證的特定實例不僅將產生與口令自身有關的數(shù)據(jù)，還將產生與該口令嘗試有關的稱為“元數(shù)據(jù)”的境況數(shù)據(jù)。這個境況數(shù)據(jù)包括諸如以下的信息:特定認證實例發(fā)生的時間、從其傳遞認證信息的網絡地址、以及本領域技術人員已知的關于認證數(shù)據(jù)的起源可以確定的任何其它信息(連接的類型、處理器序列號等)。在許多情況下，僅僅少量的境況元數(shù)據(jù)可用。例如，如果用戶位于使用掩蔽起源計算機的地址的代理服務器或網絡地址翻譯或另一技術的網絡上，則僅僅可以確定代理服務器或路由器的地址。類似地，在許多情況下，例如處理器序列號的信息由于使用的硬件或操作系統(tǒng)的限制(系統(tǒng)運營商禁用這些特征)或者用戶的系統(tǒng)與信任引擎110之間的連接的其它限制而不可用。如圖16所示，一旦在步驟1605中提取并分離了在認證數(shù)據(jù)內表示的各個認證實例，認證引擎215針對每個實例的指示用戶是他宣稱的那個人的可靠性進行評估。通常，基于幾個因素確定單個認證實例的可靠性?？蓪⑺鼈兎纸M為在步驟1610中評估的和與認證技術關聯(lián)的可靠性有關的因素以及在步驟1815中評估的與提供的特定認證數(shù)據(jù)的可靠性有關的因素。第一組包括但不限于正使用的認證技術的固有可靠性以及與該方法一起使用的登記數(shù)據(jù)的可靠性。第二組包括但不限于登記數(shù)據(jù)與由認證實例提供的數(shù)據(jù)之間的匹配度以及與該認證實例關聯(lián)的元數(shù)據(jù)。這些因素中的每一個可以獨立于其它因素而變化。認證技術的固有可靠性基于冒名頂替者提供他人的正確數(shù)據(jù)的難度以及認證技術的整體誤差率。對于基于口令和知識的認證方法，這種可靠性常常是相當?shù)偷?，這是因為無法防止某人向另一個人泄露他們的口令以及該第二人使用該口令。即使是更加復雜的基于知識的系統(tǒng)仍可能僅具有中等可靠性，這是因為知識從一個人傳遞到另一人是相當容易的?；诹钆频恼J證(例如，具有正確智能卡或者使用特定終端執(zhí)行認證)在獨自使用時的可靠性同樣低，這是因為不能夠保證正當?shù)娜藫碛姓_令牌。然而，生物測定技術的固有可靠性更高，因為一般難以以方便的方式(甚至是有意地)向他人提供使用你的指紋的能力。由于破壞生物測定認證技術更加困難，所以生物測定方法的固有可靠性通常高于純粹基于知識或令牌的認證技術。然而，即使是生物測定技術也會有一些產生誤接受或誤拒絕的情況。通過相同生物測定技術的不同實施方式的不同可靠性，可以反映出這些情況。例如，由一個公司提供的指紋匹配系統(tǒng)可以提供比由一個不同公司提供的指紋匹配系統(tǒng)更高的可靠性，因為一個公司使用了更高質量的光學部件或更好的掃描分辨率或者減少誤接受或誤拒絕的發(fā)生的一些其它改進。要注意，該可靠性可以通過不同方式進行表示。期望以可由啟發(fā)法530和認證弓I擎215的算法用來計算每個認證的置信等級的一些度量來表示可靠性。表示這些可靠性的一個優(yōu)選方式是百分比或分數(shù)。例如，可能向指紋被分配97%的固有可靠性，而可能僅向口令分配50%的固有可靠性。本領域技術人員將認識到，這些特定值僅僅是示例性的并且可以在特定實施方式之間變化。必須評估可靠性的第二因素是登記的可靠性。這是上文提及的“分級登記”過程的一部分。該可靠性因素反映在初始登記過程內提供的標識的可靠性。例如，如果個人最初以他們用身體向公證人或其它公共官員生成他們的身份的證據(jù)的方式進行登記并且此時記錄并公證登記數(shù)據(jù)，則該數(shù)據(jù)的可靠性要強于經由網絡在登記過程中提供并且僅通過數(shù)字簽名或不真實依賴于該個人的其它信息進行擔保的數(shù)據(jù)。
具有不同可靠性等級的其它登記技術包括但不限于:在信任引擎110運營商的物理辦公室進行登記、在用戶的雇傭地點進行登記、在郵局或護照辦公室進行登記、通過附屬或信任方向信任引擎110運營商進行登記、登記身份還沒有被識別為真實個人的匿名或筆名登記、以及本領域知道的其它方式。
這些因素反映信任引擎110與在登記過程期間提供的標識的源之間的信任。例如，如果在提供身份證明的初始過程中與雇主關聯(lián)地執(zhí)行登記，則可認為這個信息對于公司內的用途是非?？煽康?，但是對于政府機構或競爭者而言信任程度較低。因此，由這些其它組織的每個操作的信任引擎可以為這個登記分配不同的可靠性等級。
類似地，在網絡上提交但是通過在先前向同一信任引擎110登記過程中提供的其它信任數(shù)據(jù)進行認證的附加數(shù)據(jù)可以被認為與原始登記數(shù)據(jù)一樣可靠，即使后一數(shù)據(jù)是在開放網絡上提交的。在這種境況下，隨后的公證將有效地提高與原始登記數(shù)據(jù)關聯(lián)的可靠性的等級。這樣，例如，通過向某登記官員展示與登記的數(shù)據(jù)匹配的個人的身份，匿名或筆名登記然后可被提升至全登記。
通常，上述的可靠性因素是在任何特定認證實例之前確定的值。這是因為它們基于登記和技術而非實際認證。在一個實施例中，基于這些因素產生可靠性的步驟包括查找針對這個特定認證技術的先前確定的值以及用戶的登記數(shù)據(jù)。在本發(fā)明的有利實施例的另一個方面中，這些可靠性可以包括在登記數(shù)據(jù)自身內。這樣，這些因素連同從儲存器210發(fā)送的登記數(shù)據(jù)被自動傳遞給認證引擎215。
盡管通?？梢栽谌魏蝹€體認證實例之前確定這些因素，但是它們仍然對針對該用戶使用該特定認證技術的每個認證實例具有影響。另外，盡管這些值可以隨時間而變化(例如，如果用戶以更可靠的方式重新登記)，但是它們并不取決于認證數(shù)據(jù)自身。通過對比，與單個特定實例的數(shù)據(jù)關聯(lián)的可靠性因素對于每個場合會變化。在步驟1815中，針對每個新的認證必須對下述的這些因素進行評估從而產生可靠性得分。
認證數(shù)據(jù)的可靠性反映了在特定認證實例中由用戶提供的數(shù)據(jù)與在認證登記過程內提供的數(shù)據(jù)之間的匹配。這是認證數(shù)據(jù)是否與用戶所宣稱的個人的登記數(shù)據(jù)匹配的基本提問。通常，當數(shù)據(jù)不匹配時，認為用戶沒有得到成功認證，并且認證失敗。對此進行評估的方式可以根據(jù)使用的認證技術而改變。通過如圖5所示的認證引擎215的比較器515功能執(zhí)行這種數(shù)據(jù)的比較。
例如，通常以二元方式對口令的匹配進行評估。換言之，口令要么是完全匹配，要么是失敗匹配。如果口令不是完全正確的，即使是部分匹配(接近于正確口令的口令)，通常也是不可以接受的。因此，當對口令認證進行評估時，由比較器515返回的認證的可靠性通常要么是100% (正確)要么是0% (錯誤)，而不存在中間值的可能性。
通常，與口令的規(guī)則類似的規(guī)則應用于基于令牌的認證方法(例如，智能卡)。這是因為具有一具有相似標識符或者與正確智能卡類似的智能卡，仍然與具有任何其它不正確令牌一樣是錯誤的。因此，令牌同樣趨于二元認證:用戶要么具有正確令牌，要么沒有。
然而，某些類型的認證數(shù)據(jù)(例如，問卷和生物測定)通常不是二元認證者。例如，指紋可以以不同程度與基準指紋進行匹配。在一定程度上，這可能是由于在初始登記過程或者在隨后的認證中捕捉的數(shù)據(jù)的質量的變化。(指紋可能被弄臟，或者人在特定手指上具有治療傷疤或燒傷)。在其它情況下，由于信息自身有些可變并且基于模式匹配，所以數(shù)據(jù)不會那么完美地匹配。(由于背景噪聲、或者記錄語音的環(huán)境的聲學或者由于人感冒，語音分析看起來接近但并非相當正確)。最終，在大量數(shù)據(jù)進行比較的情況下，就會有如下情況:很多數(shù)據(jù)匹配良好，但是一些數(shù)據(jù)不匹配。(十個提問的問卷會得到針對個人提問的八個正確回答以及兩個不正確回答)。針對這些理由中的任何理由，期望由比較器515向登記數(shù)據(jù)與特定認證實例的數(shù)據(jù)之間的匹配分配一個部分匹配值。這樣，例如，可以將指紋說成是85%匹配，將聲紋說成是65%匹配，將問卷說成是80%匹配。由比較器515生成的這種測量(匹配度)是表示認證是否正確的基本問題的因素。然而，如上所述，這僅僅是可用于確定給定的認證實例的可靠性的因素之一。還要注意，即使可以確定某部分程度的匹配，最終，希望基于部分匹配提供二元結果。在另一種操作模式下，還可以基于匹配度是否通過特定閾值的匹配水平，將部分匹配視為二元的，即，要么完美(100%)，要么失敗(0%)。這種過程可用于向系統(tǒng)提供簡單的通過/失敗等級的匹配，該系統(tǒng)否則以其它方式生成部分匹配。在評估給定的認證實例的可靠性時要考慮的另一個因素涉及提供針對這個特定實例的認證數(shù)據(jù)的境況。如上所述，這些境況是指與特定認證實例關聯(lián)的元數(shù)據(jù)。這可以包括但不限于如下信息:能夠進行確定的認證者的網絡地址、認證的時間、認證數(shù)據(jù)的傳輸模式(電話線、蜂窩電話、網絡等)、以及認證者的系統(tǒng)的序號。這些因素可用于生成由用戶通常請求的認證的類型的概況。然后，這個信息能夠用于以至少兩種方式評估可靠性。一種方式是考慮用戶是否正在以與該用戶的認證的正常概況一致的方式請求認證。如果用戶通常在工作日(當她工作時)向一個網絡地址進行認證請求并且在晚間或周末(當她在家時)向一個不同的網絡地址進行認證請求，則在工作日從家庭地址發(fā)生的認證是較不可靠的，因為它在正常認證概況之外。類似地，如果用戶通常使用指紋生物測定并且在夜間進行認證，則在白天僅僅使用口令發(fā)起的認證是較不可靠的。境況元數(shù)據(jù)可用于評估認證的實例的可靠性的另外方式是確定境況提供認證者是它宣稱的個人有多么確實。例如，如果認證來自已知與用戶關聯(lián)的序號的系統(tǒng)，則這是用戶是他們宣稱的人的良好境況指示符。相反地，如果認證來自已知位于洛杉磯的網絡地址而用戶已知位于倫敦，則這是該認證基于其境況而較不可靠的指示。當用戶與賣方系統(tǒng)或信任引擎110進行交互時，cookie或其它電子數(shù)據(jù)可以安置在用戶使用的系統(tǒng)上。這個數(shù)據(jù)寫入到用戶的系統(tǒng)的存儲器并且可以包含可由Web瀏覽器或用戶系統(tǒng)上的其它軟件讀取的標識。如果在會話之間這個數(shù)據(jù)被允許駐留在用戶系統(tǒng)上(“持久cookie”)，則在特定用戶的認證過程中，該數(shù)據(jù)可以與認證數(shù)據(jù)一起發(fā)送，作為這個系統(tǒng)的過去使用的進一步證據(jù)。實際上，給定實例的元數(shù)據(jù)(尤其是持久cookie)可以自身形成一種基于令牌的認證器。一旦如上所述在步驟1610和步驟1615中分別產生基于認證實例的技術和數(shù)據(jù)的適當?shù)目煽啃砸蛩兀诓襟E1620中它們用于產生提供的認證實例的總可靠性。這樣做的一種方式是以百分比簡單表示每個可靠性，然后將它們一起相乘。例如，假定:根據(jù)用戶的過去認證概況從對于用戶的家庭計算機完全已知的網絡地址送入認證數(shù)據(jù)(100%)，使用的技術是指紋識別(97%)，初始指紋數(shù)據(jù)由用戶的雇主通過信任引擎Iio進行登記(90%)，認證數(shù)據(jù)與登記數(shù)據(jù)中的原始指紋模板之間的匹配非常好(99%)。這個認證實例的總可靠性于是可以被計算為這些可靠性的乘積(100% X 97% X 90% X 99%=86.4% 可靠性)。
這個計算的可靠性表示一個認證的實例的可靠性。還可以使用不同地對待不同可靠性因素的技術，例如，通過使用向每個可靠性因素分配不同權重的公式，來計算一個認證實例的總可靠性。另外，本領域技術人員將認識到，使用的實際值可以表示與百分比不同的值并且可以使用非算術系統(tǒng)。一個實施例可以包括由認證請求者用來設置每個因素的權重和用于建立認證實例的總可靠性的算法的模塊。
如步驟1620所示，認證引擎215可以使用以上技術及其變型來確定一個認證實例的可靠性。然而，在許多認證情形下，它對于要同時提供的多個認證實例是有用的。例如，當使用本發(fā)明的系統(tǒng)嘗試對自身進行認證時，用戶可以提供用戶標識、指紋認證數(shù)據(jù)、智能卡和口令。在這種情況下，三個獨立的認證實例被提供給信任引擎110以進行評估。進行到步驟1625，如果認證引擎215確定由用戶提供的數(shù)據(jù)包括超過一個認證實例，則如步驟1630所示將依次選擇每個實例并且如上所述在步驟1610、1615和1620中進行評估。
要注意，許多所述的可靠性因素在這些實例中的一個與另一個之間不同。例如，這些技術的固有可靠性以及在認證數(shù)據(jù)與登記數(shù)據(jù)之間提供的匹配度很可能不同。另外，用戶可能已經在不同時間在不同境況下針對這些技術的每一個提供了登記數(shù)據(jù)，針對這些實例的每一個也提供不同的登記可靠性。最終，即使這些實例中的每一個實例的數(shù)據(jù)被提交的境況相同，這些技術的使用也均可以不同地適應用戶的概況。(例如，用戶可以正常使用他們的口令和指紋，而不是他們的智能卡)。
結果，這些認證實例的每一個的最終可靠性會彼此不同。然而，通過一起使用多個實例，認證的總置信等級將趨于增大。
一旦認證引擎針對在認證數(shù)據(jù)中提供的所有的認證實例執(zhí)行了步驟1610到1620，在步驟1635中使用每個實例的可靠性，評估總認證置信等級。將各個認證實例可靠性組合成認證置信等級的這個過程可以通過與生成的各個可靠性相關的各種方法進行模擬，并且還可以解決這些認證技術中的一些之間的特定交互。(例如，與一個口令甚至是例如基本語音分析的相當弱的生物測定相比，諸如口令的多個基于知識的系統(tǒng)可以生成較低的置信度)。
認證引擎215可以將多個并發(fā)認證實例的可靠性進行組合以產生最終置信等級的一個方式是將每個實例的不可靠性相乘以達到總不可靠性。通常，不可靠性是可靠性的互補百分比。例如，84%可靠的技術是16%不可靠的。生成86%、75%和72%的可靠性的上述的三個認證實例(指紋、智能卡、口令)分別將具有對應的(100-86)%、(100-75)%和(100-72)%、或者14%、25%和28%的不可靠性。通過將這些不可靠性相乘，我們得到14%X25%X28%的累積不可靠性，即0.98%的不可靠性，這對應于99.02%的可靠性。
在另一種操作模式中，可以在認證引擎215內應用附加因素和啟發(fā)法530以解決各種認證技術的依存性。例如，如果某人未經授權地訪問了特定家庭計算機，則他們很可能也可訪問該地址的電話線。因此，基于發(fā)起電話號碼以及認證系統(tǒng)的序號的認證不會使認證的總置信度增加多少。然而，基于知識的認證很大程度上獨立于基于令牌的認證(即，如果某人盜取了你的蜂窩電話或鑰匙，他們在沒有你的PIN或口令的情況下不大可能知道你的PIN或口令)。另外，不同賣方或其它認證請求者可能希望對認證的不同方面進行不同的加權。這可以包括使用單獨的加權因子或用于計算各個實例的可靠性的算法以及使用不同方式來評估具有多個實例的認證事件。例如，某些類型的事務的賣方(例如公司電子郵件系統(tǒng))希望缺省地主要基于啟發(fā)法和其它境況數(shù)據(jù)進行認證。因此，他們可以對與元數(shù)據(jù)和與圍繞認證事件的境況關聯(lián)的其它概況相關信息相關的因素施加高權重。通過與在工作時間內用戶登錄到正確機器相比不從用戶要求更多，這種布置可用于減輕正常工作時間內用戶的負擔。然而，另一個賣方可能對來自特定技術(例如指紋匹配)的認證進行最重加權，這是由于這種技術最適于出于特定賣方的目的進行認證的策略判斷。在一種操作模式下，在產生認證請求時由請求者定義這些不同的權重，并且這些不同的權重與認證請求一起發(fā)送至信任引擎110。在另一種操作模式下，在初始登記過程內針對認證請求者還可將這些選項設置為偏好并且存儲在認證引擎內。一旦認證引擎215針對提供的認證數(shù)據(jù)生成了認證置信等級，在步驟1640中這個置信等級用于完成認證請求，并且這個信息從認證引擎215轉發(fā)至事務引擎205，以包含在去往認證請求者的消息內。上述的過程僅僅是示例性的，本領域技術人員將認識到:這些步驟不需要按照所示順序執(zhí)行，或者僅希望執(zhí)行某些步驟，或者希望步驟的各種組合。另外，如果境況允許，某些步驟(例如，提供的每個認證實例的可靠性的評估)可以彼此并行地執(zhí)行。在本發(fā)明的另一個方面中，提供了一種適應當由上述過程生成的認證置信等級無法滿足要求認證的賣方或其它方的要求的信任等級時的情況的方法。在例如在提供的置信等級與希望的信任等級之間存在差距的境況下，信任引擎110的運營商能夠向一方或雙方提供提供替代數(shù)據(jù)或要求以彌合這個信任差距的機會。這里，這個過程將稱作“信任仲裁”。信任仲裁可以發(fā)生在以上參照圖10和圖11描述的密碼認證的框架內。如那里所示，賣方或其它方將請求與特定事務關聯(lián)的特定用戶的認證。在一種境況下，賣方簡單地請求認證(要么肯定，要么否定)，并且在從用戶接收到適當數(shù)據(jù)后，信任引擎110將提供這種二元認證。在例如這些的境況下，基于在信任引擎110內設置的偏好，確定為了保護肯定認證所需的置信度。然而，賣方也可以請求特定的信任等級以完成特定事務。這個所需的等級可包括在認證請求內(例如，對這個用戶認證達到98%置信度)，或者可由信任引擎110基于與事務關聯(lián)的其它因素確定(即，針對這個事務適當?shù)貙@個用戶進行認證)。一個這種因素可以是事務的經濟值。針對具有較大經濟值的事務，可能需要更高的信任度。相似地，針對具有高風險度的事務，可能需要高的信任度。相反，針對低風險或者低值的事務，賣方或其它認證請求者可能要求較低的信任等級。信任仲裁的過程發(fā)生于在圖10的步驟1050中信任引擎110接收認證數(shù)據(jù)的步驟和在圖10的步驟1055中將認證結果返回到賣方的步驟之間。在這些步驟之間，如圖17所示發(fā)生導致信任等級的評估和潛在信任仲裁的過程。在執(zhí)行簡單的二元認證的境況下，圖17所示的過程縮減為如上面參照圖10所述使事務引擎205直接將提供的認證數(shù)據(jù)與識別的用戶的登記數(shù)據(jù)進行比較，將任何差別標記為否定認證。
如圖17所示，在步驟1050中接收數(shù)據(jù)后的第一個步驟是在步驟1710中針對這個特定事務由事務引擎205確定肯定認證所需的信任等級。這個步驟可通過幾種不同方法之一執(zhí)行。當進行認證請求時，認證請求者可以對信任引擎110指定所需的信任等級。認證請求者還可以預先設置偏好，這個偏好存儲在可由事務引擎205訪問的儲存器210或其它存儲器內。然后，每當這個認證請求者進行認證請求時，可以讀取和使用這個偏好。該偏好還可以與特定用戶進行關聯(lián)，作為使得總是需要特定的信任等級以對那個用戶進行認證的安全性措施，該用戶偏好存儲在可由事務引擎205訪問的儲存器210或其它存儲介質中。所需等級還可以由事務引擎205或認證引擎215基于在認證請求中提供的信息(例如，要認證的事務的值和風險等級)而導出。在一種操作模式下，策略管理模塊或當產生認證請求時使用的其它軟件用于為事務的認證指定所需的信任度。這可以用于提供當基于在策略管理模塊內指定的策略分配所需的信任等級時要遵守的一系列規(guī)則。一種有利的操作模式是將這種模塊包括在賣方的Web服務器內，以針對由賣方的Web服務器發(fā)起的事務適當?shù)卮_定所需的信任等級。這樣，可以根據(jù)賣方的策略向來自用戶的事務請求分配所需的信任等級，并且這種信息可以與認證請求一起轉發(fā)至信任引擎110。這個所需的信任等級與賣方希望具有的、個人認證實際上是他將自己識別成的那個人的確定度相關。例如，如果事務是賣方希望合理的確定度的事務(由于貨物是轉手的)，則賣方可以要求85%的信任等級。對于賣方僅對用戶進行認證以允許他觀看會員內容或在聊天室實踐特權的情形，不利風險足夠小從而賣方僅要求60%的信任等級。然而，為了參與上萬美元的生產合同，賣方可以要求99%或更高的信任等級。這個所需的信任等級表示用戶必須對自己進行認證以完成事務的度量。例如如果所需的信任等級是85%，則用戶必須向信任引擎110提供足以使信任引擎110以85%置信度說用戶是他們說他們是的那個人的認證。這是所需的信任等級與生成肯定認證(達到賣方的滿意)或可能的信任仲裁的認證置信等級之間的平衡。如圖17所示，在事務引擎205接收到所需的信任等級后，在步驟1720中將所需的信任等級與認證引擎215針對當前認證計算的認證置信等級(參照圖16所討論的)進行比較。在步驟1730中如果認證置信等級高于事務的所需的信任等級，則過程移至步驟1740，在步驟1740中，事務引擎205針對這個事務生成肯定認證。表示此意的消息然后將被插入到認證結果中并且由事務引擎205返回到賣方，如在步驟1055中所示(見圖10)。然而，如果在步驟1730中認證置信等級沒有滿足所需的信任等級，則對于當前認證存在置信度差距，并且在步驟1750中進行信任仲裁。在下文參照圖18更加完全地描述信任仲裁。下述的這個過程在信任引擎110的事務引擎205內發(fā)生。由于執(zhí)行信任仲裁不需要認證或其它密碼操作(除了事務引擎205與其它部件之間的SSL通信所需的那些以外)，所以可以在認證引擎215之外執(zhí)行該過程。然而，如下所述，認證數(shù)據(jù)或其它密碼或認證事件的任何重新評估將要求事務引擎205向認證引擎215重新提交適當?shù)臄?shù)據(jù)。本領域技術人員將認識到，信任仲裁過程可以代替地構造為部分或全部地在認證引擎215自身內發(fā)生。如上所述，信任仲裁是信任引擎110對賣方與用戶之間的協(xié)商進行調停以嘗試適當?shù)乇ＷC肯定認證的過程。如在步驟1805所示，事務引擎205首先確定當前情況是否適于信任仲裁。這可以基于認證的境況(例如，這個認證是否已經經過多個循環(huán)的仲裁)以及賣方或者用戶的偏好進行確定，這將在下文進一步進行討論。
在不可以仲裁的這些境況下，該過程進行到步驟1810，在步驟1810中，事務引擎205產生否定認證，然后將它插入到認證結果，該認證結果在步驟1055中發(fā)送至賣方(見圖10)。可有利用于防止認證不確定地待決的一個限制是設置從初始認證請求開始的超時時段。這樣，在時限內沒有得到肯定認證的任何事務被拒絕進一步仲裁并且得到否定認證。本領域技術人員將認識到，這種時限可以根據(jù)事務的境況以及用戶和賣方的希望而變化。還可以對在提供成功認證時可進行的嘗試的數(shù)目進行限制。可以通過如圖5所示的嘗試限制器535對這些限制進行處理。
如果在步驟1805中沒有禁止仲裁，則事務引擎205然后將與事務方之一或二者進行協(xié)商。如在步驟1820中所示，事務引擎205可以向用戶發(fā)送消息以請求某形式的附加認證從而提高生成的認證置信等級。在最簡單的形式中，這可以簡單指示認證是不充分的。還可以發(fā)送生成一個或多個附加認證實例以提高認證的總置信等級的請求。
如果在步驟1825中用戶提供一些附加認證實例，則事務引擎205向事務的認證數(shù)據(jù)添加這些認證實例并且將它發(fā)送至認證引擎215，如在步驟1015所示(見圖10)，并且基于針對這個事務的預先存在的認證實例和新提供的認證實例重新評估該認證。
一種附加類型的認證可以是來自信任引擎110的用于例如通過電話呼叫在信任引擎110運營商(或者信任的合作人)與用戶之間進行某形式的人對人聯(lián)系的請求。這個電話呼叫或其它非計算機認證能夠用于提供與個人的私人聯(lián)系以及執(zhí)行某形式的基于問卷的認證。這還可以給出驗證發(fā)起電話號碼以及當呼入時潛在的用戶語音解析的機會。即使不能夠提供附加認證數(shù)據(jù)，與用戶的電話號碼關聯(lián)的附加上下文仍可以提高認證上下文的可靠性。基于這個電話呼叫的任何修正的數(shù)據(jù)或境況被送入信任引擎110以用于對認證請求的考慮。
此外，在步驟1820中，信任引擎110可以向用戶提供購買保險的機會，從而有效地購買更加確信的認證。信任引擎110的運營商有時可能僅希望使得在認證的置信等級高于某閾值的情況下才開始可用這個選項。實際上，這個用戶側保險是當認證滿足信任引擎110對于認證的正常所需信任等級但不滿足這個事務的賣方的所需信任等級時信任引擎110對用戶進行擔保的方式。這樣，即使用戶僅僅具有生成針對信任引擎110足夠的置信度的認證實例，他仍可以成功地認證為賣方要求的非常高的等級。
信任引擎110的這個功能使得信任引擎110可以對被認證為滿足信任引擎110而非滿足賣方的某人進行擔保。這與在向文檔添加公證人的簽名以向以后讀取該文檔的某人指示簽名出現(xiàn)在文檔上的人實際是對它進行簽名的人時由公證人執(zhí)行的功能類似。公證人的簽名證實用戶簽名的動作。以相同的方式，信任引擎提供執(zhí)行事務的人是他們說他們是的人的指示。
然而，因為信任引擎110人工推升用戶提供的置信等級，所以對于信任引擎110運營商存在更大的風險，因為用戶實際上沒有滿足賣方的所需的信任等級。保險的花費被設計為抵消誤肯定認證對于信任引擎110 (其可有效地對用戶的認證進行公證)的風險。用戶向信任引擎110運營商付費以承擔認證為比實際提供的還要高的置信等級的風險。
由于這種保險系統(tǒng)允許某人從信任引擎110有效地購買更高的置信等級，所以賣方和用戶都會希望防止在某些事務中使用用戶側保險。賣方可能希望將肯定認證限制到它們知道實際認證數(shù)據(jù)支持它們要求的置信度的情況，因此可能向信任引擎110指示用戶側保險不被允許。類似地，為了保護他的在線身份，用戶可能希望防止在他的帳戶上使用用戶側保險或者可能希望將它的使用限制到沒有保險的認證置信等級高于一定限制的情形。這可用作防止某人偷聽口令或盜取智能卡并使用它們假冒認證到低置信等級并且然后購買保險以生成非常高的(假)置信等級的安全措施。在確定是否允許用戶側保險時可以對這些因素進行評估。如果在步驟1840中用戶購買了保險，則在步驟1845中基于購買的保險調整認證置信等級，并且在步驟1730中把認證置信等級與所需的信任等級再次進行比較(見圖17)。該過程從步驟1730繼續(xù)，并且可能導致步驟1740中的肯定認證(見圖17)或者返回步驟1750中的信任仲裁過程從而進一步進行仲裁(如果允許的話),或者如果進一步仲裁被禁止則導致步驟1810中的否定認證。除了在步驟1820中向用戶發(fā)送消息以外，在步驟1830中事務引擎205還可以向賣方發(fā)送指示未決認證當前低于所需信任等級的消息。該消息還可以提供關于如何前進到賣方的各種選項。這些選項之一是簡單地向賣方通知當前認證置信等級是什么以及詢問賣方是否希望維持他們的當前未滿足的所需信任等級。這是有益的，因為在一些情況下，賣方可以具有用于對事務進行認證的獨立手段或者可能已經使用缺省的一組要求，該組要求通常導致初始指定比手邊的特定事務實際需要的更高的所需等級。例如，與賣方的所有輸入購買訂單事務預計滿足98%信任等級是標準實踐。然而，如果通過電話在賣方與長期顧客之間最近討論了訂單，并且緊接之后該事務得到認證，但是僅僅認證到93%置信等級，則賣方可能希望簡單降低這個事務的接受閾值，因為電話呼叫有效地向賣方提供了附加認證。在某些境況下，賣方會愿意降低他們的所需信任等級，但是并不總是降低到當前認證置信等級。例如，以上例子中的賣方可能認為，在訂單之前的電話呼叫可能值所需信任度下降4%，然而，這仍大于用戶生成的93%的置信度。如果在步驟1835中賣方確實調整了他們的所需的信任等級，則在步驟1730中對由認證生成的認證置信等級與該所需的信任等級進行比較(見圖17)。如果置信等級現(xiàn)在超過所需的信任等級，則在步驟1740中在事務引擎205中可產生肯定認證(見圖17)。如果沒有超過，則在允許的情況下可以如上所述嘗試進一步仲裁。除了請求對所需的信任等級進行調整外，事務引擎205還可以向請求認證的賣方提供賣方側保險。這個保險用于與以上針對用戶側保險描述的用途相同的用途。這里，然而，成本不對應于由信任引擎110在以上認證生成的實際認證置信等級時所承擔的風險，保險的成本對應于賣方在認證中接受低信任等級時所承擔的風險。不是僅僅降低他們的實際所需的信任等級，賣方可以選擇購買保險以保護自己免受與用戶認證中的低信任等級關聯(lián)的附加風險。如上所述，在現(xiàn)有認證已經高于某閾值的條件下，賣方僅僅考慮購買這種保險來覆蓋信任差距是有利的。得到這種賣方側保險，允許賣方有如下選項:在對自己無附加成本的情況下直接降低他的信任要求；自己承受誤認證的風險(基于所需的低信任等級)；或者針對認證置信等級與他的要求之間的信任差距購買保險，其中由信任引擎110運營商承擔已經提供的低置信等級的風險。通過購買保險，賣方有效地保持他的高信任等級要求，因為誤認證的風險被轉移給信任引擎110運營商。
如果在步驟1840中賣方購買了保險，則在步驟1730中對認證置信等級與所需的信任等級進行比較(見圖17)，并且該過程如上所述繼續(xù)。
要注意，用戶和賣方均響應來自信任引擎110的消息也是可以的。本領域技術人員將認識到，有多種方式可以處理這些情形。處理多個響應的可能性的一種有利模式是簡單地以先來先服務方式處理響應。例如，如果賣方以降低的所需信任等級進行響應并且用戶之后還立即購買保險以提升他的認證等級，則首先基于來自賣方的降低的信任要求對認證進行重新評估。如果認證現(xiàn)在是肯定的，則用戶的保險購買被忽略。在另一種有利的操作模式下，可能僅針對滿足新的降低的賣方的信任要求所需的保險等級向用戶收費(如果即使在降低了賣方信任要求的情況下仍然存在信任差距的話)。
如果在步驟1850中在信任仲裁過程中在針對認證設置的時限內沒有從任何一方接收到響應，則在步驟1805中對仲裁進行重新評估。這有效地再次開始仲裁過程。如果在步驟1805中時限終止或者其它境況防止進一步仲裁，則在步驟1810中由事務引擎205產生否定認證并且在步驟1055中返回到賣方(見圖10)。否則，新消息可以發(fā)送至用戶和賣方，并且該過程可以按期望被重復。
要注意，對于某些類型的事務，例如，對不是事務的一部分的文檔進行數(shù)字簽名，并不一定有賣方或其它第三方，因此事務主要在用戶與信任引擎110之間。在例如這些的境況下，信任引擎110將具有必須被滿足以產生肯定認證的它自身的所需的信任等級。然而，在這些境況下，常常不希望信任引擎110向用戶提供保險以使他可以提升他自己簽名的置信度。
可以使用在上文中參照信任引擎110描述的各種通信模式，執(zhí)行上述以及在圖16到圖18中所示的過程。例如，這些消息可以是基于web的并且使用信任引擎110與實時下載到在用戶或賣方系統(tǒng)上運行的瀏覽器的Java小程序之間的SSL連接進行發(fā)送。在另一種操作模式下，便于進行這種仲裁和保險事務的某些專用的應用可以由用戶和賣方使用。在另一種操作模式下，安全電子郵件操作可用于對上述的仲裁進行調停，由此實現(xiàn)延遲評估和認證的批處理。本領域技術人員將認識到，不同的通信模式可適用于賣方的認證要求和境況。
下面參照圖19的說明描述了整合上述本發(fā)明的各個方面的樣本事務。這個例子示出了由信任引擎110進行調停的用戶與賣方之間的整個過程。盡管以上詳細描述的各個步驟和部件可用于執(zhí)行下面的事務，但是所示的過程集中于信任引擎110、用戶以及賣方之間的交互。
在步驟1900中，當用戶在在線觀看網頁時在賣方的網站上填寫訂單表格時，事務開始。用戶希望將簽寫有他的數(shù)字簽名的這個訂單表格提交給賣方。為了這樣做，在步驟1905中，用戶向信任引擎110提交訂單表格和他對簽名的請求。用戶還將提供將如上所述用于對他的身份進行認證的認證數(shù)據(jù)。
在步驟1910中，如上所述由信任引擎110將認證數(shù)據(jù)與登記數(shù)據(jù)進行比較，并且如果生成了肯定認證，則用用戶的私鑰簽名的訂單表格的哈希值與訂單表格自身一起被轉發(fā)送賣方。
在步驟1915中，賣方接收到簽名的表格，然后在步驟1920中，賣方將產生發(fā)票或與要進行的購買有關的其它合同。在步驟1925中，這個合同以及對簽名的請求被發(fā)送回用戶。在步驟1930中，賣方還向信任引擎110發(fā)送針對這個合同事務的認證請求(包括將由雙方簽名的合同的哈希值)。為了允許由雙方對合同進行數(shù)字簽名，賣方還包括針對自身的認證數(shù)據(jù)從而使得能夠在以后對合同上的賣方的簽名進行驗證(如果需要的話)。如上所述，信任引擎110然后對由賣方提供的認證數(shù)據(jù)進行驗證以確認賣方的身份，并且如果在步驟1935中該數(shù)據(jù)生成肯定認證，則當從用戶接收到數(shù)據(jù)時從步驟1955繼續(xù)。如果賣方的認證數(shù)據(jù)沒有與賣方的登記數(shù)據(jù)匹配達到期望程度，則將一消息返回給賣方以請求進一步認證。如上所述，為了使得賣方向信任引擎110成功地認證自身，如果需要的話在這里可以執(zhí)行信任仲裁。當在步驟1940中用戶接收到合同時，他檢查合同，在步驟1945中如果合同可以接受則產生認證數(shù)據(jù)以對它進行簽名，然后在步驟1950中，向信任引擎110發(fā)送合同的哈希值以及他的認證數(shù)據(jù)。在步驟1955中，信任引擎110驗證該認證數(shù)據(jù)，并且如果認證良好，則如下所述繼續(xù)處理合同。如以上參照圖17和圖18所述，可以適當?shù)貓?zhí)行信任仲裁以彌合認證置信等級與事務的所需的認證等級之間存在的任何信任差距。在步驟1960中，信任引擎110用用戶的私鑰對合同的哈希值進行簽名，并且將該簽名的哈希值發(fā)送至賣方，代表自己對完整消息進行簽名，即，包括利用信任引擎110的私鑰510加密的完整消息(包括用戶的簽名)的哈希值。在步驟1965中，這個消息由賣方接收。該消息代表簽名的合同(使用用戶的私鑰加密的合同的哈希值)以及來自信任引擎110的收據(jù)(包括使用信任引擎110的私鑰加密的簽名的合同的消息的哈希值)。在步驟1970中，信任引擎110利用賣方的私鑰類似地準備合同的哈希值，并且將由信任引擎110簽名的這個合同轉發(fā)至用戶。這樣，在步驟1975中，用戶還接收由賣方簽名的合同的副本以及由信任引擎110簽名的傳遞簽名的合同的收據(jù)。除了上述以外，本發(fā)明的附加方面提供了 一種密碼服務提供模塊(SPM)，該密碼服務提供模塊(SPM)可由客戶機側應用用作訪問上述的由信任引擎110提供的功能的裝置。密碼SPM提供這種服務的一個有利方式是對第三方應用編程接口(API)與可經由網絡或其它遠程連接進行訪問的信任引擎110之間的通信進行調停。在下文中參照圖20描述樣本密碼SPM。例如，在典型系統(tǒng)上，程序員可使用多個API。每個API提供可由在系統(tǒng)上運行的應用2000進行的一組功能調用。提供適于密碼功能、認證功能和其它安全功能的編程接口的API的例子包括由微軟在它的Windows操作系統(tǒng)中提供的密碼API (CAPI) 2010和由IBM、Intel和開放組的其它成員發(fā)起的公共數(shù)據(jù)安全架構(⑶SA)。在下文的討論中，CAPI將用作示例性安全API。然而,還可以與CDSA或者本領域已知的其它安全API —起使用所述的密碼SPM。當調用密碼功能時，用戶系統(tǒng)105或賣方系統(tǒng)120使用這個API。包括在這些功能中的可以是與執(zhí)行各種密碼操作(諸如用特定密鑰對文檔進行加密，對文檔進行簽名，請求數(shù)字證書，驗證簽名的文檔上的簽名)關聯(lián)的請求以及本文所述或本領域技術人員知道的其它密碼功能。通常，在CAPI 2010所處于的系統(tǒng)本地執(zhí)行這些密碼功能。這是因為一般調用的功能要求使用本地用戶系統(tǒng)105的資源(例如，指紋讀取器)或者使用在本地機器上執(zhí)行的庫進行編程的軟件功能。通常由以上提及的提供執(zhí)行密碼功能使用的資源的一個或多個服務提供模塊(SPM) 2015,2020執(zhí)行對這些本地資源的訪問。這些SPM可以包括執(zhí)行加密或解密操作的軟件庫2015或者能夠訪問專用硬件2025 (例如，生物測定掃描裝置)的驅動程序和應用2020。與CAPI 2010提供可由系統(tǒng)105的應用2000使用的功能的方式非常類似，SPM 2015,2020向CAPI提供對與系統(tǒng)上的可用服務關聯(lián)的低級功能和資源的訪問。
根據(jù)本發(fā)明，可以提供一種密碼SPM 2030，其能夠訪問由信任引擎110提供的密碼功能并且使得應用2000通過CAPI 2010可獲得這些功能。與CAPI 2010僅僅能夠訪問可通過SPM 2015和2020在本地獲得的資源的實施例不同，這里所述的密碼SPM 2030將能夠向位于遠處的可進行網絡訪問的信任引擎110提交對密碼操作的請求以執(zhí)行希望的操作。
例如，如果應用2000需要密碼操作，例如對文檔進行簽名，則應用2000對適當?shù)腃API 2010功能進行功能調用。CAPI 2010繼而將執(zhí)行這個功能，利用通過SPM 2015和2020以及密碼SPM 2030使其可獲得的資源。在數(shù)字簽名功能的情況下，密碼SPM 2030將產生將通過通信鏈路125發(fā)送至信任引擎110的適當請求。
在密碼SPM 2030與信任引擎110之間發(fā)生的操作是可以在任何其它系統(tǒng)與信任引擎110之間進行的相同操作。然而，通過CAPI 2010可以使得用戶系統(tǒng)105有效地獲得這些功能，從而使這些功能看起來在用戶系統(tǒng)105自己的本地可獲得。然而，與普通的SPM2015和2020不同，這些功能在遠程信任引擎110上執(zhí)行，并且響應于適當請求，結果經由通信鏈路125中繼到密碼SPM 2030。
這個密碼SPM 2030使用戶系統(tǒng)105或賣方系統(tǒng)120可以獲得以其它方式可能無法獲得的大量操作。這些功能包括但不限于:文檔的加密和解密、數(shù)字證書的發(fā)放、文檔的數(shù)字簽名、數(shù)字簽名的驗證、以及對本領域技術人員顯而易見的其它操作。
在一個單獨的實施例中，本發(fā)明包括對任何數(shù)據(jù)集執(zhí)行本發(fā)明的數(shù)據(jù)保護方法的完整系統(tǒng)。這個實施例的計算機系統(tǒng)包括數(shù)據(jù)分裂模塊，該數(shù)據(jù)分裂模塊包括圖8所示和本文所述的功能。在本發(fā)明的一個實施例中，在本文中有時稱作安全數(shù)據(jù)解析器的數(shù)據(jù)分裂模塊包括包含數(shù)據(jù)分裂、加密和解密、重構或重裝功能的解析器程序或軟件套裝。這個實施例還可以包括一個數(shù)據(jù)存儲設施或多個數(shù)據(jù)存儲設施。數(shù)據(jù)分裂模塊或安全數(shù)據(jù)解析器包括跨平臺軟件模塊套裝，該跨平臺軟件模塊套裝集成在電子基礎設施內或者作為要求其數(shù)據(jù)元素的最大安全性的任何應用的附件。這個解析過程對任何類型的數(shù)據(jù)集，以及對任何和所有文件類型，或者在數(shù)據(jù)庫中對該數(shù)據(jù)庫中的任何數(shù)據(jù)行或列或單元進行運算。
在一個實施例中，可以以模塊分層方式設計本發(fā)明的解析過程，并且任何加密過程適用于本發(fā)明的過程。本發(fā)明的解析和分裂過程的模塊層可以包括但不限于:1)密碼分裂，分散并安全存儲在多個位置；2)加密，密碼分裂，分散并安全存儲在多個位置；3)加密，密碼分裂，對每份加密，然后分散并安全存儲在多個位置；以及4)加密，密碼分裂，用與在第一步驟中使用的加密不同類型的加密對每份進行加密，然后分散并安全存儲在多個位置。
在一個實施例中，這個過程包括根據(jù)產生的隨機數(shù)或密鑰的內容對數(shù)據(jù)進行分裂，并且對把要保護的數(shù)據(jù)分裂成兩個或更多部分或份的解析或分裂數(shù)據(jù)(在一個實施例中，優(yōu)選分裂成四個或更多部分的解析和分裂數(shù)據(jù))的加密中使用的密鑰執(zhí)行相同的密碼分裂，對所有的部分進行加密，然后根據(jù)請求者對隱私和安全的需要，將這些部分分散并存儲回數(shù)據(jù)庫中或者將它們重新定位到固定或可移動的任何指定裝置?；蛘?，在另一個實施例中，在由分裂模塊或安全數(shù)據(jù)解析器對數(shù)據(jù)集進行分裂之前可以進行加密。如在這個實施例中所述進行處理的原始數(shù)據(jù)被加密并打亂并且得到保護。實際上，如果希望的話，加密的元素可以分散到任何地方，包括但不限于單個服務器或數(shù)據(jù)存儲裝置、或者多個獨立的數(shù)據(jù)存儲設施或裝置之間。在一個實施例中，加密密鑰管理可以包括在軟件套裝內，或者在另一個實施例中，可以集成到現(xiàn)有的基礎設施或任何其它期望位置。密碼分裂(密碼術分裂)將數(shù)據(jù)劃分成N份。該劃分可以基于任何大小的數(shù)據(jù)單元，包括一個比特、多個比特、字節(jié)、千字節(jié)、兆字節(jié)或更大單元以及預定或隨機產生的數(shù)據(jù)單元大小的任何模式或組合?；陔S機或者預定的一組值，這些單元還可以具有不同的大小。這意味著數(shù)據(jù)能夠被看作是這些單元的序列。按照這種方式，例如通過使用一個或多個預定或隨機產生的數(shù)據(jù)單元大小的模式、序列或組合，數(shù)據(jù)單元自身的大小可以使數(shù)據(jù)更加安全。這些單元然后(隨機地或者根據(jù)一組預定值)被分布到N份中。該分布還可以涉及在各份中攪亂(shuffle)單元的順序。本領域普通技術人員易于明白，可以根據(jù)多種多樣的可能選擇(包括但不限于固定大小、預定大小、或者預定或隨機產生的數(shù)據(jù)單元大小的一個或多個組合、模式或序列)執(zhí)行將數(shù)據(jù)單元分布到多份中。在該密碼術分裂分裂過程的一些實施例中，數(shù)據(jù)的大小可以是任何合適數(shù)量的字節(jié)，大小諸如為一個、兩個、三個、五個、二十個、五十個、一百個、多于一百個、或N個字節(jié)。這種密碼分裂過程或密碼術分裂的一個特別例子將考慮數(shù)據(jù)大小為23個字節(jié)，數(shù)據(jù)單元大小選擇為I個字節(jié)，并且選擇的份數(shù)為4。每個字節(jié)將被分布到這4份之一中。假定隨機分布，將獲得密鑰以建立23個隨機數(shù)的序列(rl、r2、r3到r23)，其中，每個隨機數(shù)具有與這4份對應的I至4的值。數(shù)據(jù)的每個單元(在這個例子中，數(shù)據(jù)的23個獨立字節(jié))與對應于4份之一的23個隨機數(shù)之一關聯(lián)。通過將數(shù)據(jù)的第一字節(jié)安置到份號rl、將第二字節(jié)安置到份r2，將第三字節(jié)安置到份r3只至將數(shù)據(jù)的第23字節(jié)安置到份r23，可以將數(shù)據(jù)的各字節(jié)分布到這4份中。本領域普通技術人員易于理解，多種多樣的其它可行步驟或者步驟的組合或序列(包括數(shù)據(jù)單元的大小)可用于本發(fā)明的密碼術分裂過程，并且以上例子是用于對數(shù)據(jù)進行密碼術分裂的一個過程的非限制性描述。為了重建原始數(shù)據(jù)，將執(zhí)行反向操作。在本發(fā)明的密碼術分裂過程的另一個實施例中，用于密碼術分裂過程的選項是在各份中提供充足冗余從而使得僅僅需要這些份的子集就能夠將數(shù)據(jù)重裝或恢復成它的原始或可用形式。作為一個非限制性例子，可以按照“4取3”密碼術分裂進行密碼術分裂，從而使得將數(shù)據(jù)重裝或恢復成它的原始或可用形式僅僅需要這4份中的3份。這還稱作“N取M密碼術分裂”，其中，N是總份數(shù)，M至少比N小I。本領域普通技術人員易于理解，在本發(fā)明的密碼術分裂過程中建立這種冗余存在許多可能性。在本發(fā)明的密碼術分裂過程的一個實施例中，數(shù)據(jù)的每個單元存儲在兩份(主要份和備份份)中。使用上述的“4取3”密碼術分裂過程，可以丟失任何一份，并且由于僅僅需要全部4份中的3份，所以在沒有丟失數(shù)據(jù)單元的情況下這仍足以重裝或恢復原始數(shù)據(jù)。如本文所述，對應于這些份之一產生隨機數(shù)。基于密鑰，該隨機數(shù)與數(shù)據(jù)單元關聯(lián)并且存儲在對應份中。在這個實施例中，一個密鑰用于產生主要份和備份份隨機數(shù)。如本文所述，對于本發(fā)明的密碼術分裂過程，產生與數(shù)據(jù)單元的數(shù)目相等的從O到3的一組隨機數(shù)(還稱作主要份數(shù)字)。然后，產生與數(shù)據(jù)單元的數(shù)目相等的從I到3的另一組的隨機數(shù)(還稱作備份份數(shù)字)。然后，將數(shù)據(jù)的每個單元與主要份數(shù)字和備份份數(shù)字進行關聯(lián)?；蛘?，可以產生少于數(shù)據(jù)單元的數(shù)目的一組隨機數(shù)并且重復該隨機數(shù)組，但是這會降低敏感數(shù)據(jù)的安全性。主要份數(shù)字用于確定數(shù)據(jù)單元存儲在哪個份中。備份份數(shù)字與主要份數(shù)字進行組合以建立O至3的第三份數(shù)字，并且這個數(shù)字用于確定數(shù)據(jù)單元存儲在哪個份中。在這個例子中，用于確定第三份數(shù)字的式子是:
(主要份數(shù)字+備份份數(shù)字)MOD4=第三份數(shù)字
在上述的主要份數(shù)字為O至3且備份份數(shù)字為I至3的實施例中，確保了第三份數(shù)字與主要份數(shù)字不同。這導致數(shù)據(jù)單元存儲在兩個不同份中。本領域普通技術人員易于理解，除了本文公開的實施例以外，還有執(zhí)行冗余密碼術分裂和非冗余密碼術分裂的許多方式。例如，可以使用不同的算法攪亂每份中的數(shù)據(jù)單元。例如，當原始數(shù)據(jù)分裂成多個數(shù)據(jù)單元時，或者在將數(shù)據(jù)單元安置到各份中以后，或者份已滿以后，可以執(zhí)行該數(shù)據(jù)單元攪舌L。
可以對任何大小的數(shù)據(jù)單元(包括但不限于一個比特、多個比特、字節(jié)、千字節(jié)、兆字節(jié)或更大)執(zhí)行本文所述的各種密碼術分裂過程和數(shù)據(jù)攪亂過程以及本發(fā)明的密碼術分裂和數(shù)據(jù)攪亂方法的所有其它實施例。
執(zhí)行本文所述的密碼術分裂過程的源代碼的一個實施例的例子是:
權利要求
1.一種用于保護包括原始數(shù)據(jù)包的移動中數(shù)據(jù)的方法，該方法包括: 建立安全通信信道； 在所述安全通信信道內建立多個安全通信隧道，其中所述多個安全通信隧道中的每個使用由多個唯一認證機構中的一個發(fā)放的證書來建立； 基于多因素秘密共享，把每一個所述原始數(shù)據(jù)包分散為多個份； 使用與所述安全通信隧道中的一個不同安全通信隧道的建立關聯(lián)的密鑰，對所述多個份中的每個份進行加密；以及 把多個加密的份中的每個在所述多個安全通信隧道中的一個上發(fā)送。
2.根據(jù)權利要求1的方法，其中發(fā)送所述多個加密的份中的每個還包括:把所述多個加密的份中的每個在與由所述多個唯一認證機構中的一個發(fā)放的證書關聯(lián)的所述多個安全通信隧道中的一個上發(fā)送，其中在所述證書下建立了所述多個安全通信隧道中的所述一個。
3.根據(jù)權利要求1的方法，還包括: 接收所述多個加密的份，每個加密的份在所述多個安全通信隧道中的相應一個隧道上接收； 基于與所述多個安全通信隧道中的相應一個隧道的建立關聯(lián)的密鑰，對所述多個加密的份中的每個進行解密；以及 基于多因素秘密共享，恢復原始數(shù)據(jù)包的集合。
4.根據(jù)權利要求1的 方法，還包括產生認證機構層級，其中該認證機構層級包括一組根認證機構，并且其中所述多個唯一認證機構包括該組根認證機構。
5.根據(jù)權利要求1的方法，還包括產生認證機構層級，其中該認證機構層級包括一組次要認證機構，并且其中所述多個唯一認證機構包括該組次要認證機構。
6.根據(jù)權利要求1的方法，其中所述多個安全通信隧道中的每個建立在不同的物理傳輸介質上。
7.根據(jù)權利要求6的方法，其中所述物理傳輸介質中的至少一個經歷網絡故障，所述方法還包括在不喪失數(shù)據(jù)完整性的情況下恢復原始數(shù)據(jù)包。
8.根據(jù)權利要求7的方法，其中物理傳輸介質中的至少一個經歷網絡故障，所述多個份中的一部分被指定在故障的物理傳輸介質上發(fā)送，并且所述物理傳輸介質中的至少一個可工作，所述方法還包括: 在所述至少一個可工作物理傳輸介質內建立另外的安全通信隧道；以及 在所述另外的安全通信隧道上發(fā)送指定在該組故障物理傳輸介質中的至少一個上發(fā)送的所述多個份中的所述一部分。
9.根據(jù)權利要求1的方法，其中隧道和唯一認證機構之間的關聯(lián)是動態(tài)的。
10.根據(jù)權利要求1的方法，其中把每一個所述原始數(shù)據(jù)包分散為多個份還包括:基于N中取M密碼術分裂把每一個所述原始數(shù)據(jù)包分裂為多個份。
11.根據(jù)權利要求10的方法，其中所述多個份能夠通過重新組合至少定額的份從至少所述多個份的子集恢復。
12.根據(jù)權利要求1的方法，其中所述多個安全通信隧道是基于傳輸層安全協(xié)議建立的。
13.一種用于計算至少一個共享加密密鑰的方法，該方法包括: 產生原始秘密信息； 從多個唯一認證機構獲得公鑰； 把秘密信息分散成多個份； 至少部分地基于所述多個唯一認證機構中的一個不同認證機構的公鑰對每一個所述份進行加密，其中所述多個份能夠通過重新組合至少定額的份從至少所述多個份的子集恢復。
14.根據(jù)權利要求13的方法，還包括: 重新組合所述至少定額的份；以及 基于重新組合的份發(fā)送數(shù)據(jù)。
15.根據(jù)權利要求14的方法，還包括: 產生一組隨機數(shù)； 基于該組隨機數(shù)和原始秘密信息計算第一共享加密密鑰； 基于該組隨機數(shù)和重新組合的份計算第二共享加密密鑰；以及 基于第一共享加密密鑰和第二共享加密密鑰發(fā)送數(shù)據(jù)。
16.根據(jù)權利要求15的方法，還包括: 比較第一共享加密密鑰和第二共享加密密鑰； 基于所述比較確定是否發(fā)送數(shù)據(jù)；以及 基于所述確定發(fā)送數(shù)據(jù)。
17.根據(jù)權利要求13的方法，還包括:基于密鑰包裝對秘密信息的所述多個份的每一個進行加密。
18.根據(jù)權利要求17的方法，其中所述密鑰包裝基于工作組密鑰。
19.根據(jù)權利要求13的方法，還包括: 產生認證機構層級，其中該認證機構層級包括根認證機構；以及 基于由認證機構層級中的唯一根認證機構發(fā)放的證書對份的集合中的每一份進行加LU O
20.根據(jù)權利要求1的方法，還包括: 產生認證機構層級，其中該認證機構層級包括一組次要認證機構；以及基于由認證機構層級中的唯一次要認證機構發(fā)放的證書對份的集合中的每一份進行加密。
21.一種用于保護包括原始數(shù)據(jù)包的移動中數(shù)據(jù)的系統(tǒng)，該系統(tǒng)包括包含處理電路的第一裝置，該處理電路被配置為: 建立安全通信信道； 在所述安全通信信道內建立多個安全通信隧道，其中所述多個安全通信隧道中的每個使用由多個唯一認證機構中的一個發(fā)放的證書來建立； 基于多因素秘密共享，把每一個所述原始數(shù)據(jù)包分散為多個份； 使用與所述安全通信隧道中的一個不同安全通信隧道的建立關聯(lián)的密鑰，對所述多個份中的每個份進行加密；以及 把多個加密的份中的每個在所述多個安全通信隧道中的一個上發(fā)送。
22.根據(jù)權利要求21的系統(tǒng)，其中所述處理電路還被配置為:通過把所述多個加密的份中的每個在與由所述多個唯一認證機構中的一個發(fā)放的證書關聯(lián)的所述多個安全通信隧道中的一個上發(fā)送來發(fā)送所述多個加密的份中的每個，其中在所述證書下建立了所述多個安全通信隧道中的所述一個。
23.根據(jù)權利要求21的系統(tǒng)，還包括第二裝置，該第二裝置包括的處理電路還被配置為: 接收所述多個加密的份，每個加密的份在所述多個安全通信隧道中的相應一個隧道上接收； 基于與所述多個安全通信隧道中的相應一個隧道的建立關聯(lián)的密鑰，對所述多個加密的份中的每個進行解密；以及 基于多因素秘密共享，恢復原始數(shù)據(jù)包的集合。
24.根據(jù)權利要求21的系統(tǒng)，其中所述處 理電路還被配置為產生認證機構層級，其中該認證機構層級包括一組根認證機構，并且其中所述多個唯一認證機構包括該組根認證機構。
25.根據(jù)權利要求21的系統(tǒng)，其中所述處理電路還被配置為產生認證機構層級，其中該認證機構層級包括一組次要認證機構，并且其中所述多個唯一認證機構包括該組次要認證機構。
26.根據(jù)權利要求21的系統(tǒng)，其中所述多個安全通信隧道中的每個建立在不同的物理傳輸介質上。
27.根據(jù)權利要求26的系統(tǒng)，其中所述物理傳輸介質中的至少一個經歷網絡故障，所述方法還包括在不喪失數(shù)據(jù)完整性的情況下恢復原始數(shù)據(jù)包。
28.根據(jù)權利要求27的系統(tǒng)，其中物理傳輸介質中的至少一個經歷網絡故障，所述多個份中的一部分被指定在故障的物理傳輸介質上發(fā)送，并且所述物理傳輸介質中的至少一個可工作，所述處理電路還被配置為: 在所述至少一個可工作物理傳輸介質內建立另外的安全通信隧道；以及在所述另外的安全通信隧道上發(fā)送指定在該組故障物理傳輸介質中的至少一個上發(fā)送的所述多個份中的所述一部分。
29.根據(jù)權利要求21的系統(tǒng)，其中隧道和唯一認證機構之間的關聯(lián)是動態(tài)的。
30.根據(jù)權利要求21的系統(tǒng)，其中所述處理電路還被配置為通過基于N中取M密碼術分裂把每一個所述原始數(shù)據(jù)包分裂為多個份而把每一個所述原始數(shù)據(jù)包分散為多個份。
31.根據(jù)權利要求30的系統(tǒng)，其中所述多個份能夠通過重新組合至少定額的份從至少所述多個份的子集恢復。
32.根據(jù)權利要求21的系統(tǒng)，其中所述多個安全通信隧道是基于傳輸層安全協(xié)議建立的。
33.一種用于計算至少一個共享加密密鑰的系統(tǒng)，該系統(tǒng)包括包含第一處理電路的第一裝置，第一處理電路被配置為: 產生原始秘密信息； 從多個唯一認證機構獲得公鑰； 把秘密信息分散成多個份；基于所述多個唯一認證機構中的一個不同認證機構的公鑰對每一個所述份進行加密，其中所述多個份能夠通過重新組合至少定額的份從至少所述多個份的子集恢復。
34.根據(jù)權利要求33的系統(tǒng)，還包括第二裝置，該第二裝置包括的第二處理電路被配置為: 重新組合所述至少定額的份；以及 基于重新組合的份發(fā)送數(shù)據(jù)。
35.根據(jù)權利要求34的系統(tǒng)，其中第一處理電路還被配置為產生第一組隨機數(shù)，并且第二處理電路還被配置為產生第二組隨機數(shù)。
36.根據(jù)權利要求35的系統(tǒng),其中第一處理電路還被配置為基于第一組和第二組隨機數(shù)以及原始秘密信息計算第一共享加密密鑰，第二處理電路還被配置為基于第一組和第二組隨機數(shù)以及重新組合的份計算第二共享加密密鑰，并且第一和第二處理電路還被配置為基于第一共享加密密鑰和第二共享加密密鑰發(fā)送數(shù)據(jù)。
37.根據(jù)權利要求36的系統(tǒng)，其中第一處理電路還被配置為: 比較第一共享加密密鑰和第二共享加密密鑰； 基于所述比較確定是否發(fā)送數(shù)據(jù)；以及 基于所述確定發(fā)送數(shù)據(jù)。
38.根據(jù)權利要求33的系統(tǒng)，其中第一處理電路還被配置為基于密鑰包裝對秘密信息的多個份的每一個進行加密。
39.根據(jù)權利要求38的系統(tǒng)，其中所述密鑰包裝基于工作組密鑰。
40.根據(jù)權利要求33的系統(tǒng)，其中第一處理電路還被配置為: 產生認證機構層級，其中該認證機構層級包括根認證機構；以及 基于由認證機構層級中的唯一根認證機構發(fā)放的證書對份的集合中的每一份進行加LU O
41.根據(jù)權利要求33的系統(tǒng)，其中第一處理電路還被配置為: 產生認證機構層級，其中該認證機構層級包括一組次要認證機構；以及基于由認證機構層級中的唯一次要認證機構發(fā)放的證書對份的集合中的每一份進行加 密。
全文摘要
提供了在一組認證機構之中分布信任的兩種方案。這兩種方案是同等安全的。在每種方案中，將安全數(shù)據(jù)解析器與任何合適的加密技術整合。每種方案可被用于保護移動中數(shù)據(jù)。一種方案提供使用安全數(shù)據(jù)解析器在兩個裝置的連接的初始協(xié)商期間(例如，密鑰建立階段)在一組認證機構之中分布信任的方法和系統(tǒng)。本發(fā)明的另一種方案提供使用安全數(shù)據(jù)解析器把數(shù)據(jù)包分散為多個份的方法和系統(tǒng)。使用一組認證機構在一通信信道內建立一組隧道，在所述隧道的建立期間形成的密鑰被用于對每個隧道的數(shù)據(jù)份進行加密，所述數(shù)據(jù)份通過各個隧道發(fā)送。因此，在通信信道自身的結構中在一組認證機構之中分布了信任。
文檔編號H04L12/22GK103190129SQ201080060510
公開日2013年7月3日 申請日期2010年11月24日 優(yōu)先權日2009年11月25日
發(fā)明者R·L·歐西尼, M·S·歐艾爾, S·C·博諾, G·D·蘭道, S·J·尼艾爾森 申請人:安全第一公司