资讯洞察 
密钥托管及数据托管加密系统和方法
2026-08-26
浏览次数：次
返回列表
本专利提出了一种基于密钥托管与数据托管的密码技术方案。针对传统加密系统密钥丢失不可恢复、数据恢复过程缺乏验证机制的问题，创新性地采用分段密钥存储与多级验证机制：发送端将对话密钥分割后分别用托管代理机构的公钥加密生成法律强制访问域（LEAF），接收端通过重构LEAF验证发送端身份；加密用户通过数据恢复域（DRF）封装访问规则索引与用户机密，解密用户需经数据恢复中心（DRC）根据访问规则验证后恢复数据，实现了密钥安全托管与数据可控恢复的双重保障。
被称为“克利珀尔创议”(Clipper initiative)的1993年4月16目的美国总统公告要求开发一种称为“叩头虫”(Skipjack)的保密加密算法的硬件实施方案。总统公告将这种叩头虫算法刻划为“明显优于目前公众所能用到的任一种算法”。叩头虫的硬件实施方案也应该包括一种称为“密钥托管”的能力，这种能力允许政府恢复用于数据加密的密钥。实现叩头虫算法的集成电路芯片被称为“克利珀尔芯片”和/或“卡普斯通芯片”(Capstone芯片)。
克利珀尔创议(尤其是密钥托管特征)试图在为守法的公民提供一种比他们现在能用到的系统都要强大得多的加密系统的同时，试图维持法律强制和国家安全截取和探测通信内容的能力。克利珀尔创议公告以及随后的讨论使之变得清楚虽然叩头虫是比现有的非保密数据加密标准(DES)功能更强的加密算法，但法律执行单位认为，DES语音保密装置的激增将成为他们维护其执行法院命令从电话(电报)线路上窃取情报能力的极大障碍。
在对4月16日公告的公众反应中，对克利珀尔创议的大量反对意见是很明显的。反对意见采用各种形式表达，但以下的主要观点最为突出·许多人反对这样的可能密钥托管加密技术的展开以及今后将和政府托管代理人共享私人密码密钥的做法将导致个人隐私的丧失。
·许多人反对管理机构企图把政府的购买力强行成为它们事实上的标准，从而政府代理人能随意击败。
·有些人反对引入分级算法做为保护非保密信息的标准。DES是公开的并且在其15年的使用周期中已经有了广泛和详尽的研究。有人暗示叩头虫可能存在某种缺陷或陷门(而不是密钥托管过程)。一个外部密码员的专门小组对叩头虫的赞同考察也不能平息这些反对意见。
·许多人(尤其是信息技术产品的供应商)反对硬件实施方案的要求，因为成本提高而且受到要在整个系统或产品设计上必须采用政府所设计的芯片的限制。
在1993年8月，国家标准化技术研究所(NIST)宣布了和工业界的一个协作计划，寻找用软件实现密钥托管的可能方法(不需要专用硬件元件，例如克利珀尔(Clipper)芯片或卡普斯通(Capstone)芯片。
讨论该课题时存在许多互相交织的问题，问题包括硬件实施方案、保密的加密算法，以及对加密过程的用户必须给予多大的信任等问题。这些问题将在下面讨论，但在涉及这些问题之前，先讨论一下密钥托管将是有用的。
密钥托管密码技术将密钥托管技术加到实现密码特征的产品中，可允许被授权的用户查找用于加密通信的密钥并利用密钥对通信解密。在克利珀尔创议中，用于每个加密装置的密钥在数学上被分成两半(每一半在长度上等于原始的密钥)并且分别由两个独立的托管代理人保存。在对某个给定的装置中的通信解密之前，两个托管代理人必须协作(重新产生原始的密钥)。对于克利珀尔创议来说，托管代理人为政府机构，要求他们保证请求密钥的法律强制机构得到法院命令授权对所讨论的通信从电话(电报)线路上窃取情报。
许多需求已经被引用以证明密钥托管密码技术是需要的。某些适用于法制和国家安全的需要，而其它的则适用于个人用户或组织的要求。
·使法制和国家安全机构感到担心的是，加密通信日益增长的使用将损害他们利用法院命令从电话(电报)线路上窃取情报以解决犯罪问题和防止恐怖行为的能力。广泛使用密钥托管加密技术将维护这些机构的这种能力，又能为公众提供高质量密码术的好处。在法律强制和国家安全的情况下，当法院命令授权时，政府托管机构提供对通信的访问。
·某些公司已经表示了这样的担心雇员的粗心大意或蓄意破坏可能会使公司得不到对其有价值信息的访问。公司级的密钥托管密码技术已经实现了这样一种机制，在这种机制中，这些公司能重新获得对其信息的访问。在这类应用中，可以由高级管理或人事办公室做为托管代理人，他可允许雇员的主管访问雇员文件或通信。
·在自己的信息中使用加密技术的个人可能会因为死亡或残废而忘记或丢失保护其加密密钥的口令。密钥托管密码技术已经被推荐做为这样一些个人的一种安全机制。在这种情况下，个人可以选择朋友或律师做为允许个人(或者也许是其财产的指定遗嘱执行人)访问被保护的信息的托管代理人。
·在某些情况下，政府代理机构有权监视其雇员的商业通信。例如，这样的权限适用于军事和国家安全设施，用于检测对保密或敏感信息的滥用。密钥托管密码技术也为这样的代理机构提供了行使其监视加密通信的权力的机会。在这种应用中，通信安全官员可以做为托管代理人，他们将授权给线路的管理员或指挥员。
克利珀尔创议集中在上述引用的对密钥托管的四种应用中的第一种。此外，克利珀尔创议将密钥托管的引入和叩头虫算法的引入结合起来，叩头虫算法是一种比非保密DES要强得多的加密算法。
克利珀尔创议的反对者争辩说，象克利珀尔这样的密钥托管加密系统可能会被象有组织的犯罪这样的老练用户所击败，这些人有能力编写成购买他们自己的加密系统(不用密钥托管)并且不理采密钥托管产品或者先在他们自己的系统下加密，然后再在密钥托管系统下加密。希望能协同击败密钥托管技术的用户对也有各种选择方法的余地，克利珀尔创议的某些反对者认为，阻止这种情况发生的唯一办法是通过法律禁止使用非托管的加密技术，并且采用强有力的通信监视手段来实施这种法律-至少可以说这是一种毫无吸引力的指望。
克利珀尔创议的拥护者反击说，他们很清楚成对的协同用户有许多方法避开密钥托管。这些拥护者的目的是使个别的“无赖”用户难以或者不可能有把握地和同线的用户(或更准确地说和被托管的加密装置)通信，由此使之相信，在他们所进行的通信中，两边的通信者都忠实地遵循托管规则。
“个别无赖用户”的情况对密钥托管系统构成了一种测试。成功的密钥托管系统(硬件或软件)应该能防止个别的无赖用户探测到被托管产品中的密码技术，并且能防止其破坏或绕过产品的密钥托管特征，同时又能使其他的用户(产品)进行可靠的通信，相信他们和无赖用户都在正确地实现托管特征。
“克利珀尔”芯片解决“个别无赖用户”问题的方法是将每次个人通信对话的密钥嵌入由对所有“克利珀尔”芯片都一样的密钥(族密钥)加密的法律强制访问域(LEAF)中。被嵌入的信息包括依赖对话密钥的检查和。接收方的“克利珀尔”芯片也存放族密钥；因此，它可比对LEAF解密并且证实该检查和对于当前的对话密钥是正确的(为了通信的成功和安全，两个芯片必须秘密共享)。所有“克利珀尔”芯片共享被嵌入的族密钥并且依靠芯片的防窜改硬件保护族密钥免于被发现。
密钥托管密码技术的硬件实施方案有几个因素支持这样的决策，即需要在做为克利珀尔创议的元件的密钥托管产品(克利珀尔和卡普斯通芯片)的设计中采用独立的硬件。下面将要讨论到的这些因素中的某些和密钥托管密码技术的引入有关，有些因素和使用某种保密的加密算法有关，而另一些则和用于加密产品设计的保守标准有关。
·单独的硬件提供了在软件系统中难以得到的加密处理的保护程度。出错的或恶意的计算机程序不能破坏嵌入在象克利珀尔或卡普斯通芯片这样的硬件加密装置中的加密算法或密钥管理功能。
·单独的硬件提供了在软件系统中难以得到的密钥托管处理的保护程度。虽然软件能处理托管过程的外部可视参数，但硬件至少能提供托管操作得到执行或验证的某些保证。
·如果使用例如叩头虫这样的保密加密算法，执行具体保护措施的单独硬件对保护算法的设计不被暴露可能是最为重要的。
·保密的密码密钥在硬件装置上能得到高级的保护，因为不加密的密钥永远不需要出现在装置外部。反之，要保护嵌在软件中的保密密钥免受用户用基础计算机硬件的物理控制是很困难甚至不可能的。
·加密能力的激增可以预期，利用硬件装置控制受控装置的计费以及出口的限制比采用嵌入的软件要更为方便。
上述的观点表明，采用克利珀尔创议装置的需求中，有些是为了保护保密的叩头虫算法，有些是由于加密系统保守设计的需要，而有的则是为了保护托管处理过程。
使用保密的数据加密算法随克利珀尔创议引入的叩头虫加密算法声称比现有公开使用的算法(例如DES)要强得多。对于任何新的加密产品来说，具有好的算法是一种有价值的销售观点。但是，正如上述中所指出的那样，至少在现在的技术状况下，保护保密算法不被发现，需要某种硬件实施方案，体现出阻止反向工程的特殊措施。
通常认为保密的加密算法比公共领域中的算法要好得多，因为这些用来保护政府保密信息的算法是保密的。但由于公众无法对其复审，人们对于使用保密的算法来保护非保密信息的建议表示怀疑，因为可能存未知的故意的陷门或非故意的缺陷。虽然DES最初也受到某些人的怀疑，但经过认真的公开的仔细检查，现在其主要力量在于即使15年了也没有发现什么严重的缺陷。
这样的密钥托管技术并不要求使用保密的算法，而可以使用例如DES和IDEA这样公开可得到的算法或者例如RSADSI的RC2和RC4这样专用的但非保密的算法。如果一种公开使用或专用的非保密算法被用在体现密钥托管加密技术的产品中，将不需要采用硬件实施方案来达到保护加密算法不被泄露的目的(虽然存在采用硬件实现密钥托管加密技术的其它理由，如上表列出的那样)。
在检验软件密钥托管方法的可行性中，硬件实施方案和保密的算法之间的这种相互依赖性已经引起了相当大的混乱。如果需要某种保密的算法，无论是否实现密钥托管，都必须采用硬件来保护该算法。如果选择某种非保密的公用的或专用的算法，就可以自由选择用硬件或软件的方法来实现。采用硬件或软件的决定是由其它因素驱使的，例如在上述的列举中所列出的那些理由。
软件加密的优点和局限性在历史上，用来保护敏感信息的加密系统都是采用单独的硬件装置来实现的，通常为在计算机或通信系统和某种通信电路之间的外围的“盒子”。这样的装置在设计中对操作的完整性采用高水平的检查技术来面对失效和恶意的攻击，并采用特别小心的措施来保护密码函数和密钥。
软件加密系统在历史上一直受到怀疑的对待，因为它们对保护算法和密钥的能力是有限的。上面的段落中讨论了有关保护保密的加密算法免于泄露的问题。在这些问题之外还存在这样的事实，即采用软件实现的加密算法受到各种各样的攻击。计算机的操作系统或用户能修改实施加密算法的代码，以便使之失效；从存储器中偷走保密的密码密钥，或者，最糟的是，每次发送或接收加密消息时，都导致产品泄露其保密的密码密钥。
使用加密硬件的主要缺点，而同时又是集成化的软件实施方案的主要优点是成本。当采用硬件实现加密时，无论是芯片、线路板、外围设备(例如PCMCIA卡)或盒子，最终用户都必须支付价格。销售商必须购买芯片并将其设计在装置中，由于芯片所需的附加的“不动产”将使得设备的成本上升。最终用户必须购买具有集成加密硬件的更为昂贵的设备，或者必须购买PCMCIA卡或类似的设备，然后花钱在其计算系统上增加一个设备接口，或者指定某个现有的接口做为加密用，而不是由调制解调器或磁盘执行的另一种功能。
软件实施方案的第二个主要优点是操作的简单性。软件方法能方便地被集成为各种各样的应用程序。企图以成于上万或几百万的数量销售产品的大规模市场软件工业寻找能用软件实现一切，以便减少对硬件变化和配置的依赖性并以最少的成本向用户提供最有用的产品。
本发明的目的是提供用在包括发送器和接收器的系统中的密钥托管密码的系统和方法。对于“发送器”，我们指的是为随后的传输或存储对数据加密的某个程序或设备，对于“接收器”，指的是对已经接收到的或从存储器中检索到的数据解密的某个程序或设备。只有公共密钥被存在发送器和接收器中，才不需要对软件保密。根据本发明的第一个实施例，发送器用保密对话密钥(KS)加密消息，并通过组合唯一的程序标识符(UIP)、程序唯一密钥的公用部分(KUpub)和签名而产生页验证串(LVS)。签名代表由密钥托管程序设计软件包(KEPF)密钥(KEPFpriv)的保密部分标识的UIP和KUpub。加密的LVS(ELVS)是通过用KS对LVS加密后形成的。
发送器利用KUpub加密KS而产生第一加密对话密钥(EKS)，并通过用存在发送器中的族密钥公用部分(KFpub)的拷贝对第一EKS和UIP的组合加密，产生第一法律强制访问域(LEAF)。被加密的消息、ELVS和第一LEAF从发送器中送到接收器。
接收器操作过程如下。接收器存储KEPF密钥的公用部分(KEPFpub)和族密钥的公用部分(KFpub)。接收器利用KS对ELVS解密，并从LVS中提取UIP、KUpub和签名，并利用KEPFpub验证签名。如果验证成功，接收器将利用被提取的KUpub对KS加密以产生第二加密对话密钥(EKS)。接收器用存储在其中的KFpub的一个拷贝对第二EKS和被提取的UIP的组合加密，产生第二LEAF。接着，接收器比较第一LEAF和第二LEAF。如果第一LEAF等于第二LEAF，则接收器用KS对被加密的消息解密。
本发明的该实施例是这样操作的，不用抗窜改技术，也不用对发送器或接收器的软件或硬件保密，已经修改了发送器或接收器的硬件或软件的用户不能成功地和没有被修改的接收器或发送器进行通信，并且同时也不能阻止法制机构获得对通信的授权访问。
在本发明的第二个实施例中，发送器利用保密的对话密钥(KS)对消息加密，并通过组合KS1和KS2(这里KS＝KS1XOR KS2)产生LVS。利用KS加密LVS而形成ELVS。此外，发送器利用每个托管代理人的公共密钥(KEApub1和KEApub2)加密KS1和KS2，分别产生EKS1和EKS2。最后，发送器通过并置EKS1和EKS2产生第一LEAF。被加密的消息ELVS和LEAF从发送器送到接收器。
第二实施例中的接收器操作过程如下。接收器存储KEApub1和KEApub2。接收器利用KS对ELVS解密并提取KS1和KS2。然后接收器通过对KS1和KS2的异或运算产生试验的KS。如果试验的KS等于KS，则接收器利用KEApub1和KEApub2的拷贝计算出第二LEAF。如果第二LEAF等于第一LEAF，则接收器利用KS对被加密的消息进行解密。
最后，在关于数据托管密码技术的本发明第三实施例中，加密用户利用保密的存储密钥(KS)加密文件并产生包括访问规则索引(ARI)和由收据恢复中心(DRC)公共密钥(DRCpub)加密的KS的数据恢复域(DRF)。DRCpub是在初始注册阶段中得到的，后该阶段中，AR定义用户定义一组对DRF的内容的潜在访问进行控制的访问规则(ARs)。在DRC接收到来自AR定义用户的AR后，DRC返回被包括在附属于随后的加密文件的一个或多个DRFs中的ARI。
为了对用KS加密的文件解密，正常的解密用户使用通常适合于标识或访问存储沉密钥KS的任何机制。当失败时，借助DRF实现紧急访问。在这种情况下，紧急解密用户提取附加在被加密消息中的DRF并将其送到DRC。DRC根据AR定义用户所定义的ARs访问紧急解密用户，并且当紧急解密用户满足访问时，将包含KS的消息送给紧急解密用户。
在其它的实施例中，KS不是加密密钥，而宁可说是能装在DRF中的任何一条机密信息。在所有的情况下，DRC限制对紧急解密用户的访问，这些用户能满足由DRF中的ARI指定的AR所定义的询问。
本发明的进一步的特征的优点，以及本发明各种实施例的结构和操作将在下面结合附图详细介绍。在附图中，相同的引用数字表示相同的或功能上类似的文件。
图1为根据本发明第一实施例的密钥托管密码系统的方块图；图2至图9以及图17为流程图，说明了根据本发明第一实施例的密钥托管密码系统；图10为本发明第二实施例的密钥托管密码系统的方块图；图11至图16为说明本发明第二实施例密钥托管密码系统的流程图；图18为根据本发明的某个实施例的数据处理器的方块图；图19为根据本发明第三实施例的数据托管密码系统的方块图；图20、图24和图26为描述访问规则定义处理的数据流图；图21至图23以及图25为描述访问规则定义的流程图；图27为数据恢复域结构的最佳实施例；图28为描述紧急访问请求处理的流程图29为示例性的询问-应答周期流程图；图30为描述嵌入某个紧急访问请求中的询问应答周期的数据流图；以及图31为描述检索数据恢复域中的访问规则的数据流图。
本发明的目标是提供一种密钥托管和数据托管密码技术的系统和方法。本发明最好采用软件实现，然而，采用硬件技术实施本发明同样能很好工作。
本发明最好使用某种不保密的数据加密算法。因此，软件不能保护保密的加密算法这样一种反对意见就不能适用于本发明。
另一种反对采用软件技术的意见是不能保证密钥托管软件能正确工作并且不被用户修改以绕过或破坏托管处理。应该注意，这种反对意见不仅限于软件，而且对于允许软件控制进出硬件加密装置的信息流的硬件实施方案也会出现同样的问题。
另一种反对采用软件技术的意见是不可能在不易被发现的大风险下将保密的密码密钥嵌入软件产品中。本发明解决这种在常规的密钥托管软件实施方案中所固有的问题的方法是，不将保密的密钥或专用密钥嵌入在发送器和接收器的软件模块中。本发明的这种特征将在后面讨论。
在本发明中，最好采用任何为人们所熟知的不保密的和公开可得到的算法(例如DES和IDEA)或者任何为人们所熟知的专用的但不保密的算法(例如RSADSI的RC2和RC4)来执行加密和解密操作。加密和解密算法的具体细节将不在本发明中介绍。
本文使用下述符号。b表示利用密钥“b”对“ a”加密；同样，加密(e，f)表示利用密钥“f”对“e”加密。
{x}y表示采用为人们所熟知的过程，利用密钥“y”对“x”数字签字；同样，sign(a，b)表示利用密钥“b”对“a”进行数字签字。
extract(g，h)表示利用熟知的过程从并置的值“g”中提取“h”。
用在这里时，具有后缀“priv”的标号的值被认为是专用的或保密的。后缀为“pub”的标号的值被认为是公用的。
关于由Z＝[X]Y(X由Y加密)表示的符号，如果Y为公共密钥，并且Z需要用不具有对应于Y的专用密钥的某些其它程序重建，则这种加密需要用到已知的或被送到该重建过程的X周围的所有没有被用到的位。如果不需要重建Z，这可以直接间接加密。即，可以等价地计算Z＝([X]K1，[K1]Y)(这里的Ki为常规的随机选择对称加密密钥)并取得相同的功能结果。如果X大于能一次在Y下直接加密的数量，这可能是所希望的。同样，也可以计算Z＝([X]K2，[K2]K1，[K1]Y)。
下面将介绍三个实施例，两个适用于密钥托管密码技术的系统和方法，而第三个适用于数据托管密码技术。前两个实施例一般都具有下列的最佳特征·两个实施例都能保证修改过发送器或接收器软件的用户不能成功地和没有修改过的接收器或发送器通信，并且同时不能拒绝对通信的法律强制授权访问。
·在这两个实施例中，通信的接收方重新构造发送器的LEAF，以验证所接收到的LEAF对于当前被加密的通信都是有效和正确的LEAF。这种选择针对个别无赖的攻击。
·都使用了基于公共密钥加密技术的托管规约来建立法律强制访问域(LEAF)，使法律强制权威机构能得到用户的密钥。这种选择不需要将任何保密的密钥放在软件产品中(应该是托管过程的一部分)。
另一方面，第三实施例集中在对被存储中信息的恢复，而不是对被传输信息的恢复。在该实施例中，数据恢复域(DRF)(和LEAF类似的一种结构)允许用户对前面实施例的法律强制机构发挥相同的作用。访问不但能通过法院强制命令执行，而且也能通过任何一组由发送器定义的访问规则(AR)得到。
1.第一实施例图1为根据本发明第一实施例的密钥托管系统102的方块图。密钥托管系统102包括密钥托管程序设计软件包(KEPF)106，两个或多个密钥托管代理机构(KEA)110和114，发送和接收实体124和130，以及法律强制解密器120。
发送实体124的方块图由图18表示。发送实体124最好是具有中央处理器(CPU)的数据处理装置1802，CPU1804通过数据总线和其它设备连接。CPU1804根据控制逻辑1806进行操作。控制逻辑1806最好是计算机程序，这样，CPU1804就能根据该程序中买球平台的指令执行操作。
数据处理装置1802还包括通信或存储装置1808，监视器1812，键盘1814和打印机1816。发送实体124和其他装置(例如接收实体130)之间的通信是通过通信或存储装置1808的操作来实现的，通信或存储装置为任何熟知的发送机或存储器。
根据本发明，控制逻辑1806使发送实体124(尤其是CPU1804)能如本文所述那样操作。例如，控制逻辑1806(当由CPU1804执行时)使发送实体124能执行如图7所示的步骤。
接收实体130的结构类似发送实体124，因此，上面的描述同样适用于接收实体130。然而，根据本发明，接收实体130的控制逻辑1806使接收实体130(具体来说为CPU1804)能如本文所述的那样操作。例如，控制逻辑1806(当被CPU1804执行时)使接收实体130能执行如图8所示的步骤。
由于发送和接收实体124和130中的控制逻辑1806最好代表软件，因此发送和接收实体124和130在本文中有时也称为“程序”。然而，应该理解，这样的“程序”代表了根据软件操作的设备1802。另外，根据本发明的另一实施例，发送和接收实体124和130完全采用硬件实现(例如，CPU1804和控制逻辑1806代表了硬件状态机)。
如上所述，这样的系统104和Clipper/Capstone系统之间的一个差别是，系统104利用公共密钥密码技术而不是常规的(对称的)密码技术来产生法律强制访问域LEAF。众所周知，采用对称的密码技术时，发送器和接收器共享一个密钥，用来控制加密和解密。而使用非对称的密码技术时，加密和解密使用的是单独的密钥，不能从对另一个的计算得到。因此，加密密钥可比成为公用的(一个“公共密钥”)而且任何人可以送出保密消息，该消息只能由对应(“专用”)的解密密钥的持有者解密。使用公共密钥密码技术允许软件程序124和130产生和验证LEAFs而不需要存储保密密钥或专用密钥。只需将公用的信息嵌入软件程序124和130中，因此，本发明不需要保存其自身结构或内容的秘密。现在将介绍系统102的各种元件。
1.1密钥托管程序设计软件包密钥托管程序设计软件包(KEPF)106位于被保护的环境104之内。保护环境104被定义为某个物理上和过程上的保密区域，该区域足以保护将由任何密钥托管加密程序保护的所有信息的值。
KEPF106包括各种和密码有关的数据108。这种存储在KEPF106中的数据108不能被保护环境104外的人员或实体访问。下面将结合图2中的流程图202介绍KEPF106初始化这些数据108的方法。
KEPF106用两对公共/专用密钥初始化。第一对为KEPF公共/专用密钥对，它们在步骤206、208、210和212中被初始化，用于标识和认证由KEPF106产生和分布的其它组成部分。KEPF密钥对是在外部产生并装入KEPF106中(步208)，或者是在KEPF106的内部产生(步210)。控制可用于KEPF密钥对的产生和保管上，因为它们将成为克利珀尔/卡普斯通芯片程序设计软件包所使用的族密钥和种密钥。KEPF公共、专用密钥对在步212中被存在一个存储器装置中。
KEPF所用的第二密钥对为族密钥(KF)，它们在步214、216、218、220和222中被初始化。KF最好在KEPF106的外部产生(步216)，虽然也可以内部产生(步218)。只有公用部分(KFpub)被送给KEPF106(步222)。对应的专用部分(KFpriv)被装入法律强制解密器(LED)120(步220)。KF的专用部分也可以被分为两半并且被托管。
1.2法律强制解密器法律强制解密器(LED)120也在保护环境104之内。LED包括族专用密钥KFpriv122。
LED120对族专用密钥122的初始化如图4所示。在步406中，LED得到KF的专用部分KFpriv，并在步408中存入一个存储装置中。
1.3产生程序参数在上述操作的基础上，KEPF106对每个程序进行签字并选择性地产生唯一的程序参数，正如克利珀尔/卡普斯通程序设计软件包对每个单独芯片进行程序设计一样。具体来说，如图3的流程图302所示，KEPF106在步306中将KEPFpub和KFpub送给软件的供应商/用户118。然后对每个程序例子执行步308-324。
在步308中，KEPF106产生或取得程序唯一标识符(UIP)和程序唯一密钥(KU)。KU最好是某个非对称的公共/专用密钥对。KU在KEPF106内部产生并且和在外部产生并被装入KEPF106的参数一块做为种子。KU的专用部分(KUpriv)被分成两半(步308)，这最好通过产生随机位串的方法来实现，只要将KUpriv做为KUpriv1并且通过对KUpriv1和KUpriv的异或运算计算出KUpriv2。
在步310中，UIP和两个半个的单独的专用密钥由两个托管代理机构(KEA)110和114托管。具体来说，如图5中的流程图所示，托管代理人110接收UIP和KUpriv1(步504)并存储UIP和KUpriv1(步骤506)。对每个程序例子重复执行这些步骤，如步508所指示的那样。另一个代理人114的操作过程和这个一样。
在步312和314中，KEPF106将程序唯一参数UIP和KUpub送到软件供应商118，以便被嵌入软件程序产品中。在步312中，KEPF106利用所熟知的过程，用其专用密钥KEPFpriv数字化地对这些参数签字，并将签名和其它部分一块送给软件供应商118(步314)。程序设计软件包的公共密钥(KEPFpub)和族密钥公用部分(KFpub)也被送给供应商118。对每个程序例子重复步骤308-314，如步316所示。
1.4产生软件产品如果KEPF106通过某个频带之外的(保密)通道将其公共密钥KEPFpub送给供应商118，供应商就能可靠地认证从KEPF106中接收到的一组参数(KFpub，UIP，KUpub)。这是因为，众所周知，用专用密钥加密(或数字签字的)的数据可由拥有相应公共密钥的任何人解密(或验证)。另外，用公共密钥加密的数据则只能用对应的专用密钥解密。
正如图6的流程图602所表示的那样，当软件供应商118制造其产品的软件拷贝时，将KFpub和KEPFpub嵌入在产品的代码中(步608)。已经从KEPF106中接收到KFpub和KEPFpub(步606)了。每个程序例子必须用下面的数据初始化KEPFpubKFpub对该程序例子唯一的KUpub对该程序例子唯一的UIPS＝{KFpub，KUpub，UIP}KEPFpriv，对该程序例子唯一的。
这些数据可以放在程序的代码中或者放在和该程序有关的某个存储文件中。KEPFpub，KFpub和S必须来自KEPF、KUpub和KUpriv，而UIP可以由KEPF、供应商或程序本身在初始化期间产生。S只能在接收或产生的有效的KUpub、KUpriv对和成功地托管KUpriv的基础上由KEPF产生。
供应商118最好将每个程序的程序唯一性参数(UIP，KUpub和有关的签名)嵌入程序的介质中(步612)。UIP，KUpub和相关的答名是在步610从KEPF106中接收到的。对每个软件产品执行步610和612，如步614所示。
上述的数据在发送程序124中用引用数字126表示，而在接收程序中用引用数字132表示(图1)。
注意，在程序产品中不提供保密的或专用的密钥。只将公用量KEPFpub，KFpub和KUpub嵌入软件产品中。
在软件产品采用大规模制造的CDROM介质出售(从而不能接受唯一的系列号或密钥信息)时，或者装在某种共享的存储装置上供多用户访问时，为每个产品拷贝嵌入唯一的KUpub、UIP和相关的签名是不可行的。在这些情况下，产品的用户可以被要求运行某个安装程序，后者在网络或通信线路上检索KUpub、UIP及其签名。通过执行安装程序并且拥有KUpub、UIP以及相应的有效签名，能让产品的加密功能操作随机变化。
由于为其用户定制的托管软件所需的只是对某些量进行数字化签字并公开，因此，在网络或其它不安全的通信通道上检索它们并不存在危险。其可靠性没有什么问题，其完整性也可以利用KEPFpub进行验证，KEPFpub对所有的用户和产品的拷贝都是一样的并且可由供应商118嵌入。
1.5发送程序的操作如图7中的流程图702所示，发送程序124在步706中接收数据消息M。在步708中，发送程序124和接收程序130利用任何熟知的过程议定某个保密的对线利用保密的(或专用的)对话密钥KS加密并传送数据消息M。这个被加密的消息C由[M]KS表示。
另外，在步710中，发送程序124通过在程序唯一公共密钥KUpub下加密对话密钥KS，由此产生[KS]KUPpub。[KS]KUpub也被称为加密的对话密钥或EKS。EKS和程序唯一标识符UIP并置因而产生[KS]KUpubUIP。该值由该公共密钥KFpub加密。所得的LEAF被符号化为[[KS]KUpub[UIP]KFpub。请注意，在本发明中，M的加密是利用对称加密实现的，而在密钥KUpub和KFpub下的LEAF中的加密则是利用非对称、而不是对称密码技术实现的。
另外，在步710中，发送程序124产生的LEAF验证串(LVS)包括(1)发送程序124的程序唯一标识符UIP，(2)程序唯一公共密钥KUpub，以及(3)通过密钥托管程序设计软件包106施加到这两个量上的签名S，即{UIPKUpub}KEPFpriv(这三项被称为页验证串LVS)。该串在对话密钥KS下被加密，因此，ELVS表示如下[UIPKUpub{UIP，KUpub}KEPFpriv]KS在步712中，C、LEAF和ELVS被送到接收程序130。
1.6接收程序的操作如图8的流程图802所示，在步806中接收程序130和发送程序124议定保密线中接收C、LEAF和ELvS。
在步820中，接收程序820用对话密钥KS对被加密的消息C解密以恢复消息M。然而，在此之前，接收程序820必须认证LEAF以保证发送程序124已经包括了某个有效的LEAF做为消息传送的一部分。这将在步810、812、814和816期间执行。
注意，接收程序130不能对LEAF解密，因为它不具有族专用密钥KFpriv的拷贝。而根据本发明接收程序130通过对LEAF的重构来验证它。这样做是可能的，由于接收程序130已经被提供了组成LEAF的所有各种组成部分，或者通过托管系统(KF和KS)操作的外部通信或者被签字后的加密LEAF验证串ELVS发送。
具体来说，在步810中，接收程序130利用话路密钥KS对被加密的页验证串ELVS进行解密以得到页验证串LVS或UIPKUpub{UIPKUpub}KEPFpriv。接着在步810中，接收程序130验证所接收到的发送程序124的拷贝的程序唯一密钥KUpub和程序唯一标识符UIP(在LVS中)是正确的可靠的。这将在步812中通过利用KEPFpub验证对应的答名S或{UIPKUpub}KEPFpriv来实现的。
如果页验证串LVS是可靠的(根据步812中所确定的)，则在步814中，接收程序130利用KS和KFpub以及发送程序124的KUpub和UIP重新计算LEAF(在图8中被称为“fest-LEAF”)。如果所计算的LEAF和接收到的一致(在步816中确认)，则LEAF是有效的。因此，接收程序130接受并解密消息(步820)。否则，接收程序130柜绝该消息(步818)。
使用话路密钥KS加密页验证串LVS对于验证LEAF的功能是没有必要的，而这一步能保护发送程序124的UIP和Kupub免于被不和它进行通信的同线法律强制解密器由法律强制机构操作的法律强制作解密器(LED)120包括族专用密钥KFpriv(在图1中被表示为122)。其操作由图4的流程图402所表示，LED120在步406中从KEPF106中接收KFpriv(对应图2中的步220KFpriv在KEPF106中产生的情况；这里的KFpriv是由某个外部实体在KEPF106的外面产生的(没有表示出来)，接着，外部实体将KFpriv送给LED120)。在步408中，LED120将KFpriv存放在LED120的存储装置中。
2.第二实施例在线托管机构克利珀尔创议的密钥托管规约受到批评是由于一开始就发现了这样的事实，其唯一密钥(初始克利珀尔模式中的KU)已经从托管代理机构取出的装置从取出后的时间起易遭到解密。虽然克利珀尔创议的公开策略是，一旦从电话(电报)线路中窃取情报的授权到期时，唯一密钥将从法律强制解密器(LED)中擦除，但对于一开始就认为密钥托管毫无吸引力的个人来说，这种策略是一种使人不寒而栗的安慰。
上述的本发明软件密钥托管系统的第一实施例和克利珀尔创议一样都使用设备唯一密钥(KUpriv)，该密钥被装入法律强制解密器LED120，并且当从电话(电报)线路上窃取情报的授权到期时必须被擦除。此外，可能会有这样的情况，某个恶意的用户利用被修改过的软件产品获取或重用其他用户的托管信息(UIP和KUpub)，向他们秘密地传递潜在的问题，在这种情况下，可以导致法律强制机构对清白的同线用户查找Kupriv。
本发明软件密钥托管系统的第二实施例将讨论和解决这些担心。第二实施例不用唯一密钥(KU，KUpub和KUpriv)和标识符(UIP)。反之，每个发送器分割其对话密钥KS并在每个托管代理机构的公共密钥下加密一个碎片。这种模式也加入LEAF和LEAF的验证串，但和KEPF无关并简化了供应商的作用。
图10为第二实施例的方块图。KEApub1和KEApriv1(表示为1008)被存储在密钥托管代理机构1006中，而KEApub2和KEApriv2(被指定为1012)被存储在密钥托管代理机构1010中。注意，没有密钥托管程序设计软件包(KEPF)。然而，在对密钥托管代理机构1006和1010进行初始化的被保护环境1004中有某些实体(图中没有表示，该实体可以被称为KEPF)。这个初始化过程由图11中的流程图1102表示，在其中的步1108中，实体从某个外部源(没有表示出来)得到KEApub1和KEApub2。备择地，在步1110中，实体产生KEApub1、KEApriv1、KEApub2和KEApriv2，将KEApriv1和KEApub1发送给密钥托管代理机构1006，将KEApriv2和KEApub2发送给密钥托管代理机构1010，并擦除KEApriv1和KEApriv2。在步1114中，实体存储KEApub1和KEApub2。在步1116中，实体将KEApub1和KEApub2发送给软件供应商1014。备择地，如图10所示，KEApub1和KEApub2从密钥托管代理机构1006和1010中发送到软件供应商1014。
供应商1014的唯一作用是在每个程序例子中嵌入代码，该代码实现两个(或多个)托管代理机构的公用密钥(KEApub1和KEApub2)和密钥托管功能。这些密钥在发送程序1018和接收程序1024中分别用1020和1026表示。软件供应商1014的操作由图12表示，在其中的步1206中，软件供应商1014从密钥托管代理机构1006和1010中接收KEApub1和KEApub2，在步1208中，软件供应商1014存储KEApub1和KEApub2，并在步1210和1212中，软件供应商1014将KEApub1和KEApub2嵌入在每个软件程序中。
发送程序1018的操作如图13的流程图1302所示。在步1306中，发送程序1018接收消息M。在步1308中，发送程序1018和接收程序1024利用任何众所周知的过程议定某个保密的对线用密钥KS加密消息M。
在步1312中，发送程序1018将对话密钥KS分割为两半KS1和KS2。最好按已知的方法赋给KS1某个随机数，然后将该随机数和KS的异或结果赋给KS2。发送程序1018在步1312中还产生LEAF。LEAF等于在KEApub1下被加密的KS1和在KEApub2下被加密的KS2的并置，并且可由下式表示LEAF＝([KS1]KEApub1[KS2]KEApub2)LEAF不需要用KEApub加密，因为任何人都得不到KEAprivi，到这些解密服务的唯一路径大概只能通过LED。KEApubi加密足以保持LEAF内容的保密性，而不必求助于KFpub加密。然而，如果存在某些不是通过LED对“托管”(解密)代理机构的通信路径，或者如果存在不同类型的用户，对于其中的某些用户，LED可能不允许被访问，则族密钥KFpub提供了所需的安全性。应该注意到，本实施例并不局限于两路分割的对话密钥。在其它的实施例中，任何数目的分割，从1向上都可以使用。一般的LEAF可由下式表示LEAF＝([KS1]KEApub1，[KS2]KEApub2，…，[KSn]KEApubn)或者LEAF＝[[KS1]KEApub1，[KS2]KEApub2，…，[KSn]KEApubn]KFpub其中n＞0LEAF结构的选择取决于是否需要KFpub加密的额外保护。然而，在某些点上，当考虑到一个密钥的尺寸时，可能禁止在一个KFpub密钥下对所有的碎片加密。
接着在步1312中，发送程序1018产生等于KS1和KS2的并置的页验证串LVS。然后利用话路密钥KS对LVS加密而产生被加密的页验证串ELVS。
接收程序1024的操作如图14的流程图1402所示。在步1406中，接收程序1024从发送程序1018中接收C、LEAF和ELVS。在步1408中，对话密钥KS被议定产生(该步对应图13中的步1308)。然后，接收程序1024检查页验证串LVS并重新计算LEAF。具体来说，在步1410中，接收程序1024利用KS对被加密的页验证串ELVS解密，以得到页验证串LVS。从LVS中提取出被称为trial-KS1和trial-KS2的假定存在的KS1和KS2。接着，接收程序1024通过对刚从LVS中提取出来的trial-KS1和trial-KS2做异或运算而产生对线中称为“trial-KS”)。在步1412中，接收程序1024比较trial-KS和议定的对话密钥KS。如果不相等，则说明LEAF是坏的并拒绝接收该消息(步1418)。
在步1416中，接收程序1024判断frail-LEAF是否等于LEAF。若不相等，则拒绝接收消息(步1418)；若相等，则认为LEAF是有效的并用KS对消息M解密。
由LED1016对某个托管代理1006和1010提交的用于电话(电报)线路窃取情报的密钥部分都必须由对应的密钥加密，当法院命令到期时，托管代理1006和1010删除保密的密钥KS1和KS2，因此，在命令到期之后，不能履行任何对密钥的请求。因为和托管代理1006和1010的所有通信都必须被加密以便保密，这一处理并没有对操作增加执行时间。
由于没有数据库链接某个UIP到任何为法院命令的目标的个人，托管代理1006和1010没有别的选择，只能相信为某次特信定的电话(电报)线路窃听任务法院命令所对准的个人相关的LED1016。上述的规约可修改为在被送到托管代理1006和1010的LEAF部分中中入UIP，使这些代理1006和1010能保持每次法院命令目标的程序例子列表供以后的窃听使用。
该第二实施例的优点是，不向LED1016公开产品唯一密钥。一旦停止监视，LED1016就没有能力对发送程序1018的通信进行解密，除非再次请求托管代理1006和1010的服务。作为一种次要的作用，对于无赖的申请来说，不可能欺骗LED1016取出无关用户的唯一密钥。
第二实施例要求托管代理1006和1010为在线的并且包括对新对话密钥的每次解密。这不能看作是一种缺点，因为托管代理1006和1010被作为克利珀尔创议一部分负责连续不断地工作。假定具有公共密钥解密的硬件支持，托管代理的在线秒钟之内响应，托管代理机构和LED之间的可靠通信应该足够容易地被提供。
3.第三实施例一数据恢复中心本技术的第三实施例适用于数据恢复中心(DRC)。第三实施例的目的是在丢失正常解密密钥的事件中能提供对被存储加密数据的紧急访问。不用密钥托管或托管代理机构，并且除了在初始化、注册阶段和紧急访问处理期间之外，不和第三方(具体地说为任何DRC)进行通信。
该实施例类似第二实施例，没有被托管密钥的数据库，因此也不存在被托管的密钥和托管代理机构。象第二实施例，本实施例的目的是解密服务。在为法律强制服务的第二实施例中，执行解密服务的实体被称为托管代理机构，即使它们并不执行托管功能。在本实施例中，为了吸引公司和个人的兴趣，执行解密服务的实体被称为DRCs。
图19给出了根据第三实施例的环境1902的方块图。环境1902包括位于被保护环境1904中的数据恢复中心(DRC)1910(可选择冗余)。被保护的环境1904由希望根据本发明第三实施例的原理提供服务的任何实体建立和维护。例如，被保护环境1904可由某个公共组织(例如某个州的汽车分部)或某个私人组织(例如某个公司)或公共/私人实体的多种组合建立和维护。DRC1910最好代表在某个适当装备的计算机系统上执行的软件。
功能元素1912(正常文件解密)、1914(文件加密)、1916(紧急文件解密)和1918(AR定义)代表在4个不同操作方式中的某个用户。在下面的描述中，这4个元素将分别被称为正常解密用户、加密用户、紧急解密用户和AR定义用户。应该理解这些用户不需要代表相同的用户。
在本实施例中，AR定义用户1918首先和DRC议定以得到DRC公共密钥(DRCpub)。AR定义用户1918接着建立某个访问规则(AR)定义并用DRC1910注册该AR定义。DRC1910将对应该AR的访问规则索引(ARI)送回到AR定义用户1918。AR定义用户1918接着将任何新的DRCpub、新的ARI以及附属的注释存储在AR文件1920中。
加密用户1914用存储密钥(KS)对文件F加密以产生被加密的文件C＝[F]KS。加密用户1914是希望加密数据并存储这些被加密数据的任何实体。例如，加密用户可以是运行在某个计算机上的某个商业软件程序(例如字处理程序、电子表格程序、数据库程序或通信程序等等)。
加密用户1914建立数据恢复域(DRF)，包括某个访问规则索引(ARI)和由DRCpub加密的KS。从ARI文件1920中检索到ARI和DRCpub的值。ARI值是由DRC1910在AR定义用户1918和DRC1910之间的初始化设置阶段期间产生的。DRF被附加到被加密的消息C上并由加密用户1914送到存储介质1922上。如果希望允许在后面的验证阶段中重构DRF，加密用户1914还产生DRF验证串(DVS)并附加在DRF上。(可选的)DVS包括用在DRF中、由存储密钥KS加密的ARI。
在该第三实施例中，加密消息和DRF被存在存储介质1922中，供正常解密用户1912或紧急解密用户1916检索用。通常，正常解密用户1912和加密用户1914为同一人，在不需要引用DRC的情况下访问存储密钥KS。
当紧急解密用户1916不具有对消息解密所需的KS时，就会出现紧急访问的情况。例如，这可能发生在这样的公司环境中，经理需要访问由某个雇员加密的数据，但该雇员不在场而且经理不知道该雇员的存储密钥KS。也可能发生在加密用户1914忘记KS或忘记产生KS和访问KS的正常方法的情况下。为了访问KS，紧急加密用户1916从存储介质1922中提取DRF并将其送给DRC1910。DRC1910用先前由AR定义用户1918在注册阶段定义、并由加密用户1914在加密期间选择的询问来响应，并且在紧急解密用户1916成功地满足询问时，将包含在相关DRF中的KS释放给紧急加密用户1916。在这种情况下，紧急解密用户1916一般可以被描述为对这些由加密用户1914首创的信息的某个特许方(例如管理机构)。
从一个更广泛的视角看，DRF中的KS能代表加密用户1914希望控制访问的任何一块秘密的信息。换句线检索之后KS的预期使用并不限于本实施例的使用范围。
数据恢复中心1910、客户1918和用户1916最好每个都代表根据控制器中的指令或集合操作的数据处理装置。(在某些实施例中，数据处理装置包括处理器，在这种情况下，处理器根据控制器的指令或命令操作)。在一个实施例中，控制器代表硬件状态机。在另一个实施例中，控制器代表采用可直接由计算机读出的某种电子/磁形式的计算机程序。该计算机程序最好做为计算机程序产品(例如其上具有用电子或磁性记录的控制逻辑的软盘)散布或者通过某个通信网络分布。
3.1数据恢复域这在头两个实施例中称为法律强制访问域(LEAF)，而在第三实施例中则称为数据恢复域(DRF)。因为在本实施例中紧急访问只被提供给紧急解密用户1916(例如加密用户1914本身或其雇主)，因此本实施例的最佳方式避免分割KS。显然，在其它的方式中，密钥分割仍然是加密用户希望的一种可能的实施方案。
应该注意，在其它的实施例中，KS不需要是存储密钥(即加密密钥)。DRF中的数据可以是加密用户1914希望加密和存储的任何数据。这样一种在DRF中的数据封装在功能上等同于利用随机产生的存储密钥(KS)对文件中的数据加密。随机产生的存储密钥(KS)被包含在附属于文件的DRF中并迫使文件的所有者做为紧急解密用户1916去访问该文件的内容。
同第二实施例的进一步比较是显然的，考虑n＝1和无KFpub加密的LEAF。在该例中，LEAF包括[KS1]EApub1，这里的[Y]X意味着用密钥X对Y加密。相比下，第三实施例的DRF由[ARIKS]DRCpub组成。在这里，由加密用户1914定义的访问规则(AR)的索引和由加密用户1914选择的存储密钥(KS)并置，然后用DRC的公共密钥DRCpub国密。如果加密用户1914将DRC1910看作潜在的敌人，可采用另一个实施例来实现的DRF包括[ARI1，KS1]DRCpub1，[ARI2，KS2]DRCpub2，…，[ARIn，KSn]DRCpubn在该替换的实施例中，至少需要n个KSi中的k个来恢复KS，并且n个DRC1910被分散，并且不受到(K-1)个以上方的合谋。将KS分解为若干份的任务由任何众所周知的保密共享机制实现。这样一种保密共享机制的例子在A.Shamir的“如何共享一个秘密”一文中被介绍，该文于1979年11月发表在ACM的通信(Communications of theACM)上，Vol.22，no.11，PP.612-613，这里将作为一个整体引用。
最后，由于DRF为加密用户1914本身提供了某种服务，没有必要强制形成其正确的结构。加密用户1914并不是故意要在所需的服务上设下陷井，利用自愿和可能支付的某些数量的钱得到这种服务。另外，基于某个不正确的DRF拒绝任何解密(正如在前两个实施例中一样)对存储加密都是一种不恰当的行为。在加密时毁坏的DRF以及在解密时检测不正确的DRF都是无效的。因此，在最佳实施例中，实施无DRF验证或采用背景“嗅探器”形式的验证。正如下面将进一步介绍的那样，“嗅探器”是这样一个处理过程随机选择文件，检查其DRF格式(利用DRC1910提供的格式检查服务)并且在发现不正确格式的情况下，将缺陷通知文件的创建者(以及可能向其经理)。这将在加密时或加密后不久提供适度的社会或管理压力以纠正错误，产生正确的DRF。产生不正确的DRF可能是由于意外的事故或疏忽出错引起的，而不是恶意的破坏。
3.2 DRF验证加密用户1914在不是有意破坏的情况下也可能使用这样一种软件，该软件没有将DRF附加在文件上(可能是因为当时不能作出这种选择)，或者错误地加上(由于软件中的某种缺陷)不正确的DRF，或者不正确地构造DRF。有几种供选择的方法能检测出这样的问题并且最大限度地减少由此所可能出现的损害。这些方法(如下所述)包括格式的嗅探、DRF的随机重构、由DRC1910随机验证，以及什么事也不做，即不执行验证(选取不验证已经讨论过)。由于访问DRF是很少发生的事件，在对坏的DRF的检测中的时间延迟都可能少于等待需要DRF的时间，因此允许加密用户1914有时间重新建立正确的DRF。
3.2.1对格式的嗅探一般来说，准备一个文件“嗅探器”程序是一种明智的做法，该程序扫描存储装置(例如存储装置1922)，读出记录和可能遇到的坏块。磁盘存储器可能在没读时就坏了，而当读它时才检测到坏块。如果在数据被写入后检测工作的时间被延迟太长，则这些数据的备份也可能已经变坏了。“嗅探器”企图在其备份变坏之前找出这些坏块。
和DRC1910在一起的“嗅探器”不但能检测坏的数据块，而且也能检查坏的格式的DRF。为安全起见，该背景处理不应该访问到被加密文件的位。例如，在一个实施例中，文件和“嗅探器”处理可以驻留在不受拥有数据的公司或个人控制的某个商业性的文件服务器中。然而，“嗅探器”能从文件(已经被修改为能识别其是否存在)中选择DRF，并将其送到各自的DRC1910中，从DRC1910中返回布尔回答信号，指示该DRF是否被正确加密。这样在被加密文件中检查出不合适的DRF格式或缺少DRF。
在另一个实施例中，这里的DRC1910被这样一种“嗅探”的工作解决了问题，“嗅探器”可比被程序设计为能选择某个伪随机数并利用该值来控制是否验证某个特定的DRF，其效果为所遇到的DRF中的只有某个百分比数目的DRF被验证。该百分比可以变化以调节DRC1910的工作负担。如果DRC1910回答说某个DRF是坏的，则DRC1910或“嗅探器”(或两者)能产生审查日志记录并将错误通知文件的拥有者(也可能是拥有者管理链中的其他人)。维护所要通知的人员各单以及发出该通知的方法通常被认为是程序设计的工作，这里将不做进一步的详细介绍。
3.2.2 DRF的随机重构“嗅探器”不能验证DRF中的存储密钥(KS)是否有效，因为它不能访问KS或解密DRF所需的专用密钥。如果DRF具有重构的形式(利用公共密钥算法直接建立DRF、而不是用公共密钥算法加密第二存储密钥KS2，这又被用来加密DRF的内容)，并且如果加密用户1914已经附加了DRF验证串(DVS)，则紧急解密用户1916/程序能通过重构它来验证DRF。在通过该处理过程检测错误的事件中，正常解密用户1916/程序将产生审查日志记录，并且，在一个实施例中，将消息(通过任何一种最佳的手段)送给文件的拥有者以及在公司管理机构中的其他人。然而，不象前面实施例的通信情况，在这种情况下拒绝解密是不合适的。拒绝对被存储的数据解密意味着失去对数据的访问，并且保护了对DRC1910打算提供的数据的访问。
由于这种重构是一种费时的操作，并且由于重构的目的是使加密用户1914对所用软件更加警觉，一个实施例预期解密软件重构仅仅重构随机选择的某个百分比的DRF。期望这种重构偶尔得到的知识足以提高加密用户1914的警觉性。
3.2.3 DRC的随机验证在替换的实施例中，DRF格式不允许重构。然而，即使这些格式能由解密程序验证，但DRC1910必须参加该验证过程。为此，可以按比其它类型的验证低得多的百分比随机选择这种DRF格式进行验证。
在涉及DRC1910的验证的一个实施例中，加密用户1914得到文件的紧急访问解密并验证该处理过程起作用。在另一个实施例中，在加密用户1914和DRC1910之间的相互作用在验证期间被降低。在该实施例中，在得到存储密钥(KS)并对文件解密之后，解密程序将KS和DRF一块发送到DRC1910，要求DRC1910仅对DRF解密并回答所发送的KS和DRF数据中的KS是否一致。
在这种情况下不要求访问规则询问和应答，因为做为外来者对文件获得访问的一种方法，这种方法相当于一种蛮干的密钥测试法，但在这种方法中，每次测试都涉及到通信费用，因此是缓慢的并且没有随着VLSI电路速度的提高而改进。受攻击的程序比其它的方法小，因此不存在越来越大的安全风险。
3.3访问规则本发明定义了两类访问规则(ARS)，基本验证测试规则和复合授权规则。AR是由定义它的AR定义用户1918指定的并将其送给DRC1910。作为响应，DRC1910授与AR定义用户1918访问规则索引(A RI)。因此，加密用户1914可用ARI来加入某个DRF，而AR定义用户1918可用ARI来定义其它的AR。AR定义用户1918和DRC1910之间的这种相互作用被称为注册阶段并在下面作更详细的描述。而DRC 1910又利用ARI来定位相关的AR并利用规则来控制对紧急解密用户1916的询问以制定解密器是否有权访问。
验证测试是相对简单的AR示例。如果紧急解密用户1916通过该测试，则该紧急解密用户1916得到访问权。更一般地，紧急解密用户1916接收访问或者接收用于响应其它询问的成功令牌。另一方面，复合授权规则指定一组ARI，其中的某些(或全部)需要被满足，才能使AR也被满足。
3.3.1验证测试在一个实施例中，基本验证测试包括证明某个用户身份的方法。具体来说，可能包括共享的秘密(例如母亲少女时的名字)、密码验证规约、第三方担保(例如提交供验证的数据的人是否有效地持有预先指定的驾驶执照并和执照上的照片、描述以及签名匹配)、生物统计测定(例如视网膜扫描)或任何其它的证明。
其它的验证测试包括多重提示/回答对。在多重提示/回答对中，AR定义用户1918可以指定一组N个提示及其相关的回答。AR定义用户1918也指定数字A和K(K≤A≤N)，使得当DRC1910进行验证测试时，它能随机选择N个提示中的A个来询问紧急解密用户1916。紧急解密用户1916企图对所有被选择的提示都提供正确的回答。如果紧急解密用户1916能给出K个以上的正确回答，则该验证测试被满足。提供给紧急解密用户1916的是这种有变化的共享秘密测试是不一样的，因为他们可能难以记住某个特定类型的串，但他们更可能记住其中A个中的K个。
最后，在共享秘密验证的一个最佳实施例中，为回答部分提供机密性保证。具体来说，不是将回答做为一个可读的文本串存放，而是在注册和对询问响应时，构造提示及回答的密码式坚固杂凑。这个杂凑值用ASCII码编码后送给DRC1910做为回答响应串。这种机密性允许AR定义用户1918在理论上能使用令人为难的(embarrassing)记忆作为一种回答，因为这种记忆不容易被忘记或共享。
3.3.2授权规则在一个实施例中，复合授权规则采用下面的形式[n，k，ARI1，ARI2，…，ARIn]；k≤n如果给定的n个ARI中有k个被满足，则该规则被满足。这些ARI所引用的AR可用AR定义用户1918建立，也可以由该AR定义用户1918所认识的其他人所建立。例如，可以建立一个AR来代表某公司集体紧急访问的授权规则，并且该ARI可比被列为每个雇员的一种可选择的应急访问方法。
具体来说，如果该公司有一个公司的ARI＝c，而雇员有个人的ARI＝e，则雇员可建立并使用的ARI＝u，定义u＝[2，1，e，c]。通过该定义，任何在其DRF中包括“u”作为ARI的文件都可以用在应急的情况下，只要满足雇员或公司的ARI。
应该注意到，n＝k的组等价于该组规则的逻辑与，这意味着所有的ARI都必须被满足。同理，k＝1的组等价于该组规则的逻辑或，意味着ARI中的任一个被满足就可以。而n＝1和k＝1的组则表示该ARI间接引用了另一个ARI。
3.4利用DRC访问实现数据托管DRC1910提供的紧急访问并没有代替对加密文件的正常访问。假定在不考虑DRF的情况下对存储密钥(KS)进行正常的访问。在这种情况下，正常解密用户1912和加密用户1914为同一个人，他具有存储密钥(KS)或具有不依赖KRC1910来得到KS的方法的知识，因此，在一般情况下，DRC1910将不知道加密用户1914已经为某个文件建立了DRF。然而，本发明允许一种新的存储加密，在这种加密中，存储密钥被随机选择(例如由加密程序随机选择)。结果，在本实施例中，唯一的访问方法是借助DRF的应急使用。通过适当地定义AR，这种方法允许加密用户1914实现一种数据托管机制，在这种机制中，数据的被授与者将一直采用加密的形式保存数据，并且仅当满足某个可能复杂的AR时才能接收使用这些被加密的数据。任何个人，甚至这些数据的最初加密用户1914，都不能在不满足该AR的情况下解密数据。为了实现这种方法，只需一个受托的DRC1910，除了满足相应的AR外，其从不释放被解密的DRF。除了下面对DRC1910的介绍之外，DRC1910也可以被密封在防窜改的外壳中并且不被定义为最优先的访问。在一个实施例中，受托的DRC1910通过冗余技术定义为高度容错的。
3.5最优先级访问在某些实施例中，提供了最优先级访问。具体来说，在对来自DRC1910满足某个AR的询问的响应中，被询问的紧急解密用户1916可以用“最优先级”应答。然后再根据为DRC1910定义的最优先级AR询问紧急解密用户1916。例如，最优先级AR可以要求预先被指定的5个公司办公人员中的3人同意最优选级访问。这样一种策略的定义是通过上述的(以及下面将进一步介绍的)访问规则机制来实现的。
让AR定义用户1918总是定义并使用如上所述的复合授权规则(例如u＝[2，1，e，c])也能取得同样的效果。然而，最优先级机制节省了AR定义用户1918的注册时间并保证监督实体(例如管理机构)能被允许访问所有的文件，而不依赖雇员方面的任何行为。
3.6 DRC的操作使用DRC1910所提供的紧急访问能力包括以下几个独立的步骤(1)注册，(2)列出所定义的ARI，(3)建立DRF，(4)紧急访问请求，(5)询问一应答规约，以及(6)接收并使用被解密的DRF数据。
除了这些步骤之外，应该注意到，进出DRC1910的信息通常都是保密的，因此，在最佳实施例中，DRC1910的实现包括对DRC1910和用户1916以及1918之间的所有事务的加密。为此，DRC的公共密钥(DRCpub)被用来将某个随机选择的线(或紧急解密用户1916)将被加密的对DRC1910的请求包括在其中，这是DRC1910将用于返回消息的回答密钥。除了机密性的问题之外，还有验证的问题。由于AR定义用户有1918通过在注册期间提供AR定义的方法定义本身，对于DRC1910/AR定义用户1918通信不需要存在进一步AR定义用户1918的验证。
然而，DRC1910本身要求通过众所周知的公用密钥方法进行验证。这可通过广泛地发布该DRC的公用密钥的方法来实现，即通过广泛被了解的或受托(或两者都有)的某个密钥利用DRC公共密钥上的各种通道或签名。如果AR定义用户使用某个不可靠的DRC公共密钥，则AR定义用户1918容易受到DRC1910不正当行为的攻击，并且无法为法律的纠正提供识别该DRC1910的令人信服的证据。
3.6.1注册DRC1910注册(即，让AR定义用户1918对DRC1910进行登记注册)包括建立AR以及由AR定义用户1918接收每个AR的访问规则索引(ARI)。图20一般地说明了AR定义用户1918和DRC1910之间的AR定义过程。在这个简介中，AR定义过程包括下面的步骤(1)AR定义用户1918将AR定义发送给DRC1910，(2)DRC1910将新的ARI发送给AR定义用户1918，以及(3)AR定义用户1918将该新的ARI和可选的解释性注释归档在AR文件1920中。
ARI是由DRC建立的一个值，使DRC找到对应ARI的AR定义。在最佳实施例中，ARI包括存放AR定义的一个地址。
该注册过程由图21的流程图进一步表示。在步2106中，AR定义用户1918得到DRC的公共密钥(这一步将在3.6.1节中描述)。在步2108中，AR定义用户1918选择所需的注册交互作用。这些注册的交互作用包括在步2112中得到新的DRCpub，在步2114中建立新的AR定义，在步2116中重定义现有的AR，以及在步2118中得到ARI的列表。获取新的DRCpub在3.6.1节中介绍，建立新的AR在3.6.1.2、3.6.1.4、3.6.1.5以及3.6.1.6节中描述，3.6.1.3节介绍重定义现有的AR，而3.6.2节中介绍获取ARI的列表。
3.6.1.1获取DRCpub在这里标记为DRCpub(0)的初始DRC公共密钥可从广告栏或其他人的消息中得到。公共密钥的进一步发送的安全性取决于对该初始密钥可信赖的程度，因为公共密钥验证技术不能达到绝对可靠的程度。而更确切地只能建立信赖的等效性。
DRC1910不时地产生新的DRC公共密钥，以便使在任一密钥下进行紧急访问的数据量达到最小。在一个密钥下能被访问的数据量越大，对于某个敌手企图破除该特定密钥的诱惑力就越大。DRC1910保存所有被产生的DRC公共密钥/专用密钥对，因此，解密用户能用这些DRCpub密钥中的任何一个初始化安全的通信。
在AR定义用户1918获取某个可靠的DRC公共密钥之后，DRC1910将该DRC公共密钥的签字后版本返回给AR定义用户1918(图21中的步2106)。在和任何AR定义用户1918的每次DRC1910交互作用中，最近的DRC公共密钥做为被附加到DRC的正常消息上的文本块被返回。根据AR定义用户1918的某个具体请求，其中，AR定义用户1918发送数学“i”(所需的密钥号)和“k”(旧的密钥号)，DRC1910将返回旧加密者选择的用前一个密钥DRCpub(k)签字的新密钥DRCpub(i)。
3.6.1.2建立某个新的访问规则图22说明了建立新AR的过程，从步2206开始，在该步中，AR定义用户1918将AR定义发送到记录该定义的DRC1910中。在步2208中，DRC1910将ARI返回给该AR定义用户1918。AR定义用户1918在步2210中接收该ARI，并且，在附加上由AR定义用户1918提供的某个可选的描述性注释之后，将该ARI记录添加到ARI文件里。ARI文件已经包括该DRCpub以及AR定义用户1918已经获得的任何其它的ARI。
3.6.1.3重定义现有的访问规则图23说明了AR定义用户1918希望改变某个现有的AR的定义的处理过程。虽然AR定义用户1918能随意产生新的AR。但是，当已经存在由某个给定的ARI加密的文件并且AR定义用户1918决定对这些现有的文件改变紧急访问过程时，就要求重定义。为了执行重定义，AR定义用户1918在步2306中将新的AR定义以及对应将被定义的AR的ARI发送给DRC1910。接着，在步2308中，DRC1910用附加在110的ARI上的AR询问AR定义用户1918。如果AR定义用户1918未能满足DRC1910发出的询问，则在步2110中拒绝重定义请求。如果AR定义用户1918成功地满足了该询问，则在步2312中允许AR定义用户1918改变对应该ARI的AR定义。因为在该实施例中，DRC1910记录了每个被定义的ARI的AR定义用户的1914网络地址，因此重定义的请求必须来自这些网络地址。
3.6.1.4第三方访问规则从AR定义用户的1914观点看，存在利用正常验证测试规则和组规则建立起来的第三方验证规则。例如，AR定义用户1918用某些人工服务注册，通过AR定义用户1914的驾驶执照或任何生物统计措施(例如掌纹、视网膜扫描等)得到验证。如图24所示，这种服务包括(1)接收AR定义用户的1914驾驶执照号(不必亲自到场)以及(2)产生只有服务2404能成功地满足的AR，(3)再接收其ARI。服务2404接着(4)将得到的ARI附加到该服务的ARI文件2406中的该AR定义用户1914的执照号的记录上，然后(5)将得到的ARI送给AR定义用户1918。AR定义用户1918将(6)为该ARI产生一个间接的AR(间接AR的定义将在下面更详细介绍)，(7)为该新的AR取得一个ARI，并且(8)将该ARI(现在属于AR定义用户1918而不是属于服务2404)归档在ARI文件2408中。
3.6.1.5定义授权(组)规则图25说明一个组授权规则的产生过程。首先，在步2506中，AR定义用户1918从自己的ARI文件中检索一个或多个将被包含在该组中的ARI。AR定义用户1918在步2508中将组定义中的这张表发送给DRC，一起发送的还有数字“k”，指出为满足该组而必须被满足的组元素的数目，并且在步2510从DRC1910中接收对应该组的ARI。最后，在步2512，AR定义用户1918将新的ARI存在客户的ARI文件中。
3.6.1.6建立间接访问规则如图26所示，间接AR的建立和上述的过程类似，只是引用了别的某些ARI。在这种情况下，其他人的2606 ARI将(1)从某些可靠的通信通道而不是从AR定义用户1914自己的ARI文件1920中得到。该处理过程的其它(2)-(4)步和上述的AR定义过程相同。
3.6.2列出被定义的ARIAR定义用户1918也可以要求列出由其定义的所有AR的状态。在一个实施例中，用网络地址标识AR定义用户1918。在其它的实施例中，可以利用AR及其专用于标识AR的归属而定义的ARI，也可以采用DRC1910常规所用的网络或通信连接的任何一种标识方法。然而，如果DRC1910被指定来屏蔽网络地址，则ARI也可用作所有者的标识符。在本实施例中，当要求列表时，拥有者提供其标识的ARI。DRC 1910接着将询问拥有者，以证明其身份(利用标识的ARI)，然后提供列表。
3.6.3建立DRF图27给出了DRF2730结构的最佳实施例。在该实施例中，加密用户1914的软件通过ARI2706(由加密用户1914选择，取决于加密用户1914所要使用哪个AR)和某些小的用户机密[US]2708的并置而建立DRF2730。US2708通常(但不限于)为文件对称加密的密钥(即KS)，但可以是加密用户1914想要加密的任何数据。这种并置的结果被称为DRF的内容(DRFC)2714。接着利用DRCpub对DRFC2714加密而产生被加密的DRFC(EDRFC)2722。EDRFC2722和唯一标识用于产生EDRFC2722的DRCpub的密钥标识符(KI)2712并置。在最佳实施例中，KI2712包括和DRCpub密钥数字2704并置的DRC[DRC ID]2702的网络地址。这个KI2712的一个例子为“，4”。
3.6.4紧急访问请求当紧急解密用户1916需要对某个其存储密钥已在DRF里面但不能对KS正常访问的文件进行解密时，可以使用附加在该文件上的DRF。更一般地，无论什么时候紧急解密用户1916需要被保存在DRF中的无论什么样的小秘密(即US2708)，紧急解密用户1916都可以向DRC1910发生紧急访问请求。
图28说明获得紧急访问的方法。首先，在步2806中，紧急解密用户1916从存储介质1922中提取被附加到所需文件上的DRF(如果需要的话，也可以是单独的DRF)，接着，在步2808中，将被提取的DRF发送给DRC1910。在步2810中，DRC1910发生由被提取的DRF中的ARI的AR定义所定义的询问。
再次参看图28，如果在步2812中，紧急解密用户1916不能满足询问，则紧急访问在步2814中被拒绝。如果紧急解密用户1916在步2812中满足询问，则DRC1910在步2816中将DRFC2714发送给紧急解密用户1916。紧急解密用户1916在步2818中接收DRFC2714并且在步2820中从DRFC2714中提取US2708。
在一个实施例中，最初建立文件和DRF的软件执行步2806和2820。在该实施例中，在文件(或数据库记录，或被加密的任何项目)中或旁边的DRF的定位是在某些应用软件的控制下实现的，而不是DRC1910或其加密用户1914实现的。
在一个实施例中，步2808至步2818由紧急解密用户1916的软件执行，以向DRC1910提供方便的和无缝的接口。在一个最佳实施例中，紧急解密用户1916的软件在步2806中将DRF写入文件并且在步2820中从文件中检索DRFC，允许纯为DRC客户的独立应用软件执行步2808至步2814。
根据一个实施例，步2808和2818利用为人们所熟知的方法提供安全的信息传输。最佳实施例用紧急解密用户1916随机选择的对话密钥进行对称加密。该密钥由DRCpub加密并和被加密的消息一块被送给DRC1910(和KI2712一起以识别所用的密钥)。该消息包括对DRC1910的一个命令，以利用某个给定的(随机选择的)密钥送回给紧急解密用户1916(步2818)。采用这种方。
