Skip to main content

MPC-TSS flow

MPC-TSS 的工作原理​

虽然我无法直接为你绘制图像，但我可以描述一个简单的流程图来帮助你理解 MPC-TSS（多方计算门限签名方案）的工作原理。你可以根据这个描述自行绘制或想象这个过程。

流程图描述​

假设我们有三个参与者（设备）：A、B 和 C。我们需要这三者中的任意两个合作才能生成有效的签名。这种方案通常被称为 2-of-3 门限签名方案。

  1. 私钥分片生成

    • 私钥被分割成三份份额：A1、B1、C1。
    • 每个份额分别安全地分发到设备 A、B、C。

  2. 签名请求

    • 假设要对一个交易进行签名。
    • 交易数据被发送到所有设备（A、B、C）。

  3. 部分签名计算

    • 设备 A 使用其份额 A1 对交易数据进行部分签名，生成签名片段 SA。
    • 设备 B 使用其份额 B1 对交易数据进行部分签名，生成签名片段 SB。
    • 设备 C 也可以进行同样的操作生成签名片段 SC，但在这个例子中我们只需要两个签名片段。

  4. 签名片段收集和聚合

    • 选取两个设备（例如 A 和 B）的签名片段（SA 和 SB）。
    • 这些签名片段通过安全的通道交换到一个中心点（可以是其中一个设备或一个独立的协调者）。

  5. 生成最终签名

    • 在中心点，签名片段 SA 和 SB 被聚合，形成最终的完整签名 S。
    • 这个签名 S 在数学和结构上等同于使用一个未分割的私钥所生成的签名。

  6. 签名应用

    • 最终的签名 S 被用于验证交易，确保交易的合法性和安全性。

图形元素​

  • 方框：表示操作或过程，如“生成私钥分片”、“计算部分签名”、“聚合签名”。
  • 箭头：表示数据流或操作顺序，指向下一个操作步骤。
  • 圆圈：可以表示参与者或设备，如 A、B、C。

根据上述描述，你可以使用任何绘图工具（如 Microsoft PowerPoint、Visio，或在线绘图工具如 Lucidchart、Draw.io）来绘制这个流程图。这将帮助你更直观地理解 MPC-TSS 的工作原理和过程。

MPC-TSS 基础流程图​

以下是使用 Mermaid 语法来描述 MPC-TSS（多方计算门限签名方案）的一个基础流程图。Mermaid 是一种流行的、基于文本的图表制作工具，可以很方便地集成到 Markdown 文件中。

如何使用这个 Mermaid 图​

  1. 私钥分片生成：私钥被分割成多个份额。
  2. 分片分发：每个份额分别安全地分发到不同的设备。
  3. 交易数据：需要签名的交易数据被发送到所有设备。
  4. 设备 A/B/C 计算部分签名：每个设备使用其私钥份额对交易数据进行部分签名。
  5. 签名片段收集：从各设备收集部分签名片段。
  6. 签名聚合：将收集到的签名片段聚合。
  7. 生成最终签名：聚合后生成最终的签名。
  8. 签名应用：最终签名被用于验证交易。

使用场景​

这个 Mermaid 图可以直接嵌入支持 Mermaid 的 Markdown 编辑器或者其他支持 Mermaid 的平台中，如 GitHub 的 README 文件、GitLab、或者其他支持 Mermaid 的文档工具中。这样可以直观地展示门限签名的流程，便于理解和交流。

1. 完整 MPC-TSS 流程图​

如果要将密钥分片刷新作为一个可选的、按需执行的步骤，我们可以将其设置为一个独立的模块，用户可以根据需要触发这一过程。这种方式允许用户在认为必要时更新密钥分片，例如在怀疑密钥泄露或者为了遵守某些安全政策时。下面是调整后的流程图，展示了如何将密钥分片刷新作为一个独立的、按需执行的模块：

1-1. 完整 MPC-TSS 流程图 需要验证​

详细说明​

  1. 用户请求刷新密钥分片 - 用户或系统管理员可以在认为有必要时发起密钥分片的刷新请求。这可以是基于时间的策略，如每年一次，或者是基于事件的策略，如在密钥可能被泄露后。

  2. 密钥分片刷新 - 一旦接收到刷新请求，系统使用安全多方计算（SMC）技术来生成新的密钥份额。这个过程确保密钥更新的同时不会泄露任何私钥信息。

  3. 重新分发新的密钥分片 - 新的密钥份额通过安全的通道分发给所有参与方，替换旧的密钥份额。

这种按需刷新模式为用户提供了更大的灵活性和控制权，使他们可以根据自己的安全需求和政策来更新密钥。同时，它也减少了不必要的操作和资源消耗，因为密钥只在确实需要时才被刷新。

2. 完整 MPC-TSS 流程图 分组策略刷新​

如果您想将密钥分片的刷新过程分组，以便更好地管理或为不同的用户或部门设置不同的刷新策略，这是完全可行的。在这种情况下，您可以设计一个系统，其中密钥分片按组进行管理和刷新。每个组可以有自己的刷新触发条件，比如时间间隔、特定事件或手动触发。以下是一个示例流程图，展示了如何将密钥分片刷新分组进行管理：

详细说明​

  1. 分组管理 - 系统可以根据不同的安全需求、地理位置或部门功能将密钥分片划分为不同的组。每个组可以有自己独立的刷新策略，并且可以独立触发刷新过程。

  2. 组密钥刷新 - 每个组可以根据预设的条件或按需请求进行密钥刷新。这样的设计使得密钥管理更加灵活，可以针对不同的安全级别或操作需求进行优化。

  3. 重新分发新的密钥分片 - 无论是哪一个组的密钥被刷新，新的密钥份额都需要通过安全的通道重新分发给该组的所有参与方。

这种分组方法不仅提高了密钥管理的效率和安全性，还允许不同的组根据其具体需求进行操作，从而提高整个系统的灵活性和响应能力。

3. 完整 MPC-TSS 流程图 密钥分片验证​

在密钥分片刷新过程中，密钥分片验证是一个非常重要的步骤。它确保每个设备接收到的密钥分片是正确且完整的，从而保证整个分布式签名方案的安全性和可靠性。

为什么需要密钥分片验证？​

  1. 安全性：验证密钥分片的正确性可以防止恶意参与者发送错误或篡改的分片，从而破坏整个系统的安全性。
  2. 完整性：确保所有设备接收到的密钥分片是完整的，防止由于分片丢失或损坏导致的签名失败。
  3. 一致性：验证分片可以确保所有设备使用的密钥分片是一致的，从而保证签名的正确性。

密钥分片验证的流程​

在密钥分片刷新过程中，密钥分片验证通常包括以下步骤：

  1. 接收分片：设备通过安全通道接收新的密钥分片。
  2. 验证分片：设备使用零知识证明或其他验证机制，确保接收到的分片是正确且完整的。
  3. 确认分片：如果验证通过，设备确认接收到的分片可以用于后续的签名计算。

更新后的流程图​

以下是更新后的流程图，包含密钥分片验证步骤：

详细解释​

  1. 私钥分片生成 (A)：

    • 使用 Feldman's VSS（可验证秘密分享）和 BIP32（分层确定性钱包）生成私钥的多个分片。

  2. 分片分发 (B)：

    • 通过安全通道将生成的密钥分片分发到不同的设备（A、B、C）。

  3. 交易数据 (C)：

    • 从外部源获取交易数据，准备进行签名。

  4. 设备 A、B、C 计算部分签名 (D, E, F)：

    • 每个设备使用 ED25519 算法和各自的密钥份额计算部分签名。

  5. 签名片段收集 (G)：

    • 收集所有设备生成的签名片段，使用承诺方案（Commitment Schemes）确保签名片段的完整性和正确性。

  6. 签名聚合 (H)：

    • 使用 Schnorr 证明和 Paillier 加密进行签名片段的聚合。Paillier 加密的同态性质允许在加密状态下进行加法运算，聚合后的结果可以用公钥解密。

  7. 生成最终签名 (I)：

    • 聚合所有签名片段，生成最终的签名。

  8. 签名应用 (J)：

    • 将生成的最终签名应用于交易确认或文档认证，公钥可用于验证签名的有效性。

  9. 用户请求刷新密钥分片 (M)：

    • 用户请求刷新密钥分片，以提高安全性。

  10. 密钥分片刷新 (K)：

    • 使用安全多方计算（MPC）生成新的密钥分片。

  11. 密钥分片生成确认 (N)：

    • 使用零知识证明（ZKP）确保生成的密钥分片的正确性。

  12. 重新分发新的密钥分片 (L)：

    • 通过安全通道将新的密钥分片分发到不同的设备（A、B、C）。

  13. 密钥分片验证 (O)：

    • 各设备验证接收到的新的密钥分片的正确性和完整性。

  14. 设备 A、B、C 重新计算部分签名 (P, Q, R)：

    • 每个设备使用新的密钥份额重新计算部分签名。

  15. 签名片段收集和聚合：

    • 重新计算的签名片段再次进行收集、聚合和生成最终签名。

总结​

密钥分片验证是密钥分片刷新过程中的重要步骤，确保每个设备接收到的密钥分片是正确且完整的，从而保证整个分布式签名方案的安全性和可靠性。通过添加密钥分片验证步骤，可以进一步提高系统的安全性和稳定性。