21、后量子密钥托管用于监督式秘密数据共享

后量子密钥托管用于监督式秘密数据共享

1. 基础知识

在当今的信息安全领域，区块链和加密技术的结合日益重要。下面我们将介绍一些相关的基础知识。

1.1 联盟区块链与Hyperledger Fabric

联盟区块链在一组组织的管理下运行，为那些有共同目标但彼此不完全信任的组织之间的交互提供了安全保障。例如，组织内或组织间共享秘密数据的对等节点与数据监督组织之间的交互。

在现有的联盟区块链项目中，Hyperledger Fabric是较为成功的一个。它支持在一个通道内的组织和对等节点联盟上执行分布式应用程序（即链码，也称为智能合约），其业务逻辑可以用标准的通用编程语言（如Go、Node.js、Java）编写成链码。

Hyperledger Fabric采用了执行 - 排序 - 验证架构，部署了背书节点、提交节点、排序器和客户端，节点可以按所属组织分组。所有链码在执行前都需要在特定节点上实例化。其工作流程如下：
1. 客户端向背书节点提交交易提案，调用链码执行。
2. 背书节点执行链码并为执行结果生成签名，然后将背书提案返回给客户端。
3. 客户端将背书提案广播给排序器。
4. 排序器为通道内所有提交的交易建立全局顺序，将这些交易批量打包成新块，并分发给通道内的所有提交节点。
5. 提交节点验证新块中的每个交易，并将块追加到分布式账本中。

在Hyperledger Fabric执行过程中，节点可以通过键访问链上数据，键类似于绑定到实例化链码的成员变量，一个键可以是单个数据或数据元组。所有对数据和实例化链码的修改/更新都会被记录，便于监督。

除了链上数据，节点和组织可能在自己的链下私有数据库中保存秘密数据。当秘密数据在线共享时，节点和组织会上传加密数据以防止数据被其他意外参与者获取，但这可能会违反区块链的透明度和可追溯性。因此，基于密钥托管的监督式秘密数据共享应运而生，它平衡了链上数据保密性和透明度的需求。

下面是Hyperledger Fabric的工作流程示意：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;

    A(客户端):::process -->|提交交易提案| B(背书节点):::process
    B -->|返回背书提案| A
    A -->|广播背书提案| C(排序器):::process
    C -->|分发新块| D(提交节点):::process
    D -->|追加到分布式账本| E(分布式账本):::process

1.2 密钥托管系统与示例协议

密钥托管的原始概念由Silvio Micali在其关于公平公钥密码系统的工作中提出。在密钥托管系统中，交换的秘密数据使用预先协商的会话密钥进行加密，并且通信中使用的每个会话密钥都被托管（例如，使用托管密钥进行非对称加密）。通常，执法机构（称为托管代理）可以恢复托管的会话密钥（例如，使用相应的托管密钥进行非对称解密），并使用恢复的会话密钥进一步解密秘密数据（在金融监管和司法取证的情况下）。如果一个托管代理不完全可信，系统可以配置多个托管代理。因此，一个密钥托管系统由两组实体组成：共享用于保护交换秘密数据的会话密钥的用户和恢复会话密钥的托管代理。

我们以一个基于软件的密钥托管协议为例，该协议涉及两个用户和两个托管代理。在这个示例协议中，两个密钥托管代理KEA1和KEA2分别有自己的公钥/私钥对，分别表示为(KEA1Pub, KEA1Priv)和(KEA2Pub, KEA2Priv)，两个公钥分别集成到用户A和B执行的密钥托管程序（即PA和PB）中。该示例密钥托管协议的执行步骤如下：
1. 假设用户A想向用户B发送消息M。首先，A和B需要预先协商一个会话密钥SK。
2. 然后，A将M和SK输入到他/她的密钥托管程序PA中，该程序将输出以下信息：
- 使用会话密钥SK对称加密的消息C = SEncSK(M)。
- 两个随机生成的临时会话密钥SK1和SK2在两个密钥托管代理的公钥下非对称加密的串联，其异或结果为会话密钥SK。串联表示为LEAF = AEncKEA1Pub(SK1) || AEncKEA2Pub(SK2)，其中SK = SK1 ⊕ SK2。
3. 用户B收到用户A的上述消息后，将它们与会话密钥SK一起输入到他/她的密钥托管程序PB中，该程序将使用会话密钥SK解密加密消息C以获得消息M。
4. 为了监听用户A和用户B之间的通信，监督部门需要向两个密钥托管代理KEA1和KEA2出示法院命令和LEAF信息，两个代理将分别使用自己的私钥解密相应组件，并将SK1和SK2返回给监督部门。最后，监督部门使用SK1 ⊕ SK2解密加密消息C，最终获得消息M。

实现基于软件的密钥托管系统的关键是确保密钥托管程序（如PA和PB）正确执行，不被恶意用户修改，而联盟区块链可以为数据、身份和代码执行的完整性和可追溯性提供保障，解决这个问题。

1.3 NIST后量子公钥加密/密钥封装机制（KEM）算法

在NIST后量子公钥加密/KEM算法的第三轮（当前轮）征集提案中，有四个决赛入围者（即Classic McEliece、CRYSTALS - KYBER、NTRU、SABER）和五个备选候选者（即BIKE、NTRU Prime、FrodoKEM、SIKE、HQC）。决赛入围者将在第三轮结束后继续接受审查以考虑标准化，而备选候选者只是有可能被标准化（很可能在第三轮结束时不会发生），但可能由于各种原因（如更好的性能、更高的安全级别、更广泛的硬度假设）在NIST的第四轮评估中被重新考虑。

为了消除填充方案的复杂性和证明填充安全性所需的证明，NIST目前只公布了后量子公钥加密/KEM算法的KEM模式（而不是加密/解密模式）。一个密钥封装机制KEM包括以下三个步骤：
- 密钥生成步骤KEM.KeyGen()，输出公钥/私钥对(pubKey, privKey)。
- 封装步骤KEM.Encap(pubKey)，以公钥pubKey为输入，输出共享秘密/密文对(SS, CT)。
- 解封装步骤KEM.Decap(privKey, CT)，以相应的私钥privKey和密文CT为输入，输出共享秘密SS。

在基于KEM的协议中，Alice生成共享秘密SS和封装SS的密文CT，Bob从CT中解封装出SS。共享秘密SS进一步用作对称密钥，用于加密/解密Alice和Bob之间交换的秘密数据。

以下是NIST第三轮征集提案中所有决赛入围者和备选候选者的详细信息总结：
| 算法 | 类型 | 说明 |
| ---- | ---- | ---- |
| Classic McEliece | 决赛入围者 | - |
| CRYSTALS - KYBER | 决赛入围者 | - |
| NTRU | 决赛入围者 | - |
| SABER | 决赛入围者 | - |
| BIKE | 备选候选者 | - |
| NTRU Prime | 备选候选者 | - |
| FrodoKEM | 备选候选者 | - |
| SIKE | 备选候选者 | - |
| HQC | 备选候选者 | - |

通过使用不同的密钥大小，所有算法都可以达到不同的NIST安全级别（即安全位级别），NIST安全级别1 - 5大约对应128/160/192/224/256位的安全级别。与共享秘密大小相比，所有算法的公钥、私钥和密文大小都相对较大，这表明后量子密钥托管系统可能会消耗大量存储资源。

2. 系统设计与实现

2.1 系统架构与执行流程

PQ - KES4Chain是为联盟区块链设计的密钥托管系统，主要基于智能合约，不依赖任何加密芯片的保护。底层联盟区块链可以保证托管相关数据的完整性，同时，开发人员应在客户端代码中预先记录和检查所有预期链码的版本号，以防止恶意节点修改或伪造已安装的链码。

PQ - KES4Chain中的节点分为三类组织：数据共享组、托管代理组和监督组。数据共享组织包括愿意将会话密钥托管给托管代理的发送/接收节点；托管代理组织和监督组织分别包含一个托管代理节点和一个监督节点，会话密钥托管给托管代理节点，监督节点可以从托管代理节点获取恢复的会话密钥。为防止托管代理不可信，PQ - KES4Chain配置了两个托管代理节点（分别位于两个托管代理组织），并使用两个链上私有数据库（即私有数据集合，PDC）来防止托管代理节点读取为监督节点准备的彼此的链上数据。

由于NIST只提供了所有相关后量子算法的KEM模式，我们需要设计相应的密钥托管系统执行流程。PQ - KES4Chain的执行流程包括六个阶段：
1. 初始化 ：部署所有组织和节点，然后在特定节点上实例化三个链码：接收者链码、发送者链码和托管链码。前两个链码安装在数据共享组织的每个节点上，后两个链码安装在托管代理组织和监督组织的每个节点上。为保护交换的秘密数据，PQ - KES4Chain要求发送和接收节点预先协商一个会话密钥SK（可以通过链下方法或基于后量子KEM算法的链上会话）。此外，需要初始调用托管链码为每个托管代理生成一个后量子公钥/私钥对（分别表示为pubKey1/privKey1和pubKey2/privKey2），用于托管和恢复发送节点与托管节点之间的共享秘密。由于链上数据元组通过键访问，一次发送 - 接收 - 监督会话需要事先离线约定发送者数据的键和托管代理的公钥（分别表示为SD键和EAPK键），它们分别绑定到发送者链码和托管链码。SD键指向发送节点生成的加密秘密数据和托管的共享秘密。
2. 秘密数据准备 ：初始化步骤完成后，发送节点从其链下私有数据库中读取秘密数据M，为密钥托管过程做准备。
3. 加密秘密数据和托管共享秘密的生成与上传 ：秘密数据准备好后，发送节点调用发送者链码，执行以下操作：
- 发送者链码使用预先协商的会话密钥SK对称加密秘密数据M（表示为C = SEncSK(M)）。
- 由于NIST只提供KEM模式，发送节点使用托管代理的公钥pubKey1和pubKey2（在EAPK键下绑定到托管链码）执行封装操作，生成两个托管的共享秘密（表示为ESS1和ESS2）和两个密文（表示为CT1和CT2）。
- 发送节点使用ESS1和ESS2的异或结果作为密钥对称加密秘密数据M（即C′ = SEncESS(M)，其中ESS = ESS1 ⊕ ESS2）。
- 发送节点将C、C′、CT1和CT2的串联上传到绑定到发送者链码的SD键下的发送者数据元组中。由于Hyperledger Fabric的特性，接收节点和托管代理节点只能通过调用发送者链码来检索发送者数据。
4. 秘密数据的下载与解密 ：加密秘密数据C生成并上传后，接收节点调用接收者链码，使用预先协商的会话密钥SK解密秘密数据，最终获得交换的秘密数据M（即M = SDecSK(C)）。
5. 会话密钥/共享秘密的恢复 ：当需要披露交换的秘密数据时，两个托管节点调用托管链码，使用自己的私钥privKey1和privKey2以及存储在SD键下的密文CT1和CT2分别恢复托管的共享秘密ESS1和ESS2。托管共享秘密的解封装表示为ESS1 = Decap(privKey1, CT1)和ESS2 = Decap(privKey2, CT2)。然后将ESS1和ESS2写入绑定到托管链码的ESS键中。
6. 秘密数据的解密 ：一旦托管的共享秘密ESS1和ESS2准备好，监督节点调用托管链码，通过计算ESS1和ESS2的异或结果恢复ESS，从绑定到发送者链码的SD键中读取对称加密消息C′ = SEncESS(M)，最终解密C′以获得交换的秘密数据M。

下面是PQ - KES4Chain的执行流程示意：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;

    A(初始化):::process --> B(秘密数据准备):::process
    B --> C(加密秘密数据和托管共享秘密的生成与上传):::process
    C --> D(秘密数据的下载与解密):::process
    D --> E(会话密钥/共享秘密的恢复):::process
    E --> F(秘密数据的解密):::process

2.2 系统实现

PQ - KES4Chain的主要实现包括三个链码：发送者链码、接收者链码和托管链码。发送者链码提供生成/上传加密秘密数据和托管共享秘密（即发送者数据）的API，以及为其他链码检索发送者数据的API。接收者链码仅提供解密加密秘密数据的API，而托管链码可以被调用来生成托管代理的公钥/私钥对、获取相关公钥、使用私钥解封装/恢复共享秘密以及使用解封装的共享秘密解密秘密数据。

为了帮助开发人员创建后量子监督式秘密数据共享应用程序，还提供了客户端代码，如下所示：
| 客户端代码 | 功能 |
| ---- | ---- |
| Sender | 调用发送者链码API |
| Receiver | 调用接收者链码API |
| Escrow1_0 | 调用托管链码为托管代理1生成后量子密钥对 |
| Escrow2_0 | 调用托管链码为托管代理2生成后量子密钥对 |
| Escrow1_1 | 调用托管链码解封装托管给托管代理1的共享秘密 |
| Escrow2_1 | 调用托管链码解封装托管给托管代理2的共享秘密 |
| Supervisor | 调用托管链码使用解封装的共享秘密解密秘密数据 |
| CAUtil | 被其他客户端代码调用以获取Hyperledger Fabric CA证书 |
| AppUtil | 被其他客户端代码调用以获取系统的设置信息 |

所有代码的安全设计和实现的详细分析将在后续部分介绍，所有代码可在指定位置获取。

3. 安全分析

在实际应用中，保障系统的安全性至关重要。接下来，我们将介绍PQ - KES4Chain的威胁模型，阐述如何设计和实现该系统以保护链上数据和链码免受威胁模型中的攻击，还会分析如何在实际应用场景中结合后量子KEM算法和其他加密算法，以在量子计算机攻击下达到足够的安全级别。

3.1 威胁模型

PQ - KES4Chain中的所有节点都可能尝试进行攻击，以绕过或破坏密钥托管系统。恶意节点可能发起的攻击如下：
- 恶意发送/接收节点 ：可能会修改或替换属于其他发送 - 接收会话的SD键下的发送者数据，还可能试图读取不应在托管代理组织外暴露的ESS键下的托管共享秘密。
- 恶意托管节点 ：可能会尝试恢复或修改托管给其他托管节点的ESS键下的托管共享秘密。
- 恶意监督节点 ：可能会在没有托管代理帮助的情况下，尝试恢复ESS键下的托管共享秘密（以获取会话密钥并进一步解密秘密数据）。

此外，所有恶意节点都可能试图生成或替换EAPK键下的托管代理公钥，以误导发送/接收节点使用伪造的公钥，并且可能会修改/更新链码以绕过原始链码中的安全检查。

下面用表格总结不同类型恶意节点可能的攻击行为：
| 恶意节点类型 | 可能的攻击行为 |
| ---- | ---- |
| 恶意发送/接收节点 | 修改或替换SD键下发送者数据；读取ESS键下托管共享秘密 |
| 恶意托管节点 | 恢复或修改其他托管节点的ESS键下托管共享秘密 |
| 恶意监督节点 | 无托管代理帮助下恢复ESS键下托管共享秘密 |
| 所有恶意节点 | 生成或替换EAPK键下托管代理公钥；修改/更新链码 |

3.2 安全设计

为了保护PQ - KES4Chain免受恶意节点的攻击，我们开发并部署了安全机制，以确保链上数据和链码的完整性和保密性。

• SD键下发送者数据的完整性 ：为了简化，我们没有对发送者数据的完整性进行检查。但开发者可以通过基于会话密钥SK（和时间戳）计算消息认证码（MAC），将MAC附加到发送者数据上并验证MAC来实现这一检查。MAC还可以用于验证发送者的身份。
• EAPK键下托管代理公钥的完整性 ：我们在托管链码中使用getCreator() API（在shim包中）进行访问控制，以确保只有托管节点可以调用托管链码中的Gen_EA_KeyPair() API来生成托管代理的密钥对，并将公钥存储在EAPK键下。

以下是安全设计措施的流程示意：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;

    A(发送者数据完整性检查):::process -->|计算MAC| B(MAC附加与验证):::process
    C(托管代理公钥完整性):::process -->|访问控制| D(仅托管节点生成公钥):::process

在实际应用中，结合后量子KEM算法和其他加密算法可以有效抵御量子计算机的攻击。例如，在PQ - KES4Chain密钥托管系统中，使用后量子KEM算法进行密钥的生成、封装和解封装，同时结合对称加密算法对秘密数据进行加密和解密。通过这种方式，可以在量子计算机攻击下达到足够的安全级别，确保系统的安全性和可靠性。

综上所述，PQ - KES4Chain通过合理的系统设计、实现和安全机制，为联盟区块链环境下的秘密数据共享提供了一种有效的密钥托管解决方案。它平衡了数据保密性和透明度的需求，同时能够抵御来自恶意节点的攻击，在量子计算机时代为数据安全提供了有力保障。开发人员可以基于提供的链码和客户端代码，进一步创建后量子监督式秘密数据共享应用程序。