专利名称：用于管理加密密钥的系统和方法
技术领域：
本发明一般地涉及用于保护数据以免于未授权访问或使用的系统。更具体地，本发明涉及用于支持加密密钥的公共接口。
背景技术：
在当今社会，个人和企业在计算机系统上和通过计算机系统执行不断增加的活动量。这些计算机系统，包括专属的和非专属的计算机网络，通常存储、存档和传输各种类型的敏感信息。因此，存在不断增加的用于确保通过这些系统存储和传输的数据不被读取或泄露(compromise)的需求。用于保护计算机系统的一种通常解决方案是提供登录和口令功能。然而，口令管理已经被证明是花费非常大的，大量的求助台呼叫都与口令问题有关。此外，口令提供了很少的安全性，这是因为它们通常被存储在易受到通过例如暴力攻击而进行的不适当访问的文件中。用于保护计算机系统的另一方案是提供加密基础结构。密码术通常指的是通过将数据变换或加密成为不可读格式来保护数据。只有那些拥有加密密钥的人才能够将数据解密成可用格式。密码术被用来识别用户(例如认证)，以允许访问特权(例如授权)从而创建数字证书和签名等。一种普遍的密码术系统是使用两个密钥的公钥系统，公钥被每个人知道，而私钥仅被其个人或企业所有者知道。通常，使用一个密钥加密的数据用另一密钥解密，并且任一密钥都不可由另一密钥重建。遗憾的是，即使上述典型的公钥加密系统在安全上仍然高度依赖用户。例如，加密系统例如通过用户浏览器向用户发布私钥。没有经验的用户然后通常将该私钥存储在可被其他人通过开放的计算机系统(例如，因特网)访问的硬盘驱动器上。另一方面，用户可能为包含其私钥的文件选择较差的名字，例如，“密钥”。上述和其他动作的结果是使得密钥或多个密钥易被泄露。除了上述泄露，用户还可能将他或她的私钥保存在配置有存档或备份系统的计算机系统上，潜在地导致私钥的副本经过多个计算机存储装置或其他系统。这种安全漏洞通常被称作“密钥迁移(key migration)”。类似于密钥迁移，许多应用最多通过简单的登录和口令访问提供对用户的私钥的访问。如上所述，登录和口令访问往往无法提供充分的安全性。用于增加上述加密系统的安全性的一个解决方案是将生物识别(biometrics)包括作为认证或授权的一部分。生物识别通常包括可测量的身体特征，诸如能够由自动化系统通过例如图案匹配或者指纹图案或语音图案识别而检查的指纹或语音。在这样的系统中，用户的生物识别信息和/或密钥可以被存储在移动计算装置(例如，智能卡、膝上型电脑、个人数字助理、或移动电话)上，从而使得生物识别信息或密钥能够在移动环境下使用。上述的移动生物识别加密系统仍然遭受各种缺点。例如，移动用户可能丢失或损坏智能卡或便携式计算装置，从而使他或她对可能重要的数据的访问被完全切断。或者，恶意的人可能偷取移动用户的智能卡或便携式计算装置并使用它来有效地偷取移动用户的数字证书。另一方面，便携式计算装置可以连接到诸如因特网之类的开放系统，并且，类似于口令，存储生物识别信息的文件可能由于用户对于安全性的疏忽或恶意入侵者而易被泄露。此外，有许多方式来安全地创建、存储和管理个人加密密钥。例如，一些应用可以将用户的加密密钥存储在密钥存储器或其他数据结构中。在用户的密钥存储器中的加密密钥可以被多种应用访问。然而一些应用可能与其他应用不兼容，或可能损害用户的加密密钥的安全性，例如，将一个或多个密钥暴露至讹误或未授权或不安全的访问。
发明内容
因此，提供一种密码系统，其安全性是用户无关的，同时仍支持移动用户。此外，还提供了一种公共接口，例如应用程序接口(API )，其能够支持对多个加密密钥提供者的多个接口，并将从这些密钥提供者获取的加密密钥提交给安全解析器引擎(secure parser engine),该安全解析器引擎用于例如保护用于存储或传输的数据。这样的安全解析器引擎在Orsini等人的美国专利N0.7，391，865,2005年10月25日提交的美国专利申请N0.11/258,839以及2006年11月20日提交的美国专利申请N0.11/602,667中有更详细的描述，所有这些都通过引用全文结合于此。因此，本发明的一个方面是提供一种用于保护实际上任何类型的数据免于未授权访问或使用的方法。该方法包括将要保护的数据解析、拆分和/或分离成为两个或更多个部或部分的一个或多个步骤。该方法还包括加密要保护的数据。数据的加密可以在数据的第一次解析、拆分和/或分离之前或之后执行。此外，对于数据的一个或多个部分可以重复加密步骤。类似地，对于数据的一个或多个部分可以重复解析、拆分和/或分离步骤。该方法还可选地包括存储已经在一个位置或在多个位置处加密的解析、拆分和/或分离的数据。该方法还可选地包括将被保护的数据重建或重新组装成其原始形式以供授权的访问或使用。该方法可以结合到任何能够执行该方法的期望步骤的计算机、服务器、引擎等的操作中。本发明的另一方面提供了一种用于实际保护任何类型的数据免于未授权访问或使用的系统。该系统包括数据拆分模块、加密处理模块以及可选的数据组装模块。在一个实施例中，该系统还包括一个或多个数据存储设备，其中可以存储安全数据。因此，本发明的一个方面是提供安全服务器或信任引擎，其具有服务器中心(server-centric)密钥，或换句话说，在服务器上存储加密密钥和用户认证数据。根据该实施例，用户访问信任引擎以执行认证和加密功能，所述功能诸如但不限于，认证，授权，数字签名，生成、存储和检索证书，加密，类似公证和类似委托书的动作，等等。
本发明的另一方面是提供一种可靠的或可信任的认证处理。而且，在可信任的肯定认证之后，可以采取大量的不同动作，从提供加密技术，到系统或装置授权和访问，到允许使用或控制一个或大量电子装置。本发明的另一方面是在加密密钥和认证数据不被丢失、偷取或泄露的环境中提供加密密钥和认证数据，从而有利地避免对连续重新发布和管理新密钥和认证数据的需求。根据本发明的另一方面，信任引擎允许用户为多个活动、供应商和/或认证请求使用一个密钥对。根据本发明的另一方面，信任引擎在服务器端执行加密处理的至少一个步骤，例如但不限于，加密、认证、或签名，从而允许客户或用户仅拥有很少的计算资源。根据本发明的另一方面，信任引擎包括一个或多个仓库，用于存储每个加密密钥和认证数据的各个部分。这些部分是通过数据拆分处理来创建的，禁止在没有来自一个仓库中多于一个位置或来自多个仓库的预定部分的情况下重建。根据另一实施例，多个仓库在地理上可以是远离的，从而在一个仓库处的不良员工或被泄密的系统不会提供对用户密钥或认证数据的访问。根据另一实施例，认证处理有利地允许信任引擎并行处理多个认证活动。根据另一实施例，信任引擎可以有利地跟踪失败的访问尝试，并由此限制恶意入侵者可能尝试破坏系统的次数。根据本发明的另一实施例，信任引擎可以包括多个实例，其中每个信任引擎可以预测并与其他信任引擎共享处理负荷。根据另一实施例，信任引擎可以包括用于轮询(poll)多个认证结果以确保多于一个系统认证了用户的冗余模块。因此，本发明的一个方面包括安全加密系统，其可以被远程访问，用于存储任何类型的数据，包括但不限于与多个用户相关联的多个私有加密密钥。该加密系统将多个用户中的每个用户与多个私有加密密钥中的一个或多个不同密钥相关联，并使用相关联的一个或多个不同密钥为每个用户执行加密功能而不释放(release)所述多个私有加密密钥给用户。该加密系统包括仓库系统，其具有存储要保护的数据(诸如多个私有加密密钥和多个注册认证数据)的至少一个服务器。每个注册认证数据识别多个用户之一，并且多个用户中的每个用户与多个私有加密密钥中的一个或多个不同密钥相关联。该加密系统还可以包括认证引擎，其将由多个用户中的一个用户接收的认证数据与对应于该用户并从仓库系统接收的注册认证数据进行比较，从而产生认证结果。该加密系统还可以包括加密引擎，其在认证结果表明正确识别了该多个用户中的该用户时，以该多个用户中的该用户的名义使用从仓库系统接收的相关联的一个或多个不同密钥执行加密功能。该加密系统还可以包括交易引擎，连接以将数据从多个用户路由至仓库服务器系统、认证引擎、以及加密引擎。本发明的另一方面包括安全加密系统，其可选地可远程访问。该加密系统包括仓库系统，其具有存储至少一个私钥和任何其他数据的至少一个服务器，其中其他数据例如但不限于多个注册认证数据，每个注册认证数据识别可能的多个用户之一。该加密系统还可以可选地包括认证引擎，其将用户接收到的认证数据与对应于该用户并从仓库系统接收的注册认证数据进行比较，从而产生认证结果。该加密系统还包括加密引擎，其在认证结果表明正确识别了用户时，以该用户的名义至少使用所述私钥来执行加密功能，所述私钥可以从仓库系统接收。该加密系统还可以可选地包括交易引擎，其连接以将数据从用户路由至其他引擎或系统，例如但不限于，仓库服务器系统、认证引擎、以及加密引擎。
本发明的另一方面包括一种有助于加密功能的方法。该方法包括将多个用户中的一个用户与存储在安全位置(诸如安全服务器)的多个私有加密密钥中的一个或多个密钥相关联。该方法还包括接收来自用户的认证数据，以及将该认证数据与对应于该用户的认证数据进行比较，从而校验该用户的身份。该方法还包括使用一个或多个密钥来执行加密功能而不向该用户释放该一个或多个密钥。本发明的另一方面包括认证系统，用于通过安全存储用户的注册认证数据来唯一识别用户。该认证系统包括一个或多个数据存储设备，其中每个数据存储设备包括计算机可存取存储介质，其存储注册认证数据的至少一个部分。该认证系统还包括与一个或多个数据存储设备通信的认证引擎。该认证引擎包括:数据拆分模块，其对注册认证数据进行操作以创建多个部分；数据组装模块，其处理来自至少一个数据存储设备的部分以组装注册认证数据；以及数据比较器模块，其从用户接收当前认证数据，并将该当前认证数据与所组装的注册认证数据进行比较以确定该用户是否已经被唯一识别。本发明的另一方面包括加密系统。该加密系统包括一个或多个数据存储设备，其中每个数据存储设备包括计算机可存取存储介质，其存储一个或多个加密密钥的至少一部分。该加密系统还包括加密引擎，其与数据存储设备通信。加密引擎还包括:数据拆分模块，其对加密密钥进行操作以创建多个部分；数据组装模块，其处理来自至少一个数据存储设备的部分以组装加密密钥；以及加密处理模块，其接收所组装的加密密钥并利用其执行加密功能。本发明的另一方面包括一种在地理上远程的安全数据存储设备中存储任何类型的数据(包括但不限于认证数据)的方法，从而保护数据不会由任何单独的数据存储设备合成。该方法包括在信任引擎接收数据，在信任引擎将数据与第一基本上随机的值结合以形成第一结合值，以及将数据与第二基本上随机的值结合以形成第二结合值。该方法包括创建第一基本上随机的值与第二结合值的第一配对，创建第一基本上随机的值与第二基本上随机的值的第二配对，以及将第一配对存储在第一安全数据存储设备中。该方法包括将第二配对存储在远离第一安全数据存储设备的第二安全数据存储设备中。本发明的另一方面包括一种存储任何类型的数据(包括但不限于认证数据)的方法，包括:接收数据，将该数据与第一位组(set of bits)结合以形成第二位组，以及将该数据与第三位组结合以形成第四位组。该方法还包括创建第一位组与第三位组的第一配对。该方法还包括创建第一位组与第四位组的第二配对，以及将第一配对和第二配对中的一个存储在第一计算机可存取存储介质中。该方法还包括将第一配对和第二配对中的另一个存储在第二计算机可存取存储介质中。本发明的另一方面包括一种将加密数据存储在地理上远离的安全数据存储设备中的方法，从而保护加密数据不会由任何单独的数据存储设备组成。该方法包括在信任引擎接收加密数据，在信任引擎将加密数据与第一基本上随机的值结合以形成第一结合值，以及将加密数据与第二基本上随机的值结合以形成第二结合值。该方法还包括创建第一基本上随机的值与第二结合值的第一配对，创建第一基本上随机的值与第二基本上随机的值的第二配对，以及将第一配对存储在第一安全数据存储设备中。该方法还包括将第二配对存储在远离第一安全数据存储设备的第二安全数据存储设备中。本发明的另一方面包括一种存储加密数据的方法，包括接收认证数据以及将加密数据与第一位组结合以形成第二位组。该方法还包括将加密数据与第三位组结合以形成第四位组，创建第一位组和第三位组的第一配对，以及创建第一位组和第四位组的第二配对。该方法还包括在第一计算机可存取存储介质中存储第一配对和第二配对中的一个，以及在第二计算机可存取存储介质中存储第一配对和第二配对中的另一个。本发明的另一方面包括一种在加密系统中处理任何类型或形式的敏感数据的方法，其中敏感数据仅在授权用户使用该敏感数据的动作期间以可用形式存在。该方法还包括在软件模块中从第一计算机可存取存储介质接收基本上随机化的或加密的敏感数据，以及在该软件模块中从一个或多个其他计算机可存取存储介质接收可能是或不是敏感数据的基本上随机化的或加密的数据。该方法还包括在软件模块中处理基本上随机化的预加密敏感数据和可能是或不是敏感数据的基本上随机化的或加密的数据以组装敏感数据，以及在软件引擎中使用敏感数据执行动作。所述动作包括但不限于认证用户和执行加密功能之
O本发明的另一方面包括安全认证系统。该安全认证系统包括多个认证引擎。每个认证引擎接收被设计为以某个确信度唯一识别用户的注册认证数据。每个认证引擎接收当前认证数据以与注册认证数据相比较，并且每个认证引擎确定认证结果。该安全认证系统还包括冗余系统，其接收至少两个认证引擎的认证结果并确定用户是否已被唯一识别。本发明的另一方面包 括在移动系统中的安全数据，借由该移动系统，数据能够在根据本发明被保护的不同部分中传输，从而被泄露的任何一个部分都不会提供足够数据来恢复原始数据。这可以应用于任何数据传输，无论其是有线、无线或物理的。本发明的另一方面包括将本发明的安全数据解析器集成到存储或传输数据的任何适当系统中。例如，电子邮件系统、RAID系统、视频广播系统、数据库系统、或任何其他适当系统可以具有以任何适当等级集成的安全数据解析器。本发明的另一方面包括使用任何适当的解析和拆分算法来生成数据份(share)。随机、伪随机、确定的或其任意组合都可以被采用来解析和拆分数据。
下面结合附图具体描述本发明，附图用于示出本发明，但不用于限制本发明，其中:图1示出了根据本发明的实施例的多个方面的加密系统的框图；图2示出了根据本发明的实施例的多个方面，图1的信任引擎的框图；图3示出了根据本发明的实施例的多个方面，图2的交易引擎的框图；图4示出了根据本发明的实施例的多个方面，图2的仓库的框图；图5示出了根据本发明的实施例的多个方面，图2的认证引擎的框图；图6示出了根据本发明的实施例的多个方面，图2的加密引擎的框图；图7示出了根据本发明的另一实施例的多个方面的仓库系统的框图；图8示出了根据本发明的实施例的多个方面的数据拆分处理的流程图；图9，面A示出了根据本发明的实施例的多个方面的注册处理的数据流；图9,面B示出了根据本发明的实施例的多个方面的互用性(interoperability)处理的流程图10示出了根据本发明的实施例的多个方面的认证处理的数据流；图11示出了根据本发明的实施例的多个方面的签名处理的数据流；图12示出了根据本发明的另一实施例的多个方面的数据流和加密/解密处理；图13示出了根据本发明的另一实施例的多个方面的信任引擎系统的简化框图；图14示出了根据本发明的另一实施例的多个方面的信任引擎系统的简化框图；图15示出了根据本发明的实施例的多个方面，图14的冗余模块的框图；图16示出了根据本发明的一个方面，评估认证的处理；图17示出了根据在本发明的图16中所示的一个方面，为认证赋值的处理；图18示出了在图17中所示的本发明的一个方面中执行信任裁决的处理；图19示出了根据本发明的实施例的多个方面，在用户和卖方之间的范例交易，其中，初始基于网页的联系引向由双方签署的销售合同；图20示出了具有为用户系统提供安全性功能的加密服务提供者模块的范例用户系统；图21示出了解析、拆分和/或分离被加密的数据以及将加密主密钥与数据一起存储的处理；图22示出了解析、拆分和/或分离被加密的数据以及将加密主密钥与数据分开存储的处理；图23示出了解析、拆分和/或分离被加密的数据以及将加密主密钥与数据一起存储的中间密钥处理；图24示出了解析、拆分和/或分离被加密的数据以及将加密主密钥与数据分开存储的中间密钥处理；图25示出了对于小工作组，本发明的加密方法和系统的使用；图26是采用根据本发明一个实施例的安全数据解析器的示例性物理令牌安全系统的框图；图27是根据本发明的一个实施例，将安全数据解析器集成在系统中的示例性布置的框图；图28是根据本发明一个实施例的在移动系统中的示例性数据的框图；图29是根据本发明一个实施例的在移动系统中的另一示例性数据的框图；图30-32是根据本发明一个实施例的具有集成的安全数据解析器的示例性系统的框图；图33是根据本发明的一个实施例的用于解析和拆分数据的示例性处理的处理流程图；图34是根据本发明的一个实施例的用于将多个部分的数据恢复成原始数据的示例性处理的处理流程图；图35是根据本发明的一个实施例的用于以位级拆分数据的示例性处理的处理流程图；图36是根据本发明的一个实施例的示例性步骤和特征的处理流程图，其可以具有任何适当添加、删除或修改，或以任何适当组合的形式被使用；图37是根据本发明的一个实施例的示例性步骤和特征的处理流程图，其可以具有任何适当添加、删除或修改，或以任何适当组合的形式被使用；图38是根据本发明的一个实施例，份中的密钥和数据成分的存储的简化框图，其可以具有任何适当添加、删除或修改，或以任何适当组合的形式被使用；图39是根据本发明的一个实施例，使用工作组密钥的份中的密钥和数据成分的存储的简化框图，其可以具有任何适当添加、删除或修改，或以任何适当组合的形式被使用；图40A和40B是用于移动数据的头生成和数据拆分的简化和示意性处理流程图，其可以具有任何适当添加、删除或修改，或以任何适当组合的形式被使用；图41是根据本发明的一个实施例的示例性份格式的简化框图，其可以具有任何适当添加、删除或修改，或以任何适当组合的形式被使用；图42是根据本发明的一个实施例的用于管理加密密钥的示例性步骤和特征的处理流程图，其可以具有任何适当添加、删除或修改，或以任何适当组合的形式被使用。
具体实施例方式本发明的一个方面提供一种加密系统，其中一个或多个安全服务器或信任引擎存储加密密钥和用户认证数据。用户通过对信任引擎的网络访问来访问传统加密系统的功能，然而，信任引擎不释放实际密钥和其他认证数据，因此，密钥和数据保持安全。密钥和认证数据的这种服务器中心存储提供用户无关的安全性、便携性、可用性以及简单性。因为用户能够确信或信任该加密系统来执行用户和文档认证以及其他加密功能，所以广泛的各种功能可以被结合到该系统中。例如，信任引擎提供者可以通过例如认证协定参与者、以参与者的名义或者为参与者数字签署协定、以及存储由每个参与者数字签署的协定的记录，来确保防备协定抵赖(repudiation)。此外，该加密系统可以监视协定并基于例如价格、用户、卖方、地理位置、使用地点等来确定应用不同程度的认证。为了便于完全理解本发明，具体实施方式
的余下部分参考附图描述本发明，其中通篇，类似的部件使用类似的标号来表示。图1示出了根据本发明的实施例的多个方面的加密系统100的框图。如图1所示，加密系统100包括通过通信链路125进行通信的用户系统105、信任引擎110、证书颁发机构(certificate authority) 115、以及卖方系统 120。根据本发明的一个实施例，用户系统105包括传统通用目的计算机，其具有一个或多个微处理器，例如基于Intel的处理器。此外,用户系统105包括适当的操作系统,例如，能够包括图形或窗口的操作系统，诸如Windows、Unix、Linux等等。如图1所示,用户系统105可以包括生物识别装置107。生物识别装置107可以有利地获取用户的生物识别信息并将获取的生物识别信息传递至信任引擎110。根据本发明的一个实施例，生物识别装置可以有利地包括具有类似于在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中公开的那些属性和特征的装置，所有这些专利由当前受让人所有，以及全部通过引用结合于此。此外，用户系统105可以通过传统业务提供商，例如，拨号、数字订户线路(DSL)、有线调制解调器、光纤连接等等，连接到通信链路125。根据另一实施例，用户系统105通过诸如局域网或广域网之类的网络连接而连接通信链路125。根据一个实施例，操作系统包括TCP/IP栈，其处理在通信链路125上传递的所有输入和输出消息业务。尽管参考上述实施例描述了用户系统105，但是本发明不因此而被限制。相反，本领域技术人员由此处的披露应该意识到用户系统105的大量可替换实施例，包括能够发送信息至另一计算机系统或从另一计算机系统接收信息的几乎任何计算装置。例如，用户系统105可以包括但不限于，能够与通信链路125交互的计算机工作站、交互式电视、交互式信息站、个人移动计算装置(诸如数字助理、移动电话、膝上型电脑等等)、无线通信装置、智能卡、嵌入式计算装置等等。在这样的可替换系统中，操作系统很可能不同，并且适于特定装置。然而，根据一个实施例，操作系统有利地继续提供与通信链路建立通信所需的适当的通信协议。图1示出了信任引擎110。根据一个实施例，该信任引擎110包括用于访问和存储敏感信息的一个或多个安全服务器，敏感信息可以是任何类型或形式的数据，诸如但不限于文本、音频、视频、用户认证数据以及公共和私有加密密钥。根据一个实施例，认证数据包括被设计为唯一识别加密系统100的用户的数据。例如，认证数据可以包括用户标识号、一个或多个生物识别信息、以及由信任引擎100或用户生成但由用户在注册时初始回答的一系列问题和答案。上述问题可以包括诸如出生地、地址、周年纪念之类的人口统计数据，诸如母亲的娘家姓、最喜欢的冰激凌之类的个人数据，或被设计为唯一识别用户的其他数据。信任引擎110将与当前交易相关联的用户的认证数据与较早时候(例如注册期间)提供的认证数据进行比较。信任引擎110可以有利地要求用户在每次交易时产生认证数据，或者，信任引擎110可以有利地允许用户周期性地产生认证数据，例如在一串交易的开始或在登录到特定卖方网站时。根据用户产生生物识别数据的实施例，用户向生物识别装置107提供身体特征，诸如但不限于脸部扫描、手扫描、耳朵扫描、虹膜扫描、视网膜扫描、血管模式、DNA、指纹、笔迹、或语音。生物识别装置有利地产生身体特征的电子图案或生物识别信息。电子图案通过用户系统105被传递至信任引擎110用于注册或认证目的。一旦用户产生适当的认证数据并且信任引擎110确定认证数据(当前认证数据)与在注册时提供的认证数据(注册认证数据)之间的肯定匹配，则信任引擎110向用户提供完全的加密功能。例如，被正确认证的用户可以有利地使用信任引擎110来执行散列、数字签名、加密和解密(通常一起仅称为加密)、创建或分发数字证书、等等。然而，用在加密功能中的私有加密密钥在信任引擎110之外不可用，因此保证加密密钥的完整性。根据一个实施例，信任引擎110生成并存储加密密钥。根据另一实施例，至少一个加密密钥与每个用户相关联。此外，当加密密钥包括公钥技术时，与用户相关的每个私钥在信任引擎110中生成，而不从其释放。因此，只要用户已经访问了信任引擎110，用户就可以使用他或她的私钥或公钥执行加密功能。这样的远程访问有利地允许用户保留完全的移动性，以及通过实际中的任何因特网连接(例如蜂窝和卫星电话、信息站、膝上型电脑、宾馆房间等)访问加密功能。根据另一实施例，信任引擎110使用为信任引擎110生成的密钥对来执行加密功能。根据该实施例，信任引擎110首先认证该用户，然后在用户已经正确产生与注册认证数据匹配的认证数据之后，信任引擎110使用其本身的加密密钥对，以被认证的用户的名义执行加密功能。本领域的技术人员从此处的公开应意识到，加密密钥可以有利地包括一些或所有对称密钥、公钥和私钥。此外，本领域的技术人员从此处的公开应意识到，上述密钥可以使用诸如RSA、ELGAMAL等商业技术提供的多种算法来实现。图1还示出了证书颁发机构115。根据一个实施例，证书颁发机构115可以有利地包括发布数字证书的可信的第三方组织或公司，例如，VeriSign, Baltimore, Entrust等等。信任引擎110可以有利地通过一个或多个传统数字证书协议(例如PKCS10)向证书颁发机构115发送数字证书请求。作为响应，证书颁发机构115将以多种不同协议中的一种或多种发布数字证书，例如PKCS7。根据本发明的一个实施例，信任引擎110从多个或所有著名的证书颁发机构115请求数字证书，从而信任引擎110能够使用与任何请求方的证书标准相对应的数字证书。根据另一实施例，信任引擎110在内部执行证书发布。在该实施例中，信任引擎110可以访问证书系统以生成证书和/或可以在证书被请求时，例如在密钥生成时，或者以请求时所请求的证书标准，在内部生成证书。下面将更加详细地披露信任引擎110。图1还示出了卖方系统120。根据一个实施例，卖方系统120有利地包括Web服务器。典型的Web服务器通常使用多种互联网标记语言或文档格式标准(例如超文本标记语言(HTML)或可扩展标记语言(XML))中的一种在因特网上提供内容。Web服务器接受来自诸如Netscape和Internet Explorer之类的浏览器的请求,然后返回适当的电子文档。多种服务器或客户端技术可以用来在传递标准电子文档的能力之外增加Web服务器的能力。例如，这些技术包括公共网关接口(CGI)脚本、安全套接字层(SSL)安全、以及动态服务器网页(ASP)。卖方系统120可以有利地提供关于商业、个人、教育或其他交易的电子内容。尽管参考上面实施例披露了卖方系统120，但是本发明不因此被限制。相反，本领域技术人员应该从此处的公开意识到，卖方系统120可以有利地包括参考用户系统105描述的任何装置或其组合。图1还示出了连接用户系统105、信任引擎110、证书颁发机构115和卖方系统120的通信链路125。根据一个实施例，通信链路125优选地包括因特网。如在整个公开中所使用的，因特网是计算机的全球网络。本领域普通技术人员公知的因特网的结构包括网络骨干(network backbone),以及从骨干分支的网络。这些分支又具有从它们分支的网络,如此等等。路由器在网络级之间移动信息包，然后从网络至网络，直到包到达其目的地附近。从该目的地，目的地网络的主机将该信息包引向适当的终端或节点。在一个有利的实施例中，因特网路由集线器包括本领域公知的使用传输控制协议/网际协议(TCP/IP)的域名系统(DNS)服务器。路由集线器通过高速通信链路连接到一个或多个其他路由集线器。因特网的一个普及部分是万维网。万维网包括不同的计算机，其存储能够显示图形或文本信息的文件。在万维网上提供信息的计算机通常被称作“网站”。网站由具有相关电子页面的因特网地址定义。电子页面可以由统一资源定位符(URL)标识。通常，电子页面是组织文本、图形图像、音频、视频等的呈现的文档。尽管通信链路125以其优选实施例被公开，但是本领域的技术人员应该从在此的公开意识到，通信链路125可以包括广泛的交互通信链路。例如，通信链路125可以包括交互式电视网络、电话网络、无线数据传输系统、双向电缆系统、定制的私有或公共计算机网络、交互式信息站网络、自动柜员机网络、直接链路、卫星或蜂窝网络、等等。图2示出了根据本发明的一个实施例的多个方面的图1的信任引擎110的框图。如图2所示，信任引擎110包括交易引擎205、仓库210、认证引擎215、以及加密引擎220。根据本发明的一个实施例，信任引擎110还包括大容量存储器225。如图2进一步所示，交易引擎205与仓库210、认证引擎215、以及加密引擎220、连同大容量存储器225通信。此夕卜，仓库210与认证引擎215、加密引擎220以及大容量存储器225通信。此外，认证引擎215与加密引擎220通信。根据本发明的一个实施例，上述通信中的一些或所有都可以有利地包括传输XML文档至对应于接收装置的IP地址。如上所述，XML文档有利地允许设计者创建其自身的定制文档标签，使得能够在应用程序之间和组织之间定义、传输、验证和解释数据。此外，上述通信中的一些或所有可以包括传统SSL技术。根据一个实施例,交易引擎205包括数据路由装置,诸如由Netscape、Microsoft、Apache等提供的传统Web服务器。例如，Web服务器可以有利地接收来自通信链路125的输入数据。根据本发明的一个实施例，输入数据被定址到用于信任引擎110的前端安全系统。例如，前端安全系统可以有利地包括防火墙、搜索已知攻击特征的入侵检测系统、和/或病毒扫描器。在通过前端安全系统之后，数据由交易引擎205接收并路由至仓库210、认证引擎215、加密引擎220以及大容量存储器225之一。此外，交易引擎205监视来自认证引擎215和加密引擎220的输入数据，并通过通信链路125将数据路由至特定系统。例如，交易引擎205可以有利地将数据路由至用户系统105、证书颁发机构115或卖方系统120。根据一个实施例，数据使用传统HTTP路由技术被路由，例如采用URL或统一资源指示符(URI)。URI类似于URL，然而，URI通常指示文件或动作的源，例如，可执行文件、脚本等。因此，根据一个实施例，用户系统105、证书颁发机构115、卖方系统120、以及信任引擎210的部件有利地包括通信URL或URI中的足够数据以便交易引擎205在加密系统中正确地路由数据。尽管参考其优选实施例公开了数据路由，但是本领域的技术人员应该意识到大量的可行的数据路由解决方案或策略。例如，XML或其他数据包可以有利地通过其格式、内容等被拆包和识别，从而交易引擎205可以在信任引擎110中正确地路由数据。此外，本领域技术人员应该意识到，数据路由可以有利地适应符合特定网络系统——例如当通信链路125包括局域网时-的数据传输协议。根据本发明的另一实施例，交易引擎205包括传统SSL加密技术，从而上述系统可以在特定通信期间使用交易引擎205认证自身，反之亦然。如在整个公开中所使用的，术语“1/2SSL”表示服务器被SSL认证而客户端不一定被SSL认证的通信，术语“全SSL”表示客户端和服务器都被SSL认证的通信。在当前公开使用术语“SSL”时，通信可以包括1/2或全 SSL。当交易引擎205将数据路由至加密系统100的各部件时，交易引擎205可以有利地创建审计跟踪(audit trail)。根据一个实施例，审计跟踪包括至少关于由交易引擎205在加密系统100中路由的数据的类型和格式的记录。这样的审计数据可以有利地存储在大容量存储器225中。图2还示出了仓库210。根据一个实施例，仓库210包括一个或多个数据存储设备，诸如目录服务器、数据库服务器等。如图2中所示，仓库210存储加密密钥和注册认证数据。加密密钥可以有利地对应于信任引擎110或者对应于加密系统100的用户，诸如用户或卖方。注册认证数据可以有利地包括被设计为唯一识别用户的数据，诸如用户ID、口令、问题答案、生物识别数据等。该注册认证数据可以有利地在用户注册时或其他可替换的稍后时间被获取。例如，信任引擎110可以包括注册认证数据的周期性的或别的更新或重新发布。根据一个实施例，往返于交易引擎205与认证引擎215和加密引擎220之间的通信包括安全通信，例如，传统SSL技术。此外，如上所述，往返于仓库210的通信的数据可以使用URL、UR1、HTTP或XML文档传递，它们有利地将数据请求和格式嵌入其中。如上所述，仓库210可以有利地包括多个安全数据存储设备。在这样的实施例中，安全数据存储设备可以被配置为使得单个数据存储设备中的安全性损害不会泄露存储在其中的加密密钥或认证数据。例如，根据该实施例，对加密密钥和认证数据进行数学运算以便统计地并基本上随机化存储在每个数据存储设备中的数据。根据一个实施例，单个数据存储设备的数据的随机化使得数据不可破译。因此，单个数据存储设备的泄密仅仅产生随机的不可破译的数字并且不损害作为整体的加密密钥或认证数据的安全性。图2还示出了信任引擎110包括认证引擎215。根据一个实施例，认证引擎215包括数据比较器，其被配置为将来自交易引擎205的数据与来自仓库210的数据进行比较。例如，在认证过程中，用户将当前认证数据提供至信任引擎110，从而交易引擎205接收到该当前认证数据。如上所述，交易引擎205识别优选为URL或URI的数据请求，并将认证数据路由至认证引擎215。此外，基于请求，仓库210将对应于该用户的注册认证数据转发至认证引擎215。从而，认证引擎215具有当前认证数据和注册认证数据这两者以供比较。根据一个实施例，至认证引擎的通信包括安全通信，诸如SSL技术。此外，可以在信任引擎110部件中提供安全性，例如使用公钥技术的超级加密。例如，根据一个实施例，用户使用认证引擎215的公钥来加密当前认证数据。此外，仓库210还使用认证引擎215的公钥来加密注册认证数据。以该方式，只有认证引擎的私钥可以被用来解密该传输。如图2中所示，信任引擎110还包括加密引擎220。根据一个实施例，加密引擎包括加密处理模块，其被配置为有利地提供传统加密功能，诸如公钥基础结构(PKI)功能。例如，加密引擎220可以有利地发布用于加密系统100的用户的公钥和私钥。以该方式，加密密钥在加密引擎220处生成，并被转发至仓库210，从而至少私有加密密钥在信任引擎110外部不可用。根据另一实施例，加密引擎220至少随机化并拆分私有加密密钥数据，从而仅存储随机化的拆分的数据。类似于注册认证数据的拆分，拆分处理保证所存储的密钥在加密引擎220的外部不可用。根据另一实施例，加密引擎的功能可以与认证引擎215结合并由其执行。根据一个实施例，往返于加密引擎的通信包括安全通信，诸如SSL技术。此外，XML文档可以有利地被用于传递数据和/或进行加密功能请求。图2还示出了信任引擎110具有大容量存储器225。如上所述，交易引擎205保持对应于审计跟踪的数据，并将这样的数据存储在大容量存储器225中。类似地，根据本发明的一个实施例，仓库210保持对应于审计跟踪的数据并将这样的数据存储在大容量存储装置225中。仓库审计跟踪数据类似于交易引擎205的审计跟踪数据，因为审计跟踪数据包括由仓库210接收的请求的记录及其响应。此外，大容器存储器225可以被用来存储其中包含有用户公钥的数字证书。尽管参考其优选和可替换实施例公开了信任引擎110，但本发明不因此被限制。相反，本领域技术人员在此处的公开中应该意识到信任引擎110的大量替换例。例如，信任引擎110可以有利地仅执行认证，或可替换地，仅执行部分或全部加密功能，诸如数据加密和解密。根据这样的实施例，认证引擎215和加密引擎220之一可以有利地被去除，从而创建更加简单的信任引擎110设计。此外，加密引擎220还可以与证书颁发机构通信，从而证书颁发机构被包括在信任引擎110中。根据另一实施例，信任引擎110可以有利地执行认证和一个或多个加密功能，例如数字签名。图3示出了根据本发明的实施例的多个方面，图2的交易引擎205的框图。根据该实施例，交易引擎205包括具有处理线程和监听线程的操作系统305。操作系统305可以有利地类似于在传统大容量服务器中的那些操作系统，例如由Apache提供的Web服务器。监听线程监视来自通信链路125、认证引擎215、以及加密引擎220之一的输入通信中的输入数据流。处理线程识别输入数据流的特定数据结构，例如前述的数据结构，从而将输入数据路由至通信链路125、仓库210、认证引擎215、加密引擎220、或大容量存储器225之一。如图3所示，输入和输出数据可以有利地通过例如SSL技术而被保护。图4示出了根据本发明的实施例的多个方面的图2的仓库210的框图。根据该实施例，仓库210包括一个或多个轻量级目录访问协议(LDAP)服务器。LDAP目录服务器可以由多个制造商提供，诸如Netscape、ISO和其他制造商。图4还示出，目录服务器优选存储对应于加密密钥的数据405和对应于注册认证数据的数据410。根据一个实施例，仓库210包括单个逻辑存储结构，其将认证数据和加密密钥数据索引至唯一用户ID。该单个逻辑存储结构优选地包括保证存储在其中的数据具有高信任度或安全性的机制。例如，仓库210的物理位置可以有利地包括多种传统安全措施，诸如有限的雇员访问、现代监视系统等。在物理安全措施之外或取而代之，计算机系统或服务器可以有利地包括软件解决方案来保护存储的数据。例如，仓库210可以有利地创建并存储与所执行的动作的审计跟踪相对应的数据415。此外，输入和输出通信可以有利地使用与传统SSL技术相结合的公钥加密来加
LU O根据另一实施例，仓库210可以包括不同的且物理上分开的数据存储设备，如进一步参考图7所述。图5示出了根据本发明的实施例的多个方面，图2的认证引擎215的框图。类似于图3的交易引擎205，认证引擎215包括操作系统505，其至少具有传统Web服务器(例如Apache提供的Web服务器)的修改版本的监听和处理线程。如图5所示，认证引擎215包括对至少一个私钥510的访问。私钥510可以有利地被用来例如解密来自交易引擎205或仓库210的使用认证引擎215的相应公钥加密过的数据。图5还示出了认证引擎215包括比较器515、数据拆分模块529、以及数据组装模块525。根据本发明的优选实施例，比较器515包括能够比较与上述生物识别认证数据有关的可能复杂的图案的技术。该技术可以包括用于图案比较的硬件、软件或其组合方案，所述图案诸如是表示指纹图案或语音图案的那些图案。此外，根据一个实施例，认证引擎215的比较器515可以有利地比较文档的传统散列值以给出比较结果。根据本发明的一个实施例，比较器515包括将试探法(heuristics) 530应用于比较。试探法530可以有利地处理围绕认证尝试的详情，例如一天中的时间、IP地址或子网掩码、购买简档、电子邮件地址、处理器序列号或ID、等等。此外，生物识别数据比较的特性可能使得由当前生物识别认证数据与注册数据的匹配产生变化的可信度。例如，与可能仅返回肯定或否定匹配的传统口令不同，指纹可能被确定为是部分匹配，例如，90%匹配、75%匹配或10%匹配，而不是简单地正确或不正确。诸如声纹分析或面貌识别之类的其他生物识别标识也可以具有该概率认证性质，而不是绝对认证。当使用这样的概率认证或者在认证被认为并非绝对可靠的情况下，希望应用试探法530来确定所提供的认证中的可信度是否足够高到能够认证正在进行的交易。 有时候的情况是，待解决的交易是相对低价值的交易，其中被认证为较低可信度是可以接受的。这可能包括与其相关的美金值较低的交易(例如，$10购买)或具有较低风险的交易(例如，仅会员可进的网站)。相反，为了认证其他交易，希望在允许交易进行之前要求认证的高可信度。这样的交易可能包括大额美金值的交易(例如，签订几百万美金供应合同)或如果发生不正确的认证会具有高风险的交易(例如远程登录至政府计算机)。下面将描述使用试探法530与可信度和交易值结合，以允许比较器提供动态的上下文相关的认证系统。根据本发明的另一实施例，比较器515可以有利地跟踪对于特定交易的认证尝试。例如，当交易失败时，信任引擎110可以请求用户重新输入他或她的当前认证数据。认证引擎215的比较器515可以有利地使用尝试限制器535来限制认证尝试的次数，从而禁止试图模仿用户的认证数据的暴力尝试。根据一个实施例，尝试限制器535包括监视交易中的重复认证尝试并例如将对于给定交易的认证尝试限制为三次的软件模块。因此，尝试限制器535将限制模仿个体的认证数据的自动化尝试，例如简单的三次“guesses”。一旦三次失败，尝试限制器535可以有利地拒绝追加的认证尝试。这样的拒绝可以有利地通过例如不管被传输的当前认证数据是什么，比较器515都返回否定结果来实现。另一方面，交易引擎205可以有利地阻止与之前已有三次失败尝试的交易有关的任何其它的认证尝试。认证引擎215还包括数据拆分模块520和数据组装模块525。数据拆分模块520有利地包括软件、硬件或组合模块，具有对各种数据进行数学运算从而基本上随机化数据并将其拆分成多个部分的能力。根据一个实施例，原始数据不能从单个部分中重建。数据组装模块525有利地包括软件、硬件或组合模块，其被配置为对上述基本上随机化的部分进行数学运算，从而其组合提供原始的被破译数据。根据一个实施例，认证引擎215使用数据拆分模块520来随机化注册认证数据并将其拆分成多个部分，以及使用数据组装模块525来将这些部分重新组装成可用的注册认证数据。图6示出了根据本发明的一个实施例的多个方面，图2的信任引擎200的加密引擎220的框图。类似于图3的交易引擎205，加密引擎220包括操作系统605，其至少具有传统Web服务器(例如，Apache提供的Web服务器)的修改版本的监听线程和处理线程。如图6中所示，加密引擎220包括数据拆分模块610和数据组装模块620，其功能类似于图5中的那些模块。然而，根据一个实施例，数据拆分模块610和数据组装模块620处理加密密钥数据，不同于上述注册认证数据。尽管如此，本领域技术人员从此处的公开应意识到数据拆分模块610和数据组装模块620可以与认证引擎215的数据拆分模块和数据组装模块结
口 ο加密引擎220还包括加密处理模块625，其被配置为执行大量加密功能中的一个、部分或所有。根据一个实施例，加密处理模块625可以包括软件模块或程序、硬件、或两者。根据另一实施例，加密处理模块625可以执行数据比较、数据解析、数据拆分、数据分离、数据散列、数据加密或解密、数字签名校验或创建、数字证书的生成、存储或请求、加密密钥生成、等等。此外，本领域技术人员应该从在此处的公开意识到，加密处理模块625可以有利地包括公钥基础结构，诸如优秀保密(Pretty Good Privacy，PGP)、基于RSA的公钥系统、或大量可替换的密钥管理系统。此外，加密处理模块625可以执行公钥加密、对称密钥加密、或两者。除了上面所述，加密处理模块625可以包括一个或多个计算机程序或模块、硬件、或两者，用于实现无缝、透明、互用性功能。本领域的技术人员从在此的公开还应该意识到，加密功能可以包括通常与加密密钥管理系统有关的大量或多种功能。图7示出了根据本发明的实施例的多个方面的仓库系统700的简化框图。如图7所示，仓库系统700有利地包括多个数据存储设备，例如，数据存储设备D1、D2、D3和D4。然而，本领域的普通技术人员容易理解仓库系统可能仅具有一个数据存储设备。根据本发明的一个实施例，每个数据存储设备Dl至D4可以有利地包括参考图4的仓库210公开的部分或所有元件。类似于仓库210，数据存储设备Dl至D4与交易引擎205、认证引擎215、以及加密引擎220通信，优选通过传统SSL通信。通信链路传输例如XML文档。来自交易引擎205的通信可以有利地包括对数据的请求，其中该请求被有利地广播至每个数据存储设备Dl至D4的IP地址。另一方面，交易引擎205可以基于诸如响应时间、服务器负荷、维护计划等大量标准而将请求广播至特定数据存储设备。响应于来自交易引擎205的对于数据的请求，仓库系统700有利地转发所存储的数据至认证引擎215和加密引擎220。各个数据组装模块接收转发的数据并将数据组装成可用格式。另一方面，从认证引擎215和加密引擎220到数据存储设备Dl至D4的通信可以包括传输要存储的敏感数据。例如，根据一个实施例，认证引擎215和加密引擎220可以有利地使用其各自的数据拆分模块以将敏感数据分解成不可破译的部分，然后将敏感数据的一个或多个不可破译的部分传输至特定数据存储设备。根据一个实施例，每个数据存储设备Dl至D4包括分开且独立的存储系统，例如目录服务器。根据本发明的另一实施例，仓库系统700包括多个地理上分开的独立的数据存储系统。通过将敏感数据分发至不同且独立的存储设备Dl至D4—其中部分或所有存储设备可以有利地在地理上分开，仓库系统700与其他安全措施一起提供冗余。例如，根据一个实施例，仅来自多个数据存储设备Dl至D4中的两个数据存储设备的数据需要解密并重新组装该敏感数据。因此，四个数据存储设备Dl至D4中的两个数据存储设备可以由于维护、系统故障、电源故障等而不工作，但不影响信任引擎110的功能。此外，因为根据一个实施例，存储在每个数据存储设备中的数据被随机化并不可破译，所以任何单个数据存储设备的泄密不必然地泄露敏感数据。此外，在数据存储设备地理上分开的实施例中，多个地理上远离的设备的泄密变得越发困难。事实上，不良员工要暗中破坏所需的多个独立的地理上远离的数据存储设备将面临更大的挑战。尽管参考其优选和可替换实施例描述了仓库系统700，但是本发明不因此被限制。相反，本领域技术人员将由在此的公开意识到仓库系统700的多个替换例。例如，仓库系统700可以包括一个、两个或更多数据存储设备。此外，敏感数据可以被数学运算，使得需要来自两个或更多数据存储设备的部分以便重新组装并解密该敏感数据。如上所述，认证引擎215和加密引擎220每个都分别包括数据拆分模块520和610，用于拆分任何类型或形式的敏感数据，诸如文本、音频、视频、认证数据和加密密钥数据。图8示出了根据本发明的实施例的多个方面，由数据拆分模块执行的数据拆分处理800的流程图。如图8所示，数据拆分处理800在步骤805处开始，此时敏感数据“S”由认证引擎215或加密引擎220的数据拆分模块接收。优选地，在步骤810，数据拆分模块然后生成基本上随机的数、值、或串、或位组“A”。例如，随机数A可以用本领域技术人员已知的用于产生适于在加密应用中使用的高质量随机数的多种不同传统技术生成。此外，根据一个实施例，随机数A包括可以是任何适当长度的位长度，诸如短于、长于、或等于敏感数据S的位长度。此外，在步骤820中，数据拆分处理800生成另一统计上随机的数“C”。根据优选实施例，统计上随机的数A和C可以有利地并行生成。数据拆分模块然后将数A和C与敏感数据S结合，从而生成新的数“B”和“D”。例如，数B可以包括A XOR S的二进制结合，数D可以包括C XOR S的二进制结合。XOR函数或“异或”函数对于本领域的技术人员是已知的。上述结合优选地分别发生在步骤825和830，以及根据一个实施例，上述结合还并行发生。数据拆分处理800然后进行到步骤835，其中随机数A和C以及数B和D被配对，使得没有哪个配对本身包含重新组织和解密原始敏感数据S的足够数据。例如，这些数可以被如下配对:AC,AD,BC和BD。根据一个实施例,每一个上述配对被分配至图7中的仓库Dl至D4之一。根据另一实施例，每个上述配对被随机分配给仓库Dl至D4之一。例如，在第一数据拆分处理800的过程中，配对AC可以通过例如随机选择的D2的IP地址被发送至仓库D2。然后，在第二数据拆分处理800的过程中，配对AC可以通过例如随机选择的D4的IP地址被发送至仓库D4。此外，这些配对所有都可以被存储在一个仓库，以及可以被存储在所述仓库中分开的位置。基于上面所述，数据拆分处理800有利地将敏感数据的多个部分放置在四个数据存储设备Dl至D4中的每一个中，从而没有单个数据存储设备Dl至D4包括重建原始敏感数据S的足够的被加密的数据。如上所述，这样的将数据随机化为单独不可用的加密部分提升了安全性并提供了对数据的信任的维持，即使数据存储设备Dl至D4之一被泄密。尽管参考其优选实施例公开了数据拆分处理800，本发明不因此被限制。相反，本领域的技术人员应从此处的公开意识到数据拆分处理800的多种替换。例如，数据拆分处理可以有利地将数据拆分成两个数，例如，随机数A和数B，并且通过两个数据存储设备随机分配A和B。此外，数据拆分处理800可以有利地通过生成另外的随机数而在大量数据存储设备中拆分数据。数据可以被拆分成任何期望的、选择的、预定的或随机分配的尺寸单元，包括但不限于一位、多位、字节、千字节、兆字节或更大、或尺寸的任何组合或序列。此夕卜，由拆分处理导致的改变数据单元的尺寸可以使得数据更难以恢复成可用形式，从而增加敏感数据的安全性。本领域的普通技术人员容易理解，拆分数据单元的尺寸可以是多种不同的数据单元尺寸或尺寸的图样(pattern)或尺寸的组合。例如，数据单元尺寸可以被选择或预定为都具有相同的尺寸、具有不同尺寸的固定的组、尺寸的组合、或随机生成尺寸。类似地，数据单元可以根据固定或预定的数据单元尺寸、数据单元尺寸的图样或组合、或随机生成的数据单元尺寸或每份的尺寸而被分配成一份或多份。如上所述，为了重建敏感数据S，数据部分需要被解随机和重新组织。该处理可以有利地分别发生在认证引擎215和加密引擎220的数据组装模块525和620中。数据组装模块，例如数据组装模块525，接收来自数据存储设备Dl至D4的数据部分，以及将数据组装成可用形式。例如，根据一个实施例，数据拆分模块520使用图8的数据拆分处理800，而数据组装模块525使用来自数据存储设备Dl至D4中至少两个的数据部分以重建敏感数据S。例如，配对AC、AD、BC和BD被分配以使得任何两个提供A和B或C和D之一。注意S=A XOR B或S=C XOR D表示当数据组装模块接收A和B或C和D之一时，数据组装模块525可以有利地重新组装敏感数据S。因此，数据组装模块525可以在例如接收到来自数据存储设备Dl至D4中至少前两个的数据部分时，组装敏感数据S，以响应于信任引擎110的组装请求。基于上述的数据拆分和组装处理，敏感数据S仅在信任引擎110的有限区域中以可用格式存在。例如，当敏感数据S包括注册认证数据时，可用的未随机化的注册认证数据仅在认证引擎215中可用。类似地，当敏感数据S包括私有加密密钥数据时，可用的未随机化的私有加密密钥数据仅在加密引擎220中可用。尽管参考其优选实施例公开了数据拆分和组装处理，本发明不因此被限制。相反，本领域的技术人员从此处的公开应该意识到用于拆分和重新组装敏感数据S的多种替换。例如，公钥加密可以被用于在数据存储设备Dl至D4处进一步保护数据。此外，本领域的技术人员容易理解在此描述的数据拆分模块也是本发明的单独且独立的实施例，可以合并到包括任何已有计算机系统、软件套件、数据库、或其组合、或本发明的其他实施例(诸如在此公开和描述的信任引擎、认证引擎以及交易引擎)中，或与之结合，或作为其中一部分。图9A示出了根据本发明的实施例的多个方面的注册处理900的数据流。如图9A所示，注册处理900在步骤905处开始，用户期望使用加密系统100的信任引擎110注册。根据该实施例，用户系统105有利地包括例如基于Java的客户端小程序(applet),其询问用户以输入注册数据，例如人口统计数据和注册认证数据。根据一个实施例，注册认证数据包括用户ID、口令、生物识别信息等。根据一个实施例，在询问处理过程中，客户端小程序优选地与信任引擎110通信以保证所选择的用户ID是唯一的。当用户ID非唯一时，信任引擎110可以有利地建议唯一用户ID。客户端小程序收集注册数据并将注册数据例如通过XML文档传输至信任引擎110，更具体地，至交易引擎205。根据一个实施例，用认证引擎215的公钥编码该传输。根据一个实施例，用户在注册处理900的步骤905期间执行单个注册。例如，用户将他或她本身注册为特定人，例如Joe User。当Joe User期望注册为Joe User,Mega公司的CEO时，根据该实施例，Joe User第二次注册，接收到第二个唯一用户ID，并且信任引擎110不将两个身份相关联。根据本发明的另一实施例，注册处理900为单个用户ID提供多个用户身份。从而，在上述示例中，信任引擎110有利地将Joe User的两个身份相关联。如本领域技术人员从此处的公开可以理解的，用户可以具有许多身份，例如，一家之主的JoeUser，慈善基金会成员Joe User，等等。即使用户可以具有多个身份，根据该实施例，信任引擎110优选地仅存储一组注册数据。此外，用户可以根据他们的需要有利地增加、编辑/更新、或删除身份。尽管参考其优选实施例公开了注册处理900，但是本发明不因此被限制。相反，本领域技术人员从此处的公开应理解用于收集注册数据尤其是注册认证数据的多种替换例。例如，小程序可以是基于通用对象模型(COM)的小程序，等等。另一方面，注册处理可以包括分级注册。例如，在最低级的注册中，用户可以通过通信链路125注册而不产生关于他或她身份的文件。根据注册等级的提高，用户使用诸如数字公证之类的可信第三方进行注册。例如，用户可以亲自出现在可信第三方面前，制作诸如出生证明、驾照、军人ID等，以及可信第三方可以有利地在注册提交时包括例如他们的数字签名。可信第三方可以包括实际公证处、政府机构(例如邮局或机动车部)、大公司中注册员工的人力资源人员等。本领域的技术人员从此处的公开应该理解在注册处理900中可能发生多种不同等级的注册。在步骤915处接收注册认证数据之后，交易引擎205使用传统全SSL技术将注册认证数据转发至认证引擎215。在步骤920，认证引擎215使用认证引擎215的私钥解密注册认证数据。此外，认证引擎215使用数据拆分模块对注册认证数据进行数学运算，从而将数据拆分成至少两个独立的不可破译的随机化的数。如上所述，至少两个数可以包括统计随机的数和二进制异或的数。在步骤925，认证引擎215将随机化的数的每个部分转发给数据存储设备Dl至D4之一。如上所述，认证引擎215还可以有利地随机化哪些部分被传递到哪些仓库。通常在注册处理900的过程中，用户还期望发布数字证书，从而他或她可以接收来自加密系统100外部的其他系统的加密文档。如上所述，证书颁发机构115通常根据多种传统标准中的一个或多个标准发布数字证书。通常，数字证书包括每个人都知道的用户或系统的公钥。无论用户是在注册时还是在其他时间请求数字证书，该请求通过信任引擎110传递至认证引擎215。根据一个实施例，该请求包括具有例如用户正确姓名的XML文档。根据步骤935，认证引擎215将该请求传递至加密引擎220，指示加密引擎220生成加密密钥或密钥对。一经请求，在步骤935，加密引擎220生成至少一个加密密钥。根据一个实施例，加密处理模块625生成密钥对，其中一个密钥被用作私钥，以及一个被用作公钥。加密引擎220存储私钥，以及根据一个实施例存储公钥的拷贝。在步骤945中，加密引擎220向交易引擎205传输数字证书请求。根据一个实施例，该请求有利地包括标准化请求，例如，嵌入在例如XML文档中的PKCSlO。数字证书请求可以有利地对应于一个或多个证书颁发机构，以及证书颁发机构要求的一个或多个标准格式。在步骤950，交易引擎205转发该请求至证书颁发机构115，后者在步骤955返回数字证书。返回的数字证书可以有利地为标准化格式，例如PKCS7，或者为一个或多个证书颁发机构115的专有格式。在步骤960中，数字证书被交易引擎205接收，副本被转发至用户，以及用信任引擎110存储副本。信任引擎110存储证书的副本，从而信任引擎110不需要依赖于证书颁发机构115的可用性。例如，当用户期望发送数字证书或第三方请求用户的数字证书时，数字证书请求通常被发送到证书颁发机构115。然而，如果证书颁发机构115正在进行维护或已经成为故障或安全损害的牺牲品，则数字证书可能不可用。在发布加密密钥之后的任何时间，加密引擎220可以有利地采用上述的数据拆分处理800以使得加密密钥被拆分成独立不可破译的随机化的数。类似于认证数据，在步骤965，加密引擎220将随机化的数传送到数据存储设备Dl至D4。本领域技术人员从此处公开应理解，用户可以在注册之后的任何时间请求数字证书。此外，系统之间的通信可以有利地包括全SSL或公钥加密技术。此外，注册处理可以发布来自多个证书颁发机构的多个数字证书，所述证书颁发机构包括信任引擎110内部或外部的一个或多个专有证书颁发机构。如在步骤935至960中所公开的，本发明的一个实施例包括最终存储在信任引擎110上的证书请求。根据一个实施例，因为加密处理模块625发布由信任引擎110使用的密钥，因此每个证书对应于一个私钥。因此，信任引擎110可以有利地通过监视由用户拥有或与用户相关联的证书来提供互用性。例如，当加密引擎220接收加密功能请求时，加密处理模块625可以调查由进行请求的用户所拥有的证书以确定该用户是否拥有与该请求的属性相匹配的私钥。当存在这样的证书时，加密处理模块625可以使用证书或与其相关的公钥或私钥，来执行所请求的功能。当这样的证书不存在时，加密处理模块625可以有利且透明地执行若干动作以试图对缺少适当的密钥进行补救。例如，图9B示出了根据本发明的实施例的多个方面的互用性处理970的流程图，公开上述步骤以保证加密处理模块625使用适当密钥来执行加密功能。如图9B中所示，互用性处理970从步骤972开始，在该处，加密处理模块925确定期望的证书类型。根据本发明的一个实施例，证书的类型可以有利地在加密功能请求或请求者提供的其他数据中指定。根据另一实施例，证书类型可以由请求的数据格式确定。例如，加密处理模块925可以有利地识别该请求对应于特定的类型。根据一个实施例，证书类型可包括一个或多个算法标准，例如，RSA、ELGAMAL等。此夕卜，证书类型可以包括一个或多个密钥类型，例如对称密钥、公钥、诸如256位密钥的强加密密钥、低安全密钥等。此外，证书类型可以包括一个或多个上述算法标准或密钥、一个或多个消息或数据格式、一个或多个数据封装或编码机制(例如Base32或Base64)的升级或替换。证书类型还可以包括与一个或多个第三方加密应用或接口、一个或多个通信协议、或一个或多个证书标准或协议的兼容性。本领域的技术人员从在此的公开应该理解其他差异可能存在于证书类型中，以及如在此所公开的，可以执行这些差异之间的来回转换。一旦加密处理模块625确定证书类型，互用性处理970进行到步骤974，并确定用户是否拥有与在步骤974中确定的类型相匹配的证书。当用户拥有匹配证书时，例如，信任引擎110可以通过例如其先前的存储获得匹配证书，加密处理模块825知道匹配私钥也存储在信任引擎110中。例如，匹配私钥可以被存储在仓库210或仓库系统700中。加密处理模块625可以有利地请求从例如仓库210组装匹配私钥，然后在步骤976，使用匹配私钥执行加密动作或功能。例如，如上所述，加密处理模块625可以有利地执行散列、散列比较、数据加密或解密、数字签名校验或创建、等等。当用户不拥有匹配证书时，互用性处理970进行到步骤978，在这里，加密处理模块625确定用户是否拥有交叉证明证书。根据一个实施例，证书颁发机构之间的交叉证明在第一证书颁发机构确定信任来自第二证书颁发机构的证书时发生。换句话说，第一证书颁发机构确定来自第二证书颁发机构的证书符合一定质量标准，并因此可以被“证明”为等同于第一证书颁发机构本身的证书。交叉证明在证书颁发机构发布例如具有信任等级的证书时变得更复杂。例如，第一证书颁发机构通常基于注册处理中的可靠程度，可以为特定证书提供三个信任等级，而第二证书颁发机构可以提供七个信任等级。交叉证明可以有利地跟踪来自第二证书颁发机构的哪些等级以及哪些证书可以代替来自第一证书颁发机构的哪些等级和哪些证书。当在两个证书颁发机构之间官方和公开地完成上述交叉证明时，彼此的证书和等级的映射通常被称作“链接(chaining)”。根据本发明的另一实施例，加密处理模块625可以有利地开发由证书颁发机构认为一致的那些之外的交叉证明。例如，加密处理模块625可以访问第一证书颁发机构的证书实践声明(certificate practice statement,CPS)或其他公开的政策声明，并且使用例如特定信任等级所需的认证令牌使第一证书颁发机构的证书匹配至另一证书颁发机构的那些证书。当在步骤978中加密处理模块625确定用户拥有交叉证明的证书时，互用性处理970进行到步骤976，并使用交叉证明的公钥、私钥或两者来执行加密动作或功能。可替换地，当加密处理模块625确定用户不拥有交叉证明证书时，互用性处理970进行到步骤980，在这里，加密处理模块625选择发布所请求的证书类型或被交叉证明的证书的证书颁发机构。在步骤982，加密处理模块625确定前面所讨论的用户注册认证数据是否符合所选证书颁发机构的认证要求。例如，如果用户是通过例如回答人口统计学和其他问题在网络上注册的，所提供的认证数据与提供生物识别数据和呈现在例如公证人的第三方面前的用户相比可以建立较低的信任等级。根据一个实施例，上述认证要求可以有利地设置在所选证书颁发机构的CPS中。当用户已经向信任引擎110提供符合所选证书颁发机构的要求的注册认证数据时，互用性处理970进行到步骤984，在这里，加密处理模块825从所选证书颁发机构获取证书。根据一个实施例，加密处理模块625通过遵照注册处理900的步骤945至960来获取证书。例如，加密处理模块625可以有利地使用来自加密引擎220已经可用的一个或多个密钥对的一个或多个公钥来从证书颁发机构请求证书。根据另一实施例，加密处理模块625可以有利地生成一个或多个新的密钥对，以及使用与其对应的公钥来从证书颁发机构请求证书。根据另一实施例，信任引擎110可以有利地包括能够发布一个或多个证书类型的一个或多个证书发布模块。根据该实施例，证书发布模块可以提供上述证书。当加密处理模块625获取到证书，互用性处理970进行到步骤976，使用对应于所获取的证书的公钥、私钥或两者来执行加密动作或功能。当在步骤982中用户没有向信任引擎110提供满足所选证书颁发机构的要求的注册认证数据时，加密处理模块625在步骤986中确定是否存在具有不同认证要求的其他证书颁发机构。例如，加密处理模块625可以寻找具有较低认证要求的证书颁发机构，但仍然发布所选证书或其交叉证明。当存在上述具有较低要求的证书颁发机构时，互用性处理970进行到步骤980并选择该证书颁发机构。可替换地，当没有这样的证书颁发机构存在时，在步骤988，信任引擎110可以要求来自用户的其他认证令牌。例如，信任弓丨擎110可以要求包括例如生物识别数据的新注册认证数据。同样，信任引擎110可以要求用户在可信第三方前出现，并提供适当的认证凭证，例如带着驾照、社会保障卡、银行卡、出生证明、军人ID等出现在公证人面前。当信任引擎110接收到更新的认证数据时，互用性处理970进行到步骤984并获取上述所选的证书。通过上述互用性处理970，加密处理模块625有利地提供不同加密系统之间的无缝、透明的翻译和转换。本领域技术人员从在此的公开应该理解上述互用系统的优点和实施方式。例如，互用性处理970的上述步骤986可以有利地包括下面将更详细描述的信任仲裁的各个方面，其中证书颁发机构在可以特定情况下接受较低等级的交叉证明。此外，互用性处理970可以包括保证标准证书撤销之间的互用性，以及采用标准证书撤销，例如采用证书撤销列表(CRL)、在线证书状态协议(OCSP)等。图10示出了根据本发明的实施例的多个方面的认证处理1000的数据流。根据一个实施例，认证处理1000包括从用户收集当前认证数据并将其与用户的注册认证数据进行比较。例如，认证处理1000在步骤1005处开始，在这里，用户期望与例如卖方执行交易。这样的交易可以包括例如选择购买选项、请求对卖方系统120的受限制区域或装置的访问。在步骤1010，卖方向用户提供交易ID和认证请求。交易ID可以有利地包括192位的量，其具有与128位随机量级联的32位时间戳，或与32位特定于卖方的常量级联的“临时随机数(nonce)”。这样的交易ID唯一地标识该交易，从而模仿交易能够被信任引擎110拒绝。认证请求可以有利地包括特定交易所需的认证等级。例如卖方可以在发布时指定该交易所需的特定可信度。如果不能如下所述地对该可信度进行认证，则除非有用户提升可信度的进一步认证或卖方和服务器之间的认证改变，否则不能发生该交易。这些发布将在下面详细讨论。根据一个实施例，交易ID和认证请求可以有利地由卖方端小程序或其他软件程序生成。此外，交易ID和认证数据的传输可以包括使用传统SSL技术(例如1/2SSL、或换句话说，卖方端认证的SSL)加密的一个或多个XML文档。在用户系统105接收到交易ID和认证请求之后，用户系统105收集来自用户的当前认证数据，可能包括当前生物识别信息。用户系统105在步骤1015使用认证引擎215的公钥来至少加密当前认证数据“B”和交易ID，以及将该数据传输至信任引擎110。该传输优选地包括至少使用传统1/2SSL技术加密的XML文档。在步骤1020，交易引擎205接收该传输，优选地识别URL或URI中的数据格式或请求，并将该传输转发至认证引擎215。在步骤1015和1020中，卖方系统120在步骤1025使用优选的全SSL技术转发交易ID和认证请求至信任引擎110。该通信还可以包括卖方ID，尽管卖方标识还可以通过交易ID的非随机部分被传送。在步骤1030和1035，交易引擎205接收该通信，在审计跟踪中创建记录，以及生成对将从数据存储设备Dl至D4组装的用户的注册认证数据的请求。在步骤1040，仓库系统700将对应于用户的注册认证数据的各部分传输至认证引擎215。在步骤1045，认证引擎215使用其私钥解密该传输，并将注册认证数据与用户提供的当前认证数据进行比较。步骤1045的比较可以优选地应用试探式上下文相关认证，如上面提及并将在下面详细讨论的。例如，如果所接收的生物识别信息没有完美地匹配，则导致较低的信任匹配。在特定实施例中，认证的可信度与交易的性质和用户与卖方的期望被权衡考虑。这也将在下面更详细讨论。在步骤1050，认证引擎215使用步骤1045的比较结果填充认证请求。根据本发明的一个实施例，认证请求被填充有认证处理1000的是/否或真/假结果。在步骤1055，被填充的认证请求返回到卖方供卖方采取行动，例如允许用户完成发起过认证请求的交易。根据一个实施例，确认消息被传递至用户。基于上面的描述，认证处理1000优选地保持敏感数据的安全性，并产生用于维护敏感数据完整性的结果。例如，敏感数据仅在认证引擎215中被组装。例如，注册认证数据不可破译，直到其在认证引擎215中被数据组装模块组装，并且当前认证数据不可破译，直到其被传统SSL技术和认证引擎215的私钥解包装。此外，传输至卖方的认证结果不包括敏感数据，用户可能甚至不知道他或她是否产生了有效的认证数据。尽管参考优选和可替换实施例公开了认证处理1000，本发明不因此被限制。相反，本领域技术人员应该从在此的公开理解认证处理1000的多种替换例。例如，卖方可以有利地由几乎任何请求应用来代替，甚至是那些与用户系统105—起驻留的应用。例如，客户端应用，诸如Microsoft Word，可以使用应用程序接口(API)或加密API (CAPI)来在解锁文件之前请求认证。可替换地，邮件服务器、网络、蜂窝电话、个人或移动计算装置、网络工作站等都可以发出能够被认证处理1000填充的认证请求。事实上，在提供上述可信任的认证处理1000之后，请求应用或装置可以提供对多个电子或计算机装置或系统的访问和使用。此外，认证处理1000可以在认证失败时使用多种替换过程。例如，认证失败可以保持相同的交易ID并请求用户重新输入他或她的当前认证数据。如上所述，使用相同的交易ID使得认证引擎215的比较器能够监视和限制对特定交易的认证尝试的次数，从而创建更安全的加密系统100。此外，认证处理1000可以有利地被使用来开发简洁的单一登录解决方案(singlesign-on solution),例如解锁敏感数据资料库。例如,成功或肯定认证可以为被认证的用户提供自动访问几乎无限多个系统和应用的任何数量的口令的能力。例如，用户的认证可以为用户提供对与多个在线卖方、局域网、各种个人计算装置、因特网业务提供商、拍卖商、投资经纪等相关联的口令、登录、金融凭证等的访问。通过使用敏感数据资料库，用户可以选择非常大且随机的口令，因为不再需要通过联想来记住它们。相反，认证处理1000提供对其的访问。例如，用户可以选择长度为20多位的随机混合符号串，而不是与可记住的数据、姓名等有关的东西。根据一个实施例，与给定用户相关的敏感数据资料库可以有利地存储在仓库210的数据存储设备中，或在仓库系统700中被拆分和存储。根据该实施例，在肯定的用户认证之后，信任引擎HO向进行请求的应用提供所请求的敏感数据，例如适当的口令。根据另一实施例，信任引擎110可以包括用于存储敏感数据资料库的单独系统。例如，信任引擎110可以包括执行数据资料库功能并表现为驻留在上述信任引擎110的前端安全系统“之后”的独立软件引擎。根据该实施例，软件引擎在该软件引擎接收到来自信任引擎110的表示肯定用户认证的信号之后提供所请求的敏感数据。在另一实施例中，数据资料库可以由第三方系统实现。类似于软件引擎实施例，第三方系统可以有利地在第三方系统从信任引擎110接收表示肯定用户认证的信号之后提供所请求的敏感数据。根据另一实施例，数据资料库可以在用户系统105上实现。用户端软件引擎可以有利地在接收到来自信任引擎110的表示肯定用户认证的信号之后提供前述数据。尽管参考可替换实施例公开了前述数据资料库，但是本领域技术人员应该从在此的公开理解多种其他实施方式。例如，特定数据资料库可以包括前述实施例中的部分或所有实施例的多个方面。此外，任何前述数据资料库可在不同时间使用一个或多个认证请求。例如，任何数据资料库可以要求每一个或多个交易、周期性地、每一个或多个会话、每访问一个或多个网页或网站、以一个或多个其他指定间隔、等等，进行认证。图11示出了根据本发明的实施例的多个方面的签名处理1100的数据流。如图11所示，签名处理1100包括类似于前面参考图10所述的认证处理1000的步骤。根据本发明的一个实施例，如下面将进一步具体讨论的，签名处理1100首先认证用户，然后执行若干数字签名功能中的一个或多个。根据另一实施例，签名处理1100可以有利地存储与其相关的数据，诸如消息或文件等的散列。该数据可以有利地被用在审计或任何其他事件中，例如在参与方企图抵赖交易时。如图11中所示，在认证步骤期间，用户和卖方可以有利地对诸如合同之类的消息达成一致。在签名过程中，签名处理1100有利地保证由用户签署的合同与卖方提供的合同相同。因此，根据一个实施例，在认证期间，卖方和用户在传输至认证引擎215的数据中包括他们各自的消息或合同副本的散列。通过仅使用消息或合同的散列，信任引擎110可以有利地存储显著减少的数据量，从而提供更高效以及节省成本的加密系统。此外，所存储的散列可以有利地与尚存疑的文件的散列进行比较，以确定该尚存疑的文件是否与由任何一方签名的文件匹配。这种确定文件是否与和交易相关的一个文件相同的能力提供了附加的证据，其能够用于反对一方抵赖交易的主张。在步骤1103，认证引擎215组装注册认证数据并将其与由用户提供的当前认证数据进行比较。当认证引擎215的比较器指示注册认证数据匹配当前认证数据时，认证引擎215的比较器还将由卖方提供的消息的散列与由用户提供的消息的散列进行比较。因此，认证引擎215有利地保证用户同意的消息与卖方同意的消息相同。在步骤1105，认证引擎215传输数字签名至加密引擎220。根据本发明的一个实施例，该请求包括消息或合同的散列。然而，本领域技术人员从此处的公开应了解加密引擎220实际上可以加密任何类型的数据，包括但不限于视频、音频、生物识别信息、图像、或文本，以形成期望的数字签名。返回到步骤1105，数字签名请求优选地包括通过传统SSL技术传送的XML文档。在步骤1110中，认证引擎215传输请求至每个数据存储设备Dl至D4，从而每个数据存储设备Dl至D4传输与签名方相对应的加密密钥(一个或多个)中它们各自的部分。根据另一实施例，加密引擎220使用上面所述的互用性处理970的部分或所有步骤，从而加密引擎220首先确定要从仓库210或仓库系统700请求的用于签名方的一个或多个适当密钥，以及采取行动来提供适当的匹配密钥。根据另一实施例，认证引擎215或加密引擎220可以有利地请求与签名方相关联并存储在仓库210或仓库系统700中的一个或多个密钥。根据一个实施例，签名方包括用户和卖方中的一个或两者。在这样的情况下，认证引擎215有利地请求对应于用户和/或卖方的加密密钥。根据另一实施例，签名方包括信任引擎110。在该实施例中，信任引擎110证明认证处理1000正确地认证了用户、卖方、或两者。因此，认证引擎215请求信任引擎110的加密密钥，例如属于加密引擎220的密钥，以执行数字签名。根据另一实施例，信任引擎110执行类似数字公证的功能。在该实施例中，签名方包括用户、卖方、或两者，连同信任引擎110。因此，信任引擎110提供用户和/或卖方的数字签名，然后使用其本身的数字签名表示用户和/或卖方已经被正确认证。在该实施例中，认证引擎215可以有利地请求组装对应于用户、卖方或两者的加密密钥。根据另一实施例，认证引擎215可以有利地请求组装对应于信任引擎110的加密密钥。根据另一实施例，信任引擎110执行类似委托书的功能。例如，信任引擎110可以以第三方的名义数字签名该消息。在这种情况下，认证引擎215请求与第三方相关联的加密密钥。根据该实施例，在允许类似委托书的功能之前，签名处理1100可以有利地包括第三方的认证。此外，认证处理1000可以包括检查第三方约束，例如指示何时以及在什么情况下可以使用特定第三方签名的商业逻辑等。基于上面所述，在步骤1110，认证引擎从数据存储设备Dl至D4请求对应于签名方的加密密钥。在步骤1115中，数据存储设备Dl至D4传输与签名方相对应的加密密钥中它们各自的部分至加密引擎220。根据一个实施例,上述传输包括SSL技术。根据另一实施例，上述传输可以有利地使用加密引擎220的公钥被超级加密(super-encrypt)。在步骤1120，加密引擎220组装签名方的上述加密密钥并以其加密该消息，从而形成数字签名(一个或多个)。在签名处理1100的步骤1125，加密引擎220传输数字签名至认证引擎215。在步骤1130，认证引擎215传输填充的认证请求连同散列的消息的副本以及数字签名至交易引擎205。在步骤1135，交易引擎205传输包括交易ID、关于认证是否成功的指示和数字签名的收据(receipt)至卖方。根据一个实施例，上述传输可以有利地包括信任引擎110的数字签名。例如，信任引擎110可以使用其私钥加密收据的散列，从而形成将被附加到至卖方的传输的数字签名。根据一个实施例，交易引擎205还传输确认消息至用户。尽管参考其优选和可替换实施例公开了签名处理1100，但是本发明不因此被限制。相反，本领域技术人员应该从此处的公开了解签名处理1100的多种替换例。例如，卖方可以由用户应用(例如电子邮件应用)来代替。例如，用户可能希望用他或她的数字签名来数字签名特定电子邮件。在这样的实施例中，通过签名处理1100的传输可以有利地仅包括消息的散列的一份副本。此外，本领域技术人员应该从此处的公开理解多种客户端应用可以请求数字签名。例如，客户端应用可以包括文字处理器、电子表格、电子邮件、语音邮件、对受限系统区域的访问，等等。此外，本领域技术人员应该从此处的公开理解签名处理1100的步骤1105至1120可以有利地使用图9B的互用性处理970的部分或全部步骤，从而提供不同加密系统之间的互用性，其中不同加密系统可能例如需要处理不同签名类型的数字签名。图12示出了根据本发明的一个实施例的多个方面的加密/解密处理1200的数据流。如图12中所示，解密处理1200从使用认证处理1000认证用户开始。根据一个实施例，认证处理1000包括认证请求中的同步会话密钥。例如，在传统PKI技术中，本领域技术人员应该理解使用公钥和私钥加密或解密数据是数学密集的，并且可能需要相当多的系统资源。然而，在对称密钥加密系统中或在消息的发送者或接收者共享用于加密和解密消息的单个共同密钥的系统中，数学运算要简单和快速得多。因此，在传统PKI技术中，消息的发送者将生成同步会话密钥，并使用较为简单且较快速的同步密钥系统加密该消息。然后，发送者将使用接收者的公钥加密会话密钥。加密的会话密钥将附加到同步加密的消息，并且两个数据都被发送至接收者。接收者使用他或她的私钥来解密该会话密钥，然后使用该会话密钥来解密该消息。基于上面所述，较简单且较快速的对称密钥系统被用于大部分的加密/解密处理。因此，在解密处理1200中，解密有利地假设同步密钥已经用用户的公钥被加密。因此，如上所述，加密的会话密钥被包括在认证请求中。返回到解密处理1200，在用户已经在步骤1205中被认证之后，认证引擎215将加密的会话密钥转发至加密引擎220。在步骤1210，认证引擎215将请求转发至每个数据存储设备Dl至D4，请求用户的加密密钥数据。在步骤1215，每个数据存储设备Dl至D4传输其各自的加密密钥部分至加密引擎220。根据一个实施例，上述传输使用加密引擎220的公钥被加密。在解密处理1200的步骤1220，加密引擎220组装加密密钥并以其解密会话密钥。在步骤1225，加密引擎转发会话密钥至认证引擎215。在步骤1227，认证引擎215填充认证请求以包括解密的会话密钥，并将填充的认证请求传输至交易引擎205。在步骤1230，交易引擎205将认证请求连同会话密钥转发至进行请求的应用或卖方。然后，根据一个实施例，进行请求的应用或卖方使用该会话密钥来解密被加密的消息。尽管参考其优选和可替换实施例公开了解密处理1200，本领域技术人员从此处的公开应该了解解密处理1200的多种替换例。例如，解密处理1200可以位于同步密钥加密之前并且依赖于全公钥技术。在这样的实施例中，进行请求的应用可以传输整个消息至加密引擎220，或可以使用一些类型的压缩或可逆散列以传输消息至加密引擎220。本领域技术人员从此处的公开也应该理解上述通信可以有利地包括以SSL技术包装的XML文档。加密/解密处理1200还提供文档或其他数据的加密。因此，在步骤1235，进行请求的应用或卖方可以有利地传输对用户公钥的请求至信任引擎110的交易引擎205。该进行请求的应用或卖方进行该请求，是因为进行请求的应用或卖方使用用户的公钥来例如加密将被用来加密文档或消息的会话密钥。如在注册处理900中所述，交易引擎205将用户的数字证书的副本存储在例如大容量存储器225中。因此，在加密处理1200的步骤1240，交易引擎205从大容量存储器225请求用户的数字证书。在步骤1245，大容量存储器225将对应于该用户的数字证书传输至交易引擎205。在步骤1250，交易引擎205将数字证书传输至进行请求的应用或卖方。根据一个实施例，加密处理1200的加密部分不包括用户的认证。这是因为进行请求的卖方仅需要用户的公钥，并且不请求任何敏感数据。本领域技术人员从此处的公开应理解，如果特定用户不具有数字证书，则信任引擎110可以使用注册处理900的部分或全部来生成用于该特定用户的数字证书。然后，信任引擎110可以启动加密/解密处理1200，从而提供适当的数字证书。此外，本领域的技术人员从此处的公开应该理解，加密/解密处理1200的步骤1220和1235至1250可以有利地使用图9B的互用性处理的部分或全部步骤，从而提供在可能例如需要处理加密的不同加密系统之间的互用性。图13示出了根据本发明的另一实施例的多个方面的信任引擎系统1300的简化框图。如图13中所示，信任引擎系统1300包括多个不同的信任引擎1305、1310、1315和1320。为了有利于更全面理解本发明，图13示出了每个信任引擎1305、1310、1315和1320具有交易引擎、仓库和认证引擎。然而，本领域技术人员应该理解，每个交易引擎可以有利地包括参考图1-8公开的元件和通信信道的部分、组合或所有。例如，一个实施例可以有利地包括具有一个或多个交易引擎、多个仓库和多个加密服务器、或其任意组合的信任引擎。根据本发明的一个实施例，每个信任引擎1305、1310、1315和1320在地理上分开，从而例如信任引擎1305可以位于第一位置，信任引擎1310可以位于第二位置，信任引擎1315可以位于第三位置，而信任弓丨擎1320可以位于第四位置。上述地理分开有利地减小了系统响应时间而增加了整个信任引擎系统1300的安全性。例如，当用户登录至加密系统100时，用户可能最靠近第一位置，并且可能期望被认证。如参考图10所述，为了被认证，用户提供当前认证数据，诸如生物识别信息等等，并且当前认证数据与该用户的注册认证数据进行比较。因此，根据一个示例，用户有利地提供当前认证数据至地理上最靠近的信任引擎1305。信任引擎1305的交易引擎1321然后转发当前认证数据至同样位于第一位置的认证引擎1322。根据另一实施例，交易引擎1321转发当前认证数据至信任引擎1310、1315或1320的一个或多个认证引擎。交易引擎1321还请求组装来自例如每个信任引擎1305至1320的仓库的注册认证数据。根据该实施例，每个仓库提供注册认证数据中它的部分至信任引擎1305的认证引擎1322。认证引擎1322然后使用来自例如前两个响应的仓库的加密数据部分，并将注册认证数据组装成被破译的形式。认证引擎1322将注册认证数据与当前认证数据进行比较并返回认证结果至信任引擎1305的交易引擎1321。基于上面所述，信任引擎系统1300使用多个地理上分开的信任引擎1305至1320中最近的一个来执行认证处理。根据本发明的一个实施例，将信息路由至最近的交易引擎可以有利地在运行在用户系统105、卖方系统120或证书颁发机构115中的一个或多个上的客户端小程序处执行。根据一个可替换实施例，可以使用更复杂的判定处理来从信任引擎1305至1320中进行选择。例如，判定可以基于给定信任引擎的可用性、可操作性、连接的速度、负荷、性能、地理接近度、或其组合。以该方式，信任引擎系统1300降低其响应时间同时维持与地理上远离的数据存储设备相关联的安全性优点，例如参考图7所讨论的那些优点，其中在图7中每个数据存储设备存储敏感数据的随机化部分。例如，在例如信任引擎1315的仓库1325处的安全性损害不必然泄露信任引擎系统1300的敏感数据。这是因为仓库1325仅包括不可破译的随机化的数据，该数据在没有更多数据的情况下是完全无用的。根据另一实施例，信任引擎系统1300可以有利地包括多个类似于认证引擎而布置的加密引擎。加密引擎可以有利地执行诸如参考图1-8所公开的加密功能。根据另一实施例，信任引擎系统1300可以有利地用多个加密引擎代替多个认证引擎，从而执行诸如参考图1-8所公开的加密功能。根据本发明的又一实施例，如上所述，信任引擎系统1300可以使用具有认证引擎、加密引擎或两者的部分或所有功能的引擎来代替每个多认证引擎。尽管参考其优选和可替换实施例公开了信任引擎系统1300，本领域的技术人员应该理解，信任引擎系统1300可以包括部分的信任引擎1305至1320。例如，信任引擎系统1300可以包括一个或多个交易引擎，一个或多个仓库、一个或多个认证引擎、或一个或多个加密引擎、或其组合。图14示出了根据本发明的另一实施例的多个方面的信任引擎系统1400的简化框图。如图14所示，信任引擎系统1400包括多个信任引擎1405、1410、1415和1420。根据一个实施例，每个信任引擎1405、1410、1415、和1420包括参考图1_8公开的信任引擎110的部分或全部元件。根据该实施例，当用户系统105、卖方系统120或证书颁发机构115的客户端小程序与信任引擎系统1400通信时，这些通信被发送至每个信任引擎1405至1420的IP地址。此外，每个信任引擎1405、1410、1415和1420的每个交易引擎类似于参考图13公开的信任引擎1305的交易引擎1321而工作。例如，在认证处理过程中，每个信任引擎1405、1410、1415和1420的每个交易引擎传输当前认证数据至其各自的认证引擎，并传输请求以组装存储在每个信任引擎1405至1420的每个仓库中的随机化的数据。图14没有示出所有这些通信，因为这样示出的话就变得过于复杂了。继续认证处理，每个仓库然后将其随机化数据部分传送至每个信任引擎1405至1420的每个认证引擎。每个信任引擎的每个认证引擎使用其比较器来确定当前认证数据是否与每个信任引擎1405至1420的仓库提供的注册认证数据匹配。根据该实施例，每个认证引擎的比较结果然后被传输至其他三个信任引擎的冗余模块。例如，来自信任引擎1405的认证引擎的结果被传输至信任引擎1410、1415和1420的冗余模块。从而类似地，信任引擎1405的冗余模块接收来自信任引擎1410、1415和1420的认证引擎的结果。图15示出了图14的冗余模块的框图。该冗余模块包括比较器，用于接收来自三个认证引擎的认证结果以及将该结果传输至第四个信任引擎的交易引擎。比较器将来自这三个认证引擎的认证结果进行比较，如果有两个结果是一致的，则比较器断定认证结果与两个达成一致的认证引擎的认证结果匹配。该结果然后被传输回对应于与这三个认证引擎不相关联的信任引擎的交易引擎。基于上面所述，冗余模块基于从优选地地理上与该冗余模块的信任引擎相远离的认证引擎接收到的数据确定认证结果。通过提供这样的冗余功能，信任引擎系统1400保证信任引擎1405至1420之一的认证引擎的损害不足以损害该特定信任引擎的冗余模块的认证结果。本领域技术人员应该理解，信任引擎系统1400的冗余模块功能也可以被应用于每个信任引擎1405至1420的加密引擎。然而，这样的加密引擎通信没有在图14中示出以避免复杂。此外，本领域技术人员应该理解，用于图15的比较器的多种可替换的认证结果冲突解决算法适于用在本发明中。根据本发明的另一实施例，信任引擎系统1400可以有利地在加密比较步骤过程中采用冗余模块。例如，上述参考图14和15公开的冗余模块的部分或全部可以有利地在对一方或多方在特定交易期间提供的文档进行散列比较期间实施。尽管已经根据某些优选和可替换实施例描述了上述发明，但是本领域技术人员可以由此处公开显而易见其他实施例。例如，信任引擎110可以发布短期证书，而私有加密密钥被释放给用户某个预定时间段。例如，当前证书标准包括能够被设置为在预定时间量后过期的有效性字段。因此，信任引擎Iio可以向用户释放私钥，其中该私钥在例如24小时内有效。根据这样的实施例，信任引擎110可以有利地发布与特定用户相关联的新的加密密钥对，然后释放该新的加密密钥对的私钥。然后，一旦私有加密密钥被释放，信任引擎110就立即终止这样的私钥的任何内部有效使用，因为其信任引擎110不再保证其安全。此外，本领域技术人员应该意识到，加密系统100或信任引擎110可以包括识别任何类型的装置的能力，所述装置诸如但不限于膝上型电脑、蜂窝电话、网络、生物识别装置、等等。根据一个实施例，这样的识别可以来自于在对特定服务的请求中提供的数据，所述请求诸如对弓I起访问或使用的认证的请求、对加密功能的请求等。根据一个实施例，上述请求可以包括唯一装置标识符，例如处理器ID。可替换地，该请求可以包括具有特定可识别数据格式的数据。例如，移动和卫星电话通常不包括对于完全X509.V3重加密证书(full X509.V3heavy encryption certificates)的处理能力，从而不请求它们。根据该实施例,信任引擎110可以识别所呈现的数据格式的类型，并仅以同样方式响应。在上述系统的其他方面，上下文相关认证可以使用下面将描述的各种技术来提供。上下文相关认证，例如图16中所示的，提供了不仅评估在用户试图认证其本身时发送的实际数据，而且还评估在生成和传递该数据的周围的环境的能力。如下面将描述的，这样的技术也可以支持用户与信任引擎110之间或卖方与信任引擎110之间的特定于交易的信任仲裁。如上所讨论的，认证是证明用户是其所声称的那个人的过程。通常，认证要求向认证权力机构证实一些事实。本发明的信任引擎110代表用户必须向其认证自身的权力机构。用户必须通过知道一些仅该用户应知道的东西(基于知识的认证)、具有一些仅该用户应具有的东西(基于令牌的认证)、或是仅该用户应该是的东西(基于生物识别的认证)来向信任引擎110证实他是他所声称的那个人。基于知识的认证的示例包括但不限于口令、PIN号、或锁组合。基于令牌的认证的示例包括但不限于房间钥匙、物理信用卡、驾照、或特定电话号码。基于生物识别的认证的示例包括但不限于指纹、笔迹分析、面部扫描、手扫描、耳朵扫描、虹膜扫描、血管模式、DNA、语音分析、或视网膜扫描。每种类型的认证都具有特定优点和缺点，并且每种类型提供不同的安全等级。例如，与偶然听到某个人的口令并重复该口令相比，通常较难创建与其他人的指纹匹配的假指纹。每种类型的认证还要求不同类型的数据是认证权力机构所知道的，以便校验使用这种认证形式的人。如在此所使用的，“认证”广义地表示证实某人的身份是他声称他是的那个人的整个过程。“认证技术”表示基于特定的知识、物理令牌、或生物识别读取的特定类型的认证。“认证数据”表示发送至认证权力机构或向其证实以建立身份的信息。“注册数据”表示初始提交给认证权力机构以建立用于与认证数据进行比较的基准的数据。“认证实例(authentication instance)”表示与用认证技术进行认证的尝试相关联的数据。参考上面图10来描述在认证用户的处理中所涉及的内部协议和通信。该处理中发生上下文相关认证的部分出现在图10的步骤1045所示的比较步骤中。该步骤在认证引擎215中发生，并涉及组装从仓库210取回的注册数据410以及将其与用户提供的认证数据进行比较。该处理的一个特定实施例在图16中示出并在下面描述。由用户提供的当前认证数据和从仓库取回的注册数据在图16的步骤1600中被认证引擎215接收。这两个数据集合都可能包含与认证的分离技术有关的数据。在步骤1605，认证引擎215分离与每个单独认证实例相关联的认证数据。这是必要的，从而认证数据与用户的注册数据的适当子集进行比较(例如，指纹认证数据应该与指纹注册数据进行比较，而不是与口令注册数据进行比较)。通常，认证用户涉及一个或多个单独认证实例，取决于用户可用的认证技术。这些方法被注册过程中由用户提供的注册数据所限制(如果用户在注册时没有提供视网膜扫描，他就不能使用视网膜扫描来认证自己)，以及被用户当前可用的手段所限制(例如，如果用户在他当前位置不具有指纹读取器，指纹认证将不可行)。在一些情况下，单个认证实例可能足以认证用户；然而在某些情况下，多个认证实例的组合可以被使用以更加确信地认证特定交易的用户。每个认证实例包括与一种特定认证技术(例如指纹、口令、智能卡等)以及在获取和传递用于该特定技术的数据周围的环境有关的数据。例如，尝试通过口令进行认证的特定实例不仅生成与口令本身有关的数据，还生成与该口令尝试有关的环境数据，被称为“元数据”。该环境数据包括诸如以下的信息:特定认证实例发生的时间、认证信息从其递送的网络地址、以及本领域技术人员所知的可以确定的关于认证数据的来源的任何其他信息(连接的类型、处理器序列号等)。在许多情况下，仅有少量的环境元数据可用。例如，如果用户位于使用代理或网络地址转换或其它掩盖发源计算机地址的技术的网络上，则仅仅可以确定代理服务器或路由器的地址。类似地，在许多情况下，诸如处理器序列号之类的信息将不可用，这是由于所使用的硬件或操作系统的限制、系统的操作者禁用这样的特征、或用户的系统与信任引擎110之间的连接的其他限制。如图16中所示，一旦在认证数据中表示的单独认证实例在步骤1605中被提取和分离，认证引擎215就评估每个实例在表示该用户是其所声称的那个人这方面的可靠性。单个认证实例的可靠性通常基于若干因素来确定。这些可以被成组为跟与认证技术相关联的可靠性有关的因素(其在步骤1610中被评估)和跟所提供的特定认证数据的可靠性有关的因素(其在步骤1815中被评估)。第一组包括但不限于所使用的认证技术的固有可靠性，以及与该方法一起使用的注册数据的可靠性。第二组包括但不限于注册数据与认证实例所提供的数据之间的匹配度以及与该认证实例相关联的元数据。这些因素中的每一个可以独立于其他因素而改变。认证技术的固有可靠性基于冒名顶替者提供其他人的正确数据有多困难，以及认证技术的整体错误率。对于基于口令和知识的认证方法，该可靠性通常相当低，因为不存在任何东西来阻止某人将其口令泄露给另一个人以及阻止该另一个人使用该口令。更复杂的基于知识的系统可能仅具有中等可靠性，这是因为知识可以相当容易地从一个人传到另一个人。基于令牌的认证，诸如具有正确的智能卡或使用特定终端来执行认证，类似地具有由其本身使用的低可靠性，这是因为不能保证正确的人持有该正确的令牌。然而，生物识别技术更固有地可靠，因为其通常难以方便地甚至故意地为其他人提供使用你的指纹的能力。因为破坏生物识别认证技术更加困难，所以生物识别方法的固有可靠性通常高于纯粹基于知识或令牌的认证技术的可靠性。然而，即使生物识别技术也可能具有一些产生错误接受或错误拒绝的情况。这些情况的发生可以由相同的生物识别技术的不同实施方式的不同可靠性反映出来。例如，由一个公司提供的指纹匹配系统可以提供比由另一公司提供的指纹匹配系统更高的可靠性，因为该公司使用更高质量的光学器件或更好的扫描分辨率或一些其他的减少错误接受或错误拒绝的发生的改进。 注意该可靠性可以以不同方式表示。可靠性被期望以某种能够被试探法530和认证引擎215的算法使用以计算每种认证的可信度的衡量标准来表示。表示这些可靠性的一种优选模式是百分比或分数。例如，指纹可以被赋予97%的固有可靠性，而口令可能仅被赋予50%的固有可靠性。本领域的技术人员应该理解这些特定值仅是示例性的，并且可以在具体实施方式
之间改变。评估可靠性必须针对的第二个因素是注册的可靠性。这是上面提及的“分级注册”处理的一部分。该可靠性因素反映在初始注册处理期间提供的标识的可靠性。例如，如果个人以物理地将他们身份的证据出示给公证人或其他政府官员的方式初始注册，并且注册数据在此时被记录和公证，则该数据将比在注册过程中通过网络提供并且仅由数字签名或其他没有真实绑定至个人的信息担保的数据更可靠。具有不同可靠性等级的其他注册技术包括但不限于:在信任引擎110操作者的物理办公室注册；在用户的就业地点注册；在邮局或护照办公室注册；通过附属方或可信方向信任引擎110操作者注册；匿名或笔名注册，其中注册的身份尚不等同于特定的真实个人；以及本领域已知的这样的其他手段。这些因素反映信任引擎110和注册处理期间提供的标识的源之间的信任。例如，如果在提供身份证据的初始处理期间与雇主相关联地执行注册，则该信息可以被认为在公司内部极为可靠，但是可能被政府机构或竞争者认为是较低等级可信。因此，这些其他组织中每一个所操作的信任引擎可以给该注册分配不同的可靠性等级。类似地，通过网络提交但是用相同的信任引擎110由在先前注册过程中提供的其他信任数据认证的另外的数据可以被认为与原始注册数据一样可靠，即使后者数据是通过开放网络提交的。在这样的情况下，后续公证将有效地增加与原始注册数据相关联的可靠性等级。以该方式，例如，通过向一些注册官员证明个人身份与注册数据相匹配，匿名或笔名注册就可以上升为完全注册。上述可靠性因素通常是可以在任何特定认证实例之前确定的值。这是因为他们基于注册和技术而不是实际的认证。在一个实施例中，基于这些因素生成可靠性的步骤包括查找以前确定的用于该特定认证技术和用户注册数据的值。在本发明的一个有利实施例的另一方面，这样的可靠性可以包括在注册数据本身中。以该方式，这些因素连同从仓库210发送的注册数据一起被自动传递至认证引擎215。尽管这些因素通常可以在任何单个认证实例之前确定，但是他们仍然对为用户使用特定认证技术的每个认证实例有影响。此外，尽管这些值可能随着时间改变(例如，如果用户以更可靠的方式重新注册)，但是他们不取决于认证数据本身。相反，与单个特定实例的数据相关联的可靠性因素可能随每个情况而改变。如下所讨论，对于每个新认证，都必须评估这些因素，从而在步骤1815生成可靠性分数。认证数据的可靠性反映了由用户在特定认证实例中提供的数据与在认证注册期间提供的数据之间的匹配。这是认证数据是否匹配于用户声称是其的个人的注册数据的基本问题。通常，当数据不匹配时，用户被认为是没有被成功认证，并且认证失败。被评估的方式可以根据所使用的认证技术而改变。这种数据的比较是由图5中所示的认证引擎215的比较器515功能来实现的。例如，口令的匹配通常以二元(binary)形式评估。换句话说，口令或者是完美匹配，或者是失败匹配。通常不期望接受即使是部分匹配，即口令接近正确口令但不是完全正确。因此，当评估口令认证时，由比较器515返回的认证的可靠性通常是100% (正确)或0%(错误)，而没有中间值的可能。与用于口令的规则相类似的规则通常被应用于基于令牌的认证方法，例如智能卡。这是因为拥有具有类似标识符的智能卡或类似于正确智能卡的智能卡，仍然如同拥有任何其他不正确令牌一样是错误的。因此，令牌也趋向于是二元认证:用户或者具有正确令牌，或者不具有。然而，某些类型的认证数据，诸如问卷和生物识别，通常不是二元认证。例如，指纹可以与参考指纹具有不同程度的匹配。某种程度上，这可能是由于在初始注册或在后续认证过程中获取的数据质量的变化。(指纹可能被弄脏或人可能在特定手指上具有静态愈合的伤疤或烧伤)。在其他情况下，数据可能匹配得不够完美，这是因为信息本身在某种程度上是可变的并且是基于图案匹配。(由于背景噪声、或者录制语音的环境的音响效果、或者由于该人感冒了，而导致语音分析可能像是接近但不完全正确)。最后，在大量数据被比较的情形中，情况可能是大部分数据匹配很好而一些匹配不好。(十个问题的问卷可能导致个人问题中八个正确答案，但是两个不正确答案)。由于这些原因中的任一个，注册数据和用于特定认证实例的数据之间的匹配可能期望由比较器515赋予一个部分匹配值。以该方式，例如，可以假定指纹85%匹配，声纹65%匹配，以及问卷80%匹配。由比较器515产生的测量结果(匹配度)是表示认证是否正确这一基本问题的因素。然而，如上所述，这仅是可用于确定给定认证实例的可靠性的多个因素之一。还注意，即使能够确定某种部分程度的匹配，最终还是期望基于部分匹配来提供二元结果。在一种可替换的操作模式中，也可以基于匹配度是否通过特定的阈值匹配水平将部分匹配当做二元的，即，完美匹配(100%)或失败匹配(0%)。这样的处理可以被用来为否则将产生部分匹配的系统提供简单的通过/失败匹配等级。在评估给定认证实例的可靠性时考虑的另一因素是关于提供用于该特定实例的认证数据的环境。如上所述，环境指的是与特定认证实例相关联的元数据。这可包括但不限于这样的信息:认证者的网络地址，到其能够被确定的程度；认证的时间；认证数据的传输模式(电话线、蜂窝网络等)；以及认证者的系统的序列号。这些因素可以被用来产生通常由用户请求的认证的类型的简档(profile)。然后，该信息可以被用来以至少两种方式评估可靠性。一种方式是考虑用户是否正以与该用户的认证的正常简档相一致的方式请求认证。如果用户正常情况下在工作日(当其工作时)从一个网络地址进行认证请求而在晚间或周末(当其在家时)从一不同的网络地址进行认证请求，那么在工作日期间从家庭地址发生的认证就不那么可靠，因为这是在正常认证简档之外的。类似地，如果用户正常情况下使用指纹生物识别并且在晚间进行认证，则在白天仅使用口令发起的认证就不那么可靠。环境元数据可以被用来评估认证实例的可靠性的另一方法是确定环境提供多少证据来证明认证者就是其所声称的个人。例如，如果认证来自于具有已知是与用户相关联的序列号的系统，则其是良好的环境指示器，指示用户是其声明的用户。相反，如果认证来源于已知在洛杉矶的网络地址而已知用户居住在伦敦时，这就指示，基于其环境，该认证是不可靠的。Cookie或其他电子数据也可能被放置在当用户与卖方系统或信任引擎110交互时由用户使用的系统上。该数据被写入用户的系统的存储器，并且可以包括可以由用户系统上的网络浏览器或其他软件读取的标识。如果允许该数据在会话之间驻留在用户系统上(“持续的cookie”)，其可以在认证特定用户期间作为过去使用过该系统的进一步证据与认证数据一起被发送。事实上，给定实例的元数据，特别是持续的cookie，其本身可以形成一种基于令牌的认证者。一旦基于认证实例的技术和数据的适当可靠性因素如在上面步骤1610和1615中分别描述的那样被生成，它们就被用来产生在步骤1620中提供的认证实例的总可靠性。实现这个的一种方式是简单地将每个可靠性表示为百分数，然后将它们相乘。例如，假设认证数据是从已知是完全符合用户过去的认证简档的用户家庭计算机的网络地址发送的(100%)，并且所使用的技术是指纹识别(97%)，并且初始指纹数据是通过用户的雇主使用信任引擎110登记的(90%)，并且认证数据和注册数据中的原始指纹模板之间的匹配非常好(99%)。则该认证实例的总可靠性可以被计算为这些可靠性的乘积:100%*97%*90%*99%-86.4% 可靠性。这样计算的可靠性表示一个单个认证实例的可靠性。单个认证实例的总可靠性还可以使用不同地对待不同可靠性因素的技术来计算，例如，通过使用将不同权重分配给每个可靠性因素的公式。此外，本领域的技术人员将意识到所使用的实际值可以表示百分比之外的值，并且可以使用非算术系统。一个实施例可以包括由认证请求者使用以便为每个因素设置权重的模块，以及用于建立认证实例的总可靠性的算法。认证引擎215可以使用上述技术及其变型来确定单个认证实例的可靠性，如步骤1620所示。然而，在许多认证情况下，同时提供多个认证实例可能是有用的。例如，当尝试使用本发明的系统认证自身时，用户可以提供用户标识、指纹认证数据、智能卡以及口令。在这样情况下，三个独立的认证实例被提供至信任引擎110供评估。进行到步骤1625，如果认证引擎215确定由用户提供的数据包括多于一个认证实例，则每个实例依次如在步骤1630中所示的被选择以及如上面步骤1610、1615和1620中所述的被评估。注意，所讨论的许多可靠性因素因实例而异。例如，这些技术的固有可靠性很可能不同，在认证数据和注册数据之间提供的匹配度也可能不同。此外，用户可能在不同时间和在不同环境下为这些技术中的每一种技术提供了注册数据，这为这些实例中的每个实例提供不同的注册可靠性。最后，即使这些实例中的每个实例被提交的环境是相同的，这些技术的使用可能每个都不同地适合用户的简档，因此可以被赋予不同的环境可靠性。(例如，用户可能在正常情况下使用其口令和指纹，而不是其智能卡)。因此，这些认证实例中的每个实例的最终可靠性可能彼此不同。然而，通过一起使用多个实例，认证的总可信度趋向于增加。一旦认证引擎已经对认证数据中提供的所有认证实例执行了步骤1610至1620，每个实例的可靠性被用在步骤1635中以评估总的认证可信度。将单个认证实例的可靠性合并成认证可信度的处理可以用各种将所产生的单独可靠性联系起来的方法来建模，也可以处理这些认证技术中的一些认证技术之间的特定相互作用。(例如,诸如多个口令之类的多个基于知识的系统产生的可信度可以小于单个口令和甚至相当弱的生物识别(诸如基本语音分析)的可信度。)认证引擎215可以合并多个同时存在的认证实例的可靠性以生成最终可信度的一种方式是，将每个实例的不可靠性相乘以得到总的不可靠性。不可靠性通常是可靠性的互补百分比。例如，可靠性为84%的技术的不可靠性是16%。产生86%、75%和72%的可靠性的上面所述三个认证实例(指纹、智能卡、口令)分别具有对应的不可靠性(100-86)%、(100-75) %和(100-72) %，或14%、25%和28%。通过将这些不可靠性相乘，我们得到累积不可靠性14%*25%*28%——0.98%的不可靠性，对应于99.02%的可靠性。在另一操作模式中，另外的因素和试探法530可以被应用在认证引擎215中以解释各种认证技术的相互依赖。例如，如果有人已经未经授权地访问了特定家庭计算机，则他们可能也能够访问该地址的电话线。因此，既基于发起电话号码也基于认证系统序列号的认证不会对认证的总可信度增加很多。然而，基于知识的认证大大地独立于基于令牌的认证(即，如果有人窃取了你的蜂窝电话号码或密钥，如果他们不曾知道你的PIN或口令，他们就不再可能知道)。此外，不同的卖方或其他认证请求者可能希望为认证的不同方面不同地加权。这可以包括使用不同的加权因子或用于计算单个实例的可靠性的算法，以及使用不同方式来评估具有多个实例的认证事件。例如，某些类型的交易(例如公司电子邮件系统)的卖方可能期望主要基于试探法和其他默认的环境数据来进行认证。因此，他们可以对跟元数据和其他与认证事件周围的环境相关联的关于简档的信息有关的因素应用高权重。由于除了在工作时间期间登录到正确机器之外不向用户要求别的，因此这种安排可以用来减轻用户在正常操作时间期间的负担。然而，另一卖方可能由于策略决定而给予来自特定技术的认证(例如指纹匹配)以最重的权重，其中该策略决定是，这种技术对于该特定卖方的目的而言最适于认证。在一种操作模式中，这些不同的权重可以由认证请求者在生成认证请求时定义，并与认证请求一起发送至信任引擎110。在另一操作模式中，这样的选项也可以在认证请求者的初始注册过程中被设置为优选项并存储在认证引擎中。一旦认证引擎215产生所提供的认证数据的认证可信度，该可信度就被用来在步骤1640中完成认证请求，并且该信息从认证引擎215转发至交易引擎205，以便包括在至认证请求者的消息中。上述处理仅是示例性的，本领域的技术人员应该理解所述步骤不需要以所示的顺序执行，或者仅希望执行某些步骤，或者可以期望步骤的多种组合。此外，如果环境允许，某些步骤，例如对所提供的每个认证实例的可靠性的评估，可以彼此并行执行。在本发明的另一方面，提供了一种方法以适应当由上述处理产生的认证可信度不能满足卖方或要求认证的其他方所需的信任等级时的情况。在诸如在所提供的可信度和所期望的信任等级之间存在差距的情况下，信任引擎110的操作员能够为一方或双方提供用于提供替换数据或要求的机会以弥补该信任差距。该处理在这里将被称作“信任仲裁”。信任仲裁可以在如上面参考图10和11所述的加密认证的框架中发生。如在此所示，卖方或其他方将请求与特定交易相关联的特定用户的认证。在一种情况下，卖方简单地请求认证，或者肯定或者否定，并且在接收到来自用户的适当数据之后，信任引擎110将提供这样的二元认证。在诸如这些的情况下，为了保证肯定认证所需要的可信度是基于信任引擎110中设置的优选项而确定的。然而，卖方可能要求特定的信任等级以完成特定交易也是有可能的。所要求的等级可以包括在认证请求中(例如，认证该用户为98%的可信度)，或可以由信任引擎110基于与交易相关联的其他因素确定(即认证该用户为适于该交易)。一个这样的因素可能是交易的经济价值。对于具有较大经济价值的交易，可能需要较高的信任度。类似地，对于具有高风险度的交易，可能需要高信任度。相反，对于或者低风险或者低价值的交易，卖方或其他认证请求者可能要求低的信任等级。信任仲裁的处理发生在图10的步骤1050中信任引擎110接收认证数据的步骤与图10的步骤1055中将认证结果返回到卖方的步骤之间。在这些步骤之间，如图17所示，发生导致信任等级评估和可能的信任仲裁的处理。在执行简单的二元认证的情况下，如图17所示的处理减少为使交易引擎205直接比较所提供的认证数据和被识别的用户的注册数据，如上参考图10所述，将任何不同标记为否定认证。如图17所示，在步骤1050中接收数据之后的第一步骤是在步骤1710中交易引擎205确定该特定交易的肯定认证所需的信任等级。该步骤可以由若干不同方法中的一种来执行。所需的信任等级可以由认证请求者在进行认证请求时指定给信任引擎110。认证请求者还可以事先设置优选项，其被存储在仓库210或可由交易引擎205访问的其他存储器中。该优选项然后可以在每次由该认证请求者进行认证请求时读取和使用。该优选项还可以与特定用户相关联作为安全性度量，使得总是需要特定的信任等级来认证该用户，用户优选项存储在仓库210或其他可由交易引擎205访问的存储介质中。所需的等级也可以由交易引擎205或认证引擎215基于在认证请求中提供的信息而获得，所述信息诸如要认证的交易的价值和风险等级。在一种操作模式中，在生成认证请求时所使用的策略管理模块或其他软件被用来规定认证该交易所需的信任度。这可以被用来提供在基于在策略管理模块中规定的策略而赋予所需信任等级时要遵循的一系列规则。对于这样的模块，一种有利的操作模式是与卖方的web服务器合并以适当地确定使用卖方的web服务器启动的交易所需的信任等级。以该方式，来自用户的交易请求可以被赋予与卖方的策略一致的所需信任等级，并且这样的信息可以连同认证请求一起被转发至信任引擎110。所需的信任等级与卖方想要的该认证个体事实上就是他将自己标识为的那个人的确定度有关。例如，如果交易是卖方想要普通确定度的交易——因为货物是易手，则卖方可能要求85%的信任等级。对于卖方仅是认证用户以允许他观看会员专用内容或在聊天室享有特权，则负面风险很小以至卖方仅要求60%的信任等级。然而，为了订立价值几万美金的生产合同，卖方可能要求99%或更高的信任等级。该要求的信任等级代表用户必须认证自己以便完成该交易的衡量标准。如果所要求的信任等级例如是85%，则用户必须向信任引擎110提供足以使信任引擎110具有85%信心认为该用户是他们所声称的那个用户的认证。这是在该要求的信任等级和认证可信度之间的平衡，其或者产生肯定认证(令卖方满意)，或者产生信任仲裁的可能。如图17所示，在交易引擎205接收所要求的信任等级后，在步骤1720中将所要求的信任等级与认证引擎215为当前认证所计算的认证可信度(如图16所讨论的)进行比较。如果在步骤1730中认证可信度高于交易所要求的信任等级，则处理进行到步骤1740，由交易引擎205产生对于该交易的肯定认证。带有这个意思的消息然后被插入认证结果中并通过交易引擎205返回至卖方，如步骤1055中所示(见图10)。然而，如果在步骤1730中认证可信度不能满足所要求的信任等级，则当前认证存在信任差距，并且在步骤1750中进行信任仲裁。下面将参考图18更全面地描述信任仲裁。如下所述的该处理在信任引擎110的交易引擎205中发生。因为执行信任仲裁不需要认证或其他加密操作(除了交易引擎205和其他部件之间的SSL通信所需的)，该处理可以在认证引擎215的外部执行。然而，如下所讨论的，认证数据或其他加密或认证事件的任何重新评估都将要求交易引擎205重新提交适当数据至认证引擎215。本领域的技术人员应该意识到，信任仲裁处理可以可替换地被构造成部分或全部在认证引擎215本身中发生。如上所述，信任仲裁是信任引擎110调解卖方和用户之间的协商以尝试酌情保证肯定认证的处理。如在步骤1805中所示，交易引擎205首先确定当前状态是否适于信任仲裁。这可以基于认证的环境来确定，例如，如下面将进一步讨论的，基于该认证是否已经经过多次仲裁循环，以及基于卖方或用户的优选项。在仲裁不可能的环境下，处理进行到步骤1810，在此交易引擎205生成否定认证，然后将其插入在步骤1055 (见图10)中发送至卖方的认证结果中。一个可以被有利地使用以防止认证无限期待定的限制是设置从初始认证请求开始的超时周期。以该方式，任何在该期限内未被肯定认证的交易被拒绝进一步仲裁并被否定认证。本领域的技术人员应该意识到，这样的期限可以根据交易的环境以及用户和卖方的期望而改变。也可以基于在提供成功认证时可进行的尝试次数来设置多种限制。这样的限制可以由如图5所示的尝试限制器535来处理。如果在步骤1805中没有禁止仲裁，则交易引擎205将参与与交易一方或双方的协商。如在步骤1820中所示的，交易引擎205可以发送消息至用户以请求某种形式的附加认证，以便提升所产生的认证可信度。最简单的形式，这可以简单地表明认证不足。也可以发送产生一个或多个另外的认证实例以改进认证的总可信度的请求。如果用户在步骤1825提供一些另外的认证实例，则交易引擎205将这些认证实例增加到用于交易的认证数据并将其转发至认证引擎215，如步骤1015中所示(见图10)，并基于之前已有的该交易的认证实例和新提供的认证实例重新评估该认证。一种附加的认证类型可以是来自信任引擎110的请求在信任引擎110操作者(或可信的同事)与用户之间进行某种形式的人与人的联系(例如通过电话)的请求。该电话或其他非计算机认证可以被用来提供与该个人的个人联系以及进行基于认证的某种形式的问卷。这还给出校验发起的电话号码和潜在的在用户打进电话时对其进行语音分析的机会。即使不能提供另外的认证数据，与用户的电话号码相关联的附加情境可以提高认证情境的可靠性。基于该电话的任何修订的数据或环境都被提供至信任引擎110，供考虑认证请求时使用。此外，在步骤1820，信任引擎110可以为用户提供购买保险的机会，以有效地购买更确信的认证。信任引擎110的操作者有时仅希望在认证的可信度高于开始的一定阈值的情况下使这样的选项可用。事实上，这种用户侧保险是信任引擎110在认证满足信任引擎110对于认证的正常所需信任等级但是不满足卖方对于该交易所要求的信任等级时担保用户的方式。以该方式，用户仍可以成功地认证至卖方所要求的非常高的等级，即使他仅仅具有产生足以用于信任引擎110的可信度的认证实例。信任引擎110的该功能允许信任引擎110为被认证为满足信任引擎110而不满足卖方的人担保。这类似于由公证员执行的功能，即，将其签名添加至文档以向后面读取该文档的人表明其签名出现在文档上的人就是事实上签名的人。公证员的签名证明用户签名的动作。以相同的方式，信任引擎提供交易人就是他们所声称的人的指示。然而，因为信任引擎110人为地提升由用户提供的可信度，因此，对于信任引擎110操作者来说存在较大风险，这是因为用户实际上没有达到卖方所要求的信任等级。保险的费用被设计为抵消信任引擎110 (其可以有效地公证用户的认证)的错误肯定认证的风险。用户付款给信任引擎110操作者以承担认证至高于实际已提供的可信度的风险。因为这样的保险系统允许某个人从信任引擎110有效购买较高信任评级，所以卖方和用户可能都希望防止在某些交易中使用用户侧保险。卖方可能希望将肯定认证限制到他们知道实际认证数据支持他们所需的可信度的情况，因而可能指示信任引擎110不允许用户侧保险。类似地，为了保护他的在线身份，用户可能希望防止在其帐户上使用用户侧保险，或可能希望对于没有保险时的认证可信度高于一定限度的情况限制该保险的使用。这可以被用作安全措施以防止有人偷听口令或盗取智能卡并使用它们来错误地认证为低的可信度，然后购买保险来产生非常高的(错误的)可信度。在确定是否允许用户侧保险时可以评估这些因素。如果在步骤1840中用户购买保险，则在步骤1845中，认证可信度基于所购买的保险被调整，以及在步骤1730中，认证可信度和所要求的信任等级再次被比较(见图17)。处理从这里继续，并且可能进行到步骤1740中的肯定认证(见图17)或回到步骤1750中的信任仲裁处理，以便进一步仲裁(如果允许)或在进一步仲裁被禁止的情况下进行步骤1810中的否定认证。除了在步骤1820中发送信息至用户之外，交易引擎205还在步骤1830中发送消息至卖方，表示待定认证目前低于所要求的信任等级。该消息还向卖方提供关于如何继续进行的各种选项。这些选项之一是简单地通知卖方当前认证可信度是什么以及询问卖方是否希望维持其当前未满足的所要求信任等级。这样是有好处的，因为在一些情况下，卖方可能具有用于认证该交易的独立方式，或者可能已经使用默认的一组要求，其通常导致初始规定的所需等级高于其手边的特定交易实际需要的等级。例如，标准作法可能期望该卖方的所有进入的购买订单交易都满足98%的信任等级。然而，如果订单是近来通过电话在卖方和长期顾客之间讨论的，并且然后马上认证该交易，但是仅达到93%可信度，则卖方可能希望简单地降低对于该交易的接受阈值，因为电话有效地向卖方提供了附加认证。在某些情况下，卖方可能愿意降低其所要求的信任等级，但是不是一直降低到当前认证的可信度。例如，上述示例中的卖方可能认为在该订单之前的电话可以值得所需信任度减少4%，然而，这还是大于由用户产生的93%的可信度。如果在步骤1835中卖方不调节其所要求的信任等级，则通过认证产生的认证可信度和所要求的信任等级在步骤1730中被比较(见图17)。如果可信度现在超过了所要求的信任等级，则在步骤1740中在交易引擎205中可以生成肯定认证(见图17)。如果没有超过，则如果允许的话，可以如上所述地尝试进一步仲裁。
除了请求调节所要求的信任等级，交易引擎205还可以向请求认证的卖方提供卖方侧保险。该保险起到类似于上述用户侧保险的目的。然而，在这里，当接受认证中的较低信任等级时，保险的费用对应于由卖方承担的风险，而不同于在认证高于所产生的实际认证可信度时，费用对应于由信任引擎110所承担的风险的情况。代替仅减低他们实际所要求的信任等级，卖方可以选择购买保险以使其避免与在认证用户时的较低信任等级相关联的其它风险。如上所述，对于卖方来说，仅仅在现有认证已经高于某个阈值的情况下考虑购买这样的保险来弥补信任差距是有利的。提供这样卖方侧保险使得卖方能够选择:直接降低他的信任要求而无需他的附加花费，自己承担错误认证的风险(基于所要求的较低信任等级)；或者为认证可信度和其要求之间的信任差距购买保险，使信任引擎110操作者承担已提供的较低可信度的风险。通过购买保险，卖方有效地保持其高的信任等级要求；因为错误认证的风险被转移到信任引擎110操作者。如果在步骤1840中卖方购买保险，则在步骤1730中比较认证可信度和所要求的信任等级(见图17)，并且处理如上所述地继续。注意，用户和卖方也可以都响应来自信任引擎110的消息。本领域技术人员应该意识到存在多种能够处理这样的情况的方法。处理多个响应的可能性的一种有利模式是简单地以先到先服务的方式对待响应。例如，如果卖方以降低所要求的信任等级作为响应，并且紧跟其后用户也购买了保险来提高他的认证等级，则认证首先基于来自卖方的降低的信任要求而被重新评估。如果认证现在是肯定的，则用户的保险购买被忽略。在另一种有利的操作模式中，用户可能仅被收取满足新的降低的卖方信任要求所需的保险等级的费用(如果即使使用降低的卖方信任要求，仍然存在信任差距)。在为认证设置的时限之内，如果没有来自任一方的响应在步骤1850的信任仲裁处理期间被接收到，则在步骤1805中重新评估仲裁。这就有效地再次开始仲裁处理。如果时限结束或其他情况阻止在步骤1805中的进一步仲裁，则由交易引擎205在步骤1810中生成否定认证，并在步骤1055 (见图10)中返回至卖方。如果不是，则新消息可以发送至用户和卖方，并且处理可以根据需要被重复。注意，对于某些类型的交易，例如，对文档进行数字签名，其不是交易的一部分，可能不一定存在卖方或其他第三方；因此，该交易主要是在用户和信任引擎110之间。在这样的情况下，信任引擎110将具有其本身要求的信任等级，其必须被满足以生成肯定认证。然而，在这样的情况下，信任引擎110通常不希望向用户提供保险以使他增加他自己的签名的可信度。上面所述的以及在图16-18中示出的处理可以使用如上参考信任引擎110所述的各种通信模式来执行。例如，消息可以是基于网络的，并使用信任引擎110与实时下载到在用户或卖方系统上运行的浏览器的小程序之间的SSL连接来发送。在替换的操作模式中，用户和卖方可以使用某些专用应用程序，其有助于这样的仲裁和保险交易。在另一替换的操作模式中，可以使用安全电子邮件操作来调解上述仲裁，从而允许延迟的评估和认证批处理。本领域的技术人员应该理解，可以使用适合于环境和卖方的认证要求的不同的通信模式。下面参考图19的说明描述结合了上述本发明各个方面的范例交易。该示例示出了由信任引擎110调解的在用户和卖方之间的整个处理。尽管上面具体描述的各个步骤和部件可以被用来执行下面的交易，但是所描述的处理集中在信任引擎110、用户和卖方之间的相互作用。在步骤1900，当用户在线观看网页时填写卖方的网站上的订单时，交易开始。用户希望将该使用他的数字签名来签名的订单提交至卖方。为了实现该目的，在步骤1905，用户将订单和其签名请求一起提交至信任引擎110。用户还提供将如上所述用于认证其身份的认证数据。在步骤1910，信任引擎110如上所述地将认证数据与注册数据进行比较，如果产生肯定认证，则将用该用户的私钥签名的订单的散列连同订单本身一起转发至卖方。在步骤1915，卖方接收该签名的订单，然后在步骤1920，卖方将生成发货单(invoice)或其他与将进行的购买有关的合同。在步骤1925，该合同连同签名请求被发送回用户。在步骤1930，卖方还向信任引擎110发送对该合同交易的认证请求，包括将由双方签名的合同的散列。为了使合同能够被双方数字签名，卖方还包括其本身的认证数据，从而如有必要，卖方在该合同上的签名还可以在以后被校验。如上所讨论的，信任引擎110然后校验卖方提供的认证数据以确认卖方的身份，以及如果在步骤1935中该数据产生肯定认证，则在从用户接收到数据时继续步骤1955。如果卖方的认证数据不与卖方的注册数据匹配至期望程度，则返回消息至卖方以请求进一步认证。如上所述的，如有必要，在此可以执行信任仲裁，以便卖方向信任引擎110成功认证其本身。在步骤1940，当用户接收到该合同时，他检查该合同，在步骤1945生成认证数据以便在合同可接受的情况下签署该合同，然后在步骤1950发送合同的散列和他的认证数据至信任引擎110。在步骤1955，信任引擎110校验该认证数据，并且如果认证良好，则如下所述地继续处理该合同。如上参考图17和18所述，信任仲裁可以酌情执行以弥补在认证可信度和交易所要求的认证等级之间的任何信任差距。在步骤1960，信任引擎110使用用户的私钥签署合同的散列，并将该已签名的散列发送至卖方，其中以其自己的名义签署完整消息，即，包括用信任引擎110的私钥510加密的完整消息(包括用户的签名)的散列。在步骤1965中，该消息被卖方接收。该消息代表已签名的合同(用用户的私钥加密的合同的散列)以来自信任引擎110的收据(用信任引擎110的私钥加密的、包括已签名的合同的消息的散列)。在步骤1970中，信任引擎110类似地准备具有卖方的私钥的合同的散列，并将由信任引擎110签名的该合同的散列转发至用户。这样，在步骤1975，用户也接收到一份由卖方签名的合同的副本，以及由信任弓丨擎110签名的关于该已签名的合同的交付的收据。除了上面所述，本发明的另一方面提供了加密服务提供者模块(SPM)，其可以用于客户端应用以作为用于访问由上述信任引擎110提供的功能的手段。提供这样的服务的一种有利方式是加密SPM作为中介实现第三方应用编程接口(API)与可通过网络或其他远程连接来访问的信任引擎110之间的通信。下面参考图20描述范例性的加密SPM。例如，在典型的系统上，多个API对于程序员可用。每个API提供一组函数调用，其可以被运行在系统上的应用程序2000调用。提供适于加密功能、认证功能和其他安全功能的编程接口的API的示例包括由微软提供的使用其Windows操作系统的加密API(CAPI)2010、以及由IBM、Intel和The Open Group的其他成员提议的通用数据安全结构(CDSA)。在下面的讨论中将使用CAPI作为示例性安全API。但是，所述的加密SPM可以使用CDSA或本领域已知的其他安全API。在调用加密功能时，该API由用户系统105或卖方系统120使用。包括在这些功能中的可能是与执行各种加密操作相关联的请求，诸如用特定私钥加密文档、签名文档、请求数字证书、校验已签名的文档上的签名、以及如在此所述或本领域技术人员已知的这类其他的加密功能。这样的加密功能通常在CAPI2010所位于的系统处本地地执行。这是因为通常所调用的功能需要使用本地用户系统105的资源(例如，指纹读取器)或用在本地机器上执行的库来编程的软件功能。对这些本地资源的访问通常由如上所述的一个或多个服务提供者模块(SPM) 2015,2020提供，这些模块提供执行加密功能所使用的资源。这样的SPM可以包括软件库2015以执行加密或解密操作，或包括能够访问专用硬件的驱动器和应用程序2020，例如生物识别扫描装置。以与CAPI2010提供可由系统105的应用程序2000使用的功能差不多的方式，SPM2015、2020向CAPI提供对与系统上可用的服务相关联的较低等级的功能和资源的访问。根据本发明，可以提供一种加密SPM2030，其能够访问由信任引擎110提供的加密功能，并且能够通过CAPI2010使这些功能对于应用程序2000可用。不同于CAPI2010仅能够通过SPM2015、2020访问本地可用的资源的实施例，在此所述的加密SPM2030能够向位于远程的、网络可访问的信任引擎110提交加密操作请求以执行期望的操作。例如，如果应用程序2000需要加密操作，例如签署文档，则应用程序2000对适当的CAPI2010函数进行函数调用。CAPI2010随后执行该函数，以使用由SPM2015、2020和加密SPM2030为其提供的资源。在数字签名功能的情况下，加密SPM2030将生成将通过通信链路125发送至信任引擎110的适当请求。发生在加密SPM2030和信任引擎110之间的操作是与任何其他系统和信任引擎110之间可能的操作相同的操作。然而，这些功能通过CAPI2010被有效地提供至用户系统105，从而在用户系统105本身看来它们是本地可用的。然而，不同于一般的SPM2015、2020，这些功能是在远程信任引擎110上执行的，并且结果响应于适当的请求通过通信链路125中继到加密SPM2030。加密SPM2030使得原本可能不可用于用户系统105或卖方系统12的大量操作对于用户系统105或卖方系统120可用。这些功能包括但不限于:加密和解密文档；发布数字证书；文档的数字签名；校验数字签名；以及对于本领域技术人员显而易见的其他操作。在另一实施例中，本发明包括用于在任何数据集上执行本发明的数据安全方法的完整系统。本发明的该计算机系统包括数据拆分模块，其包括图8中所示并在此描述的功能。在本发明的一个实施例中，数据拆分模块(有时在此被称为安全数据解析器)包括解析程序或软件套件，其包括数据拆分、加密和解密、重建或重新组装功能。该实施例还可以进一步包括一个数据存储设备或多个数据存储设备。数据拆分模块或安全数据解析器包括跨平台软件模块套件，其集成在电子基础结构中，或作为需要其数据元素极为安全的任何应用程序的插件。该解析处理对任何类型的数据集、以及对任何和所有文件类型进行操作，或在数据库中对该数据库中的任何数据行、列或单元进行操作。
在一个实施例中，本发明的解析处理可以以模块化的分层形式来设计，并且任何加密处理都适于用在本发明的处理中。本发明的解析和拆分处理的模块化层级可以包括但不限于:1)加密拆分，分散并安全存储在多个位置；2)加密，加密拆分，分散并安全存储在多个位置；3)加密，加密拆分，加密每份，然后分散并安全存储在多个位置；以及4)加密，力口密拆分，用不同于在第一步骤中使用的加密类型加密每份，然后分散并安全存储在多个位置。在一个实施例中，所述处理包括根据生成的随机数的内容或密钥来拆分数据，以及对在要保护的数据的拆分的加密中使用的密钥执行相同的加密拆分，以形成两个或更多部分或份的解析和拆分数据，并且在一个实施例中优选地形成四个或更多部分的解析和拆分数据，加密所有部分，然后将这些部分分散并存回至数据库，或将它们重新放置到任何指定的装置，这些装置是固定或可移动的，取决于请求者对保密性和安全性的要求。可替换地，在另一实施例中，加密可以在由拆分模块或安全数据解析器拆分数据集之前发生。如在此实施例中描述的那样被处理的原始数据被加密和混乱(obfuscate)并且被保护。如果希望，加密元素的分散事实上可以在任何地方，包括但不限于单个服务器或数据存储装置，或在分开的数据存储设备或装置之间。在一个实施例中，加密密钥管理可以被包括在软件套件中，或者在另一实施例中，可以集成在已有基础结构或任何其他期望位置中。加密的拆分(加密拆分，cryptosplit)将数据划分成N份。该划分可以基于任何大小的数据单元，包括单个位、多个位、字节、千字节、兆字节或更大的单元，以及预定或随机生成的数据单元大小的任何模式或组合。基于随机或预定一组值，这些单元也可以具有不同的大小。这意味着数据可以被看做是这些单元的序列。以该方式，数据单元的大小本身可以使得数据更安全，例如，通过使用数据单元大小的一个或多个预定或随机生成的模式、序列或组合。单元然后(随机地或以预定的一组值)被分配成N份。该分配也可以包括打乱各份中的单元的顺序。本领域的普通技术人员应该容易理解将数据单元分成多个份可以根据多种可能的选择来执行，包括但不限于固定大小、预定大小、或预定或随机生成的数据单元大小的一种或多种组合、模式或序列。这种加密的拆分处理或加密拆分的一个示例将考虑数据的大小为23字节，数据单元大小被选择为I字节，以及被选择的份数是4。每个字节将被分配至这4份之一。假设随机分配，密钥可能被得到以创建具有23个随机数(rl，r2, r3至r23)的序列，每个随机数具有对应于4份的在I和4之间的值。每个数据单元(在该示例中有23个单独字节的数据)与对应于4份之一的23个随机数之一相关联。通过将数据的第一字节置于份号rl、字节2置于份r2、字节3置于份r3、直到数据的第23个字节置于份r23来将数据的各字节分配成4份。本领域的普通技术人员容易理解多种其他可能步骤和步骤的组合和序列，包括数据单元的大小，可以被应用在本发明的加密拆分处理中，并且上述示例是加密拆分数据的一种处理的非限制性描述。为了重新创建原始数据，将执行相反操作。在本发明的加密拆分处理的另一实施例中，加密拆分处理的一个选项是提供份的足够冗余，从而仅需要份的子集来重新组装或恢复数据至其原始或可用形式。作为非限制示例，加密拆分可以作为“4中3个”加密拆分来执行，从而4份中仅3份是必要的以重新组装或恢复数据至其原始或可用形式。这也被称为“N中M个加密拆分”，其中N是份的总数，以及M至少比N小I。本领域的技术人员应该理解在本发明的加密拆分处理中存在创建该冗余的多种可能性。在本发明的加密拆分处理的一个实施例中，每个数据单元被存储在两份中，主份和备用份。使用上述的“4中3个”加密拆分处理，任何一份可以缺少，由于仅需要总计4份中的3份，所以这足以重新组装或恢复没有缺少数据单元的原始数据。如在此所述的，生成对应于多个份之一的随机数。随机数与数据单元相关联，并基于密钥存储在对应的份中。在该实施例中，使用一个密钥来生成主份和备用份随机数。如在此所述的，对于本发明的加密拆分处理，生成等于数据单元的数量的从O至3的一组随机数(也称作主份号)。然后生成等于数据单元的数量的从I至3的另一组随机数(也称作备用份号)。每个数据单元然后与一个主份号和一个备用份号相关联。可替换地，可以生成小于数据单元数量的一组随机数，但是这可能降低敏感数据的安全性。主份号被用于确定数据单元被存储在哪个份中。备用份号与主份号结合以创建O和3之间的第三份号，并且该号被用于确定数据单元被存储在哪个份中。在该示例中，确定第三份号的等式是:(主份号+备用份号)M0D4=第三份号。在上述实施例中，主份号在O和3之间以及备用份号在I和3之间确保第三份号不同于主份号。这就导致数据单元存储在两个不同份中。本领域的技术人员容易理解除了在此公开的实施例，存在多种执行冗余加密拆分和非冗余加密拆分的方法。例如，在每份中的数据单元可以使用不同算法被打乱。这种数据单元打乱例如可以在原始数据被拆分成数据单元时、或在数据单元被置于份中之后、或在份满了之后执行。在此描述的各种加密拆分处理和数据打乱处理，以及本发明的加密拆分和数据打乱方法的所有其他实施例可以在任何大小的数据单元上执行，包括但不限于，与单个位一样小、多位、字节、千字节、兆字节或更大。执行在此所述的加密拆分处理的源代码的一个实施例的一个示例是:DATA [1:24]-具有将被拆分的数据的字节数组SHARES
_2维数组，每行代表份之一
RANDOM [1:24]-在0..3范围内的数组随机数SI = I ；S2 = I ；S3 = I ；S4 = I ；
权利要求
1.一种用于管理加密密钥的方法，所述方法包括: 从第一接口接收管理远离所述第一接口存储的至少一个加密密钥的请求； 将所述请求从第一接口格式转换为公共接口格式； 通过至少校验所述请求是从授权源发起的来认证所述请求；以及 执行转换后的具有所述公共接口格式的请求。
2.根据权利要求1所述的方法，其中，执行转换后的请求包括取回所述至少一个加密密钥。
3.根据权利要求1所述的方法,其中，执行转换后的请求包括生成所述至少一个加密密钥。
4.根据权利要求1所述的方法，其中，执行转换后的请求包括删除所述至少一个加密密钥。
5.根据权利要求1所述的方法，其中，执行转换后的请求包括在密钥存储器中存储所述至少一个加密密钥。
6.根据权利要求1所述的方法，其中，执行转换后的请求包括在可移动介质上存储所述至少一个加密密钥。
7.根据权利要求1所述的方法，进一步包括使用所述至少一个加密密钥来保护数据集，其中保护所述数据集包括: 使用所述至少一个加密密钥来加密所述数据集； 生成随机或伪随机值； 至少部分基于所述随机或伪随机值，将所述数据集中的加密数据分配成两份或更多份；以及 将所述两份或更多份分开存储在至少一个数据仓库中。
8.根据权利要求7所述的方法，其中，将所述两份或更多份分开存储在至少一个数据仓库中包括将所述两份或更多份存储在至少两个地理上分开的数据仓库中。
9.根据权利要求1所述的方法，进一步包括将所执行的请求的至少一个返回参数从公共接口格式转换为第一接口格式。
10.根据权利要求9所述的方法，其中，所执行的请求的所述至少一个返回参数包括至少一个加密密钥。
11.根据权利要求9所述的方法，进一步包括通过安全通信通道将所述至少一个返回参数传输至所述第一接口。
12.根据权利要求1所述的方法，其中，认证所述请求包括执行认证协议或加密握手。
13.根据权利要求1所述的方法，其中，认证所述请求包括校验与所述请求相关联的加密签名。
14.根据权利要求1所述的方法，其中，认证所述请求包括验证认证令牌。
15.根据权利要求14所述的方法，其中，验证认证令牌包括实施与所述认证令牌相关联的截止日期或截止时间。
全文摘要
提供了一种用于管理加密密钥的公共接口。管理加密密钥的请求可以以第一接口格式被接收，被转换为公共接口格式，然后远离第一接口被执行。返回参数然后可以从公共接口格式转换为与第一接口兼容的格式并被安全地传送至第一接口。加密密钥可以与安全数据解析器联合使用，其中安全数据解析器通过将数据集中的数据随机分配成两个或更多个份来保护数据。
文档编号H04L9/08GK103152170SQ201310021829
公开日2013年6月12日 申请日期2008年9月12日 优先权日2007年9月14日
发明者R·L·奥尔西尼, M·S·奥黑尔, R·达文波特 申请人:安全第一公司