專利名稱：用于管理加密密鑰的系統(tǒng)和方法
技術領域：
本發(fā)明一般地涉及用于保護數(shù)據(jù)以免于未授權訪問或使用的系統(tǒng)。更具體地，本發(fā)明涉及用于支持加密密鑰的公共接口。
背景技術：
在當今社會，個人和企業(yè)在計算機系統(tǒng)上和通過計算機系統(tǒng)執(zhí)行不斷增加的活動量。這些計算機系統(tǒng)，包括專屬的和非專屬的計算機網(wǎng)絡，通常存儲、存檔和傳輸各種類型的敏感信息。因此，存在不斷增加的用于確保通過這些系統(tǒng)存儲和傳輸?shù)臄?shù)據(jù)不被讀取或泄露(compromise)的需求。用于保護計算機系統(tǒng)的一種通常解決方案是提供登錄和口令功能。然而，口令管理已經(jīng)被證明是花費非常大的，大量的求助臺呼叫都與口令問題有關。此外，口令提供了很少的安全性，這是因為它們通常被存儲在易受到通過例如暴力攻擊而進行的不適當訪問的文件中。用于保護計算機系統(tǒng)的另一方案是提供加密基礎結(jié)構(gòu)。密碼術通常指的是通過將數(shù)據(jù)變換或加密成為不可讀格式來保護數(shù)據(jù)。只有那些擁有加密密鑰的人才能夠?qū)?shù)據(jù)解密成可用格式。密碼術被用來識別用戶(例如認證)，以允許訪問特權(例如授權)從而創(chuàng)建數(shù)字證書和簽名等。一種普遍的密碼術系統(tǒng)是使用兩個密鑰的公鑰系統(tǒng)，公鑰被每個人知道，而私鑰僅被其個人或企業(yè)所有者知道。通常，使用一個密鑰加密的數(shù)據(jù)用另一密鑰解密，并且任一密鑰都不可由另一密鑰重建。遺憾的是，即使上述典型的公鑰加密系統(tǒng)在安全上仍然高度依賴用戶。例如，加密系統(tǒng)例如通過用戶瀏覽器向用戶發(fā)布私鑰。沒有經(jīng)驗的用戶然后通常將該私鑰存儲在可被其他人通過開放的計算機系統(tǒng)(例如，因特網(wǎng))訪問的硬盤驅(qū)動器上。另一方面，用戶可能為包含其私鑰的文件選擇較差的名字，例如，“密鑰”。上述和其他動作的結(jié)果是使得密鑰或多個密鑰易被泄露。除了上述泄露，用戶還可能將他或她的私鑰保存在配置有存檔或備份系統(tǒng)的計算機系統(tǒng)上，潛在地導致私鑰的副本經(jīng)過多個計算機存儲裝置或其他系統(tǒng)。這種安全漏洞通常被稱作“密鑰遷移(key migration)”。類似于密鑰遷移，許多應用最多通過簡單的登錄和口令訪問提供對用戶的私鑰的訪問。如上所述，登錄和口令訪問往往無法提供充分的安全性。用于增加上述加密系統(tǒng)的安全性的一個解決方案是將生物識別(biometrics)包括作為認證或授權的一部分。生物識別通常包括可測量的身體特征，諸如能夠由自動化系統(tǒng)通過例如圖案匹配或者指紋圖案或語音圖案識別而檢查的指紋或語音。在這樣的系統(tǒng)中，用戶的生物識別信息和/或密鑰可以被存儲在移動計算裝置(例如，智能卡、膝上型電腦、個人數(shù)字助理、或移動電話)上，從而使得生物識別信息或密鑰能夠在移動環(huán)境下使用。上述的移動生物識別加密系統(tǒng)仍然遭受各種缺點。例如，移動用戶可能丟失或損壞智能卡或便攜式計算裝置，從而使他或她對可能重要的數(shù)據(jù)的訪問被完全切斷?；蛘撸瑦阂獾娜丝赡芡等∫苿佑脩舻闹悄芸ɑ虮銛y式計算裝置并使用它來有效地偷取移動用戶的數(shù)字證書。另一方面，便攜式計算裝置可以連接到諸如因特網(wǎng)之類的開放系統(tǒng)，并且，類似于口令，存儲生物識別信息的文件可能由于用戶對于安全性的疏忽或惡意入侵者而易被泄露。此外，有許多方式來安全地創(chuàng)建、存儲和管理個人加密密鑰。例如，一些應用可以將用戶的加密密鑰存儲在密鑰存儲器或其他數(shù)據(jù)結(jié)構(gòu)中。在用戶的密鑰存儲器中的加密密鑰可以被多種應用訪問。然而一些應用可能與其他應用不兼容，或可能損害用戶的加密密鑰的安全性，例如，將一個或多個密鑰暴露至訛誤或未授權或不安全的訪問。

發(fā)明內(nèi)容
因此，提供一種密碼系統(tǒng)，其安全性是用戶無關的，同時仍支持移動用戶。此外，還提供了一種公共接口，例如應用程序接口(API )，其能夠支持對多個加密密鑰提供者的多個接口，并將從這些密鑰提供者獲取的加密密鑰提交給安全解析器引擎(secure parser engine),該安全解析器引擎用于例如保護用于存儲或傳輸?shù)臄?shù)據(jù)。這樣的安全解析器引擎在Orsini等人的美國專利N0.7，391，865,2005年10月25日提交的美國專利申請N0.11/258,839以及2006年11月20日提交的美國專利申請N0.11/602,667中有更詳細的描述，所有這些都通過引用全文結(jié)合于此。因此，本發(fā)明的一個方面是提供一種用于保護實際上任何類型的數(shù)據(jù)免于未授權訪問或使用的方法。該方法包括將要保護的數(shù)據(jù)解析、拆分和/或分離成為兩個或更多個部或部分的一個或多個步驟。該方法還包括加密要保護的數(shù)據(jù)。數(shù)據(jù)的加密可以在數(shù)據(jù)的第一次解析、拆分和/或分離之前或之后執(zhí)行。此外，對于數(shù)據(jù)的一個或多個部分可以重復加密步驟。類似地，對于數(shù)據(jù)的一個或多個部分可以重復解析、拆分和/或分離步驟。該方法還可選地包括存儲已經(jīng)在一個位置或在多個位置處加密的解析、拆分和/或分離的數(shù)據(jù)。該方法還可選地包括將被保護的數(shù)據(jù)重建或重新組裝成其原始形式以供授權的訪問或使用。該方法可以結(jié)合到任何能夠執(zhí)行該方法的期望步驟的計算機、服務器、引擎等的操作中。本發(fā)明的另一方面提供了一種用于實際保護任何類型的數(shù)據(jù)免于未授權訪問或使用的系統(tǒng)。該系統(tǒng)包括數(shù)據(jù)拆分模塊、加密處理模塊以及可選的數(shù)據(jù)組裝模塊。在一個實施例中，該系統(tǒng)還包括一個或多個數(shù)據(jù)存儲設備，其中可以存儲安全數(shù)據(jù)。因此，本發(fā)明的一個方面是提供安全服務器或信任引擎，其具有服務器中心(server-centric)密鑰，或換句話說，在服務器上存儲加密密鑰和用戶認證數(shù)據(jù)。根據(jù)該實施例，用戶訪問信任引擎以執(zhí)行認證和加密功能，所述功能諸如但不限于，認證，授權，數(shù)字簽名，生成、存儲和檢索證書，加密，類似公證和類似委托書的動作，等等。
本發(fā)明的另一方面是提供一種可靠的或可信任的認證處理。而且，在可信任的肯定認證之后，可以采取大量的不同動作，從提供加密技術，到系統(tǒng)或裝置授權和訪問，到允許使用或控制一個或大量電子裝置。本發(fā)明的另一方面是在加密密鑰和認證數(shù)據(jù)不被丟失、偷取或泄露的環(huán)境中提供加密密鑰和認證數(shù)據(jù)，從而有利地避免對連續(xù)重新發(fā)布和管理新密鑰和認證數(shù)據(jù)的需求。根據(jù)本發(fā)明的另一方面，信任引擎允許用戶為多個活動、供應商和/或認證請求使用一個密鑰對。根據(jù)本發(fā)明的另一方面，信任引擎在服務器端執(zhí)行加密處理的至少一個步驟，例如但不限于，加密、認證、或簽名，從而允許客戶或用戶僅擁有很少的計算資源。根據(jù)本發(fā)明的另一方面，信任引擎包括一個或多個倉庫，用于存儲每個加密密鑰和認證數(shù)據(jù)的各個部分。這些部分是通過數(shù)據(jù)拆分處理來創(chuàng)建的，禁止在沒有來自一個倉庫中多于一個位置或來自多個倉庫的預定部分的情況下重建。根據(jù)另一實施例，多個倉庫在地理上可以是遠離的，從而在一個倉庫處的不良員工或被泄密的系統(tǒng)不會提供對用戶密鑰或認證數(shù)據(jù)的訪問。根據(jù)另一實施例，認證處理有利地允許信任引擎并行處理多個認證活動。根據(jù)另一實施例，信任引擎可以有利地跟蹤失敗的訪問嘗試，并由此限制惡意入侵者可能嘗試破壞系統(tǒng)的次數(shù)。根據(jù)本發(fā)明的另一實施例，信任引擎可以包括多個實例，其中每個信任引擎可以預測并與其他信任引擎共享處理負荷。根據(jù)另一實施例，信任引擎可以包括用于輪詢(poll)多個認證結(jié)果以確保多于一個系統(tǒng)認證了用戶的冗余模塊。因此，本發(fā)明的一個方面包括安全加密系統(tǒng)，其可以被遠程訪問，用于存儲任何類型的數(shù)據(jù)，包括但不限于與多個用戶相關聯(lián)的多個私有加密密鑰。該加密系統(tǒng)將多個用戶中的每個用戶與多個私有加密密鑰中的一個或多個不同密鑰相關聯(lián)，并使用相關聯(lián)的一個或多個不同密鑰為每個用戶執(zhí)行加密功能而不釋放(release)所述多個私有加密密鑰給用戶。該加密系統(tǒng)包括倉庫系統(tǒng)，其具有存儲要保護的數(shù)據(jù)(諸如多個私有加密密鑰和多個注冊認證數(shù)據(jù))的至少一個服務器。每個注冊認證數(shù)據(jù)識別多個用戶之一，并且多個用戶中的每個用戶與多個私有加密密鑰中的一個或多個不同密鑰相關聯(lián)。該加密系統(tǒng)還可以包括認證引擎，其將由多個用戶中的一個用戶接收的認證數(shù)據(jù)與對應于該用戶并從倉庫系統(tǒng)接收的注冊認證數(shù)據(jù)進行比較，從而產(chǎn)生認證結(jié)果。該加密系統(tǒng)還可以包括加密引擎，其在認證結(jié)果表明正確識別了該多個用戶中的該用戶時，以該多個用戶中的該用戶的名義使用從倉庫系統(tǒng)接收的相關聯(lián)的一個或多個不同密鑰執(zhí)行加密功能。該加密系統(tǒng)還可以包括交易引擎，連接以將數(shù)據(jù)從多個用戶路由至倉庫服務器系統(tǒng)、認證引擎、以及加密引擎。本發(fā)明的另一方面包括安全加密系統(tǒng)，其可選地可遠程訪問。該加密系統(tǒng)包括倉庫系統(tǒng)，其具有存儲至少一個私鑰和任何其他數(shù)據(jù)的至少一個服務器，其中其他數(shù)據(jù)例如但不限于多個注冊認證數(shù)據(jù)，每個注冊認證數(shù)據(jù)識別可能的多個用戶之一。該加密系統(tǒng)還可以可選地包括認證引擎，其將用戶接收到的認證數(shù)據(jù)與對應于該用戶并從倉庫系統(tǒng)接收的注冊認證數(shù)據(jù)進行比較，從而產(chǎn)生認證結(jié)果。該加密系統(tǒng)還包括加密引擎，其在認證結(jié)果表明正確識別了用戶時，以該用戶的名義至少使用所述私鑰來執(zhí)行加密功能，所述私鑰可以從倉庫系統(tǒng)接收。該加密系統(tǒng)還可以可選地包括交易引擎，其連接以將數(shù)據(jù)從用戶路由至其他引擎或系統(tǒng)，例如但不限于，倉庫服務器系統(tǒng)、認證引擎、以及加密引擎。
本發(fā)明的另一方面包括一種有助于加密功能的方法。該方法包括將多個用戶中的一個用戶與存儲在安全位置(諸如安全服務器)的多個私有加密密鑰中的一個或多個密鑰相關聯(lián)。該方法還包括接收來自用戶的認證數(shù)據(jù)，以及將該認證數(shù)據(jù)與對應于該用戶的認證數(shù)據(jù)進行比較，從而校驗該用戶的身份。該方法還包括使用一個或多個密鑰來執(zhí)行加密功能而不向該用戶釋放該一個或多個密鑰。本發(fā)明的另一方面包括認證系統(tǒng)，用于通過安全存儲用戶的注冊認證數(shù)據(jù)來唯一識別用戶。該認證系統(tǒng)包括一個或多個數(shù)據(jù)存儲設備，其中每個數(shù)據(jù)存儲設備包括計算機可存取存儲介質(zhì)，其存儲注冊認證數(shù)據(jù)的至少一個部分。該認證系統(tǒng)還包括與一個或多個數(shù)據(jù)存儲設備通信的認證引擎。該認證引擎包括:數(shù)據(jù)拆分模塊，其對注冊認證數(shù)據(jù)進行操作以創(chuàng)建多個部分；數(shù)據(jù)組裝模塊，其處理來自至少一個數(shù)據(jù)存儲設備的部分以組裝注冊認證數(shù)據(jù)；以及數(shù)據(jù)比較器模塊，其從用戶接收當前認證數(shù)據(jù)，并將該當前認證數(shù)據(jù)與所組裝的注冊認證數(shù)據(jù)進行比較以確定該用戶是否已經(jīng)被唯一識別。本發(fā)明的另一方面包括加密系統(tǒng)。該加密系統(tǒng)包括一個或多個數(shù)據(jù)存儲設備，其中每個數(shù)據(jù)存儲設備包括計算機可存取存儲介質(zhì)，其存儲一個或多個加密密鑰的至少一部分。該加密系統(tǒng)還包括加密引擎，其與數(shù)據(jù)存儲設備通信。加密引擎還包括:數(shù)據(jù)拆分模塊，其對加密密鑰進行操作以創(chuàng)建多個部分；數(shù)據(jù)組裝模塊，其處理來自至少一個數(shù)據(jù)存儲設備的部分以組裝加密密鑰；以及加密處理模塊，其接收所組裝的加密密鑰并利用其執(zhí)行加密功能。本發(fā)明的另一方面包括一種在地理上遠程的安全數(shù)據(jù)存儲設備中存儲任何類型的數(shù)據(jù)(包括但不限于認證數(shù)據(jù))的方法，從而保護數(shù)據(jù)不會由任何單獨的數(shù)據(jù)存儲設備合成。該方法包括在信任引擎接收數(shù)據(jù)，在信任引擎將數(shù)據(jù)與第一基本上隨機的值結(jié)合以形成第一結(jié)合值，以及將數(shù)據(jù)與第二基本上隨機的值結(jié)合以形成第二結(jié)合值。該方法包括創(chuàng)建第一基本上隨機的值與第二結(jié)合值的第一配對，創(chuàng)建第一基本上隨機的值與第二基本上隨機的值的第二配對，以及將第一配對存儲在第一安全數(shù)據(jù)存儲設備中。該方法包括將第二配對存儲在遠離第一安全數(shù)據(jù)存儲設備的第二安全數(shù)據(jù)存儲設備中。本發(fā)明的另一方面包括一種存儲任何類型的數(shù)據(jù)(包括但不限于認證數(shù)據(jù))的方法，包括:接收數(shù)據(jù)，將該數(shù)據(jù)與第一位組(set of bits)結(jié)合以形成第二位組，以及將該數(shù)據(jù)與第三位組結(jié)合以形成第四位組。該方法還包括創(chuàng)建第一位組與第三位組的第一配對。該方法還包括創(chuàng)建第一位組與第四位組的第二配對，以及將第一配對和第二配對中的一個存儲在第一計算機可存取存儲介質(zhì)中。該方法還包括將第一配對和第二配對中的另一個存儲在第二計算機可存取存儲介質(zhì)中。本發(fā)明的另一方面包括一種將加密數(shù)據(jù)存儲在地理上遠離的安全數(shù)據(jù)存儲設備中的方法，從而保護加密數(shù)據(jù)不會由任何單獨的數(shù)據(jù)存儲設備組成。該方法包括在信任引擎接收加密數(shù)據(jù)，在信任引擎將加密數(shù)據(jù)與第一基本上隨機的值結(jié)合以形成第一結(jié)合值，以及將加密數(shù)據(jù)與第二基本上隨機的值結(jié)合以形成第二結(jié)合值。該方法還包括創(chuàng)建第一基本上隨機的值與第二結(jié)合值的第一配對，創(chuàng)建第一基本上隨機的值與第二基本上隨機的值的第二配對，以及將第一配對存儲在第一安全數(shù)據(jù)存儲設備中。該方法還包括將第二配對存儲在遠離第一安全數(shù)據(jù)存儲設備的第二安全數(shù)據(jù)存儲設備中。本發(fā)明的另一方面包括一種存儲加密數(shù)據(jù)的方法，包括接收認證數(shù)據(jù)以及將加密數(shù)據(jù)與第一位組結(jié)合以形成第二位組。該方法還包括將加密數(shù)據(jù)與第三位組結(jié)合以形成第四位組，創(chuàng)建第一位組和第三位組的第一配對，以及創(chuàng)建第一位組和第四位組的第二配對。該方法還包括在第一計算機可存取存儲介質(zhì)中存儲第一配對和第二配對中的一個，以及在第二計算機可存取存儲介質(zhì)中存儲第一配對和第二配對中的另一個。本發(fā)明的另一方面包括一種在加密系統(tǒng)中處理任何類型或形式的敏感數(shù)據(jù)的方法，其中敏感數(shù)據(jù)僅在授權用戶使用該敏感數(shù)據(jù)的動作期間以可用形式存在。該方法還包括在軟件模塊中從第一計算機可存取存儲介質(zhì)接收基本上隨機化的或加密的敏感數(shù)據(jù)，以及在該軟件模塊中從一個或多個其他計算機可存取存儲介質(zhì)接收可能是或不是敏感數(shù)據(jù)的基本上隨機化的或加密的數(shù)據(jù)。該方法還包括在軟件模塊中處理基本上隨機化的預加密敏感數(shù)據(jù)和可能是或不是敏感數(shù)據(jù)的基本上隨機化的或加密的數(shù)據(jù)以組裝敏感數(shù)據(jù)，以及在軟件引擎中使用敏感數(shù)據(jù)執(zhí)行動作。所述動作包括但不限于認證用戶和執(zhí)行加密功能之
O本發(fā)明的另一方面包括安全認證系統(tǒng)。該安全認證系統(tǒng)包括多個認證引擎。每個認證引擎接收被設計為以某個確信度唯一識別用戶的注冊認證數(shù)據(jù)。每個認證引擎接收當前認證數(shù)據(jù)以與注冊認證數(shù)據(jù)相比較，并且每個認證引擎確定認證結(jié)果。該安全認證系統(tǒng)還包括冗余系統(tǒng)，其接收至少兩個認證引擎的認證結(jié)果并確定用戶是否已被唯一識別。本發(fā)明的另一方面包 括在移動系統(tǒng)中的安全數(shù)據(jù)，借由該移動系統(tǒng)，數(shù)據(jù)能夠在根據(jù)本發(fā)明被保護的不同部分中傳輸，從而被泄露的任何一個部分都不會提供足夠數(shù)據(jù)來恢復原始數(shù)據(jù)。這可以應用于任何數(shù)據(jù)傳輸，無論其是有線、無線或物理的。本發(fā)明的另一方面包括將本發(fā)明的安全數(shù)據(jù)解析器集成到存儲或傳輸數(shù)據(jù)的任何適當系統(tǒng)中。例如，電子郵件系統(tǒng)、RAID系統(tǒng)、視頻廣播系統(tǒng)、數(shù)據(jù)庫系統(tǒng)、或任何其他適當系統(tǒng)可以具有以任何適當?shù)燃壖傻陌踩珨?shù)據(jù)解析器。本發(fā)明的另一方面包括使用任何適當?shù)慕馕龊筒鸱炙惴▉砩蓴?shù)據(jù)份(share)。隨機、偽隨機、確定的或其任意組合都可以被采用來解析和拆分數(shù)據(jù)。


下面結(jié)合附圖具體描述本發(fā)明，附圖用于示出本發(fā)明，但不用于限制本發(fā)明，其中:圖1示出了根據(jù)本發(fā)明的實施例的多個方面的加密系統(tǒng)的框圖；圖2示出了根據(jù)本發(fā)明的實施例的多個方面，圖1的信任引擎的框圖；圖3示出了根據(jù)本發(fā)明的實施例的多個方面，圖2的交易引擎的框圖；圖4示出了根據(jù)本發(fā)明的實施例的多個方面，圖2的倉庫的框圖；圖5示出了根據(jù)本發(fā)明的實施例的多個方面，圖2的認證引擎的框圖；圖6示出了根據(jù)本發(fā)明的實施例的多個方面，圖2的加密引擎的框圖；圖7示出了根據(jù)本發(fā)明的另一實施例的多個方面的倉庫系統(tǒng)的框圖；圖8示出了根據(jù)本發(fā)明的實施例的多個方面的數(shù)據(jù)拆分處理的流程圖；圖9，面A示出了根據(jù)本發(fā)明的實施例的多個方面的注冊處理的數(shù)據(jù)流；圖9,面B示出了根據(jù)本發(fā)明的實施例的多個方面的互用性(interoperability)處理的流程圖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ā)明的實施例的多個方面，在用戶和賣方之間的范例交易，其中，初始基于網(wǎng)頁的聯(lián)系引向由雙方簽署的銷售合同；圖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ā)明一個實施例的在移動系統(tǒng)中的示例性數(shù)據(jù)的框圖；圖29是根據(jù)本發(fā)明一個實施例的在移動系統(tǒng)中的另一示例性數(shù)據(jù)的框圖；圖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是用于移動數(shù)據(jù)的頭生成和數(shù)據(jù)拆分的簡化和示意性處理流程圖，其可以具有任何適當添加、刪除或修改，或以任何適當組合的形式被使用；圖41是根據(jù)本發(fā)明的一個實施例的示例性份格式的簡化框圖，其可以具有任何適當添加、刪除或修改，或以任何適當組合的形式被使用；圖42是根據(jù)本發(fā)明的一個實施例的用于管理加密密鑰的示例性步驟和特征的處理流程圖，其可以具有任何適當添加、刪除或修改，或以任何適當組合的形式被使用。
具體實施例方式本發(fā)明的一個方面提供一種加密系統(tǒng)，其中一個或多個安全服務器或信任引擎存儲加密密鑰和用戶認證數(shù)據(jù)。用戶通過對信任引擎的網(wǎng)絡訪問來訪問傳統(tǒng)加密系統(tǒng)的功能，然而，信任引擎不釋放實際密鑰和其他認證數(shù)據(jù)，因此，密鑰和數(shù)據(jù)保持安全。密鑰和認證數(shù)據(jù)的這種服務器中心存儲提供用戶無關的安全性、便攜性、可用性以及簡單性。因為用戶能夠確信或信任該加密系統(tǒng)來執(zhí)行用戶和文檔認證以及其他加密功能，所以廣泛的各種功能可以被結(jié)合到該系統(tǒng)中。例如，信任引擎提供者可以通過例如認證協(xié)定參與者、以參與者的名義或者為參與者數(shù)字簽署協(xié)定、以及存儲由每個參與者數(shù)字簽署的協(xié)定的記錄，來確保防備協(xié)定抵賴(repudiation)。此外，該加密系統(tǒng)可以監(jiān)視協(xié)定并基于例如價格、用戶、賣方、地理位置、使用地點等來確定應用不同程度的認證。為了便于完全理解本發(fā)明，具體實施方式
的余下部分參考附圖描述本發(fā)明，其中通篇，類似的部件使用類似的標號來表示。圖1示出了根據(jù)本發(fā)明的實施例的多個方面的加密系統(tǒng)100的框圖。如圖1所示，加密系統(tǒng)100包括通過通信鏈路125進行通信的用戶系統(tǒng)105、信任引擎110、證書頒發(fā)機構(gòu)(certificate authority) 115、以及賣方系統(tǒng) 120。根據(jù)本發(fā)明的一個實施例，用戶系統(tǒng)105包括傳統(tǒng)通用目的計算機，其具有一個或多個微處理器，例如基于Intel的處理器。此外,用戶系統(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 IMAGEGENERA0R”的美國專利申請N0.08/926，277、2000年4月26日提交的標題為“IMAGINGDEVICE FOR A RELIEF 0BJECTAND SYSTEM AND METHOD OF USING THE IMAGE DEVICE” 的美國專利申請N0.09/558，634、1999年11月5日提交的標題為“RELIEF OBJECT SENSORADAPTOR”的美國專利申請N0.09/435，011、以及2000年I月5日提交的標題為“PLANAROPTICAL IMAGE SENSOR AND SYSTEM FOR GENERATING AN ELECTRONIC IMAGE OF A RELIEFOBJECT FORFINGERPRINT READING”的美國專利申請N0.09/477, 943中公開的那些屬性和特征的裝置，所有這些專利由當前受讓人所有，以及全部通過引用結(jié)合于此。此外，用戶系統(tǒng)105可以通過傳統(tǒng)業(yè)務提供商，例如，撥號、數(shù)字訂戶線路(DSL)、有線調(diào)制解調(diào)器、光纖連接等等，連接到通信鏈路125。根據(jù)另一實施例，用戶系統(tǒng)105通過諸如局域網(wǎng)或廣域網(wǎng)之類的網(wǎng)絡連接而連接通信鏈路125。根據(jù)一個實施例，操作系統(tǒng)包括TCP/IP棧，其處理在通信鏈路125上傳遞的所有輸入和輸出消息業(yè)務。盡管參考上述實施例描述了用戶系統(tǒng)105，但是本發(fā)明不因此而被限制。相反，本領域技術人員由此處的披露應該意識到用戶系統(tǒng)105的大量可替換實施例，包括能夠發(fā)送信息至另一計算機系統(tǒng)或從另一計算機系統(tǒng)接收信息的幾乎任何計算裝置。例如，用戶系統(tǒng)105可以包括但不限于，能夠與通信鏈路125交互的計算機工作站、交互式電視、交互式信息站、個人移動計算裝置(諸如數(shù)字助理、移動電話、膝上型電腦等等)、無線通信裝置、智能卡、嵌入式計算裝置等等。在這樣的可替換系統(tǒng)中，操作系統(tǒng)很可能不同，并且適于特定裝置。然而，根據(jù)一個實施例，操作系統(tǒng)有利地繼續(xù)提供與通信鏈路建立通信所需的適當?shù)耐ㄐ艆f(xié)議。圖1示出了信任引擎110。根據(jù)一個實施例，該信任引擎110包括用于訪問和存儲敏感信息的一個或多個安全服務器，敏感信息可以是任何類型或形式的數(shù)據(jù)，諸如但不限于文本、音頻、視頻、用戶認證數(shù)據(jù)以及公共和私有加密密鑰。根據(jù)一個實施例，認證數(shù)據(jù)包括被設計為唯一識別加密系統(tǒng)100的用戶的數(shù)據(jù)。例如，認證數(shù)據(jù)可以包括用戶標識號、一個或多個生物識別信息、以及由信任引擎100或用戶生成但由用戶在注冊時初始回答的一系列問題和答案。上述問題可以包括諸如出生地、地址、周年紀念之類的人口統(tǒng)計數(shù)據(jù)，諸如母親的娘家姓、最喜歡的冰激凌之類的個人數(shù)據(jù)，或被設計為唯一識別用戶的其他數(shù)據(jù)。信任引擎110將與當前交易相關聯(lián)的用戶的認證數(shù)據(jù)與較早時候(例如注冊期間)提供的認證數(shù)據(jù)進行比較。信任引擎110可以有利地要求用戶在每次交易時產(chǎn)生認證數(shù)據(jù)，或者，信任引擎110可以有利地允許用戶周期性地產(chǎn)生認證數(shù)據(jù)，例如在一串交易的開始或在登錄到特定賣方網(wǎng)站時。根據(jù)用戶產(chǎn)生生物識別數(shù)據(jù)的實施例，用戶向生物識別裝置107提供身體特征，諸如但不限于臉部掃描、手掃描、耳朵掃描、虹膜掃描、視網(wǎng)膜掃描、血管模式、DNA、指紋、筆跡、或語音。生物識別裝置有利地產(chǎn)生身體特征的電子圖案或生物識別信息。電子圖案通過用戶系統(tǒng)105被傳遞至信任引擎110用于注冊或認證目的。一旦用戶產(chǎn)生適當?shù)恼J證數(shù)據(jù)并且信任引擎110確定認證數(shù)據(jù)(當前認證數(shù)據(jù))與在注冊時提供的認證數(shù)據(jù)(注冊認證數(shù)據(jù))之間的肯定匹配，則信任引擎110向用戶提供完全的加密功能。例如，被正確認證的用戶可以有利地使用信任引擎110來執(zhí)行散列、數(shù)字簽名、加密和解密(通常一起僅稱為加密)、創(chuàng)建或分發(fā)數(shù)字證書、等等。然而，用在加密功能中的私有加密密鑰在信任引擎110之外不可用，因此保證加密密鑰的完整性。根據(jù)一個實施例，信任引擎110生成并存儲加密密鑰。根據(jù)另一實施例，至少一個加密密鑰與每個用戶相關聯(lián)。此外，當加密密鑰包括公鑰技術時，與用戶相關的每個私鑰在信任引擎110中生成，而不從其釋放。因此，只要用戶已經(jīng)訪問了信任引擎110，用戶就可以使用他或她的私鑰或公鑰執(zhí)行加密功能。這樣的遠程訪問有利地允許用戶保留完全的移動性，以及通過實際中的任何因特網(wǎng)連接(例如蜂窩和衛(wèi)星電話、信息站、膝上型電腦、賓館房間等)訪問加密功能。根據(jù)另一實施例，信任引擎110使用為信任引擎110生成的密鑰對來執(zhí)行加密功能。根據(jù)該實施例，信任引擎110首先認證該用戶，然后在用戶已經(jīng)正確產(chǎn)生與注冊認證數(shù)據(jù)匹配的認證數(shù)據(jù)之后，信任引擎110使用其本身的加密密鑰對，以被認證的用戶的名義執(zhí)行加密功能。本領域的技術人員從此處的公開應意識到，加密密鑰可以有利地包括一些或所有對稱密鑰、公鑰和私鑰。此外，本領域的技術人員從此處的公開應意識到，上述密鑰可以使用諸如RSA、ELGAMAL等商業(yè)技術提供的多種算法來實現(xiàn)。圖1還示出了證書頒發(fā)機構(gòu)115。根據(jù)一個實施例，證書頒發(fā)機構(gòu)115可以有利地包括發(fā)布數(shù)字證書的可信的第三方組織或公司，例如，VeriSign, Baltimore, Entrust等等。信任引擎110可以有利地通過一個或多個傳統(tǒng)數(shù)字證書協(xié)議(例如PKCS10)向證書頒發(fā)機構(gòu)115發(fā)送數(shù)字證書請求。作為響應，證書頒發(fā)機構(gòu)115將以多種不同協(xié)議中的一種或多種發(fā)布數(shù)字證書，例如PKCS7。根據(jù)本發(fā)明的一個實施例，信任引擎110從多個或所有著名的證書頒發(fā)機構(gòu)115請求數(shù)字證書，從而信任引擎110能夠使用與任何請求方的證書標準相對應的數(shù)字證書。根據(jù)另一實施例，信任引擎110在內(nèi)部執(zhí)行證書發(fā)布。在該實施例中，信任引擎110可以訪問證書系統(tǒng)以生成證書和/或可以在證書被請求時，例如在密鑰生成時，或者以請求時所請求的證書標準，在內(nèi)部生成證書。下面將更加詳細地披露信任引擎110。圖1還示出了賣方系統(tǒng)120。根據(jù)一個實施例，賣方系統(tǒng)120有利地包括Web服務器。典型的Web服務器通常使用多種互聯(lián)網(wǎng)標記語言或文檔格式標準(例如超文本標記語言(HTML)或可擴展標記語言(XML))中的一種在因特網(wǎng)上提供內(nèi)容。Web服務器接受來自諸如Netscape和Internet Explorer之類的瀏覽器的請求,然后返回適當?shù)碾娮游臋n。多種服務器或客戶端技術可以用來在傳遞標準電子文檔的能力之外增加Web服務器的能力。例如，這些技術包括公共網(wǎng)關接口(CGI)腳本、安全套接字層(SSL)安全、以及動態(tài)服務器網(wǎng)頁(ASP)。賣方系統(tǒng)120可以有利地提供關于商業(yè)、個人、教育或其他交易的電子內(nèi)容。盡管參考上面實施例披露了賣方系統(tǒng)120，但是本發(fā)明不因此被限制。相反，本領域技術人員應該從此處的公開意識到，賣方系統(tǒng)120可以有利地包括參考用戶系統(tǒng)105描述的任何裝置或其組合。圖1還示出了連接用戶系統(tǒng)105、信任引擎110、證書頒發(fā)機構(gòu)115和賣方系統(tǒng)120的通信鏈路125。根據(jù)一個實施例，通信鏈路125優(yōu)選地包括因特網(wǎng)。如在整個公開中所使用的，因特網(wǎng)是計算機的全球網(wǎng)絡。本領域普通技術人員公知的因特網(wǎng)的結(jié)構(gòu)包括網(wǎng)絡骨干(network backbone),以及從骨干分支的網(wǎng)絡。這些分支又具有從它們分支的網(wǎng)絡,如此等等。路由器在網(wǎng)絡級之間移動信息包，然后從網(wǎng)絡至網(wǎng)絡，直到包到達其目的地附近。從該目的地，目的地網(wǎng)絡的主機將該信息包引向適當?shù)慕K端或節(jié)點。在一個有利的實施例中，因特網(wǎng)路由集線器包括本領域公知的使用傳輸控制協(xié)議/網(wǎng)際協(xié)議(TCP/IP)的域名系統(tǒng)(DNS)服務器。路由集線器通過高速通信鏈路連接到一個或多個其他路由集線器。因特網(wǎng)的一個普及部分是萬維網(wǎng)。萬維網(wǎng)包括不同的計算機，其存儲能夠顯示圖形或文本信息的文件。在萬維網(wǎng)上提供信息的計算機通常被稱作“網(wǎng)站”。網(wǎng)站由具有相關電子頁面的因特網(wǎng)地址定義。電子頁面可以由統(tǒng)一資源定位符(URL)標識。通常，電子頁面是組織文本、圖形圖像、音頻、視頻等的呈現(xiàn)的文檔。盡管通信鏈路125以其優(yōu)選實施例被公開，但是本領域的技術人員應該從在此的公開意識到，通信鏈路125可以包括廣泛的交互通信鏈路。例如，通信鏈路125可以包括交互式電視網(wǎng)絡、電話網(wǎng)絡、無線數(shù)據(jù)傳輸系統(tǒng)、雙向電纜系統(tǒng)、定制的私有或公共計算機網(wǎng)絡、交互式信息站網(wǎng)絡、自動柜員機網(wǎng)絡、直接鏈路、衛(wèi)星或蜂窩網(wǎng)絡、等等。圖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文檔至對應于接收裝置的IP地址。如上所述，XML文檔有利地允許設計者創(chuàng)建其自身的定制文檔標簽，使得能夠在應用程序之間和組織之間定義、傳輸、驗證和解釋數(shù)據(jù)。此外，上述通信中的一些或所有可以包括傳統(tǒng)SSL技術。根據(jù)一個實施例,交易引擎205包括數(shù)據(jù)路由裝置,諸如由Netscape、Microsoft、Apache等提供的傳統(tǒng)Web服務器。例如，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可以有利地將數(shù)據(jù)路由至用戶系統(tǒng)105、證書頒發(fā)機構(gòu)115或賣方系統(tǒng)120。根據(jù)一個實施例，數(shù)據(jù)使用傳統(tǒng)HTTP路由技術被路由，例如采用URL或統(tǒng)一資源指示符(URI)。URI類似于URL，然而，URI通常指示文件或動作的源，例如，可執(zhí)行文件、腳本等。因此，根據(jù)一個實施例，用戶系統(tǒng)105、證書頒發(fā)機構(gòu)115、賣方系統(tǒng)120、以及信任引擎210的部件有利地包括通信URL或URI中的足夠數(shù)據(jù)以便交易引擎205在加密系統(tǒng)中正確地路由數(shù)據(jù)。盡管參考其優(yōu)選實施例公開了數(shù)據(jù)路由，但是本領域的技術人員應該意識到大量的可行的數(shù)據(jù)路由解決方案或策略。例如，XML或其他數(shù)據(jù)包可以有利地通過其格式、內(nèi)容等被拆包和識別，從而交易引擎205可以在信任引擎110中正確地路由數(shù)據(jù)。此外，本領域技術人員應該意識到，數(shù)據(jù)路由可以有利地適應符合特定網(wǎng)絡系統(tǒng)——例如當通信鏈路125包括局域網(wǎng)時-的數(shù)據(jù)傳輸協(xié)議。根據(jù)本發(fā)明的另一實施例，交易引擎205包括傳統(tǒng)SSL加密技術，從而上述系統(tǒng)可以在特定通信期間使用交易引擎205認證自身，反之亦然。如在整個公開中所使用的，術語“1/2SSL”表示服務器被SSL認證而客戶端不一定被SSL認證的通信，術語“全SSL”表示客戶端和服務器都被SSL認證的通信。在當前公開使用術語“SSL”時，通信可以包括1/2或全 SSL。當交易引擎205將數(shù)據(jù)路由至加密系統(tǒng)100的各部件時，交易引擎205可以有利地創(chuàng)建審計跟蹤(audit trail)。根據(jù)一個實施例，審計跟蹤包括至少關于由交易引擎205在加密系統(tǒng)100中路由的數(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之間的通信包括安全通信，例如，傳統(tǒng)SSL技術。此外，如上所述，往返于倉庫210的通信的數(shù)據(jù)可以使用URL、UR1、HTTP或XML文檔傳遞，它們有利地將數(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ù)存儲設備的泄密僅僅產(chǎn)生隨機的不可破譯的數(shù)字并且不損害作為整體的加密密鑰或認證數(shù)據(jù)的安全性。圖2還示出了信任引擎110包括認證引擎215。根據(jù)一個實施例，認證引擎215包括數(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ù)轉(zhuǎn)發(fā)至認證引擎215。從而，認證引擎215具有當前認證數(shù)據(jù)和注冊認證數(shù)據(jù)這兩者以供比較。根據(jù)一個實施例，至認證引擎的通信包括安全通信，諸如SSL技術。此外，可以在信任引擎110部件中提供安全性，例如使用公鑰技術的超級加密。例如，根據(jù)一個實施例，用戶使用認證引擎215的公鑰來加密當前認證數(shù)據(jù)。此外，倉庫210還使用認證引擎215的公鑰來加密注冊認證數(shù)據(jù)。以該方式，只有認證引擎的私鑰可以被用來解密該傳輸。如圖2中所示，信任引擎110還包括加密引擎220。根據(jù)一個實施例，加密引擎包括加密處理模塊，其被配置為有利地提供傳統(tǒng)加密功能，諸如公鑰基礎結(jié)構(gòu)(PKI)功能。例如，加密引擎220可以有利地發(fā)布用于加密系統(tǒng)100的用戶的公鑰和私鑰。以該方式，加密密鑰在加密引擎220處生成，并被轉(zhuǎn)發(fā)至倉庫210，從而至少私有加密密鑰在信任引擎110外部不可用。根據(jù)另一實施例，加密引擎220至少隨機化并拆分私有加密密鑰數(shù)據(jù)，從而僅存儲隨機化的拆分的數(shù)據(jù)。類似于注冊認證數(shù)據(jù)的拆分，拆分處理保證所存儲的密鑰在加密引擎220的外部不可用。根據(jù)另一實施例，加密引擎的功能可以與認證引擎215結(jié)合并由其執(zhí)行。根據(jù)一個實施例，往返于加密引擎的通信包括安全通信，諸如SSL技術。此外，XML文檔可以有利地被用于傳遞數(shù)據(jù)和/或進行加密功能請求。圖2還示出了信任引擎110具有大容量存儲器225。如上所述，交易引擎205保持對應于審計跟蹤的數(shù)據(jù)，并將這樣的數(shù)據(jù)存儲在大容量存儲器225中。類似地，根據(jù)本發(fā)明的一個實施例，倉庫210保持對應于審計跟蹤的數(shù)據(jù)并將這樣的數(shù)據(jù)存儲在大容量存儲裝置225中。倉庫審計跟蹤數(shù)據(jù)類似于交易引擎205的審計跟蹤數(shù)據(jù)，因為審計跟蹤數(shù)據(jù)包括由倉庫210接收的請求的記錄及其響應。此外，大容器存儲器225可以被用來存儲其中包含有用戶公鑰的數(shù)字證書。盡管參考其優(yōu)選和可替換實施例公開了信任引擎110，但本發(fā)明不因此被限制。相反，本領域技術人員在此處的公開中應該意識到信任引擎110的大量替換例。例如，信任引擎110可以有利地僅執(zhí)行認證，或可替換地，僅執(zhí)行部分或全部加密功能，諸如數(shù)據(jù)加密和解密。根據(jù)這樣的實施例，認證引擎215和加密引擎220之一可以有利地被去除，從而創(chuàng)建更加簡單的信任引擎110設計。此外，加密引擎220還可以與證書頒發(fā)機構(gòu)通信，從而證書頒發(fā)機構(gòu)被包括在信任引擎110中。根據(jù)另一實施例，信任引擎110可以有利地執(zhí)行認證和一個或多個加密功能，例如數(shù)字簽名。圖3示出了根據(jù)本發(fā)明的實施例的多個方面，圖2的交易引擎205的框圖。根據(jù)該實施例，交易引擎205包括具有處理線程和監(jiān)聽線程的操作系統(tǒng)305。操作系統(tǒng)305可以有利地類似于在傳統(tǒng)大容量服務器中的那些操作系統(tǒng)，例如由Apache提供的Web服務器。監(jiān)聽線程監(jiān)視來自通信鏈路125、認證引擎215、以及加密引擎220之一的輸入通信中的輸入數(shù)據(jù)流。處理線程識別輸入數(shù)據(jù)流的特定數(shù)據(jù)結(jié)構(gòu)，例如前述的數(shù)據(jù)結(jié)構(gòu)，從而將輸入數(shù)據(jù)路由至通信鏈路125、倉庫210、認證引擎215、加密引擎220、或大容量存儲器225之一。如圖3所示，輸入和輸出數(shù)據(jù)可以有利地通過例如SSL技術而被保護。圖4示出了根據(jù)本發(fā)明的實施例的多個方面的圖2的倉庫210的框圖。根據(jù)該實施例，倉庫210包括一個或多個輕量級目錄訪問協(xié)議(LDAP)服務器。LDAP目錄服務器可以由多個制造商提供，諸如Netscape、ISO和其他制造商。圖4還示出，目錄服務器優(yōu)選存儲對應于加密密鑰的數(shù)據(jù)405和對應于注冊認證數(shù)據(jù)的數(shù)據(jù)410。根據(jù)一個實施例，倉庫210包括單個邏輯存儲結(jié)構(gòu)，其將認證數(shù)據(jù)和加密密鑰數(shù)據(jù)索引至唯一用戶ID。該單個邏輯存儲結(jié)構(gòu)優(yōu)選地包括保證存儲在其中的數(shù)據(jù)具有高信任度或安全性的機制。例如，倉庫210的物理位置可以有利地包括多種傳統(tǒng)安全措施，諸如有限的雇員訪問、現(xiàn)代監(jiān)視系統(tǒng)等。在物理安全措施之外或取而代之，計算機系統(tǒng)或服務器可以有利地包括軟件解決方案來保護存儲的數(shù)據(jù)。例如，倉庫210可以有利地創(chuàng)建并存儲與所執(zhí)行的動作的審計跟蹤相對應的數(shù)據(jù)415。此外，輸入和輸出通信可以有利地使用與傳統(tǒng)SSL技術相結(jié)合的公鑰加密來加
LU O根據(jù)另一實施例，倉庫210可以包括不同的且物理上分開的數(shù)據(jù)存儲設備，如進一步參考圖7所述。圖5示出了根據(jù)本發(fā)明的實施例的多個方面，圖2的認證引擎215的框圖。類似于圖3的交易引擎205，認證引擎215包括操作系統(tǒng)505，其至少具有傳統(tǒng)Web服務器(例如Apache提供的Web服務器)的修改版本的監(jiān)聽和處理線程。如圖5所示，認證引擎215包括對至少一個私鑰510的訪問。私鑰510可以有利地被用來例如解密來自交易引擎205或倉庫210的使用認證引擎215的相應公鑰加密過的數(shù)據(jù)。圖5還示出了認證引擎215包括比較器515、數(shù)據(jù)拆分模塊529、以及數(shù)據(jù)組裝模塊525。根據(jù)本發(fā)明的優(yōu)選實施例，比較器515包括能夠比較與上述生物識別認證數(shù)據(jù)有關的可能復雜的圖案的技術。該技術可以包括用于圖案比較的硬件、軟件或其組合方案，所述圖案諸如是表示指紋圖案或語音圖案的那些圖案。此外，根據(jù)一個實施例，認證引擎215的比較器515可以有利地比較文檔的傳統(tǒng)散列值以給出比較結(jié)果。根據(jù)本發(fā)明的一個實施例，比較器515包括將試探法(heuristics) 530應用于比較。試探法530可以有利地處理圍繞認證嘗試的詳情，例如一天中的時間、IP地址或子網(wǎng)掩碼、購買簡檔、電子郵件地址、處理器序列號或ID、等等。此外，生物識別數(shù)據(jù)比較的特性可能使得由當前生物識別認證數(shù)據(jù)與注冊數(shù)據(jù)的匹配產(chǎn)生變化的可信度。例如，與可能僅返回肯定或否定匹配的傳統(tǒng)口令不同，指紋可能被確定為是部分匹配，例如，90%匹配、75%匹配或10%匹配，而不是簡單地正確或不正確。諸如聲紋分析或面貌識別之類的其他生物識別標識也可以具有該概率認證性質(zhì)，而不是絕對認證。當使用這樣的概率認證或者在認證被認為并非絕對可靠的情況下，希望應用試探法530來確定所提供的認證中的可信度是否足夠高到能夠認證正在進行的交易。 有時候的情況是，待解決的交易是相對低價值的交易，其中被認證為較低可信度是可以接受的。這可能包括與其相關的美金值較低的交易(例如，$10購買)或具有較低風險的交易(例如，僅會員可進的網(wǎng)站)。相反，為了認證其他交易，希望在允許交易進行之前要求認證的高可信度。這樣的交易可能包括大額美金值的交易(例如，簽訂幾百萬美金供應合同)或如果發(fā)生不正確的認證會具有高風險的交易(例如遠程登錄至政府計算機)。下面將描述使用試探法530與可信度和交易值結(jié)合，以允許比較器提供動態(tài)的上下文相關的認證系統(tǒng)。根據(jù)本發(fā)明的另一實施例，比較器515可以有利地跟蹤對于特定交易的認證嘗試。例如，當交易失敗時，信任引擎110可以請求用戶重新輸入他或她的當前認證數(shù)據(jù)。認證引擎215的比較器515可以有利地使用嘗試限制器535來限制認證嘗試的次數(shù)，從而禁止試圖模仿用戶的認證數(shù)據(jù)的暴力嘗試。根據(jù)一個實施例，嘗試限制器535包括監(jiān)視交易中的重復認證嘗試并例如將對于給定交易的認證嘗試限制為三次的軟件模塊。因此，嘗試限制器535將限制模仿個體的認證數(shù)據(jù)的自動化嘗試，例如簡單的三次“guesses”。一旦三次失敗，嘗試限制器535可以有利地拒絕追加的認證嘗試。這樣的拒絕可以有利地通過例如不管被傳輸?shù)漠斍罢J證數(shù)據(jù)是什么，比較器515都返回否定結(jié)果來實現(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)Web服務器(例如，Apache提供的Web服務器)的修改版本的監(jiān)聽線程和處理線程。如圖6中所示，加密引擎220包括數(shù)據(jù)拆分模塊610和數(shù)據(jù)組裝模塊620，其功能類似于圖5中的那些模塊。然而，根據(jù)一個實施例，數(shù)據(jù)拆分模塊610和數(shù)據(jù)組裝模塊620處理加密密鑰數(shù)據(jù)，不同于上述注冊認證數(shù)據(jù)。盡管如此，本領域技術人員從此處的公開應意識到數(shù)據(jù)拆分模塊610和數(shù)據(jù)組裝模塊620可以與認證引擎215的數(shù)據(jù)拆分模塊和數(shù)據(jù)組裝模塊結(jié)
口 ο加密引擎220還包括加密處理模塊625，其被配置為執(zhí)行大量加密功能中的一個、部分或所有。根據(jù)一個實施例，加密處理模塊625可以包括軟件模塊或程序、硬件、或兩者。根據(jù)另一實施例，加密處理模塊625可以執(zhí)行數(shù)據(jù)比較、數(shù)據(jù)解析、數(shù)據(jù)拆分、數(shù)據(jù)分離、數(shù)據(jù)散列、數(shù)據(jù)加密或解密、數(shù)字簽名校驗或創(chuàng)建、數(shù)字證書的生成、存儲或請求、加密密鑰生成、等等。此外，本領域技術人員應該從在此處的公開意識到，加密處理模塊625可以有利地包括公鑰基礎結(jié)構(gòu)，諸如優(yōu)秀保密(Pretty Good Privacy，PGP)、基于RSA的公鑰系統(tǒng)、或大量可替換的密鑰管理系統(tǒng)。此外，加密處理模塊625可以執(zhí)行公鑰加密、對稱密鑰加密、或兩者。除了上面所述，加密處理模塊625可以包括一個或多個計算機程序或模塊、硬件、或兩者，用于實現(xiàn)無縫、透明、互用性功能。本領域的技術人員從在此的公開還應該意識到，加密功能可以包括通常與加密密鑰管理系統(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與交易引擎205、認證引擎215、以及加密引擎220通信，優(yōu)選通過傳統(tǒng)SSL通信。通信鏈路傳輸例如XML文檔。來自交易引擎205的通信可以有利地包括對數(shù)據(jù)的請求，其中該請求被有利地廣播至每個數(shù)據(jù)存儲設備Dl至D4的IP地址。另一方面，交易引擎205可以基于諸如響應時間、服務器負荷、維護計劃等大量標準而將請求廣播至特定數(shù)據(jù)存儲設備。響應于來自交易引擎205的對于數(shù)據(jù)的請求，倉庫系統(tǒng)700有利地轉(zhuǎn)發(fā)所存儲的數(shù)據(jù)至認證引擎215和加密引擎220。各個數(shù)據(jù)組裝模塊接收轉(zhuǎn)發(fā)的數(shù)據(jù)并將數(shù)據(jù)組裝成可用格式。另一方面，從認證引擎215和加密引擎220到數(shù)據(jù)存儲設備Dl至D4的通信可以包括傳輸要存儲的敏感數(shù)據(jù)。例如，根據(jù)一個實施例，認證引擎215和加密引擎220可以有利地使用其各自的數(shù)據(jù)拆分模塊以將敏感數(shù)據(jù)分解成不可破譯的部分，然后將敏感數(shù)據(jù)的一個或多個不可破譯的部分傳輸至特定數(shù)據(jù)存儲設備。根據(jù)一個實施例，每個數(shù)據(jù)存儲設備Dl至D4包括分開且獨立的存儲系統(tǒng)，例如目錄服務器。根據(jù)本發(fā)明的另一實施例，倉庫系統(tǒng)700包括多個地理上分開的獨立的數(shù)據(jù)存儲系統(tǒng)。通過將敏感數(shù)據(jù)分發(fā)至不同且獨立的存儲設備Dl至D4—其中部分或所有存儲設備可以有利地在地理上分開，倉庫系統(tǒng)700與其他安全措施一起提供冗余。例如，根據(jù)一個實施例，僅來自多個數(shù)據(jù)存儲設備Dl至D4中的兩個數(shù)據(jù)存儲設備的數(shù)據(jù)需要解密并重新組裝該敏感數(shù)據(jù)。因此，四個數(shù)據(jù)存儲設備Dl至D4中的兩個數(shù)據(jù)存儲設備可以由于維護、系統(tǒng)故障、電源故障等而不工作，但不影響信任引擎110的功能。此外，因為根據(jù)一個實施例，存儲在每個數(shù)據(jù)存儲設備中的數(shù)據(jù)被隨機化并不可破譯，所以任何單個數(shù)據(jù)存儲設備的泄密不必然地泄露敏感數(shù)據(jù)。此外，在數(shù)據(jù)存儲設備地理上分開的實施例中，多個地理上遠離的設備的泄密變得越發(fā)困難。事實上，不良員工要暗中破壞所需的多個獨立的地理上遠離的數(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所示，數(shù)據(jù)拆分處理800在步驟805處開始，此時敏感數(shù)據(jù)“S”由認證引擎215或加密引擎220的數(shù)據(jù)拆分模塊接收。優(yōu)選地，在步驟810，數(shù)據(jù)拆分模塊然后生成基本上隨機的數(shù)、值、或串、或位組“A”。例如，隨機數(shù)A可以用本領域技術人員已知的用于產(chǎn)生適于在加密應用中使用的高質(zhì)量隨機數(shù)的多種不同傳統(tǒng)技術生成。此外，根據(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結(jié)合，從而生成新的數(shù)“B”和“D”。例如，數(shù)B可以包括A XOR S的二進制結(jié)合，數(shù)D可以包括C XOR S的二進制結(jié)合。XOR函數(shù)或“異或”函數(shù)對于本領域的技術人員是已知的。上述結(jié)合優(yōu)選地分別發(fā)生在步驟825和830，以及根據(jù)一個實施例，上述結(jié)合還并行發(fā)生。數(shù)據(jù)拆分處理800然后進行到步驟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ù)的信任的維持，即使數(shù)據(jù)存儲設備Dl至D4之一被泄密。盡管參考其優(yōu)選實施例公開了數(shù)據(jù)拆分處理800，本發(fā)明不因此被限制。相反，本領域的技術人員應從此處的公開意識到數(shù)據(jù)拆分處理800的多種替換。例如，數(shù)據(jù)拆分處理可以有利地將數(shù)據(jù)拆分成兩個數(shù)，例如，隨機數(shù)A和數(shù)B，并且通過兩個數(shù)據(jù)存儲設備隨機分配A和B。此外，數(shù)據(jù)拆分處理800可以有利地通過生成另外的隨機數(shù)而在大量數(shù)據(jù)存儲設備中拆分數(shù)據(jù)。數(shù)據(jù)可以被拆分成任何期望的、選擇的、預定的或隨機分配的尺寸單元，包括但不限于一位、多位、字節(jié)、千字節(jié)、兆字節(jié)或更大、或尺寸的任何組合或序列。此夕卜，由拆分處理導致的改變數(shù)據(jù)單元的尺寸可以使得數(shù)據(jù)更難以恢復成可用形式，從而增加敏感數(shù)據(jù)的安全性。本領域的普通技術人員容易理解，拆分數(shù)據(jù)單元的尺寸可以是多種不同的數(shù)據(jù)單元尺寸或尺寸的圖樣(pattern)或尺寸的組合。例如，數(shù)據(jù)單元尺寸可以被選擇或預定為都具有相同的尺寸、具有不同尺寸的固定的組、尺寸的組合、或隨機生成尺寸。類似地，數(shù)據(jù)單元可以根據(jù)固定或預定的數(shù)據(jù)單元尺寸、數(shù)據(jù)單元尺寸的圖樣或組合、或隨機生成的數(shù)據(jù)單元尺寸或每份的尺寸而被分配成一份或多份。如上所述，為了重建敏感數(shù)據(jù)S，數(shù)據(jù)部分需要被解隨機和重新組織。該處理可以有利地分別發(fā)生在認證引擎215和加密引擎220的數(shù)據(jù)組裝模塊525和620中。數(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=A XOR B或S=C XOR D表示當數(shù)據(jù)組裝模塊接收A和B或C和D之一時，數(shù)據(jù)組裝模塊525可以有利地重新組裝敏感數(shù)據(jù)S。因此，數(shù)據(jù)組裝模塊525可以在例如接收到來自數(shù)據(jù)存儲設備Dl至D4中至少前兩個的數(shù)據(jù)部分時，組裝敏感數(shù)據(jù)S，以響應于信任引擎110的組裝請求。基于上述的數(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ù)拆分模塊也是本發(fā)明的單獨且獨立的實施例，可以合并到包括任何已有計算機系統(tǒng)、軟件套件、數(shù)據(jù)庫、或其組合、或本發(fā)明的其他實施例(諸如在此公開和描述的信任引擎、認證引擎以及交易引擎)中，或與之結(jié)合，或作為其中一部分。圖9A示出了根據(jù)本發(fā)明的實施例的多個方面的注冊處理900的數(shù)據(jù)流。如圖9A所示，注冊處理900在步驟905處開始，用戶期望使用加密系統(tǒng)100的信任引擎110注冊。根據(jù)該實施例，用戶系統(tǒng)105有利地包括例如基于Java的客戶端小程序(applet),其詢問用戶以輸入注冊數(shù)據(jù)，例如人口統(tǒng)計數(shù)據(jù)和注冊認證數(shù)據(jù)。根據(jù)一個實施例，注冊認證數(shù)據(jù)包括用戶ID、口令、生物識別信息等。根據(jù)一個實施例，在詢問處理過程中，客戶端小程序優(yōu)選地與信任引擎110通信以保證所選擇的用戶ID是唯一的。當用戶ID非唯一時，信任引擎110可以有利地建議唯一用戶ID?？蛻舳诵〕绦蚴占詳?shù)據(jù)并將注冊數(shù)據(jù)例如通過XML文檔傳輸至信任引擎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)。如本領域技術人員從此處的公開可以理解的，用戶可以具有許多身份，例如，一家之主的JoeUser，慈善基金會成員Joe User，等等。即使用戶可以具有多個身份，根據(jù)該實施例，信任引擎110優(yōu)選地僅存儲一組注冊數(shù)據(jù)。此外，用戶可以根據(jù)他們的需要有利地增加、編輯/更新、或刪除身份。盡管參考其優(yōu)選實施例公開了注冊處理900，但是本發(fā)明不因此被限制。相反，本領域技術人員從此處的公開應理解用于收集注冊數(shù)據(jù)尤其是注冊認證數(shù)據(jù)的多種替換例。例如，小程序可以是基于通用對象模型(COM)的小程序，等等。另一方面，注冊處理可以包括分級注冊。例如，在最低級的注冊中，用戶可以通過通信鏈路125注冊而不產(chǎn)生關于他或她身份的文件。根據(jù)注冊等級的提高，用戶使用諸如數(shù)字公證之類的可信第三方進行注冊。例如，用戶可以親自出現(xiàn)在可信第三方面前，制作諸如出生證明、駕照、軍人ID等，以及可信第三方可以有利地在注冊提交時包括例如他們的數(shù)字簽名。可信第三方可以包括實際公證處、政府機構(gòu)(例如郵局或機動車部)、大公司中注冊員工的人力資源人員等。本領域的技術人員從此處的公開應該理解在注冊處理900中可能發(fā)生多種不同等級的注冊。在步驟915處接收注冊認證數(shù)據(jù)之后，交易引擎205使用傳統(tǒng)全SSL技術將注冊認證數(shù)據(jù)轉(zhuǎn)發(fā)至認證引擎215。在步驟920，認證引擎215使用認證引擎215的私鑰解密注冊認證數(shù)據(jù)。此外，認證引擎215使用數(shù)據(jù)拆分模塊對注冊認證數(shù)據(jù)進行數(shù)學運算，從而將數(shù)據(jù)拆分成至少兩個獨立的不可破譯的隨機化的數(shù)。如上所述，至少兩個數(shù)可以包括統(tǒng)計隨機的數(shù)和二進制異或的數(shù)。在步驟925，認證引擎215將隨機化的數(shù)的每個部分轉(zhuǎn)發(fā)給數(shù)據(jù)存儲設備Dl至D4之一。如上所述，認證引擎215還可以有利地隨機化哪些部分被傳遞到哪些倉庫。通常在注冊處理900的過程中，用戶還期望發(fā)布數(shù)字證書，從而他或她可以接收來自加密系統(tǒng)100外部的其他系統(tǒng)的加密文檔。如上所述，證書頒發(fā)機構(gòu)115通常根據(jù)多種傳統(tǒng)標準中的一個或多個標準發(fā)布數(shù)字證書。通常，數(shù)字證書包括每個人都知道的用戶或系統(tǒng)的公鑰。無論用戶是在注冊時還是在其他時間請求數(shù)字證書，該請求通過信任引擎110傳遞至認證引擎215。根據(jù)一個實施例，該請求包括具有例如用戶正確姓名的XML文檔。根據(jù)步驟935，認證引擎215將該請求傳遞至加密引擎220，指示加密引擎220生成加密密鑰或密鑰對。一經(jīng)請求，在步驟935，加密引擎220生成至少一個加密密鑰。根據(jù)一個實施例，加密處理模塊625生成密鑰對，其中一個密鑰被用作私鑰，以及一個被用作公鑰。加密引擎220存儲私鑰，以及根據(jù)一個實施例存儲公鑰的拷貝。在步驟945中，加密引擎220向交易引擎205傳輸數(shù)字證書請求。根據(jù)一個實施例，該請求有利地包括標準化請求，例如，嵌入在例如XML文檔中的PKCSlO。數(shù)字證書請求可以有利地對應于一個或多個證書頒發(fā)機構(gòu)，以及證書頒發(fā)機構(gòu)要求的一個或多個標準格式。在步驟950，交易引擎205轉(zhuǎn)發(fā)該請求至證書頒發(fā)機構(gòu)115，后者在步驟955返回數(shù)字證書。返回的數(shù)字證書可以有利地為標準化格式，例如PKCS7，或者為一個或多個證書頒發(fā)機構(gòu)115的專有格式。在步驟960中，數(shù)字證書被交易引擎205接收，副本被轉(zhuǎn)發(fā)至用戶，以及用信任引擎110存儲副本。信任引擎110存儲證書的副本，從而信任引擎110不需要依賴于證書頒發(fā)機構(gòu)115的可用性。例如，當用戶期望發(fā)送數(shù)字證書或第三方請求用戶的數(shù)字證書時，數(shù)字證書請求通常被發(fā)送到證書頒發(fā)機構(gòu)115。然而，如果證書頒發(fā)機構(gòu)115正在進行維護或已經(jīng)成為故障或安全損害的犧牲品，則數(shù)字證書可能不可用。在發(fā)布加密密鑰之后的任何時間，加密引擎220可以有利地采用上述的數(shù)據(jù)拆分處理800以使得加密密鑰被拆分成獨立不可破譯的隨機化的數(shù)。類似于認證數(shù)據(jù)，在步驟965，加密引擎220將隨機化的數(shù)傳送到數(shù)據(jù)存儲設備Dl至D4。本領域技術人員從此處公開應理解，用戶可以在注冊之后的任何時間請求數(shù)字證書。此外，系統(tǒng)之間的通信可以有利地包括全SSL或公鑰加密技術。此外，注冊處理可以發(fā)布來自多個證書頒發(fā)機構(gòu)的多個數(shù)字證書，所述證書頒發(fā)機構(gòu)包括信任引擎110內(nèi)部或外部的一個或多個專有證書頒發(fā)機構(gòu)。如在步驟935至960中所公開的，本發(fā)明的一個實施例包括最終存儲在信任引擎110上的證書請求。根據(jù)一個實施例，因為加密處理模塊625發(fā)布由信任引擎110使用的密鑰，因此每個證書對應于一個私鑰。因此，信任引擎110可以有利地通過監(jiān)視由用戶擁有或與用戶相關聯(lián)的證書來提供互用性。例如，當加密引擎220接收加密功能請求時，加密處理模塊625可以調(diào)查由進行請求的用戶所擁有的證書以確定該用戶是否擁有與該請求的屬性相匹配的私鑰。當存在這樣的證書時，加密處理模塊625可以使用證書或與其相關的公鑰或私鑰，來執(zhí)行所請求的功能。當這樣的證書不存在時，加密處理模塊625可以有利且透明地執(zhí)行若干動作以試圖對缺少適當?shù)拿荑€進行補救。例如，圖9B示出了根據(jù)本發(fā)明的實施例的多個方面的互用性處理970的流程圖，公開上述步驟以保證加密處理模塊625使用適當密鑰來執(zhí)行加密功能。如圖9B中所示，互用性處理970從步驟972開始，在該處，加密處理模塊925確定期望的證書類型。根據(jù)本發(fā)明的一個實施例，證書的類型可以有利地在加密功能請求或請求者提供的其他數(shù)據(jù)中指定。根據(jù)另一實施例，證書類型可以由請求的數(shù)據(jù)格式確定。例如，加密處理模塊925可以有利地識別該請求對應于特定的類型。根據(jù)一個實施例，證書類型可包括一個或多個算法標準，例如，RSA、ELGAMAL等。此夕卜，證書類型可以包括一個或多個密鑰類型，例如對稱密鑰、公鑰、諸如256位密鑰的強加密密鑰、低安全密鑰等。此外，證書類型可以包括一個或多個上述算法標準或密鑰、一個或多個消息或數(shù)據(jù)格式、一個或多個數(shù)據(jù)封裝或編碼機制(例如Base32或Base64)的升級或替換。證書類型還可以包括與一個或多個第三方加密應用或接口、一個或多個通信協(xié)議、或一個或多個證書標準或協(xié)議的兼容性。本領域的技術人員從在此的公開應該理解其他差異可能存在于證書類型中，以及如在此所公開的，可以執(zhí)行這些差異之間的來回轉(zhuǎn)換。一旦加密處理模塊625確定證書類型，互用性處理970進行到步驟974，并確定用戶是否擁有與在步驟974中確定的類型相匹配的證書。當用戶擁有匹配證書時，例如，信任引擎110可以通過例如其先前的存儲獲得匹配證書，加密處理模塊825知道匹配私鑰也存儲在信任引擎110中。例如，匹配私鑰可以被存儲在倉庫210或倉庫系統(tǒng)700中。加密處理模塊625可以有利地請求從例如倉庫210組裝匹配私鑰，然后在步驟976，使用匹配私鑰執(zhí)行加密動作或功能。例如，如上所述，加密處理模塊625可以有利地執(zhí)行散列、散列比較、數(shù)據(jù)加密或解密、數(shù)字簽名校驗或創(chuàng)建、等等。當用戶不擁有匹配證書時，互用性處理970進行到步驟978，在這里，加密處理模塊625確定用戶是否擁有交叉證明證書。根據(jù)一個實施例，證書頒發(fā)機構(gòu)之間的交叉證明在第一證書頒發(fā)機構(gòu)確定信任來自第二證書頒發(fā)機構(gòu)的證書時發(fā)生。換句話說，第一證書頒發(fā)機構(gòu)確定來自第二證書頒發(fā)機構(gòu)的證書符合一定質(zhì)量標準，并因此可以被“證明”為等同于第一證書頒發(fā)機構(gòu)本身的證書。交叉證明在證書頒發(fā)機構(gòu)發(fā)布例如具有信任等級的證書時變得更復雜。例如，第一證書頒發(fā)機構(gòu)通?；谧蕴幚碇械目煽砍潭?，可以為特定證書提供三個信任等級，而第二證書頒發(fā)機構(gòu)可以提供七個信任等級。交叉證明可以有利地跟蹤來自第二證書頒發(fā)機構(gòu)的哪些等級以及哪些證書可以代替來自第一證書頒發(fā)機構(gòu)的哪些等級和哪些證書。當在兩個證書頒發(fā)機構(gòu)之間官方和公開地完成上述交叉證明時，彼此的證書和等級的映射通常被稱作“鏈接(chaining)”。根據(jù)本發(fā)明的另一實施例，加密處理模塊625可以有利地開發(fā)由證書頒發(fā)機構(gòu)認為一致的那些之外的交叉證明。例如，加密處理模塊625可以訪問第一證書頒發(fā)機構(gòu)的證書實踐聲明(certificate practice statement,CPS)或其他公開的政策聲明，并且使用例如特定信任等級所需的認證令牌使第一證書頒發(fā)機構(gòu)的證書匹配至另一證書頒發(fā)機構(gòu)的那些證書。當在步驟978中加密處理模塊625確定用戶擁有交叉證明的證書時，互用性處理970進行到步驟976，并使用交叉證明的公鑰、私鑰或兩者來執(zhí)行加密動作或功能?？商鎿Q地，當加密處理模塊625確定用戶不擁有交叉證明證書時，互用性處理970進行到步驟980，在這里，加密處理模塊625選擇發(fā)布所請求的證書類型或被交叉證明的證書的證書頒發(fā)機構(gòu)。在步驟982，加密處理模塊625確定前面所討論的用戶注冊認證數(shù)據(jù)是否符合所選證書頒發(fā)機構(gòu)的認證要求。例如，如果用戶是通過例如回答人口統(tǒng)計學和其他問題在網(wǎng)絡上注冊的，所提供的認證數(shù)據(jù)與提供生物識別數(shù)據(jù)和呈現(xiàn)在例如公證人的第三方面前的用戶相比可以建立較低的信任等級。根據(jù)一個實施例，上述認證要求可以有利地設置在所選證書頒發(fā)機構(gòu)的CPS中。當用戶已經(jīng)向信任引擎110提供符合所選證書頒發(fā)機構(gòu)的要求的注冊認證數(shù)據(jù)時，互用性處理970進行到步驟984，在這里，加密處理模塊825從所選證書頒發(fā)機構(gòu)獲取證書。根據(jù)一個實施例，加密處理模塊625通過遵照注冊處理900的步驟945至960來獲取證書。例如，加密處理模塊625可以有利地使用來自加密引擎220已經(jīng)可用的一個或多個密鑰對的一個或多個公鑰來從證書頒發(fā)機構(gòu)請求證書。根據(jù)另一實施例，加密處理模塊625可以有利地生成一個或多個新的密鑰對，以及使用與其對應的公鑰來從證書頒發(fā)機構(gòu)請求證書。根據(jù)另一實施例，信任引擎110可以有利地包括能夠發(fā)布一個或多個證書類型的一個或多個證書發(fā)布模塊。根據(jù)該實施例，證書發(fā)布模塊可以提供上述證書。當加密處理模塊625獲取到證書，互用性處理970進行到步驟976，使用對應于所獲取的證書的公鑰、私鑰或兩者來執(zhí)行加密動作或功能。當在步驟982中用戶沒有向信任引擎110提供滿足所選證書頒發(fā)機構(gòu)的要求的注冊認證數(shù)據(jù)時，加密處理模塊625在步驟986中確定是否存在具有不同認證要求的其他證書頒發(fā)機構(gòu)。例如，加密處理模塊625可以尋找具有較低認證要求的證書頒發(fā)機構(gòu)，但仍然發(fā)布所選證書或其交叉證明。當存在上述具有較低要求的證書頒發(fā)機構(gòu)時，互用性處理970進行到步驟980并選擇該證書頒發(fā)機構(gòu)?？商鎿Q地，當沒有這樣的證書頒發(fā)機構(gòu)存在時，在步驟988，信任引擎110可以要求來自用戶的其他認證令牌。例如，信任弓丨擎110可以要求包括例如生物識別數(shù)據(jù)的新注冊認證數(shù)據(jù)。同樣，信任引擎110可以要求用戶在可信第三方前出現(xiàn)，并提供適當?shù)恼J證憑證，例如帶著駕照、社會保障卡、銀行卡、出生證明、軍人ID等出現(xiàn)在公證人面前。當信任引擎110接收到更新的認證數(shù)據(jù)時，互用性處理970進行到步驟984并獲取上述所選的證書。通過上述互用性處理970，加密處理模塊625有利地提供不同加密系統(tǒng)之間的無縫、透明的翻譯和轉(zhuǎn)換。本領域技術人員從在此的公開應該理解上述互用系統(tǒng)的優(yōu)點和實施方式。例如，互用性處理970的上述步驟986可以有利地包括下面將更詳細描述的信任仲裁的各個方面，其中證書頒發(fā)機構(gòu)在可以特定情況下接受較低等級的交叉證明。此外，互用性處理970可以包括保證標準證書撤銷之間的互用性，以及采用標準證書撤銷，例如采用證書撤銷列表(CRL)、在線證書狀態(tài)協(xié)議(OCSP)等。圖10示出了根據(jù)本發(fā)明的實施例的多個方面的認證處理1000的數(shù)據(jù)流。根據(jù)一個實施例，認證處理1000包括從用戶收集當前認證數(shù)據(jù)并將其與用戶的注冊認證數(shù)據(jù)進行比較。例如，認證處理1000在步驟1005處開始，在這里，用戶期望與例如賣方執(zhí)行交易。這樣的交易可以包括例如選擇購買選項、請求對賣方系統(tǒng)120的受限制區(qū)域或裝置的訪問。在步驟1010，賣方向用戶提供交易ID和認證請求。交易ID可以有利地包括192位的量，其具有與128位隨機量級聯(lián)的32位時間戳，或與32位特定于賣方的常量級聯(lián)的“臨時隨機數(shù)(nonce)”。這樣的交易ID唯一地標識該交易，從而模仿交易能夠被信任引擎110拒絕。認證請求可以有利地包括特定交易所需的認證等級。例如賣方可以在發(fā)布時指定該交易所需的特定可信度。如果不能如下所述地對該可信度進行認證，則除非有用戶提升可信度的進一步認證或賣方和服務器之間的認證改變，否則不能發(fā)生該交易。這些發(fā)布將在下面詳細討論。根據(jù)一個實施例，交易ID和認證請求可以有利地由賣方端小程序或其他軟件程序生成。此外，交易ID和認證數(shù)據(jù)的傳輸可以包括使用傳統(tǒng)SSL技術(例如1/2SSL、或換句話說，賣方端認證的SSL)加密的一個或多個XML文檔。在用戶系統(tǒng)105接收到交易ID和認證請求之后，用戶系統(tǒng)105收集來自用戶的當前認證數(shù)據(jù)，可能包括當前生物識別信息。用戶系統(tǒng)105在步驟1015使用認證引擎215的公鑰來至少加密當前認證數(shù)據(jù)“B”和交易ID，以及將該數(shù)據(jù)傳輸至信任引擎110。該傳輸優(yōu)選地包括至少使用傳統(tǒng)1/2SSL技術加密的XML文檔。在步驟1020，交易引擎205接收該傳輸，優(yōu)選地識別URL或URI中的數(shù)據(jù)格式或請求，并將該傳輸轉(zhuǎn)發(fā)至認證引擎215。在步驟1015和1020中，賣方系統(tǒng)120在步驟1025使用優(yōu)選的全SSL技術轉(zhuǎn)發(fā)交易ID和認證請求至信任引擎110。該通信還可以包括賣方ID，盡管賣方標識還可以通過交易ID的非隨機部分被傳送。在步驟1030和1035，交易引擎205接收該通信，在審計跟蹤中創(chuàng)建記錄，以及生成對將從數(shù)據(jù)存儲設備Dl至D4組裝的用戶的注冊認證數(shù)據(jù)的請求。在步驟1040，倉庫系統(tǒng)700將對應于用戶的注冊認證數(shù)據(jù)的各部分傳輸至認證引擎215。在步驟1045，認證引擎215使用其私鑰解密該傳輸，并將注冊認證數(shù)據(jù)與用戶提供的當前認證數(shù)據(jù)進行比較。步驟1045的比較可以優(yōu)選地應用試探式上下文相關認證，如上面提及并將在下面詳細討論的。例如，如果所接收的生物識別信息沒有完美地匹配，則導致較低的信任匹配。在特定實施例中，認證的可信度與交易的性質(zhì)和用戶與賣方的期望被權衡考慮。這也將在下面更詳細討論。在步驟1050，認證引擎215使用步驟1045的比較結(jié)果填充認證請求。根據(jù)本發(fā)明的一個實施例，認證請求被填充有認證處理1000的是/否或真/假結(jié)果。在步驟1055，被填充的認證請求返回到賣方供賣方采取行動，例如允許用戶完成發(fā)起過認證請求的交易。根據(jù)一個實施例，確認消息被傳遞至用戶?；谏厦娴拿枋?，認證處理1000優(yōu)選地保持敏感數(shù)據(jù)的安全性，并產(chǎn)生用于維護敏感數(shù)據(jù)完整性的結(jié)果。例如，敏感數(shù)據(jù)僅在認證引擎215中被組裝。例如，注冊認證數(shù)據(jù)不可破譯，直到其在認證引擎215中被數(shù)據(jù)組裝模塊組裝，并且當前認證數(shù)據(jù)不可破譯，直到其被傳統(tǒng)SSL技術和認證引擎215的私鑰解包裝。此外，傳輸至賣方的認證結(jié)果不包括敏感數(shù)據(jù)，用戶可能甚至不知道他或她是否產(chǎn)生了有效的認證數(shù)據(jù)。盡管參考優(yōu)選和可替換實施例公開了認證處理1000，本發(fā)明不因此被限制。相反，本領域技術人員應該從在此的公開理解認證處理1000的多種替換例。例如，賣方可以有利地由幾乎任何請求應用來代替，甚至是那些與用戶系統(tǒng)105—起駐留的應用。例如，客戶端應用，諸如Microsoft Word，可以使用應用程序接口(API)或加密API (CAPI)來在解鎖文件之前請求認證?？商鎿Q地，郵件服務器、網(wǎng)絡、蜂窩電話、個人或移動計算裝置、網(wǎng)絡工作站等都可以發(fā)出能夠被認證處理1000填充的認證請求。事實上，在提供上述可信任的認證處理1000之后，請求應用或裝置可以提供對多個電子或計算機裝置或系統(tǒng)的訪問和使用。此外，認證處理1000可以在認證失敗時使用多種替換過程。例如，認證失敗可以保持相同的交易ID并請求用戶重新輸入他或她的當前認證數(shù)據(jù)。如上所述，使用相同的交易ID使得認證引擎215的比較器能夠監(jiān)視和限制對特定交易的認證嘗試的次數(shù)，從而創(chuàng)建更安全的加密系統(tǒng)100。此外，認證處理1000可以有利地被使用來開發(fā)簡潔的單一登錄解決方案(singlesign-on solution),例如解鎖敏感數(shù)據(jù)資料庫。例如,成功或肯定認證可以為被認證的用戶提供自動訪問幾乎無限多個系統(tǒng)和應用的任何數(shù)量的口令的能力。例如，用戶的認證可以為用戶提供對與多個在線賣方、局域網(wǎng)、各種個人計算裝置、因特網(wǎng)業(yè)務提供商、拍賣商、投資經(jīng)紀等相關聯(lián)的口令、登錄、金融憑證等的訪問。通過使用敏感數(shù)據(jù)資料庫，用戶可以選擇非常大且隨機的口令，因為不再需要通過聯(lián)想來記住它們。相反，認證處理1000提供對其的訪問。例如，用戶可以選擇長度為20多位的隨機混合符號串，而不是與可記住的數(shù)據(jù)、姓名等有關的東西。根據(jù)一個實施例，與給定用戶相關的敏感數(shù)據(jù)資料庫可以有利地存儲在倉庫210的數(shù)據(jù)存儲設備中，或在倉庫系統(tǒng)700中被拆分和存儲。根據(jù)該實施例，在肯定的用戶認證之后，信任引擎HO向進行請求的應用提供所請求的敏感數(shù)據(jù)，例如適當?shù)目诹?。根?jù)另一實施例，信任引擎110可以包括用于存儲敏感數(shù)據(jù)資料庫的單獨系統(tǒng)。例如，信任引擎110可以包括執(zhí)行數(shù)據(jù)資料庫功能并表現(xiàn)為駐留在上述信任引擎110的前端安全系統(tǒng)“之后”的獨立軟件引擎。根據(jù)該實施例，軟件引擎在該軟件引擎接收到來自信任引擎110的表示肯定用戶認證的信號之后提供所請求的敏感數(shù)據(jù)。在另一實施例中，數(shù)據(jù)資料庫可以由第三方系統(tǒng)實現(xiàn)。類似于軟件引擎實施例，第三方系統(tǒng)可以有利地在第三方系統(tǒng)從信任引擎110接收表示肯定用戶認證的信號之后提供所請求的敏感數(shù)據(jù)。根據(jù)另一實施例，數(shù)據(jù)資料庫可以在用戶系統(tǒng)105上實現(xiàn)。用戶端軟件引擎可以有利地在接收到來自信任引擎110的表示肯定用戶認證的信號之后提供前述數(shù)據(jù)。盡管參考可替換實施例公開了前述數(shù)據(jù)資料庫，但是本領域技術人員應該從在此的公開理解多種其他實施方式。例如，特定數(shù)據(jù)資料庫可以包括前述實施例中的部分或所有實施例的多個方面。此外，任何前述數(shù)據(jù)資料庫可在不同時間使用一個或多個認證請求。例如，任何數(shù)據(jù)資料庫可以要求每一個或多個交易、周期性地、每一個或多個會話、每訪問一個或多個網(wǎng)頁或網(wǎng)站、以一個或多個其他指定間隔、等等，進行認證。圖11示出了根據(jù)本發(fā)明的實施例的多個方面的簽名處理1100的數(shù)據(jù)流。如圖11所示，簽名處理1100包括類似于前面參考圖10所述的認證處理1000的步驟。根據(jù)本發(fā)明的一個實施例，如下面將進一步具體討論的，簽名處理1100首先認證用戶，然后執(zhí)行若干數(shù)字簽名功能中的一個或多個。根據(jù)另一實施例，簽名處理1100可以有利地存儲與其相關的數(shù)據(jù)，諸如消息或文件等的散列。該數(shù)據(jù)可以有利地被用在審計或任何其他事件中，例如在參與方企圖抵賴交易時。如圖11中所示，在認證步驟期間，用戶和賣方可以有利地對諸如合同之類的消息達成一致。在簽名過程中，簽名處理1100有利地保證由用戶簽署的合同與賣方提供的合同相同。因此，根據(jù)一個實施例，在認證期間，賣方和用戶在傳輸至認證引擎215的數(shù)據(jù)中包括他們各自的消息或合同副本的散列。通過僅使用消息或合同的散列，信任引擎110可以有利地存儲顯著減少的數(shù)據(jù)量，從而提供更高效以及節(jié)省成本的加密系統(tǒng)。此外，所存儲的散列可以有利地與尚存疑的文件的散列進行比較，以確定該尚存疑的文件是否與由任何一方簽名的文件匹配。這種確定文件是否與和交易相關的一個文件相同的能力提供了附加的證據(jù)，其能夠用于反對一方抵賴交易的主張。在步驟1103，認證引擎215組裝注冊認證數(shù)據(jù)并將其與由用戶提供的當前認證數(shù)據(jù)進行比較。當認證引擎215的比較器指示注冊認證數(shù)據(jù)匹配當前認證數(shù)據(jù)時，認證引擎215的比較器還將由賣方提供的消息的散列與由用戶提供的消息的散列進行比較。因此，認證引擎215有利地保證用戶同意的消息與賣方同意的消息相同。在步驟1105，認證引擎215傳輸數(shù)字簽名至加密引擎220。根據(jù)本發(fā)明的一個實施例，該請求包括消息或合同的散列。然而，本領域技術人員從此處的公開應了解加密引擎220實際上可以加密任何類型的數(shù)據(jù)，包括但不限于視頻、音頻、生物識別信息、圖像、或文本，以形成期望的數(shù)字簽名。返回到步驟1105，數(shù)字簽名請求優(yōu)選地包括通過傳統(tǒng)SSL技術傳送的XML文檔。在步驟1110中，認證引擎215傳輸請求至每個數(shù)據(jù)存儲設備Dl至D4，從而每個數(shù)據(jù)存儲設備Dl至D4傳輸與簽名方相對應的加密密鑰(一個或多個)中它們各自的部分。根據(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ù)字簽名表示用戶和/或賣方已經(jīng)被正確認證。在該實施例中，認證引擎215可以有利地請求組裝對應于用戶、賣方或兩者的加密密鑰。根據(jù)另一實施例，認證引擎215可以有利地請求組裝對應于信任引擎110的加密密鑰。根據(jù)另一實施例，信任引擎110執(zhí)行類似委托書的功能。例如，信任引擎110可以以第三方的名義數(shù)字簽名該消息。在這種情況下，認證引擎215請求與第三方相關聯(lián)的加密密鑰。根據(jù)該實施例，在允許類似委托書的功能之前，簽名處理1100可以有利地包括第三方的認證。此外，認證處理1000可以包括檢查第三方約束，例如指示何時以及在什么情況下可以使用特定第三方簽名的商業(yè)邏輯等?；谏厦嫠?，在步驟1110，認證引擎從數(shù)據(jù)存儲設備Dl至D4請求對應于簽名方的加密密鑰。在步驟1115中，數(shù)據(jù)存儲設備Dl至D4傳輸與簽名方相對應的加密密鑰中它們各自的部分至加密引擎220。根據(jù)一個實施例,上述傳輸包括SSL技術。根據(jù)另一實施例，上述傳輸可以有利地使用加密引擎220的公鑰被超級加密(super-encrypt)。在步驟1120，加密引擎220組裝簽名方的上述加密密鑰并以其加密該消息，從而形成數(shù)字簽名(一個或多個)。在簽名處理1100的步驟1125，加密引擎220傳輸數(shù)字簽名至認證引擎215。在步驟1130，認證引擎215傳輸填充的認證請求連同散列的消息的副本以及數(shù)字簽名至交易引擎205。在步驟1135，交易引擎205傳輸包括交易ID、關于認證是否成功的指示和數(shù)字簽名的收據(jù)(receipt)至賣方。根據(jù)一個實施例，上述傳輸可以有利地包括信任引擎110的數(shù)字簽名。例如，信任引擎110可以使用其私鑰加密收據(jù)的散列，從而形成將被附加到至賣方的傳輸?shù)臄?shù)字簽名。根據(jù)一個實施例，交易引擎205還傳輸確認消息至用戶。盡管參考其優(yōu)選和可替換實施例公開了簽名處理1100，但是本發(fā)明不因此被限制。相反，本領域技術人員應該從此處的公開了解簽名處理1100的多種替換例。例如，賣方可以由用戶應用(例如電子郵件應用)來代替。例如，用戶可能希望用他或她的數(shù)字簽名來數(shù)字簽名特定電子郵件。在這樣的實施例中，通過簽名處理1100的傳輸可以有利地僅包括消息的散列的一份副本。此外，本領域技術人員應該從此處的公開理解多種客戶端應用可以請求數(shù)字簽名。例如，客戶端應用可以包括文字處理器、電子表格、電子郵件、語音郵件、對受限系統(tǒng)區(qū)域的訪問，等等。此外，本領域技術人員應該從此處的公開理解簽名處理1100的步驟1105至1120可以有利地使用圖9B的互用性處理970的部分或全部步驟，從而提供不同加密系統(tǒng)之間的互用性，其中不同加密系統(tǒng)可能例如需要處理不同簽名類型的數(shù)字簽名。圖12示出了根據(jù)本發(fā)明的一個實施例的多個方面的加密/解密處理1200的數(shù)據(jù)流。如圖12中所示，解密處理1200從使用認證處理1000認證用戶開始。根據(jù)一個實施例，認證處理1000包括認證請求中的同步會話密鑰。例如，在傳統(tǒng)PKI技術中，本領域技術人員應該理解使用公鑰和私鑰加密或解密數(shù)據(jù)是數(shù)學密集的，并且可能需要相當多的系統(tǒng)資源。然而，在對稱密鑰加密系統(tǒng)中或在消息的發(fā)送者或接收者共享用于加密和解密消息的單個共同密鑰的系統(tǒng)中，數(shù)學運算要簡單和快速得多。因此，在傳統(tǒng)PKI技術中，消息的發(fā)送者將生成同步會話密鑰，并使用較為簡單且較快速的同步密鑰系統(tǒng)加密該消息。然后，發(fā)送者將使用接收者的公鑰加密會話密鑰。加密的會話密鑰將附加到同步加密的消息，并且兩個數(shù)據(jù)都被發(fā)送至接收者。接收者使用他或她的私鑰來解密該會話密鑰，然后使用該會話密鑰來解密該消息?；谏厦嫠?，較簡單且較快速的對稱密鑰系統(tǒng)被用于大部分的加密/解密處理。因此，在解密處理1200中，解密有利地假設同步密鑰已經(jīng)用用戶的公鑰被加密。因此，如上所述，加密的會話密鑰被包括在認證請求中。返回到解密處理1200，在用戶已經(jīng)在步驟1205中被認證之后，認證引擎215將加密的會話密鑰轉(zhuǎn)發(fā)至加密引擎220。在步驟1210，認證引擎215將請求轉(zhuǎn)發(fā)至每個數(shù)據(jù)存儲設備Dl至D4，請求用戶的加密密鑰數(shù)據(jù)。在步驟1215，每個數(shù)據(jù)存儲設備Dl至D4傳輸其各自的加密密鑰部分至加密引擎220。根據(jù)一個實施例，上述傳輸使用加密引擎220的公鑰被加密。在解密處理1200的步驟1220，加密引擎220組裝加密密鑰并以其解密會話密鑰。在步驟1225，加密引擎轉(zhuǎn)發(fā)會話密鑰至認證引擎215。在步驟1227，認證引擎215填充認證請求以包括解密的會話密鑰，并將填充的認證請求傳輸至交易引擎205。在步驟1230，交易引擎205將認證請求連同會話密鑰轉(zhuǎn)發(fā)至進行請求的應用或賣方。然后，根據(jù)一個實施例，進行請求的應用或賣方使用該會話密鑰來解密被加密的消息。盡管參考其優(yōu)選和可替換實施例公開了解密處理1200，本領域技術人員從此處的公開應該了解解密處理1200的多種替換例。例如，解密處理1200可以位于同步密鑰加密之前并且依賴于全公鑰技術。在這樣的實施例中，進行請求的應用可以傳輸整個消息至加密引擎220，或可以使用一些類型的壓縮或可逆散列以傳輸消息至加密引擎220。本領域技術人員從此處的公開也應該理解上述通信可以有利地包括以SSL技術包裝的XML文檔。加密/解密處理1200還提供文檔或其他數(shù)據(jù)的加密。因此，在步驟1235，進行請求的應用或賣方可以有利地傳輸對用戶公鑰的請求至信任引擎110的交易引擎205。該進行請求的應用或賣方進行該請求，是因為進行請求的應用或賣方使用用戶的公鑰來例如加密將被用來加密文檔或消息的會話密鑰。如在注冊處理900中所述，交易引擎205將用戶的數(shù)字證書的副本存儲在例如大容量存儲器225中。因此，在加密處理1200的步驟1240，交易引擎205從大容量存儲器225請求用戶的數(shù)字證書。在步驟1245，大容量存儲器225將對應于該用戶的數(shù)字證書傳輸至交易引擎205。在步驟1250，交易引擎205將數(shù)字證書傳輸至進行請求的應用或賣方。根據(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ù)一個示例，用戶有利地提供當前認證數(shù)據(jù)至地理上最靠近的信任引擎1305。信任引擎1305的交易引擎1321然后轉(zhuǎn)發(fā)當前認證數(shù)據(jù)至同樣位于第一位置的認證引擎1322。根據(jù)另一實施例，交易引擎1321轉(zhuǎn)發(fā)當前認證數(shù)據(jù)至信任引擎1310、1315或1320的一個或多個認證引擎。交易引擎1321還請求組裝來自例如每個信任引擎1305至1320的倉庫的注冊認證數(shù)據(jù)。根據(jù)該實施例，每個倉庫提供注冊認證數(shù)據(jù)中它的部分至信任引擎1305的認證引擎1322。認證引擎1322然后使用來自例如前兩個響應的倉庫的加密數(shù)據(jù)部分，并將注冊認證數(shù)據(jù)組裝成被破譯的形式。認證引擎1322將注冊認證數(shù)據(jù)與當前認證數(shù)據(jù)進行比較并返回認證結(jié)果至信任引擎1305的交易引擎1321。基于上面所述，信任引擎系統(tǒng)1300使用多個地理上分開的信任引擎1305至1320中最近的一個來執(zhí)行認證處理。根據(jù)本發(fā)明的一個實施例，將信息路由至最近的交易引擎可以有利地在運行在用戶系統(tǒng)105、賣方系統(tǒng)120或證書頒發(fā)機構(gòu)115中的一個或多個上的客戶端小程序處執(zhí)行。根據(jù)一個可替換實施例，可以使用更復雜的判定處理來從信任引擎1305至1320中進行選擇。例如，判定可以基于給定信任引擎的可用性、可操作性、連接的速度、負荷、性能、地理接近度、或其組合。以該方式，信任引擎系統(tǒng)1300降低其響應時間同時維持與地理上遠離的數(shù)據(jù)存儲設備相關聯(lián)的安全性優(yōu)點，例如參考圖7所討論的那些優(yōu)點，其中在圖7中每個數(shù)據(jù)存儲設備存儲敏感數(shù)據(jù)的隨機化部分。例如，在例如信任引擎1315的倉庫1325處的安全性損害不必然泄露信任引擎系統(tǒng)1300的敏感數(shù)據(jù)。這是因為倉庫1325僅包括不可破譯的隨機化的數(shù)據(jù)，該數(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或證書頒發(fā)機構(gòu)115的客戶端小程序與信任引擎系統(tǒng)1400通信時，這些通信被發(fā)送至每個信任引擎1405至1420的IP地址。此外，每個信任引擎1405、1410、1415和1420的每個交易引擎類似于參考圖13公開的信任引擎1305的交易引擎1321而工作。例如，在認證處理過程中，每個信任引擎1405、1410、1415和1420的每個交易引擎?zhèn)鬏敭斍罢J證數(shù)據(jù)至其各自的認證引擎，并傳輸請求以組裝存儲在每個信任引擎1405至1420的每個倉庫中的隨機化的數(shù)據(jù)。圖14沒有示出所有這些通信，因為這樣示出的話就變得過于復雜了。繼續(xù)認證處理，每個倉庫然后將其隨機化數(shù)據(jù)部分傳送至每個信任引擎1405至1420的每個認證引擎。每個信任引擎的每個認證引擎使用其比較器來確定當前認證數(shù)據(jù)是否與每個信任引擎1405至1420的倉庫提供的注冊認證數(shù)據(jù)匹配。根據(jù)該實施例，每個認證引擎的比較結(jié)果然后被傳輸至其他三個信任引擎的冗余模塊。例如，來自信任引擎1405的認證引擎的結(jié)果被傳輸至信任引擎1410、1415和1420的冗余模塊。從而類似地，信任引擎1405的冗余模塊接收來自信任引擎1410、1415和1420的認證引擎的結(jié)果。圖15示出了圖14的冗余模塊的框圖。該冗余模塊包括比較器，用于接收來自三個認證引擎的認證結(jié)果以及將該結(jié)果傳輸至第四個信任引擎的交易引擎。比較器將來自這三個認證引擎的認證結(jié)果進行比較，如果有兩個結(jié)果是一致的，則比較器斷定認證結(jié)果與兩個達成一致的認證引擎的認證結(jié)果匹配。該結(jié)果然后被傳輸回對應于與這三個認證引擎不相關聯(lián)的信任引擎的交易引擎?；谏厦嫠觯哂嗄K基于從優(yōu)選地地理上與該冗余模塊的信任引擎相遠離的認證引擎接收到的數(shù)據(jù)確定認證結(jié)果。通過提供這樣的冗余功能，信任引擎系統(tǒng)1400保證信任引擎1405至1420之一的認證引擎的損害不足以損害該特定信任引擎的冗余模塊的認證結(jié)果。本領域技術人員應該理解，信任引擎系統(tǒng)1400的冗余模塊功能也可以被應用于每個信任引擎1405至1420的加密引擎。然而，這樣的加密引擎通信沒有在圖14中示出以避免復雜。此外，本領域技術人員應該理解，用于圖15的比較器的多種可替換的認證結(jié)果沖突解決算法適于用在本發(fā)明中。根據(jù)本發(fā)明的另一實施例，信任引擎系統(tǒng)1400可以有利地在加密比較步驟過程中采用冗余模塊。例如，上述參考圖14和15公開的冗余模塊的部分或全部可以有利地在對一方或多方在特定交易期間提供的文檔進行散列比較期間實施。盡管已經(jīng)根據(jù)某些優(yōu)選和可替換實施例描述了上述發(fā)明，但是本領域技術人員可以由此處公開顯而易見其他實施例。例如，信任引擎110可以發(fā)布短期證書，而私有加密密鑰被釋放給用戶某個預定時間段。例如，當前證書標準包括能夠被設置為在預定時間量后過期的有效性字段。因此，信任引擎Iio可以向用戶釋放私鑰，其中該私鑰在例如24小時內(nèi)有效。根據(jù)這樣的實施例，信任引擎110可以有利地發(fā)布與特定用戶相關聯(lián)的新的加密密鑰對，然后釋放該新的加密密鑰對的私鑰。然后，一旦私有加密密鑰被釋放，信任引擎110就立即終止這樣的私鑰的任何內(nèi)部有效使用，因為其信任引擎110不再保證其安全。此外，本領域技術人員應該意識到，加密系統(tǒng)100或信任引擎110可以包括識別任何類型的裝置的能力，所述裝置諸如但不限于膝上型電腦、蜂窩電話、網(wǎng)絡、生物識別裝置、等等。根據(jù)一個實施例，這樣的識別可以來自于在對特定服務的請求中提供的數(shù)據(jù)，所述請求諸如對弓I起訪問或使用的認證的請求、對加密功能的請求等。根據(jù)一個實施例，上述請求可以包括唯一裝置標識符，例如處理器ID。可替換地，該請求可以包括具有特定可識別數(shù)據(jù)格式的數(shù)據(jù)。例如，移動和衛(wèi)星電話通常不包括對于完全X509.V3重加密證書(full X509.V3heavy encryption certificates)的處理能力，從而不請求它們。根據(jù)該實施例,信任引擎110可以識別所呈現(xiàn)的數(shù)據(jù)格式的類型，并僅以同樣方式響應。在上述系統(tǒng)的其他方面，上下文相關認證可以使用下面將描述的各種技術來提供。上下文相關認證，例如圖16中所示的，提供了不僅評估在用戶試圖認證其本身時發(fā)送的實際數(shù)據(jù)，而且還評估在生成和傳遞該數(shù)據(jù)的周圍的環(huán)境的能力。如下面將描述的，這樣的技術也可以支持用戶與信任引擎110之間或賣方與信任引擎110之間的特定于交易的信任仲裁。如上所討論的，認證是證明用戶是其所聲稱的那個人的過程。通常，認證要求向認證權力機構(gòu)證實一些事實。本發(fā)明的信任引擎110代表用戶必須向其認證自身的權力機構(gòu)。用戶必須通過知道一些僅該用戶應知道的東西(基于知識的認證)、具有一些僅該用戶應具有的東西(基于令牌的認證)、或是僅該用戶應該是的東西(基于生物識別的認證)來向信任引擎110證實他是他所聲稱的那個人?；谥R的認證的示例包括但不限于口令、PIN號、或鎖組合?；诹钆频恼J證的示例包括但不限于房間鑰匙、物理信用卡、駕照、或特定電話號碼。基于生物識別的認證的示例包括但不限于指紋、筆跡分析、面部掃描、手掃描、耳朵掃描、虹膜掃描、血管模式、DNA、語音分析、或視網(wǎng)膜掃描。每種類型的認證都具有特定優(yōu)點和缺點，并且每種類型提供不同的安全等級。例如，與偶然聽到某個人的口令并重復該口令相比，通常較難創(chuàng)建與其他人的指紋匹配的假指紋。每種類型的認證還要求不同類型的數(shù)據(jù)是認證權力機構(gòu)所知道的，以便校驗使用這種認證形式的人。如在此所使用的，“認證”廣義地表示證實某人的身份是他聲稱他是的那個人的整個過程?！罢J證技術”表示基于特定的知識、物理令牌、或生物識別讀取的特定類型的認證?！罢J證數(shù)據(jù)”表示發(fā)送至認證權力機構(gòu)或向其證實以建立身份的信息。“注冊數(shù)據(jù)”表示初始提交給認證權力機構(gòu)以建立用于與認證數(shù)據(jù)進行比較的基準的數(shù)據(jù)。“認證實例(authentication instance)”表示與用認證技術進行認證的嘗試相關聯(lián)的數(shù)據(jù)。參考上面圖10來描述在認證用戶的處理中所涉及的內(nèi)部協(xié)議和通信。該處理中發(fā)生上下文相關認證的部分出現(xiàn)在圖10的步驟1045所示的比較步驟中。該步驟在認證引擎215中發(fā)生，并涉及組裝從倉庫210取回的注冊數(shù)據(jù)410以及將其與用戶提供的認證數(shù)據(jù)進行比較。該處理的一個特定實施例在圖16中示出并在下面描述。由用戶提供的當前認證數(shù)據(jù)和從倉庫取回的注冊數(shù)據(jù)在圖16的步驟1600中被認證引擎215接收。這兩個數(shù)據(jù)集合都可能包含與認證的分離技術有關的數(shù)據(jù)。在步驟1605，認證引擎215分離與每個單獨認證實例相關聯(lián)的認證數(shù)據(jù)。這是必要的，從而認證數(shù)據(jù)與用戶的注冊數(shù)據(jù)的適當子集進行比較(例如，指紋認證數(shù)據(jù)應該與指紋注冊數(shù)據(jù)進行比較，而不是與口令注冊數(shù)據(jù)進行比較)。通常，認證用戶涉及一個或多個單獨認證實例，取決于用戶可用的認證技術。這些方法被注冊過程中由用戶提供的注冊數(shù)據(jù)所限制(如果用戶在注冊時沒有提供視網(wǎng)膜掃描，他就不能使用視網(wǎng)膜掃描來認證自己)，以及被用戶當前可用的手段所限制(例如，如果用戶在他當前位置不具有指紋讀取器，指紋認證將不可行)。在一些情況下，單個認證實例可能足以認證用戶；然而在某些情況下，多個認證實例的組合可以被使用以更加確信地認證特定交易的用戶。每個認證實例包括與一種特定認證技術(例如指紋、口令、智能卡等)以及在獲取和傳遞用于該特定技術的數(shù)據(jù)周圍的環(huán)境有關的數(shù)據(jù)。例如，嘗試通過口令進行認證的特定實例不僅生成與口令本身有關的數(shù)據(jù)，還生成與該口令嘗試有關的環(huán)境數(shù)據(jù)，被稱為“元數(shù)據(jù)”。該環(huán)境數(shù)據(jù)包括諸如以下的信息:特定認證實例發(fā)生的時間、認證信息從其遞送的網(wǎng)絡地址、以及本領域技術人員所知的可以確定的關于認證數(shù)據(jù)的來源的任何其他信息(連接的類型、處理器序列號等)。在許多情況下，僅有少量的環(huán)境元數(shù)據(jù)可用。例如，如果用戶位于使用代理或網(wǎng)絡地址轉(zhuǎn)換或其它掩蓋發(fā)源計算機地址的技術的網(wǎng)絡上，則僅僅可以確定代理服務器或路由器的地址。類似地，在許多情況下，諸如處理器序列號之類的信息將不可用，這是由于所使用的硬件或操作系統(tǒng)的限制、系統(tǒng)的操作者禁用這樣的特征、或用戶的系統(tǒng)與信任引擎110之間的連接的其他限制。如圖16中所示，一旦在認證數(shù)據(jù)中表示的單獨認證實例在步驟1605中被提取和分離，認證引擎215就評估每個實例在表示該用戶是其所聲稱的那個人這方面的可靠性。單個認證實例的可靠性通?；谌舾梢蛩貋泶_定。這些可以被成組為跟與認證技術相關聯(lián)的可靠性有關的因素(其在步驟1610中被評估)和跟所提供的特定認證數(shù)據(jù)的可靠性有關的因素(其在步驟1815中被評估)。第一組包括但不限于所使用的認證技術的固有可靠性，以及與該方法一起使用的注冊數(shù)據(jù)的可靠性。第二組包括但不限于注冊數(shù)據(jù)與認證實例所提供的數(shù)據(jù)之間的匹配度以及與該認證實例相關聯(lián)的元數(shù)據(jù)。這些因素中的每一個可以獨立于其他因素而改變。認證技術的固有可靠性基于冒名頂替者提供其他人的正確數(shù)據(jù)有多困難，以及認證技術的整體錯誤率。對于基于口令和知識的認證方法，該可靠性通常相當?shù)停驗椴淮嬖谌魏螙|西來阻止某人將其口令泄露給另一個人以及阻止該另一個人使用該口令。更復雜的基于知識的系統(tǒng)可能僅具有中等可靠性，這是因為知識可以相當容易地從一個人傳到另一個人?；诹钆频恼J證，諸如具有正確的智能卡或使用特定終端來執(zhí)行認證，類似地具有由其本身使用的低可靠性，這是因為不能保證正確的人持有該正確的令牌。然而，生物識別技術更固有地可靠，因為其通常難以方便地甚至故意地為其他人提供使用你的指紋的能力。因為破壞生物識別認證技術更加困難，所以生物識別方法的固有可靠性通常高于純粹基于知識或令牌的認證技術的可靠性。然而，即使生物識別技術也可能具有一些產(chǎn)生錯誤接受或錯誤拒絕的情況。這些情況的發(fā)生可以由相同的生物識別技術的不同實施方式的不同可靠性反映出來。例如，由一個公司提供的指紋匹配系統(tǒng)可以提供比由另一公司提供的指紋匹配系統(tǒng)更高的可靠性，因為該公司使用更高質(zhì)量的光學器件或更好的掃描分辨率或一些其他的減少錯誤接受或錯誤拒絕的發(fā)生的改進。 注意該可靠性可以以不同方式表示。可靠性被期望以某種能夠被試探法530和認證引擎215的算法使用以計算每種認證的可信度的衡量標準來表示。表示這些可靠性的一種優(yōu)選模式是百分比或分數(shù)。例如，指紋可以被賦予97%的固有可靠性，而口令可能僅被賦予50%的固有可靠性。本領域的技術人員應該理解這些特定值僅是示例性的，并且可以在具體實施方式
之間改變。評估可靠性必須針對的第二個因素是注冊的可靠性。這是上面提及的“分級注冊”處理的一部分。該可靠性因素反映在初始注冊處理期間提供的標識的可靠性。例如，如果個人以物理地將他們身份的證據(jù)出示給公證人或其他政府官員的方式初始注冊，并且注冊數(shù)據(jù)在此時被記錄和公證，則該數(shù)據(jù)將比在注冊過程中通過網(wǎng)絡提供并且僅由數(shù)字簽名或其他沒有真實綁定至個人的信息擔保的數(shù)據(jù)更可靠。具有不同可靠性等級的其他注冊技術包括但不限于:在信任引擎110操作者的物理辦公室注冊；在用戶的就業(yè)地點注冊；在郵局或護照辦公室注冊；通過附屬方或可信方向信任引擎110操作者注冊；匿名或筆名注冊，其中注冊的身份尚不等同于特定的真實個人；以及本領域已知的這樣的其他手段。這些因素反映信任引擎110和注冊處理期間提供的標識的源之間的信任。例如，如果在提供身份證據(jù)的初始處理期間與雇主相關聯(lián)地執(zhí)行注冊，則該信息可以被認為在公司內(nèi)部極為可靠，但是可能被政府機構(gòu)或競爭者認為是較低等級可信。因此，這些其他組織中每一個所操作的信任引擎可以給該注冊分配不同的可靠性等級。類似地，通過網(wǎng)絡提交但是用相同的信任引擎110由在先前注冊過程中提供的其他信任數(shù)據(jù)認證的另外的數(shù)據(jù)可以被認為與原始注冊數(shù)據(jù)一樣可靠，即使后者數(shù)據(jù)是通過開放網(wǎng)絡提交的。在這樣的情況下，后續(xù)公證將有效地增加與原始注冊數(shù)據(jù)相關聯(lián)的可靠性等級。以該方式，例如，通過向一些注冊官員證明個人身份與注冊數(shù)據(jù)相匹配，匿名或筆名注冊就可以上升為完全注冊。上述可靠性因素通常是可以在任何特定認證實例之前確定的值。這是因為他們基于注冊和技術而不是實際的認證。在一個實施例中，基于這些因素生成可靠性的步驟包括查找以前確定的用于該特定認證技術和用戶注冊數(shù)據(jù)的值。在本發(fā)明的一個有利實施例的另一方面，這樣的可靠性可以包括在注冊數(shù)據(jù)本身中。以該方式，這些因素連同從倉庫210發(fā)送的注冊數(shù)據(jù)一起被自動傳遞至認證引擎215。盡管這些因素通?？梢栽谌魏螁蝹€認證實例之前確定，但是他們?nèi)匀粚橛脩羰褂锰囟ㄕJ證技術的每個認證實例有影響。此外，盡管這些值可能隨著時間改變(例如，如果用戶以更可靠的方式重新注冊)，但是他們不取決于認證數(shù)據(jù)本身。相反，與單個特定實例的數(shù)據(jù)相關聯(lián)的可靠性因素可能隨每個情況而改變。如下所討論，對于每個新認證，都必須評估這些因素，從而在步驟1815生成可靠性分數(shù)。認證數(shù)據(jù)的可靠性反映了由用戶在特定認證實例中提供的數(shù)據(jù)與在認證注冊期間提供的數(shù)據(jù)之間的匹配。這是認證數(shù)據(jù)是否匹配于用戶聲稱是其的個人的注冊數(shù)據(jù)的基本問題。通常，當數(shù)據(jù)不匹配時，用戶被認為是沒有被成功認證，并且認證失敗。被評估的方式可以根據(jù)所使用的認證技術而改變。這種數(shù)據(jù)的比較是由圖5中所示的認證引擎215的比較器515功能來實現(xiàn)的。例如，口令的匹配通常以二元(binary)形式評估。換句話說，口令或者是完美匹配，或者是失敗匹配。通常不期望接受即使是部分匹配，即口令接近正確口令但不是完全正確。因此，當評估口令認證時，由比較器515返回的認證的可靠性通常是100% (正確)或0%(錯誤)，而沒有中間值的可能。與用于口令的規(guī)則相類似的規(guī)則通常被應用于基于令牌的認證方法，例如智能卡。這是因為擁有具有類似標識符的智能卡或類似于正確智能卡的智能卡，仍然如同擁有任何其他不正確令牌一樣是錯誤的。因此，令牌也趨向于是二元認證:用戶或者具有正確令牌，或者不具有。然而，某些類型的認證數(shù)據(jù)，諸如問卷和生物識別，通常不是二元認證。例如，指紋可以與參考指紋具有不同程度的匹配。某種程度上，這可能是由于在初始注冊或在后續(xù)認證過程中獲取的數(shù)據(jù)質(zhì)量的變化。(指紋可能被弄臟或人可能在特定手指上具有靜態(tài)愈合的傷疤或燒傷)。在其他情況下，數(shù)據(jù)可能匹配得不夠完美，這是因為信息本身在某種程度上是可變的并且是基于圖案匹配。(由于背景噪聲、或者錄制語音的環(huán)境的音響效果、或者由于該人感冒了，而導致語音分析可能像是接近但不完全正確)。最后，在大量數(shù)據(jù)被比較的情形中，情況可能是大部分數(shù)據(jù)匹配很好而一些匹配不好。(十個問題的問卷可能導致個人問題中八個正確答案，但是兩個不正確答案)。由于這些原因中的任一個，注冊數(shù)據(jù)和用于特定認證實例的數(shù)據(jù)之間的匹配可能期望由比較器515賦予一個部分匹配值。以該方式，例如，可以假定指紋85%匹配，聲紋65%匹配，以及問卷80%匹配。由比較器515產(chǎn)生的測量結(jié)果(匹配度)是表示認證是否正確這一基本問題的因素。然而，如上所述，這僅是可用于確定給定認證實例的可靠性的多個因素之一。還注意，即使能夠確定某種部分程度的匹配，最終還是期望基于部分匹配來提供二元結(jié)果。在一種可替換的操作模式中，也可以基于匹配度是否通過特定的閾值匹配水平將部分匹配當做二元的，即，完美匹配(100%)或失敗匹配(0%)。這樣的處理可以被用來為否則將產(chǎn)生部分匹配的系統(tǒng)提供簡單的通過/失敗匹配等級。在評估給定認證實例的可靠性時考慮的另一因素是關于提供用于該特定實例的認證數(shù)據(jù)的環(huán)境。如上所述，環(huán)境指的是與特定認證實例相關聯(lián)的元數(shù)據(jù)。這可包括但不限于這樣的信息:認證者的網(wǎng)絡地址，到其能夠被確定的程度；認證的時間；認證數(shù)據(jù)的傳輸模式(電話線、蜂窩網(wǎng)絡等)；以及認證者的系統(tǒng)的序列號。這些因素可以被用來產(chǎn)生通常由用戶請求的認證的類型的簡檔(profile)。然后，該信息可以被用來以至少兩種方式評估可靠性。一種方式是考慮用戶是否正以與該用戶的認證的正常簡檔相一致的方式請求認證。如果用戶正常情況下在工作日(當其工作時)從一個網(wǎng)絡地址進行認證請求而在晚間或周末(當其在家時)從一不同的網(wǎng)絡地址進行認證請求，那么在工作日期間從家庭地址發(fā)生的認證就不那么可靠，因為這是在正常認證簡檔之外的。類似地，如果用戶正常情況下使用指紋生物識別并且在晚間進行認證，則在白天僅使用口令發(fā)起的認證就不那么可靠。環(huán)境元數(shù)據(jù)可以被用來評估認證實例的可靠性的另一方法是確定環(huán)境提供多少證據(jù)來證明認證者就是其所聲稱的個人。例如，如果認證來自于具有已知是與用戶相關聯(lián)的序列號的系統(tǒng)，則其是良好的環(huán)境指示器，指示用戶是其聲明的用戶。相反，如果認證來源于已知在洛杉磯的網(wǎng)絡地址而已知用戶居住在倫敦時，這就指示，基于其環(huán)境，該認證是不可靠的。Cookie或其他電子數(shù)據(jù)也可能被放置在當用戶與賣方系統(tǒng)或信任引擎110交互時由用戶使用的系統(tǒng)上。該數(shù)據(jù)被寫入用戶的系統(tǒng)的存儲器，并且可以包括可以由用戶系統(tǒng)上的網(wǎng)絡瀏覽器或其他軟件讀取的標識。如果允許該數(shù)據(jù)在會話之間駐留在用戶系統(tǒng)上(“持續(xù)的cookie”)，其可以在認證特定用戶期間作為過去使用過該系統(tǒng)的進一步證據(jù)與認證數(shù)據(jù)一起被發(fā)送。事實上，給定實例的元數(shù)據(jù)，特別是持續(xù)的cookie，其本身可以形成一種基于令牌的認證者。一旦基于認證實例的技術和數(shù)據(jù)的適當可靠性因素如在上面步驟1610和1615中分別描述的那樣被生成，它們就被用來產(chǎn)生在步驟1620中提供的認證實例的總可靠性。實現(xiàn)這個的一種方式是簡單地將每個可靠性表示為百分數(shù)，然后將它們相乘。例如，假設認證數(shù)據(jù)是從已知是完全符合用戶過去的認證簡檔的用戶家庭計算機的網(wǎng)絡地址發(fā)送的(100%)，并且所使用的技術是指紋識別(97%)，并且初始指紋數(shù)據(jù)是通過用戶的雇主使用信任引擎110登記的(90%)，并且認證數(shù)據(jù)和注冊數(shù)據(jù)中的原始指紋模板之間的匹配非常好(99%)。則該認證實例的總可靠性可以被計算為這些可靠性的乘積:100%*97%*90%*99%-86.4% 可靠性。這樣計算的可靠性表示一個單個認證實例的可靠性。單個認證實例的總可靠性還可以使用不同地對待不同可靠性因素的技術來計算，例如，通過使用將不同權重分配給每個可靠性因素的公式。此外，本領域的技術人員將意識到所使用的實際值可以表示百分比之外的值，并且可以使用非算術系統(tǒng)。一個實施例可以包括由認證請求者使用以便為每個因素設置權重的模塊，以及用于建立認證實例的總可靠性的算法。認證引擎215可以使用上述技術及其變型來確定單個認證實例的可靠性，如步驟1620所示。然而，在許多認證情況下，同時提供多個認證實例可能是有用的。例如，當嘗試使用本發(fā)明的系統(tǒng)認證自身時，用戶可以提供用戶標識、指紋認證數(shù)據(jù)、智能卡以及口令。在這樣情況下，三個獨立的認證實例被提供至信任引擎110供評估。進行到步驟1625，如果認證引擎215確定由用戶提供的數(shù)據(jù)包括多于一個認證實例，則每個實例依次如在步驟1630中所示的被選擇以及如上面步驟1610、1615和1620中所述的被評估。注意，所討論的許多可靠性因素因?qū)嵗?。例如，這些技術的固有可靠性很可能不同，在認證數(shù)據(jù)和注冊數(shù)據(jù)之間提供的匹配度也可能不同。此外，用戶可能在不同時間和在不同環(huán)境下為這些技術中的每一種技術提供了注冊數(shù)據(jù)，這為這些實例中的每個實例提供不同的注冊可靠性。最后，即使這些實例中的每個實例被提交的環(huán)境是相同的，這些技術的使用可能每個都不同地適合用戶的簡檔，因此可以被賦予不同的環(huán)境可靠性。(例如，用戶可能在正常情況下使用其口令和指紋，而不是其智能卡)。因此，這些認證實例中的每個實例的最終可靠性可能彼此不同。然而，通過一起使用多個實例，認證的總可信度趨向于增加。一旦認證引擎已經(jīng)對認證數(shù)據(jù)中提供的所有認證實例執(zhí)行了步驟1610至1620，每個實例的可靠性被用在步驟1635中以評估總的認證可信度。將單個認證實例的可靠性合并成認證可信度的處理可以用各種將所產(chǎn)生的單獨可靠性聯(lián)系起來的方法來建模，也可以處理這些認證技術中的一些認證技術之間的特定相互作用。(例如,諸如多個口令之類的多個基于知識的系統(tǒng)產(chǎn)生的可信度可以小于單個口令和甚至相當弱的生物識別(諸如基本語音分析)的可信度。)認證引擎215可以合并多個同時存在的認證實例的可靠性以生成最終可信度的一種方式是，將每個實例的不可靠性相乘以得到總的不可靠性。不可靠性通常是可靠性的互補百分比。例如，可靠性為84%的技術的不可靠性是16%。產(chǎn)生86%、75%和72%的可靠性的上面所述三個認證實例(指紋、智能卡、口令)分別具有對應的不可靠性(100-86)%、(100-75) %和(100-72) %，或14%、25%和28%。通過將這些不可靠性相乘，我們得到累積不可靠性14%*25%*28%——0.98%的不可靠性，對應于99.02%的可靠性。在另一操作模式中，另外的因素和試探法530可以被應用在認證引擎215中以解釋各種認證技術的相互依賴。例如，如果有人已經(jīng)未經(jīng)授權地訪問了特定家庭計算機，則他們可能也能夠訪問該地址的電話線。因此，既基于發(fā)起電話號碼也基于認證系統(tǒng)序列號的認證不會對認證的總可信度增加很多。然而，基于知識的認證大大地獨立于基于令牌的認證(即，如果有人竊取了你的蜂窩電話號碼或密鑰，如果他們不曾知道你的PIN或口令，他們就不再可能知道)。此外，不同的賣方或其他認證請求者可能希望為認證的不同方面不同地加權。這可以包括使用不同的加權因子或用于計算單個實例的可靠性的算法，以及使用不同方式來評估具有多個實例的認證事件。例如，某些類型的交易(例如公司電子郵件系統(tǒng))的賣方可能期望主要基于試探法和其他默認的環(huán)境數(shù)據(jù)來進行認證。因此，他們可以對跟元數(shù)據(jù)和其他與認證事件周圍的環(huán)境相關聯(lián)的關于簡檔的信息有關的因素應用高權重。由于除了在工作時間期間登錄到正確機器之外不向用戶要求別的，因此這種安排可以用來減輕用戶在正常操作時間期間的負擔。然而，另一賣方可能由于策略決定而給予來自特定技術的認證(例如指紋匹配)以最重的權重，其中該策略決定是，這種技術對于該特定賣方的目的而言最適于認證。在一種操作模式中，這些不同的權重可以由認證請求者在生成認證請求時定義，并與認證請求一起發(fā)送至信任引擎110。在另一操作模式中，這樣的選項也可以在認證請求者的初始注冊過程中被設置為優(yōu)選項并存儲在認證引擎中。一旦認證引擎215產(chǎn)生所提供的認證數(shù)據(jù)的認證可信度，該可信度就被用來在步驟1640中完成認證請求，并且該信息從認證引擎215轉(zhuǎn)發(fā)至交易引擎205，以便包括在至認證請求者的消息中。上述處理僅是示例性的，本領域的技術人員應該理解所述步驟不需要以所示的順序執(zhí)行，或者僅希望執(zhí)行某些步驟，或者可以期望步驟的多種組合。此外，如果環(huán)境允許，某些步驟，例如對所提供的每個認證實例的可靠性的評估，可以彼此并行執(zhí)行。在本發(fā)明的另一方面，提供了一種方法以適應當由上述處理產(chǎn)生的認證可信度不能滿足賣方或要求認證的其他方所需的信任等級時的情況。在諸如在所提供的可信度和所期望的信任等級之間存在差距的情況下，信任引擎110的操作員能夠為一方或雙方提供用于提供替換數(shù)據(jù)或要求的機會以彌補該信任差距。該處理在這里將被稱作“信任仲裁”。信任仲裁可以在如上面參考圖10和11所述的加密認證的框架中發(fā)生。如在此所示，賣方或其他方將請求與特定交易相關聯(lián)的特定用戶的認證。在一種情況下，賣方簡單地請求認證，或者肯定或者否定，并且在接收到來自用戶的適當數(shù)據(jù)之后，信任引擎110將提供這樣的二元認證。在諸如這些的情況下，為了保證肯定認證所需要的可信度是基于信任引擎110中設置的優(yōu)選項而確定的。然而，賣方可能要求特定的信任等級以完成特定交易也是有可能的。所要求的等級可以包括在認證請求中(例如，認證該用戶為98%的可信度)，或可以由信任引擎110基于與交易相關聯(lián)的其他因素確定(即認證該用戶為適于該交易)。一個這樣的因素可能是交易的經(jīng)濟價值。對于具有較大經(jīng)濟價值的交易，可能需要較高的信任度。類似地，對于具有高風險度的交易，可能需要高信任度。相反，對于或者低風險或者低價值的交易，賣方或其他認證請求者可能要求低的信任等級。信任仲裁的處理發(fā)生在圖10的步驟1050中信任引擎110接收認證數(shù)據(jù)的步驟與圖10的步驟1055中將認證結(jié)果返回到賣方的步驟之間。在這些步驟之間，如圖17所示，發(fā)生導致信任等級評估和可能的信任仲裁的處理。在執(zhí)行簡單的二元認證的情況下，如圖17所示的處理減少為使交易引擎205直接比較所提供的認證數(shù)據(jù)和被識別的用戶的注冊數(shù)據(jù)，如上參考圖10所述，將任何不同標記為否定認證。如圖17所示，在步驟1050中接收數(shù)據(jù)之后的第一步驟是在步驟1710中交易引擎205確定該特定交易的肯定認證所需的信任等級。該步驟可以由若干不同方法中的一種來執(zhí)行。所需的信任等級可以由認證請求者在進行認證請求時指定給信任引擎110。認證請求者還可以事先設置優(yōu)選項，其被存儲在倉庫210或可由交易引擎205訪問的其他存儲器中。該優(yōu)選項然后可以在每次由該認證請求者進行認證請求時讀取和使用。該優(yōu)選項還可以與特定用戶相關聯(lián)作為安全性度量，使得總是需要特定的信任等級來認證該用戶，用戶優(yōu)選項存儲在倉庫210或其他可由交易引擎205訪問的存儲介質(zhì)中。所需的等級也可以由交易引擎205或認證引擎215基于在認證請求中提供的信息而獲得，所述信息諸如要認證的交易的價值和風險等級。在一種操作模式中，在生成認證請求時所使用的策略管理模塊或其他軟件被用來規(guī)定認證該交易所需的信任度。這可以被用來提供在基于在策略管理模塊中規(guī)定的策略而賦予所需信任等級時要遵循的一系列規(guī)則。對于這樣的模塊，一種有利的操作模式是與賣方的web服務器合并以適當?shù)卮_定使用賣方的web服務器啟動的交易所需的信任等級。以該方式，來自用戶的交易請求可以被賦予與賣方的策略一致的所需信任等級，并且這樣的信息可以連同認證請求一起被轉(zhuǎn)發(fā)至信任引擎110。所需的信任等級與賣方想要的該認證個體事實上就是他將自己標識為的那個人的確定度有關。例如，如果交易是賣方想要普通確定度的交易——因為貨物是易手，則賣方可能要求85%的信任等級。對于賣方僅是認證用戶以允許他觀看會員專用內(nèi)容或在聊天室享有特權，則負面風險很小以至賣方僅要求60%的信任等級。然而，為了訂立價值幾萬美金的生產(chǎn)合同，賣方可能要求99%或更高的信任等級。該要求的信任等級代表用戶必須認證自己以便完成該交易的衡量標準。如果所要求的信任等級例如是85%，則用戶必須向信任引擎110提供足以使信任引擎110具有85%信心認為該用戶是他們所聲稱的那個用戶的認證。這是在該要求的信任等級和認證可信度之間的平衡，其或者產(chǎn)生肯定認證(令賣方滿意)，或者產(chǎn)生信任仲裁的可能。如圖17所示，在交易引擎205接收所要求的信任等級后，在步驟1720中將所要求的信任等級與認證引擎215為當前認證所計算的認證可信度(如圖16所討論的)進行比較。如果在步驟1730中認證可信度高于交易所要求的信任等級，則處理進行到步驟1740，由交易引擎205產(chǎn)生對于該交易的肯定認證。帶有這個意思的消息然后被插入認證結(jié)果中并通過交易引擎205返回至賣方，如步驟1055中所示(見圖10)。然而，如果在步驟1730中認證可信度不能滿足所要求的信任等級，則當前認證存在信任差距，并且在步驟1750中進行信任仲裁。下面將參考圖18更全面地描述信任仲裁。如下所述的該處理在信任引擎110的交易引擎205中發(fā)生。因為執(zhí)行信任仲裁不需要認證或其他加密操作(除了交易引擎205和其他部件之間的SSL通信所需的)，該處理可以在認證引擎215的外部執(zhí)行。然而，如下所討論的，認證數(shù)據(jù)或其他加密或認證事件的任何重新評估都將要求交易引擎205重新提交適當數(shù)據(jù)至認證引擎215。本領域的技術人員應該意識到，信任仲裁處理可以可替換地被構(gòu)造成部分或全部在認證引擎215本身中發(fā)生。如上所述，信任仲裁是信任引擎110調(diào)解賣方和用戶之間的協(xié)商以嘗試酌情保證肯定認證的處理。如在步驟1805中所示，交易引擎205首先確定當前狀態(tài)是否適于信任仲裁。這可以基于認證的環(huán)境來確定，例如，如下面將進一步討論的，基于該認證是否已經(jīng)經(jīng)過多次仲裁循環(huán)，以及基于賣方或用戶的優(yōu)選項。在仲裁不可能的環(huán)境下，處理進行到步驟1810，在此交易引擎205生成否定認證，然后將其插入在步驟1055 (見圖10)中發(fā)送至賣方的認證結(jié)果中。一個可以被有利地使用以防止認證無限期待定的限制是設置從初始認證請求開始的超時周期。以該方式，任何在該期限內(nèi)未被肯定認證的交易被拒絕進一步仲裁并被否定認證。本領域的技術人員應該意識到，這樣的期限可以根據(jù)交易的環(huán)境以及用戶和賣方的期望而改變。也可以基于在提供成功認證時可進行的嘗試次數(shù)來設置多種限制。這樣的限制可以由如圖5所示的嘗試限制器535來處理。如果在步驟1805中沒有禁止仲裁，則交易引擎205將參與與交易一方或雙方的協(xié)商。如在步驟1820中所示的，交易引擎205可以發(fā)送消息至用戶以請求某種形式的附加認證，以便提升所產(chǎn)生的認證可信度。最簡單的形式，這可以簡單地表明認證不足。也可以發(fā)送產(chǎn)生一個或多個另外的認證實例以改進認證的總可信度的請求。如果用戶在步驟1825提供一些另外的認證實例，則交易引擎205將這些認證實例增加到用于交易的認證數(shù)據(jù)并將其轉(zhuǎn)發(fā)至認證引擎215，如步驟1015中所示(見圖10)，并基于之前已有的該交易的認證實例和新提供的認證實例重新評估該認證。一種附加的認證類型可以是來自信任引擎110的請求在信任引擎110操作者(或可信的同事)與用戶之間進行某種形式的人與人的聯(lián)系(例如通過電話)的請求。該電話或其他非計算機認證可以被用來提供與該個人的個人聯(lián)系以及進行基于認證的某種形式的問卷。這還給出校驗發(fā)起的電話號碼和潛在的在用戶打進電話時對其進行語音分析的機會。即使不能提供另外的認證數(shù)據(jù)，與用戶的電話號碼相關聯(lián)的附加情境可以提高認證情境的可靠性?；谠撾娫挼娜魏涡抻喌臄?shù)據(jù)或環(huán)境都被提供至信任引擎110，供考慮認證請求時使用。此外，在步驟1820，信任引擎110可以為用戶提供購買保險的機會，以有效地購買更確信的認證。信任引擎110的操作者有時僅希望在認證的可信度高于開始的一定閾值的情況下使這樣的選項可用。事實上，這種用戶側(cè)保險是信任引擎110在認證滿足信任引擎110對于認證的正常所需信任等級但是不滿足賣方對于該交易所要求的信任等級時擔保用戶的方式。以該方式，用戶仍可以成功地認證至賣方所要求的非常高的等級，即使他僅僅具有產(chǎn)生足以用于信任引擎110的可信度的認證實例。信任引擎110的該功能允許信任引擎110為被認證為滿足信任引擎110而不滿足賣方的人擔保。這類似于由公證員執(zhí)行的功能，即，將其簽名添加至文檔以向后面讀取該文檔的人表明其簽名出現(xiàn)在文檔上的人就是事實上簽名的人。公證員的簽名證明用戶簽名的動作。以相同的方式，信任引擎提供交易人就是他們所聲稱的人的指示。然而，因為信任引擎110人為地提升由用戶提供的可信度，因此，對于信任引擎110操作者來說存在較大風險，這是因為用戶實際上沒有達到賣方所要求的信任等級。保險的費用被設計為抵消信任引擎110 (其可以有效地公證用戶的認證)的錯誤肯定認證的風險。用戶付款給信任引擎110操作者以承擔認證至高于實際已提供的可信度的風險。因為這樣的保險系統(tǒng)允許某個人從信任引擎110有效購買較高信任評級，所以賣方和用戶可能都希望防止在某些交易中使用用戶側(cè)保險。賣方可能希望將肯定認證限制到他們知道實際認證數(shù)據(jù)支持他們所需的可信度的情況，因而可能指示信任引擎110不允許用戶側(cè)保險。類似地，為了保護他的在線身份，用戶可能希望防止在其帳戶上使用用戶側(cè)保險，或可能希望對于沒有保險時的認證可信度高于一定限度的情況限制該保險的使用。這可以被用作安全措施以防止有人偷聽口令或盜取智能卡并使用它們來錯誤地認證為低的可信度，然后購買保險來產(chǎn)生非常高的(錯誤的)可信度。在確定是否允許用戶側(cè)保險時可以評估這些因素。如果在步驟1840中用戶購買保險，則在步驟1845中，認證可信度基于所購買的保險被調(diào)整，以及在步驟1730中，認證可信度和所要求的信任等級再次被比較(見圖17)。處理從這里繼續(xù)，并且可能進行到步驟1740中的肯定認證(見圖17)或回到步驟1750中的信任仲裁處理，以便進一步仲裁(如果允許)或在進一步仲裁被禁止的情況下進行步驟1810中的否定認證。除了在步驟1820中發(fā)送信息至用戶之外，交易引擎205還在步驟1830中發(fā)送消息至賣方，表示待定認證目前低于所要求的信任等級。該消息還向賣方提供關于如何繼續(xù)進行的各種選項。這些選項之一是簡單地通知賣方當前認證可信度是什么以及詢問賣方是否希望維持其當前未滿足的所要求信任等級。這樣是有好處的，因為在一些情況下，賣方可能具有用于認證該交易的獨立方式，或者可能已經(jīng)使用默認的一組要求，其通常導致初始規(guī)定的所需等級高于其手邊的特定交易實際需要的等級。例如，標準作法可能期望該賣方的所有進入的購買訂單交易都滿足98%的信任等級。然而，如果訂單是近來通過電話在賣方和長期顧客之間討論的，并且然后馬上認證該交易，但是僅達到93%可信度，則賣方可能希望簡單地降低對于該交易的接受閾值，因為電話有效地向賣方提供了附加認證。在某些情況下，賣方可能愿意降低其所要求的信任等級，但是不是一直降低到當前認證的可信度。例如，上述示例中的賣方可能認為在該訂單之前的電話可以值得所需信任度減少4%，然而，這還是大于由用戶產(chǎn)生的93%的可信度。如果在步驟1835中賣方不調(diào)節(jié)其所要求的信任等級，則通過認證產(chǎn)生的認證可信度和所要求的信任等級在步驟1730中被比較(見圖17)。如果可信度現(xiàn)在超過了所要求的信任等級，則在步驟1740中在交易引擎205中可以生成肯定認證(見圖17)。如果沒有超過，則如果允許的話，可以如上所述地嘗試進一步仲裁。
除了請求調(diào)節(jié)所要求的信任等級，交易引擎205還可以向請求認證的賣方提供賣方側(cè)保險。該保險起到類似于上述用戶側(cè)保險的目的。然而，在這里，當接受認證中的較低信任等級時，保險的費用對應于由賣方承擔的風險，而不同于在認證高于所產(chǎn)生的實際認證可信度時，費用對應于由信任引擎110所承擔的風險的情況。代替僅減低他們實際所要求的信任等級，賣方可以選擇購買保險以使其避免與在認證用戶時的較低信任等級相關聯(lián)的其它風險。如上所述，對于賣方來說，僅僅在現(xiàn)有認證已經(jīng)高于某個閾值的情況下考慮購買這樣的保險來彌補信任差距是有利的。提供這樣賣方側(cè)保險使得賣方能夠選擇:直接降低他的信任要求而無需他的附加花費，自己承擔錯誤認證的風險(基于所要求的較低信任等級)；或者為認證可信度和其要求之間的信任差距購買保險，使信任引擎110操作者承擔已提供的較低可信度的風險。通過購買保險，賣方有效地保持其高的信任等級要求；因為錯誤認證的風險被轉(zhuǎn)移到信任引擎110操作者。如果在步驟1840中賣方購買保險，則在步驟1730中比較認證可信度和所要求的信任等級(見圖17)，并且處理如上所述地繼續(xù)。注意，用戶和賣方也可以都響應來自信任引擎110的消息。本領域技術人員應該意識到存在多種能夠處理這樣的情況的方法。處理多個響應的可能性的一種有利模式是簡單地以先到先服務的方式對待響應。例如，如果賣方以降低所要求的信任等級作為響應，并且緊跟其后用戶也購買了保險來提高他的認證等級，則認證首先基于來自賣方的降低的信任要求而被重新評估。如果認證現(xiàn)在是肯定的，則用戶的保險購買被忽略。在另一種有利的操作模式中，用戶可能僅被收取滿足新的降低的賣方信任要求所需的保險等級的費用(如果即使使用降低的賣方信任要求，仍然存在信任差距)。在為認證設置的時限之內(nèi)，如果沒有來自任一方的響應在步驟1850的信任仲裁處理期間被接收到，則在步驟1805中重新評估仲裁。這就有效地再次開始仲裁處理。如果時限結(jié)束或其他情況阻止在步驟1805中的進一步仲裁，則由交易引擎205在步驟1810中生成否定認證，并在步驟1055 (見圖10)中返回至賣方。如果不是，則新消息可以發(fā)送至用戶和賣方，并且處理可以根據(jù)需要被重復。注意，對于某些類型的交易，例如，對文檔進行數(shù)字簽名，其不是交易的一部分，可能不一定存在賣方或其他第三方；因此，該交易主要是在用戶和信任引擎110之間。在這樣的情況下，信任引擎110將具有其本身要求的信任等級，其必須被滿足以生成肯定認證。然而，在這樣的情況下，信任引擎110通常不希望向用戶提供保險以使他增加他自己的簽名的可信度。上面所述的以及在圖16-18中示出的處理可以使用如上參考信任引擎110所述的各種通信模式來執(zhí)行。例如，消息可以是基于網(wǎng)絡的，并使用信任引擎110與實時下載到在用戶或賣方系統(tǒng)上運行的瀏覽器的小程序之間的SSL連接來發(fā)送。在替換的操作模式中，用戶和賣方可以使用某些專用應用程序，其有助于這樣的仲裁和保險交易。在另一替換的操作模式中，可以使用安全電子郵件操作來調(diào)解上述仲裁，從而允許延遲的評估和認證批處理。本領域的技術人員應該理解，可以使用適合于環(huán)境和賣方的認證要求的不同的通信模式。下面參考圖19的說明描述結(jié)合了上述本發(fā)明各個方面的范例交易。該示例示出了由信任引擎110調(diào)解的在用戶和賣方之間的整個處理。盡管上面具體描述的各個步驟和部件可以被用來執(zhí)行下面的交易，但是所描述的處理集中在信任引擎110、用戶和賣方之間的相互作用。在步驟1900，當用戶在線觀看網(wǎng)頁時填寫賣方的網(wǎng)站上的訂單時，交易開始。用戶希望將該使用他的數(shù)字簽名來簽名的訂單提交至賣方。為了實現(xiàn)該目的，在步驟1905，用戶將訂單和其簽名請求一起提交至信任引擎110。用戶還提供將如上所述用于認證其身份的認證數(shù)據(jù)。在步驟1910，信任引擎110如上所述地將認證數(shù)據(jù)與注冊數(shù)據(jù)進行比較，如果產(chǎn)生肯定認證，則將用該用戶的私鑰簽名的訂單的散列連同訂單本身一起轉(zhuǎn)發(fā)至賣方。在步驟1915，賣方接收該簽名的訂單，然后在步驟1920，賣方將生成發(fā)貨單(invoice)或其他與將進行的購買有關的合同。在步驟1925，該合同連同簽名請求被發(fā)送回用戶。在步驟1930，賣方還向信任引擎110發(fā)送對該合同交易的認證請求，包括將由雙方簽名的合同的散列。為了使合同能夠被雙方數(shù)字簽名，賣方還包括其本身的認證數(shù)據(jù)，從而如有必要，賣方在該合同上的簽名還可以在以后被校驗。如上所討論的，信任引擎110然后校驗賣方提供的認證數(shù)據(jù)以確認賣方的身份，以及如果在步驟1935中該數(shù)據(jù)產(chǎn)生肯定認證，則在從用戶接收到數(shù)據(jù)時繼續(xù)步驟1955。如果賣方的認證數(shù)據(jù)不與賣方的注冊數(shù)據(jù)匹配至期望程度，則返回消息至賣方以請求進一步認證。如上所述的，如有必要，在此可以執(zhí)行信任仲裁，以便賣方向信任引擎110成功認證其本身。在步驟1940，當用戶接收到該合同時，他檢查該合同，在步驟1945生成認證數(shù)據(jù)以便在合同可接受的情況下簽署該合同，然后在步驟1950發(fā)送合同的散列和他的認證數(shù)據(jù)至信任引擎110。在步驟1955，信任引擎110校驗該認證數(shù)據(jù)，并且如果認證良好，則如下所述地繼續(xù)處理該合同。如上參考圖17和18所述，信任仲裁可以酌情執(zhí)行以彌補在認證可信度和交易所要求的認證等級之間的任何信任差距。在步驟1960，信任引擎110使用用戶的私鑰簽署合同的散列，并將該已簽名的散列發(fā)送至賣方，其中以其自己的名義簽署完整消息，即，包括用信任引擎110的私鑰510加密的完整消息(包括用戶的簽名)的散列。在步驟1965中，該消息被賣方接收。該消息代表已簽名的合同(用用戶的私鑰加密的合同的散列)以來自信任引擎110的收據(jù)(用信任引擎110的私鑰加密的、包括已簽名的合同的消息的散列)。在步驟1970中，信任引擎110類似地準備具有賣方的私鑰的合同的散列，并將由信任引擎110簽名的該合同的散列轉(zhuǎn)發(fā)至用戶。這樣，在步驟1975，用戶也接收到一份由賣方簽名的合同的副本，以及由信任弓丨擎110簽名的關于該已簽名的合同的交付的收據(jù)。除了上面所述，本發(fā)明的另一方面提供了加密服務提供者模塊(SPM)，其可以用于客戶端應用以作為用于訪問由上述信任引擎110提供的功能的手段。提供這樣的服務的一種有利方式是加密SPM作為中介實現(xiàn)第三方應用編程接口(API)與可通過網(wǎng)絡或其他遠程連接來訪問的信任引擎110之間的通信。下面參考圖20描述范例性的加密SPM。例如，在典型的系統(tǒng)上，多個API對于程序員可用。每個API提供一組函數(shù)調(diào)用，其可以被運行在系統(tǒng)上的應用程序2000調(diào)用。提供適于加密功能、認證功能和其他安全功能的編程接口的API的示例包括由微軟提供的使用其Windows操作系統(tǒng)的加密API(CAPI)2010、以及由IBM、Intel和The Open Group的其他成員提議的通用數(shù)據(jù)安全結(jié)構(gòu)(CDSA)。在下面的討論中將使用CAPI作為示例性安全API。但是，所述的加密SPM可以使用CDSA或本領域已知的其他安全API。在調(diào)用加密功能時，該API由用戶系統(tǒng)105或賣方系統(tǒng)120使用。包括在這些功能中的可能是與執(zhí)行各種加密操作相關聯(lián)的請求，諸如用特定私鑰加密文檔、簽名文檔、請求數(shù)字證書、校驗已簽名的文檔上的簽名、以及如在此所述或本領域技術人員已知的這類其他的加密功能。這樣的加密功能通常在CAPI2010所位于的系統(tǒng)處本地地執(zhí)行。這是因為通常所調(diào)用的功能需要使用本地用戶系統(tǒng)105的資源(例如，指紋讀取器)或用在本地機器上執(zhí)行的庫來編程的軟件功能。對這些本地資源的訪問通常由如上所述的一個或多個服務提供者模塊(SPM) 2015,2020提供，這些模塊提供執(zhí)行加密功能所使用的資源。這樣的SPM可以包括軟件庫2015以執(zhí)行加密或解密操作，或包括能夠訪問專用硬件的驅(qū)動器和應用程序2020，例如生物識別掃描裝置。以與CAPI2010提供可由系統(tǒng)105的應用程序2000使用的功能差不多的方式，SPM2015、2020向CAPI提供對與系統(tǒng)上可用的服務相關聯(lián)的較低等級的功能和資源的訪問。根據(jù)本發(fā)明，可以提供一種加密SPM2030，其能夠訪問由信任引擎110提供的加密功能，并且能夠通過CAPI2010使這些功能對于應用程序2000可用。不同于CAPI2010僅能夠通過SPM2015、2020訪問本地可用的資源的實施例，在此所述的加密SPM2030能夠向位于遠程的、網(wǎng)絡可訪問的信任引擎110提交加密操作請求以執(zhí)行期望的操作。例如，如果應用程序2000需要加密操作，例如簽署文檔，則應用程序2000對適當?shù)腃API2010函數(shù)進行函數(shù)調(diào)用。CAPI2010隨后執(zhí)行該函數(shù)，以使用由SPM2015、2020和加密SPM2030為其提供的資源。在數(shù)字簽名功能的情況下，加密SPM2030將生成將通過通信鏈路125發(fā)送至信任引擎110的適當請求。發(fā)生在加密SPM2030和信任引擎110之間的操作是與任何其他系統(tǒng)和信任引擎110之間可能的操作相同的操作。然而，這些功能通過CAPI2010被有效地提供至用戶系統(tǒng)105，從而在用戶系統(tǒng)105本身看來它們是本地可用的。然而，不同于一般的SPM2015、2020，這些功能是在遠程信任引擎110上執(zhí)行的，并且結(jié)果響應于適當?shù)恼埱笸ㄟ^通信鏈路125中繼到加密SPM2030。加密SPM2030使得原本可能不可用于用戶系統(tǒng)105或賣方系統(tǒng)12的大量操作對于用戶系統(tǒng)105或賣方系統(tǒng)120可用。這些功能包括但不限于:加密和解密文檔；發(fā)布數(shù)字證書；文檔的數(shù)字簽名；校驗數(shù)字簽名；以及對于本領域技術人員顯而易見的其他操作。在另一實施例中，本發(fā)明包括用于在任何數(shù)據(jù)集上執(zhí)行本發(fā)明的數(shù)據(jù)安全方法的完整系統(tǒng)。本發(fā)明的該計算機系統(tǒng)包括數(shù)據(jù)拆分模塊，其包括圖8中所示并在此描述的功能。在本發(fā)明的一個實施例中，數(shù)據(jù)拆分模塊(有時在此被稱為安全數(shù)據(jù)解析器)包括解析程序或軟件套件，其包括數(shù)據(jù)拆分、加密和解密、重建或重新組裝功能。該實施例還可以進一步包括一個數(shù)據(jù)存儲設備或多個數(shù)據(jù)存儲設備。數(shù)據(jù)拆分模塊或安全數(shù)據(jù)解析器包括跨平臺軟件模塊套件，其集成在電子基礎結(jié)構(gòu)中，或作為需要其數(shù)據(jù)元素極為安全的任何應用程序的插件。該解析處理對任何類型的數(shù)據(jù)集、以及對任何和所有文件類型進行操作，或在數(shù)據(jù)庫中對該數(shù)據(jù)庫中的任何數(shù)據(jù)行、列或單元進行操作。
在一個實施例中，本發(fā)明的解析處理可以以模塊化的分層形式來設計，并且任何加密處理都適于用在本發(fā)明的處理中。本發(fā)明的解析和拆分處理的模塊化層級可以包括但不限于:1)加密拆分，分散并安全存儲在多個位置；2)加密，加密拆分，分散并安全存儲在多個位置；3)加密，加密拆分，加密每份，然后分散并安全存儲在多個位置；以及4)加密，力口密拆分，用不同于在第一步驟中使用的加密類型加密每份，然后分散并安全存儲在多個位置。在一個實施例中，所述處理包括根據(jù)生成的隨機數(shù)的內(nèi)容或密鑰來拆分數(shù)據(jù)，以及對在要保護的數(shù)據(jù)的拆分的加密中使用的密鑰執(zhí)行相同的加密拆分，以形成兩個或更多部分或份的解析和拆分數(shù)據(jù)，并且在一個實施例中優(yōu)選地形成四個或更多部分的解析和拆分數(shù)據(jù)，加密所有部分，然后將這些部分分散并存回至數(shù)據(jù)庫，或?qū)⑺鼈冎匦路胖玫饺魏沃付ǖ难b置，這些裝置是固定或可移動的，取決于請求者對保密性和安全性的要求?？商鎿Q地，在另一實施例中，加密可以在由拆分模塊或安全數(shù)據(jù)解析器拆分數(shù)據(jù)集之前發(fā)生。如在此實施例中描述的那樣被處理的原始數(shù)據(jù)被加密和混亂(obfuscate)并且被保護。如果希望，加密元素的分散事實上可以在任何地方，包括但不限于單個服務器或數(shù)據(jù)存儲裝置，或在分開的數(shù)據(jù)存儲設備或裝置之間。在一個實施例中，加密密鑰管理可以被包括在軟件套件中，或者在另一實施例中，可以集成在已有基礎結(jié)構(gòu)或任何其他期望位置中。加密的拆分(加密拆分，cryptosplit)將數(shù)據(jù)劃分成N份。該劃分可以基于任何大小的數(shù)據(jù)單元，包括單個位、多個位、字節(jié)、千字節(jié)、兆字節(jié)或更大的單元，以及預定或隨機生成的數(shù)據(jù)單元大小的任何模式或組合?；陔S機或預定一組值，這些單元也可以具有不同的大小。這意味著數(shù)據(jù)可以被看做是這些單元的序列。以該方式，數(shù)據(jù)單元的大小本身可以使得數(shù)據(jù)更安全，例如，通過使用數(shù)據(jù)單元大小的一個或多個預定或隨機生成的模式、序列或組合。單元然后(隨機地或以預定的一組值)被分配成N份。該分配也可以包括打亂各份中的單元的順序。本領域的普通技術人員應該容易理解將數(shù)據(jù)單元分成多個份可以根據(jù)多種可能的選擇來執(zhí)行，包括但不限于固定大小、預定大小、或預定或隨機生成的數(shù)據(jù)單元大小的一種或多種組合、模式或序列。這種加密的拆分處理或加密拆分的一個示例將考慮數(shù)據(jù)的大小為23字節(jié)，數(shù)據(jù)單元大小被選擇為I字節(jié)，以及被選擇的份數(shù)是4。每個字節(jié)將被分配至這4份之一。假設隨機分配，密鑰可能被得到以創(chuàng)建具有23個隨機數(shù)(rl，r2, r3至r23)的序列，每個隨機數(shù)具有對應于4份的在I和4之間的值。每個數(shù)據(jù)單元(在該示例中有23個單獨字節(jié)的數(shù)據(jù))與對應于4份之一的23個隨機數(shù)之一相關聯(lián)。通過將數(shù)據(jù)的第一字節(jié)置于份號rl、字節(jié)2置于份r2、字節(jié)3置于份r3、直到數(shù)據(jù)的第23個字節(jié)置于份r23來將數(shù)據(jù)的各字節(jié)分配成4份。本領域的普通技術人員容易理解多種其他可能步驟和步驟的組合和序列，包括數(shù)據(jù)單元的大小，可以被應用在本發(fā)明的加密拆分處理中，并且上述示例是加密拆分數(shù)據(jù)的一種處理的非限制性描述。為了重新創(chuàng)建原始數(shù)據(jù)，將執(zhí)行相反操作。在本發(fā)明的加密拆分處理的另一實施例中，加密拆分處理的一個選項是提供份的足夠冗余，從而僅需要份的子集來重新組裝或恢復數(shù)據(jù)至其原始或可用形式。作為非限制示例，加密拆分可以作為“4中3個”加密拆分來執(zhí)行，從而4份中僅3份是必要的以重新組裝或恢復數(shù)據(jù)至其原始或可用形式。這也被稱為“N中M個加密拆分”，其中N是份的總數(shù)，以及M至少比N小I。本領域的技術人員應該理解在本發(fā)明的加密拆分處理中存在創(chuàng)建該冗余的多種可能性。在本發(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ù)據(jù)單元的數(shù)量的從I至3的另一組隨機數(shù)(也稱作備用份號)。每個數(shù)據(jù)單元然后與一個主份號和一個備用份號相關聯(lián)?？商鎿Q地，可以生成小于數(shù)據(jù)單元數(shù)量的一組隨機數(shù)，但是這可能降低敏感數(shù)據(jù)的安全性。主份號被用于確定數(shù)據(jù)單元被存儲在哪個份中。備用份號與主份號結(jié)合以創(chuàng)建O和3之間的第三份號，并且該號被用于確定數(shù)據(jù)單元被存儲在哪個份中。在該示例中，確定第三份號的等式是:(主份號+備用份號)M0D4=第三份號。在上述實施例中，主份號在O和3之間以及備用份號在I和3之間確保第三份號不同于主份號。這就導致數(shù)據(jù)單元存儲在兩個不同份中。本領域的技術人員容易理解除了在此公開的實施例，存在多種執(zhí)行冗余加密拆分和非冗余加密拆分的方法。例如，在每份中的數(shù)據(jù)單元可以使用不同算法被打亂。這種數(shù)據(jù)單元打亂例如可以在原始數(shù)據(jù)被拆分成數(shù)據(jù)單元時、或在數(shù)據(jù)單元被置于份中之后、或在份滿了之后執(zhí)行。在此描述的各種加密拆分處理和數(shù)據(jù)打亂處理，以及本發(fā)明的加密拆分和數(shù)據(jù)打亂方法的所有其他實施例可以在任何大小的數(shù)據(jù)單元上執(zhí)行，包括但不限于，與單個位一樣小、多位、字節(jié)、千字節(jié)、兆字節(jié)或更大。執(zhí)行在此所述的加密拆分處理的源代碼的一個實施例的一個示例是:DATA [1:24]-具有將被拆分的數(shù)據(jù)的字節(jié)數(shù)組SHARES
_2維數(shù)組，每行代表份之一
RANDOM [1:24]-在0..3范圍內(nèi)的數(shù)組隨機數(shù)SI = I ；S2 = I ；S3 = I ；S4 = I ；
權利要求
1.一種用于管理加密密鑰的方法，所述方法包括: 從第一接口接收管理遠離所述第一接口存儲的至少一個加密密鑰的請求； 將所述請求從第一接口格式轉(zhuǎn)換為公共接口格式； 通過至少校驗所述請求是從授權源發(fā)起的來認證所述請求；以及 執(zhí)行轉(zhuǎn)換后的具有所述公共接口格式的請求。
2.根據(jù)權利要求1所述的方法，其中，執(zhí)行轉(zhuǎn)換后的請求包括取回所述至少一個加密密鑰。
3.根據(jù)權利要求1所述的方法,其中，執(zhí)行轉(zhuǎn)換后的請求包括生成所述至少一個加密密鑰。
4.根據(jù)權利要求1所述的方法，其中，執(zhí)行轉(zhuǎn)換后的請求包括刪除所述至少一個加密密鑰。
5.根據(jù)權利要求1所述的方法，其中，執(zhí)行轉(zhuǎn)換后的請求包括在密鑰存儲器中存儲所述至少一個加密密鑰。
6.根據(jù)權利要求1所述的方法，其中，執(zhí)行轉(zhuǎn)換后的請求包括在可移動介質(zhì)上存儲所述至少一個加密密鑰。
7.根據(jù)權利要求1所述的方法，進一步包括使用所述至少一個加密密鑰來保護數(shù)據(jù)集，其中保護所述數(shù)據(jù)集包括: 使用所述至少一個加密密鑰來加密所述數(shù)據(jù)集； 生成隨機或偽隨機值； 至少部分基于所述隨機或偽隨機值，將所述數(shù)據(jù)集中的加密數(shù)據(jù)分配成兩份或更多份；以及 將所述兩份或更多份分開存儲在至少一個數(shù)據(jù)倉庫中。
8.根據(jù)權利要求7所述的方法，其中，將所述兩份或更多份分開存儲在至少一個數(shù)據(jù)倉庫中包括將所述兩份或更多份存儲在至少兩個地理上分開的數(shù)據(jù)倉庫中。
9.根據(jù)權利要求1所述的方法，進一步包括將所執(zhí)行的請求的至少一個返回參數(shù)從公共接口格式轉(zhuǎn)換為第一接口格式。
10.根據(jù)權利要求9所述的方法，其中，所執(zhí)行的請求的所述至少一個返回參數(shù)包括至少一個加密密鑰。
11.根據(jù)權利要求9所述的方法，進一步包括通過安全通信通道將所述至少一個返回參數(shù)傳輸至所述第一接口。
12.根據(jù)權利要求1所述的方法，其中，認證所述請求包括執(zhí)行認證協(xié)議或加密握手。
13.根據(jù)權利要求1所述的方法，其中，認證所述請求包括校驗與所述請求相關聯(lián)的加密簽名。
14.根據(jù)權利要求1所述的方法，其中，認證所述請求包括驗證認證令牌。
15.根據(jù)權利要求14所述的方法，其中，驗證認證令牌包括實施與所述認證令牌相關聯(lián)的截止日期或截止時間。
全文摘要
提供了一種用于管理加密密鑰的公共接口。管理加密密鑰的請求可以以第一接口格式被接收，被轉(zhuǎn)換為公共接口格式，然后遠離第一接口被執(zhí)行。返回參數(shù)然后可以從公共接口格式轉(zhuǎn)換為與第一接口兼容的格式并被安全地傳送至第一接口。加密密鑰可以與安全數(shù)據(jù)解析器聯(lián)合使用，其中安全數(shù)據(jù)解析器通過將數(shù)據(jù)集中的數(shù)據(jù)隨機分配成兩個或更多個份來保護數(shù)據(jù)。
文檔編號H04L9/08GK103152170SQ201310021829
公開日2013年6月12日 申請日期2008年9月12日 優(yōu)先權日2007年9月14日
發(fā)明者R·L·奧爾西尼, M·S·奧黑爾, R·達文波特 申請人:安全第一公司