当前位置:   article > 正文

ZLiTE Lightweight Clients for Shielded Zcash Transactions using Trusted Execution_zlite: lightweight clients for shielded zcash tran

zlite: lightweight clients for shielded zcash transactions using trusted exe

ZLiTE: Lightweight Clients for Shielded Zcash Transactions using Trusted Execution

论文:Cryptology ePrint Archive: Report 2018/1024 - ZLiTEyoutube解读

相关论文:Bite: Bitcoin Lightweight Client Privacy using Trusted ExecutionCSDN解读

0 摘要Abstract

问题:

  1. 普通区块链加密货币在交易中使用假名,容易从交易所溯源,泄露交易者隐私(zcash)
  2. zcash是用零知识证明保护shield transaction的收发方和金额的私密货币,用户必须用viewing key扫描区块链,尝试解锁每一笔交易来测试交易是否属于自己,移动设备计算与网络资源不支持。
  3. 客户端消费需构建实时更新的witness,移动设备计算与网络资源不支持。

ZLiTE:“轻客户端”的系统

  1. 服务器端:TEE(SGX)保证代码执行完整&数据机密,rORAM内存机制防止侧通道泄露敏感信息
  2. 客户端:发送viewing key给全节点以确认收款,并接收update构建witness以付款

1 简介Introduction

  • Zcash:解决交易隐私问题
    零知识证明存在一些过去的交易,这些交易给了用户他们可以花费的资金,从而删除了所有信息,如发送者/接收者的身份、金额和可链接性。

  • 收款通知:协调shield transaction
    以太坊:account;比特币:UTXO扫描区块链并检查每个事务;
    Zcash tx:(一个不透明的承诺、一个密文、一个防止重复消费的序列号,以及一个零知识证明交易的正确性和可用资金的存在)链上tx没有明文标志接受者的元数据,客户识别付款:解密tx中以接收者的公钥加密的密文。pc平台的资源充足的客户端可行,但资源紧张的移动设备客户端不可行。

  • 创建交易:协调shield transaction
    在zcash中需要提供witness以创建交易,witness是资金来源tx到最新区块tx构建的note commitment tree(Merkle tree),且需要动态实时更新新tx。

  • ZLiTE系统:私有信息检索+侧通道弹性可信执行+新的承诺树更新机制

2 背景Background

  • 屏蔽交易shielded transaction
    input note -> joinsplit -> output note
    nullifier:更新note set
    spending key & viewing key
    lightweight client:仅存block header,满足利用merkle tree验证交易

  • ORAM:隐藏内存的address、access pattern、read/write

  • SGX
    并不是识别和隔离平台上的所有恶意软件,而是将合法软件的安全操作封装在一个enclave中,保护其不受恶意软件的攻击,特权或者非特权的软件都无法访问enclave,也就是说,一旦软件和数据位于enclave中,即便操作系统或者和VMM(Hypervisor)也无法影响enclave里面的代码和数据。

3 解决方案 approach

  • Requirements
    • R1 Privacy. 不泄露隐私viewing key,transaction count, blocks containing transactions
    • R2 Integrity.资金完整 *** 即使TEE受损也要保证
    • R3 Completeness.信息完整(收/付款所需)
    • R4 Performance.性能

4 ZLiTE system

  • 架构
    在这里插入图片描述

  • 交易检索Transaction Retrieval(收款通知)

    • Initialization

    a. ZFN初始化:连接p2p网络,下载完整zcash blockchain并不断更新
    b. ZLC初始化:从p2p网络请求所有新block header,用安装包中原始block header验证;保留最近block header用以处理浅分叉,并不断更新。

    • Synchronization Protocol

    (1)ZLC对ZFN远程认证(remote attestation)
    (2)认证成功,则建立TLS安全通信隧道
    (3)ZLC请求(viewing key用以解密s-tx,h标志从已知区块高度开始检索)
    (4)ZFN创建rORAM以存储要返回的tx;从h层开始用viewing key扫描BC;
    ​ DE成功,tx写入rORAM;
    ​ DE失败,用cmov技术进行读取操作(与写入操作看起来一样,混淆侧信道)
    (5)ZFN将rORAM序列化,返回数据(tx,block headers,note commitment tree update)
    (6)ZLC验证block header PoW和merkle tree,更新witness
    在这里插入图片描述

  • 交易创建Transaction Creation
    witness路径根据note commitment tree得出,其需要根据最新区块更新。客户端保存已构建的note commitment tree,再根据update更新witness。
    在这里插入图片描述
    在这里插入图片描述

5 安全分析Security Analysis

  • 信息泄露Information Leakage
    1、ORAM的read/write不可区分,且cmov使控制流独立于tx,以此向侧信道掩饰相关tx
    2、response大小与扫描的区块数量h有关,与tx数量无关

  • 资金完整性与数据完整性Integrity and Completeness
    1、ZLC验证PoW,从p2p中其他节点接收block header以确保最长链,抵御eclipse攻击
    2、ZLC通过TEE attestation保证代码完整运行,相比SPV可以确定接收到所有收款通知

  • SGX完全受损Full SGX Compromise
    假如ZFN的enclave内数据泄露,则viewing key隐私泄露(R1),spending key仍在ZLC保密(R2)

  • 信任假设Trust Assumption
    与Zcash相同,要求大多数诚实的挖矿节点,且p2p广播信息不被eclipse攻击

6 性能分析Performance

在这里插入图片描述

7 相关工作Related Work

1、BIP37
2、BITE
3、Zcash Scalable Clients
4、Decentralized anonymous micropayments
5、Bolt: Anonymous payment channels for decentralized currencies

8 结论Conclusion

1、ZLC轻客户端可以创建和接收屏蔽支付。
2、TEE改变了Zcash的原始信任模型(viewing key->ZFN),但在最好的隐私和Zcash使用场景间取舍平衡。
3、开发支持屏蔽交易的移动客户端成为可能,更多用户可以受益于Zcash完善的隐私保护。

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/小丑西瓜9/article/detail/687293
推荐阅读
相关标签
  

闽ICP备14008679号