85、对称密钥管理的通用安全 API

对称密钥管理的通用安全 API

1. 引言

安全 API 用于界定可信代码和不可信代码之间的边界。在一些系统中，关键的安全代码会在诸如智能卡、USB 安全令牌或硬件安全模块（HSM）等防篡改设备（TRD）上执行。与常规的加密 API 不同，安全 API 旨在强制执行特定策略，确保无论从不可信代码接收到何种 API 命令，某些属性（如敏感加密密钥的保密性）都能得以维持。

近年来，这些 API 执行策略的能力受到了正式和非正式的分析。像 PKCS#11 这样的开放标准以及 IBM 的通用加密架构等专有解决方案都被发现存在漏洞，可能导致策略被破坏。由于缺乏明确的安全策略，对于何种情况构成攻击存在争议，这让应用开发者陷入困惑。随着越来越多的应用开始采用基于 TRD 的安全解决方案，迫切需要更好的解决办法。

本文从不同方向着手解决这一问题，提出了一种从设备支持的安全协议推断 TRD 安全 API 功能属性的方法。主要贡献有两点：
- 提供了一个用于密钥管理协议的通用 API，该 API 可以实现广泛的对称密钥协议。核心思想是将机密数据与被授权访问它的代理集合一起存储在安全组件内，只有当加密密钥的授权代理都被授权访问加密数据时，API 才会对数据进行加密。
- 阐述并证明了该 API 的关键安全属性，无论实现何种协议。提出了一个威胁场景的形式化模型，在该模型中，TRD 可能连接到干净的主机，也可能连接到被攻击者控制的主机，攻击者还可能攻破某些设备的防篡改机制，获取部分用户的长期密钥。研究表明，该 API 能保证仅在诚实代理（TRD 未受损的代理）之间共享的非公共数据的机密性，即使诚实代理的 API 被攻击者控制。在更强的攻击场景下，即攻击者还获得了旧的机密密钥，只要 API 切换到受限模式（仅在能进行新鲜度测试时才解密密文），仍能提供安全保障。不过，受限模式可实现的协议较少，无法实现易受重放攻击的协议，但除了已知存在重放攻击的协议外，Clark 和 Jacob 库中的对称密钥建立协议都能在受限模式下实现。

2. 形式化模型

2.1 语法

消息通常用项代数表示。假设存在有限的代理集合 Agent、无限的随机数集合 Nonce 和密钥集合 Key，以及无限的变量集合 Var，其中包括密钥类型的变量集合 VarKey 和随机数类型的变量集合 VarNonce。
- 密钥变量：Keyv ::= Key | VarKey
- 随机数变量：Noncev ::= Nonce | VarNonce
- 消息：Msg ::= Agent | Keyv | Noncev | Var{Msg}Keyv | ⟨Msg, Msg⟩
- 句柄：Handle ::= hαa(Nonce, Msg, i, S)

其中，i ∈ {0, 1, 2, 3}，S ⊆ Agent，a ∈ Agent，α ∈ {r, g}。API 不直接提供对秘密消息的访问，而是为用户提供一个句柄，用于后续指示 API 使用特定消息。句柄 hαa(n, m, i, S) 表示存储在 API 上属于代理 a 的、安全级别为 i 的消息 m 的引用。集合 S 表示被授权访问 m 的用户集合，特殊常量 All 表示公共数据。随机数 n 用于避免引用相同数据的句柄产生混淆，标签 α 区分 API 生成的值（α = g）和 API 接收的值（α = r），这有助于 API 进行新鲜度检查。TRD 内存储的值通常是随机数或密钥，但由于 TRD 无法检查任意位串是否为密钥，所以理论上允许任何消息存储在 TRD 内。安全级别分为以下四种：
- 0：公共数据
- 1：不用于加密的秘密数据（通常是随机数）
- 2：短期密钥
- 3：长期密钥

同时，考虑谓词集合 P = {Pa | a ∈ Agent ∪ {int}}，其中 Pa 表示代理 a 的知识，Pint 表示入侵者的知识。

2.2 模型

模型是一个基于状态的转换系统。规则的形式为 P1(u1), …, Pk(uk) N1,…,Np =⇒ Q1(v1), …, Ql(vl)，其中 ui、vi 是可能包含变量的消息或句柄，Ni 是变量，Pi、Qi 是谓词。

例如，下面的规则集合 INTRUDER 表示攻击者在知道密钥的情况下进行配对、投影、加密和解密的能力：

Pint(x), Pint(y) ⇒ Pint(⟨x, y⟩)
Pint(⟨x, y⟩) ⇒ Pint(x)
Pint(⟨x, y⟩) ⇒ Pint(y)
Pint(x), Pint(y) ⇒ Pint({x}y)
Pint({x}y), Pint(y) ⇒ Pint(x)

执行模型的状态是入侵者和用户当前的知识，用家族 {Sb | b ∈ Agent ∪ {int}} 表示，其中 int 是表示入侵者的特殊索引，Sb 是消息和句柄的集合。

如果存在规则 Pa1(u1), …, Pak(uk) N1,…,Np =⇒ Pb1(v1), …, Pbl(vl) 以及替换 θ，满足以下条件，则称状态 S 可以从状态 S′ 一步到达（表示为 S ⇒R S′）：
- uiθ ∈ Sai 对于任意 1 ≤ i ≤ k
- Njθ 是新鲜的随机数（不在 S 中出现）
- S′ 是满足 Sb ⊆ S′b 对于任意 b ∈ Agent ∪ {int} 且 viθ ∈ S′bi 对于任意 1 ≤ i ≤ l 的最小家族

⇒∗R 表示 ⇒R 的自反传递闭包，当规则集合明确时可以省略 R。通常的可推导性概念可以通过以下方式得到：如果存在 S′ 使得 S ⇒∗INTRUDER S′ 且 m ∈ S′int，其中 S 定义为对于任意 a ∈ Agent，Sa = ∅，Sint = S，则称项 m 可以从项集合 S 推导得出，记为 S ⊢ m。

3. 通用 API 介绍

假设存在一个具有有限内存的防篡改设备，能够进行对称密钥加密。该设备用于促进对称密钥分发协议的执行以及后续会话密钥的使用。为此，设计了一个 API，允许用户在 TRD 内管理秘密数据。用户不能直接访问存储的秘密值，而是使用 API 命令通过句柄来要求 TRD 进行加密和解密操作。该 API 有三个简单的命令：新数据生成、加密和解密。

3.1 API 规则

• 数据生成 ：
  • 安全生成 ：允许用户 a 为一组代理 S ⊆ Agent 生成安全级别为 i ∈ {1, 2} 的新随机数或密钥 K。

N,K
⇒ Pa(hg
a(N, K, i, S))
i ∈ {1, 2}

- **公共生成**：生成公共数据。

N,K
⇒ Pa(K), Pa(hg
a(N, K, 0, All))

其中，N ∈ VarNonce，当 i = 1 时，K ∈ VarNonce；当 i = 2 时，K ∈ VarKey。如果生成的是公共数据，用户将同时获得新值及其句柄。

• 加密 ：代理 a 可以使用密钥 K 对公共数据 x1, …, xk 和秘密数据 y1, …, yl 进行加密。a 通过句柄 hαa(Xn, K, i0, S0) 知道密钥 K，通过句柄 hαja (Xnj, yj, ij, Sj) 知道值 yj。

Pa(hα
a(X, K, i0, S0)), Pa(x1), ..., Pa(xn),
Pa(hα1
a (Xn1, y1, i1, S1)), ..., Pa(hαl
a (Xnl, yl, il, Sl))
⇒ Pa({x1, 0, ..., xn, 0, y1, i1, S1, ..., yl, il, Sl}K)

API 会在加密数据时为每个数据添加其安全级别和被授权访问的代理集合。要求 i0 > ij（密钥只能加密安全级别严格低于它的数据）且 S0 ⊆ Sj，以确保数据不会传输给未被授权访问的用户。

• 解密 ：用户 a 可以使用通过句柄 hαa(Xn, K, i0, S0) 传递的密钥 K 对消息进行解密，并检查之前由 API 生成的部分（公共或私有）组件 x1, …, xs, y1, …, yr 的相等性，这些测试可用于确保消息的新鲜度。

Pa(hα
a(X, K, i0, S0)), Pa({x1, 0, ..., xk, 0, y1, i1, S1, ..., yl, il, Sl}K),
Pa(hg
a(X1, x1, 0, All)), ..., Pa(hg
a(Xs, xs, 0, All)),
Pa(hg
a(Y1, y1, i1, S1)), ..., Pa(hg
a(Yr, yr, ir, Sr))
Nr+1,...,Nl
⇒
Pa(xs+1) ..., Pa(xk),
Pa(hr
a(Nr+1, yr+1, ir+1, Sr+1)), ..., Pa(hr
a(Nl, yl, il, Sl))

用户将获得未用于相等性测试的解密公共数据以及未用于相等性测试的解密私有数据的句柄，前提是 i0 > ij 且 S0 ⊆ Sj。

为了简化，上述规则展示了加密时先加密公共数据，解密测试时只测试前几个值的相等性。实际上，命令的参数顺序没有限制，完整的加密和解密规则如图 1 所示，所有规则的集合记为 API。

下面以 Carlsen 的秘密密钥发起者协议为例说明 API 的使用：
1. A → B : A, Na
2. B → S : A, Na, B, Nb
3. S → B : {Kab, Nb, A}Kbs, {Na, B, Kab}Kas
4. B → A : {Na, B, Kab}Kas, {Na}Kab, N′b
5. A → B : {N′b}Kab

该协议的目的是使用密钥服务器 s 为参与者 a 和 b 建立一个新的会话密钥 Kab。使用 API 实现该协议时，a 应该有一个指向级别为 3 的密钥 kas 的句柄 hra(n′KAS, kas, 3, {a, s})。a 可以通过以下 API 命令执行协议的第一步：

N,NA
⇒
Pa(NA), Pa(hg
a(N, NA, 0, All))

a 获得一个新鲜的公共随机数 NA 及其句柄 hga(N, NA, 0, All)。a 在协议的第二步（规则 5）也可以使用 API 命令完成。收到消息 {Na, a, Kab}Kas, {Na}Kab, N′b 后，a 可以将其拆分为三部分 x1、x2 和 x3，然后使用以下解密命令解密 x1：

Pa(hr
a(N ′
KAS, Kas, 3, {a, s})), Pa({NA, 0, y, 0, x, 2, {a, b, s}}Kas),
Pa(hg
a(N, NA, 0, All))
N ′
⇒ Pa(y), Pa(hr
a(N ′, x, 2, {a, b, s}))

a 可以检查 y 是否等于 b，并获得一个指向 x 的句柄，x 应该对应内部密钥 Kab。然后可以使用类似的解密命令解密 x2，最后使用以下加密命令构建发给 b 的消息：

Pa(hr
a(N ′, Kab, 2, {a, b, s})), Pa(x3) ⇒ Pa({x3, 0}Kab)

3.2 与 PKCS#11 的比较

最广泛使用的 TRD API 是 RSA 标准 PKCS#11（也称为“Cryptoki”），基于 PKCS#11 的 API 已被证明容易受到各种攻击，导致敏感密钥被泄露。本文提出的 API 有几个专门针对这些威胁的特性：
- 采用不同的加密方案，对来自主机的公共数据和来自 TRD 的秘密数据进行不同的标记，避免混淆，而 PKCS#11 没有这样做，许多已知的攻击正是利用了这种混淆。
- 坚持将密钥以特定角色（会话密钥或长期密钥）存储，且这些角色不能更改。PKCS#11 允许密钥角色通过属性改变，这是 Cryptoki API 的一个主要漏洞来源。
- 在 TRD 内存储密钥预期使用的代理身份，并在加密方案中包含这些身份作为标签，PKCS#11 没有这样的规定，但这对于在某些 TRD 被攻破时保持安全属性似乎是必要的。

4. 使用通用 API 实现协议

在这部分将展示如何使用通用 API 实现对称密钥协议，特别是来自 Clark - Jacob 调查中的对称密钥分发协议。具体步骤如下：
1. 分析协议 ：仔细研究对称密钥协议的流程和要求，明确需要生成、加密和解密的数据。
2. 确定 API 命令 ：根据协议步骤，选择合适的 API 命令（生成、加密、解密）。例如，在需要生成新随机数或密钥时使用生成命令，需要保护数据时使用加密命令，需要获取数据时使用解密命令。
3. 设置参数 ：为每个 API 命令设置正确的参数，包括代理集合、安全级别、句柄等。例如，在加密命令中，确保加密密钥的授权代理集合是被加密数据授权代理集合的子集，并且密钥的安全级别高于被加密数据的安全级别。
4. 执行命令 ：按照协议的顺序依次执行 API 命令，完成协议的实现。

通过以上步骤，可以利用通用 API 实现各种对称密钥协议，确保数据的安全性和完整性。同时，API 的通用性质使得它能够适应不同的协议需求，为对称密钥管理提供了一种灵活而安全的解决方案。

对称密钥管理的通用安全 API

5. 通用 API 的安全性分析

5.1 威胁场景建模

为了评估通用 API 的安全性，构建了一个形式化的威胁场景模型。在这个模型中，TRD 可能会连接到不同状态的主机：有时连接到干净的主机，此时系统处于正常运行状态；有时连接到被攻击者控制的主机，攻击者可以在该主机上执行任意代码。此外，攻击者还可能攻破某些设备的防篡改机制，获取部分用户的长期密钥。

在这个威胁场景下，将代理分为诚实代理和被攻击代理。诚实代理的 TRD 未被攻破，其数据和 API 操作应该得到保护；而被攻击代理的 TRD 可能已被攻击者控制，其 API 可能会受到攻击者的操纵。

5.2 安全属性证明

针对上述威胁场景，对通用 API 的安全属性进行了证明。主要证明了以下两个关键安全属性：

• 机密性 ：对于仅在诚实代理之间共享的非公共数据，API 能够保证其机密性。即使诚实代理的 API 被攻击者控制（例如，诚实用户的机器被蠕虫感染），只要代理的 TRD 未被攻破，这些数据仍然是安全的。这是因为 API 在加密数据时，会检查加密密钥的授权代理集合是否是被加密数据授权代理集合的子集，确保数据不会被传输给未授权的用户。

• 受限模式下的安全性 ：在更强的攻击场景下，即攻击者还获得了旧的机密密钥，API 可以切换到受限模式。在受限模式下，API 只有在能够进行新鲜度测试时才会解密密文。虽然这种受限模式可实现的协议较少，无法实现易受重放攻击的协议，但研究发现，除了已知存在重放攻击的协议外，Clark 和 Jacob 库中的对称密钥建立协议都能在受限模式下实现。

通过这些安全属性的证明，表明通用 API 在不同的攻击场景下都能提供一定程度的安全保障，为对称密钥管理提供了可靠的解决方案。

6. 案例研究：Clark - Jacob 协议套件

为了进一步验证通用 API 的通用性和实用性，选择了 Clark - Jacob 协议套件中的对称密钥建立协议进行案例研究。

6.1 协议选择与分析

Clark - Jacob 协议套件包含了多个经典的对称密钥建立协议，这些协议在不同的场景下用于建立会话密钥。对这些协议进行了详细分析，确定了每个协议的步骤和所需的操作，包括密钥生成、数据加密和解密等。

6.2 API 命令实例化

根据协议分析的结果，使用简单的算法将通用 API 命令实例化为具体的协议实现。这个算法已在 Prolog 中实现，它能够根据协议的要求自动生成相应的 API 命令。

例如，对于 Carlsen 的秘密密钥发起者协议，按照前面介绍的步骤，将协议的每个步骤转换为 API 命令。通过这种方式，展示了通用 API 能够支持多种对称密钥建立协议的实现。

6.3 受限模式下的实现

在案例研究中，还探讨了在受限模式下实现协议的情况。除了已知存在重放攻击的协议外，其他协议都可以在受限模式下实现。这表明受限模式虽然有一定的局限性，但仍然能够满足大多数对称密钥建立协议的安全需求。

7. 总结与展望

7.1 总结

本文提出了一个用于对称密钥管理的通用安全 API，该 API 具有以下优点：
- 通用性 ：可以实现广泛的对称密钥协议，包括 Clark - Jacob 协议套件中的大部分协议。
- 安全性 ：通过严格的安全属性证明，保证了在不同攻击场景下数据的机密性和完整性。
- 灵活性 ：提供了简单的 API 命令，用户可以根据协议的需求灵活使用这些命令。

与现有的 PKCS#11 API 相比，该通用 API 在加密方案、密钥角色管理和代理身份存储等方面进行了改进，能够有效避免 PKCS#11 中存在的一些安全漏洞。

7.2 展望

虽然通用 API 已经取得了一定的成果，但仍有一些方面可以进一步改进和扩展：
- 支持更多协议 ：可以进一步研究如何在受限模式下支持更多类型的协议，特别是那些对新鲜度有特殊要求的协议。
- 性能优化 ：在保证安全性的前提下，对 API 的性能进行优化，减少加密和解密操作的时间开销。
- 与其他安全机制集成 ：考虑将通用 API 与其他安全机制（如身份认证、访问控制等）集成，提供更全面的安全解决方案。

通过不断的改进和扩展，通用 API 将能够更好地满足对称密钥管理的需求，为各种应用提供更加安全可靠的支持。

附录：API 规则完整列表

规则类型	规则内容	说明
安全生成	N,K ⇒ Pa(hg a(N, K, i, S))，i ∈ {1, 2}	生成安全级别为 1 或 2 的随机数或密钥
公共生成	N,K ⇒ Pa(K), Pa(hg a(N, K, 0, All))	生成公共数据
加密	Pa(hα a(X, K, i0, S0)), Pa(x1), …, Pa(xn), Pa(hα1 a (Xn1, y1, i1, S1)), …, Pa(hαl a (Xnl, yl, il, Sl)) ⇒ Pa({x1, 0, …, xn, 0, y1, i1, S1, …, yl, il, Sl}K)	对公共数据和秘密数据进行加密
解密/测试	Pa(hα a(X, K, i0, S0)), Pa({x1, 0, …, xk, 0, y1, i1, S1, …, yl, il, Sl}K), Pa(hg a(X1, x1, 0, All)), …, Pa(hg a(Xs, xs, 0, All)), Pa(hg a(Y1, y1, i1, S1)), …, Pa(hg a(Yr, yr, ir, Sr)) Nr+1,…,Nl ⇒ Pa(xs+1) …, Pa(xk), Pa(hr a(Nr+1, yr+1, ir+1, Sr+1)), …, Pa(hr a(Nl, yl, il, Sl))	解密密文并进行新鲜度测试

流程图：通用 API 实现协议的流程

graph TD
    A[分析协议] --> B[确定 API 命令]
    B --> C[设置参数]
    C --> D[执行命令]
    D --> E[完成协议实现]

通过以上的分析和研究，通用 API 为对称密钥管理提供了一种有效的解决方案，在保证安全性的同时，具有良好的通用性和灵活性。未来的研究可以进一步完善和扩展该 API，使其能够更好地适应不断变化的安全需求。