2021年12月科研月报
目录
- 本学期科研规划
- 本月规划
- 第一周 2021/11/29 – 2021/12/05
- 第二周 2021/12/06 – 2021/12/12
- 第三周 2021/12/13 – 2021/12/19
- 第四周 2021/12/20 – 2021/12/26
本学期科研规划
在fabric区块链中使用sgx技术，将chaincode放入enclave中运行，保护智能合约运行安全。
本月规划
调研针对fabric链码的攻击方法，并进行防御测试，15日前完成调研工作。月底前完成整体论文。
第一周 2021/11/29 – 2021/12/05
本周工作情况和进展
链码修复工具
上周调研后发现，针对链码的攻击都是从代码漏洞出发的，如全局变量、恶意跳转等。像以太坊、比特币的智能合约攻击也都是从代码编写层面考虑的，因此在阅读相关论文后，想添加一个自动修复fabric链码的功能。
调研后发现fabric有revive^CC这个静态分析工具，只能对源码进行漏洞检测，会检查全局变量、多线程、随机数使用、读写冲突等情况，如下图：
但该工具只是对源码进行检测，不能直接对可执行程序打补丁，所以不能直接用于我们的系统。fabric可视化
因为要对链码进行攻击，使用终端查看很不方便，因此我想将fabric可视化，更直观地查看区块和交易情况。和之前测试工具caliper一样，Hyperledger社区内也有可视化工具。
Hyperledger Explorer是一个简单，功能强大，易于使用，高度可维护的开源区块链浏览器，用于查看底层区块链网络上的活动。
通过explorer可以看到网络中的区块信息和交易内容，使用后界面如下：
sgx可视化
在思考fabric可视化后，考虑到攻击enclave中的链码，需要能够“看到”enclave，因此搜索了enclave的可视化方法，找到了sgxtop项目，它可以列出enclave数目、整体enclave内存使用、分页速率和正在使用的enclave，以及它们的内存使用情况和所属进程的信息。
因为该项目需要卸载原有的isgx driver，安装适配sgxtop的sgx驱动，因此我还没有在自己电脑上测试，官方的测试效果如下：
针对链码的攻击面
阅读使用sgx保护fabric相关论文和参考文献后，提到比较多的工作如下：
[1] The Hyperledger Private Data Objects (PDOs)（Private Data Objects: an Overview）
[2] Ekiden（Ekiden: A Platform for Confidentiality-Preserving, Trustworthy, and Performant Smart Contracts）
[3] The R3 Corda distributed ledger platform（Corda: A distributed ledger）
[4] Hawk（Hawk: The Blockchain Model of Cryptography and Privacy-Preserving Smart Contracts）
[5] Coco framework（CCF: A Framework for Building Confidential Verifiable Replicated Services）
这几篇论文都是与TEE或者sgx相关的，但都没有提到攻击方式，反倒是重点讲述隐私问题，以保护区块链、链码隐私开题，然后介绍加强执行过程的隐私保护。
如：区块链数据是公开的。因此，现有的智能合约系统缺乏保密性或隐私性:它们无法安全地存储或计算敏感数据(例如，拍卖出价、金融交易)。
因此我觉得找不到一个具体的攻击方法。这几篇论文倒是可以放到一起对比，然后写入related work部分。
在调研过程中我发现了一篇浙江大学的硕士论文（基于区块链和TEE的可信计算平台设计与开发_钟雨涵），该论文和我们工作方向一致，并且作者是完全使用C语言编写sgx部分，使用cgo来与fabric链码go语言部分交互的，和之前提出的想法一样。而我们的工作与之相比就过于简单，所以画不出与他一样的框架图。该论文也没有提到攻击方法。
存在的问题
找不到与之相关的攻击方法，我觉得还是需要从隐私和执行保护入手。
下周工作计划
阅读上述五篇相关论文，写一篇方法对比报告。（准备毕业开题答辩ppt）
第二周 2021/12/06 – 2021/12/12
本周工作情况和进展
因为上周调研工作不太完善，并且也没有总结好，本周继续进行攻击调研。
sgx防护功能
在攻击前先理清sgx防护功能。sgx保护enclave中的程序不被窃取、攻击，而智能合约代码是公开的，即智能合约运行的功能是已知的，sgx可以保护链码运行，保护运行中的计算过程不被窃取。而如果代码出现漏洞，恶意用户依然可以向enclave传入数据来触发漏洞。fabric和以太坊的区别
在阐述攻击方法前，有必要先了解不同区块链的区别，因为有的攻击是针对特定区块链的，不具有通用性。
1) 运行模式
以太坊是公有链，fabric是私有链，因此fabric本身就更为安全，任何节点加入都需要批准，许多攻击无法进入fabric网络，并且恶意用户可以快速溯源。
2) 货币
以太坊上有加密货币Ether，执行智能合约也伴随有花费（gas），所以以太坊有算力的概念，而fabric是没有加密货币的。因此许多由算力、花费而带来的攻击并不适用于fabric，如51%攻击、双花攻击。 fabric共识机制不是采用POW算法，而是到order里排队处理，没有算力占优就可以决定链的现象。
3) 运行环境
以太坊运行在虚拟机（EVM）中，fabric节点运行在docker容器中，docker容器本身比虚拟机安全性更高。
4) 智能合约语言
以太坊是使用的solidity，fabric使用的是go语言（也支持java、nodejs）。编程语言类的漏洞也存在一些差异。代码漏洞
此类漏洞是最常见的，去网上搜索智能合约漏洞，大多都是代码编写漏洞。针对fabric的代码漏洞有以下几类：
1) Time库
如果链码中有获取当前时间戳的操作，不同节点执行时就会产生差异。
2) 全局变量
fabric中是先执行链码，再进行背书，如果背书是需要两个节点的同意，但我只向一个节点发送请求，背书会失败，此时链码已经执行一次。那么该节点全局变量会发生变化，与其他节点的数值便不一致。
3) 多线程
4) 先写后读
如果在一个操作中先改变账本的数值，然后又读取同一个值。因为是在同一个操作中，就会放入一个区块，产生读写冲突。
总结来说代码漏洞层面的攻击很多，而且需要针对特定的功能。此类攻击无法防御，因为我们只是为链码创造可信执行环境，存在漏洞的代码依然会在enclave中执行，那么恶意用户便可以传入恶意构造数值，达到攻击。DoS攻击
智能合约的状态改变依赖于外部函数执行的结果，又未对执行一直失败的情况做出防护，那么该智能合约就可能遭受DOS攻击而停止服务。
垃圾流量占据整个区块链网络。用户的密钥被泄露，攻击者开始向网络发送大量事务垃圾邮件。
此类攻击和代码或者网络相关，我认为也是无法防御的。重入攻击
攻击者编写了对应的恶意智能合约，调用受害者的合约，同时利用自己的回调函数，循环地调用受害者合约的代码。由于是重复进入受害者合约执行对应的一段代码导致漏洞。如下图：
此类漏洞主要发生在以太坊中，以太坊在花费后有回调函数，容易触发。而Fabric作为私有链，安装链码需要批准，用户可以设置各种批准策略，因此难度更高。如果恶意链码可以安装，我们的sgx也无法防御，enclave中的合约调用外部函数依然会触发重入。回滚攻击
攻击者得到最终区块结果后，回滚到之前的状态，调整输入，创造新的有利结果如：在得到彩票结果后，回滚到未开奖状态，重新下注。这种攻击资料较少，不知道利用什么漏洞来触发回滚。假设可以触发攻击，sgx本身就容易受到回滚攻击，sgx不对输入输出进行检查，只是安全执行，因此无法防御该漏洞。隐私问题
目前所有关于TEE保护sgx的论文都是以保护智能合约隐私为目的。区块链数据是公开的。因此，现有的智能合约系统缺乏保密性或隐私性:它们无法安全地存储或计算敏感数据(例如，拍卖出价、金融交易)。
Sgx保护三种数据：
静态数据：直接获取的数据（如数据库、账本）
传递数据：传递在网络中的数据（节点间信息传递）
运行数据：运行的程序代码，参与计算（运行中的链码）
sgx可以对以上三种情况进行保护，也是所有关于sgx保护区块链论文所讨论强调的问题。我们的项目可以保护运行中的数据。链码网络安全问题（该问题来源于fabric1.0版本）
1) 窃听:通过欺骗GRPC连接和观察事务调用以及提议响应而实现。
2) peer假冒攻击:这可以通过改变链码进程的配置，诱使它连接到一个假装是peer的恶意进程来实现。
3) 链码假冒攻击:这可以通过诱使对等端相信所连接的进程是一个合法的链码，但实际上它是一个恶意进程来实现。
我们可以添加远程认证，当链码在enclave中运行后向peer节点发送证明，证明自己在可信环境中，那么就可以防御链码假冒攻击，因为假冒的链码无法提供该证明。容器安全问题（攻击权限要求较高）（来源于2020年论文）
容器安全问题来源于2020年发表的论文：Perturbing Smart Contract Execution Through the Underlying Runtime，是针对fabric运行环境docker容器提出的。
1) 不安全通信和中间人攻击
Peer和chaincode采取grpc通信，通信信息经过tls加密，但加密密钥等信息都存储在容器内。
那么就存在中间人，在容器中获取信息后使用密钥解密信息，从而窃取二者的通信信息，甚至可以篡改。此类攻击我们无法防御。
2) 镜像替换
ccenv镜像：编译链码 baseos镜像：运行链码
Fabric运行容器时只注意镜像标签tag，而不是镜像的哈希值，恶意用户可以用自己的恶意镜像打上标签，伪装成baseos镜像，从而使智能合约运行在恶意镜像中。此类攻击我认为可以防御，同样使用远程认证，被替换后的镜像无法提供远程认证，因此不被peer节点连接。
这两个攻击是基于fabric运行的环境提出的，对攻击者的权限要求较高，比如拿到主机权限或者可以访问容器。
总结来说，我认为可以防御的攻击有链码假冒攻击和容器替换攻击，同时我们的方法也可以加强智能合约执行的隐私性。
存在的问题
初步尝试替换链码进行攻击，替换后节点无法连接上新链码，导致无法处理新的智能合约运算。所有说简单替换是不行的。找不到与之相关的攻击方法，我觉得还是需要从隐私和执行保护入手。
下周工作计划
完善攻击方法，尽可能实现上述两种攻击。
添加远程认证功能。
第三周 2021/12/13 – 2021/12/19
本周工作情况和进展
本周尝试使用SGX远程认证，SGX提供两种认证方式：
Elliptic Curve Digital Signature Algorithm (ECDSA) Attestation
Intel® Enhanced Privacy ID (Intel® EPID) Attestation
ECDSA：通过Intel® Software Guard Extensions Data Center Attestation Primitives (Intel® SGX DCAP)实现第三方认证，允许用户构建他们自己的认证服务，而不是使用Intel提供的远程认证服务。该认证需要机器满足Intel SGX DCAP的安装要求，需要支持flexible launch control和AES新指令。
EPID：在不知道enclave运行在何种Intel®处理器的情况下验证enclave。使用这种技术需要一个远程认证平台，并且平台需要有互联网接入。
两种认证方式对应两个不同的sgx驱动，因此也对应两种intel处理器，支持FLC和不支持的。
ego也内置了认证方式，但是ego的认证是基于ECDSA的本地认证，因此使用了ego就不能使用EPID认证。
优先还是选择ECDSA认证方式，不需要IAS（intel认证服务）注册，本地搭建认证服务，更为实用。
存在的问题
实验室机器原本安装的是EPID版本的sgx驱动，因此跑不通远程认证，现在正在重新安装DCAP和ECDSA的驱动，遇到一些安装问题。
下周工作计划
先解决sgx驱动安装问题，测试sgx的远程认证功能，再集成到fabric的框架中。
绘制新的多enclave框架图。
第四周 2021/12/20 – 2021/12/26
本周工作情况和进展
在上周的基础上，本周重新安装了sgx驱动和PCCS（Provisioning Certificate Caching Service）配置证书缓存服务。PCCS就相当于本地的认证服务，可以提供根证书、tcb等信息，如访问pccs服务获取tcb信息：
pccs就是一个在线服务器，如上图网址https://localhost:8081/sgx/certification/v3/，传入tcb获取信息，也可以获取根证书等。
运行sgx的远程认证案例成功：
sgx远程认证有两种，基于ECDSA（椭圆曲线）算法和EPID的。此处必须先更新电脑BIOS至最新版本，然后关闭BIOS中的Hyper-Threading，然后才可以运行成功。（红框圈出了的认证过程有时依然会失败，原因未知）
运行QuoteGeneration（生成证明）成功：
运行QuoteVerification（验证证明）有warning：
验证时产生warning，查阅得知a008错误：TCB level of the platform is up to date, but additional configuration of the platform at its current patching level may be needed. Moreover, SGX SW Hardening is also needed.
不知道这个TCB level过期是什么意思，找了很多解决办法都不行，网上也有说要在BIOS关闭Internal Graphic，在实验室电脑BIOS上未找到该设置。
运行ego的远程认证失败：
这个也是提示TCB level无效，应该是和上面同样的错误。
存在的问题
ego认证过程会报错TCB level失效，未找到解决方法。
下周工作计划
解决TCB level问题，尽可能运行ego的远程认证。