To date, only the lazy have not written about blockchain technology, cryptocurrencies, and how cool it is. But in this article there will be no praising of this technology, it will be just about its shortcomings and ways to eliminate them.

While working on one of the projects at Altirix Systems, the task arose of secure, censorship-resistant confirmation of data from a source external to the blockchain. It was necessary to confirm changes in the records of the third system and, based on these changes, execute one or another branch in the smart contract logic. At first glance, the task is quite trivial, but when the financial condition of one of the parties participating in the process depends on the result of its implementation, additional requirements appear. First of all, it is a comprehensive trust in such a validation mechanism. But first things first.

The problem is that the blockchain itself is an autonomous, closed entity, so smart contracts inside the blockchain know nothing about the outside world. At the same time, the terms of smart contracts are often associated with information about real things (flight delay, exchange rates, etc.). For smart contracts to work properly, information obtained from outside the blockchain must be reliable and verified. This problem is solved by using oracles such as Town Crier and DECO. These oracles allow a smart contract in the blockchain network to trust information from a trusted web server, we can say that these are reliable information providers.

Oracles

Imagine that a smart contract transfers 0.001 btc to your bitcoin wallet if your favorite football club wins the Russian Cup. In case of a real victory, the smart contract needs to transfer information about which club won, and here a number of problems arise: where to get this information, how to safely transfer it to the smart contract, and how to make sure that the information received in the smart contract on really matches reality?

In the issue with the source of information, there can be 2 scenarios: connecting a smart contract to a trusted website that centrally stores information about the results of matches, and the second option is to connect several sites at once and then choose information from most sources that provide the same data. To make sure the information is correct, oracles are used, such as Oraclize, which uses TLSNotary (TLS Modification to Prove Data Authenticity). But there is enough information about Oraclize in Google, and there are several articles on Habré, but today I will talk about oracles that use a slightly different approach to transmitting information: Town Crier and DECO. The article provides a description of the principles of operation of both oracles, as well as a detailed comparison.

Town Scream

Town Crier (TC) was introduced by IC3 (The Initiative for CryptoCurrencies and Contracts) in 2016 at CCS'16. The main idea behind TC is to pass the information from the website to the smart contract and make sure that the information delivered by the TC is the same as on the website. TC uses TEE (Trusted Execution Environment) to authenticate data ownership. The original version of TC describes how to work with Intel SGX.
Town Crier consists of a part inside the blockchain and a part inside the OS itself - TC Server.

The TC Contract is on the blockchain and acts as a front end for TC. It accepts requests from the CU (User Smart Contract) and returns a response from the TC Server. Inside the TC Server is a Relay that connects the enclave to the Internet (bidirectional traffic) and connects the enclave to the blockchain. Enclave contains progencl, which is code that makes requests from the blockchain and returns messages to the digitally signed blockchain, progencl contains part of the smart contract code and in fact performs some of its functions.

The Intel SGX enclave can be thought of as a shared library with an API running through ecall. Ecall transfers control to the enclave. The enclave executes its code until it terminates or until an exception occurs. To call functions defined outside the enclave, use ocall. Ocall runs outside the enclave and is treated as an untrusted call by the enclave. After ocall is executed, control returns to the enclave.

In the Enclave part, a secure channel is configured with the web server, the enclave itself performs a TLS handshake with the target server and performs all cryptographic operations within itself. The TLS library (mbedTLS) and a minified version of the HTTP code have been exported to the SGX environment. Also, the Enclave contains root CA certificates (collection of certificates) to check the certificates of remote servers. The Request Handler accepts a datagram request in the format provided by Ethereum, decrypts it, and parses it. It then generates an Ethereum transaction containing the requested datagram, signs it with skTC, and sends it to Relay.

The Relay part includes Client Interface, TCP, Blockchain Interface. The Client Interface is needed to validate the enclave code and communicate with the client. The client sends an attestation request using ecall and receives a timestamp signed by skTC along with att (the attestation signature), then att is validated using the Intel Attestation Service (IAS) and the timestamp is verified by a trusted time service. The Blockchain Interface validates incoming requests and places transactions on the blockchain to deliver datagrams. Geth is the official Ethereum client and allows Relay to interact with the blockchain via RPC calls.

Working with TEE, TC allows you to run several enclaves in parallel, thereby increasing the speed of information processing by 3 times. If with one working enclave the speed was 15 tx/sec, then with 20 parallel running enclaves 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. Ensures data confidentiality and integrity.
DECOs with TLS use symmetric encryption, so the client and the web server have encryption keys, and the client can spoof the TLS session data if it wants to. To solve this problem, DECO uses a three-way handshake protocol between the prover (smart contract), verifier (oracle) and web-server (data source).

The way DECO works is that the prover receives a piece of data D and confirms to the verifier that D came from the TLS server S. Another problem is that TLS does not sign the data and it is difficult for the TLS client to prove that the data was received from that server (provenance difficulty).

The DECO protocol uses the KEnc and KMac encryption keys. The client sends a Q request to the web server, the response from the R server is encrypted, but the client and server own the same KMac, and the client can forge the TLS message. DECO's solution is to "hide" the KMac from the client (prover) until it responds to the request. Now KMac is divided between prover and verifier - KpMac and KvMac. The server receives a KMac to encrypt the response using the KpMac ⊕ KvMac = KMac operation on the parts of the key.

By setting up a three-way handshake, the data exchange between the client and the server will be carried out with a guarantee of security.

Speaking of the decentralized oracle system, one cannot fail to mention Chainlink, which aims to create a decentralized network of oracle nodes compatible with Ethereum, Bitcoin and Hyperledger, with modularity in mind: every part of the system can be upgraded. At the same time, to ensure security, Chainlink offers each oracle participating in the task to issue a combination of keys (public and private). The private key is used to generate a partial signature that contains their decision to request data. To get the answer, it is necessary to combine all the partial signatures of the oracles of the network.

Chainlink is planning an initial PoC DECO focusing on decentralized finance applications like Mixicles. At the time of writing, there was news on Forbes that Chainlink had acquired DECO from Cornell University.

attacks on oracles

From an information security point of view, the following attacks on Town Crier have been considered:

1. Rogue smart-contact code injection on TEE nodes.
   The essence of the attack: sending a knowingly incorrect smart contract code to TEE, so that an attacker who has gained access to the node will be able to execute his own (fraudulent) smart contract on the decrypted data. However, the returned values ​​will be encrypted with the private key, and the only way to access such data is to leak the ciphertext on return/output.
   Protection against this attack consists in checking the correctness of the code located at the current address by the enclave. This can be achieved with an addressing scheme where the address of the contract is determined by hashing the contract code.

2. Contract state ciphertext changes leak.
   The essence of the attack: The owners of the nodes on which smart contracts are executed have access to the contract state in encrypted form outside the enclave. An attacker, having gained control of the node, can compare the contact state before and after the transaction and can determine which arguments were entered and which smart contract method was used, since the smart contract code itself and its technical specifications are publicly available.
   Protection in ensuring the reliability of the node itself.

3. Side channel attacks.
   A special type of attack that uses monitoring of enclave memory and cache access in various scenarios. An example of such an attack is Prime and Probe.
   
   Attack order:

   • t0: The attacker fills the entire data cache of the victim's process.
   • t1: The victim executes code with memory accesses that depend on the victim's sensitive data (cryptographic keys). The cache line is selected by the keybit value. In the example in the figure, keybit = 0 and read the address X in cache line 2. The data stored in X is loaded into the cache, displacing the data that was there before.
   • t2: The attacker checks which of his cache lines have been evicted - lines used by the victim. This is done by measuring the access time. By repeating this operation for each of the keybits, the attacker obtains the entire key.

Attack protection: Intel SGX has protection against side-channel attacks that disables monitoring of cache-related events, but a Prime and Probe attack will still pass, since the attacker observes the cache events of his process and shares the cache with the victim.

Thus, at the moment there is no reliable protection against this attack.

Specter and Foreshadow (L1TF) attacks similar to Prime and Probe are also known. They allow you to read data from the cache through a third-party channel. Protection against the Specter-v2 vulnerability is provided, which works against these two attacks.

In relation to DECO, the three-way handshake provides a security guarantee:

1. Prover Integrity: A compromised prover cannot forge server origin information and cannot cause the server to accept invalid requests or incorrectly respond to valid requests. This is done through request patterns between server and prover.
2. Verifier Integrity: A hacked verifier cannot cause the prover to get wrong answers.
3. Privacy: Hacked verifier only examines publicly available information (request, server name).

In DECO, only traffic injection vulnerabilities are possible. First, with a three-way handshake, the verifier can establish the server's identity with a fresh nonce. However, after the handshake, the verifier must rely on network layer indicators (IP addresses). Thus, communication between verifier and server must be protected from traffic injection. This is achieved by using a proxy.

Comparison of oracles

Town Crier is based on working with an enclave in the back-end, while DECO allows you to authenticate the origin of data using a three-way handshake and encrypt data with cryptographic keys. Comparison of these oracles was carried out according to the following criteria: speed, security, cost and practicality.

Town Scream
DECO

performance
Faster (0.6s to finish)
Slower (10.50s to finish the protocol)

safety
Less secure
More secure

cost
Expensive
Cheaper

practicality
Requires special hardware
Works with any server that supports TLS

PerformanceA: DECO requires 0.37-way handshake setup, takes 2 seconds when set up via LAN, 0,13PC-HMAC (3s per write) is effective for communication after connection is established. The performance of DECO depends on the available TLS cipher suites, the size of the private data, and the complexity of the proofs for a particular application. Using the binary option application from IC10,50 as an example: it takes about 0,6 seconds to complete the protocol via LAN. By comparison, Town Crier takes approximately 20 seconds to complete a similar application, which is about XNUMX times faster than DECO. Under equal conditions, TC will be faster.

Security: Attacks on the Intel SGX enclave (side-channel attacks) work and can cause real damage to smart contract participants. With regard to DECO, traffic injection attacks are possible, but the use of a proxy nullifies such attacks. Therefore DECO is more secure.

Price: The cost of hardware that supports working 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, special equipment that supports TEE is required. For example, Intel SGX is supported on 6th Gen Intel Core family processors and later. DECO allows you to work with any equipment, although there is a DECO setting using TEE. According to the setup process, DECO's XNUMX-way handshake may take some time, but this is nothing compared to the hardware limitation for TC, so DECO is more practical.

Conclusion

Looking at the two oracles separately and comparing them on four criteria, it is clear that Town Crier is inferior to DECO on three points out of four. DECO is more reliable in terms of information security, cheaper and more practical, although setting up a three-way protocol can take some time and has its drawbacks, such as additional operations with encryption keys. TC is faster than DECO, but a side-channel attack vulnerability makes it at risk of losing privacy. Keep in mind that DECO was introduced in January 2020, and not enough time has passed to consider it safe. Town Crier has been attacked for 4 years now and has gone through many tests, so its use in many projects is justified.

Source: habr.com