如今，只有懒人没有写过有关区块链技术、加密货币及其有多酷的文章。 但本文不会赞扬这项技术；我们将讨论它的缺点以及消除它们的方法。
在 Altirix Systems 从事其中一个项目时，出现了对来自区块链外部来源的数据进行安全、抗审查确认的任务。 需要确认第三系统记录的变化，并根据这些变化执行智能合约逻辑中的一个或另一个分支。 乍一看，这项任务相当微不足道，但当参与该过程的一方的财务状况取决于其实施结果时，就会出现额外的要求。 首先，这是对这样一个验证机制的全面信任。 但首先要说的是。
问题在于区块链本身是一个自治的、封闭的实体，因此区块链内部的智能合约对外界一无所知。 同时，智能合约的条款往往与真实事物的信息（航班延误、汇率等）相关。 为了使智能合约正常工作，从区块链外部接收的信息必须可靠且经过验证。 这个问题通过使用Town Crier、DECO等预言机解决。 这些预言机允许区块链网络上的智能合约信任来自可信网络服务器的信息；我们可以说它们是可靠信息的提供者。
神谕者
想象一下，如果您最喜欢的足球俱乐部赢得了俄罗斯杯，那么智能合约会将 0.001 比特币转移到您的比特币钱包中。 如果真正获胜，智能合约需要传输哪支球队获胜的信息，这就产生了一系列问题：从哪里获取这些信息、如何安全地传输到智能合约以及如何确保这些信息智能合约中收到的有效信息是否与现实相符？
当涉及到信息来源时，可以有两种情况：将智能合约连接到集中存储比赛结果信息的可信网站，第二种选择是一次连接多个站点，然后从大多数来源中选择信息提供相同的数据。 为了验证信息的正确性，需要使用预言机，例如Oraclize，它使用TLSNotary（TLS Notary Modification to Prove the Authenticity of Data）。 不过 Google 上关于 Oraclize 的信息已经足够多了，而且还有几篇关于 Habré 的文章。今天我要讲的是使用稍微不同的方式来传输信息的 oracle：Town Crier 和 DECO。 文章描述了两种预言机的运行原理，并进行了详细的比较。
城镇危机
Town Crier (TC) 由 IC3（加密货币和合约倡议组织）于 2016 年 CCS'16 上推出。 TC的主要思想：将信息从网站传输到智能合约，并确保TC传递的信息与网站上的信息相同。 TC使用TEE（可信执行环境）来验证数据所有权。 TC 的原始版本描述了如何与 Intel SGX 一起工作。
Town Crier 由区块链内部的部分和操作系统本身内部的部分（TC 服务器）组成。
TC合约位于区块链上，作为TC的前端。 它接受来自 CU（用户智能合约）的请求并返回来自 TC Server 的响应。 TC Server 内部有一个 Relay，它在 enclave 和互联网之间建立连接（双向流量），并将 enclave 与区块链连接起来。 Enclave 包含 progencl，这是从区块链发出请求并使用数字签名将消息返回到区块链的代码，progencl 包含部分智能合约代码并本质上执行其一些功能。
Intel SGX enclave 可以被认为是一个共享库，其 API 通过 ecall 运行。 Ecall 将控制权转移到飞地。 飞地执行其代码，直到退出或发生异常。 ocall 用于调用 enclave 外部定义的函数。 Ocall 在 enclave 外部执行，并被 enclave 视为不可信调用。 执行 ocall 后，控制权返回到 enclave。
在Enclave部分，通过Web服务器配置安全通道，Enclave本身与目标服务器执行TLS握手并在内部执行所有加密操作。 TLS 库 (mbedTLS) 和简化的 HTTP 代码已导出到 SGX 环境。 此外，Enclave 还包含根 CA 证书（证书的集合）来验证远程服务器的证书。 请求处理程序接受以太坊提供的格式的数据报请求，对其进行解密并解析。 然后它生成一个包含所请求数据报的以太坊交易，用 skTC 对其进行签名并将其传输到 Relay。
中继部分包括客户端接口、TCP、区块链接口。 需要客户端接口来验证 enclave 代码并与客户端进行通信。 客户端使用 ecall 发送证明请求，并接收 skTC 签名的时间戳以及 att（证明签名），然后使用 Intel Attestation Service (IAS) 验证 att，并由可信时间服务验证时间戳。 区块链接口验证传入的请求并将交易放置在区块链上以传输数据报。 Geth 是官方的以太坊客户端，允许 Relay 通过 RPC 调用与区块链进行交互。
TC与TEE配合使用，可以并行运行多个enclave，从而将信息处理速度提高3倍。 如果一个运行的 enclave 的速度为 15 tx/秒，那么如果有 20 个并行运行的 enclave，速度会增加到 65 tx/秒；作为比较，比特币区块链中的最大运行速度为 26 tx/秒。
DECO
DECO（TLS 的去中心化预言机）在 CCS'20 上亮相，与支持 TLS 连接的站点合作。 确保数据的机密性和完整性。
DECO with TLS 使用对称加密，因此客户端和 Web 服务器都有加密密钥，并且客户端可以根据需要伪造 TLS 会话数据。 为了解决这个问题，DECO 在证明者（智能合约）、验证者（预言机）和网络服务器（数据源）之间使用三向握手协议。
DECO 的工作方式是，验证者收到一条数据 D，并向验证者确认 D 来自 TLS 服务器 S。另一个问题是 TLS 不会对数据进行签名，TLS 客户端很难证明该数据是来自 TLS 服务器 S。数据是从正确的服务器接收的（来源困难）。
DECO 协议使用 KEnc 和 KMac 加密密钥。 客户端向 Web 服务器发送请求 Q，服务器 R 的响应以加密形式出现，但客户端和服务器拥有相同的 KMac，客户端可以伪造 TLS 消息。 DECO 的解决方案是对客户端（证明者）“隐藏”KMac，直到它响应请求。 现在KMac分为证明者和验证者——KpMac和KvMac。 服务器接收 KMac 并使用密钥部分运算 KpMac ⊕ KvMac = KMac 加密响应。
通过建立三次握手，客户端和服务器之间的数据交换将在安全的情况下进行。
说到去中心化的预言机系统，就不能不提到Chainlink，它的目标是创建一个兼容以太坊、比特币和超级账本的去中心化的预言机节点网络，并考虑到模块化：系统的每个部分都可以更新。 同时，为了保证安全性，Chainlink 为参与任务的每个预言机提供了密钥组合（公钥和私钥）。 私钥用于生成部分签名，其中包含他们对数据请求的决定。 为了获得答案，有必要结合网络预言机的所有部分签名。
Chainlink 计划进行初始 PoC DECO，重点关注 Mixicles 等去中心化金融应用。 截至撰写本文时，《福布斯》上有消息称 Chainlink 收购了康奈尔大学的 DECO。
对神谕的攻击
从信息安全的角度来看，考虑了对 Town Crier 的以下攻击：
-
TEE 节点上的恶意智能接触代码注入。
攻击的本质是：将故意不正确的智能合约代码传输到TEE，因此，获得节点访问权限的攻击者将能够在解密的数据上执行自己的（欺诈性）智能合约。 然而，返回值将使用私钥加密，访问此类数据的唯一方法是在返回/输出时泄露密文。
针对这种攻击的防护包括飞地检查当前地址处代码的正确性。 这可以使用寻址方案来实现，其中合约地址是通过散列合约代码来确定的。 -
合约状态密文变化泄露。
攻击的本质是：执行智能合约的节点的所有者可以以加密形式访问 enclave 之外的合约状态。 攻击者在获得节点控制权后，可以比较交易前后的联系状态，并确定输入了哪些参数以及使用了哪种智能合约方法，因为智能合约代码本身及其技术规范是公开的。
保护以保证节点本身的可靠性。 -
旁路攻击。
一种特殊类型的攻击，在各种场景中使用监控 enclave 内存和缓存访问。 此类攻击的一个例子是 Prime 和 Probe。
攻击顺序：- t0：攻击者填满受害者进程的整个数据缓存。
- t1：受害者通过依赖于受害者的敏感数据（加密密钥）的内存访问来执行代码。 缓存行是根据密钥位值选择的。 在图中的例子中，keybit = 0，读取缓存线2中的地址X，X中存储的数据被加载到缓存中，替换之前的数据。
- t2：攻击者检查哪些缓存行已被逐出——受害者使用的行。 这是通过测量访问时间来完成的。 通过对每个密钥位重复此操作，攻击者可以获得整个密钥。
攻击保护：英特尔 SGX 具有针对侧通道攻击的保护功能，可防止监控与缓存相关的事件，但 Prime 和 Probe 攻击仍然有效，因为攻击者监控其进程的缓存事件并与受害者共享缓存。
因此，目前没有针对这种攻击的可靠保护。
与 Prime 和 Probe 类似的 Spectre 和 Foreshadow (L1TF) 等攻击也是已知的。 它们允许您通过第三方通道从缓存中读取数据。 提供针对 Spectre-v2 漏洞的防护，可抵御其中两种攻击。
对于DECO来说，三向握手提供了安全保证：
- 证明者完整性：被黑客攻击的证明者无法伪造服务器源信息，也无法导致服务器接受无效请求或错误地响应有效请求。 这是通过服务器和证明者之间的请求模式来完成的。
- 验证者完整性：被黑的验证者不会导致证明者收到错误的答案。
- 隐私：被黑客攻击的验证程序仅检查公共信息（请求、服务器名称）。
在 DECO 中，只有流量注入漏洞是可能的。 首先，通过三向握手，验证者可以使用新的随机数来确定服务器的身份。 然而，握手之后，验证者必须依赖网络层指标（IP地址）。 因此，必须保护验证者和服务器之间的通信免受流量注入。 这是通过使用Proxy来实现的。
预言机比较
Town Crier 基于服务器部分中的 enclave 工作，而 DECO 允许您使用三向握手和使用加密密钥进行数据加密来验证数据来源的真实性。 这些预言机的比较是根据以下标准进行的：性能、安全性、成本和实用性。
城镇危机
DECO
表现
更快（0.6秒完成）
较慢（10.50 秒完成协议）
安全
安全性较低
更安全
成本
更贵
便宜一点
实用性
需要特殊硬件
适用于任何支持 TLS 的服务器
速度表现：与DECO配合使用，需要三次握手，通过LAN建立时需要0.37秒，建立连接后交互，2PC-HMAC有效（每次写入0,13秒）。 DECO 的性能取决于可用的 TLS 密码套件、私有数据的大小以及特定应用程序证据的复杂性。 以IC3的二元期权应用为例：通过LAN完成协议大约需要10,50秒。 相比之下，Town Crier 大约需要 0,6 秒才能完成类似的应用程序，比 DECO 快大约 20 倍。 在所有条件相同的情况下，TC 会更快。
安全：对 Intel SGX enclave 的攻击（旁道攻击）有效，并且可能对智能合约的参与者造成真正的损害。 对于DECO，与流量注入相关的攻击是可能的，但是代理的使用可以将此类攻击消除。 因此DECO更安全。
成本：支持Intel SGX的设备成本高于在DECO中设置协议的成本。 这就是为什么TC更贵的原因。
实际性：要与 Town Crier 合作，需要支持 TEE 的特殊设备。 例如，第六代英特尔酷睿处理器系列及更高版本支持英特尔 SGX。 DECO 允许您使用任何设备，尽管有使用 TEE 的 DECO 设置。 根据设置过程来看，DECO的三次握手可能需要一些时间，但这与TC的硬件限制相比并不算什么，所以DECO更加实用。
结论
分别查看两个神谕并根据四个标准进行比较，很明显 Town Crier 在四分之三上不如 DECO。 从信息安全的角度来看，DECO 更可靠、更便宜、更实用，尽管建立三方协议可能需要一些时间，并且有其缺点，例如需要使用加密密钥进行额外操作。 TC 比 DECO 更快，但侧信道攻击漏洞使其容易丢失机密性。 必须考虑到，DECO 是在 2020 年 4 月推出的，而且还没有足够的时间来考虑它的安全性。 Town Crier已经遭受了XNUMX年的攻击，并且经过了多次测试，因此它在许多项目中的使用是合理的。
来源： habr.com