毕设20 - 共享密钥方案

| 笔记 | 4115 | 11分钟 | 毕设智能合约TrustZone密码学

最后一个问题，如何让多个区块链节点可以共享一个私钥，或是共享不同私钥的但是均可以独立解密用户提供的数据。

解决方案：统一共享私钥结合TEE安全存储

  1. 系统初始化阶段：
    • 在区块链网络部署前，生成一个统一的椭圆曲线密钥对（如ECDH密钥对），包含一个公共的公钥和一个私钥。
    • 将该私钥安全注入每个区块链节点的TEE（TrustZone）安全存储中。由于TEE的保护，私钥无法被外部读取或导出，但可在TEE内部用于密码学操作。
  2. 用户加密流程：
    • 用户使用自己的私钥（如用户钱包的私钥）和区块链的统一公钥，通过密钥协商协议（如ECDH）生成共享密钥。
    • 用该共享密钥对VC（包含生日信息）进行对称加密（如AES-GCM），生成密文。
    • 用户将加密后的VC发送给电影院。
  3. 区块链节点解密验证：
    • 电影院将加密的VC转发至区块链网络。
    • 每个区块链节点在TEE内使用注入的统一私钥和用户的公钥，通过相同的密钥协商协议（ECDH）重新生成共享密钥。
    • 节点在TEE内用共享密钥解密VC，验证凭证的有效性（如签名、过期时间）和年龄是否满18岁。
    • 节点生成零知识证明（如范围证明），证明解密后的年龄满足条件，无需泄露具体生日。
  4. 去中心化与安全性：
    • 所有节点独立验证和解密，确保去中心化特性。
    • 私钥始终在TEE内受保护，即使单个节点被物理攻击，私钥也不会泄露。

关键点与优化

  • 统一私钥的安全性：依赖TEE的安全机制（如TrustZone）确保私钥无法被提取。即使攻击者物理访问节点设备，也无法获取私钥明文。
  • 动态密钥更新：为避免长期使用同一私钥的风险，可定期通过安全协议（如TEE安全通道）轮换统一私钥，所有节点同步更新。区块链运行一定时间后（产生一定数量的区块后），重新生成一次共享私钥。这也自动实现了VC过期间。

对抗性分析

  • 私钥泄露风险：由于私钥统一存储，若TEE被大规模攻破（理论上极难），整个网络可能受损。可通过门限签名方案改进（如私钥分片存储，需多节点协作解密），但会增加复杂性。

总结

通过预置统一私钥到所有节点的TEE中，利用密钥协商协议（ECDH）生成相同共享密钥，实现去中心化节点对加密VC的独立解密和验证。TEE保障私钥安全，零知识证明保护用户隐私，平衡安全性与去中心化需求。

生成共享私钥并注入所有TrustZone

1. 生成共享密钥

我觉得统一共享私钥的方案很合理。那么现在遇到另一个问题，如何安全的生成相同的共享密钥？

区块链节点运行在TrustZone中，REE部分执行非安全操作（如网络和共识），TEE部分用于执行安全操作（如智能合约、密码学操作）

以下是我想到的几个方案：

  • 固定一个随机种子，让所有节点生成同一份私钥：
    • 如果在REE中生成私钥，私钥就有泄露风险。
    • 如果在REE中生成相同的随机种子，TEE根据随机种子生成私钥？也不可行，如果泄露了随机种子，外界也可以计算出私钥。
    • 如果在TEE内部生成随机种子？不可行，不同的TEE节点无法保证生成相同的随机数。
  • 在一个TEE中生成私钥对，以某种方式广播私钥？
    • 首先OPTEE生成的私钥无法获取（也许可以修改代码想办法提取私钥）
    • 如果OPTEE的私钥可以获取，如何广播私钥？
      • 其他节点生成一个临时密钥对，并广播自己的公钥
      • **新私钥生成节点 **接受所有公钥，分别用公钥加密新私钥，广播加密后的新私钥
      • 其他节点收到加密后的私钥，用自己的临时私钥解密
    • 缺点：
      • 可能无法提取私钥
      • 广播过程、反复加密解密的过程，导致效率极低
  • （摆烂方案）预先生成一个私钥，在区块链节点部署前注入TrustZone。在该系统的威胁模型中假如“假设共享私钥不会泄露”。

我认为上述方案都不够好，有更好的方案吗？或者我的方案可以修改成实际可行的吗？

Deepseek和ChatGPT都提供了**门限秘密共享（Threshold Secret Sharing）和安全多方计算（MPC）**的方案。

但是都有一个前提，需要多个节点共同运作才能解密。

而且，这个过程需要在多个TEE节点之间建立安全通道。既然可以这样做，那么直接在多个TEE之间共性同一个秘钥也是可行的。门限秘密共享方案仅仅实现了单一节点的私钥泄露不会破坏系统安全性。但是该系统威胁模型就是TEE无法被攻陷。

所以回到最初的方案，获取秘钥。

2. 秘钥注入TrustZone

这一步简单，只要OPTEE支持有一种方式传入私钥即可。

完成！！！

剩余工作，整理代码存到github上。

在香橙派中运行多个节点，进行多节点的功能测试和性能测试。

写毕业论文，准备毕业答辩。

存在的问题即解决思路

问题1：TEE与REE通信的反向调用机制

问题描述：
OP-TEE架构将系统分为可信执行环境(TEE)和富执行环境(REE)，传统上只支持REE向TEE发起请求的单向通信模式。在本毕业设计中，wasm智能合约运行在TEE的安全虚拟机中，但智能合约执行过程中需要实时访问和修改区块链状态数据，这些数据位于REE中。如何实现TEE中的智能合约能够主动向REE发起请求，突破传统TEE-REE通信的单向限制？

解决思路：
设计了基于共享内存的双向通信机制：

  1. 在REE中申请一块共享内存区域，确保TEE和REE均有读写权限
  2. 区块链节点在调用智能合约时分出两个并行线程：
    • 主线程负责调用TEE中的智能合约
    • 监听线程持续轮询共享内存区域，检测来自TEE的请求
  3. 实现了防止编译器优化的内存屏障机制，确保数据读写顺序正确
  4. 设计了请求-响应协议，支持get/set等操作类型
  5. 当智能合约需要访问链上数据时，将请求写入共享内存并设置标志位
  6. REE监听线程检测到请求后，执行相应操作并将结果写回共享内存
  7. TEE中的智能合约从共享内存获取结果继续执行

这种机制实现了TEE到REE的反向调用，同时保持了TEE的安全隔离特性，不需要修改OP-TEE的核心架构。

问题2：基于TrustZone的隐私保护数字身份验证

问题描述：
传统的分布式数字身份(DID)系统通常依赖纯数学层面的零知识证明算法，这些算法计算复杂且难以实现。如何利用ARM TrustZone提供的可信执行环境，设计一种更高效、更安全的隐私保护数字身份验证机制，充分发挥硬件可信根的优势？

解决思路：
设计了基于TEE的隐私保护验证流程：

  1. 用户DID文档中包含一个ECDH公钥用于安全密钥交换
  2. 区块链网络中的所有节点共享同一ECDH密钥对：
    • 私钥安全存储在OP-TEE的隔离空间中，永不离开TEE
    • 公钥公开存储在区块链上，任何实体可获取
  3. 用户通过区块链公钥与自身私钥计算共享密钥，使用该密钥对可验证凭证(VC)进行AES加密
  4. 验证流程保护用户隐私：
    • 验证机构无法直接解密用户VC，保护敏感信息
    • 验证请求转发至区块链节点的TEE环境
    • TEE环境使用安全存储的私钥与用户公钥计算共享密钥
    • 在TEE内部解密VC并验证内容，仅向外部返回验证结果
  5. 整个过程中敏感数据始终在TEE内处理，未加密数据不会暴露给REE

这种方案将密码学保护与硬件隔离相结合，提供了比纯软件方案更强的安全保证，同时降低了计算复杂度。

问题3：支持Rust编写的复杂Wasm智能合约

问题描述：
本毕业设计参考《WaTZ: A Trusted WebAssembly Runtime Environment with Remote Attestation for TrustZone》论文，在OP-TEE中实现了 wasm 虚拟机。然而，论文中使用的WAMR(WebAssembly Micro Runtime)不支持WebAssembly的”多内存提案”(Multi-Memory Proposal)特性，导致无法运行由Rust语言编译的复杂智能合约。Rust作为一种内存安全的系统级语言，非常适合编写智能合约，但其编译产生的Wasm模块通常依赖多内存特性和更复杂的内存管理机制。如何扩展TEE中的WebAssembly运行时，使其能够支持现代Rust编译的智能合约？

解决思路：

  1. 首先分析了Rust编译为wasm时的内存模型与C的区别：
    • C 语言编译的wasm使用简单的内存模型，直接调用malloc分配内存
    • Rust需要自定义内存分配器，且默认会生成更复杂的内存管理代码
    • 通过实验对比发现Rust编译的wasm会使用多内存提案特性
  2. 修改WAMR运行时和OP-TEE以支持多内存提案：
    • 放弃使用论文中的旧版WAMR，迁移至最新版本的WebAssembly Micro Runtime
    • 重新实现了WAMR与OP-TEE的全部接口层，包括内存管理、系统时钟等
    • 在OP-TEE中实现了mprotect系统调用，修改内存区域的保护属性
  3. 解决内存分配问题：
    • 采用Rust的no_std模式编译，并引入轻量级内存分配器wee_alloc，显著降低内存开销
    • 根据TEE环境的实际内存限制，调整WAMR的内存模型参数

通过以上方案，成功在OP-TEE的TEE环境中运行了由Rust编写的复杂wasm智能合约，解决了多内存提案支持问题，并克服了TEE环境下的内存限制。这使得可以在保证安全隔离的同时，利用Rust语言的安全特性开发更复杂、更可靠的智能合约。

下一阶段工作计划与研究内容

  1. 多节点分布式测试环境搭建：
    • 在多台华为香橙派开发板上部署完整的区块链节点
    • 构建基于局域网的区块链测试网络
  2. 功能测试与验证：
    • 测试智能合约在多节点环境下的一致性执行
    • 验证节点间状态同步和共识机制的正确性
    • 进行各类异常情况下的系统恢复测试
  3. 性能测试与优化：
    • 测量交易处理吞吐量和延迟
    • 分析TEE环境下智能合约执行效率
    • 评估系统在不同负载下的资源消耗
    • 比较与传统区块链系统的性能差异
  4. 安全性分析与评估：
    • 进行系统安全威胁建模
    • 评估潜在攻击面和防御措施
  5. 毕业论文撰写毕业答辩准备