码迷,mamicode.com
首页 > 其他好文 > 详细

区块链应该拒绝硬件吗?

时间:2020-07-01 20:33:29      阅读:161      评论:0      收藏:0      [点我收藏+]

标签:新版   runtime   通过   架构   mda   包括   一加   known   提交   

  区块链应该拒绝硬件吗?

  或许你会觉得硬件与区块链风马牛不相及。毕竟,从比特币到以太坊,区块链都是软件为王,基于硬件的解决方案往往有中心化的嫌疑。其实,在隐私保护领域,引入硬件是常规操作。硬件是实现实用化的基础,软硬结合的方案可以实现一加一大于二的效果。通过巧妙组合,Phala 可以在让其去信任化的同时,让解决方案在可拓展性和保密性之间达到绝佳的平衡。

  1 、基于TEE的区块链保密

  Phala Network[1] 运用了保密智能合约来实现区块链保密。与传统合约不同的是,它运行在CPU内一个特殊的硬件区域(可信执行环境[2])内。这个区域与其他部件高度隔离;未经授权,包括恶意攻击在内的任何尝试都无法读取TEE中的数据,也无法干预其中程序的执行。

  Phala将运行在TEE中的程序称为 pRuntime。pRuntime 在 TEE 内维持矿工和 Gatekeeper 节点运行,并负责处理 TEE 远程证明、链上注册、密钥管理和保密合同执行。

  然而,如何让用户相信智能合约运行在 pRuntime 里,而不只是一个伪造的 TEE 环境?这个时候,我们需要了解什么是“远程认证”(Remote Attestation[3])。

  “An application that hosts an enclave can also ask the enclave to produce a report and then pass this report to a platform service to produce a type of credential that reflects enclave and platform state. This credential is known as a quote. This quote can then be passed to entities off of the platform, and verified…”

  “特殊安全区(enclave)里的应用程序也可以要求安全区生成报告,然后将该报告传递到平台服务以生成反映安全区和平台状态的凭证。这样的反馈凭证被称为“引报”(quote)。之后,Quote 就可以作为信任源向外界验证安全区内应用的可信性……”

  远程认证是确保 TEE 系统处于安全和可信状态的关键。来自英特尔的 Quate 可以证明这段代码(以哈希值确定)和需要用到的某些数据都确确实实运行在最新版本的 SGX 安全区内。

  2、 Secret Provisioning

  远程认证是保密智能合约的灵魂。但如果我们无法在 TEE 和第三方之间建立端到端加密的通信,应用范围就会受到限制。所以,英特尔 SGX 还运用了 Secret Provisioning[4] 协议来优雅地解决这个问题。

  借助 Secret Provisioning 协议,我们可以建立从用户到 pRuntime 的信任链:

  区块链上公示了合法pRuntime代码的哈希;

  pRuntime运行远程证明协议,获取远程认证报告,报告中含有:被证明代码的哈希值(pRuntime本身);身份认证密钥对的公钥(有时效性)

  远程验证报告在链上提交,并在链上进行验证;

  区块链比较远程报告返回的哈希值(旨在证明:参与方确实是TEE中运行的合法pRuntime)

  身份认证公钥完成链上注册(以后只有目前正在运行的pRuntime可以使用此密钥对)

  注册完成后,但凡是由这个身份签名的消息,都一定是由此 pRuntime 生成的。用户可以使用已注册的身份公钥进一步和 pRuntime 建立类似 TLS 的连接。

  需要与 TEE 进行通信时,用户可以从区块链获取已注册的 pRuntime 的公钥,并用 Substrate 账户和公钥进行ECDH迪菲赫尔曼协议[5]密钥协商,并获得用于和 pRuntime 进行通信的密钥。

  信任链建立后,该身份密钥将唯一地表示 pRuntime 的身份。理论上,只要 TEE 没有硬件漏洞(在后文我们会继续讨论这个问题),则一次成功的远程认证就可以确保所有与 pRuntime 往来的通信处于安全和可信的状态。

  3、 链上升级

  链上升级可以极大地降低硬件升级硬分叉带来的风险,所以非常重要。Substrate 天生支持 Runtime 链上升级,在治理[6]模块即可完成。同理, TEE 里的 Runtime 也是可以升级的。

  升级 pRuntime 时,需要将新的哈希提交到区块链上。之后便可由社区通过类似于 Substrate 的链上治理流程来审查代码、讨论并投票赞成升级。

  链上一旦有升级,Phala 的守门人(Gatekeeper)[7]和矿工都必须第一时间升级 pRuntime。这个过程对矿工来说会相对容易一些,因为他们不用 24 小时在线,只用暂停挖矿,升级,然后继续挖矿即可。守门人由于肩负可用性重任,需尽可能在线,因此他们要么运行另一个新版本的 TEE 客户端等待下一次选举期间的自然切换,要么对状态数据进行紧急加密转储,然后将其恢复到新的pRuntime。

  虽然后者有状态数据丢失或暴露的风险,但在紧急情况下也不失为一种选择。SGX 有一个“密封至安全区(Seal to Enclave)[8]”功能,可以生成只能由同一安全区解码的密钥。这个密钥可以确保数据不被任何第三方查看或迁移。为了降低硬件安全漏洞被利用的可能性,Gatekeeper 中的密钥是通过 Shamir 密钥共享方案分发的。即使 sealing 崩坏,如果没有网络中的多方合谋,主机也无法获取密钥。

  4、 攻与守

  Phala 的威胁模型首先假设 TEE 厂商是部分可信的。原因有二:一,TEE 厂商在制造芯片的时候并不知道这些芯片会被用在什么地方;二,即便遭受“零日漏洞攻击(Zero-day Attack)”,其他所有运行在芯片上的程序都会有风险,而不单单是 TEE 承受风险。

  虽然秉持上述假设,不可否认的是,硬件漏洞攻击仍然时有发生。好在,有以下几种方法可以解决或处理硬件风险问题。

  首先,硬件漏洞是可以修复的。一个常见的误区是,只有软件漏洞可以修复,而硬件漏洞不能修复。事实并非如此,我们可以通过微码[9]来修复硬件漏洞。英特尔为SGX设计了一种特殊的架构,大多数漏洞都可以被及时修复。比如,最近新出现的一种名为 SGAxe[10] 的攻击就已经通过微码升级和密钥组轮换被修复。密钥经过转置和撤回后,所有非最新版 SGX 设备的请求都将被远程认证驳回。

  其次,随机性是一柄利器。有人会问,零日漏洞攻击怎么应对?——矿工拥有硬件访问权限,就可能会利用零日漏洞攻击盗取数据,有作恶的可能。针对这种情况,我们可以活用“随机性”,让区块链把保密智能合约在一个时间段随机分配给不同的矿工,这样,每个时间段的矿工都不同,攻击者必须在不同时间段持续控制大多数矿工的 TEE 设备才能成功,作恶成本会非常高。

  最后,保密合约可以通过副本保证执行的正确性。即使在极端情况下,安全区完全被攻陷、机密数据完全暴露在攻击者面前、TEE 内程序可以被任意改写,合约的“正确性”(correctness)仍然可以得到保证。在 Phala 的设计中,保密合约可以有一个或多个副本并行运行。副本不会影响合约的执行,因为所有输入都来自区块链。并行状态下,会有多个 TEE 同时尝试向链上提交状态数据。此时就会有一个简单的链上投票过程,状态数据的“最终确认”(finalize)将遵循少数服从多数的原则。

  副本的设计让这个过程变成了类似 Polkadot Validator[11] 选举的过程。要想攻击“正确性”,攻击者必须控制绝大多数 TEE 矿工。——这还是在完全被攻破的极端情况下。

  5、 结论

  过去,区块链仅限于软件范畴。发展至今,完全公开性已成为其大范围落地的桎梏。而有了可信硬件和精心设计的协议支持,Phala将证明和构建出一个可信、可保密、可大范围落地的区块链世界。

区块链应该拒绝硬件吗?

标签:新版   runtime   通过   架构   mda   包括   一加   known   提交   

原文地址:https://www.cnblogs.com/yyuyu/p/13220973.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!