本发明一般涉及数据加密，更具体地涉及密钥托管和数据托管加 密。

被称为“克利珀尔创议”(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＝KS1 XOR 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)来执行加密和解密操作。加密 和解密算法的具体细节将不在本发明中介绍。

本文使用下述符号。

[a]b表示利用密钥“b”对“ a”加密；同样，加密(e，f)表示 利用密钥“f”对“e”加密。

{x}y表示采用为人们所熟知的过程，利用密钥“y”对“x”数字 签字；同样，sign(a，b)表示利用密钥“b”对“a”进行数字签字。

a|b表示“a”和“b”并置(连接)。

decrypt(m，n)表示利用密钥“n”对“m”解密。

extract(g，h)表示利用熟知的过程从并置的值“g”中提取“h”。

verify(a，b，c)表示利用密钥“c”验证签名“b”或“a”。

xor(o，p)表示用“p”按位异或“o”。

用在这里时，具有后缀“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通过数据总线1810 和其它设备连接。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)了。每个程 序例子必须用下面的数据初始化：

KEPFpub

KFpub

对该程序例子唯一的KUpub

对该程序例子唯一的UIP

S＝{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嵌 入。

让产品检索KUpub和UIP的另一种方法是让产品在初始化处理中 产生UIP和KU，并将所有的组成部分(UIP，KUpub和KUpriv)在 KEPFpub加密下送到KEPF106。在这种不同的方法中，KEPF106将 分裂KUpriv并将这两半送到托管代理机构110和114，对[UIP|KUpub] 和KUpub签字，并将{UIP|KUpub}KEPpriv送回给产品。

1.5发送程序的操作

如图7中的流程图702所示，发送程序124在步706中接收数据消 息M。在步708中，发送程序124和接收程序130利用任何熟知的过程 议定某个保密的对话密钥708。在步710和712中，发送程序124利用 保密的(或专用的)对话密钥KS加密并传送数据消息M。这个被加密 的消息C由[M]KS表示。

另外，在步710中，发送程序124通过在程序唯一公共密钥KUpub 下加密对话密钥KS，由此产生[KS]KUPpub。[KS]KUpub也被称为加 密的对话密钥或EKS。EKS和程序唯一标识符UIP并置因而产生 [KS]KUpub|UIP。该值由该公共密钥KFpub加密。所得的LEAF被符 号化为[[KS]KUpub[UIP]KFpub。请注意，在本发明中，M的加密是利 用对称加密实现的，而在密钥KUpub和KFpub下的LEAF中的加密则 是利用非对称、而不是对称密码技术实现的。

另外，在步710中，发送程序124产生的LEAF验证串(LVS) 包括：(1)发送程序124的程序唯一标识符UIP，(2)程序唯一公 共密钥KUpub，以及(3)通过密钥托管程序设计软件包106施加到这 两个量上的签名S，即{UIP|KUpub}KEPFpriv(这三项被称为页验证 串LVS)。该串在对话密钥KS下被加密，因此，ELVS表示如下：

[UIP|KUpub|{UIP，KUpub}KEPFpriv]KS

在步712中，C、LEAF和ELVS被送到接收程序130。

1.6接收程序的操作

如图8的流程图802所示，在步806中接收程序130和发送程序124 议定保密话路密钥KS(这对应图7中的步708)。在步808中，接收程 序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或UIP|KUpub|{UIP| KUpub}KEPFpriv。接着在步810中，接收程序130验证所接收到的发 送程序124的拷贝的程序唯一密钥KUpub和程序唯一标识符UIP(在 LVS中)是正确的可靠的。这将在步812中通过利用KEPFpub验证对 应的答名S或{UIP|KUpub}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免于被不和它进 行通信的同线用户发现。

1.7法律强制解密器

由法律强制机构操作的法律强制作解密器(LED)120包括族专 用密钥KFpriv(在图1中被表示为122)。其操作由图4的流程图402 所表示，LED120在步406中从KEPF106中接收KFpriv(对应图2中 的步220KFpriv在KEPF106中产生的情况；这里的KFpriv是由某个外 部实体在KEPF106的外面产生的(没有表示出来)，接着，外部实体将 KFpriv送给LED120)。在步408中，LED120将KFpriv存放在LED120 的存储装置中。

因为LED120有了KFpriv，因此LED130能对LEAF解密。这一 操作由图17中的流程图1702表示。在步1706中，LED120从发送程序 124中接收C、LEAF和ELVS。在步1708中，LED130利用KFpriv 对LEAF解密，并从被解密的LEAF(在图17中称为“plain-LEAF”) 中提取UIP。在步1710、1712、1714和1716中，LED120利用UIP 从各自的密钥托管代理机构110和114中得到发送程序124的唯一专用 密钥组成部分KUpriv1和KUpriv2。如果有一个密钥托管代理机构表示 不能找到对应UIP的专用密钥组成部分，则该LEAF无效(步1724)。 在步1718中，LED130最好利用某个熟知的异或操作组合KUpriv1和 KUpriv2以形成发送程序124的程序唯一密钥KUpriv。KUpriv在步 1720中被存储在LED120中。在步1722中，LED130用KUpriv对对话 密钥KS解密。另外，在步1722中，在给定KS下，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。在步1310 中，发送程序1018用密钥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＞0 LEAF结构的选择取决于是否需要KFpub加密的额外保护。然而，在某 些点上，当考虑到一个密钥的尺寸时，可能禁止在一个KFpub密钥下对 所有的碎片加密。

接着在步1312中，发送程序1018产生等于KS1和KS2的并置的页 验证串LVS。然后利用话路密钥KS对LVS加密而产生被加密的页验证 串ELVS。

在步1314中，C、LEAF和ELVS被送到接收程序1026中。

接收程序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做异或运算而产生对话密钥KS(在步1412中称为 “trial-KS”)。在步1412中，接收程序1024比较trial-KS和议定的 对话密钥KS。如果不相等，则说明LEAF是坏的并拒绝接收该消息(步 1418)。

如果相等，则在步1414中，接收程序利用KEApub1和KEApub2 的拷贝重新计算LEAF。这是通过利用KEApub1加密trial-KS1以及利 用KEApub2加密trial-KS2并由此分别产生trail-EKS1和trail-EKS2来 实现的。接着，通过trail-EKS1和trail-EKS2的并置计算出被称为test- LEAF的LEAF。

在步1416中，接收程序1024判断frail-LEAF是否等于LEAF。 若不相等，则拒绝接收消息(步1418)；若相等，则认为LEAF是有效 的并用KS对消息M解密。

法律强制解密器LED1016的操作如图15的流程图1502所示。在 步1506中，LED1016从发送程序1018中接收到C、LEAF和ELVS。 在步1508中，从LEAF中提取EKS1和EKS2。在步1510中，LED1016 将EKS1送到密钥托管代理机构(KEA)1006并将EKS2送给KEA 1010。另外，LED1016为每个托管代理机构1006和1010显露一个适 当的法院命令。每个代理机构1006和1010验证法院命令的有效性，记 录其有效日期，并利用对应特定法院命令的KEApriv1或KEApriv2产生 保密的密钥的一半KS1或KS2并发送给LED1016。这由步1512表示， 其中，LED1016从KEA11006接收KS1并从KEA21010接收KS2。 LED1016组合回送的KS1和KS2得到KS(步1514)，并利用KS对消 息解密(步1516)。

由LED1016对某个托管代理1006和1010提交的用于电话(电报) 线路窃取情报的密钥部分都必须由对应的密钥加密，当法院命令到期 时，托管代理1006和1010删除保密的密钥KS1和KS2，因此，在命令 到期之后，不能履行任何对密钥的请求。因为和托管代理1006和1010 的所有通信都必须被加密以便保密，这一处理并没有对操作增加执行时 间。

KEA11006的操作如图16中的流程图1602所示。KEA11006和 KEA21010是一样的，因此，下面的描述同样适合于KEA21010。在步 1606中，KEA11006从LED1016中接收EKS1。在步1608中，KEA1 1006利用KEApriv1对EKS1解密以得到KS1。在步1610中，KEA11006 将KS1发送给LED1016。

由于没有数据库链接某个UIP到任何为法院命令的目标的个人，托 管代理1006和1010没有别的选择，只能相信为某次特信定的电话(电 报)线路窃听任务法院命令所对准的个人相关的LED1016。上述的规约 可修改为在被送到托管代理1006和1010的LEAF部分中中入UIP，使 这些代理1006和1010能保持每次法院命令目标的程序例子列表供以后 的窃听使用。

该第二实施例的优点是，不向LED1016公开产品唯一密钥。一旦 停止监视，LED1016就没有能力对发送程序1018的通信进行解密，除 非再次请求托管代理1006和1010的服务。作为一种次要的作用，对于 无赖的申请来说，不可能欺骗LED1016取出无关用户的唯一密钥。

第二实施例要求托管代理1006和1010为在线的并且包括对新对话 密钥的每次解密。这不能看作是一种缺点，因为托管代理1006和1010 被作为克利珀尔创议一部分负责连续不断地工作。假定具有公共密钥解 密的硬件支持，托管代理的在线计算机系统可期望有0.2秒钟之内响应， 托管代理机构和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希望 控制访问的任何一块秘密的信息。换句话说，在被紧急解密用户1916检 索之后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由[ARI|KS]DRCpub组 成。在这里，由加密用户1914定义的访问规则(AR)的索引和由加密 用户1914选择的存储密钥(KS)并置，然后用DRC的公共密钥DRCpub 国密。如果加密用户1914将DRC1910看作潜在的敌人，可采用另一个 实施例来实现的DRF包括：

[ARI1，KS1]DRCpub1，[ARI2，KS2]DRCpub2，…，[ARIn，KSn]DRC pubn在该替换的实施例中，至少需要n个KSi中的k个来恢复KS，并 且n个DRC1910被分散，并且不受到(K-1)个以上方的合谋。将 KS分解为若干份的任务由任何众所周知的保密共享机制实现。这样一种 保密共享机制的例子在A.Shamir的“如何共享一个秘密”一文中被介 绍，该文于1979年11月发表在ACM的通信(Communications of the ACM)上，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)被用来将某个随机选择的话路密钥从AR定义用户1918(或 紧急解密用户1916)中送到DRC1910。此外，AR定义用户1918(或 紧急解密用户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列出被定义的ARI

AR定义用户1918也可以要求列出由其定义的所有AR的状态。在 一个实施例中，用网络地址标识AR定义用户1918。在其它的实施例中， 可以利用AR及其专用于标识AR的归属而定义的ARI，也可以采用DRC 1910常规所用的网络或通信连接的任何一种标识方法。然而，如果DRC 1910被指定来屏蔽网络地址，则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的一个例子为 “drc@tis.com，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定义所定义的询问。

图31说明由DRC1910执行的向紧急解密用户1916发生询问的处 理步骤。首先，在步3106中，DRC1910利用KI2712识别DRCpub， 然后，在步3108中，检索出对应特定DRCpub的DRC专用密钥。在步 3110中，DRC1910对EDRFC2722解密以便得到DRFC2714并且在 步3112中，从DRFC2714中检索出ARI2706。最后，在步3114中， DRC1910利用ARI2706定位对应的AR(例如存放在地址ARI中的 AR)并且在步3116中询问紧急解密用户1916。

再次参看图28，如果在步2812中，紧急解密用户1916不能满足 询问，则紧急访问在步2814中被拒绝。如果紧急解密用户1916在步2812 中满足询问，则DRC1910在步2816中将DRFC2714发送给紧急解密 用户1916。紧急解密用户1916在步2818中接收DRFC2714并且在步 2820中从DRFC2714中提取US2708。

在一个实施例中，最初建立文件和DRF的软件执行步2806和 2820。在该实施例中，在文件(或数据库记录，或被加密的任何项目) 中或旁边的DRF的定位是在某些应用软件的控制下实现的，而不是DRC 1910或其加密用户1914实现的。

在一个实施例中，步2808至步2818由紧急解密用户1916的软件 执行，以向DRC1910提供方便的和无缝的接口。在一个最佳实施例中， 紧急解密用户1916的软件在步2806中将DRF写入文件并且在步2820 中从文件中检索DRFC，允许纯为DRC客户的独立应用软件执行步2808 至步2814。

根据一个实施例，步2808和2818利用为人们所熟知的方法提供安 全的信息传输。最佳实施例用紧急解密用户1916随机选择的对话密钥进 行对称加密。该密钥由DRCpub加密并和被加密的消息一块被送给DRC 1910(和KI2712一起以识别所用的密钥)。该消息包括对DRC1910 的一个命令，以利用某个给定的(随机选择的)密钥送回给紧急解密用 户1916(步2818)。采用这种方式，紧急解密用户1916不需要为密钥 的传送而建立公共密钥。

3.6.5询问-应答规约

应答谒问的过程反映了相关AR定义的嵌套结构。图29表示询问- 应答周期。在步2906中，DRC1910发出询问(可以被看作是一种远程 过程调用[RPC])，而AR定义用户1918或紧急解密用户1916在步2908 中响应应该询问。图30将该周期表示为附属于某个紧急访问请求。

如果ARI标识的AR代表简单的验证测试，则紧急解密用户1916 具有提供正确应答的所有信息。然而，如果ARI标识的AR代表一个组 或间接的AR，则紧急解密用户1916需要执行非局部的任务以便得到正 确的应答。这种非局部任务将包括进一步嵌套RPC。如果ARI标识某个 间接，则RPC是从一个紧急解密用户1916到另一个紧急解密用户 1916。在不同情况中，RPC可以涉及网络通信，或只涉及软盘上用于传 送的数据(例如，该间接是用于物理的验证)。

对于DRC1910发出的每次询问，该DRC1910包括顺序记号 (SEQ)。SEQ是一个只有DRC1910才能解密的被加密数据，包括 带有事务号和基于SEQ内容的强检查和的询问递归栈(为了检查窜改行 为)。例如，如果ARI＝17标识了一个组，ARI＝5为一个成员，第一个 顺序记号将列出递归深度为1的表并且集[17]为栈。接着用列出该组成员 的组询问对紧急解密用户1916进行询问。解密用户1916选择其中的一 个来满足第一个，例如5，并递归地调用DRC1910来询问紧急解密用 户1916以满足ARI＝5。该递归调用包括用组询问提供的DRC1910的 SEQ。当DRC1910执行递归RPC时，调用紧急解密用户1916来满足 ARI＝5，该调用将包括列出递归深度为2和[17，5]和栈的SEQ。

在最佳实施例中，DRC1910在两个条件下对紧急解密用户1916 发生询问。在第一条件中，紧急解密用户1916提交紧急访问的DRF 2730。该提交不包括其它的信息并开始新的事务。如果该询问得到正确 的应答，DRC2730返回DRFC2714。

在第二个条件中，紧急解密用户1916提交将被询问的请求作为实现 某个组成间接询问的部分。这个提交包括识别该事务的SEQ和以该递归 询问作为一部分的递归栈。提交该请求的紧急解密用户1916和提交DRF 2730启动该事务的紧急解密用户1916不需要是同一个用户。如果该询问 得到正确的应答，DRC1910返回SUCCESS记号，其包括作为SEQ的 相同信息以及成功的事实。

为了响应简单询问(例如提示/回答或数字签名)，紧急解密用户 1916用SEQ和正确的应答。而DRC1910又提供了DRFC2714或 SUCCESS记号。

为了响应组或间接的询问，紧急解密用户1916提供了DRC1910 验证为该事务的一部分并且正确地满足该组或间接AR的一个或多个 SUCCESS记号。而DRC1910又提供了DRFC2714或SUCCESS记号。

此外，在最佳实施例中，为了避免使DRC1910或紧急解密用户1916 交叉在PRC上保持状态(即所有变量的内容，它们将由在从RPC中得 到回答和返回到该程序的调用者之间发出RPC的计算机程序使用， DRC1910包括具有它初始化的每个RPC的状态记号，而紧急解密用户 1916包括具有它初始化的每个RPC的状态记号。RPC的应答程序用其 应答返回该记号，如果存在任何这样的记号的话。这些记号是用仅为发 起人所知的一个密钥加密并且包含能使发起人验证该记号和伴随的SEQ 一致的信息。

结果，DRC1910和紧急解密用户1916的状态被维持在该PRC的 递归集上，在其中，调用者的身份保持更换管理。

3.6.6DRFC的接收和使用

如上所述，成功实现紧急访问的请求是将DRFC 2714返回给该紧 急解密用户1916。询问一应答的目的是验证发出该请求的紧急解密用户 1916被授权接收该DRFC2714。由于DRFC2714包括AR定义用户1918 的ARI2706，因此，任何能满足该AR2706的随后的紧急解密用户1916 大概已经被AR定义用户1918授权访问。

一旦DRFC2714被返回给紧急解密用户1916，该紧急解密用户 1916的软件负责利用该DRFC2714提供对该文件的访问(即，用于从 DRFC2714中提取US2708，并且也许利用US2708对其它的数据解 密)。另外，应该注意到，在其它应用软件中，DRFC2714本身可以是 所需的信息(例如某个安全的组合)。在这种情况下，在接收DRFC2714 的软件中不需要别的什么东西。

虽然上面已经介绍了本发明的各种实施例，但应该理解为这仅仅是 一些被提供的例子，而不是什么限制。因此，本发明的广度和范围不应 该被局限在上述的示例性实施例中，而只能根据下面的权利要求书及其 等同物来定义本发明。