45、高效且可证明安全的服务器辅助阈值签名方案

高效且可证明安全的服务器辅助阈值签名方案

在当今数字化时代，签名功能的安全性至关重要。为了满足不同场景下对签名安全的需求，我们将介绍两种高效且可证明安全的服务器辅助阈值签名方案，同时还会对保护签名功能的系统进行分类。

1. TPAKE - HTSig 方案

1.1 构建基础

TPAKE - HTSig 方案基于满足特定规范的 TPAKE 和 HTSig 构建。其中，HTSig 可以基于 DSS 或 Schnorr 实现。基于 DSS 的 HTSig 可通过组合相关方案得到，但效率不是很高；而基于 Schnorr 的 HTSig 则通过组合另外的方案能获得更高的效率。

1.2 具体构建过程

1.2.1 初始化阶段

• 用户 U 和服务器 {S1, · · ·, Sn} 执行 TPAKE.Init，用户 U 会向服务器发送经过某种变换的密码。
• 用户 U 和服务器 {S1, · · ·, Sn} 执行 HTSig.Init：
• 用户 U 执行 X(2,2) ←→(XU, XS)，并将 XU 存储在自己的设备上。
• 用户 U 执行 XS(t + 1,n) ←→(X(1)S, · · ·, X(n)S)，服务器 Sj（1 ≤ j ≤ n）存储 X(j)S。

1.2.2 调用阶段

假设用户 U 要对消息 m 进行签名，具体步骤如下：
1. 用户 U 发起与一组服务器 (Si1, · · ·, Siw) 的 TPAKE.Login，最终用户 U 持有 w 个不同的即时会话密钥 ski1, · · ·, skiw，这些密钥也分别被服务器 Si1, · · ·, Siw 所知。
2. 用户 U 和服务器 (Si1, · · ·, Siw) 执行以下操作：
- 用户 U 生成部分签名 σU = g′1(m, XU)。
- 用户 U 向服务器 Sij 发送 (m, δ = fskij (m))，其中 1 ≤ j ≤ w，f 是安全的消息认证码。
- 服务器 Sij（1 ≤ j ≤ w）验证接收到的 (m, δ) 的完整性。如果 δ ≠ fskij (m)，则中止操作；否则，将其部分签名 σ(ij)S = g1(m, XijS) 返回给用户。
- 用户 U 根据 w 个有效的部分签名 σ(i1)S, · · ·, σ(iw)S 计算 σS = g2(σ(i1)S, · · ·, σ(iw)S)。
- 用户 U 根据 σU 和 σS 计算最终签名 σ = g′2(σU, σS)。

1.3 安全性分析

我们主要关注 TPAKE - HTSig 的不可伪造性。可以看出，TPAKE - HTSig 的健壮性由 TPAKE 和 HTSig 的健壮性保证。如果 TPAKE - HTSig 被破解，那么 TPAKE 也会被破解。

以下是 TPAKE - HTSig 方案的流程图：

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    classDef decision fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px;

    A([开始]):::startend --> B(初始化阶段):::process
    B --> B1(执行 TPAKE.Init):::process
    B --> B2(执行 HTSig.Init):::process
    B2 --> B21(U 计算 X(2,2) ←→(XU, XS)):::process
    B2 --> B22(U 计算 XS(t + 1,n) ←→(X(1)S, · · ·, X(n)S)):::process
    B22 --> B23(Sj 存储 X(j)S):::process
    B --> C(调用阶段):::process
    C --> C1(U 发起 TPAKE.Login):::process
    C1 --> C2(U 获得 w 个会话密钥):::process
    C --> C3(U 生成部分签名 σU):::process
    C --> C4(U 发送 (m, δ) 到 Sij):::process
    C4 --> D{Sij 验证 (m, δ) 完整性}:::decision
    D -->|δ ≠ fskij (m)| E(中止):::process
    D -->|δ = fskij (m)| F(Sij 返回部分签名 σ(ij)S):::process
    F --> G(U 计算 σS):::process
    G --> H(U 计算最终签名 σ):::process
    H --> I([结束]):::startend

2. LW - TSig 方案

2.1 适用场景

LW - TSig 方案，即轻量级服务器辅助阈值签名方案，适用于用户拥有没有加密协处理器的智能卡（或一般的硬令牌），但又希望其私钥签名功能得到阈值保护的现实场景。

2.2 具体构建过程

2.2.1 初始化阶段

此过程在安全环境（如安全计算机）中进行，涉及用户 U（拥有公钥和私钥对 (Y, X)）和服务器 {S1, · · ·, Sn}。过程结束后，用户 U 在智能卡上存储 (key1, · · ·, keyn)，服务器 Sj（1 ≤ j ≤ n）持有 (keyj, Xj)。具体步骤如下：
- 用户 U 执行 X(t + 1,n) ←→(X1, · · ·, Xn)，其中 Xj（1 ≤ j ≤ n）是服务器 Sj 的份额。
- 用户 U 选择对称密钥 keyj 并秘密发送给服务器 Sj（1 ≤ j ≤ n）。

2.2.2 调用阶段

假设用户 U 需要为接收者对消息 m 进行签名，具体步骤如下：
1. 用户 U 生成 {δj = fkeyj(m)}n j = 1 并发送给签名接收者，其中 f 是安全的消息认证码。
2. 签名接收者将 (m, δj) 转发给服务器 Sj（1 ≤ j ≤ n）。
3. 服务器 Sj（1 ≤ j ≤ n）使用密钥 keyj 检查请求 (m, δj) 是否有效。如果请求通过验证，服务器 Sj 参与阈值签名生成协议 TSig.Sig，并可能将其部分签名返回给签名接收者。
4. 签名接收者获得可以使用 TSig.Ver 验证的签名。

2.3 安全性分析

如果消息认证方案和阈值签名方案 TSig 都是安全的，那么 LW - TSig 方案也是安全的。

以下是 LW - TSig 方案的流程图：

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    classDef decision fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px;

    A([开始]):::startend --> B(初始化阶段):::process
    B --> B1(U 执行 X(t + 1,n) ←→(X1, · · ·, Xn)):::process
    B --> B2(U 选择 keyj 并发送给 Sj):::process
    B --> C(调用阶段):::process
    C --> C1(U 生成 {δj = fkeyj(m)}n j = 1):::process
    C1 --> C2(U 发送 {δj} 给签名接收者):::process
    C2 --> C3(签名接收者转发 (m, δj) 给 Sj):::process
    C3 --> D{Sj 验证 (m, δj) 有效性}:::decision
    D -->|无效| E(不参与签名生成):::process
    D -->|有效| F(Sj 参与 TSig.Sig):::process
    F --> G(签名接收者获得可验证签名):::process
    G --> H([结束]):::startend

3. 保护签名功能的系统分类

3.1 相关术语

3.1.1 用户存储介质

• 人类记忆：用于记忆密码。
• 软令牌：存储在联网设备（通常是能高效计算诸如模幂运算等加密操作的计算机）上的数据结构，可能会进一步用密码保护。
• 硬令牌：像智能卡这样的专用硬件，攻击者可能无法访问，可能具有加密协处理器，具有抗篡改能力，并可用密码保护。
• 软令牌和硬令牌：用户同时持有存储在联网设备上的软令牌和硬令牌，其中一个或两个都可能用密码保护。

3.1.2 运行时密钥份额数量

当私钥签名功能激活时，私钥可能以完整形式存在，也可能在多个参与方之间共享。假设运行时私钥为 n 份，可分为三种情况：n = 1（即一份）、n = 2（即两份）和 n > 2（即多份）。

3.2 具体分类

我们根据用户存储介质（x 轴）和运行时密钥份额数量（y 轴）对保护私钥签名功能的系统进行分类。坐标 (x, y) 表示相应的系统，其中 x ∈ {人类记忆, 软令牌, 硬令牌, 软令牌和硬令牌}，y ∈ {一份, 两份, 多份}。以下是对 12 种系统类型的详细介绍：
| 用户存储介质 | 一份密钥份额 | 两份密钥份额 | 多份密钥份额 |
| — | — | — | — |
| 人类记忆 | 用户通过记忆密码从远程服务器下载私钥，传输过程中私钥用即时会话密钥保护，但存在单点故障问题。 | 一种是从密码派生部分私钥，另一部分存储在远程服务器，易受离线字典攻击；另一种是用密码激活两个远程服务器协作签名。 | 一种是从密码派生部分私钥，其他部分存储在远程服务器，易受离线字典攻击；另一种是用密码激活多个远程服务器协作签名，是 TPAKE - HTSig 方案的特殊情况。 |
| 软令牌 | 一种是在设备上存储受密码保护的私钥，设备被攻破后易受离线字典攻击；另一种是采用前向安全机制，保证某一时刻私钥被攻破不影响过去私钥的安全性。 | 私钥分成两份，一份存储在用户设备作为软令牌，另一份存储在远程服务器，用户对远程服务器的认证可能基于密码。 | TPAKE - HTSig 方案属于此类，用户将私钥 X 分成 XU 和 XS，XU 存储在联网设备上，XS 在远程服务器间共享。 |
| 硬令牌 | 传统解决方案，私钥存储在具有加密协处理器的（抗篡改）智能卡上，可加入前向安全机制。 | 一种是将私钥的一份存储在智能卡，另一份存储在远程服务器，智能卡或其上的份额可能受密码保护；另一种是在智能卡上存储对称密钥，私钥在两个远程服务器间共享协作生成签名，是 LW - TSig 方案的简化版本。 | LW - TSig 方案属于此类，用户的私钥在一组服务器间共享，智能卡用于存储对称密钥，用户对服务器的认证基于对称密钥加密。 |
| 软令牌和硬令牌 | 基于密钥隔离的系统，将系统生命周期分为多个时间段，智能卡仅用于更新对应固定公钥的私钥，增强了抗入侵能力，可保证前向安全。 | 用户设备和智能卡通过两方签名方案协作。 | 可看作 TPAKE - HTSig 或 LW - TSig 方案的扩展，软令牌可持有私钥份额，智能卡可持有对称密钥，有一些有趣的变体。 |

通过以上介绍，我们详细了解了两种高效且可证明安全的服务器辅助阈值签名方案，以及保护签名功能的系统分类。这些方案和分类为不同场景下的签名安全提供了多样化的选择和解决方案。在实际应用中，我们可以根据具体的需求和环境，选择最合适的方案来保障签名功能的安全。

4. 方案对比与应用建议

4.1 方案对比

为了更清晰地了解 TPAKE - HTSig 和 LW - TSig 方案的特点，我们从多个方面进行对比，如下表所示：
| 对比项 | TPAKE - HTSig 方案 | LW - TSig 方案 |
| — | — | — |
| 适用场景 | 用户设备能高效计算模幂运算等加密操作的场景 | 用户拥有无加密协处理器的智能卡，希望私钥签名功能得到阈值保护的场景 |
| 初始化复杂度 | 涉及 TPAKE.Init 和 HTSig.Init 两个初始化过程，相对复杂 | 在安全环境中完成初始化，主要是私钥份额分配和对称密钥分发，复杂度相对较低 |
| 调用过程 | 需要用户与服务器多次交互，生成部分签名并组合成最终签名 | 用户生成消息认证码发送给接收者，接收者转发给服务器，服务器验证后参与签名生成，交互过程相对清晰 |
| 安全性依赖 | 依赖 TPAKE 和 HTSig 的安全性，不可伪造性与 TPAKE 相关 | 依赖消息认证方案和阈值签名方案 TSig 的安全性 |

4.2 应用建议

根据不同的应用场景和需求，我们可以选择合适的方案：
- 场景一：用户设备性能较强
如果用户设备能够高效计算模幂运算等加密操作，且需要在多个服务器间协作完成签名，TPAKE - HTSig 方案是一个不错的选择。例如，在企业级的分布式系统中，用户使用高性能的计算机进行操作，需要多个服务器提供安全的签名服务，TPAKE - HTSig 方案可以满足其需求。其具体操作步骤如下：
1. 初始化：执行 TPAKE.Init 和 HTSig.Init，用户存储相关信息在设备上，服务器存储对应份额。
2. 调用：用户发起 TPAKE.Login 获得会话密钥，生成部分签名并与服务器交互，最终计算出完整签名。
- 场景二：用户使用无加密协处理器的智能卡
当用户拥有无加密协处理器的智能卡，且希望私钥签名功能得到阈值保护时，LW - TSig 方案更为合适。比如，普通用户使用智能卡进行日常的签名操作，智能卡不具备强大的加密计算能力，LW - TSig 方案可以通过服务器辅助完成签名。其操作步骤为：
1. 初始化：在安全环境中，用户分配私钥份额给服务器，并发送对称密钥。
2. 调用：用户生成消息认证码发送给接收者，接收者转发给服务器，服务器验证后参与签名生成。

5. 总结与展望

5.1 总结

本文介绍了两种高效且可证明安全的服务器辅助阈值签名方案：TPAKE - HTSig 方案和 LW - TSig 方案，并对保护签名功能的系统进行了分类。TPAKE - HTSig 方案适用于用户设备能高效计算加密操作的场景，通过 TPAKE 和 HTSig 的结合，实现了安全的签名功能。LW - TSig 方案则针对用户拥有无加密协处理器的智能卡的场景，通过简单而有效的方式提供了阈值签名保护。同时，我们根据用户存储介质和运行时密钥份额数量对保护签名功能的系统进行了分类，为不同场景下的签名安全提供了多样化的选择。

5.2 展望

随着信息技术的不断发展，签名安全的需求也在不断提高。未来，我们可以从以下几个方面对这些方案进行进一步的研究和改进：
- 性能优化 ：进一步优化方案的计算复杂度和通信开销，提高签名的生成和验证效率。例如，研究更高效的加密算法和协议，减少不必要的计算和通信步骤。
- 安全性增强 ：考虑更多的安全威胁和攻击场景，增强方案的安全性。例如，针对量子计算威胁，研究基于量子抗性的签名方案。
- 应用拓展 ：将这些方案应用到更多的实际场景中，如物联网、区块链等领域，为这些领域的安全提供保障。

总之，服务器辅助阈值签名方案在保障签名安全方面具有重要的作用，未来的研究和发展将为签名安全带来更多的可能性。

通过以上的介绍和分析，我们对服务器辅助阈值签名方案有了更深入的了解，希望这些内容能为相关领域的研究和应用提供有益的参考。