用于安全分布式存儲的系統(tǒng)與方法
【專利摘要】提供了用于將客戶端計算設備引導至存儲在多個存儲位置上的數(shù)據(jù)部分的系統(tǒng)和方法。注冊/認證服務器接收來自客戶端計算設備的對于取回存儲在多個存儲位置處的數(shù)據(jù)部分的請求。注冊/認證服務器基于標準向客戶端計算設備提供指向可用存儲位置的指針，于是客戶端計算設備可取回數(shù)據(jù)部分并重構期望的數(shù)據(jù)集。
【專利說明】用于安全分布式存儲的系統(tǒng)與方法
[0001]對相關申請的交叉引用
[0002]本申請要求2011年6月I日提交的61/492，296號美國臨時申請的優(yōu)先權，這里通過引用并入該美國臨時申請的全部內(nèi)容。

【發(fā)明內(nèi)容】

[0003]本文描述了用于存儲安全分布式數(shù)據(jù)并且將客戶端計算設備引導至安全存儲的分布式數(shù)據(jù)的系統(tǒng)和方法。在一些方面中，提供了一種方法，該方法的步驟由編程的計算機系統(tǒng)實現(xiàn)。從計算設備接收對于識別多個存儲位置的請求。多個存儲位置中的每一個存儲由該請求標識的數(shù)據(jù)集的一部分，并且該數(shù)據(jù)集可以從該數(shù)據(jù)集的預定數(shù)目的部分恢復，所述預定數(shù)目的部分是該數(shù)據(jù)集的至少兩個部分并且少于該數(shù)據(jù)集的所有部分?；谝粋€或多個標準選擇來自多個存儲位置的至少預定數(shù)目的可用存儲位置。每個所選的存儲位置存儲該數(shù)據(jù)集的一部分，并且所選的存儲位置比多個存儲位置的全部更少的存儲位置。標識所選存儲位置的數(shù)據(jù)被發(fā)送到客戶端計算設備。在一些實現(xiàn)方式中，在接收對于識別多個物理上分離的存儲位置的請求之前，從不同于該客戶端計算設備的計算設備接收該數(shù)據(jù)集的多個部分，并且將該數(shù)據(jù)的多個部分存儲在多個物理上分離的存儲位置之中。
[0004]在一些實現(xiàn)方式中，可訪問性標準包括地理位置，并且多個存儲位置中的至少一個的地理位置被確定。在一些實現(xiàn)方式中，可訪問性標準包括負荷，并且多個存儲位置中的至少一個上的負荷被確定。負荷可以是存儲負荷和處理負荷中的至少一者。在一些實現(xiàn)方式中，基于與企業(yè)、產(chǎn)品、客戶端、用戶或請求相關聯(lián)的規(guī)則來選擇存儲位置。
[0005]在一些實現(xiàn)方式中，數(shù)據(jù)集的每個部分包括頭部和與該頭部相關聯(lián)的多個數(shù)據(jù)塊。在一些實現(xiàn)方式中，數(shù)據(jù)集的每個部分的頭部可通過指派給該頭部和每個數(shù)據(jù)塊的分部作業(yè)標識符來與該多個數(shù)據(jù)塊相關聯(lián)。
[0006]在這種實現(xiàn)方式中，可從多個存儲位置中的至少一個獲取頭部。頭部還可用于驗證與頭部相關聯(lián)的數(shù)據(jù)塊可用于恢復數(shù)據(jù)集?？蛻舳擞嬎阍O備可請求修改經(jīng)加密的數(shù)據(jù)集的一部分的頭部，并且經(jīng)加密的數(shù)據(jù)集的該部分的頭部可被修改?？蛻舳擞嬎阍O備還可請求利用新密鑰對數(shù)據(jù)集的一部分的頭部中的數(shù)據(jù)進行密鑰更新。數(shù)據(jù)集的該部分的頭部中的數(shù)據(jù)隨后被拆包，并利用新密鑰來重新包裹。
[0007]在一些實現(xiàn)方式中，如果確定在第一存儲位置處數(shù)據(jù)集的一部分對于客戶端計算設備是不可訪問的，則從至少預定數(shù)目的可用部分將數(shù)據(jù)集的該部分恢復到第一存儲位置。在一些實現(xiàn)方式中，至少一個存儲位置是云計算存儲位置。
【專利附圖】

【附圖說明】
[0008]以下聯(lián)系附圖更具體地描述本發(fā)明，附圖是要說明而不是限定本發(fā)明，而且其中:
[0009]圖1根據(jù)本發(fā)明一種實施例的各方面說明了密碼系統(tǒng)的框圖；
[0010]圖2根據(jù)本發(fā)明一種實施例的各方面說明了圖1信任引擎的框圖；[0011]圖3根據(jù)本發(fā)明一種實施例的各方面說明了圖2事務引擎的框圖；
[0012]圖4根據(jù)本發(fā)明一種實施例的各方面說明了圖2存儲庫的框圖；
[0013]圖5根據(jù)本發(fā)明一種實施例的各方面說明了圖2認證引擎的框圖；
[0014]圖6根據(jù)本發(fā)明一種實施例的各方面說明了圖2密碼引擎的框圖；
[0015]圖7根據(jù)本發(fā)明另一種實施例的各方面說明了存儲庫系統(tǒng)的框圖；
[0016]圖8根據(jù)本發(fā)明一種實施例的各方面說明了數(shù)據(jù)分割過程的流程圖；
[0017]圖9的面板A根據(jù)本發(fā)明一種實施例的各方面說明了注冊過程的數(shù)據(jù)流；
[0018]圖9的面板B根據(jù)本發(fā)明一種實施例的各方面說明了互操作性過程的流程圖；
[0019]圖10根據(jù)本發(fā)明一種實施例的各方面說明了認證過程的數(shù)據(jù)流；
[0020]圖11根據(jù)本發(fā)明一種實施例的各方面說明了簽署過程的數(shù)據(jù)流；
[0021]圖12根據(jù)本發(fā)明另一種實施例的各方面說明了數(shù)據(jù)流和加密/解密過程；
[0022]圖13根據(jù)本發(fā)明另一種實施例的各方面說明了信任引擎系統(tǒng)的簡化框圖；
[0023]圖14根據(jù)本發(fā)明另一種實施例的各方面說明了信任引擎系統(tǒng)的簡化框圖；
[0024]圖15根據(jù)本發(fā)明一種實施例的各方面說明了圖14冗余性模塊的框圖；
[0025]圖16根據(jù)本發(fā)明的一方面說明了用于評估認證的過程；
[0026]圖17根據(jù)本發(fā)明圖16中所示的一方面說明了用于給認證分配一個值的過程；
[0027]圖18說明了在圖17所示本發(fā)明的一方面中用于執(zhí)行信任仲裁的過程；及
[0028]圖19根據(jù)本發(fā)明一種實施例的各方面說明了用戶與賣方之間的樣本事務，其中最初基于網(wǎng)絡的聯(lián)系導致雙方簽署的銷售合同。
[0029]圖20說明了具有密碼服務提供者模塊的樣本用戶系統(tǒng)，其中密碼服務提供者模塊向用戶系統(tǒng)提供安全功能。
[0030]圖21說明了用于解析、分割和/或分離數(shù)據(jù)的過程，加密主密鑰與數(shù)據(jù)一起加密和儲存。
[0031]圖22說明了用于解析、分割和/或分離數(shù)據(jù)的過程，加密和存儲加密主密鑰與數(shù)據(jù)分開。
[0032]圖23說明了用于解析、分割和/或分離數(shù)據(jù)的中間密鑰過程，加密主密鑰與數(shù)據(jù)一起加密和儲存。
[0033]圖24說明了用于解析、分割和/或分離數(shù)據(jù)的中間密鑰過程，加密和存儲加密主密鑰與數(shù)據(jù)分開。
[0034]圖25說明了由小型工作組利用本發(fā)明的密碼方法和系統(tǒng)。
[0035]圖26是根據(jù)本發(fā)明的一種實施例、采用安全數(shù)據(jù)解析器的說明性物理標記安全系統(tǒng)的框圖。
[0036]圖27是根據(jù)本發(fā)明的一種實施例、其中安全數(shù)據(jù)解析器集成到一個系統(tǒng)中的說明性布置的框圖。
[0037]圖28是根據(jù)本發(fā)明一種實施例的說明性運動數(shù)據(jù)(data in motion)系統(tǒng)的框圖。
[0038]圖29是根據(jù)本發(fā)明一種實施例的另一種說明性運動數(shù)據(jù)系統(tǒng)的框圖。
[0039]圖30-圖32是根據(jù)本發(fā)明一種實施例、具有集成的安全數(shù)據(jù)解析器的說明性系統(tǒng)的框圖。
[0040]圖33是根據(jù)本發(fā)明一種實施例、用于解析和分割數(shù)據(jù)的說明性過程的過程流程圖。
[0041]圖34是根據(jù)本發(fā)明一種實施例、用于將數(shù)據(jù)部分恢復成原始數(shù)據(jù)的說明性過程的過程流程圖。
[0042]圖35是根據(jù)本發(fā)明一種實施例、用于在位級分割數(shù)據(jù)的說明性過程的過程流程圖。
[0043]圖36是根據(jù)本發(fā)明一種實施例的說明性步驟與特征的過程流程圖。
[0044]圖37是根據(jù)本發(fā)明一種實施例的示例性步驟與特征的過程流程圖。
[0045]圖38是根據(jù)本發(fā)明一種實施例、在份內(nèi)儲存密鑰和數(shù)據(jù)成分的簡化框圖。
[0046]圖39是根據(jù)本發(fā)明一種實施例、使用工作組密鑰在份內(nèi)儲存密鑰和數(shù)據(jù)成分的簡化框圖。
[0047]圖40A和圖40B是根據(jù)本發(fā)明一種實施例、用于對運動數(shù)據(jù)進行頭部生成和數(shù)據(jù)分割的簡化和說明性過程流程圖。
[0048]圖41是根據(jù)本發(fā)明一種實施例的說明性份格式的簡化框圖。
[0049]圖42A-圖42E是根據(jù)本發(fā)明一種實施例、繪出說明性安全共享系統(tǒng)的操作的框圖。
[0050]圖43說明了根據(jù)本發(fā)明一種實施例的一種實現(xiàn)，其中用戶設備的密碼共享客戶端配置成執(zhí)行組合的共享操作，以便與多個用戶安全地共享一個數(shù)據(jù)集。
[0051]圖44是根據(jù)本發(fā)明一種實施例、用于安全地共享數(shù)據(jù)的一種方法的說明性步驟的流程圖。
[0052]圖45是根據(jù)本發(fā)明一種實施例、在執(zhí)行圖44步驟4410的過程中處理器可以執(zhí)行的說明性子步驟的流程圖。
[0053]圖46是根據(jù)本發(fā)明一種實施例、用于根據(jù)圖44中說明的方法訪問安全共享的數(shù)據(jù)集的一種方法的說明性步驟的流程圖。
[0054]圖47是根據(jù)本發(fā)明一種實施例、用于安全地共享數(shù)據(jù)的一種方法的說明性步驟的流程圖。
[0055]圖48是根據(jù)本發(fā)明一種實施例、用于存儲分成部分的數(shù)據(jù)的說明性系統(tǒng)的框圖。
[0056]圖49A-C是根據(jù)本發(fā)明一種實施例、繪出圖48的系統(tǒng)中的數(shù)據(jù)的安全存儲的框圖。
[0057]圖50A-圖50E是根據(jù)本發(fā)明一種實施例、繪出用于從圖48的系統(tǒng)請求和接收存儲的數(shù)據(jù)的過程的框圖。
[0058]圖51根據(jù)本發(fā)明一種實施例說明了用于在圖48的系統(tǒng)中存儲數(shù)據(jù)的示范性數(shù)據(jù)結構。
[0059]圖52是根據(jù)本發(fā)明一種實施例、繪出圖48的系統(tǒng)的存儲位置不可用的場景的框圖。
[0060]圖53A-圖53C是根據(jù)本發(fā)明一種實施例、繪出用于在圖48的系統(tǒng)中將數(shù)據(jù)恢復到存儲位置的過程的框圖。
[0061]圖54是根據(jù)本發(fā)明一種實施例、繪出用于在圖48的系統(tǒng)的存儲位置中分布來自分部作業(yè)(portioning job)的頭部和數(shù)據(jù)塊的過程的框圖。
[0062]圖55是根據(jù)本發(fā)明一種實施例、繪出用于在圖48的系統(tǒng)的存儲位置中分布來自兩個解析分部作業(yè)的頭部和數(shù)據(jù)塊的過程的框圖。
[0063]圖56是根據(jù)本發(fā)明一種實施例、繪出數(shù)據(jù)頭部中存儲的數(shù)據(jù)的類型的框圖。
[0064]圖57A-圖57D是根據(jù)本發(fā)明一種實施例、繪出用于從圖48的系統(tǒng)中的存儲位置取回頭部的過程的框圖。
[0065]圖58A-圖58B是根據(jù)本發(fā)明一種實施例、繪出用于對如圖57A-圖57D中所示從存儲位置取回的頭部進行驗證的過程的框圖。
[0066]圖59A-圖59C是根據(jù)本發(fā)明一種實施例、繪出用于對如圖57A-圖57D中所示從存儲位置取回的頭部進行密鑰更新(rekey)的過程的框圖。
[0067]圖60A-圖60C是根據(jù)本發(fā)明一種實施例、繪出用于對如圖57A-圖57D中所示從存儲位置取回的頭部中的信息進行修改的過程的框圖。
[0068]圖61A-圖61E是根據(jù)本發(fā)明一種實施例、繪出用于對圖48的安全存儲系統(tǒng)中存儲的數(shù)據(jù)進行搜索的過程的框圖。
[0069]圖62是根據(jù)本發(fā)明一種實施例、用于在圖48的安全存儲系統(tǒng)中分配存儲的方法的說明性步驟的流程圖。
[0070]圖63是根據(jù)本發(fā)明一種實施例，用于將存儲位置返回給被解析數(shù)據(jù)存儲系統(tǒng)的用戶的方法的說明性步驟的流程圖。
[0071]圖64A-B是根據(jù)本發(fā)明一種實施例，用于基于可訪問性標準確定存儲位置的集合以返回給圖48的系統(tǒng)的用戶的方法的說明性步驟的流程圖。
[0072]圖65是根據(jù)本發(fā)明一種實施例，用于在圖48的系統(tǒng)中存儲數(shù)據(jù)的方法的說明性步驟的流程圖。
具體實施例
[0073]本文描述的系統(tǒng)和方法可以與2005年10月25日提交的共同擁有的美國專利號7，391，865和共同擁有的美國專利申請?zhí)?1/258，839、2006年11月20日提交的11/602，667、2007 年 11 月 7 日提交的 11/983，355、2007 年 12 月 5 日提交的 11/999,575、2008年4月18日提交的12/148，365,2008年9月12日提交的12/209，703,2009年I月7日提交的12/349，897、2009年2月23日提交的12/391，028、2010年5月19日提交的12/783，276、2010年11月24日提交的12/953，877、及2011年I月27日提交的美國臨時專利申請?zhí)?1/436，991、2009年11月25日提交的61/264，464、2010年3月31日提交的61/319，658,2010 年 4 月 I 日提交的 61/320，242,2010 年 5 月 28 日提交的 61/349，560、2010年8月12日提交的61/373，187及2010年9月20日提交的61/384，583中描述的其它系統(tǒng)和方法相結合使用。以上提到的早先提交的每個申請的公開內(nèi)容都在此全部引入作為參考。
[0074]本發(fā)明的一方面是提供一種密碼系統(tǒng),在該系統(tǒng)中，一個或多個安全服務器，或者說信任引擎，存儲密碼密鑰和用戶認證數(shù)據(jù)。用戶通過對信任引擎的網(wǎng)絡訪問來訪問傳統(tǒng)密碼系統(tǒng)的功能，但是，信任引擎不釋放真實的密鑰和其它認證數(shù)據(jù)，因此密鑰和數(shù)據(jù)保持安全。密鑰和認證數(shù)據(jù)的這種服務器集中儲存提供了獨立于用戶的安全性、便攜性、可用性和簡單明了性。
[0075]因為用戶可以確信，或者說信任，密碼系統(tǒng)執(zhí)行用戶和文檔認證及其它密碼功能，所以可以將多種功能結合到系統(tǒng)中。例如，信任引擎提供商能夠通過例如，認證協(xié)議參與方、為了參與方的利益或為了參與方而數(shù)字簽署協(xié)定、并且存儲由每個參與方數(shù)字簽署的協(xié)議的記錄，來確保防止否認協(xié)議。此外，密碼系統(tǒng)可以監(jiān)視協(xié)議并基于例如價格、用戶、賣方、地理位置、使用地點等來確定應用程度變化的認證。
[0076]為了便于對本發(fā)明的透徹理解，余下的具體描述參考附圖來描述本發(fā)明，其中相同的元素自始至終由相同的標號來標注。
[0077]圖1說明了根據(jù)本發(fā)明一種實施例的各方面的密碼系統(tǒng)100的框圖。如圖1所示，密碼系統(tǒng)100包括通過通信鏈路125通信的用戶系統(tǒng)105、信任引擎110、證書機構115和賣方系統(tǒng)120。
[0078]根據(jù)本發(fā)明的一種實施例，用戶系統(tǒng)105包括傳統(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 (浮雕對象圖像產(chǎn)生器)〃的美國專利申請?zhí)?08/926，277、2000 年 4 月 26 日提交的標題為〃IMAGING DEVICE FOR A RELIEF OBJECTAND SYSTEM AND METHOD OF USING THE IMAGE DEVICE (用于浮雕對象的成像設備和使用這種成像設備的系統(tǒng)和方法)〃的美國專利申請?zhí)?9/558，634、1999年11月5日提交的標題為〃RELIEF OBJECT SENSOR ADAPTOR (浮雕對象傳感器轉(zhuǎn)接器)〃的美國專利申請?zhí)?9/435，011 和 2000 年 I 月 5 日提交的標題為〃PLANAR OPTICAL IMAGE SENSOR AND SYSTEMFOR GENERATING AN ELECTRONIC IMAGE OF A RELIEF OBJECT FOR FINGERPRINT READING(平面光學成像傳感器和用于產(chǎn)生用于指紋讀取的浮雕對象的電子圖像的系統(tǒng))〃的美國專利申請?zhí)?9/477，943，所有這些申請都由本申請的受讓人擁有，而且其全部內(nèi)容都在此引入作為參考。
[0079]此外，用戶系統(tǒng)105可以通過例如像撥號、數(shù)字用戶線路(DSL)、線纜調(diào)制解調(diào)器、光纖連接等傳統(tǒng)的服務提供商連接到通信鏈路125。根據(jù)另一種實施例，用戶系統(tǒng)105通過例如像局域或廣域網(wǎng)的網(wǎng)絡連接而連接通信鏈路125。根據(jù)一種實施例，操作系統(tǒng)包括TCP/IP堆棧，TCP/IP堆棧對通過通信鏈路125傳遞的所有進入和外出的消息流量進行操縱。
[0080]盡管參考上述實施例公開了用戶系統(tǒng)105，但是本發(fā)明不是要這樣受到限制。相反，本領域技術人員將由本文的公開內(nèi)容意識到，用戶系統(tǒng)105的大量可選實施例幾乎包括能夠從另一個計算機系統(tǒng)發(fā)送或接收信息的任何計算設備。例如，用戶系統(tǒng)105可以包括、但不限于:計算機工作站，交互式電視，交互式公共電話亭，例如數(shù)字助理、移動電話、膝上型電腦等的個人移動計算設備，能夠與通信鏈路125交互的例如家庭路由器、網(wǎng)絡儲存設備("NAS")、個人熱點等，或無線通信設備、智能卡、嵌入式計算設備等的個人聯(lián)網(wǎng)設備。在這種可選系統(tǒng)中，操作系統(tǒng)將可能是不同的并且為特殊設備而改變。然而，根據(jù)一種實施例，操作系統(tǒng)有利地連續(xù)提供與通信鏈路125建立通信所需的適當通信協(xié)議。
[0081]圖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把與當前事務相關的用戶的認證數(shù)據(jù)與例如像在注冊期間更早時候提供的認證數(shù)據(jù)進行比較。信任引擎110可以有利地要求用戶在每次事務時產(chǎn)生認證數(shù)據(jù)，或者，信任引擎110可以有利地允許用戶定期產(chǎn)生認證數(shù)據(jù)，例如在一串事務開始的時候者或登錄到特定的賣方網(wǎng)站上時。
[0082]根據(jù)用戶產(chǎn)生生物測定數(shù)據(jù)的實施例，用戶向生物測定設備107提供一種物理特性，例如，但不限于:面部掃描、手掃描、耳朵掃描、虹膜掃描、視網(wǎng)膜掃描、血管圖案、DNA、指紋、筆跡或語音。生物測定設備有利地產(chǎn)生物理特性的電子圖案或生物測定。電子圖案通過用戶系統(tǒng)105被傳送給信任引擎110，用于注冊或認證目的。
[0083]一旦用戶產(chǎn)生了適當?shù)恼J證數(shù)據(jù)并且信任引擎110確定了認證數(shù)據(jù)(當前認證數(shù)據(jù))與注冊時提供的認證數(shù)據(jù)(注冊認證數(shù)據(jù))之間的肯定匹配，信任引擎110就向用戶提供完整的密碼功能。例如，得到正確認證的用戶可以有利地采用信任引擎110來執(zhí)行哈希、數(shù)字簽署、加密和解密(經(jīng)常合在一起僅被稱為加密)、產(chǎn)生或分發(fā)數(shù)字證書等。但是，密碼功能中使用的私人密碼密鑰在信任引擎110之外將不可用，由此確保密碼密鑰的完整性。
[0084]根據(jù)一種實施例，信任引擎110生成并存儲密碼密鑰。根據(jù)另一種實施例，至少有一個密碼密鑰與每個用戶關聯(lián)。而且，當密碼密鑰包括公共密鑰技術時，與用戶關聯(lián)的每個私人密鑰都在信任引擎110內(nèi)產(chǎn)生、并且不從信任引擎110釋放。因此，只要用戶有權訪問信任引擎110，用戶就可以使用他或她的私人或公共密鑰執(zhí)行密碼功能。這種遠程訪問有利地允許用戶通過事實上任何互聯(lián)網(wǎng)連接，例如蜂窩和衛(wèi)星電話、公共電話亭、膝上型電腦、旅館房間等，保持完全的移動和訪問密碼功能。
[0085]根據(jù)另一種實施例，信任引擎110利用為信任引擎110生成的密鑰對執(zhí)行密碼功能。根據(jù)這種實施例，信任引擎110首先認證用戶，并且在用戶具有與注冊認證數(shù)據(jù)匹配的正確產(chǎn)生的認證數(shù)據(jù)之后，信任引擎110為了被認證用戶的利益而使用它自己的密碼密鑰對來執(zhí)行密碼功能。
[0086]本領域技術人員將從本文公開的內(nèi)容認識到，密碼密鑰可以有利地包括對稱密鑰、公共密鑰和私人密鑰中的一些或全部。另外，本領域技術人員還將從本文公開的內(nèi)容認識到，可以利用可以從商業(yè)技術獲得的大量算法，例如像RSA、ELGAMAL等，實現(xiàn)上述密鑰。
[0087]圖1還說明性了證書機構115。根據(jù)一種實施例，證書機構115可以有利地包括頒發(fā)例如像VeriSign、Baltimore、Entrust等數(shù)字證書的被信任的第三方組織或公司。信任引擎110可以有利地通過例如PKCSlO的一種或多種傳統(tǒng)數(shù)字證書協(xié)議把對數(shù)字證書的請求傳輸?shù)阶C書機構115。作為響應，證書機構115將按照例如PKCS7的多種不同協(xié)議中的一種或多種協(xié)議頒發(fā)數(shù)字證書。根據(jù)本發(fā)明的一種實施例，信任引擎110從幾個或全部的著名證書機構115請求數(shù)字證書,使得證書機構115有權訪問對應于任何請求方的證書標準的數(shù)字證書。[0088]根據(jù)另一種實施例，信任引擎110在內(nèi)部執(zhí)行證書頒發(fā)。在這種實施例中，信任引擎110可以訪問證書系統(tǒng)以便生成證書和/或可以在它們被請求時，例如在生成密鑰時，或者可以按照請求時請求的證書標準在內(nèi)部生成證書。下面將更具體地公開信任引擎110。
[0089]圖1還說明了賣方系統(tǒng)120。根據(jù)一種實施例，賣方系統(tǒng)120有利地包括網(wǎng)絡服務器。典型的網(wǎng)絡服務器通常使用例如超文本標記語言(HTML)或可擴展標記語言(XML)的幾種互聯(lián)網(wǎng)標記語言或文檔格式標準之一經(jīng)互聯(lián)網(wǎng)提供內(nèi)容。網(wǎng)絡服務器接受來自像Netscape和Internet Explorer的瀏覽器的請求,然后返回適當?shù)碾娮游臋n。許多服務器或客戶側技術都能夠用于使網(wǎng)絡服務器的能力增大到超過它的能力，以交付標準電子文檔。例如，這些技術包括公共網(wǎng)關接口(CGI)腳本、加密套接字協(xié)議層(SSL)安全性和動態(tài)服務器主頁(ASP)。賣方系統(tǒng)120可以有利地提供與商業(yè)、個人、教育、或其它事務有關的電子內(nèi)容。
[0090]盡管參考上述實施例公開了賣方系統(tǒng)120，但是本發(fā)明不是要由此受到限制。相反，本領域技術人員將從本文公開的內(nèi)容認識到，賣方系統(tǒng)120可以有利地包括參考用戶系統(tǒng)105描述的任何設備或者其組合。
[0091]圖1還說明了連接用戶系統(tǒng)105、信任引擎110、證書機構115和賣方系統(tǒng)120的通信鏈路125。根據(jù)一種實施例，通信鏈路125優(yōu)選地包括互聯(lián)網(wǎng)。如貫穿本公開內(nèi)容所使用的，互聯(lián)網(wǎng)是計算機的全球網(wǎng)絡。本領域普通技術人員眾所周知的互聯(lián)網(wǎng)的結構包括網(wǎng)絡主干線，具有從網(wǎng)絡主干線開始的網(wǎng)絡分支。這些分支又具有從它們開始的網(wǎng)絡分支，以此類推。路由器在網(wǎng)絡級之間移動信息包，從一個網(wǎng)絡到另一個網(wǎng)絡，直到包到達其目的地的鄰居。目的地網(wǎng)絡的主機從該目的地引導信息包到達適當?shù)慕K端，或節(jié)點。在一種有利的實施例中，互聯(lián)網(wǎng)路由集線器包括使用本領域中眾所周知的傳輸控制協(xié)議/因特網(wǎng)協(xié)議(TCP/IP)的域名系統(tǒng)(DNS)服務器。路由集線器經(jīng)高速通信鏈路連接到一個或多個其它路由集線器。
[0092]互聯(lián)網(wǎng)的一個流行部分是萬維網(wǎng)。萬維網(wǎng)包含不同的計算機，這些計算機存儲能夠顯示圖形和文本信息的文檔。在萬維網(wǎng)上提供信息的計算機通常被稱為“網(wǎng)站”。網(wǎng)站是通過具有相關聯(lián)的電子頁面的互聯(lián)網(wǎng)地址來定義的。電子頁面可以通過統(tǒng)一資源定位符(URL)來識別。通常，電子頁面是對文本、圖形化圖像、音頻、視頻等的呈現(xiàn)進行組織的文檔。
[0093]盡管通信鏈路125是就其優(yōu)選實施例公開的，但是本領域普通技術人員將從本文公開的內(nèi)容認識到，通信鏈路125可以包括廣泛的交互式通信鏈路。例如，通信鏈路125可以包括交互式電視網(wǎng)絡、電話網(wǎng)絡、無線數(shù)據(jù)傳輸系統(tǒng)、雙向電纜系統(tǒng)、定制的私人或公共計算機網(wǎng)絡、交互式公共電話網(wǎng)絡、自動出納機網(wǎng)絡、直接鏈路、衛(wèi)星或蜂窩網(wǎng)絡等。
[0094]圖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文檔傳輸?shù)綄诮邮赵O備的IP地址。如上所述，XML文檔有利地允許設計者產(chǎn)生他們自己定制的文檔標簽，在應用程序之間和組織之間允許數(shù)據(jù)的定義、傳輸、確認和解釋。此外，上述通信的一部分或全部可以包括傳統(tǒng)的SSL技術。
[0095]根據(jù)一種實施例，事務引擎205包含數(shù)據(jù)路由設備,例如從Netscape、Microsoft、Apache等可買到的傳統(tǒng)網(wǎng)絡服務器。例如，網(wǎng)絡服務器可以有利地接收從通信鏈路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、證書機構115或賣方系統(tǒng)120。
[0096]根據(jù)一種實施例，使用傳統(tǒng)的HTTP路由技術路由數(shù)據(jù)，傳統(tǒng)的HTTP路由技術例如采用URL或者統(tǒng)一資源標識符(URI )。URI類似于URL，但是，URI通常指出例如可執(zhí)行文件、腳本等的文件或動作的源。因此，根據(jù)一種實施例，用戶系統(tǒng)105、證書機構115、賣方系統(tǒng)120及信任引擎210的組件有利地在通信URL或URI內(nèi)包括用于讓事務引擎205貫穿密碼系統(tǒng)正確地路由數(shù)據(jù)的足夠數(shù)據(jù)。
[0097]盡管參考其優(yōu)選實施例公開了數(shù)據(jù)路由，但是本領域技術人員將認識到大量可能的數(shù)據(jù)路由方案或策略。例如，XML或其它數(shù)據(jù)包可以有利地被拆包并通過它們的格式、內(nèi)容等被認出，使得事務引擎205可以通過信任引擎110正確地路由數(shù)據(jù)。而且，本領域技術人員將認識到數(shù)據(jù)路由可以有利地適于符合特定網(wǎng)絡系統(tǒng)的數(shù)據(jù)傳送協(xié)議，例如當通信鏈路125包含本地網(wǎng)絡時。
[0098]根據(jù)本發(fā)明的還有另一種實施例，事務引擎205包括傳統(tǒng)的SSL加密技術，使得上述系統(tǒng)可以在特定通信期間利用事務引擎205認證它們自己，反之亦然。如貫穿本公開內(nèi)容將使用的，術語“ 1/2SSL”指的是服務器被SSL認證而客戶不必被SSL認證的通信，而術語“完全SSL”指的是客戶端和服務器都被SSL認證的通信。在當前公開內(nèi)容使用術語“SSL”時，通信可以包括1/2或完全SSL。
[0099]隨著事務引擎205將數(shù)據(jù)路由到密碼系統(tǒng)100的不同組件，事務引擎205可以有利地產(chǎn)生檢查跟蹤(audit trail)。根據(jù)一種實施例，檢查跟蹤包括通過事務引擎205貫穿密碼系統(tǒng)100路由的數(shù)據(jù)的至少類型和格式的記錄。這種檢查數(shù)據(jù)可以有利地存儲在海量儲存器225中。
[0100]圖2還說明了存儲庫210。根據(jù)一種實施例，存儲庫210包含一個或多個數(shù)據(jù)儲存設施，例如目錄服務器、數(shù)據(jù)庫服務器等。如圖2所示，存儲庫210存儲密碼密鑰和注冊認證數(shù)據(jù)。密碼密鑰可以有利地對應于信任引擎110或?qū)诿艽a系統(tǒng)100的用戶，例如用戶或賣方。注冊認證數(shù)據(jù)可以有利地包括被設計成唯一識別用戶的數(shù)據(jù)，例如用戶ID、密碼、對問題的回答、生物測定數(shù)據(jù)等。在用戶注冊時或另一個可選的稍后時間可以有利地獲得這種注冊認證數(shù)據(jù)。例如，信任引擎110可以包括對注冊認證數(shù)據(jù)的定期或其它更新或重新發(fā)布。
[0101]根據(jù)一種實施例，來自事務引擎205及來往于認證引擎215和密碼引擎220的通信包括例如傳統(tǒng)SSL技術的安全通信。此外，如上所述，來往于存儲庫210的通信數(shù)據(jù)可以使用URL、UR1、HTTP或XML文檔來傳送，把數(shù)據(jù)請求和格式有利地嵌入到上述任何文檔中。
[0102]如上所述，存儲庫210可以有利地包括多個安全數(shù)據(jù)儲存設施。在這樣一種實施例中，安全數(shù)據(jù)儲存設施可以配置成使得對一個個別的數(shù)據(jù)儲存設施的安全性的損害將不會損害存儲在其中的密碼密鑰或認證數(shù)據(jù)。例如，根據(jù)這種實施例，密碼密鑰和認證數(shù)據(jù)都經(jīng)過數(shù)學運算，以便對存儲在每個數(shù)據(jù)儲存設施中的數(shù)據(jù)進行統(tǒng)計學上和充分地隨機化。根據(jù)一種實施例，各別數(shù)據(jù)存儲設施的數(shù)據(jù)的隨機化使數(shù)據(jù)不可破譯。因此，個別數(shù)據(jù)存儲設施的損害只產(chǎn)生隨機的不可破譯的數(shù)而且不損害作為一個整體的任何密碼密鑰或認證數(shù)據(jù)的安全性。
[0103]圖2還說明了包括認證引擎215的信任引擎110。根據(jù)一種實施例，認證引擎215包括配置成對來自事務引擎205的數(shù)據(jù)和來自存儲庫210的數(shù)據(jù)進行比較的數(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ù)，用于比較。
[0104]根據(jù)一種實施例，到認證引擎的通信包括例如SSL技術的安全通信。此外，可以使用公鑰技術在例如超級加密的信任引擎110組件內(nèi)提供安全性。例如，根據(jù)一種實施例，用戶利用認證引擎215的公鑰加密當前的認證數(shù)據(jù)。此外，存儲庫210也利用認證引擎215的公鑰加密注冊認證數(shù)據(jù)。以這種方式，只有認證引擎的私鑰可以被用于對傳輸進行解密。
[0105]如圖2所示，信任引擎110還包括密碼引擎220。根據(jù)一種實施例，密碼引擎包括密碼處理模塊，該密碼處理模塊配置成有利地提供例如公共密鑰基礎設施(PKI)功能的傳統(tǒng)密碼功能。例如，密碼引擎220可以有利地發(fā)布用于密碼系統(tǒng)100的用戶的公鑰和私鑰。以這種方式，密碼密鑰在密碼引擎220處生成并轉(zhuǎn)發(fā)到存儲庫210，使得至少私有密碼密鑰在信任引擎HO之外是不可用的。根據(jù)另一種實施例，密碼引擎220隨機化并分割至少私有密碼密鑰數(shù)據(jù)，由此只存儲隨機化后的被分割數(shù)據(jù)。與注冊認證數(shù)據(jù)的分割類似，分割過程確保被存儲的密鑰在密碼引擎220之外不可用。根據(jù)另一種實施例，密碼引擎的功能能夠與認證引擎215組合并且由認證引擎215執(zhí)行。
[0106]根據(jù)一種實施例，來往于密碼引擎的通信包括例如SSL技術的安全通信。此外，可以有利地采用XML文檔來傳送數(shù)據(jù)和/或進行密碼功能請求。
[0107]圖2還說明了具有海量儲存器225的信任引擎110。如上所述，事務引擎205保存對應于檢查跟蹤的數(shù)據(jù)并將這種數(shù)據(jù)存儲在海量儲存器225中。類似地，根據(jù)本發(fā)明的一種實施例，存儲庫210保存對應于檢查跟蹤的數(shù)據(jù)并將這種數(shù)據(jù)存儲在海量儲存器設備225中。存儲庫檢查跟蹤數(shù)據(jù)類似于事務引擎205的檢查跟蹤數(shù)據(jù)，因為檢查跟蹤數(shù)據(jù)包括對存儲庫210所接收請求的記錄和對其的響應。此外，海量儲存器225可以用于存儲數(shù)字證書，數(shù)字證書中含有用戶的公鑰。
[0108]盡管參考其優(yōu)選和可選實施例公開了信任引擎110，但是本發(fā)明不是要由此受到限制。相反，本領域技術人員將從本文公開的內(nèi)容認識到，對信任引擎110存在眾多的備選方法。例如，信任引擎110可以有利地只執(zhí)行認證，或者可選地，只執(zhí)行密碼功能的一部分或全部，例如數(shù)據(jù)加密和解密。根據(jù)此類實施例，可以有利地去除認證引擎215和密碼引擎220之一，由此產(chǎn)生對信任引擎110更簡潔的設計。此外，密碼引擎220還可以與證書機構通信，使得證書機構體現(xiàn)在信任引擎110中。根據(jù)還有另一種實施例，信任引擎110可以有利地執(zhí)行認證及一個或多個密碼功能，例如數(shù)字簽署。[0109]圖3說明了根據(jù)本發(fā)明一種實施例各方面的圖2事務引擎205的框圖。根據(jù)這種實施例，事務引擎205包括具有處理線程和監(jiān)聽線程的操作系統(tǒng)305。操作系統(tǒng)305可以有利地類似于在傳統(tǒng)高容量服務器中找到的那些服務器，例如從Apache可以買到的網(wǎng)絡服務器。監(jiān)聽線程監(jiān)視來自通信鏈路125、認證引擎215和密碼引擎220之一的進入通信，以便發(fā)現(xiàn)進入的數(shù)據(jù)流。處理線程認出進入的數(shù)據(jù)流的特定數(shù)據(jù)結構，例如上述數(shù)據(jù)結構，由此將進入的數(shù)據(jù)路由到通信鏈路125、存儲庫210、認證引擎215、密碼引擎220或海量儲存器225之一。如圖3所示，進入和外出的數(shù)據(jù)可以有利地通過例如SSL技術得到保護。
[0110]圖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包括對唯一用戶ID索引認證數(shù)據(jù)和密碼密鑰數(shù)據(jù)的單個邏輯存儲器結構。這單個邏輯存儲器結構優(yōu)選包括用于確保在其中存儲的數(shù)據(jù)的高度信任或安全性的機制。例如，存儲庫210的物理位置可以有利地包括眾多傳統(tǒng)的安全措施，諸如受限的員工訪問、現(xiàn)代監(jiān)視系統(tǒng)等。除了物理安全之外或者代替物理安全，計算機系統(tǒng)或服務器可以有利地包括軟件解決方案來保護被存儲的數(shù)據(jù)。例如，存儲庫210可以有利地產(chǎn)生并存儲對應于所采取動作的檢查跟蹤的數(shù)據(jù)415。此外，進入和外出的通信可以有利地用與傳統(tǒng)SSL技術耦合的公鑰加密進行加密。
[0111]根據(jù)另一種實施例，存儲庫210可以包括不同的且物理分離的數(shù)據(jù)儲存設施，如參考圖7進一步公開的那樣。
[0112]圖5說明了根據(jù)本發(fā)明一種實施例各方面的圖2認證引擎215的框圖。類似于圖3的事務引擎205，認證引擎215包括操作系統(tǒng)505，操作系統(tǒng)505具有例如可以從Apache買到的網(wǎng)絡服務器的傳統(tǒng)網(wǎng)絡服務器的更改版本的監(jiān)聽和處理線程。如圖5所示，認證引擎215包括對至少一個私鑰510的訪問。私鑰510可以有利地用于例如解密來自事務引擎205或存儲庫210的數(shù)據(jù)，該數(shù)據(jù)是用認證引擎215的相應公鑰加密的。
[0113]圖5還說明了包括比較器515、數(shù)據(jù)分割模塊520和數(shù)據(jù)組裝模塊525的認證引擎215。根據(jù)本發(fā)明的優(yōu)選實施例，比較器515包括能夠比較與上述生物測定認證數(shù)據(jù)有關的可能復雜的模式的技術。該技術可以包括硬件、軟件或者組合的解決方案，用于例如那些代表指紋模式或語音模式的模式比較。此外，根據(jù)一種實施例，認證引擎215的比較器515可以有利地比較傳統(tǒng)的文檔哈希，以便給出比較結果。根據(jù)本發(fā)明的一種實施例，比較器515包括將試探法530對比較的應用。試探法530可以有利地解決與認證嘗試密切相關的情形，例如時刻、IP地址或子網(wǎng)掩碼、購買簡檔、電子郵件地址、處理器序列號或ID等。
[0114]而且，生物測定數(shù)據(jù)比較的本質(zhì)可能導致由于當前的生物測定認證數(shù)據(jù)與注冊數(shù)據(jù)的匹配產(chǎn)生的不同程度的置信度。例如，不像可能只返回肯定或否定匹配的傳統(tǒng)密碼，指紋可以被確定為部分匹配，例如90%匹配、75%匹配、或10%匹配，而非簡單地正確或錯誤。例如聲紋(voice print)分析或面部識別的其它生物測定標識符可以共享這個概率認證而非絕對認證的屬性。
[0115]當用這種概率認證工作時或者在認證被視為不夠絕對可靠的其它情況下，期望應用試探法530來確定所提供的認證中的置信級別是否高到足以認證正在進行的事務。[0116]有時候情況將是所發(fā)布的事務是相對低價值的事務，在這種情況下，被認證為較低的置信級別是可以接受的。這可以包括具有與其相關的低美元價值的事務(例如10美元的購買)或者具有低風險的事務(例如只許可成員的網(wǎng)站)。
[0117]反之，對于認證其他事務，在允許事務進行之前在認證中要求高置信度可能是期望的。這種事務可以包括大美元價值的事務(例如簽署數(shù)百萬美元的供應契約)或者如果錯誤認證發(fā)生將具有高風險的事務(例如遠程登錄到政府計算機上)。
[0118]如下面要描述的那樣，與置信級別和事務值相結合的試探法530的使用可以用于允許比較器提供動態(tài)背景敏感的認證系統(tǒng)。
[0119]根據(jù)本發(fā)明的另一種實施例，比較器515可以有利地跟蹤用于特定事務的認證嘗試。例如，當事務失敗時，信任引擎110可以請求用戶重新輸入他或她的當前認證數(shù)據(jù)。認證引擎215的比較器515可以有利地采用嘗試限制器535來限制認證嘗試的次數(shù)，由此禁止模仿用戶的認證數(shù)據(jù)的粗暴(brute-force)嘗試。根據(jù)一種實施例,嘗試限制器535包括監(jiān)視事務的軟件模塊，用于重復認證嘗試和例如對于給定的事務將認證嘗試限制到三次。因此，嘗試限制器535將把模仿個人的認證數(shù)據(jù)的自動嘗試限制到例如簡單的三次“猜測”。三次失敗之后，嘗試限制器535可以有利地拒絕額外的認證嘗試。這種拒絕可以有利地通過例如比較器515返回否定結果而不管當前所傳輸?shù)恼J證數(shù)據(jù)是什么來實現(xiàn)。另一方面，事務引擎205可以有利地阻擋從屬于三次嘗試之前已經(jīng)失敗的事務的任何額外的認證嘗試。
[0120]認證引擎215還包括數(shù)據(jù)分割模塊520和數(shù)據(jù)組裝模塊525。數(shù)據(jù)分割模塊520有利地包括軟件、硬件或組合模塊，該模塊具有對不同數(shù)據(jù)進行數(shù)學運算從而基本上使數(shù)據(jù)隨機化并把數(shù)據(jù)分割成幾部分的能力。根據(jù)一種實施例，原始數(shù)據(jù)不能從個別的部分重建。數(shù)據(jù)組裝模塊525有利地包括軟件、硬件或組合模塊，該模塊配置成對之前基本上隨機化了的部分進行數(shù)學運算，使得其組合提供原始被破譯的數(shù)據(jù)。根據(jù)一種實施例，認證引擎215采用數(shù)據(jù)分割模塊520來隨機化注冊認證數(shù)據(jù)并將其分割成幾部分，并采用數(shù)據(jù)組裝模塊525將這幾部分重組成可用的注冊認證數(shù)據(jù)。
[0121]圖6說明了根據(jù)本發(fā)明一種實施例各方面的圖2信任引擎200的密碼引擎220的框圖。類似于圖3的事務引擎205，密碼引擎220包括操作系統(tǒng)605，操作系統(tǒng)605至少具有例如可以從Apache買到的網(wǎng)絡服務器的傳統(tǒng)網(wǎng)絡服務器的更改版本的監(jiān)聽和處理線程。如圖6所示，密碼引擎220包括功能類似于圖5那些模塊的數(shù)據(jù)分割模塊610和數(shù)據(jù)組裝模塊620。但是，與之前的注冊認證數(shù)據(jù)相反，根據(jù)一種實施例，數(shù)據(jù)分割模塊610和數(shù)據(jù)組裝模塊620處理密碼密鑰數(shù)據(jù)。盡管這樣，本領域技術人員將從本文公開的內(nèi)容認識到，數(shù)據(jù)分割模塊610和數(shù)據(jù)組裝模塊620可以與認證引擎215的那些模塊組合。
[0122]密碼引擎220還包括配置成執(zhí)行眾多密碼功能的一個、一些或全部的密碼處理模塊625。根據(jù)一種實施例，密碼處理模塊625可以包括軟件模塊或程序、硬件或者兩者都包括。根據(jù)另一種實施例，密碼處理模塊625可以執(zhí)行數(shù)據(jù)比較、數(shù)據(jù)解析、數(shù)據(jù)分割、數(shù)據(jù)分離、數(shù)據(jù)哈希、數(shù)據(jù)加密或解密、數(shù)字簽名驗證或產(chǎn)生、數(shù)字證書產(chǎn)生、儲存或請求、密碼密鑰產(chǎn)生等。而且，本領域技術人員將從本文公開的內(nèi)容認識到，密碼處理模塊625可以有利地包含公共密鑰基礎設施，例如完美隱私(PGP)、基于RSA的公共密鑰系統(tǒng)或眾多可選的密鑰管理系統(tǒng)。此外，密碼處理模塊625可以執(zhí)行公共密鑰加密、對稱密鑰加密或者兩者都執(zhí)行。除了上述之外，密碼處理模塊625還可以包括一個或多個計算機程序或模塊、硬件或者兩者都包括，以便實現(xiàn)無縫、透明的互操作性功能。
[0123]本領域技術人員還將從本文公開的內(nèi)容認識到，密碼功能可以包括通常與密碼密鑰管理系統(tǒng)有關的眾多或各種功能。
[0124]圖7說明了根據(jù)本發(fā)明一種實施例各方面的存儲庫系統(tǒng)700的簡化框圖。如圖7所示，存儲庫系統(tǒng)700有利地包括多個數(shù)據(jù)儲存設施，例如數(shù)據(jù)儲存設施Dl、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ù)儲存設施廣播請求。
[0125]響應來自事務引擎205的對數(shù)據(jù)的請求，存儲庫系統(tǒng)700將存儲的數(shù)據(jù)有利地轉(zhuǎn)發(fā)到認證引擎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ù)儲存設施。
[0126]根據(jù)一種實施例，每個數(shù)據(jù)儲存設施，Dl至D4，都包括例如目錄服務器的單獨且獨立的儲存系統(tǒng)。根據(jù)本發(fā)明的另一種實施例，存儲庫系統(tǒng)700包括多個地理上分離的獨立數(shù)據(jù)儲存系統(tǒng)。通過將敏感數(shù)據(jù)分配到不同且獨立的儲存設施Dl至D4中，存儲庫系統(tǒng)700提供冗余性和額外的安全措施，其中儲存設施Dl至D4中的一些或全部可以有利地在地理上分離。例如，根據(jù)一種實施例，只有來自多個數(shù)據(jù)儲存設施Dl至D4中的兩個的數(shù)據(jù)需要被破譯并且重組敏感數(shù)據(jù)。因此，多達四個數(shù)據(jù)儲存設施Dl至D4中的兩個可以由于維護、系統(tǒng)故障、電力故障等不起作用，但不影響信任引擎110的功能。此外，根據(jù)一種實施例，因為每個數(shù)據(jù)儲存設施中存儲的數(shù)據(jù)是隨機化且不可破譯的，所以任何單獨的數(shù)據(jù)儲存設施的損害都不一定損害到敏感數(shù)據(jù)。而且，在具有地理分離的數(shù)據(jù)儲存設施的實施例中，多個地理上遠離的設施的損害變得更加困難。事實上，為了顛覆必須的多個獨立的地理上遠程的數(shù)據(jù)儲存設施，即使調(diào)皮搗蛋的員工也將得到極大的挑戰(zhàn)。
[0127]盡管參考存儲庫系統(tǒng)700的優(yōu)選和可選的實施例公開了存儲庫系統(tǒng)700，但是本發(fā)明不是要由此受到限制。相反，本領域技術人員將從本文公開的內(nèi)容認識到用于存儲庫系統(tǒng)700的眾多可選方案。例如，存儲庫系統(tǒng)700可以包括一個、兩個或更多數(shù)據(jù)儲存設施。此外，敏感數(shù)據(jù)可以進行數(shù)學運算，使得重組和破譯敏感數(shù)據(jù)需要來自兩個或更多數(shù)據(jù)儲存設施的幾部分。
[0128]如上所述，認證引擎215和密碼引擎220每個都分別包括數(shù)據(jù)分割模塊520和610，用于分割任何類型或形式的敏感數(shù)據(jù)，例如像文本、音頻、視頻、認證數(shù)據(jù)和密碼密鑰數(shù)據(jù)。圖8說明了根據(jù)本發(fā)明一種實施例各方面通過數(shù)據(jù)分割模塊執(zhí)行的數(shù)據(jù)分割過程800的流程圖。如圖8所示，當敏感數(shù)據(jù)〃S〃被認證引擎215或密碼引擎220的數(shù)據(jù)分割模塊接收時，數(shù)據(jù)分割過程800在步驟805開始。優(yōu)選地，在步驟810中，數(shù)據(jù)分割模塊接著產(chǎn)生基本上隨機的數(shù)、值、或位的串或組，〃A〃。例如，可以用本領域普通技術人員可用的眾多不同的傳統(tǒng)技術來產(chǎn)生隨機數(shù)A，以便產(chǎn)生適于在密碼應用程序中使用的高品質(zhì)隨機數(shù)。此外，根據(jù)一種實施例，隨機數(shù)A包括可以是任何適當長度的位長度，例如比敏感數(shù)據(jù)S的位長度更短、更長或與其相等。
[0129]此外，在步驟820中，數(shù)據(jù)分割過程800產(chǎn)生另一個統(tǒng)計上隨機的數(shù)"C"。根據(jù)優(yōu)選實施例，統(tǒng)計上隨機的數(shù)A和C的產(chǎn)生可以有利地并行進行。數(shù)據(jù)分割模塊隨后將數(shù)A和C與敏感數(shù)據(jù)S組合，使得產(chǎn)生新數(shù)〃B〃和〃D〃。例如，數(shù)B可以包含A異或(XOR) S的二進制組合并且數(shù)D可以包含C XOR S的二進制組合。XOR功能或者說〃異或〃功能，是本領域普通技術人員熟知的。上述組合優(yōu)選地分別發(fā)生在步驟825和830中，并且，根據(jù)一種實施例，上述組合還可并行發(fā)生。然后，數(shù)據(jù)分割過程800前進到步驟835，在步驟835中隨機數(shù)A和C以及數(shù)B和D被配對，使得沒有一個配對會通過它們自己含有足夠的數(shù)據(jù)，來重組和破譯原始敏感數(shù)據(jù)S。例如，這些數(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。此外，配對可以全部存儲在一個存儲庫上，并且可以存儲在所述存儲庫上的單獨的位置中。
[0130]基于以上所述，數(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ù)保持?目任。
[0131] 盡管參考其優(yōu)選實施例公開了數(shù)據(jù)分割過程800，但是本發(fā)明不是要由此受到限制。相反，本領域技術人員將從本文公開的內(nèi)容認識到對于數(shù)據(jù)分割過程800的眾多可選項。例如，數(shù)據(jù)分割過程可以將數(shù)據(jù)有利地分成兩個數(shù)，例如，隨機數(shù)A和數(shù)B，以及，通過兩個數(shù)據(jù)儲存設施隨機分配A和B。而且，數(shù)據(jù)分割過程800可以通過產(chǎn)生附加的隨機數(shù)在眾多數(shù)據(jù)儲存設施當中有利地分割數(shù)據(jù)。數(shù)據(jù)可以被分割成任何期望的、選擇的、預定的或者隨機分配的大小的單元，包括但不限于一位、多位、多字節(jié)、千字節(jié)、兆字節(jié)或者更大，或大小的任何組合或序列。此外，由分割過程引起的對數(shù)據(jù)單元大小的改變可能使數(shù)據(jù)更難以恢復成可用的形式，由此增加了敏感數(shù)據(jù)的安全性。本領域普通技術人員很容易理解，分割后的數(shù)據(jù)單元大小可以是多種多樣的數(shù)據(jù)單元大小或大小的模式或大小的組合。例如，數(shù)據(jù)單元大小可以被選擇或預定為全都是相同的大小、固定設置的不同大小、大小的組合或者隨機產(chǎn)生的大小。類似地，根據(jù)固定或預定的數(shù)據(jù)單元大小、數(shù)據(jù)單元大小的模式或組合或者隨機產(chǎn)生的數(shù)據(jù)單元大小或每份的大小，數(shù)據(jù)單元可以分配到一份或多份中。
[0132]如上所述，為了重建敏感數(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ù)圖8數(shù)據(jù)分割過程800所采用的數(shù)據(jù)分割模塊520的一種實施例，數(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。因此，響應信任引擎110的組裝請求，當例如數(shù)據(jù)組裝模塊525從數(shù)據(jù)儲存設施Dl至D4中至少前兩個接收到數(shù)據(jù)部分時，它可以組裝敏感數(shù)據(jù)S。
[0133]基于上述數(shù)據(jù)分割和組裝過程，敏感數(shù)據(jù)S只在信任引擎110的有限區(qū)域中以可用格式存在。例如，當敏感數(shù)據(jù)S包括注冊認證數(shù)據(jù)時，可用的、非隨機化的注冊認證數(shù)據(jù)只在認證引擎215中可用。同樣，當敏感數(shù)據(jù)S包括私有密碼密鑰數(shù)據(jù)時，可用的、非隨機化的私有密碼密鑰數(shù)據(jù)只在密碼引擎220中可用。
[0134]盡管參考其優(yōu)選實施例公開了數(shù)據(jù)分割和組裝過程，但是本發(fā)明不是要由此受到限制。相反，本領域技術人員將從本文公開的內(nèi)容認識到用于分割和重組敏感數(shù)據(jù)S的眾多可選方案。例如，公鑰加密可以用于在數(shù)據(jù)儲存設施Dl至D4進一步保護數(shù)據(jù)。此外，本領域普通技術人員很容易理解，本文描述的數(shù)據(jù)分割模塊也是本發(fā)明的單獨且不同的實施例，這些實施例可以結合到任何現(xiàn)有的計算機系統(tǒng)、軟件套件、數(shù)據(jù)庫、或者其組合，或者像本文公開和描述的信任引擎、認證引擎和事務引擎的本發(fā)明其它實施例當中，或者與它們組合或者成為它們的一部分。
[0135]圖9A說明了根據(jù)本發(fā)明一種實施例各方面的注冊過程900的數(shù)據(jù)流。如圖9A所示，注冊過程900在用戶期望用密碼系統(tǒng)100的信任引擎110注冊時在步驟905處開始。根據(jù)這種實施例，用戶系統(tǒng)105有利地包括客戶端小程序，例如如基于Java的，該小程序詢問用戶以輸入像人口數(shù)據(jù)和注冊認證數(shù)據(jù)的注冊數(shù)據(jù)。根據(jù)一種實施例，注冊認證數(shù)據(jù)包括用戶ID、密碼(多個密碼)、生物測定(多個生物測定)等。根據(jù)一種實施例，在詢問過程期間，客戶端小程序優(yōu)選與信任引擎110通信以確保選定的用戶ID是唯一的。當用戶ID不唯一時，信任引擎110可以有利地建議一個唯一的用戶ID?？蛻舳诵〕绦蚴占詳?shù)據(jù)并且例如通過XML文檔將注冊數(shù)據(jù)傳輸?shù)叫湃我?10，而且尤其是傳輸?shù)绞聞找?05。根據(jù)一種實施例，傳輸是利用認證引擎215的公鑰編碼的。
[0136]根據(jù)一種實施例，用戶在注冊過程900的步驟905期間執(zhí)行單次注冊。例如，用戶將他自己或她自己注冊為一個特定的人，例如Joe User。當Joe User期望注冊為Mega公司的CEO，Joe User時，根據(jù)這種實施例，Joe User第二次注冊，接收第二個唯一的用戶ID并且信任引擎110不使兩個身份相關。根據(jù)本發(fā)明的另一種實施例，注冊過程900為單個用戶ID提供多個用戶身份。因此，在上述例子中，信任引擎110將有利地使Joe User的兩個身份相關。如本領域技術人員從本文公開的內(nèi)容將認識到的那樣，一個用戶可以具有許多身份，例如，戶主Joe User,慈善基金會成員Joe User等。即使用戶可以具有多個身份，但是，根據(jù)這種實施例，信任引擎110也優(yōu)選地只存儲一個注冊數(shù)據(jù)集。而且，用戶可以按照他們的需要有利地增加、編輯/更新或刪除身份。
[0137]盡管參考其優(yōu)選實施例公開了注冊過程900，但是本發(fā)明不是要由此受到限制。相反，本領域技術人員將從本文公開的內(nèi)容認識到用于收集注冊數(shù)據(jù)并且尤其是注冊認證數(shù)據(jù)的眾多可選方案。例如，小程序可以是基于公共對象模式(COM)的小程序等。
[0138]另一方面，注冊過程可以包括分級注冊。例如，在最低級注冊，用戶可以通過通信鏈路125注冊而不產(chǎn)生關于他或她的身份的文檔資料(documentation)。根據(jù)升級的注冊，用戶使用例如數(shù)字公證員的被信任的第三方來注冊。例如，而且用戶可以向被信任的第三方現(xiàn)出真身，提供像出生證、駕照、軍人ID等證件，并且被信任的第三方在注冊提交過程中可以有利地包括例如他們的數(shù)字簽名。被信任的第三方可以包括真正的公證員、例如郵局或機動車輛部門的政府機構、注冊為員工的大公司里的人力資源人員等。本領域技術人員將從本文公開的內(nèi)容認識到，注冊的眾多變化級別可以在注冊過程900期間發(fā)生。
[0139]在步驟915接收到注冊認證數(shù)據(jù)之后，事務引擎205使用傳統(tǒng)的完全SSL (FULLSSL)技術將注冊認證數(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還可以有利地隨機決定哪幾部分傳送給哪幾個存儲庫。
[0140]在注冊過程900期間，用戶還將常常期望具有發(fā)布的數(shù)字證書，從而使他或她可以從密碼系統(tǒng)100之外的其它來源接收加密的文檔。如上所述，證書機構115通常根據(jù)幾種傳統(tǒng)標準中的一種或多種發(fā)布數(shù)字證書。總的來說，數(shù)字證書包括每個人都知道的用戶或系統(tǒng)的公鑰。
[0141]不管用戶是在注冊時還是在另一個時間請求數(shù)字證書，該請求都通過信任引擎110傳送到認證引擎215。根據(jù)一種實施例，請求包括具有例如用戶的真名的XML文檔。根據(jù)步驟935，認證引擎215將請求傳送到密碼引擎220，命令密碼引擎220產(chǎn)生密碼密鑰或密鑰對。
[0142]在步驟935請求后，密碼引擎220生成至少一個密碼密鑰。根據(jù)一種實施例，密碼處理模塊625生成密鑰對，其中一個密鑰被用作私鑰，而另一個被用作公鑰。密碼引擎220存儲私鑰并且，根據(jù)一種實施例，還存儲公鑰的副本。在步驟945，密碼引擎220將對數(shù)字證書的請求傳輸?shù)绞聞找?05。根據(jù)一種實施例，該請求有利地包括標準化的請求，例如嵌在像XML文檔中的PKCSlO。對數(shù)字證書的請求可以有利地對應于一個或多個證書機構和證書機構要求的一種或多種標準格式。
[0143]在步驟950中，事務引擎205將這個請求轉(zhuǎn)發(fā)到證書機構115，證書機構115在步驟955中返回數(shù)字證書。返回的數(shù)字證書可以有利地具有例如PKCS7的標準化格式，或者具有一個或多個證書機構115的專有格式。在步驟960中，數(shù)字證書被事務引擎205接收，并且其一個副本被轉(zhuǎn)發(fā)到用戶并且一個副本用信任引擎110進行存儲。信任引擎110存儲證書的副本，從而使信任引擎110將不需要依賴證書機構115的可用性。例如，當用戶期望發(fā)送數(shù)字證書或者第三方請求用戶的數(shù)字證書時，對數(shù)字證書的請求一般發(fā)送到證書機構115。但是，如果證書機構115正在進行維護或已經(jīng)是故障或安全性損害的受害者，則數(shù)字證書可能不可用。
[0144]在發(fā)布密碼密鑰之后的任何時間，密碼引擎220都可以有利地采用上述的數(shù)據(jù)分割過程800，使得密碼密鑰被分割成獨立的不可破譯的隨機化的數(shù)。類似于認證數(shù)據(jù)，在步驟965，密碼引擎220把隨機化的數(shù)傳送到數(shù)據(jù)儲存設施Dl至D4。
[0145]本領域技術人員將從本文公開的內(nèi)容認識到，用戶可以在注冊之后的任何時間請求數(shù)字證書。而且，系統(tǒng)之間的通信可以有利地包括FULL SSL或公鑰加密技術。而且，注冊過程可以從包括信任引擎110內(nèi)部或外部的一個或多個專門的證書機構在內(nèi)的多個證書機構發(fā)布多個數(shù)字證書。
[0146]如在步驟935至960中所公開的，本發(fā)明的一種實施例包括對最終存儲在信任引擎110上的證書的請求。因為，根據(jù)一種實施例，密碼處理模塊625發(fā)布由信任引擎110使用的密鑰，每個證書對應一個私鑰。因此，信任引擎110可以有利地提供互操作性，監(jiān)視用戶擁有或者與用戶相關聯(lián)的證書。例如，當密碼引擎220接收到對密碼功能的請求時，密碼處理模塊625可以調(diào)查發(fā)出請求的用戶所擁有的證書以確定該用戶是否擁有與所請求的屬性匹配的私鑰。當這種證書存在時，密碼處理模塊625可以使用該證書或者與其相關聯(lián)的公共或私有密鑰來執(zhí)行所請求的功能。當這種證書不存在時，密碼處理模塊625可以有利地且透明地執(zhí)行許多動作以嘗試補救適當密鑰的缺乏。例如，圖9B說明了互操作性過程970的流程圖，根據(jù)本發(fā)明一種實施例的各方面，互操作性過程970公開了上述步驟，以確保密碼處理模塊625使用適當?shù)拿荑€執(zhí)行密碼功能。
[0147]如圖9B所示，互操作性過程970開始于步驟972，在步驟972中密碼處理模塊925確定期望證書的類型。根據(jù)本發(fā)明的一種實施例，證書類型可以有利地在對密碼功能的請求或者由請求者提供的其它數(shù)據(jù)中規(guī)定。根據(jù)另一種實施例，證書類型可以由請求的數(shù)據(jù)格式確定。例如，密碼處理模塊925可以有利地認識到該請求對應于特定的類型。
[0148]根據(jù)一種實施例，證書類型可以包括例如RSA、ELGAMAL等一種或多種算法標準。此外，證書類型可以包括例如對稱密鑰、公鑰、諸如256位密鑰的強加密密鑰、較不安全密鑰等一種或多種密鑰類型。而且，證書類型可以包括一種或多種上述算法標準或密鑰、一種或多種消息或數(shù)據(jù)格式、例如Base 32或Base 64的一種或多種數(shù)據(jù)封裝或編碼體系的升級或替換。證書類型還可以包括與一種或多種第三方密碼應用程序或接口、一種或多種通信協(xié)議或者一種或多種證書標準或協(xié)議的兼容性。本領域技術人員將從本文公開的內(nèi)容認識到，在證書類型中可以存在其它差別，并且可以如本文所公開的那樣實現(xiàn)對這些差別的翻譯和由這些差別翻譯。
[0149]一旦密碼處理模塊625確定了證書類型，互操作性過程970就可以前進到步驟974，并且確定用戶是否擁有與步驟974中確定的類型匹配的證書。例如，當用戶擁有匹配的證書時，信任引擎110有權訪問匹配的證書，通過例如其之前的儲存，密碼處理模塊625知道匹配的私鑰也存儲在信任引擎110內(nèi)。例如，匹配的私鑰可以存儲在存儲庫210或存儲庫系統(tǒng)700內(nèi)。密碼處理模塊625可以有利地請求從例如存儲庫210組裝匹配的私鑰，然后，在步驟976中，使用匹配的私鑰執(zhí)行密碼動作或功能。例如，如上所述，密碼處理模塊625可以有利地執(zhí)行哈希、哈希比較、數(shù)據(jù)加密或解密、數(shù)字簽名驗證或產(chǎn)生等。
[0150]當用戶不擁有匹配的證書時，互操作性過程970前進到步驟978，在步驟978中密碼處理模塊625確定用戶是否擁有被交叉證明的證書。根據(jù)一種實施例，當?shù)谝蛔C書機構確定信任來自第二證書機構的證書時，證書機構之間的交叉證明發(fā)生。換言之，第一證書機構確定來自第二證書機構的證書滿足一定的質(zhì)量標準，因此可以被〃認證為〃為等價于第一證書機構自己的證書。在證書機構發(fā)布例如具有信任級別的證書時，交叉證明變得更加復雜。例如，第一證書機構通?；谧赃^程中的可靠度，可以為特定的證書提供三個信任級別，而第二證書機構可以提供七個信任級別。交叉證明可以有利地跟蹤來自第二證書機構的哪幾個級別和哪幾個證書可以用來自第一證書機構的哪幾個級別和哪幾個證書代替。當在兩個證書機構之間官方和公開地進行上述交叉證明時，相互之間證書和級別的映射經(jīng)常被稱為“鏈接(chaining)”。
[0151]根據(jù)本發(fā)明的另一種實施例，密碼處理模塊625可以有利地在由證書機構商定的那些交叉證明之外開發(fā)交叉證明。例如，密碼處理模塊625可以訪問第一證書機構的認證慣例聲明(CPS)或者其它公布的政策聲明，并且使用例如特定信任級別要求的認證標記來使第一證書機構的證書與另一個證書機構的證書匹配。
[0152]在步驟978中，當密碼處理模塊625確定用戶擁有被交叉證明的證書時，互操作性過程970前進到步驟976，并使用被交叉證明的公鑰、私鑰或者這兩者來執(zhí)行密碼動作或功能?？蛇x地，當密碼處理模塊625確定用戶不擁有被交叉證明的證書時，互操作性過程970前進到步驟980，在步驟980中密碼處理模塊625選擇發(fā)布被請求的證書類型或者去它們那里交叉證明的證書的證書機構。在步驟982，密碼處理模塊625確定前面討論的用戶注冊認證數(shù)據(jù)是否滿足選定證書機構的認證要求。例如，如果用戶通過例如回答人口統(tǒng)計問題和其它問題通過網(wǎng)絡進行注冊，則所提供的認證數(shù)據(jù)可以建立比提供生物測定數(shù)據(jù)并在例如公證員的第三方前露臉的用戶更低級別的信任。根據(jù)一種實施例，上述認證要求可以有利地在被選證書機構的CPS中提供。
[0153]當用戶已經(jīng)給信任引擎110提供了滿足選定證書機構的要求的注冊認證數(shù)據(jù)時，互操作性過程970前進到步驟984，在步驟984中密碼處理模塊625獲得來自選定證書機構的證書。根據(jù)一種實施例，密碼處理模塊625通過注冊過程900后面的步驟945至960獲得證書。例如，密碼處理模塊625可以有利地采用來自密碼引擎220中早就可用的一個或多個密鑰對中的一個或多個公鑰來請求來自證書機構的證書。根據(jù)另一種實施例，密碼處理模塊625可以有利地產(chǎn)生一個或多個新密鑰對并使用與其對應的公鑰來請求來自證書機構的證書。
[0154]根據(jù)另一種實施例，信任引擎110可以有利地包括能夠發(fā)布一種或多種證書類型的一個或多個證書發(fā)布模塊。根據(jù)這種實施例，證書發(fā)布模塊可以提供上述證書。當密碼處理模塊625獲得證書時，互操作性過程970前進到步驟976，并使用對應于所獲得的證書的公鑰、私鑰或者這兩者來執(zhí)行密碼動作或功能。
[0155]在步驟982中，當用戶尚未給信任引擎110提供滿足選定證書機構的要求的注冊認證數(shù)據(jù)時，密碼處理模塊625在步驟986中確定是否存在具有不同認證要求的其它證書機構。例如，密碼處理模塊625可以尋找具有較低認證要求的證書機構，但是仍然發(fā)布其選定的證書或者其交叉證明。
[0156]當具有較低要求的上述證書機構存在時，互操作性過程970前進到步驟980并選擇那個證書機構?？蛇x地，當不存在這種證書機構時，在步驟988中，信任引擎110可以請求來自用戶的附加的認證標記。例如，信任引擎110可以請求包含例如生物測定數(shù)據(jù)的新注冊認證數(shù)據(jù)。而且，信任引擎110可以請求用戶在被信任的第三方前露臉并提供適當?shù)恼J證證件，例如在公證員前出示駕照、社會保障卡、銀行卡、出生證、軍人ID等。當信任引擎110接收到更新后的認證數(shù)據(jù)時，互操作性過程970前進到步驟984并且獲得上述選定的證書。
[0157]通過上述互操作性過程970，密碼處理模塊625在不同密碼系統(tǒng)之間有利地提供無縫、透明的翻譯和轉(zhuǎn)換。本領域技術人員將從本文公開的內(nèi)容認識到上述可互操作的系統(tǒng)的眾多優(yōu)點和實現(xiàn)。例如，互操作性過程970的上述步驟986可以有利地包括以下進一步具體討論的信任仲裁的各個方面，在信任仲裁中證書機構可以特殊情形下接收較低級別的交叉證明。另外，互操作性過程970可以包括在例如采用證書撤銷列表(CRL)的標準證書撤銷、在線證書狀態(tài)協(xié)議(OCSP)等的采用之間確?；ゲ僮餍?。
[0158]圖10說明了根據(jù)本發(fā)明一種實施例各方面的認證過程1000的數(shù)據(jù)流。根據(jù)一種實施例，認證過程1000包括收集來自用戶的當前認證數(shù)據(jù)并將其與用戶的注冊認證數(shù)據(jù)進行比較。例如，認證過程1000開始于步驟1005，在步驟1005中用戶期望與例如賣方執(zhí)行事務。這種事務可以包括例如選擇購買選項、請求訪問賣方系統(tǒng)120的受限區(qū)域或設備等。在步驟1010，賣方向用戶提供事務ID和認證請求。事務ID可以有利地包括192位的量，具有與128位隨機量聯(lián)系在一起的32位時間戳，或者與32位賣方規(guī)定常數(shù)聯(lián)系在一起的“隨機數(shù)(nonce)”。這種事務ID唯一識別該事務，使得模仿者事務會被信任引擎110拒絕。
[0159]認證請求可以有利地包括對于特定事務需要什么級別的認證。例如，賣方可以規(guī)定所發(fā)布的事務所需的特定置信級別。如果不能對這個置信級別做出認證，如下面將討論的那樣，那么，如果沒有通過用戶升高置信級別的進一步認證或者關于賣方與服務器之間的認證方面的改變，事務就將不發(fā)生。這些問題在下面更加完整地討論。
[0160]根據(jù)一種實施例，事務ID和認證請求可以通過賣方端小程序或其它軟件程序有利地生成。此外，事務ID和認證數(shù)據(jù)的傳輸可以包括使用像1/2SSL，或者換句話說是賣方端被認證的SSL，的傳統(tǒng)SSL技術加密的一個或多個XML文檔。
[0161]在用戶系統(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ù)格式或請求，并將該傳輸轉(zhuǎn)發(fā)到認證引擎215。
[0162]在步驟1015和1020期間，賣方系統(tǒng)120在步驟1025使用優(yōu)選的FULL SSL技術將事務ID和認證請求轉(zhuǎn)發(fā)到信任引擎110。雖然賣方識別還可以通過事務ID的非隨機部分傳送，但是這種通信也可以包括賣方ID。在步驟1030和1035，事務引擎205接收通信，在檢查跟蹤中產(chǎn)生記錄，并且生成對要從數(shù)據(jù)儲存設施Dl至D4組裝的用戶注冊認證數(shù)據(jù)的請求。在步驟1040，存儲庫系統(tǒng)700將對應于用戶的注冊認證數(shù)據(jù)的多個部分傳送到認證引擎215。在步驟1045，認證引擎215使用它的私鑰對傳輸進行解密并且比較注冊認證數(shù)據(jù)與用戶提供的當前認證數(shù)據(jù)。
[0163]步驟1045的比較可以有利地應用啟發(fā)式背景敏感認證，如之前所提到的，并且在下面更具體地進行討論。例如，如果接收到的生物測定信息不能理想地匹配，則較低的信任匹配產(chǎn)生。在特定的實施例中，認證的置信級別要權衡事務的本質(zhì)和用戶及賣方兩者的期望。這也在下面更具體地討論。
[0164]在步驟1050，認證引擎215用步驟1045的比較結果填寫認證請求。根據(jù)本發(fā)明的一種實施例，用認證過程1000的是/否或真/假結果填寫認證請求。在步驟1055中，填好的認證請求返回到賣方，便于賣方照辦，例如，允許用戶完成啟動了該認證請求的事務。根據(jù)一種實施例，確認消息被傳遞到用戶。
[0165]基于以上所述，認證過程1000有利地保持敏感數(shù)據(jù)安全并產(chǎn)生配置成維持敏感數(shù)據(jù)的完整性的結果。例如，敏感數(shù)據(jù)僅在認證引擎215內(nèi)部被組裝。例如，注冊認證數(shù)據(jù)在它被數(shù)據(jù)組裝模塊在認證引擎215內(nèi)組裝之前是不可破譯的，而且當前認證數(shù)據(jù)在它被傳統(tǒng)的SSL技術和認證引擎215的私鑰解開之前是不可破譯的。而且，傳輸給賣方的認證結果不包括敏感數(shù)據(jù)，并且用戶可能甚至不知道他或她是否產(chǎn)生了有效的認證數(shù)據(jù)。
[0166]盡管參考其優(yōu)選和可選實施例公開了認證過程1000，但是本發(fā)明不是要由此受到限制。相反，本領域技術人員將從本文公開的內(nèi)容認識到用于認證過程1000的眾多可選方案。例如，賣方可以有利地被幾乎任何發(fā)出請求的應用程序，甚至是駐留在用戶系統(tǒng)105內(nèi)的應用程序，代替。例如，像Microsoft Word的客戶應用程序可以使用應用程序接口(API)或密碼API (CAPI)在解鎖文檔之前請求認證?？蛇x地，郵件服務器、網(wǎng)絡、蜂窩電話、個人或移動計算設備、工作站等都可以做出可以通過認證過程1000填寫的認證請求。事實上，在提供上述可信的認證過程1000后，發(fā)出請求的應用程序或設備可以提供對眾多電子或計算機設備或系統(tǒng)的訪問或使用。
[0167]而且，認證過程1000可以在認證失敗的情況下采用眾多可選的過程。例如，認證失敗可以維持同一個事務ID并請求用戶重新輸入他或她的當前認證數(shù)據(jù)。如上所述，使用同一個事務ID允許認證引擎215的比較器監(jiān)視并限制對特定事務的認證嘗試的次數(shù)，由此產(chǎn)生更安全的密碼系統(tǒng)100。
[0168]另外，可以有利地采用認證過程1000開發(fā)簡潔的單一簽署(sign-on)解決方案，例如解鎖敏感數(shù)據(jù)倉庫(vau11)。例如,成功或肯定的認證可以向通過認證的用戶提供自動訪問用于幾乎無限量系統(tǒng)或應用程序的任何次數(shù)的密碼的能力。例如，對用戶的認證可以向用戶提供對與多個在線賣方、局域網(wǎng)、不同的個人計算設備、互聯(lián)網(wǎng)服務提供商、拍賣提供商、投資經(jīng)紀人等相關的密碼、登錄、財經(jīng)證件等的訪問。通過采用敏感數(shù)據(jù)倉庫，用戶可以選擇真正大而隨機的密碼，因為他們不再需要通過聯(lián)想記住它們。相反，認證過程1000提供對它們的訪問。例如，用戶可以選擇長度超過二十位數(shù)的隨機字母數(shù)字字符串，而不是與難忘的數(shù)據(jù)、姓名等相關的什么東西。
[0169]根據(jù)一種實施例，與給定用戶相關聯(lián)的敏感數(shù)據(jù)倉庫可以有利地存儲在存儲庫210的數(shù)據(jù)儲存設施中，或者被分割并存儲在存儲庫系統(tǒng)700中。根據(jù)這種實施例，在肯定的用戶認證之后，信任引擎110將例如用于適當?shù)拿艽a的被請求的敏感數(shù)據(jù)供應給發(fā)出請求的應用程序。根據(jù)另一種實施例，信任引擎110可以包括用于存儲敏感數(shù)據(jù)倉庫的單獨的系統(tǒng)。例如，信任引擎110可以包括獨立的軟件引擎，該軟件引擎實施數(shù)據(jù)倉庫功能并且形象地駐留在信任引擎110的上述前端安全系統(tǒng)“后面”。根據(jù)這種實施例，軟件引擎在其從信任引擎110接收到指出肯定的用戶認證的信號之后供應被請求的敏感信號。
[0170]在還有另一種實施例中，可以由第三方系統(tǒng)實現(xiàn)數(shù)據(jù)倉庫。類似于軟件引擎實施例，第三方系統(tǒng)可以在其從信任引擎110接收到指出肯定的用戶認證的信號之后有利地供應被請求的敏感數(shù)據(jù)。根據(jù)還有另一種實施例，可以在用戶系統(tǒng)105上實現(xiàn)數(shù)據(jù)倉庫。用戶端軟件引擎可以在接收到來自信任引擎110的指出肯定的用戶認證的信號之后供給上述數(shù)據(jù)。
[0171]雖然參考其可選實施例公開了上述數(shù)據(jù)倉庫，但是本領域技術人員將從本文公開的內(nèi)容認識到其眾多的其他實現(xiàn)。例如，一種特定的數(shù)據(jù)倉庫可以包括來自上述實施例的一些或全部的多個方面。另外，任何上述數(shù)據(jù)倉庫都可以在不同時間采用一個或多個認證請求。例如，任何數(shù)據(jù)倉庫都可以在每隔一個或多個事務時、定期地、每隔一個或多個會話時、每次訪問一個或多個網(wǎng)頁或網(wǎng)站時、以一個或多個其它規(guī)定的時間間隔等，要求認證。
[0172]圖11說明了根據(jù)本發(fā)明一種實施例各方面的簽署過程1100的數(shù)據(jù)流。如圖11所示，簽署過程1100包括類似于之前參考圖10描述的認證過程1000的那些步驟。根據(jù)本發(fā)明的一種實施例，簽署過程1100首先認證用戶，然后執(zhí)行將如下更具體討論的幾種數(shù)字簽名功能之中的一個或多個。根據(jù)另一種實施例，簽署過程1100可以有利地存儲與其有關的數(shù)據(jù)，例如消息或文檔的哈希等。這個數(shù)據(jù)可以有利地用在檢查或任何其它事件中，例如當參與方嘗試拒絕接受事務時。
[0173]如圖11所示，在認證步驟期間，用戶和賣方可以有利地商定例如合同的消息。在簽署期間，簽署過程1100有利地確保由用戶簽署的合同與賣方提供的合同完全相同。因此，根據(jù)一種實施例，在認證期間，在傳輸?shù)秸J證引擎215的數(shù)據(jù)中，賣方和用戶包括他們各自的消息或合同副本的哈希。通過只采用消息或合同的哈希，信任引擎110可以有利地存儲顯著減少的數(shù)據(jù)量，提供一種更加有效和低成本高效益的密碼系統(tǒng)。此外，所存儲的哈?？梢杂欣嘏c考慮中的文檔的哈希進行比較，以確定考慮中的文檔是否與任何一方簽署的文檔匹配。確定該文檔是否與和事務有關的文檔完全相同的能力提供了能夠用于反對一方對事務拒絕的要求的額外證據(jù)。
[0174]在步驟1103，認證引擎215組裝注冊認證數(shù)據(jù)并將其與用戶提供的當前認證數(shù)據(jù)進行比較。當認證引擎215的比較器指出注冊認證數(shù)據(jù)與當前認證數(shù)據(jù)匹配時，認證引擎215的比較器還把賣方提供的消息的哈希與用戶提供的消息的哈希進行比較。因此，認證引擎215有利地確保用戶同意的消息與賣方同意的消息完全相同。
[0175]在步驟1105中，認證引擎215將數(shù)字簽名請求傳輸?shù)矫艽a引擎220。根據(jù)本發(fā)明的一種實施例，該請求包括消息或合同的哈希。但是，本領域技術人員將從本文公開的內(nèi)容認識到，密碼引擎220事實上可以加密任何類型的數(shù)據(jù)，包括但不限于視頻、音頻、生物測定、圖像或文本，以形成所需的數(shù)字簽名。返回到步驟1105，數(shù)字簽名請求優(yōu)選地包含通過傳統(tǒng)SSL技術傳送的XML文檔。
[0176]在步驟1110，認證引擎215將請求傳輸?shù)矫總€數(shù)據(jù)儲存設施Dl至D4，使得每個數(shù)據(jù)儲存設施Dl至D4都傳輸對應于簽署方的一個或多個密碼密鑰中他們各自的部分。根據(jù)另一種實施例，密碼引擎220采用之前討論過的互操作性過程970的一些或全部步驟，使得密碼引擎220首先確定要為簽署方從存儲庫210或存儲庫系統(tǒng)700請求的一個或多個適當密鑰，并且采取動作來提供適當?shù)钠ヅ涿荑€。根據(jù)還有另一種實施例，認證引擎215或密碼引擎220可以有利地請求與簽署方相關并且存儲在存儲庫210或存儲庫系統(tǒng)700中的一個或多個密鑰。
[0177]根據(jù)一種實施例，簽署方包括用戶和賣方之一或兩者都包括。在這種情況下，認證引擎215有利地請求對應于用戶和/或賣方的密碼密鑰。根據(jù)另一種實施例，簽署方包括信任引擎110。在這種實施例中，信任引擎110證實認證過程1000正確地認證了用戶、賣方或者這兩者。因此，認證引擎215請求信任引擎110的密碼密鑰，例如像屬于密碼引擎220的密鑰，以執(zhí)行數(shù)字簽名。根據(jù)另一種實施例，信任引擎110執(zhí)行類似數(shù)字公證員的功能。在這種實施例中，簽署方包括用戶、賣方或者兩者都包括，以及信任引擎110。因此，信任引擎110提供用戶和/或賣方的數(shù)字簽名，然后用它自己的數(shù)字簽名指出用戶和/或賣方得到了正確認證。在這種實施例中，認證引擎215可以有利地請求對應于用戶、賣方或者這兩者的密碼密鑰的組裝。根據(jù)另一種實施例，認證引擎215可以有利地請求對應于信任引擎110的密碼密鑰的組裝。
[0178]根據(jù)另一種實施例，信任引擎110執(zhí)行類似代理人職能的功能。例如，信任引擎110可以代表第三方的利益數(shù)字簽署消息。在這種情況下，認證引擎215請求與該第三方相關的密碼密鑰。根據(jù)這種實施例，在允許類似代理人職能的功能之前，簽署過程1100可以有利地包括第三方的認證。此外,認證過程1000可以包括對第三方約束的檢查，例如指出何時和在什么情形下可以使用特定的第三方簽名的商業(yè)邏輯等。
[0179]基于以上所述，在步驟1110中，認證引擎從對應于簽署方的數(shù)據(jù)儲存設施Dl至D4請求密碼密鑰。在步驟1115中，數(shù)據(jù)儲存設施Dl至D4將對應于簽署方的密碼密鑰中它們各自的部分傳輸?shù)矫艽a引擎220。根據(jù)一種實施例,上述傳輸包括SSL技術。根據(jù)另一種實施例，上述傳輸可以有利地用密碼引擎220的公鑰進行超級加密。
[0180]在步驟1120中，密碼引擎220組裝簽署方的上述密碼密鑰，并且用其加密消息，由此形成一個或多個數(shù)字簽名。在簽署過程1100的步驟1125中，密碼引擎220將這一個或多個數(shù)字簽名傳輸給認證引擎215。在步驟1130中，認證引擎215將填好的認證請求連同被哈希的消息和一個或多個數(shù)字簽名的副本一起傳輸?shù)绞聞找?05。在步驟1135中，事務引擎205將包括事務ID、認證是否成功的指示和一個或多個數(shù)字簽名的收據(jù)傳輸?shù)劫u方。根據(jù)一種實施例，上述傳輸可以有利地包括信任引擎110的數(shù)字簽名。例如，信任引擎110可以用它的私鑰加密收據(jù)的哈希，由此形成要附到給賣方的傳輸?shù)臄?shù)字簽名。
[0181]根據(jù)一種實施例，事務引擎205還將確認消息傳輸?shù)接脩簟１M管參考其優(yōu)選和可選實施例公開了簽署過程1100，但是本發(fā)明不是要由此受到限制。相反，本領域技術人員將從本文公開的內(nèi)容認識到用于簽署過程1100的眾多可選方案。例如，賣方可以被例如電子郵件應用程序的用戶應用程序代替。例如，用戶可能希望用他或她的數(shù)字簽名數(shù)字簽署特定的電子郵件。在這樣一種實施例中，貫穿簽署過程1100的傳輸可以有利地只包括消息的哈希的一個副本。此外，本領域技術人員將從本文公開的內(nèi)容認識到，眾多的客戶應用程序都可以請求數(shù)字簽名。例如，客戶應用程序可以包含文字處理器、電子制表軟件、電子郵件、語音郵件、對受限系統(tǒng)區(qū)域的訪問等。
[0182]此外，本領域技術人員將從本文公開的內(nèi)容認識到，簽署過程1100的步驟1105至1120可以有利地采用圖9B的互操作性過程970的一些或全部步驟，由此在可能例如需要處理具有不同簽名類型的數(shù)字簽名的不同密碼系統(tǒng)之間提供互操作性。
[0183]圖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ā)送者將產(chǎn)生同步會話密鑰，并使用更簡單更快的對稱密鑰系統(tǒng)加密消息。然后，發(fā)送者將用接收者的公鑰加密會話密鑰。加密后的會話密鑰將附到同步加密的消息，并且兩個數(shù)據(jù)都發(fā)送到接收者。接收者使用他或她的私鑰解密會話密鑰，然后使用會話密鑰來解密消息?；谝陨纤?，更簡單更快的對稱密鑰系統(tǒng)被用于大多數(shù)的加密/解密處理。因此，在解密過程1200中，解密有利地假設同步密鑰已經(jīng)利用用戶的公鑰加密了。因此，如上所述，加密后的會話密鑰包括在認證請求中。
[0184]返回解密過程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都將密碼密鑰中它們各自的部分傳輸?shù)矫艽a引擎220。根據(jù)一種實施例，上述傳輸是用密碼引擎220的公鑰加密的。
[0185]在解密過程1200的步驟1220中，密碼引擎220組裝密碼密鑰并用其解密會話密鑰。在步驟1225中，密碼引擎將會話密鑰轉(zhuǎn)發(fā)到認證引擎215。在步驟1227中，認證引擎215填寫包括解密后的會話密鑰的認證請求，并將填好的認證請求傳輸?shù)绞聞找?05。在步驟1230中，事務引擎205將認證請求連同會話密鑰一起轉(zhuǎn)發(fā)到發(fā)出請求的應用程序或賣方。然后，根據(jù)一種實施例，發(fā)出請求的應用程序或賣方使用該會話密鑰解密加密的消息。
[0186]盡管參考其優(yōu)選和可選實施例公開了解密過程1200，但是本領域技術人員將從本文公開的內(nèi)容認識到用于解密過程1200的眾多可選方案。例如，解密過程1200可以走在同步密鑰加密之前并且依賴完全公鑰技術。在這樣一種實施例中，發(fā)出請求的應用程序可以將全部消息傳輸?shù)矫艽a引擎220，或者可以采用某些類型的壓縮或可逆哈希，以便將消息傳輸?shù)矫艽a引擎220。本領域技術人員還將從本文公開的內(nèi)容認識到，上述通信可以有利地包括用SSL技術包裝的(wrapped) XML文檔。
[0187]加密/解密過程1200還提供對文檔或其它數(shù)據(jù)的加密。因此，在步驟1235中，發(fā)出請求的應用程序或賣方可以有利地將對用戶公鑰的請求傳輸?shù)叫湃我?10的事務引擎205。發(fā)出請求的應用程序或賣方做出這個請求是因為，例如，發(fā)出請求的應用程序或賣方使用用戶的公鑰來加密用于加密文檔或消息的會話密鑰。如在注冊過程900中所提到的，事務引擎205將用戶的數(shù)字證書的副本存儲在例如海量儲存器225中。因此，在加密過程1200的步驟1240中，事務引擎205從海量儲存器225請求用戶的數(shù)字證書。在步驟1245中，海量儲存器225將對應于用戶的數(shù)字證書傳輸?shù)绞聞找?05。在步驟1250中，事務引擎205將數(shù)字證書傳輸?shù)桨l(fā)出請求的應用程序或賣方。根據(jù)一種實施例，加密過程1200的加密部分不包括用戶的認證。這是因為發(fā)出的請求賣方只需要用戶的公鑰而且不請求任何敏感數(shù)據(jù)。
[0188]本領域技術人員將從本文公開的內(nèi)容認識到，如果特定用戶不具有數(shù)字證書，則信任引擎110可以采用注冊過程900的一部分或全部來為該特定用戶生成數(shù)字證書。然后，信任引擎110可以啟動加密/解密過程1200并由此提供適當?shù)臄?shù)字證書。此外，本領域技術人員將從本文公開的內(nèi)容認識到，加密/解密過程1200的步驟1220和1235至1250可以有利地采用圖9B的互操作性過程的一些或全部步驟，由此提供可能例如需要處理加密的不同密碼系統(tǒng)之間的互操作性。
[0189]圖13說明了根據(jù)本發(fā)明還有另一種實施例各方面的信任引擎系統(tǒng)1300的簡化框圖。如圖13所示，信任引擎系統(tǒng)1300分別包括多個不同的信任引擎1305、1310、1315和1320。為了便于更加完全地理解本發(fā)明，圖13將每個信任引擎1305、1310、1315和1320說明為具有事務引擎、存儲庫和認證引擎。但是，本領域技術人員將認識到，每個事務引擎都可以有利地包括參考圖1-圖8公開的元素和通信信道的一些、組合或者全部。例如，一種實施例可以有利地包括具有一個或多個事務引擎、存儲庫和密碼服務器或其任何組合的信任引擎。
[0190]根據(jù)本發(fā)明的一種實施例，每個信任引擎1305、1310、1315和1320都是地理上分離的，使得例如信任引擎1305可以駐留在第一位置中，信任引擎1310可以駐留在第二位置中，信任引擎1315可以駐留在第三位置中，而信任引擎1320可以駐留在第四位置中。上述地理分離有利地減少了系統(tǒng)響應時間，同時增加了整個信任引擎系統(tǒng)1300的安全性。
[0191]例如，當用戶登錄到密碼系統(tǒng)100上時，用戶可能離第一位置最近并且可能期望被認證。如參考圖10所描述的，為了被認證，用戶提供例如生物測定等的當前認證數(shù)據(jù)，并且該當前認證數(shù)據(jù)被與用戶的注冊認證數(shù)據(jù)比較。因此，根據(jù)一個例子，用戶有利地將當前認證數(shù)據(jù)提供給地理上最近的信任引擎1305。然后，信任引擎1305的事務引擎1321將當前認證數(shù)據(jù)轉(zhuǎn)發(fā)到同樣駐留在該第一位置的認證引擎1322。根據(jù)另一種實施例，事務引擎1321將當前認證數(shù)據(jù)轉(zhuǎn)發(fā)到信任引擎1310、1315或1320的一個或多個認證引擎。
[0192]事務引擎1321還請求組裝來自例如每個信任引擎1305至1320的存儲庫的注冊認證數(shù)據(jù)。根據(jù)這種實施例，每個存儲庫都將注冊認證數(shù)據(jù)中它的那部分提供給信任引擎1305的認證引擎1322。然后，認證引擎1322采用來自例如前兩個存儲庫的被加密數(shù)據(jù)部分來作出響應，并將注冊認證數(shù)據(jù)組裝成被破譯的形式。認證引擎1322將注冊認證數(shù)據(jù)與當前認證數(shù)據(jù)進行比較并且將認證結果返回到信任引擎1305的事務引擎1321。
[0193]基于以上所述，信任引擎系統(tǒng)1300采用多個地理上分離的信任引擎1305至1320中最近的一個來執(zhí)行認證過程。根據(jù)本發(fā)明的一種實施例，將信息路由到最近的事務引擎可以有利地在客戶端小程序執(zhí)行，該客戶端小程序在用戶系統(tǒng)105、賣方系統(tǒng)120或證書機構115中的一個或多個上執(zhí)行。根據(jù)一種可選實施例，可以采用更加精密的決策過程從信任引擎1305至1320進行選擇。例如，決策可以基于給定信任引擎的可用性、操作性、連接速度、負荷、性能、地理接近度或者其組合。
[0194]以這種方式，信任引擎系統(tǒng)1300使其響應時間更低，同時維持與地理上遠程的數(shù)據(jù)儲存設施相關的安全優(yōu)點，例如參考圖7討論過的那些，在圖7中每個數(shù)據(jù)存儲設施都存儲敏感數(shù)據(jù)被隨機化的部分。例如，在例如信任引擎1315的存儲庫1325的安全損害不一定損害信任引擎系統(tǒng)1300的敏感數(shù)據(jù)。這是因為存儲庫1325只包含不可破譯的被隨機化的數(shù)據(jù)，如果沒有更多的話，這種數(shù)據(jù)是完全沒用的。
[0195]根據(jù)另一種實施例，信任引擎系統(tǒng)1300可以有利地包括布置成類似于認證引擎的多個密碼引擎。密碼引擎可以有利地執(zhí)行密碼功能，例如參考圖1-圖8所公開的那些。根據(jù)還有另一種實施例，信任引擎系統(tǒng)1300可以有利地用多個密碼引擎代替多個認證引擎，由此執(zhí)行例如參考圖1-圖8所公開的那些的密碼功能。根據(jù)本發(fā)明還有另一種實施例，信任引擎系統(tǒng)1300可以用具有上述公開的認證引擎、密碼引擎或者這兩者的功能的一些或全部的引擎代替多個認證引擎中的每一個。
[0196]盡管參考其優(yōu)選和可選實施例公開了信任引擎系統(tǒng)1300，但是本領域技術人員將認識到，信任引擎系統(tǒng)1300可以包括信任引擎1305至1320的部分。例如，信任引擎系統(tǒng)1300可以包括一個或多個事務引擎，一個或多個存儲庫，一個或多個認證引擎或者一個或多個密碼引擎或者其組合。
[0197]圖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的客戶端小程序與信任引擎系統(tǒng)1400通信時，那些通信被發(fā)送給每個信任引擎1405至1420的IP地址。此外，每個信任引擎1405、1410、1415和1420的每個事務引擎的行為都類似于參考圖13所公開的信任引擎1305的事務引擎1321。例如，在認證過程期間，每個信任引擎1405、1410、1415和1420的每個事務引擎都將當前認證數(shù)據(jù)傳輸?shù)剿鼈兏髯缘恼J證引擎，并傳輸請求，以組裝存儲在每個信任引擎1405至1420的每個存儲庫中的隨機化的數(shù)據(jù)。圖14沒有說明這些通信的全部；不然這種說明將變得過于復雜。繼續(xù)認證過程，然后，每個存儲庫將它的被隨機化數(shù)據(jù)部分傳送給每個信任引擎1405至1420的每個認證引擎。每個信任引擎的每個認證引擎都采用它的比較器來確定當前認證數(shù)據(jù)與通過每個信任引擎1405至1420的存儲庫提供的注冊認證數(shù)據(jù)是否匹配。根據(jù)這種實施例，然后，每個認證引擎的比較結果傳輸?shù)狡渌齻€信任引擎的冗余模塊。例如，來自信任引擎1405的認證引擎的結果傳輸?shù)叫湃我?410、1415和1420的冗余模塊。因此，信任引擎1405的冗余模塊也同樣接收來自信任引擎1410、1415和1420的認證引擎的結果。
[0198]圖15說明了圖14的冗余模塊的框圖。該冗余模塊包括比較器，比較器被配置成從三個認證引擎接收認證結果并將該結果傳輸?shù)剿膫€信任引擎的事務引擎。比較器比較來自三個認證引擎的認證結果，并且如果兩個結果一致，比較器就斷定認證結果應該與兩個一致的認證引擎的認證結果匹配。然后，這個結果傳輸回到對應于與這三個認證引擎無關的信任引擎的事務引擎。
[0199]基于以上所述，冗余模塊由從認證引擎接收到的數(shù)據(jù)確定認證結果，該認證引擎優(yōu)選在地理上遠離該冗余模塊的信任引擎。通過提供這種冗余功能，信任引擎系統(tǒng)1400確保信任引擎1405至1420之一的認證引擎的損害不足以損害該特定信任引擎的冗余模塊的認證結果。本領域技術人員將認識到，信任引擎系統(tǒng)1400的冗余模塊功能還可以應用到每個信任引擎1405至1420的密碼引擎。但是，這種密碼引擎通信未在圖14中示出，以免復雜。而且，本領域技術人員將認識到，對于圖15的比較器的眾多可選認證結果沖突消解算法都適于在本發(fā)明中使用。
[0200]根據(jù)本發(fā)明的還有另一種實施例，信任引擎系統(tǒng)1400在密碼比較步驟期間可以有利地采用冗余模塊。例如，可以在由一方或多方在特定事務階段提供的文檔的哈希比較期間有利地實現(xiàn)參考圖14和15公開的上述冗余模塊的一部分或全部。
[0201]盡管已經(jīng)就某些優(yōu)選和可選實施例描述了上述發(fā)明，但是由本文公開的內(nèi)容，其他實施例對本領域普通技術人員也將是顯而易見的。例如，信任引擎110可以發(fā)布短期證書，在該短期證書中私有的密碼密鑰被釋放給用戶預定的時間段。例如，當前證書標準包括有效性域，該有效性域可以被設置成在預定量時間之后過期。因此，信任引擎110可以將私有密鑰釋放給用戶，該私有密鑰將是例如24小時有效。根據(jù)這樣一種實施例，信任引擎110可以有利地發(fā)布與特定用戶相關聯(lián)的新密碼密鑰對，然后釋放該新密碼密鑰對的私鑰。隨后,一旦私有密碼密鑰被釋放,信任引擎110就立即終止這種私有密鑰的任何內(nèi)部有效使用，因為它不再能夠被信任引擎110保護。
[0202]此外，本領域技術人員將認識到，密碼系統(tǒng)100或信任引擎110可以包括認出任何類型設備的能力，例如但不限于膝上型電腦、手機電話、網(wǎng)絡、生物測定設備等。根據(jù)一種實施例，這種認出可以來自在對特定服務的請求中提供的數(shù)據(jù)，例如對導致訪問或使用的認證的請求、對密碼功能的請求等。根據(jù)一種實施例，上述請求可以包括例如像處理器ID的唯一設備標識符?？蛇x地，請求可以包括具有特定可認出的數(shù)據(jù)格式的數(shù)據(jù)。例如，移動電話和衛(wèi)星電話經(jīng)常不包括對完全X509.v3重加密證書的處理職能，因此不能請求它們。根據(jù)這種實施例，信任引擎110可以認出所給出的數(shù)據(jù)格式的類型，并且只用這個類型響應。
[0203]在上述系統(tǒng)的其它方面中，可以使用將如下所述的各種技術來提供背景敏感的認證。如圖16所示，背景敏感的認證提供不僅評估當嘗試認證用戶自己時由用戶發(fā)送的實際數(shù)據(jù)而且評估圍繞該數(shù)據(jù)的產(chǎn)生和交付的情形的可能性。這種技術還可以支持用戶與信任引擎110之間或賣方與信任引擎110之間的事務專用信任仲裁，如下面將要描述的。
[0204]如以上所討論的，認證是證明一個用戶就是他說的那個人的過程?？偟膩碚f，認證需要向證書機構證明一些事實。本發(fā)明的信任引擎110代表用戶必須向它認證他自己的機構。用戶必須通過以下任意一個來向信任引擎110展示他就是他說的那個人:知道只有該用戶應該知道的一些事情(基于知識的認證)、具有只有該用戶應該具有的一些東西(基于標記的認證)、或者通過是只有用戶應該是的一些東西(基于生物測定的認證)。
[0205]基于知識的認證的例子包括但不限于密碼、PIN號或鎖定組合。基于標記的認證的例子包括但不限于房屋鑰匙、物理信用卡、司機的駕照或特定的電話號碼?；谏餃y定的認證的例子包括但不限于指紋、筆跡分析、面部掃描、手掃描、耳朵掃描、虹膜掃描、血管掃描、DNA、語音分析或視網(wǎng)膜掃描。
[0206]每種類型的認證都具有特定的優(yōu)點和缺點，并且每種都提供不同的安全級別。例如，產(chǎn)生與某個其他人匹配的錯誤指紋比偶然聽到某人的密碼并重復它通常更難。每種類型的認證還要求不同類型的數(shù)據(jù)被證書機構知道，以便使用那種形式的認證來驗證某人。
[0207]如在此所使用的，“認證”將廣泛地指為驗證某人的身份就是他說的那個人的全過程?！罢J證技術”將指基于特定的一塊知識、物理標記或生物測定讀數(shù)的特定認證類型?！罢J證數(shù)據(jù)”指發(fā)送到或者以別的方式證明給證書機構以便確立身份的信息?！白詳?shù)據(jù)”將指最初提交給證書機構以便建立用于與認證數(shù)據(jù)進行比較的基線的數(shù)據(jù)。“認證實例”將指與嘗試通過認證技術進行認證有關的數(shù)據(jù)。
[0208]上面參考圖10描述了在認證用戶的過程中涉及到的內(nèi)部協(xié)議和通信。該過程中背景敏感認證發(fā)生的那部分在如圖10的步驟1045所示的比較步驟內(nèi)發(fā)生。這個步驟發(fā)生在認證引擎215內(nèi)并且涉及組裝從存儲庫210取回(檢索，retrieve)到的注冊數(shù)據(jù)410并把用戶提供的認證數(shù)據(jù)與它進行比較。這個過程的一種特定實施例在圖16中示出并且在下面進行描述。
[0209]在圖16的步驟1600中，認證引擎215接收用戶提供的當前認證數(shù)據(jù)和從存儲庫210取回到的注冊數(shù)據(jù)。這兩個數(shù)據(jù)集都可以包含與各自的認證技術有關的數(shù)據(jù)。認證引擎215在步驟1605中分離與每個個別認證實例相關的認證數(shù)據(jù)。這是必要的，以便使得認證數(shù)據(jù)可以與用于用戶的注冊數(shù)據(jù)的適當子集進行比較(例如，指紋認證數(shù)據(jù)應該與指紋注冊數(shù)據(jù)而不是密碼注冊數(shù)據(jù)進行比較)。
[0210]總的來說，依賴于哪種認證技術對用戶可用，認證一個用戶涉及一個或多個個別的認證實例。這些方法受限于用戶在他的注冊過程期間提供的注冊數(shù)據(jù)(如果用戶在注冊時不提供視網(wǎng)膜掃描，他將不能使用視網(wǎng)膜掃描認證他自己)，以及當前對用戶可用的手段(例如，如果用戶在他的當前位置不具有指紋閱讀器，指紋認證將是不實際的)。在一些情況下，單個認證實例可能足以認證用戶；但是，在某些情形下，為了特定事務更肯定地認證用戶，可以使用多個認證實例的組合。
[0211]每個認證實例都由與特定認證技術(例如指紋、密碼、智能卡等)有關的數(shù)據(jù)和圍繞用于該特定技術的數(shù)據(jù)的捕獲和交付的情形組成。例如，嘗試經(jīng)密碼進行認證的特定實例將不僅產(chǎn)生與密碼本身有關的數(shù)據(jù)，而且產(chǎn)生與密碼嘗試有關的、被稱為“元數(shù)據(jù)”的旁證數(shù)據(jù)(circumstantial data)。這種旁證數(shù)據(jù)包括例如下列信息:特定認證實例發(fā)生的時間，認證信息從哪里被交付的網(wǎng)絡地址，以及本領域技術人員已知的可以關于認證數(shù)據(jù)的來源進行確定的任何其它信息(連接類型，處理器序列號等)。
[0212]在許多情況下，只有少量的旁證元數(shù)據(jù)將是可用的。例如，如果用戶位于使用代理或網(wǎng)絡地址翻譯或屏蔽原計算機的地址的其它技術的網(wǎng)絡上，則只有代理或路由器的地址可以被確定。同樣，在許多情況下，例如處理器序列號的信息將不可用，因為要么是所使用的硬件或操作系統(tǒng)的限制、系統(tǒng)的操作者禁止這種特征，要么是用戶的系統(tǒng)與信任引擎110之間連接的其它限制。
[0213]如圖16所示，一旦在步驟1605中在認證數(shù)據(jù)內(nèi)提供的各個認證實例被提取和分離，認證引擎215就對每個實例的可靠性進行評估，指出該用戶就是他所宣稱的那個人。通常將基于幾個因素確定單個認證實例的可靠性。這些因素可以被分組為:與認證技術相關的可靠性的因素，這些因素在步驟1610中被評估，和與所提供的特定認證數(shù)據(jù)的可靠性有關的因素，這些因素在步驟1815中被評估。第一組包括但不限于所使用的認證技術的固有可靠性及該方法所使用的注冊數(shù)據(jù)的可靠性。第二組包括但不限于注冊數(shù)據(jù)與認證實例提供的數(shù)據(jù)之間的匹配度及與該認證實例相關聯(lián)的元數(shù)據(jù)。這些因素中的每一個都可以獨立于其它因素而變化。
[0214]認證技術的固有可靠性是基于對于一個騙子而言提供其他人的正確數(shù)據(jù)有多難以及認證技術的總體誤差率。對于基于密碼和知識的認證方法，這個可靠性常常相當?shù)?，因為不能避免有人將他們的密碼暴露給另一個人而且這第二個人使用該密碼。即使基于更復雜知識的系統(tǒng)也可能只有中等程度的可靠性，因為知識可以很容易地從一個人傳送給另一個人。例如具有正確的智能卡或使用特定終端來執(zhí)行認證的基于標記的認證，在由它自己使用時同樣具有低可靠性，因為不能保證正確的人擁有正確的標記。
[0215]但是，生物測定技術是更加固有可靠的，因為它一般難以給某人提供以便利方式、甚至是故意地使用你的指紋的能力。因為破壞生物測定認證技術更困難，所以生物測定方法的固有可靠性一般高于純粹基于知識或標記物的認證技術。但是，即使生物測定技術也可能具有一些產(chǎn)生錯誤接受或錯誤拒絕的場合。這些事件可以通過用于同一種生物測定技術的不同實現(xiàn)的不同可靠性反映出來。例如，一個公司提供的指紋匹配系統(tǒng)可以比另一個公司提供的指紋匹配系統(tǒng)提供更高的可靠性，因為這個公司使用更高質(zhì)量的光學設備或更好的掃描分辨率或減少錯誤接受或錯誤拒絕發(fā)生的一些其它改進。[0216]應當指出，這種可靠性可以用不同方式來表達。期望將可靠性表達成某種量度，這種量度能夠被試探法530和認證引擎215的算法用來計算每個認證的置信度。表達這些可靠性的一種優(yōu)選模式是作為百分比或分數(shù)。例如，指紋可以被分配97%的固有可靠性，而密碼可以只被分配為50%的固有可靠性。本領域技術人員將認識到，這些特定的值僅僅是示例性的并且可以在具體實現(xiàn)之間變化。
[0217]必須對其可靠性進行評估的第二個因素是注冊的可靠性。這是上面提到的“分級注冊”的一部分。這個可靠性因素反映出在最初的注冊過程期間所提供的認證的可靠性。例如，如果個人最初以他們給公證員或其他公職人員物理產(chǎn)生他們的身份的證據(jù)的方式注冊，并且注冊數(shù)據(jù)當時被記錄和公正，那么該數(shù)據(jù)將比在注冊期間通過網(wǎng)絡提供的和僅僅由并非真正綁定個人的數(shù)字簽名或其它信息擔保的數(shù)據(jù)更加可靠。
[0218]可靠性級別變化的其它注冊技術包括但不限于:在信任引擎110操作者的實體辦公室注冊；在用戶的就業(yè)場所注冊；在郵局或護照辦公室注冊；通過信任引擎110操作者的下屬方或信任方注冊；所注冊的身份尚未利用特定真人識別的匿名或筆名注冊以及本領域已知的這種其它手段。
[0219]這些因素反映出信任引擎110與注冊過程期間提供的識別來源之間的信任。例如，如果在提供身份證據(jù)的最初過程期間與雇主相關地執(zhí)行注冊，這個信息就可以被視為對于公司內(nèi)部目的是極其可靠的，但是對于政府機構、或競爭對手而言可能是較低的信任度。因此，由這些其它組織中每一個操作的信任引擎可以將不同的可靠性級別分配給這個注冊。
[0220]類似地，通過網(wǎng)絡提交但是通過之前用同一個信任引擎110注冊期間提供的其它被信任數(shù)據(jù)認證的附加數(shù)據(jù)可以被視為與原始注冊數(shù)據(jù)一樣可靠，即使后者的數(shù)據(jù)是通過開放式網(wǎng)絡提交的。在這種情況下，后續(xù)的公正將有效增加與原始注冊數(shù)據(jù)相關的可靠性級別。以這種方式，例如，通過給一些注冊官方展示與注冊數(shù)據(jù)匹配的個人身份，于是匿名或筆名注冊可以被升至完全注冊。
[0221]以上討論的可靠性因素通常是可以在任何特定認證實例之前被確定的值。這是因為它們是基于注冊和技術，而不是實際的認證。在一種實施例中，基于這些因素產(chǎn)生可靠性的步驟涉及為這種特定的認證技術和用戶的注冊數(shù)據(jù)查找之前被確定的值。在本發(fā)明一種有利實施例的另一方面中，這種可靠性可以被注冊數(shù)據(jù)本身包括。以這種方式，這些因素連同由存儲庫210發(fā)送的注冊數(shù)據(jù)一起自動交付給認證引擎215。
[0222]盡管這些因素通?？梢栽谌魏蝹€人認證實例之前被確定，但是它們對使用用于那個用戶認證的那種特定技術的每個認證實例都有影響。此外，盡管這些值可能隨時間改變(例如，如果用戶以更加可靠的方式重新注冊)，但是它們不依賴認證數(shù)據(jù)本身。與此相反，與單個具體實例的數(shù)據(jù)相關的可靠性因素可以針對每種場合而變。必須為每個新認證而對這些因素進行評估，以便在步驟1815中產(chǎn)生可靠性分數(shù)，如以下所討論的。
[0223]認證數(shù)據(jù)的可靠性反映出用戶在特定認證實例中提供的數(shù)據(jù)與在認證注冊期間提供的數(shù)據(jù)之間的匹配。對于用戶宣稱他就是的那個個人而言，認證數(shù)據(jù)與注冊數(shù)據(jù)是否匹配是最基本的問題。通常，當數(shù)據(jù)不匹配時，用戶被視為未被成功認證，并且認證失敗。對此進行評估的方式可以依賴所使用的認證技術而變。這種數(shù)據(jù)的比較是由如圖5所示的認證引擎215的比較器515的功能來執(zhí)行的。[0224]例如，一般以二進制方式評估密碼的匹配。換言之，密碼要么完美匹配，要么不匹配。接受即使是部分匹配的密碼通常也是不期望的，其中部分匹配的密碼如果不是完全正確的話就是接近于正確的密碼。因此，當對密碼認證進行評估時，由比較器515返回的認證的可靠性通常要么是100% (正確)要么是0% (錯誤)，沒有中間值的可能性。
[0225]與用于密碼的規(guī)則類似的規(guī)則通常應用到基于標記的認證方法，例如智能卡。這是因為有一張具有類似標識符或類似于正確智能卡的智能卡仍然與具有任何其它不正確標記是一樣錯誤的。因此，標記也傾向于是二進制認證器:用戶要么有正確的標記，要么沒有。
[0226]但是，例如問卷和生物測定的某些類型的認證數(shù)據(jù)一般不是二進制認證器。例如，指紋可以與參考指紋有變化程度的匹配。在某種程度上，這可能是由于在最初注冊期間或在后續(xù)認證中所捕捉到的數(shù)據(jù)在質(zhì)量方面的變化。(指紋可能被弄臟或者一個人在特定的手指上可能有仍在康復中的傷疤或燒傷)。在其他實例中，數(shù)據(jù)可能不太完美地匹配，因為信息本身也會有些可變并且是基于模式匹配。(語音分析可看起來接近但不是完全正確，因為記錄語音時的背景噪聲或環(huán)境聲響，或者因為這個人感冒了)。最后，在大量數(shù)據(jù)被比較的情況下，情況可能只不過是大部分數(shù)據(jù)匹配良好，但是一些數(shù)據(jù)匹配不良好。(十個問題的問卷可能導致對人員問題的八個正確回答，以及兩個錯誤回答)。對于這些原因中的任何原因，注冊數(shù)據(jù)與用于特定認證實例的數(shù)據(jù)之間的匹配可能期望由比較器515分配一個部分匹配值。以這種方式，例如，指紋可能被說成是85%匹配，聲紋是65%匹配，而問卷是80%匹配。
[0227]由比較器515產(chǎn)生的這個測量(匹配度)是代表認證是正確還是錯誤的基本問題的因素。但是，如以上所討論的，這只是可以在確定給定認證實例的可靠性中使用的因素之一。還應當注意，即使可以確定最終匹配到某部分程度，但基于部分匹配提供二進制結果可能還是期望的。在一種可選的操作模式中，還有可能基于匹配度是否超過特定的匹配閥值水平而將部分匹配作為二進制來看待，即，要么完美匹配(100%)，要么不匹配(0%)。這種過程可以用于為將以別的方式產(chǎn)生部分匹配的系統(tǒng)提供簡單的匹配通過/失敗級別。
[0228]在評估給定認證實例的可靠性中要考慮的另一個因素涉及提供用于這個特殊實例的認證數(shù)據(jù)所處的情形。如以上所討論的，該情形指與特定認證實例相關聯(lián)的元數(shù)據(jù)。這可以包括但不限于例如這種信息:認證者的網(wǎng)絡地址；能夠被確定到的程度；認證的時間，認證數(shù)據(jù)傳輸?shù)哪Ｊ?電話線、蜂窩、網(wǎng)絡等)；及認證者的系統(tǒng)的序列號。
[0229]這些因素可以用于產(chǎn)生通常被用戶請求的認證類型的簡檔。然后，該信息可以用于以至少兩種方式訪問可靠性。一種方式是考慮用戶是否正在以一種方式請求認證，這種方式與通過該用戶認證的標準簡檔一致。如果用戶通常在工作日期間(當她在工作時)從一個網(wǎng)絡地址而在晚上或周末期間(當她在家時)從一個不同的網(wǎng)絡地址做出認證請求，則在工作日期間從家庭地址發(fā)生的認證是不太可靠的，因為它在正常的認證簡檔之外。類似地，如果用戶通常使用指紋生物并且在晚上認證，則日間只使用密碼發(fā)起的認證是不太可靠的。
[0230]旁證元數(shù)據(jù)可以用于評估認證實例的可靠性的另一種方式是確定環(huán)境提供了多少該認證者就是他宣稱的那個個人的進一步證據(jù)。例如，如果認證來自具有已知與該用戶相關的序列號的系統(tǒng)，那么這是用戶就是他宣稱的那個人的良好旁證指示器。反之，如果認證來自已知是洛杉磯的網(wǎng)絡地址而用戶已知是住在倫敦，則基于其環(huán)境，這是該認證不太可靠的指示。
[0231]當用戶與賣方系統(tǒng)或者與信任引擎110交互時，還有可能Cookie或其它電子數(shù)據(jù)放在用戶使用的系統(tǒng)上。這種數(shù)據(jù)寫到用戶系統(tǒng)的儲存器并且可以包含可以被用戶系統(tǒng)上的網(wǎng)絡瀏覽器或其它軟件讀取的識別。如果在會話之間允許這種數(shù)據(jù)駐留在用戶系統(tǒng)上(“持久的Cookie”)，則在特定的用戶認證期間它可以與認證數(shù)據(jù)一起發(fā)送，作為過去使用過這個系統(tǒng)的進一步證據(jù)。事實上，給定實例的元數(shù)據(jù)，尤其是持久的Cookie，可以形成一種基于標記的認證器本身。
[0232]一旦如上所述分別在步驟1610和1615中基于認證實例的技術和數(shù)據(jù)產(chǎn)生了適當?shù)目煽啃砸蛩?，它們就被用于為在步驟1620中提供的認證實例產(chǎn)生總體可靠性。完成這個任務的一種手段是將每個可靠性簡單地表達為百分比然后使它們相乘。
[0233]例如，假設認證數(shù)據(jù)是從完全根據(jù)用戶過去的認證簡檔(100%)已知是用戶的家庭計算機的網(wǎng)絡地址發(fā)送來的，并且所使用的技術是指紋識別(97%)，并且最初的指紋數(shù)據(jù)是通過具有認證引擎110的用戶的雇主擺出的(roistered) (90%)，而且認證數(shù)據(jù)與注冊數(shù)據(jù)中最初的指紋模板之間的匹配非常好(99%)。于是，這種認證實例的總體可靠性可以被計算為這些可靠性的乘積:100% * 97% * 90% * 99%-86.4%可靠性。
[0234]這個計算出的可靠性代表一個單個認證實例的可靠性。還可以使用一些技術計算單個認證實例的總體可靠性，這些技術例如通過使用一些公式對不同的可靠性因素進行不同處置，在這些公式中將不同的權重分配給每個可靠性因素。此外，本領域技術人員將認識至IJ，所使用的實際值可以代表除百分比之外的其它值并且可以使用非算術系統(tǒng)。一種實施例可以包括被由認證請求者用于為每個因素設置權重的模塊和在建立認證實例的總體可靠性中使用的算法。
[0235]認證引擎215可以使用上述技術及其變體來確定單個認證實例的可靠性，如步驟1620所指出的那樣。但是，在同時要提供多個認證實例的許多認證情形中它可能是有用的。例如，當嘗試使用本發(fā)明的系統(tǒng)認證他自己時，用戶可以提供用戶識別、指紋認證數(shù)據(jù)、智能卡和密碼。在這種情況下，三個獨立的認證實例提供給信任引擎110，用于評估。前進到步驟1625，如果認證引擎215確定用戶提供的數(shù)據(jù)包括多于一個認證實例，則每個實例又像步驟1630所示的那樣被選擇，并且像以上在步驟1610、1615和1620中所描述的那樣進行評估。
[0236]應當注意，所討論的許多可靠性因素都可以在這些實例中的一個與另一個之間發(fā)生變化。例如，這些技術的固有可靠性，以及認證數(shù)據(jù)與注冊數(shù)據(jù)之間提供的匹配度，都有可能不同。此外，用戶可能在不同的時間和不同的情形下已經(jīng)為這些技術中的每一個都提供了注冊數(shù)據(jù)，還為這些實例中的每一個提供了不同的注冊可靠性。最后，即使被提交的用于每個這些實例的數(shù)據(jù)所處的情形相同，這些技術的使用也可以每個都不同地適合用戶的簡檔，因此可以被分配不同的旁證可靠性。(例如，用戶通?？赡苁褂盟麄兊拿艽a和指紋，而不是他們的智能卡。)
[0237]因此，用于這些認證實例中每一個的最終可靠性可以各不相同。但是，通過一起使用多個實例，認證的總體置信級別將趨于增大。
[0238]一旦認證引擎已經(jīng)為認證數(shù)據(jù)中提供的所有認證實例執(zhí)行了步驟1610至1620，就在步驟1635中使用每個實例的可靠性來評估總體認證置信級別。將各認證實例可靠性結合到認證置信級別中的這個過程可以通過與所產(chǎn)生的各可靠性有關的各種方法進行模擬，并且還可以解決這些認證技術中的一些之間的特定交互。(例如，多個基于知識的系統(tǒng)，例如密碼，可以產(chǎn)生比單個密碼和甚至是例如基本語音分析的相當弱的生物測定更少的信任。)
[0239]其中認證引擎215可以結合多個并發(fā)認證實例的可靠性來產(chǎn)生最終置信級別的一種手段是使每個實例的不可靠性相乘，以獲得總體不可靠性。不可靠性一般是可靠性的互補百分數(shù)。例如，84%可靠的技術就是16%不可靠的。產(chǎn)生可靠性86%、75%和72%的上述三個認證實例(指紋、智能卡、密碼)具有分別為(100-86)%、(100-75)%和(100-72)%，或14%、25%和28%，的對應不可靠性。通過使這些不可靠性相乘，我們得到14% ± 25% *28%-0.98%不可靠性的累計不可靠性，這對應于99.02%的可靠性。
[0240]在另一種操作模式中，可以在認證引擎215內(nèi)應用別的因素和試探法530，來說明不同認證技術的互相依賴性。例如，如果某人尚未被認證有權訪問特定的家庭計算機，他們還可能有權訪問該地址的電話線。因此，基于源電話號碼以及基于認證系統(tǒng)的序列號的認證不會在認證過程中給總信任增加太多。但是，基于知識的認證在很大程度上不依賴于基于標記的認證(即，如果某人偷了你的蜂窩電話或密碼，則他們不會比沒做此事更有可能知道你的PIN或密碼)。
[0241]此外，不同賣方或其他認證請求者可能希望給認證的不同方面施以不同的權重。這可以包括使用單獨的權重因素或在計算各實例的可靠性過程中使用的算法，以及使用不同手段評估具有多個實例的認證事件。
[0242]例如，對于某種類型事務的賣方，例如社團電子郵件系統(tǒng)，可能期望主要基于試探法和默認的其它旁證數(shù)據(jù)進行認證。因此，他們可以將高的權重施加給與元數(shù)據(jù)和其它簡檔有關的因素，其中其它簡檔涉及與圍繞認證事件的情形相關的信息。通過不比用戶在工作日期間登錄到正確的機器上對用戶要求更多，這種安排可以用于在正常操作時間期間減輕用戶的負擔。但是，另一個賣方可能給來自特定技術的認證施加更重的權重，例如指紋匹配，這是因為這種技術最適于用于該特定賣方目的的認證的方針決策。
[0243]這種變化的權重可以由認證請求者在產(chǎn)生認證請求的過程中定義并且在一種操作模式中利用認證請求發(fā)送給信任引擎110。這種選項在用于認證請求者的最初注冊過程期間與可以被設置為偏好并在另一種操作模式中存儲在認證引擎內(nèi)。
[0244]—旦認證引擎215為所提供的認證數(shù)據(jù)產(chǎn)生了認證置信級別，這個認證級別就在步驟1640中用于完成認證請求，并且這個信息從認證引擎215轉(zhuǎn)發(fā)到事務引擎205，以便包括在給認證請求者的消息中。
[0245]上述過程只是示例性的，而且本領域技術人員將認識到，這些步驟不需要按照所示的順序執(zhí)行或者只期望執(zhí)行某些步驟，或者可能期望這些步驟的各種組合。此外，如果情形允許的話，某些步驟，例如對所提供的每個認證實例的可靠性的評估，可以彼此并行地執(zhí)行。
[0246]在本發(fā)明的另一方面中，提供了一種當上述過程產(chǎn)生的認證置信級別不滿足要求認證的賣方或其他方要求的信任級別時適應這種條件的方法。在例如所提供的置信級別與期望的信任級別之間存在差距的情形下，信任引擎110的操作者要給一方或兩方提供機會來提供替代數(shù)據(jù)或要求，以關閉這種信任差距。在本文中這個過程將被稱為“信任仲裁”。
[0247]信任仲裁可以在如上參考圖10和11所描述的密碼認證框架內(nèi)發(fā)生。如其中所示，賣方或其他方將請求與特定事務相關的特定用戶的認證。在一種情形下，賣方簡單地請求認證，要么肯定要么否定，并且在接收到來自用戶的適當數(shù)據(jù)后，信任引擎110將提供這種二進制認證。在例如這些的情形下，為了保證肯定的認證，所需的置信度是基于信任引擎110內(nèi)設置的偏好確定的。
[0248]但是，為了完成特定的事務，賣方還可能請求特定的信任級別。這個所需級別可以被包括在認證請求內(nèi)(例如，認證該用戶98%可信)或者可以由信任引擎110基于與事務相關的其它因素確定(即，將該用戶認證為對于該事務是適當?shù)?。一個這種因素可能是事務的經(jīng)濟價值。對于具有更大經(jīng)濟價值的事務，可能要求更高的信任度。同樣，對于具有高度風險的事務可以要求高信任度。反之，對于低風險或低價值的事務，可以要求賣方或其他認證請求者較低的信任級別。
[0249]信任仲裁過程發(fā)生在信任引擎110在圖10的步驟1050中接收認證數(shù)據(jù)與在圖10的步驟1055中將認證結果返回給賣方的步驟之間。在這些步驟之間，導致對信任級別和可能的信任仲裁進行評估過程發(fā)生，如圖17所示。在執(zhí)行簡單的二進制認證的情形下，圖17所示的過程縮小成使事務引擎205將所提供的認證數(shù)據(jù)與用于被識別用戶的注冊數(shù)據(jù)直接進行比較，如上面參考圖10所討論的，從而將任何差別都標志為否定的認證。
[0250]如圖17所示，在步驟1050中接收到數(shù)據(jù)后的第一步是讓事務引擎205確定對用于步驟1710中的這個特定事務的肯定認證要求的信任級別。這個步驟可以通過幾種不同方法之一執(zhí)行。在做出認證請求時，可以由認證請求者給信任引擎110規(guī)定要求的信任級另O。認證請求者還可以事先設置偏好，該偏好存儲在可通過事務引擎205訪問的存儲庫210或其它儲存器內(nèi)。然后這個偏好被讀取并在每次由這個認證請求者做出認證請求時使用。偏好還可以作為一種安全措施與特定用戶相關，使得為了認證該用戶總是要求特定的信任級別，其中用戶偏好存儲在可通過事務引擎205訪問的存儲庫210或其它儲存器中。還可以由事務引擎205或認證引擎215基于在認證請求中提供的信息，例如待認證事務的價值和風險級別，導出要求的級別。
[0251]在一種操作模式中，產(chǎn)生認證請求時所使用的策略管理模塊或其它軟件用于規(guī)定事務認證要求的信任度。當基于策略管理模塊內(nèi)規(guī)定的策略分配要求的信任度時，這可以用于提供一系列要遵守的規(guī)則。一種有利的操作模式是讓這樣一種模塊與賣方的網(wǎng)絡服務器合并，以便適當?shù)卮_定用于以賣方的網(wǎng)絡服務器啟動的事務所要求的信任級別。以這種方式，來自用戶的事務請求可以依據(jù)賣方的策略被分配一個要求的信任級別，并且這種信息可以連同認證請求一起轉(zhuǎn)發(fā)到信任引擎110。
[0252]這個被要求的信任級別與賣方想要使認證的個人事實上就是他將他自己識別成的那個人的確信度相關。例如，如果因為貨物轉(zhuǎn)手而使得事務是賣方想要中等確信度的那種事務，則賣方可能需要85%的信任級別。對于賣方只是認證用戶以便允許他只查看成員的內(nèi)容或練習聊天室的權利的狀況，負面風險可能小到足以使賣方只要求60%的信任級另O。但是，為了進入價值為好幾萬美元的產(chǎn)品合同，賣方可能需要99%或更高的信任級別。
[0253]這個被要求的信任級別代表用戶必須認證他自己以便完成該事務的量度。例如，如果要求的信任級別為85%，則用戶必須給信任引擎110提供認證，該認證足以使信任引擎110以85%的信心說出該用戶是他們說他們是的那個人。在這個被要求的信任級別與產(chǎn)生肯定認證(為了賣方滿意)或信任仲裁的可能性的認證置信級別之間存在一種平衡。
[0254]如圖17所示，事務引擎205接收到被要求的信任級別后，它在步驟1720中對被要求的信任級別與認證引擎215為當前認證計算的認證置信級別進行比較(如參考圖16所討論的)。如果在步驟1730中認證置信級別高于對事務要求的信任級別，則過程移到步驟1740，在步驟1740中由事務引擎205產(chǎn)生用于該事務的肯定認證。然后，為此目的的消息將被插到認證結果中并通過事務引擎205返回給賣方，如步驟1055所示(參見圖10)。
[0255]但是，在步驟1730中如果認證置信級別不滿足所要求的信任級別，則當前的認證存在置信差距，并且在步驟1750中進行信任仲裁。下面參考圖18更完整地描述信任仲裁。如下所述的這個過程發(fā)生在信任引擎110的事務引擎205內(nèi)。因為(除了在事務引擎205與其它組件之間的SSL通信要求的那些之外)不需要認證或其它密碼操作來執(zhí)行信任仲裁，所以可以在認證引擎215外執(zhí)行該過程。但是，如以下將討論的，認證數(shù)據(jù)或其它密碼或認證事件的任何重新評估都將要求事務引擎205將適當?shù)臄?shù)據(jù)重新提交給認證引擎215。本領域技術人員將認識到，信任仲裁過程能夠可選地被構建成部分或全部地在認證引擎215自身當中發(fā)生。
[0256]如上所述，信任仲裁是一種在適當?shù)臅r候嘗試保護肯定認證中信任引擎110在賣方和用戶之間對協(xié)商進行調(diào)解的過程。如步驟1805所示，事務引擎205首先確定當前的狀況是否適于信任仲裁。這可以基于認證的情形，例如，該認證是否已經(jīng)通過多輪仲裁，以及基于賣方或用戶的偏好，進行確定，如以下將進一步討論的。
[0257]在仲裁不可行這種情形下，過程前進到步驟1810，在步驟1810中事務引擎205產(chǎn)生否定認證并且隨后將它插到在步驟1055(參見圖10)中發(fā)送給賣方的認證結果中。可以有利地用于防止認證無限期等待的一個限制是從最初的認證請求開始設置超時時間段。以這種方式，在該時限內(nèi)未被肯定認證的任何事務都被拒絕進一步仲裁并被否定認證。本領域技術人員將認識到，這種時限可以依據(jù)事務的情形以及用戶和賣方的期望而變化。還可以對提供成功的認證時做出嘗試的次數(shù)進行限制。這種限制可以由嘗試限制器535操縱，如圖5所示。
[0258]如果在步驟1805中未禁止仲裁，事務引擎205接著將參與到與事務方之一或二者的協(xié)商中。事務引擎205可以向用戶發(fā)送請求某些形式的附加認證的消息，以便提高如步驟1820所示產(chǎn)生的認證置信級別。以最簡單的形式，這可以簡單地指出認證是不充分的。還可以發(fā)送產(chǎn)生一個或多個附加認證實例的請求，以提高認證的總體置信級別。
[0259]如果用戶在步驟1825中提供一些附加的認證實例，則事務引擎205將這些認證實例添加到用于事務的認證數(shù)據(jù)中并將它轉(zhuǎn)發(fā)到認證引擎215，如步驟1015所示(參見圖10)，并且基于為這個事務預存的認證實例和新提供的認證實例兩者重新評估認證。
[0260]附加類型的認證可以是來自信任引擎110的一個請求，用于例如通過電話呼叫在信任引擎110操作者(或被信任的伙伴)與用戶之間進行某種形式的人與人的接觸。這種電話呼叫或其它非計算機認證可以用于提供與個人的私人接觸，并且還用于進行基于認證的某種形式的問卷。當用戶呼入時，這還可以給出驗證來源電話號碼和對用戶的可能的語音分析的機會。即使不能提供附加的認證數(shù)據(jù)，與用戶的電話號碼相關的附加背景也可以提高認證背景的可靠性?；谶@種電話號碼的任何已修改的數(shù)據(jù)或情形都被饋送至信任引擎110中，以便在考慮認證請求時使用。
[0261]此外，在步驟1820中，信任引擎110可以向用戶提供購買保險的機會，從而有效地購買更多的可信認證。有時候，如果認證的置信級別高于起初的某個閥值，信任引擎110的操作者可能只想讓這種選項可用。實際上，這種用戶端的保險是一種在認證滿足信任引擎110對認證的正常要求的信任級別但不滿足賣方對這個事務要求的信任級別時信任引擎110為用戶做擔保的方式。以這種方式，即使用戶只具有產(chǎn)生對信任引擎110而言足夠的信心的認證實例，他也仍舊可以成功地認證到如賣方可能要求的非常高的級別。
[0262]信任引擎110的這個功能使信任引擎110能夠擔保被認證為信任引擎110滿意但是賣方不滿意的某個人。這類似于公證員在給文檔添加他的簽名以便向以后閱讀該文檔的某人指出其簽名出現(xiàn)在文檔上的人員事實上就是簽署文檔的人員的過程中執(zhí)行的功能。公證員的簽名證明了被用戶簽署的行為。按照同樣的方式，信任引擎提供正在進行事務的人員就是他們說他們就是的那個人的指示。
[0263]但是，因為信任引擎110人為地提高用戶提供的置信級別，所以對于信任引擎110操作者而言存在較大的風險，因為用戶事實上不滿足賣方要求的信任級別。將保險的成本設計成對信任引擎110(其可以是對用戶的認證進行有效公正的信任引擎110)彌補錯誤的肯定認證的風險。用戶向信任引擎110操作者付費，承擔認證到比已經(jīng)實際提供的置信級別更高的級別的風險。
[0264]因為這種保險系統(tǒng)允許某人從信任引擎110有效地購買更高的置信率，所以賣方和用戶可能都希望在某些事務中防止用戶端保險的使用。賣方可能希望將肯定認證限制到他們知道實際的認證數(shù)據(jù)支持他們要求的置信度這種情形，因此可以向信任引擎110指出不允許用戶端保險。類似地，為了保護他的在線身份，用戶可能希望避免在他的賬戶上使用用戶端保險，或者可能希望將其使用限制到無保險的認證置信級別高于某個限制的情形。這可以被用作一種安全措施，以防某人偶然聽到密碼或偷了智能卡并使用它們錯誤地認證到低置信級別，然后購買保險來產(chǎn)生非常高的(錯誤)置信級別。在確定用戶端保險是否被允許的過程中可以評估這些因素。
[0265]如果用戶在步驟1840中購買了保險，就在步驟1845中基于購買的保險調(diào)整認證置信級別，并且在步驟1730(參見圖17)中對認證置信級別與要求的信任級別再次進行比較。過程從那里繼續(xù)，并且可以在步驟1740(參見圖17)中導致肯定認證，或者回到步驟1750中的信任仲裁過程中以便進一步仲裁(如果允許)，或者如果進一步的仲裁被禁止的話就是步驟1810中的否定認證。
[0266]除了在步驟1820中將消息發(fā)送給用戶之外，事務引擎205還可以在步驟1830中將消息發(fā)送給賣方，所述消息指出未決的認證當前處于要求的信任級別之下。該消息還可以提供關于怎樣去往賣方的不同選項。這些選項之一是簡單地告知賣方當前的認證置信級別是什么并且詢問賣方是否希望維持他們當前尚不滿足要求的信任級別。這可能是有利的，因為，在某些情況下，賣方可能具有對于認證事務而言獨立的手段或者可能曾經(jīng)使用了缺省設置的要求，該默認設置的要求一般會導致最初規(guī)定比對手頭特定事務實際上需要的級別更高要求的級別。
[0267]例如，期望所有進入的與賣方的訂購單事務都滿足98%信任級別可以是標準慣例。但是，如果一個訂單最近通過電話在賣方與長期消費者之間被討論過，并且事務在其后被立即認證，但是只有93%置信級別，則賣方可能希望簡單地降低用于該事務的認可閥值，因為電話呼叫給賣方有效地提供了附加認證。在某些情況下，賣方可能愿意降低他們要求的信任級別，并非總是當前的認證置信級別。例如，上述示例中的賣方可以認為訂購之前的電話呼叫可以獲得在所需信任度方面4%的較少；但是，這仍舊比用戶產(chǎn)生的93%的信心大。
[0268]如果賣方在步驟1835中不調(diào)整他們要求的信任級別，就在步驟1730(參見圖17)中對認證產(chǎn)生的認證置信級別與要求的信任級別進行比較。如果現(xiàn)在置信級別超過了要求的信任級別，就可以在步驟1740(參見圖17)中在事務引擎205中產(chǎn)生肯定認證。如果沒有，就可以如上所述嘗試進一步的仲裁，如果這種仲裁被允許的話。
[0269]除了請求調(diào)整要求的信任級別之外，事務引擎205還可以給請求認證的賣方提供賣方端保險。這種保險充當與上述用于用戶端的保險類似的目的。但是，在這里，保險的成本對應于賣方在認證中接受較低信任級別的過程中承擔的風險的成本，而不是對應于信任引擎110在高于所產(chǎn)生的實際認證置信級別的認證中所承擔風險的成本。
[0270]賣方具有購買保險的選項以保護它自己避免與用戶認證過程中的較低信任級別相關的附加風險，而不是只降低他們實際要求的信任級別。如上所述，對于只考慮購買這種保險以克服在現(xiàn)有認證已經(jīng)超過某閥值的條件下的信任差距的賣方而言，這可能是有利的。
[0271]這種賣方側保險的可用性允許賣方有下列選項:在對他自己無附加成本時將他的信任要求直接降低，承擔錯誤認證他自己的風險(基于要求的較低信任級別)；或者，購買用于認證置信級別與他的要求之間的信任差距的保險，由信任引擎110操作者承擔已經(jīng)提供的較低置信級別的風險。通過購買保險，賣方有效保持他的高信任級別要求；因為錯誤認證的風險被轉(zhuǎn)移給信任引擎110操作者了。
[0272]如果賣方在步驟1840中購買了保險，就在步驟1730 (參見圖17)中對認證置信級別與要求的信任級別進行比較，并且過程如上所述繼續(xù)。
[0273]應當注意，還有可能用戶和賣方雙方都響應于來自信任引擎110的消息。本領域技術人員將認識到，存在能夠操縱這種狀況的多種方式。操縱可能的多個響應的一種有利模式是簡單地按照先來先服務的方式處置響應。例如，如果賣方以降低要求的信任級別響應，并且用戶也緊隨其后購買了保險來升高他的認證級別，那么，基于來自賣方的被降低的信任要求首先重新評估認證。如果現(xiàn)在認證是肯定的，則用戶的保險購買被忽略。在另一種有利的操作模式中，用戶可以只對滿足賣方新的、被降低的信任要求所要求的保險級別進行充值(如果即使賣方信任要求已降低但仍然有信任差距)。
[0274]如果在為認證設置的時間限制內(nèi)在步驟1850的信任仲裁過程期間沒有接收到來自任一方的響應，就在步驟1805中對仲裁進行重新評估。這會有效地再次開始仲裁過程。如果在步驟1805中時限是決定性的或者其它情形阻止進一步的仲裁，就在步驟1810中由事務引擎205產(chǎn)生否定認證并且在步驟1055(參見圖10)中返回給賣方。如果不是，新消息就可以發(fā)送到用戶和賣方，并且過程可以按需重復。
[0275]應當注意，對于某些類型的事務，例如，不屬于事務一部分的數(shù)字簽署文檔，可能不必有一個賣方或其他第三方；因此事務首先是在用戶與信任引擎110之間。在例如這些的情形下，信任引擎110將具有它自己要求的信任級別，為了產(chǎn)生肯定的認證，該信任級別必須被滿足。但是，在這種情形下，將經(jīng)常不期望信任引擎110給用戶提供保險以便于他升高對他自己擁有的簽名的信任。
[0276]可以使用如上參考信任引擎110所述的各種通信模式執(zhí)行以上所述并在圖16-圖18中示出的過程。例如，消息可以是基于網(wǎng)絡的并使用信任引擎110與小程序之間的SSL連接發(fā)送，其中該小程序被實時下載到運行在用戶或賣方系統(tǒng)上的瀏覽器中。在一種可選的操作模式中，某些專用的應用程序可以被推動這種仲裁和保險事務的用戶和賣方使用。在另一種可選的操作模式中，安全電子郵件操作可以用于調(diào)解上述仲裁，由此允許認證的延期評估和成批處理。本領域技術人員將認識到，可以使用適于賣方的情形和認證要求的不同通信模式。
[0277]以下參考圖19的描寫描述了融入如上所述本發(fā)明各方面的樣本事務。這個例子說明了由信任引擎110調(diào)解的用戶與賣方之間的整個過程。盡管如上具體描述過的各個步驟和組件可以用于執(zhí)行下面的事務，但是所說明的過程集中在信任引擎110、用戶與賣方之間的交互。
[0278]在步驟1900中當用戶正在在線查看網(wǎng)頁、在賣方的網(wǎng)站上填寫訂貨單時，事務開始。用戶希望將用他的數(shù)字簽名簽署的這個訂貨單提交給賣方。為此，用戶利用他在步驟1905中向信任引擎110對簽名的請求來提交訂貨單。用戶還將提供將被如上所述用于認證他的身份的認證數(shù)據(jù)。
[0279]在步驟1910中，如以上所討論的，由信任引擎110將認證數(shù)據(jù)與注冊數(shù)據(jù)進行比較，并且，如果產(chǎn)生肯定的認證，就把用用戶的私鑰簽署的訂貨單的哈希連同訂貨單自身一起轉(zhuǎn)發(fā)到賣方。
[0280]賣方在步驟1915中接收到被簽署的訂貨單，然后賣方將在步驟1920中產(chǎn)生與待做出的購買有關的發(fā)票或其它合同。在步驟1925中，這個帶有對簽名的請求的合同被發(fā)回到用戶。在步驟1930中，賣方還將對這個合同事務的認證請求發(fā)送給信任引擎110，包括將由雙方簽署的合同的哈希。為了允許雙方數(shù)字簽署合同，賣方還包括用于自身的認證數(shù)據(jù)，使得賣方對合同的簽名能夠在以后需要時被驗證。
[0281]如以上所討論的，信任引擎110接著驗證賣方提供的認證數(shù)據(jù)以確認賣方的身份，并且，如果在步驟1935中數(shù)據(jù)產(chǎn)生了肯定的認證，就在接收到來自用戶的數(shù)據(jù)時以步驟1955繼續(xù)。如果賣方的認證數(shù)據(jù)不能與賣方的注冊數(shù)據(jù)匹配到期望的程度，則一個消息被返回到賣方，請求進一步認證。為了賣方向信任引擎110成功地認證它自己，如果需要，可以在這里執(zhí)行信任仲裁，如上所述。
[0282]在步驟1940中，當用戶接收到合同時，他重新查看它，如果它在步驟1945中是可接受的，就產(chǎn)生認證數(shù)據(jù)來簽署它，然后在步驟1950中將合同的哈希及他的認證數(shù)據(jù)發(fā)送給信任引擎110。在步驟1955中，信任引擎110驗證認證數(shù)據(jù)，并且，如果認證良好，就前去處理合同，如下所述。如以上參考圖17和18所討論的，在適當?shù)臅r候可以執(zhí)行信任仲裁，以關閉存在于認證置信級別與事務所要求的認證級別之間的任何信任差距。
[0283]信任引擎110用用戶的私鑰簽署合同的哈希，并且在步驟1960中將這個簽署的哈希發(fā)送給賣方，代表它自己的利益簽署完整的消息，即，包括用信任引擎Iio的私鑰510加密的完整消息的哈希(包括用戶的簽名)。在步驟1965中，這個消息被賣方接收。該消息代表被簽署的合同(使用用戶的私鑰加密的合同的哈希)和來自信任引擎110的發(fā)票(消息的哈希包括使用信任引擎110的私鑰加密的被簽署的合同)。[0284]在步驟1970中，信任引擎110類似地用賣方的私鑰準備合同的哈希，并將這個轉(zhuǎn)發(fā)到用戶，由信任引擎110簽署合同。以這種方式，用戶也接收由賣方簽署的合同的副本以及由信任引擎Iio簽署的發(fā)票，以便在步驟1975中交付簽署的合同。
[0285]除了以上所述之外，本發(fā)明的另一方面提供一種密碼服務提供商模塊(SPM)，該模塊可以讓客戶端應用程序用作一種獲取由上述信任引擎110提供的功能的手段。對于密碼SPM而言，提供這種服務的一種有利方式是調(diào)解第三方應用編程接口(API)與信任引擎110之間的通信，其中經(jīng)網(wǎng)絡或其它遠程連接可訪問信任引擎110。下面參考圖20描述樣本密碼 SPM。
[0286]例如，在一種典型的系統(tǒng)上，許多API可以讓編程者獲得。每個API都提供一組可以由運行在系統(tǒng)上的應用程序2000進行的函數(shù)調(diào)用。提供適于密碼功能、認證功能和其他安全功能的編程接口的API的例子包括MICROSOFT用它的WINDOWS操作系統(tǒng)提供的密碼API (CAPI) 2010，及由IBM、INTEL和Open Group的其它成員發(fā)起的通用數(shù)據(jù)安全架構(CDSA)。在下面的討論中，CAPI將被用作示例性安全性API。但是，所描述的密碼SPM能夠用于CDSA或現(xiàn)有技術中已知的其它安全性API。
[0287]當為了密碼功能而進行呼叫時，這個API被用戶系統(tǒng)105或賣方系統(tǒng)120使用。包括在這些功能當中的可以是與執(zhí)行各種密碼操作相關的請求，這些密碼操作例如:用特定的密鑰加密文檔、簽署文檔、請求數(shù)字證書、對簽署的文檔上的簽名進行驗證，及在此所描述的或者本領域技術人員已知的此類其它密碼功能。
[0288]這種密碼功能通常在CAPI2010所位于的系統(tǒng)上被本地執(zhí)行。這是因為通常被調(diào)用的函數(shù)要求使用例如指紋閱讀器的本地用戶系統(tǒng)105的資源，或者使用在本地機器上執(zhí)行的庫編程的軟件函數(shù)。對這些本地資源的訪問通常是由以上提到的一個或多個服務提供商模塊(SPM)2015、2020提供的，這些模塊提供執(zhí)行密碼功能所用的資源。這種SPM可以包括用于執(zhí)行加密或解密操作的軟件庫2015，或者能夠訪問例如生物測定掃描設備的專用硬件2025的驅(qū)動器和應用程序2020。在CAPI 2010提供可被系統(tǒng)105的應用程序2000使用的函數(shù)的許多方式中，SPM 2015,2020向CAPI提供對較低級別函數(shù)和與系統(tǒng)上可用的服務相關的資源的訪問。
[0289]根據(jù)本發(fā)明，有可能提供一種能夠獲取由信任引擎110提供的密碼功能并且使這些功能通過CAPI 2010提供給應用程序2000的密碼SPM 2030。與CAPI 2010僅能訪問通過SPM 2015、2020本地提供的資源的實施例不同，本文所述的密碼SPM 2030將能夠把對密碼操作的請求提交給遠程定位的、網(wǎng)絡可訪問的信任引擎110，以便執(zhí)行期望的操作。
[0290]例如，如果應用程序2000具有對例如簽署文檔的密碼操作的需要，應用程序2000就對適當?shù)腃API 2010函數(shù)進行函數(shù)調(diào)用。CAPI2010隨后將執(zhí)行這個函數(shù)，使用通過SPM2015、2020和密碼SPM2030提供給它的資源。在數(shù)字簽名功能的情況下，密碼SPM 2030將產(chǎn)生適當?shù)恼埱?，該請求將通過通信鏈路125發(fā)送到信任引擎110。
[0291]在密碼SPM 2030和信任引擎110之間發(fā)生的操作是相同的操作，該操作在任何其它系統(tǒng)與信任引擎110之間都是可能的。但是，這些功能是通過CAPI 2010有效地提供給用戶系統(tǒng)105的，使得它們看起來就像是在用戶系統(tǒng)105上自身本地可用的。但是，與普通的SPM 2015,2020不同，該功能是響應跨信鏈路125的適當?shù)恼埱蠖谶h程信任引擎110上執(zhí)行的并且結果被中繼到密碼SPM 2030。[0292]這個密碼SP M2030進行用戶系統(tǒng)105和賣方系統(tǒng)120可用的許多操作，在其它情形下，這些操作可能不可用。這些功能包括但不限于:文檔的加密和解密；數(shù)字證書的發(fā)布；文檔的數(shù)字簽署；數(shù)字簽名的驗證；及對本領域技術人員而言將顯而易見的此類其它操作。
[0293]在一種獨立的實施例中，本發(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ù)解析器，包括跨平臺軟件模塊套件，該套件集成在電子基礎設施內(nèi)，或者作為插件集成到要求其數(shù)據(jù)元素最終安全的任何應用程序中。這個解析過程對任何類型的數(shù)據(jù)集并且對任何和所有的文件類型、或者在數(shù)據(jù)庫中對該數(shù)據(jù)庫中的任何行、列或單元數(shù)據(jù)進行操作。
[0294]在一種實施例中，本發(fā)明的解析過程可以模塊式層疊方式設計，并且任何加密過程都適于在本發(fā)明的過程中使用。本發(fā)明的解析和分割過程的模塊式層疊可以包括但不限于:1)密碼分割、分散并安全地存儲在多個位置中；2)加密、密碼分割、分散并安全地存儲在多個位置中；3)加密、密碼分割、對每份加密、然后分散并安全地存儲在多個位置中；及
4)加密、密碼分割、用不同于在第一步中使用的加密類型對每份加密，然后分散并安全地存儲在多個位置中。
[0295]在一種實施例中，該過程包闊根據(jù)所產(chǎn)生隨機數(shù)或密鑰的內(nèi)容分割數(shù)據(jù)，并對在分割數(shù)據(jù)的加密過程中使用的密鑰執(zhí)行相同的密碼分割，所述數(shù)據(jù)是要被保護成解析和分割后的數(shù)據(jù)的兩個或更多個部分，或者說份，而且，在一種實施例中，優(yōu)選被保護成解析和分割后的數(shù)據(jù)的四個或更多部分，對所有部分進行加密，然后將這些部分散開并存回數(shù)據(jù)庫中，或者依賴請求者對隱私和安全的需要將它們重新定位到任何固定或移動的指定設備中?？蛇x地，在另一種實施例中，加密可以在通過分割模塊或安全數(shù)據(jù)解析器分割數(shù)據(jù)集之前發(fā)生。如在這種實施例中所描述的那樣，被處理的原始數(shù)據(jù)被加密并混亂(obfuscate)，從而得到保護。如果期望的話，被加密元素的分散幾乎可以在任何地方，包括但不限于單個服務器或數(shù)據(jù)儲存設備，或在獨立的數(shù)據(jù)儲存設施或設備之間。在一種實施例中，加密密鑰管理可以包括在軟件套件內(nèi)，或者，在另一種實施例中，可以集成在現(xiàn)有基礎設施或任何其它期望的位置中。
[0296]密碼分割(cryptosplit)將數(shù)據(jù)分成N份。這種分塊可以針對任何大小的數(shù)據(jù)單元，包括各個位、多位、多字節(jié)、千字節(jié)、兆字節(jié)、或更大的單元，以及不管是預定還是隨機產(chǎn)生的數(shù)據(jù)單元大小的任何模式或組合?；陔S機或預訂的值集，單元還可以具有不同大小。這意味著數(shù)據(jù)可以被視為一系列這些單元。以這種方式，數(shù)據(jù)單元自身的大小可以例如通過使用一個或多個預訂或隨機產(chǎn)生的模式、序列或數(shù)據(jù)單元大小的組合使數(shù)據(jù)更安全。然后這些單元被分配成N份(隨機地或通過預訂的值集)。這種分配還涉及份內(nèi)單元次序的洗牌。對本領域普通技術人員來說很顯然的是，可以根據(jù)多種可能的選擇，包括但不限于固定大小、預定大小或一個或多個組合、預訂或隨機產(chǎn)生的數(shù)據(jù)單元大小的模式或序列，來執(zhí)行將數(shù)據(jù)單元分配成多份。[0297]在這個密碼分割過程的一些實施例中，數(shù)據(jù)的大小可以是任何合適的字節(jié)數(shù)，例如一、兩、三、五、二十、五十、一百、多于一百或者N字節(jié)大小。這種密碼分割過程或者說cryptosplit的一個特定例子將是考慮數(shù)據(jù)是23字節(jié)大小，數(shù)據(jù)單元大小選擇成一個字節(jié)，并且份數(shù)選擇成4。每個字節(jié)都將被分配到4份當中的一份。假設一種隨機分配，將獲得密鑰來產(chǎn)生一系列23個隨機數(shù)(rl，r2，r3至r23)，每個數(shù)都具有對應于四份的I和4之間的值。每個數(shù)據(jù)單元(在這個例子中是數(shù)據(jù)的各字節(jié))都與對應于四份之一的23個隨機數(shù)之一相關。通過將數(shù)據(jù)的第一字節(jié)放入份rl中，字節(jié)2放入份r2中，字節(jié)三放入份r3中，直至數(shù)據(jù)的第23字節(jié)放入份r23中，將發(fā)生把數(shù)據(jù)的字節(jié)分配到四份中。對本領域普通技術人員來說很顯然，很多種其它可能的步驟或一系列步驟的組合，包括數(shù)據(jù)單元的大小，都可以在本發(fā)明的密碼分割過程中使用，并且上述例子是對密碼分割數(shù)據(jù)的一個過程的非限制性描述。為了重建原始數(shù)據(jù)，將執(zhí)行倒過來的操作。
[0298]在本發(fā)明的密碼分割過程的另一種實施例中，對密碼分割過程的一個選項是在多份中提供足夠的冗余，使得只需要多份的一個子集就可以將數(shù)據(jù)重組或恢復成其原始或可用的形式。作為一個非限制性例子，密碼分割可以作為“4分之3”密碼分割來進行，使得只有4份中的三份必須用來將數(shù)據(jù)重組或恢復到其原始或可用的形式。這也被稱為“N分之M密碼分割”，其中N是總份數(shù)，而M至少比N小一。對本領域普通技術人員來說很顯然，在本發(fā)明的密碼分割過程中存在用于產(chǎn)生這種冗余性的許多可能性。
[0299]在本發(fā)明的密碼分割過程的一種實施例中，每個數(shù)據(jù)單元被存儲在兩份，主要份和備份份，當中。使用上述“4分之3”密碼分割過程，任何一份都可以丟失，而這足以在沒有丟失的數(shù)據(jù)單元的的情況下重組或恢復原始數(shù)據(jù)，因為只要求總共四份當中的三份。如本文所描述的，生成對應于多份之一的隨機數(shù)。隨機數(shù)與數(shù)據(jù)單元相關，并基于密鑰存儲在對應的份中。在這種實施例中，使用一個密鑰來產(chǎn)生主要和備份份隨機數(shù)。如本文中對本發(fā)明的密碼分割過程所描述的，生成等于數(shù)據(jù)單元數(shù)量的、從O到3的一個隨機數(shù)集(也被稱為主要份數(shù))。然后，生成等于數(shù)據(jù)單元數(shù)量的、從I到3的另一個隨機數(shù)集(也被稱為備份份數(shù))。然后，使每個數(shù)據(jù)單元都與一個主要份數(shù)和一個備份份數(shù)關聯(lián)?？蛇x地，可以生成少于數(shù)據(jù)單元數(shù)量的一個隨機數(shù)集，并且可以重復該隨機數(shù)集，但是這可能降低敏感數(shù)據(jù)的安全性。主要份數(shù)用于確定數(shù)據(jù)單元被存儲到哪份中。備份份數(shù)與主要份數(shù)結合，產(chǎn)生O和3之間的第三份數(shù)，并且這個數(shù)字用于確定數(shù)據(jù)單元被存儲到哪份中。在這個例子中，用于確定第三份數(shù)的方程為:
[0300](主要份數(shù)+備份份數(shù))M0D4=第三份數(shù)
[0301]在主要份數(shù)在O和3之間并且備份份數(shù)在I和3之間的上述實施例中，要確保第三份數(shù)不同于主要份數(shù)。這導致數(shù)據(jù)單元被存儲在兩個不同的份中。對本領域普通技術人員來說很顯然，除了本文公開的實施例之外，還存在執(zhí)行冗余密碼分割和非冗余密碼分割的許多方式。例如，每份中的數(shù)據(jù)單元都可以利用不同的算法洗牌。當原始數(shù)據(jù)被分割成多個數(shù)據(jù)單元時，或者在數(shù)據(jù)單元被放入份中之后，或者在份滿了之后，可以執(zhí)行這種數(shù)據(jù)單元洗牌。
[0302]可以對任何大小的數(shù)據(jù)單元，包括但不限于:小到一個個別位、多位、多字節(jié)、兆字節(jié)或更大，執(zhí)行本文描述的各種密碼分割過程和數(shù)據(jù)洗牌過程，及本發(fā)明的密碼分割和數(shù)據(jù)洗牌方法的所有其它實施例。[0303]將執(zhí)行本文所述密碼分割過程的源代碼的一種實施例的例子是:
[0304]
【權利要求】
1.一種用于將客戶端計算設備引導至存儲在多個存儲位置上的數(shù)據(jù)部分的方法，該方法的步驟由編程的計算機系統(tǒng)實現(xiàn)，該方法包括: 在服務器處從客戶端計算設備接收對于識別多個物理上分離的存儲位置的請求，所述多個物理上分離的存儲位置中的每一個存儲由所述請求標識的數(shù)據(jù)集的一部分，其中所述數(shù)據(jù)集能夠從所述數(shù)據(jù)集的預定數(shù)目的部分恢復，所述數(shù)據(jù)集的預定數(shù)目的部分是所述數(shù)據(jù)集的至少兩個部分并且少于所述數(shù)據(jù)集的所有部分； 利用所述服務器基于一個或多個標準從所述多個存儲位置中的可用存儲位置中選擇至少所述預定數(shù)目的存儲位置，其中所選位置中的每一個存儲所述數(shù)據(jù)集的一部分，并且所選的存儲位置包括比所述多個存儲位置的全部更少的存儲位置；以及從所述服務器向所述客戶端計算設備發(fā)送標識所選存儲位置的數(shù)據(jù)。
2.如權利要求1所述的方法，還包括: 在接收對于識別多個物理上分離的存儲位置的請求之前: 從與所述客戶端計算設備不同的計算設備接收所述數(shù)據(jù)集的多個部分，以及 將所述數(shù)據(jù)的多個部分存儲在所述多個物理上分離的存儲位置之中。
3.如權利要求1所述的方法，其中所述標準包括地理位置，所述方法還包括確定所述多個存儲位置中的至少一個的地理位置。
4.如權利要求1所述的方法，其中所述標準包括負荷，所述方法還包括確定所述多個存儲位置中的至少一個上的負荷，所述負荷包括存儲負荷和處理負荷中的至少一者。
5.如權利要求1所述的方法，其中對存儲位置的選擇基于與企業(yè)、產(chǎn)品、客戶端、用戶或請求相關聯(lián)的至少一個規(guī)則。
6.如權利要求1所述的方法，其中所述數(shù)據(jù)集的每個部分都包括頭部和與該頭部相關聯(lián)的多個數(shù)據(jù)塊。
7.如權利要求6所述的方法，其中所述數(shù)據(jù)集的每個部分的頭部通過指派給所述頭部和每個所述數(shù)據(jù)塊的分部作業(yè)標識符來與所述多個數(shù)據(jù)塊相關聯(lián)。
8.如權利要求6所述的方法，還包括從所述多個存儲位置中的至少一個訪問所述頭部。
9.如權利要求8所述的方法，所述方法還包括: 從所述客戶端計算設備接收對于修改經(jīng)加密的數(shù)據(jù)集的一部分的頭部的請求；以及 修改所述經(jīng)加密的數(shù)據(jù)集的該部分的頭部。
10.如權利要求8所述的方法，所述方法還包括: 從存儲網(wǎng)絡的用戶接收對于利用新密鑰對數(shù)據(jù)集的一部分的頭部中的數(shù)據(jù)進行密鑰更新的請求； 對所述數(shù)據(jù)集的該部分的頭部中的數(shù)據(jù)進行拆包；以及 利用所述新密鑰來重新包裹所述數(shù)據(jù)集的該部分的頭部中的數(shù)據(jù)。
11.如權利要求8所述的方法，所述方法還包括基于至少一個頭部來驗證與該頭部相關聯(lián)的數(shù)據(jù)塊能夠用于恢復所述數(shù)據(jù)集。
12.如權利要求1所述的方法，所述方法還包括: 確定在第一存儲位置處所述數(shù)據(jù)集的一部分對于所述客戶端計算設備是不可訪問的；以及從至少所述預定數(shù)目的可用部分恢復所述數(shù)據(jù)集的該部分到所述第一存儲位置。
13.如權利要求1所述的方法，其中所述至少一個存儲位置包括云計算存儲位置。
14.一種用于將客戶端計算設備引導至存儲在多個存儲位置上的數(shù)據(jù)部分的方法的計算機系統(tǒng)，包括: 至少一個處理器；以及 存儲計算機可執(zhí)行指令的非暫態(tài)計算機可讀介質(zhì)，所述指令當被所述至少一個處理器執(zhí)行時使得所述計算機系統(tǒng)執(zhí)行以下步驟: 從客戶端計算設備接收對于識別多個物理上分離的存儲位置的請求，所述多個物理上分離的存儲位置中的每一個存儲由所述請求標識的數(shù)據(jù)集的一部分，其中所述數(shù)據(jù)集能夠從所述數(shù)據(jù)集的預定數(shù)目的部分恢復，所述數(shù)據(jù)集的預定數(shù)目的部分是所述數(shù)據(jù)集的至少兩個部分并且少于所述數(shù)據(jù)集的所有部分； 基于一個或多個標準從所述多個存儲位置中的可用存儲位置中選擇至少所述預定數(shù)目的存儲位置，其中所選位置中的每一個存儲所述數(shù)據(jù)集的一部分，并且所選的存儲位置包括比所述多個存 儲位置的全部更少的存儲位置；以及向所述客戶端計算設備發(fā)送標識所選存儲位置的數(shù)據(jù)。
15.如權利要求14所述的系統(tǒng)，其中由所述計算機系統(tǒng)執(zhí)行的所述方法還包括: 在接收對于識別多個物理上分離的存儲位置的請求之前: 從與所述客戶端計算設備不同的計算設備接收所述數(shù)據(jù)集的多個部分，以及 將所述數(shù)據(jù)的多個部分存儲在所述多個物理上分離的存儲位置之中。
16.如權利要求14所述的系統(tǒng)，其中所述標準包括地理位置，并且其中由所述計算機系統(tǒng)執(zhí)行的所述方法還包括確定所述多個存儲位置中的至少一個的地理位置。
17.如權利要求14所述的系統(tǒng)，其中所述標準包括負荷，其中由所述計算機系統(tǒng)執(zhí)行的所述方法還包括確定所述多個存儲位置中的至少一個上的負荷，所述負荷包括存儲負荷和處理負荷中的至少一者。
18.如權利要求14所述的系統(tǒng)，其中對存儲位置的選擇基于與企業(yè)、產(chǎn)品、客戶端、用戶或請求相關聯(lián)的至少一個規(guī)則。
19.如權利要求14所述的系統(tǒng)，其中所述數(shù)據(jù)集的每個部分都包括頭部和與該頭部相關聯(lián)的多個數(shù)據(jù)塊。
20.如權利要求19所述的系統(tǒng)，其中所述數(shù)據(jù)集的每個部分的頭部通過指派給所述頭部和每個所述數(shù)據(jù)塊的分部作業(yè)標識符來與所述多個數(shù)據(jù)塊相關聯(lián)。
21.如權利要求19所述的系統(tǒng)，其中由所述計算機系統(tǒng)執(zhí)行的所述方法還包括從所述多個存儲位置中的至少一個訪問所述頭部。
22.如權利要求21所述的系統(tǒng)，其中由所述計算機系統(tǒng)執(zhí)行的所述方法還包括: 從所述客戶端計算設備接收對于修改經(jīng)加密的數(shù)據(jù)集的一部分的頭部的請求；以及 修改所述經(jīng)加密的數(shù)據(jù)集的該部分的頭部。
23.如權利要求21所述的系統(tǒng)，其中由所述計算機系統(tǒng)執(zhí)行的所述方法還包括: 從存儲網(wǎng)絡的用戶接收對于利用新密鑰對數(shù)據(jù)集的一部分的頭部中的數(shù)據(jù)進行密鑰更新的請求； 對所述數(shù)據(jù)集的該部分的頭部中的數(shù)據(jù)進行拆包；以及利用所述新密鑰來重新包裹所述數(shù)據(jù)集的該部分的頭部中的數(shù)據(jù)。
24.如權利要求21所述的系統(tǒng)，其中由所述計算機系統(tǒng)執(zhí)行的所述方法還包括基于至少一個頭部來驗證與該頭部相關聯(lián)的數(shù)據(jù)塊能夠用于恢復所述數(shù)據(jù)集。
25.如權利要求14所述的系統(tǒng)，其中由所述計算機系統(tǒng)執(zhí)行的所述方法還包括: 確定在第一存儲位置處所述數(shù)據(jù)集的一部分對于所述客戶端計算設備是不可訪問的；以及 從至少所述預定數(shù)目的可用部分恢復所述數(shù)據(jù)集的該部分到所述第一存儲位置。
26.如權利要求14所述的系統(tǒng)，其中所述至少一個存儲位置包括云計算存儲位置。
27.一種存儲計算機可執(zhí)行指令的非暫態(tài)計算機可讀介質(zhì)，所述指令當被至少一個處理器執(zhí)行時使得計算機系統(tǒng)執(zhí)行用于將客戶端計算設備引導至存儲在多個存儲位置上的數(shù)據(jù)部分的方法，該方法包括以下步驟: 從客戶端計算設備接收對于識別多個物理上分離的存儲位置的請求，所述多個物理上分離的存儲位置中的每一個存儲由所述請求標識的數(shù)據(jù)集的一部分，其中所述數(shù)據(jù)集能夠從所述數(shù)據(jù)集的預定數(shù)目的部分恢復，所述數(shù)據(jù)集的預定數(shù)目的部分是所述數(shù)據(jù)集的至少兩個部分并且少于所述數(shù)據(jù)集的所有部分； 基于一個或多個標準從所述多個存儲位置中的可用存儲位置中選擇至少所述預定數(shù)目的存儲位置，其中所選位置中的每一個存儲所述數(shù)據(jù)集的一部分，并且所選的存儲位置包括比所述多個存儲位置的全部更少的存儲位置；以及向所述客戶端計算設備發(fā)送標識所選存儲位置的數(shù)據(jù)。
28.如權利要求27所述的非暫態(tài)計算機可讀介質(zhì)，其中所述方法還包括: 在接收對于識別多個物理上分離的存儲位置的請求之前: 從與所述客戶端計算設備不同的計算設備接收所述數(shù)據(jù)集的多個部分，以及 將所述數(shù)據(jù)的多個部分存儲在所述多個物理上分離的存儲位置之中。
29.如權利要求27所述的非暫態(tài)計算機可讀介質(zhì)，其中所述標準包括地理位置，并且其中所述方法還包括確定所述多個存儲位置中的至少一個的地理位置。
30.如權利要求27所述的非暫態(tài)計算機可讀介質(zhì)，其中所述標準包括負荷，其中所述方法還包括確定所述多個存儲位置中的至少一個上的負荷，所述負荷包括存儲負荷和處理負荷中的至少一者。
31.如權利要求27所述的非暫態(tài)計算機可讀介質(zhì)，其中對存儲位置的選擇基于與企業(yè)、產(chǎn)品、客戶端、用戶或請求相關聯(lián)的至少一個規(guī)則。
32.如權利要求27所述的非暫態(tài)計算機可讀介質(zhì)，其中所述數(shù)據(jù)集的每個部分都包括頭部和與該頭部相關聯(lián)的多個數(shù)據(jù)塊。
33.如權利要求32所述的非暫態(tài)計算機可讀介質(zhì)，其中所述數(shù)據(jù)集的每個部分的頭部通過指派給所述頭部和每個所述數(shù)據(jù)塊的分部作業(yè)標識符來與所述多個數(shù)據(jù)塊相關聯(lián)。
34.如權利要求32所述的非暫態(tài)計算機可讀介質(zhì)，其中所述方法還包括從所述多個存儲位置中的至少一個訪問所述頭部。
35.如權利要求34所述的非暫態(tài)計算機可讀介質(zhì)，其中所述方法還包括: 從所述客戶端計算設備接收對于修改經(jīng)加密的數(shù)據(jù)集的一部分的頭部的請求；以及 修改所述經(jīng)加密的數(shù)據(jù)集的該部分的頭部。
36.如權利要求34所述的非暫態(tài)計算機可讀介質(zhì)，其中所述方法還包括: 從存儲網(wǎng)絡的用戶接收對于利用新密鑰對數(shù)據(jù)集的一部分的頭部中的數(shù)據(jù)進行密鑰更新的請求； 對所述數(shù)據(jù)集的該部分的頭部中的數(shù)據(jù)進行拆包；以及 利用所述新密鑰來重新包裹所述數(shù)據(jù)集的該部分的頭部中的數(shù)據(jù)。
37.如權利要求34所述的非暫態(tài)計算機可讀介質(zhì)，其中所述方法還包括基于至少一個頭部來驗證與該頭部相關聯(lián)的數(shù)據(jù)塊能夠用于恢復所述數(shù)據(jù)集。
38.如權利要求27所述的非暫態(tài)計算機可讀介質(zhì)，其中所述方法還包括: 確定在第一存儲位置處所述數(shù)據(jù)集的一部分對于所述客戶端計算設備是不可訪問的；以及 從至少所述預定數(shù)目的可用部分恢復所述數(shù)據(jù)集的該部分到所述第一存儲位置。
39.如權利要求27所述的非暫態(tài)計算機可讀介質(zhì)，其中所述至少一個存儲位置包括云計算存儲位置。
【文檔編號】H04L29/08GK103959302SQ201280034840
【公開日】2014年7月30日 申請日期:2012年6月1日 優(yōu)先權日:2011年6月1日
【發(fā)明者】M·S·奧黑爾, D·馬丁, R·弗爾福德, R·L·奧爾西尼 申請人:安全第一公司