Today, only the lazy have not written about blockchain technology, cryptocurrencies, and how great it is. However, this article will not praise this technology; instead, it will address its drawbacks and ways to mitigate them.
While working on one of the projects at Altirix Systems, the task arose for secure, censorship-resistant confirmation of data from an external source to the blockchain. It was necessary to confirm changes in the records of a third-party system and, based on these changes, execute a specific branch in the logic of the smart contract. The task seems straightforward at first glance, but when the financial condition of one of the participating parties depends on the outcome, additional requirements emerge. First and foremost is the need for comprehensive trust in such a validation mechanism. But let's address everything in order.
The problem lies in the fact that blockchain itself is an autonomous, closed object; therefore, smart contracts within the blockchain know nothing about the external world. At the same time, the conditions of smart contracts are often tied to information about real-world events (e.g., flight delays, exchange rates, etc.). For smart contracts to function correctly, the information obtained from outside the blockchain must be reliable and verified. This issue is addressed through the use of oracles, such as Town Crier and DECO. These oracles allow a smart contract in the blockchain network to trust information from a verified web server, so they can be considered reliable information providers.
Oracles
Imagine a smart contract executing a transfer of 0.001 btc to your bitcoin wallet if your favorite football club wins the Russian Cup. In the event of an actual victory, the smart contract needs to be provided with information on which club won, and several problems arise here: where to obtain this information, how to safely transmit it to the smart contract, and how to ensure that the information received by the smart contract matches reality?
There can be two scenarios regarding the source of information: connecting a smart contract to a trusted website that centrally stores match results, or connecting to multiple websites and then selecting information from the majority that provide the same data. To verify the accuracy of the information, oracles are used, such as Oraclize, which employs TLSNotary (a modification of TLS for data authenticity proof). However, there is enough information about Oraclize on Google, and several articles on Habr, so today I will discuss oracles that use a slightly different approach to information transfer: Town Crier and DECO. This article outlines the operational principles of both oracles and provides a detailed comparison.
Town Crier
Town Crier (TC) was introduced by IC3 (The Initiative for CryptoCurrencies and Contracts) in 2016 at CCS’16. The main idea of TC is to transmit information from a website to the smart contract and ensure that the information delivered by TC matches that on the website. TC employs TEE (Trusted Execution Environment) for data ownership authenticity. In the original version, TC describes its operation with Intel SGX.
Town Crier consists of a part within the blockchain and a part within the operating system itself — the TC Server.
The TC Contract resides in the blockchain and acts as the front end for TC. It accepts requests from the CU (user smart contract) and returns responses from the TC Server. Inside the TC Server, there is a Relay that establishes a connection between the enclave and the internet (bidirectional traffic) and links the enclave to the blockchain. The enclave contains progencl, which is the code that executes requests from the blockchain and returns messages to the blockchain with a digital signature; progencl contains part of the smart contract code and essentially performs some of its functions.
The Intel SGX enclave can be regarded as a common library with an API, operating through ecall. Ecall transfers control to the enclave. The enclave executes its code until completion or an exception occurs. To invoke functions defined outside the enclave, ocall is used. Ocall is executed outside the enclave and is handled by it as an untrusted call. After the ocall execution, control returns to the enclave.
In the Enclave part, a secure channel is set up with the web server, the enclave itself performs the TLS handshake with the target server, and carries out all cryptographic operations internally. The TLS library (mbedTLS) and HTTP code in a reduced form are exported to the SGX environment. Additionally, the Enclave contains root CA certificates (a collection of certificates) to verify the certificates of remote servers. The Request Handler accepts a datagram request in the format provided by Ethereum, decrypts it, and analyzes it. Then it generates an Ethereum transaction containing the requested datagram, signs it using skTC, and sends it to the Relay.
The Relay part includes the Client Interface, TCP, and Blockchain Interface. The Client Interface is needed for attesting the enclave code and communicating with the client. The client sends an attestation request using ecall and receives a timestamp signed by skTC along with the att (attestation signature), which is then confirmed using the Intel Attestation Service (IAS), and the timestamp is verified by a trusted time service. The Blockchain Interface checks incoming requests and places transactions in the blockchain for delivering datagrams. Geth is the official Ethereum client and allows the Relay to interact with the blockchain through RPC calls.
Working with TEE, TC allows multiple enclaves to be launched simultaneously, increasing information processing speed threefold. If with one running enclave the speed was 15 tx/sec, then with 20 enclaves running in parallel, the speed increases to 65 tx/sec; for comparison, the maximum speed in the Bitcoin blockchain is 26 tx/sec.
DECO
DECO (Decentralized Oracles for TLS) was introduced at CCS'20 and works with sites that support TLS connections. It ensures data confidentiality and integrity.
DECO with TLS uses symmetric encryption, so both the client and web server have encryption keys, and the client can, if desired, spoof the TLS session data. To solve this problem, DECO employs a three-party handshake protocol between the prover (smart contract), verifier (oracle), and web-server (data source).
The principle of DECO's operation is for the prover to obtain part of the data D and confirm to the verifier that D came from the TLS server S. Another issue is that TLS does not sign the data, making it difficult for the TLS client to prove that the data was indeed received from that server (provenance difficulty).
The DECO protocol uses the encryption keys KEnc and KMac. The client sends a request Q to web server, and the server's response R arrives in encrypted form, but both the client and server possess the same KMac, allowing the client to forge a TLS message. DECO's solution is to 'hide' KMac from the client (prover) until it responds to the request. Now KMac is split between the prover and verifier — KpMac and KvMac. The server obtains KMac for encrypting the response using the key parts operation KpMac ⊕ KvMac = KMac.
By setting up a three-way handshake, the data exchange between the client and server will proceed with security guarantees.
When discussing decentralized oracle systems, one cannot overlook Chainlink, which aims to create a decentralized network of oracle nodes compatible with Ethereum, Bitcoin, and Hyperledger, considering modularity: each part of the system can be updated. For security, Chainlink provides each oracle participating in a task with a key combination (public and private). The private key is used to generate a partial signature that contains their solution to the data request. To obtain a response, all partial signatures from the network's oracles must be combined.
Chainlink plans to conduct the initial PoC DECO focused on decentralized financial applications, such as Mixicles. At the time of writing, news broke on Forbes that Chainlink acquired DECO from Cornell University.
Attacks on Oracles
From an information security standpoint, the following attacks on Town Crier have been considered:
Rogue smart contract code injection on TEE nodes.
The essence of the attack is the transmission of deliberately false smart contract code to the TEE, allowing an attacker who has accessed the node to execute their own (fraudulent) smart contract on decrypted data. Nevertheless, the returned values will be encrypted with a private key, and the only way to access such data lies in the leakage of the ciphertext during return/output.
Protection against this attack involves the enclave verifying the correctness of the code located at the current address. This can be achieved using an addressing scheme where the contract's address is defined by hashing the contract code.Contract state ciphertext changes leak.
The essence of the attack: Owners of nodes running smart contracts have access to the contract state in an encrypted form outside of the enclave. An attacker who gains control of a node can compare the contract state before and after executing a transaction and determine which arguments were submitted and which specific method of the smart contract was used, as the smart contract code and its technical specifications are publicly available.
Protection in ensuring the reliability of the node itself.Side-channel attacks.
A special type of attack that uses monitoring access to the memory and cache of the enclave in various scenarios. An example of such an attack is Prime and Probe.
Procedure for carrying out the attack:- t0: The attacker fills the entire data cache of the victim's process.
- t1: The victim executes code with memory accesses that depend on confidential data (cryptographic keys). The selection of the cache line occurs based on the value of keybit. In the example in the diagram, keybit = 0 and address X has been read in cache line 2. The data stored in X is loaded into the cache, evicting the data that was there before.
- t2: The attacker checks which of their cache lines were evicted — the lines used by the victim. This is done by measuring access time. By repeating this operation for each keybit, the attacker obtains the entire key.
Protection against the attack: Intel SGX has protection against side-channel attacks that prohibits monitoring events related to the cache, but the Prime and Probe attack will still succeed, as the attacker observes cache events of their process and shares the cache with the victim.
Thus, at this moment, there is no reliable protection against this attack.
There are also known attacks such as Spectre and Foreshadow (L1TF), similar to Prime and Probe. They allow reading data from cache memory through a side channel. A defense against the Spectre-v2 vulnerability is provided, which works against both of these attacks.
Regarding DECO, the three-party handshake provides a security guarantee:
- Prover Integrity: a compromised prover cannot forge information about the origin of the server and cannot cause the server to accept invalid requests or respond incorrectly to valid requests. This is achievable through request patterns between the server and prover.
- Verifier Integrity: a compromised verifier cannot cause the prover to receive incorrect responses.
- Privacy: The hacked verifier only examines publicly available information (request, server name).
In DECO, only vulnerabilities related to traffic injection are possible. Initially, during the three-way handshake, the verifier can establish the server's identity using a fresh nonce. However, after the handshake, the verifier must rely on network-level indicators (an IP address). Therefore, the connection between the verifier and the server must be protected against traffic injection. This is achieved through the use of a Proxy.
Comparison of Oracles
Town Crier is based on working with an enclave on the server side, whereas DECO allows for authenticity verification of data origin through a three-way handshake and encryption of data with cryptographic keys. The comparison of oracle data was conducted based on the following criteria: performance, security, cost, and practicality.
Town Crier
DECO
performance
Faster (0.6s to finish)
Slower (10.50s to finish the protocol)
security
Less secure
More secure
cost
More expensive
Cheaper
practicality
Requires special hardware
Works with any server that supports TLS
Performance: Configuring the three-way handshake for DECO takes 0.37 seconds when set up over LAN; it is efficient for interaction after establishing a connection with 2PC-HMAC (0.13s for writing). The performance of DECO depends on the available TLS cipher suites, the size of personal data, and the complexity of proofs for a specific application. For example, in the binary options application from IC3: completing the protocol over LAN takes about 10.50s. In comparison, Town Crier takes about 0.6 seconds to perform a similar application, which is approximately 20 times faster than DECO. Under equal conditions, TC will be faster.
Security: Attacks on the Intel SGX enclave (side-channel attacks) are feasible and can cause real harm to smart contract participants. Regarding DECO, attacks related to traffic injection are possible, but the use of proxy mitigates such attacks. Therefore, DECO is more secure.
Cost: The cost of hardware that supports operation with Intel SGX is higher than the cost of configuring the protocol in DECO. Therefore, TC is more expensive.
Practicality: To work with Town Crier, specialized hardware that supports TEE is essential. For instance, Intel SGX is supported on Intel Core processors from the 6th generation and newer. DECO, on the other hand, can operate with any hardware, although there is a DECO setup using TEE. The three-way handshake process in DECO may take some time, but this pales in comparison to the hardware constraints for TC, making DECO more practical.
Conclusion
When examining the two oracles separately and comparing them across four criteria, it becomes clear that Town Crier falls short of DECO in three out of four points. DECO is more reliable in terms of information security, less expensive, and more practical, although setting up the three-way protocol may take some time and has its downsides, such as additional operations with encryption keys. TC operates faster than DECO, but the vulnerability related to side-channel attacks puts it at risk of privacy loss. It's important to note that DECO was introduced in January 2020, and there hasn't been enough time to consider it completely secure. Town Crier has been under attack for four years and has undergone numerous checks, making its application in many projects justifiable.
Source: habr.com
