加密API的模块化安全模型

加密API的模块化处理：对称密钥情况

1 引言

密钥管理，即密钥的安全生成、存储、备份和销毁，长期以来被认为是密码学所有实际应用中的主要挑战。为了实现高水平的安全性，实践中通常依赖于物理保护：将加密密钥存储在一种称为加密令牌的防篡改设备内，并仅通过应用程序编程接口（API）间接提供对密钥的访问（例如执行密码学操作）。加密令牌在实践中已得到广泛应用，涵盖从智能卡和U盘到功能强大的硬件安全模块（HSM）。它们被用于生成和存储证书颁发机构的密钥、加速SSL/TLS连接，并构成银行间通信网络的核心基础。

拥有令牌访问权限的用户可使用API在令牌上安全地执行密码学操作，例如使用存储的密钥集对用户提供的数据进行加密或认证。此类API的一个关键特性是支持跨令牌的密钥管理。我们重点关注密钥封装，即通过在已共享的密钥下加密密钥以在设备之间传输密钥的机制。

最后，该API通过属性和策略防止密钥的不安全或未授权使用。通过其API，整体分布式架构为密钥提供了更高水平的安全性，通过灵活的密钥管理简化了访问控制，并实现了模块化应用开发。

密钥管理API的设计与分析主要遵循工业标准，特别是PCKS#11[23],这些标准侧重于规定功能和互操作性。这些标准通常缺乏明确定义的安全目标，更不用说对任何安全声明是否合理达成进行严格分析。因此，正确的部署在很大程度上依赖于最佳实践（未在公共领域中记录）；此外，令牌经常遭受成功攻击[2–4,7]。这引发了一个问题：是否可以结合部分密钥可能泄露的现实情况，对加密API的安全性进行建模和模块化处理。

在密钥管理中使用的主要对称操作，即密钥封装原语，已通过适当的模型和高效实现得到了较为充分的理解[15,21,22]。然而，加密API的整体设计的安全性是一个更为复杂的问题，直到最近才受到关注[5,17,18]。现有的模型没有一个是完全令人满意的：它们要么过于具体化[5,17]；要么在规范不足的同时对PKCS#11的使用方式施加了不必要的限制[18]；或者回避了高度相关的自适应密钥泄露问题[5,17]。我们将在本文后面提供更深入的比较（第6节）。我们的模型自然且毫不意外地与以往工作共享了若干建模选择：我们使用图来跟踪有关哪个密钥加密了哪个密钥的信息；我们以类似的方式维护关于密钥、句柄和属性的信息。我们的重点在于模块化分析，其中密钥管理组件可以独立于使用这些密钥的密码方案进行分析，并且这一切都在一个合理的泄露模型下进行。

我们的贡献

我们为加密API提供了形式语法和安全模型，反映了从PKCS#11中提炼出的概念。我们力求达到一种抽象层次，既能支持常见的部署“最佳实践”（例如根据预期用途对受管密钥进行分层结构设计），又不会过度依赖于任何特定实现。我们的形式化方法捕捉了加密API暴露的核心对称功能。具体而言，通过API管理以及导出/导入加密密钥；以及在受管密钥下执行的密码学操作（例如加密），由应用程序通过API请求这些操作。

为了促进模块化分析，我们为密钥管理系统（即受密钥管理API调用影响其状态的抽象“后端”）建立安全性目标。这些目标对密钥将支持的具体密码学操作保持无关性。API暴露的密码学操作所依赖的原语也被抽象地处理，其对应的安全性概念同样如此。

我们的核心技术结果表明，正如人们所期望的那样，在满足某些条件的前提下，将一个安全的密钥管理系统与一个安全原语组合，能够得到一个整体安全的系统。值得注意的是，我们的组合结果在允许对受管密钥进行自适应泄露的情况下仍然成立；我们将在后文讨论如何克服在同一框架中整合组合性与自适应安全性的众所周知的困难。

我们还展示了如何基于确定性认证加密（DAE）实例化一个安全的密钥管理系统。DAE原语先前被提出作为一种安全“密钥封装”的方法，大致是指在另一个密钥 K2下对密钥 K1（及其关联数据）进行对称加密，主要用于在共享 K2的设备之间传输 K1。我们在此功能基础上构建了一个（最小化的）安全密钥管理组件，作为加密API的一部分，特别是具备密钥的分层结构的组件。下文将更详细地讨论这些贡献。

我们的语法和安全模型

我们对加密API的语法抽象地描述了以下能力：(1)在命名令牌上创建具有指定属性的密钥；(2)封装并随后解封装受管密钥，以在令牌之间进行外部传输；(3)在令牌之间直接传输密钥（无需封装或解封装）；以及(4)在用户指定的密钥下，对用户提供的输入执行（非密钥管理类）密码原语。这些操作均需遵守令牌所实施的策略。我们在模型中包含了对策略的依赖性，但未对其进行具体规定。

安全模型将这些能力暴露给对手，这些对手非正式地通过一系列API调用来尝试“攻破”令牌。具体而言，对手可以按需创建、封装和解封密钥，并在支持的密码学原语中使用这些密钥。通过允许对手在令牌之间进行密钥的直接传输（模拟在制造过程中或将密钥安全注入多个令牌的场景，或由安全人员操作），以及允许其自适应地破坏单个密钥，该模型捕捉到了现实中的多令牌环境。后一种能力模拟了某些密钥可能泄露的真实情况，例如由于部分安全漏洞或成功的密码分析所致。

在我们的模型下，安全性要求所有未被泄露的受管密钥（无论是直接泄露，还是通过巧妙的API调用间接泄露）都能够被密码学原语安全地使用。我们关注的是导出的原语而非单个密钥，这突显了密码令牌的存在理由：它们应确保对其所存储密钥执行的操作的安全性。

我们模型的一个显著特点是其通用性。我们并非仅针对加密API等特定情况提供模型，而是使用一种抽象的（对称）密码原语进行建模。简而言之，我们从任意（对称）原语的抽象安全定义出发，并将其扩展到API的场景中。这种通用化处理的好处在于，所得出的安全定义可以实例化应用于导出一大类对称原语（包括所有常用原语）。

组合定理

本文的主要技术贡献是对加密API的模块化处理。作为第一步，我们分离出密码令牌共享的核心公共组件，即密钥管理，并为其提供独立的安全模型。本质上，我们将密钥管理API（简称KM-API）定义为仅允许密钥管理操作的加密API。我们定义KM-API的安全性意味着任何未被显然泄露（直接或间接）的密钥都与随机值不可区分。

接下来，我们展示如何将一个密钥管理API与任意（抽象）原语进行组合。我们需要合理的语法限制，以确保组合具有实际意义（例如，密钥管理API所管理的密钥空间必须与对称原语所需的密钥空间相匹配）。更重要的是，我们所提出的方案要求每个密钥只能用于密钥管理或用于为原语提供密钥，而不能同时用于两者。许多现有针对API的攻击都是由于未能谨慎执行这种密钥角色分离所导致的。从技术上讲，我们通过PKCS#11标准中的一种机制来强制实施这一要求；我们的构造安全性在本质上验证了该机制的有效性。

简而言之，每个密钥都关联一个属性，以确定该密钥是外部的还是非外部的。我们通过要求该属性具有粘性来确保其具有预期的效果。这一概念形式化了PKCS#11非正式定义的属性完整性属性，保证一旦设置，属性值便无法更改。

以下定理确立了我们设计的安全性，使得两个组件可以分别进行设计和分析。

定理1（非正式） 。如果CA是安全的密钥管理API，且P是安全原语，则CA与P的组合（如上所述）是一个安全的加密API，可导出P。

重要的是，该组合定理适用于攻击者可以自适应地corrupt密钥的场景。我们的模型依赖于基于游戏的定义，这是我们用来协调组合性与自适应corrupt这两个特性的主要工具，而这两个特性在基于模拟的[6,20]模型中会引发众所周知的问题。

基于确定性认证加密的构造

我们证明了可以基于DAE方案构建安全的密钥管理API。具体而言，我们证明了当封装和解封功能由安全的DAE方案实现时，可以为强制执行密钥的分层结构的抽象“后端”安全地实例化一个 KM-API。在层次结构最底层的密钥仅用于为密码学原语提供密钥（我们称这些为外部密钥），而高于该层的密钥仅用于封装较低层的密钥（我们称这些为内部密钥）。一个密钥是外部还是内部，由该密钥的属性指定。要使用内部密钥 K2封装外部密钥 K1，需采用DAE方案的加密算法，并将密钥 K2的属性作为关联数据。（当然，密钥管理API只允许调用应用程序指明哪些密钥将被涉及，而不能访问实际的密钥值。）我们所提出的API设计确保了API策略将强制执行分层结构。

扩展

我们的最终目标是提供可用的安全模型，以促进在现实场景中对安全令牌的分析。本文中，为简化起见，我们仅关注API的对称方面；此外，我们对加密API的安全定义仅涉及其导出的原语。我们未涉及可由令牌策略强制执行的其他属性，例如内部策略可能将操作限制为已登录令牌的认证用户。此类策略在依赖令牌的应用程序逻辑中起着重要作用。尽管如此，我们认为我们的模型为后续扩展提供了一个合适的起点。事实上，我们已经引入了属性，并使用了一种非常简单的策略来确保组合的安全性。我们将识别和形式化其他PKCS#11属性的预期语义以及扩展至公钥功能视为一个开放问题。

2 密码学原语

在本节中，我们提供了一个抽象框架，用于描述密码学原语，该框架涵盖了加密和消息认证等常见目标。我们的抽象是专门为后续定义（第3节）和构造（第4节）加密API而设计的。因此，尽管我们的抽象具有相当的通用性，但关于在框架中应抽象哪些内容以及应显式表达哪些内容的选择，都强烈地受到后续上下文的驱动。

标准的加密和认证概念（例如IND-CPA和EUF-CMA）通常基于单密钥进行定义，且很少考虑该单密钥的corrupt：这通常会使安全游戏变得平凡（要么攻击者轻易获胜，要么从信息论角度上获胜根本不可能）。在单密钥安全模型中显式引入corruption有助于过渡到多密钥场景（这是更一般的API环境所必需的）。文献中也存在真正的多密钥定义（例如针对密钥相关消息安全性），但由于技术原因，我们需要一种由单密钥定义诱导出的模块化多密钥定义。

语法

原语P由一对无状态随机算法（KgP,AlgP）定义。算法KgP以参数pm作为输入，并从某个密钥集Keyspm中生成一个密钥；此处的分布可能依赖于该参数（例如，使用的密钥长度）。算法AlgP实现原语的功能，以密钥和主输入in作为输入，并生成输出out。在不失一般性的前提下，原语的定义仅需一个形式化算法。如果某些功能自然地需要通过多个算法来实现（例如，分别用于加密和解密的算法），则可以通过在输入到AlgP的数据上添加标签以指示应执行哪一个具体算法，从而将这些算法全部“打包”进AlgP中。这意味着我们的框架也能够涵盖需要支持多种“类型”原语（例如，同时支持加密和MAC）的情况，因为所有相关的算法都可以被整洁地打包进单个AlgP中（对于该算法可以定义多个不同的安全概念，例如，一个用于机密性，另一个用于真实性）。

正确性

正确性通常被定义为对涉及定义原语的算法调用序列的一种要求。例如，在相同密钥下，对任意消息进行加密，随后解密所得密文，应返回原始消息。定义1在任意原语的背景下捕捉了这一思想。为了通用性，该定义在包含多个密钥的场景下进行表述。

我们考虑一个对手，它可以通过预言机 new创建其选择的原语密钥，并通过预言机alg使用密钥 Ki的索引 i调用原语的算法。实验维护一个列表tr以记录执行轨迹：轨迹中出现三元组(i, x, y)表示算法AlgP在密钥 Ki上以输入 x被调用并返回 y。原语P的正确性由应用于执行轨迹的谓词corrP来刻画。通常 corrP是单调的：对于空轨迹初始为真，一旦变为假，则始终保持为假。

图1. 实验 Exp corr P P(A)（含预言机），用于定义原语P =(KgP,AlgP)的正确性。

定义1. 设(KgP,AlgP)实现一个原语P，其密钥集为Keys ⊇⋃pm[Keyspm]。设corrP 为一个正确性谓词， A为一个对手，则对手 A相对于(KgP,AlgP)和谓词corrP
的错误优势定义为
Advcorr P corr P
for the experiment Expcorr P P(A)如图1所示。
我们称P关于corrP是正确的，当且仅当对于所有（终止的）攻击者而言，其优势 为0。

安全性

接下来，我们引入一种用于指定对称原语安全概念的形式化方法。我们首先考虑单密钥的情况（将其与索引1相关联），然后将该形式化方法扩展到多密钥的情况。

单密钥场景

原语P的一个安全概念由四个算法sec=(setup,chal0,chal1,chalaux) 给出。非正式地，这些算法定义了两个实验Exp 1sec(pm)-0 P和Exp 1sec(pm)-1 P，它们通过以下方式刻画安全性

一个试图区分这两者的对手。两个实验均通过算法setup初始化来维护一个状态st。在实验Exp1sec(pm)-b P(A)（其中b为0或1）中，对手只能通过其挑战预言机 chalb和辅助预言机 chalaux间接访问算法AlgP。这些预言机的行为由算法 chalx（对于相应的 x ∈{0, 1,aux}）定义，该算法既能访问游戏状态，又能通过预言机访问实际原语算法AlgP。我们的形式化方法推广了许多密码学原语安全性的标准定义，其中对手需要区分两个“世界”（在此由预言机 chalb对应 b= 0,1建模）。例如，为了定义概率性对称加密方案在选择明文攻击下的不可区分性，我们将预言机 chalb实例化为一个左右预言机，该预言机接收一对消息 m0, m1，检查它们是否具有相同长度，并返回对 mb的加密结果。预言机 chalaux将允许对手查看其任意选择的消息的加密结果。针对选择密文攻击的安全性可以通过让预言机 chalaux也能响应解密查询来实现。

不失一般性，我们假设 chalx 至多对AlgP 进行一次调用。游戏的状态允许算法 chalx 抑制或修改AlgP 的输出，例如避免将挑战密文的解密结果直接提供给对手。当然，一系列对 chalb 和 chalaux 的调用如何相互作用取决于具体的安全游戏。

我们的模型允许对手corrupt密钥。将algorithm chalb 与作为chalb接口的 oracle chalb区分开来，使我们能够显式地处理泄露问题：如果密钥被泄露，接口 chalb将抑制算法chalb的输出。我们使用集合 H记录密钥是否在某个挑战预言机 chalb中被使用，并使用集合 C记录其corruption状态，然后通过适当的检查防止平凡胜利。

多密钥场景

当在令牌中使用时，原语实际上处于多密钥环境中。展望未来，我们对加密API安全性的定义本质上是从上述独立场景中原语的安全性出发，推广到在此类更复杂的场景中使用时的情况。

3 加密API

加密API是不可信使用环境与可信环境之间的接口，该可信环境用于存储密码学对象（例如密钥）并执行密码学操作（例如加密）。在实践中，可信环境通常以硬件令牌或硬件安全模块的形式实现；我们将这种可信环境简称为令牌。

用户可以通过加密API请求令牌代表其执行密码学操作。在典型场景中，用户还将通过指定一个或多个密钥的句柄来控制所使用的密钥。然而，密钥的密码学值（存储在令牌上）应对用户及外界保持隐藏。

为了保护导出和导入的密钥的机密性和正确使用，令牌采用密钥封装和解封装机制。在同一个密码生态系统中通常存在多个令牌。在这种情况下，密钥可以通过API从一个可信令牌导出到另一个可信令牌。因此，我们的抽象包含（一组最小的）显式密钥管理功能，以及用于使用某个特定密码原语的接口。

加密API的最终目标是正确且安全地实现某种密码原语，本节的主要目标是给出正确性（定义3）和安全性（定义5）的适当定义。这些定义建立在第2节中密码原语的抽象概念之上。

如引言中所述，本文的重点是加密API共有的与密钥管理相关的方面。例如，在封装密钥时，期望在解封装后能恢复原始封装密钥（正确性），并且该密钥未泄露（安全性），例如不会因封装过程而导致密钥泄露。我们为加密API的密钥管理部分提供了单独的一组相关概念（定义4、6和7）。

3.1 建模与语法

令牌、句柄、密钥和属性 。形式上，我们将令牌 t 建模为具有一些抽象状态 s ∈ States 以及多个相关联的句柄。为简便起见，我们假设令牌身份 t 是一个（唯一）自然数，并令

令牌的初始状态仅包含此身份。当对令牌进行API调用时，其状态可能会任意演变。

句柄属于某个句柄集Handles（该集合本身可被视为{0, 1}∗的某个固定有限子集）。每个句柄隶属于一个唯一的令牌，由tkn(h)标识，并指向一个实际的密码密钥值，记为 h.key。由于密钥将存储在令牌tkn(h)上，因此 h.key所表示的值取决于该令牌的状态。由于此状态不是静态的， h.key可能随时间变化。

不同的符号表示法tkn(h)与 h.key反映了句柄相关属性之间的区别：前者是与句柄关联的不可变属性（可能用于密码游戏中的记录管理），后者是API直接关联到句柄的可变量。

句柄与加密密钥之间的关联通过一个属性进行标注，记为 h.attr。例如，该属性可以表明该句柄指向一个128位AES密钥，且仅用于某种特定的操作模式，例如CBC-MAC。

与密钥类似，属性也将存储在加密令牌上（并且可能会随时间改变）。我们将假设 h.attr ∈Attributes，其中Attributes是某些固定的可能属性集合。

注意，抽象为单一属性并无损失通用性，因为可以通过单个属性（在这种情况 下为真/假向量）来表示传统意义上的多个布尔属性。

我们的模型是有意抽象的，但值得牢记实际中使用的典型实现。例如， PKCS #11 对“对象”的依赖意味着令牌的状态将包含一个从句柄到密钥-属性对的映射，以及帮助令牌维护安全策略的附加信息。因此，对于大多数API，可以将状态显式地写成 s=(s˜,(h →(key a))h) 的形式，其中对于每个句柄h，映射 h →(key a) 表示关联的密钥和属性对（即h.key=key 且 h.attr= a），而状态 s˜仅包含令牌过去输入/输出的一个快照（原则上该快照可公开而不影响核心密码安全性）。

应用程序编程接口（API） 。每个令牌都运行一个API，允许外部世界与该令牌上的密钥集进行交互。定义2列出了我们的抽象API所支持的过程。直观上，每个API过程都有明确指定的目标。例如，存在一个API调用 CA.new(t, a)，该调用旨在在令牌上创建新密钥 t并返回一个新句柄 h，使得 h.密钥 是此新生成的密钥，且h.attr= a。此处的新鲜性是全局的，意味着该句柄尚未在其他地方出现，因此句柄可以唯一关联到一个令牌（显式地将令牌身份嵌入句柄中可有助于实现全局新鲜性）。尽管语法保证了API调用返回的句柄的唯一性，但并不能保证API调用的行为符合预期（除非后续引入的正确性属性可能隐含此类保证）。

定义2。 加密API 证书颁发机构 导出原语 原语P （参见第2节）由以下算法元组定义。

– h←$ CA.new(t, a) 在令牌 t 上创建并返回一个新句柄，因此 tkn(h) = t；其含义是 h.attrib = a 且 h.key 是根据某个分布从密钥集 Keys 中生成的新密钥，该分布可能依赖于 a。

– h←$ CA.create(t, key a) 在令牌 t 上创建并返回一个新句柄，因此 tkn(h) = t；其含义是 h.attrib = a 且 h.key 等于输入的 key=。

– w ←$ CA.wrap(h1, h2) 接收两个句柄作为输入，并在其第一个句柄的令牌 tkn(h1) 上运行。它返回某个 w ∈CWraps，其中 CWraps 是所有封装的集合。据称 w 是在密钥 h1.key 下对h2.key 并绑定属性 h2.attr 的一个密钥封装。

– h←$ CA.unwrap(h, w, a) 接收一个用于解封装的句柄、一个封装 ¯ 和一个属性字符串作为输入。如果解封装成功，则在 ¯ ¯tkn(h) 上创建一个新句柄 h 并返回。其含义是 h. attrib = a 且 h.key 等于在密钥 h.key 下被封装的原始密钥。

– out ←$ CA.alg(h,in) 意图是在密钥 h.key 上对原语 AlgP 应用输入 in 进行计算，并输出 out。

任何调用都可能导致API错误 ⊥api。仅用于密钥管理的API可以省略过程CA.alg。

上述所有命令（除了CA.create）均反映了用户在使用令牌时通常可用的接口。我们使用CA.create作为将密钥从一个令牌传输到另一个令牌的各种（通常是非加密的）机制的抽象。例如，在生产阶段，相同的加密密钥可能会被注入多个设备中（这些设备由同一公司使用）。

API 的过程仅直接操作 one 个令牌的状态，相关令牌要么通过 API 调用显式指定（CA.new 和 CA.create），要么由涉及的句柄决定（例如， CA.wrap(h1, h2) 可能影响 tkn(h1) 的状态）。为了可读性，我们将令牌的状态保持为隐式，并仅强调这些命令不得依赖或修改另一个 令牌的状态。

策略与属性。 为了保护密钥安全，API将强制执行一项策略。例如，API可能禁止将用于认证的密钥用于加密。为了表明某项操作不被允许，API调用可以返回一个策略错误消息（这与解密无效密文等操作可能产生的其他错误消息不同）。为简化起见，我们将使用一个1符号 ⊥api来统一表示所有可能的策略错误。

我们不会对构成策略的内容给出形式化定义。实际上，我们模型的抽象层次使得精确而通用地界定策略概念变得有些繁琐。在实际的多令牌环境中，使用属性有助于在多个令牌之间强制实施一致且高效的策略实现。我们将在第4节中看到一个具体的例子（见定义8）。

我们模型的一个扩展可以考虑更细粒度的错误级别，识别为何某个操作会导致错误。

API 还可以利用令牌的状态来做出此类决策（例如，防止将敏感密钥封装在被视为不安全的密钥下，或避免循环依赖）。例如，一个令牌可以记录所有曾经对其发起的调用（包括响应）（注意，除了key值之外，CA.create查询的信息外，这些信息都可以公开）。如果仅存在单个令牌，这将形成 API 使用的完整历史，足以（尽管效率较低）实现有意义的安全策略（参见[5]）。

强制语义 。到目前为止，我们的语法并未形式化地保证 h.key和 h.attr被API以明确且有意义的方式使用。我们对状态概念的通用性允许某个API声明某个密钥为 h.key，但实际上却在整个过程中使用完全不同的密码学值。KSW定义与我们的工作类似，也采用了抽象状态，同样存在这一问题，但未加以解决。

由于完全抽象地工作（例如，不对状态做任何假设）似乎很容易导致困难而没有明显的收益，因此我们对实现做出明确的假设。我们即将提出的正确性概念将封装机制视为在令牌之间传输密钥的一种手段。请注意，封装涉及 h. key，其中 h是“源”句柄，并且只是隐式地涉及相关联的密钥。由于我们希望反映实际密钥被转移的事实，因此需要明确假设封装与实际的加密密钥相关联。类似地，我们还明确假设API导出的密码学操作使用了实际密钥。这一假设有助于定义和分析密钥管理API与实际原语之间的组合。此外，我们将使用属性来创建策略，以区分可以被原语使用的密钥和不能被使用的密钥。这种轻微的通用性损失使得定义和分析更加简单，同时仍然几乎反映了实践中常用的全部设计。

3.2 加密API的正确性

在本节中，我们提出加密API的正确性定义。大部分讨论和形式化内容与后续章节相关，因为在定义安全性时，我们都会解释如何将第2节中的原语定义提升到API导出的原语上。

主要难点在于对手针对原语和针对API导出的原语时，二者接口之间存在一个重要差异。在第2节中，原语正确性被建模为对手执行轨迹上的一个谓词，该轨迹记录了生成的密钥以及对手使用这些密钥执行的密码学操作。关键的是，轨迹仅包含密钥索引，而不包含其密码学值。相比之下，针对API的对手使用API提供的句柄来引用底层密钥。需要注意的是，这种差异更为深远，因为多个句柄可能指向同一个加密密钥。

为了弥合这一差距，我们引入一个映射，将每个句柄关联到某个索引。我们引入的映射idx反映了具有相同索引的句柄关联着相同的加密密钥这一思想。

形式上，在定义对手用于与加密API交互的预言机时，我们显式地跟踪与句柄相关联的索引——我们将在下方解释我们的 modeling 方法。然后，我们通过（本质上）在执行轨迹中用其关联的索引替换句柄，将定义从原语提升到API导出的原语。我们将在下方详细说明我们的方法。

按等价类索引句柄

对于每个句柄 h，我们将在其创建后立即分配一个索引 idx(h) ∈ N，该创建操作紧随某个密钥管理操作之后。此索引方式诱导出一种等价关系：两个句柄 h1和 h2是等价的当且仅当idx(h1)= idx(h2)。我们的目标是确保如果两个句柄预期具有相同的关联加密密钥，则它们应属于同一个等价类。请注意，我们旨在全局范围内保持此属性，即从句柄到索引的映射是“全系统范围”的，并不限于某个特定令牌。

图3. 用于定义加密API CA正确性的实验 Exp corr P CA P 和 Exp corr km CA(A) 中所使用的预言机。加框的行仅与涉及 corrkm 的实验相关。

形式化定义。 我们对密钥管理（图 5）和导出原语的API（图4）正确性的形式化定义使用图 3中的预言机来模拟对手通过密钥管理命令与API的交互。每个预言机反映了API的行为，并包含记录管理，这些记录管理

我们通过维护和为句柄分配等价类来实现。使用这些预言机的游戏会维护一个全局变量 i（初始值为0），用于统计等价类的数量。

创建新的等价类的唯一方法是通过 new预言机：每当成功调用预言机 new（即未返回 ⊥api）时，我们递增 i，并将其分配为所返回句柄的句柄索引。

可以通过调用 transfer或unwrap预言机将句柄添加到等价类中。

如前所述， transfer预言机用于引导目的：为了在一个令牌上创建封装然后在另一个令牌上解封装，这两个令牌必须已经包含相同的密钥。预言机 transfer对这种¯能力进行建模：指向被传输密钥的句柄 h与指向原始密钥的 h具有相同的索引。

处理通过解封装创建的句柄需要更多的记录工作。我们使用集合 W（初始为空）来维护由 wrap 预言机创建的所有封装及其涉及的句柄：如果 h1, h2, w 是将与 h2 相关联的密钥用与h1 相关联的密钥进行封装的结果，则将该三元组添加到 W 中。当调用 unwrap(h, w, a) 时，我们使用 W 来测试 w 是否是通过将某个 h2 用等价于 h 的句柄 h1 进行封装而生成的（集合 S 包含所有此类 h2）。如果是这种情况（即 S 不为空），则新返回的句柄等价于 h2 ，因此被赋予相同的索引。如果某个封装 w 被多次创建，则使用最小的可用索引（如果密钥管理组件是安全的，则不应能在非等价的句柄下创建相同的封装）。如果 S 为空，则表示该封装 w 是由攻击者生成的；由于我们在定义加密API的正确性时不考虑不诚实的攻击者，因此我们设置标志 bad 以触发对抗性损失。

有效轨迹

对手对算法 CA.alg（通过其预言机 alg）的调用记录方式，与原语正确性实验中的记录方式类似（图1）。为了考虑通过等效句柄使用相同密钥的可能性，我们通过句柄的索引 来标识密码操作中使用的密钥。对于 alg 调用，该导出的索引恰好与我们在多密钥原语定义中所使用的算法索引相匹配。

定义3 。设API CA[P]实现了一个原语P，并设corrP为一个正确性谓词。那么关于corrP， A相对于CA[P]的错误优势定义为
Advcorr P corr P
对于实验 Exp corr P CA P 如图.4所示。我们称 CA[P]关于 corrP是正确的，当且仅当对于所有（终止的）攻击者而言，其优势为0。

注意，正确性实际上只意味着一致性，并未包含鲁棒性。无法保证一个成功被封装的密钥实际上可以被

图4. 实验 ExpcorrP CA P 用于定义导出原语P的密码学API CA 的正确性，基于正确性谓词 corrP。攻击者还可访问图3中给出的预言机。

完全不进行解封装，或原语API调用将导致对该原语的求值。在这两种情况下，策略很可能会导致 ⊥api，此时正确性游戏实际上会忽略相应调用的输出。一个极端的例子是，始终返回 ⊥api的加密API被认为具有正确性。

3.3 API密钥管理的正确性

对于上述正确性定义，我们仅直接关注最终的原语调用，而忽略了密码密钥值。然而，直观上，如果两个句柄是等价的，人们可能会期望它们关联的加密密钥是相同的。这一直观想法由图5中描述的实验所捕获，其中对手试图找到一个指向与该句柄索引相关联密钥不同的密钥的句柄。

图5. 用于定义加密API CA的密钥管理组件正确性的实验 A。对手可访问图3中给出的预言机。

定义4（密钥管理的正确性） 。设CA为一个密钥管理API， A为一个对手。则 A针对CA的密钥正确性的优势定义为
Advcorr km CA(A)= Pr[Exp corr km CA(A)= false]
for the experiment Exp corr km CA(A) as given in 图.5. We call CA key-correct iff for all (终止) 攻击者 优势 是 0.

请注意，加密API的密钥管理组件的正确性与属性无关。对于已部署的系统，通常等效的句柄会使用不同的属性进行关联；此外，这些属性可能会随着时间而改变。尽管如此，某些属性不应轻易被对手更改。例如，不应允许更改将密钥声明为“敏感”的属性（PKCS#11术语）。

这涉及众所周知的粘滞性概念，我们将在后文（定义7）中给出其形式化定义。

密码学密钥封装假设 。定义2提到，CA.wrap 应当将与 h2.attr 相关联的 h2. key 用密钥 h1.key 进行封装。这隐含地假设了：知道 w和 h1.key 就足以确定 h2.key。对于大多数实际使用的方案而言，这确实是成立的，但从我们的抽象语法中无法逻辑地推导出这一点（即使考虑了密钥管理组件的正确性）。

假设2 形式化了如下思想：一个诚实且成功生成的封装 w ← CA.wrap(h1, h2) 包含了足够的信息来恢复被封装密钥 h2.key，前提是已知用于封装的实际密钥 h1.key 以及封装命令中句柄所关联的属性 h1.attr h2.attr。
因此，我们将把注意力限制在满足密钥封装假设的方案上（这对我们在接下来的章节中考虑的安全概念有直接影响）。

假设2（密钥封装假设） 。一个加密API CA满足密钥封装假设，当且仅当存在一个提取器 U，能够从封装中提取密钥。具体而言，对于所有 w ← CA.wrap(h1, h2) w =⊥api，在调用时，若key1= h1.key和key2= h2.key成立，则 U(w, key1, h1.attr h2.attr)以概率1输出key2。

3.4 密码学API的安全性

我们将考虑三种类型的安全性。我们主要关注的是导出原语的安全性（定义5），次要关注的是API内部管理的密钥集的安全性（定义6）以及属性的完整性（定义7）。定义这些概念的各种安全实验依赖于一组共同的预言机，如图6所示。

除了 corrupt和attrib之外，这些预言机与正确性游戏中的预言机（如图3所示）相同，但具有更复杂的内部记录管理，其原理将在下文解释。预言机 new和 unwrap包含一个宏initclass ，该宏将根据具体的游戏进行定义。

图6. 用于安全实验Exp sec‐b CA P 、Exp km‐b CA(A) 和 Exp sticky CA(A) 的公共预言机， 适用于导出 P=(KgP,AlgP) 的加密API CA。宏initclass 针每个实验分别定义。

被腐蚀和受损的句柄

我们之前在讨论API的正确性游戏时已解释过，“诚实” 的封装/解封装查询会在句柄上诱导出一个等价关系，且句柄的等价类可以通过索引表示（并维护）。为了定义API的安全性，我们还必须考虑可能主动试图破坏系统的攻击者。除了不诚实的API调用（例如，请求对对手创建的封装进行解封装）外，我们还将对句柄的泄露进行建模。当对手泄露一个句柄时，该句柄关联的加密密钥将返回给对手。请注意，API本身并不知道泄露情况。此外，泄露和（不诚实的API）调用往往会相互加强，我们通过“受损句柄”来对此建模，即那些可以合理假设对手已知其对应的密钥的句柄。“被腐蚀和受损的句柄”这一概念基于与Cachin

加密API的模块化处理：对称密钥情况

3 加密API（续）

3.4 密码学API的安全性（续）

和Chandran[5],以及Kremer等人[18]所使用的思想类似的理念。

泄露 。加密API的前提是密钥应保密并安全存储——对手无法访问加密密钥。然而，在实践中，最初在硬件安全模块（HSM）上安全存储的密钥可能会被导出到较弱的令牌中，而这些令牌可能通过物理手段（例如侧信道分析或故障注入）被泄露。因此，对手可以获取这些密钥。此类密钥的泄露通过泄露进行建模：对手可以发出对某个句柄的泄露请求，以获取相关联的密钥。通常情况下，无法保证已被泄露的句柄的安全性（参见原语P的安全游戏）。此外，一个句柄的泄露会自动导致该句柄所属等价类的泄露（因为等价的句柄被认为指向相同的加密密钥）。我们令 C表示对手通过发出泄露查询直接泄露的句柄所对应的索引集合。

受损句柄 。对手可以发起查询 wrap(h1, h2)，从而获得封装结果 w =⊥api。随后对 h1的泄露也可能导致 h2的泄露。实际上，假设2指出，只要掌握了封装密钥，就足以解封装（并获知）被封装密钥，从而使 h2的泄露不可避免。因此，少量密钥集的泄露可能导致更大规模密钥集的泄露。

我们令 L(C) 表示对应于受损句柄的索引集合（其中 C ⊆ L(C)）。为了准确定义受损等价类的集合 L(C)，我们通过一个有向图 (V, E) 来追踪哪个密钥（句柄）封装了哪个密钥。该图的顶点由与句柄相关联的等价类定义（因此是自然数集的一个子集）。当且仅当存在句柄 h1, h2，满足 idx(h1) = i 且 idx(h2) = j，并且对手发起了查询 wrap(h1, h2) 并收到结果 w =⊥api 时，图中才存在一条从 i 到 j 的边。对于给定的图 (V, E) 和被泄露集合 C ⊆ V，我们定义 L(C) 为所有可以从 C 到达的顶点集合（包括 C 自身）。

恶意封装 。由于封装只是一个比特串，对手可以尝试解封装某个并非由API本身生成的 w （即 S= ∅在 unwrap(h, w, a)中）。如果解封装成功并返回一个新句柄，安全游戏需要将该句柄关联到某个等价类。我们将考虑两种选项。

首先，解封装可能是在一个未被泄露的句柄下执行的（直观上，这对应于一次封装伪造）。在这种情况下，解封装返回的句柄将被视为创建一个新的等价类。从技术上讲， w 现在是该新类 i 中某个句柄在 idx(h) 下的一次封装，但我们不会添加相应的边 (idx(h) i) 到 E。如果添加这条边，将会导致由于 idx(h) 的泄露而使新类也被泄露，从而使得对手无法再基于新引入的等价类赢得原语游戏。由于该新类实际上是成功伪造的一次封装的结果（如 S= ∅ 所示），我们更倾向于采用更强的定义（即不向 E 添加边），在这种定义下，对手可能从一次伪造的封装中获益。

其次，解封装可能使用了已泄露的句柄进行调用。由于对手掌握了与该泄露句柄对应的密钥，因此创建此类封装很可能可行；此外，可以假设该对手能够以了解所返回句柄对应的密钥。为了简化问题，我们将对所有在受损句柄下解封装得到的句柄使用等价类0。损坏的句柄集合 C初始时包含类0。索引类0是特殊的，因为它没有正确性保证：如果idx(h1)= idx(h2)= 0，则很可能 h1. key = h2.key。

Incorporating the Primitive’s Security Game 。直观上，当且仅当对手成功赢得原语P的安全游戏时，该对手才算攻破了导出原语P的加密API。形式化地，为了将对手针对加密API的优势用该原语自身的抽象安全游戏来表示，我们需要将对手对加密API的攻击行为解释为该对手直接参与抽象原语游戏的行为。

与正确性游戏类似，我们在API游戏中使用等价关系将句柄与原语游戏中的密钥关联起来。每当创建一个新的等价类时，API游戏通过调用st[i]←$ setup()来创建一个原语游戏的新实例（宏initclass负责此项操作）。

对于API的挑战预言机，我们希望利用原语游戏中的挑战算法。这些算法本身期望一个实现该原语的预言机。在API的游戏模型中，挑战预言机可以使用API原语接口。如果API输出 ⊥api，我们抑制挑战预言机的输出，并视作在原语的游戏中该挑战调用并未发生（注意该调用可能仍对API的状态产生了影响）。

与多密钥原语游戏类似，在游戏结束时，我们检查对手是否通过挑战 corrupt（或在此情况下为已泄露）的密钥而导致了泄露。如前所述，另一种（更强的）表述方式将通过抑制任何可能导致不变式 L(C) ∩ H= ∅ 被破坏的查询来维持该不变式（可能允许那些已被API捕获的查询）。然而，我们的形式化更易于描述，并且在不实质性改变其含义的前提下简化了原本复杂的模型。

请注意，如果一个加密API导出多个不同的原语，每个原语都有其自身的安全概念，则可以考虑该加密API的多个安全概念。可以修改chalaux算法以模拟联合安全性。

定义5 。设API CA[P]导出原语P，并设sec=(setup,chal0,chal1,chalaux)为原语 P的一个安全概念。则对手 A针对CA[P]的优势定义为
Advsec CA P = ∣ ∣ ∣ Pr[Exp sec-0 CA P = 1] − Pr[Exp sec-1 CA P = 1] ∣ ,
f or the 实验 Exp sec b
CA[P] -(A)如图7所示。

图7. 密码学API Expsec-b CA P 的安全实验CA导出了 P=(KgP,AlgP)，其安全概念为 sec =(setup, chal0, chal1, chalaux)。攻击者还可访问图 6中定义的预言机（宏 initclass 在此处被使用）。

3.5 密码学API密钥管理的安全性

在关注导出原语的安全性时，我们忽略了加密密钥的机密性和关联属性的真实性。然而，对于加密API的密钥管理组件而言，这些是重要的属性，我们分别通过定义6和7来描述这些属性。

我们通过实验Expkm b CA-(A) 来定义密钥管理API的安全性，如图8所示。在此实验中，对手的目标是区分由API管理的真实密钥和随机生成的虚假密钥。通常情况下，我们通过一个由比特 b参数化的挑战预言机来体现这一思想，该比特需要由对手确定。当以句柄 h作为输入调用该预言机时，它将返回与 h相关联的真实密钥 或一个虚假密钥（取决于 b）。在此过程中，对手控制着密钥管理API，我们通过 图6中的预言机对其进行模拟能。我们仅施加最小限制以防止平凡胜利。与之前一样，我们假设对于所有已泄露的句柄，对手都知道相应的（真实）密钥，从而导致胜利变得平凡（我们可以通过要求 H ∩ L(C)= ∅来排除这些胜利，如同之前一样）。

此外，请注意在密钥封装假设（假设2）下，如果一个句柄已被用于封装另一个密钥，则攻击者可以通过解封装轻易地区分该密钥与一个随机密钥：使用真实密钥时操作总会成功，而使用虚假密钥时则会失败。如果某个索引对应的密钥之一发生了泄露，或曾被用于封装操作，我们称该索引为被污染的 。

我们将 T(C)记为被污染索引类：如果对手挑战了一个属于被污染类的密钥，则该对手失败（实验返回0）。

定义6 。设API CA为一个密钥管理API。则对手 A针对CA的优势定义为
Advkm CA(A)= ∣∣∣Pr[Expkm-0 CA(A)= 1] − Pr[Expkm-1 CA(A)= 1] ∣∣∣,
for the experiments Expkm b CA-(A)如图8所示。

图 8. 密钥管理API Exp km-b CA(A) 的安全实验CA，相对于生成器 Kg。攻击者A还可访问 图6中定义的预言机。

我们对安全密钥管理的定义与现有定义有所不同，例如KSW描述了一种虚假游戏，其中挑战密钥并未直接泄露，而是向对手提供基于虚假密钥的封装。我们认为我们的定义更为自然：在密钥协商文献（包括KEMs）中，区分真实密钥与随机密钥是标准做法。我们对安全密钥管理的定义具有一些有益的含义：密钥不可区分性（隐私）在一定程度上意味着正确性。4参见本文的完整版本。

备注1 。一个有用的观察是，关于进行多项式数量的挑战查询的攻击者的密钥管理安全性，可以通过混合论证归约为对仅进行单个挑战查询的对手的安全性。具体而言，对于任何进行 qc个挑战查询的对手 A，都存在一个进行单个挑战查询的对手
B ≤
qc ·
km CA A
km CA B
，使得
Adv( ) Adv( )。

3.6 粘滞性：属性安全性

一般来说，与句柄相关联的属性可能会随时间推移而发生变化。例如，某个属性可能用于指示其句柄是否已被用于执行封装操作。最初该属性值为假，但一旦执行了封装操作，该属性值将变为真并应始终保持为真。现有的API攻击表明了这一点的重要性

关键属性部分的完整性（例如，防止句柄用于两个冲突的目的）。在PKCS#11 术语中，一个二进制属性是粘性的当且仅当它不能被取消设置。我们通过定义在属性空间上的任意谓词的粘滞性游戏来建模这一点。我们对粘滞性的概念不允许任何更改（即，最初未设置的谓词必须保持未设置状态）。请注意，如预期一样，对索引0没有任何保证。

图9. 用于定义加密API中属性部分真实性的实验Exp π-sticky CA(A) 的预言机。对手还可访问图6中定义的预言机。

定义7 。设 CA为具有属性空间 Attributes的加密API。令π: Attributes →{0, 1} 为属性空间上的一个谓词。则对手 A针对 π的粘滞性的优势等于 Pr[Expπ- sticky CA(A)= true]，其中实验如图9所示。

在下一节中，我们将展示一个特定的谓词，用于指定密钥是用于密钥管理还是用于其他密码学操作。这两种可能性通过应用于属性的谓词external来建模：如果密钥用于密钥管理之外的密码学操作，则该谓词被设置。

备注2 。在本节中，我们通过密钥与随机密钥的不可区分性来定义密钥的保密性。这看起来可能是一个值得商榷的选择，因为API密钥通常用于完成某些密码学任务，而任何此类使用都会立即导致一种区分攻击。这一结果可以通过与密钥交换协议领域的有用类比来理解。在那里，安全性也是通过不可区分性来定义的，即使密钥随后被用于实现其他任务（例如，实现安全信道）。一个好的密钥交换协议与安全信道的安全实现相结合，应当能够产生一个安全的信道建立协议。

类似地，人们应将本节的模型理解为迈向下一节加密API模块化分析的一步。在那里，我们展示了如何组合以本节所定义意义下安全的密钥管理API

本节将任意（对称）原语组合以构建一个安全的加密API。该加密API的安全性定义为：加密API所实现的所有密码学任务均满足其（标准）基于游戏的安全概念。

4 密钥管理的力量

在本节中，我们展示如何将一个密钥管理API与任意原语进行通用组合。首先，我们确定了一些允许这两个组件组合的兼容性条件。非正式地说，这些条件要求API的密钥属于以下两种类型之一。Internal密钥专门用于密钥管理（即封装其他密钥）。External密钥专门用于为API导出的原语提供密钥。一个密钥是内部还是外部，取决于通过谓词external与其句柄相关联的属性。下文中，我们用 h.external表示与句柄 h相关联的谓词external的值。

定义8 。设 CA=(CA.init, CA.new,CA.create,CA.key,CA.wrap,CA.unwrap)为一个密钥管理API，且设 P=(KgP,AlgP)为具有密钥集Keys的任意原语的实现。我们称 CA与 P是兼容的 ，如果：
1. 在属性空间Attributes上存在一个易于计算的谓词external ，对于特定句柄 h记为 h.external；
2. 如果在调用时 h1.external= true成立，则CA.wrap(h1, h2)和 CA.unwrap(h1, w)均返回 ⊥api；
3. 如果 h.external= true成立，则 h.key ∈ Keys。

一个抽象原语 P和一个兼容的密钥管理APICA可以通过利用谓词外部以通用方式组合，从而形成一个加密API [CA;P]，如下面的定义 9所形式化。该[ CA;P]的正确性由其两个组成部分的正确性得出（定理 3）。我们的主要组合结果（定理 4）指出，如果这两个组件都是安全的，并且此外外部 谓词是粘性的，则该组合将产生一个安全的加密API，导出P。我们在以下定义中形式化我们的构造。

定义9（[CA;P]）的构造 。设CA是由算法（CA.init、CA.new、CA.create、 CA.key、CA.wrap、CA.unwrap）定义的密钥管理API，并设P=（KgP、AlgP）为一个兼容原语。我们定义密钥管理API CA与原语P的组成为
[CA；P]=(CA.init，CA.new，CA.create，CA.key，CA.wrap，CA.unwrap，CA.alg)
其中 CA.alg(h, x) 在 h.external= true 时直接返回 AlgP(h.key x)，否则返回⊥a p i（注意调用 CA.alg(h, x) 不会改变 API 的状态）。

以下定理表明，如果各个组件是正确的，则组合的结果也是正确的。

定理3（[证书颁发机构;原语P]）的正确性 。设CA为一个密钥管理API，且设P= （KgP，AlgP） 为一个具有由谓词corrP定义的正确性概念的兼容原语。那么
AdvcorrP [CA;P] ≤ AdvcorrP CA+ AdvcorrP
然后，CA和P的正确性意味着[CA;P]的正确性。

证明。 考虑 Exp corrP [ CA;P]游戏，其中 CA.alg为当前构造所指定。所得的预言机 alg在图 10中定义（不包含框内的语句）。添加框内语句后得到一个相同的游戏，除非在某个时刻发生 h.key = key(idx(h)) 的情况。该事件恰好是触发密钥管理正确性游戏胜利的事件（加密API游戏和密钥管理游戏中的 bad标志位一致）。此外，当考虑使用 alg并包含框内语句的整体正确性游戏时，其胜利可以语法上对应到原语正确性游戏中的胜利，从而完成证明。

图10. [CA；P]正确性证明的关键预言机转换。

密钥管理API CA与原语（KgP,AlgP）的兼容性仅涉及原语密钥所来自的集合。虽然对于正确性而言这已足够，但对于安全性，密钥的分布方式也同样重要。回顾一下，KgP的输入为参数pm，而对密钥管理API的一次 new调用则以属性 a作为输入。设a2pm是一个将属性映射到参数（或 ）的函数。令Kg接受一个属性作为输入，使得对于所有设置了谓词external的属性a，均有Kg(a) =KgP(a2pm(a))成立（即两个算法的输出分布相匹配）。

以下定理表明，将一个安全的密钥管理API与一个兼容的安全原语组合，可以得到一个安全的加密API。该定理的证明见论文的完整版本。

定理4（[证书颁发机构;原语P]）的安全性 。设CA为一个密钥管理API，且令 P= （KgP，AlgP）为一个兼容原语，其安全概念由算法元组（初始化，chal0, chal1,chalaux）定义。则对于任意针对加密API [CA;P],安全性的对手 A，均存在高效的归约B1、 B2和 B3，使得
Advsec CA;P ≤ 2Advsticky CA(B1)+ qe(4Adv sticky CA(B1)+2Advkm CA(B2)+ Adv sec P(B3))
其中 Advsticky CA指代external，Advkm CA是相对于上文定义的Kg而言的，而qe是游戏中包含属性为external的句柄的非零索引类的最大数量的上界（在由 A 进行的游戏里）。

备注3 。为了避免受限于特定的密码接口，我们建立了一个适用于任意安全游戏的抽象框架。这一选择带来的一个良好副作用是，我们可以模块化地处理API通过其属性泄露外部密钥“指纹”的场景。具体来说，我们可以将这些指纹视为抽象原语的附加功能（而非属性）。显然，实际原语需要在存在指纹的情况下被证明是安全的。

5 实例化aKM‐API

我们现在展示如何从DAE方案实例化一个密钥管理API。该密钥管理API强制执行一种“分层”密钥结构。底层将包含一个或多个（未指定的）密码学原语的密钥。顶层将包含用于DAE方案的密钥。我们的密钥管理API将强制执行以下策略：顶层密钥只能用于封装或解封底层的密钥，而底层密钥不能封装或解封任何密钥。直观上，底层的密钥应仅与其关联的密码学原语一起使用。

DAE方案 。确定性认证加密方案（DAE）是一个元组 Π=(K, E,D)。第一个分量 K ⊆{0, 1}∗是加密密钥集。加密算法 E和解密算法 D均接受 K×{0, 1}∗×{0, 1}∗ 中的输入，并返回一个字符串或一个特殊值 ⊥。我们用 EV K(X) 表示 E(K, V, X)，用 DV K(Y) 表示 D(K, V, Y)。我们假定存在一个关联数据空间 V ⊆{0, 1}∗和一个 消息空间 X ⊆{0, 1} ∗，使得X ∈ X ⇒{0, 1}|X| ⊂ X且 EV K(X) ∈{0, 1}∗当且仅当 V ∈ V且 X ∈ X。我们的约定是，对于所有 K ∈ K, V ∈ V， EV K(⊥) = DV K(⊥) = ⊥。我们要求 D和 E在各自不包括 ⊥的值域上互为逆函数：对于所有K ∈ K, V ∈ V, Y ∈{0, 1} ∗，如果存在一个 X使得 EV K(X) = Y，则我们要求 DV K(Y) = X（正确性）；此外，如果不存在这样的 X，则我们要求 DV K(Y) = ⊥（整洁性）。我们要求 E具有长度正则性，其扩展为stretch τ： N × N → N，即对于所有 K ∈ K, V ∈ V, X ∈ X，均有 |EV K(X)| = |X| + τ(|V |, |X|)成立。因此，密文长度仅取决于 V和 X的 长度。

图11. 定义具有自适应密钥泄露的左或右DAE安全性的实验Exp b Π dae crpt ‐‐‐(A) 。为防止平凡胜利，我们对对手作如下假设：(1) 若先前的 Enc‐预言机查询(i, V, X)返回了 Y，或先前的 LR‐预言机查询(i, V, X0, X1)返回了 Y，则它不会向其 Dec‐预言机查询(i, V, Y)； (2) 若先前的 Dec‐预言机查询(i, V, Y)返回了 X，则它不会向其 Enc‐预言机查询(i, V, X)； (3) 若(i, V, X)曾被发送至 Enc‐预言机查询，则形式为(i, V, X,·)或(i, V,·, X)的查询永远不会被发送至 LR‐预言机，反之亦然。

DAE方案安全性 。对于整数 ≥ 1，我们定义对手 A在 -密钥左或右DAE与泄露实验中的优势为
Adv-dae-crpt Π (A)= ∣ ∣ ∣ Pr[Exp-dae-crpt-0 Π (A)= 1] − Pr[Exp-dae-crpt-1 Π (A)= 1] ∣ ,
其中概率取自图11中的实验以及 A的随机性。不失一般性，我们假设对手不会重复任何查询，并且不会提出超出其预言机隐含域范围的查询。

作为这一情况的特例，我们还将敌手 A在‐key left-or-right DAE实验中的优势定义为
AdvΠ-dae (A)= ∣ ∣ ∣ Pr[Exp -dae-0 Π (A)= 1] − Pr[Exp -dae-1 Π (A)= 1] ∣ ,
其中 Exp b Π dae ‐‐ 通过修改图11定义，不再包含 Enc或 Reveal预言机、集合 I、 C以及对这些的任何引用。对抗行为的相关限制仍然适用。

我们注意到，这一概念与罗加威和什里普顿首次提出的DAE安全性概念[22]不同。我们采用更接近杰纳罗和哈利维[15]所提出的左右版本，因为它更符合我们的需求。

一个标准的“混合论证”提供了以下定理的证明，以及所声称的对手 B的描述。我们省略了该证明。

定理5. [1‐密钥左或右DAE意味着 ‐密钥左或右DAE带有篡改。] 固定一个整数 ≥ 1。设 Π=(K, E,D)是一个具有关联数据空间 V、消息空间 X 和密文扩展函数 e 的 DAE 方案。设 A 是一个与 -密钥 DAE 优势概念兼容的对手。设 A 提出形式为 (i,·,·,·) 的 qi LR-查询和形式为 (i,·,·) 的 pi Dec-查询，且具有时间复杂度 t。则存在一个对手 B，其以黑盒方式使用 A，使得
Adv-dae-crpt Π (A) ≤ Adv1Π-dae (B)
其中 B 最多提出 maxi{qi} LR-查询 和 maxi{pi} Dec-查询。

从DAE方案构建密钥管理API 。假设在属性空间Attributes ⊆{0, 1}∗上存在一个易于计算的谓词external，并且假设采样满足该谓词以及不满足该谓词的属性都是容易的。回顾之前的内容，对于特定句柄 h，我们使用简写 h.external 表示在 h.attr上求值的谓词。

设KgP为具有密钥空间Keys的某个原语P的密钥生成算法，且设pm为将属性映射到参数（或 ）的函数。令 Π=(K, E,D)为一个DAE方案，其关联数据空间为 V=属性，消息空间X包含Keys。定义Kg: Attributes → Keys ∪ K 为如下算法：当输入一个满足external的属性 a时，按照KgP(pm(a))从Keys中采样；否则从 K中均匀采样。

在指定构成我们密钥管理API的算法之前，让我们详细说明关于令牌状态及其作用域的假设。我们假设所有令牌的状态形式为 s=(s˜,(h →(key a))h)，其中对于每个句柄 h，映射h →(key a) 表示关联的密钥和属性对（即 h.key = key 和h. attr = a），而状态 s˜ 仅包含令牌过去输入/输出的快照。fresh 是一种按令牌生成 fresh（唯一）句柄的机制。

在确立了上述所有内容后，我们的密钥管理API的算法定义如下：
– CA.new(t, a)：通过调用 fresh(t) 在令牌 t 上创建一个新句柄 h 。采样 K ←$ Kg(a)，并更新令牌 t 的状态以反映新的映射 h →(K, a)。返回 h。
– CA.create(t, K, a)：通过调用 fresh(t) 在令牌 t 上创建一个新句柄 h，并更新令牌 t 的状态以反映新的映射 h →(K, a)。返回 h。
– CA . w ← Eh 2 . h2. w wrap(h1, h2)：如果 h1.external∨¬h2.external，则返回 ⊥api。否则，attr h1 .key (密钥)。返回。
– CA.unwrap(h, w, a)：如果 h.external，则返回 ⊥ap i。计算 K ← Da h.key( w)。如果 ¯K= ⊥ ，则返回 ⊥a p i。否则，创建一个新句柄 h ，并更新令牌 tkn(h) 的状态以反映新的映射 h →(K, a)。返回 h。

定理 6 。固定一个非空集合 密钥集。设 Π=(K, E,D)是一个DAE方案，其关联数据空间为 V=属性 ，消息空间为 X，且包含密钥集。令 CA为上述密钥管理API，且令 A为一个高效的密钥管理API对手，仅提出一次挑战查询。令 qn 为 new-预言机的查询次数 A 在执行过程中所做的查询，以及令 ≤ qn 为其中生成内部密钥的查询数量。则存在高效的攻击者 B、F，针对具有泄露实验的 -密钥 DAE，使得
Advkm CA(A) ≤ 2Adv-dae-crpt Π (F)+(qn − )Adv-dae-crptΠ(B)

6 相关工作

API安全的符号模型 。鉴于许多针对API的攻击依赖于逻辑缺陷而非弱加密，大量研究工作采用符号模型来解决其安全性问题。最早的攻击是由Longley 和 Rigby[19], Bond[3],以及 Clulow[7]发现的。最近，Cortier 等人[8], Delaune 等人[13],以及 Bortolozzo 等人[4]通过使用自动化工具发现了更多漏洞。安全性证明和安全模型包括Courant 和 Monin的工作，他们使用Coq分析IBM CCA API的一个变体[11]以及 Cortier 等人[8]的研究。Fr¨oschle 和 Steel[14]以及 Cortier 和 Steel[9]分析了PKCS#11标准的一部分。较新的模型考虑了使用非对称加密的密钥管理[12]以及密钥的撤销[10]。尽管符号模型适用于发现攻击，但其安全性证明的意义较为有限——特别是它们并不能先验地意味着相对于本文所构建的更强的计算模型下的安全性。

Cachin–Chandran 模型 [5] 。这是首个针对加密API的计算安全模型。该模型基于一种特定设计，依赖于一个集中式服务器来跟踪所有密钥管理操作 （这种服务器在令牌通常运行的分布式环境中是否存在是现实的尚不明确）。该安全模型本质上是通过将特定的实现选择（例如，某些属性如何以及何时发生变化，令牌的整体内部状态应如何维护哪些信息）硬编码到构成API的语法中，来表述对API的建议实现。显然，这严重限制了该模型的适用性。例如，封装方案的安全性被硬编码在模型中，并且实质上要求封装操作必须使用概率性方案来实现——采用确定性封装机制的方案在该模型下会被判定为不安全（特别是我们的密钥管理方案未被涵盖，因为我们的令牌无需在内部跟踪与密钥相关的属性）。

从安全角度而言，与我们的模型一样，对手可以访问令牌的完整接口，并试图破坏该令牌所提供的密码学功能。然而，我们认为Cachin–Chandran模型存在三个方面的缺点，而我们的模型在这些方面实现了显著改进。首先，正如前文所述， Cachin–Chandran模型排除了一些非常合理且安全的加密API实现（无论是明确还是隐含地）。其次，由于可能存在别名问题，由此引发的问题在

在Cachin‐Chandran模型中，避免了多个不同句柄指向同一密钥的情况（本质上，不允许解封装之前未创建的封装）。最后，Cachin‐Chandran模型所考虑的泄露模型仅限于用户，这意味着对手可以代表该用户进行操作。然而，这对实验没有进一步的影响，因为代表用户操作并不会获得对任何密钥的访问权限。因此，在Cachin‐Chandran模型中不存在被泄露或泄露的密钥集的概念。

我们的模型对加密API的内部工作机制仅做了最少的假设（它允许但绝不强制要求实现中包含中央服务器）。我们的安全模型仔细追踪了由封装/解封装操作所产生的句柄上的等价类。更重要的是，我们明确允许对API密钥进行自适应泄露，并要求任何未直接受或间接受到泄露影响的其他密钥保持安全性。

克雷默–斯蒂尔–瓦林斯基模型[18] 。KSW计算模型5修正了 Cachin‐Chandran模型的一些缺点。特别是，它提出了一个不依赖于任何特定实现、并允许密钥自适应泄露的加密导出API的语法和安全性定义。该语法为单令牌模式，其所施加的安全性要求与PKCS#11实现不兼容：所有属性都必须是粘性的，而PKCS#11规定某些属性在操作过程中会发生变化。有趣的是，尽管Cachin‐Chandran模型要求使用概率加密方案来实现密钥封装，但KSW模型所采用的建模选择却强制要求密钥封装是确定性的。更糟糕的是，过高的抽象层次导致其定义存在不完整或格式错误的问题。6

相比之下，我们考虑一个多令牌环境，并仅表面化地提出一些最小假设，以避免KSW模型中的欠指定问题。我们的安全概念更为宽松。例如，对于密钥管理API，我们仅要求应用密钥保持机密性，这允许密钥封装问题采用概率性和确定性两种解决方案。关键的是，我们证明了我们对密钥管理API的安全性概念具有可组合性，而目前尚无已知结果表明KSW模型具备此类性质。

通用可组合密钥管理 [17] 。本文在本质上与我们的工作最为接近。其旨在提供一个可组合的框架，使得密钥管理能够与令牌导出的其他密码学操作分开进行分析。该论文还介绍了另外两个相关模型：一个理想化模型和一个符号模型。例如，该形式化过程关键依赖于记号 s[key(h) →$ k0]，它表示某个状态 s，其中 key(h) 已被替换为随机选取的 k0。然而，由于状态的概念是抽象的，这种状态变化究竟意味着什么尚不清楚。例如，如果另一个句柄指向相同密钥，那么该句柄的密钥是否也会受到影响？状态变化是否具有持久性？ k 0 是每次重新抽取吗？

可能导出的。该形式化方法基于通用可组合性框架（由霍夫海因茨和肖普改进的版本[16]），并包含一个理想密钥管理功能，该功能通常应由安全实现来模拟。该框架自然地涵盖了多令牌场景，这些场景仅仅是该功能的分布式实现，并应保证所需的安全性：该实现可以在任何其他场景中替代该功能。

由于底层定义框架依赖于模拟，该模型无法很好地容忍自适应泄露密钥的对手（我们将在下文讨论此问题），因此仅允许对手进行静态泄露。另一个问题是，在基于模拟的设置中，密钥无法在不同功能之间自由传递。此处采用的解决方案使用了一种繁琐的基于能力的机制来建模密钥管理与其他密码学操作之间的交互。该密钥管理功能并非完全独立于受管密钥所使用的原语P。此外，密钥管理功能内部硬编码了一个封装算法（该算法需要是确定性的、经过认证的，并且能够抵御相关密钥攻击）。

我们避免了所有这些缺点。我们的构造在很大程度上对密钥所使用的原语不敏感，并允许多种实例化，其中密钥封装可以是概率性的或确定性的。我们使用基于游戏的定义，使得即使存在自适应泄露，也能证明组合定理。

计算上可靠的应用程序接口分析 。最近，斯塞里和斯坦利‐奥克斯提出了一种使用巴纳和科蒙‐隆德框架分析密钥管理API的方法[24][1]。该框架允许使用高层抽象对密码系统进行模化和推理，并利用一个通用定理将结果与标准计算模型中的安全性关联起来。斯塞里和斯坦利‐奥克斯所采用的方法与我们的相似之处在于，他们单独处理API的密钥管理组件，并通过组合定理来恢复整个 API的安全性，该定理考虑了API密钥在对称加密中的使用。这项工作对API策略进行了更详细的处理，并得益于对协议安全性进行简单公理化推理的优势。主要缺点是对手只能对API进行固定数量的查询。

7 结论

我们提出了能够捕捉加密和密钥管理API应提供核心安全保证的模型。我们的方法具有通用性，不针对特定原语（或原语集合），而是依赖于一种支持多种实例化的抽象。本研究开辟了多个有趣的研究方向。目前我们对策略进行抽象处理，仅在执行模型中体现其对令牌的影响。进一步研究这些策略将十分有意义

进一步为与安全策略实施相关的令牌提供额外保证。例如，有用的策略可能会试图确保某些密钥仅由特定用户使用，并且仅限于一组受限的操作。这些保证可以在我们模型的扩展中进行定义和分析，该扩展引入了令牌用户的概念，并形式化了策略所设想的限制类型。本文仅考虑对称密钥的管理。将我们的处理方法扩展到包括标准PKCS#11接口中的非对称密码学原语的私钥将是有益的。