Tegenwoordig heeft vrijwel iedereen wel iets geschreven over blockchaintechnologie, cryptocurrencies en hoe geweldig dit allemaal is. Maar in dit artikel zullen we niet de lof van deze technologie bezingen; we zullen ons richten op de tekortkomingen ervan en manieren om deze te verhelpen.

Tijdens het werken aan een van de projecten bij Altirix Systems ontstond de behoefte aan een veilige, censuurbestendige bevestiging van gegevens uit een externe bron voor blockchain. Er moest bevestigd worden dat er wijzigingen waren in de records van een derde systeem, en op basis van deze wijzigingen moest een bepaalde tak in de logica van het smart contract worden uitgevoerd. Op het eerste gezicht lijkt deze taak vrij trivial, maar wanneer het financiƫle resultaat van de uitvoering ervan afhankelijk is van een van de partijen in het proces, ontstaan er extra vereisten. In de eerste plaats is er de noodzaak voor alomvattend vertrouwen in zo'n validatiemechanisme. Maar laten we alles stap voor stap bekijken.
Het probleem is dat blockchain op zichzelf een autonoom, gesloten object is, waardoor smart contracts binnen de blockchain niets weten over de externe wereld. Tegelijkertijd zijn de voorwaarden van smart contracts vaak gerelateerd aan informatie over reƫle gebeurtenissen (vertraging van een vlucht, wisselkoers, enz.). Voor een correcte werking van smart contracts moet de informatie die van buiten de blockchain komt betrouwbaar en geverifieerd zijn. Dit probleem wordt opgelost door het gebruik van orakels, zoals Town Crier en DECO. Deze orakels stellen het smart contract in de blockchain in staat informatie van een betrouwbare webserver te vertrouwen; men kan zeggen dat het betrouwbare informatieleveranciers zijn.
Orakels
Stel je voor dat een smart contract 0,001 btc naar je bitcoin-portemonnee overmaakt in het geval je favoriete voetbalclub de Russische beker wint. In het geval van een daadwerkelijke overwinning moet het smart contract informatie ontvangen over welke club heeft gewonnen, en hier ontstaan een aantal problemen: waar haal je deze informatie vandaan, hoe kan deze veilig aan het smart contract worden verzonden en hoe zorg je ervoor dat de informatie die in het smart contract terechtkomt daadwerkelijk overeenkomt met de werkelijkheid?
Bij het verzamelen van informatie kunnen zich twee scenario's voordoen: de verbinding van een slimme contract met een vertrouwde website waar centrale informatie over wedstrijdresultaten wordt opgeslagen, en de tweede optie is om meerdere websites tegelijkertijd te koppelen en vervolgens de informatie te selecteren uit de meeste bronnen die dezelfde gegevens verstrekken. Om te waarborgen dat de informatie juist is, worden orakels gebruikt, bijvoorbeeld Oraclize, dat TLSNotary gebruikt (een modificatie van TLS voor de authenticiteit van gegevens). Maar er is al voldoende informatie over Oraclize te vinden op Google en er zijn verschillende artikelen op Habrahabr; vandaag zal ik het echter hebben over orakels die een iets andere benadering van informatieoverdracht gebruiken: Town Crier en DECO. In het artikel wordt de werkwijze van beide orakels beschreven, evenals een gedetailleerde vergelijking.
Town Crier
Town Crier (TC) werd in 2016 geĆÆntroduceerd door IC3 (The Initiative for CryptoCurrencies and Contracts) op CCS'16. De belangrijkste gedachte achter TC: informatie van een website naar een slim contract overbrengen en ervoor zorgen dat de door TC geleverde informatie dezelfde is als op de website. TC maakt gebruik van TEE (Trusted Execution Environment) voor de authenticiteit van gegevensbezit. In de originele beschrijving van TC wordt de werking met Intel SGX beschreven.
Town Crier bestaat uit een onderdeel binnen de blockchain en een onderdeel binnen het besturingssysteem zelf - TC Server.

Het TC Contract bevindt zich in de blockchain en dient als front-end voor TC. Het ontvangt verzoeken van CU (gebruikers slim contract) en retourneert antwoorden van TC Server. Binnen TC Server bevindt zich een Relay die de verbinding tussen de enclave en het internet (bidirectionele netwerkverkeer) tot stand brengt en de enclave verbindt met de blockchain. De enclave bevat progencl, dat is de code die verzoeken uit de blockchain verwerkt en berichten met digitale handtekening terugstuurt naar de blockchain; progencl bevat een deel van de code van het slimme contract en voert in feite sommige van zijn functies uit.
De Intel SGX-enclave kan worden gezien als een algemene bibliotheek met API, die werkt via ecall. Ecall geeft de controle over aan de enclave. De enclave voert zijn code uit totdat deze is voltooid of totdat er een uitzondering optreedt. Voor het aanroepen van functies die buiten de enclave zijn gedefinieerd, worden ocall gebruikt. Ocall wordt buiten de enclave uitgevoerd en wordt behandeld als een onbetrouwbare oproep. Na uitvoering van de ocall keert de controle terug naar de enclave.

In de Enclave wordt een beveiligd kanaal met de webserver ingesteld, de enclave voert zelf de TLS-handshake uit met de doelserver en voert alle cryptografische operaties intern uit. De TLS-bibliotheek (mbedTLS) en HTTP-code zijn in een vereenvoudigde variant geƫxporteerd naar de SGX-omgeving. Daarnaast bevat de Enclave root CA-certificaten (een verzameling certificaten) om de certificaten van externe servers te controleren. De Request Handler ontvangt een datagram-verzoek in het formaat dat door Ethereum wordt geleverd, decodeert het en analyseert het. Vervolgens genereert het een Ethereum-transactie met daarin het gevraagde datagram, ondertekent het deze met behulp van skTC en verzendt het naar de Relay.
Het Relay-gedeelte omvat de Client Interface, TCP, Blockchain Interface. De Client Interface is nodig voor de attestatie van de enclavecode en de communicatie met de klant. De klant stuurt een attestatieverzoek met behulp van ecall en ontvangt een timestamp, ondertekend met skTC samen met att (de attestatiesignatuur), vervolgens wordt att bevestigd met behulp van de Intel Attestation Service (IAS) en de timestamp wordt gecontroleerd door een vertrouwde tijdservice. De Blockchain Interface controleert binnenkomende verzoeken en plaatst transacties in de blockchain voor de levering van datagrams. Geth is de officiƫle Ethereum-client en stelt Relay in staat om via RPC-aanroepen met de blockchain te communiceren.
Bij het werken met TEE stelt TC in staat om meerdere enclaves gelijktijdig uit te voeren, waardoor de verwerkingssnelheid met een factor drie toeneemt. Als de snelheid bij ƩƩn actieve enclave 15 tx/sec was, dan groeit deze bij 20 gelijktijdige enclaves tot 65 tx/sec; ter vergelijking, de maximale snelheid van de Bitcoin-blockchain is 26 tx/sec.
DECO
DECO (Decentralized Oracles for TLS) werd gepresenteerd op CCS'20 en werkt met websites die TLS-verbindingen ondersteunen. Het waarborgt de vertrouwelijkheid en integriteit van gegevens.
DECO met TLS maakt gebruik van symmetrische encryptie, waardoor zowel de klant als de webserver encryptiesleutels hebben, en de klant kan, als hij dat wil, de TLS-sessiedata vervalsen. Om dit probleem op te lossen, gebruikt DECO een driedelig handshaking-protocol tussen de prover (smart contract), verifier (oracle) en webserver (gegevensbron).

Het werkingsprincipe van DECO is dat de verifier een deel van de gegevens D ontvangt en bevestigt aan de verifier dat D afkomstig is van de TLS-server S. Een ander probleem is dat TLS geen gegevens ondertekent en het voor de TLS-klant moeilijk is te bewijzen dat de gegevens afkomstig zijn van die server (provenance difficulty).
In the DECO protocol, the encryption keys KEnc and KMac are used. The client sends a request Q to webserver, the server's response R is received in an encrypted form, but the client and server possess the same KMac, allowing the client to spoof the TLS message. DECO's solution is to 'hide' KMac from the client (prover) until it responds to the request. Now KMac is divided between the prover and the verifier ā KpMac and KvMac. The server obtains KMac for encrypting the response using the operation on parts of the key KpMac ā KvMac = KMac.
By setting up a three-way handshake, data exchange between the client and server will be conducted with a guarantee of security.

When discussing decentralized oracle systems, one cannot fail to mention Chainlink, which aims to create a decentralized network of oracle nodes compatible with Ethereum, Bitcoin, and Hyperledger, taking modularity into account: each part of the system can be updated. In this regard, for security purposes, Chainlink offers each oracle participating in the task a combination of keys (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, it is necessary to combine all partial signatures from the network's oracles.
Chainlink plans to conduct the initial PoC DECO with a focus on decentralized financial applications such as Mixicles. At the time of writing, news on Forbes announced that Chainlink had acquired DECO from Cornell University.
Attacks on oracles

From an information security perspective, the following attacks on Town Crier were considered:
Rogue smart contract code injection on TEE nodes.
The essence of the attack: transmission of deliberately incorrect smart contract code to the TEE, thereby enabling an attacker who has gained access to the node to execute their own (fraudulent) smart contract on decrypted data. However, the returned values will be encrypted with the private key, and the only way to access such data lies in the leakage of the ciphertext during return/output.
Defense against this attack involves the enclave checking the correctness of the code located at the current address. This can be achieved using an addressing scheme where the contract address is determined by hashing the contract code.Contract state ciphertext changes leak.
De essentie van de aanval: Eigenaren van knooppunten waar slimme contracten worden uitgevoerd, hebben toegang tot de contractstatus in versleutelde vorm buiten de enclave. Een aanvaller die de controle over een knooppunt verwerft, kan de contractstatus vergelijken voor en na de uitvoering van een transactie en kan bepalen welke argumenten zijn ingevoerd en welke specifieke methode van het slimme contract is gebruikt, aangezien de code van het slimme contract en de technische specificaties openbaar beschikbaar zijn.
Beveiliging ter waarborging van de betrouwbaarheid van het knooppunt zelf.Zij-kanaalanvallen.
Een speciaal type aanval dat gebruik maakt van het monitoren van de toegang tot het geheugen en de cache van de enclave in verschillende scenario's. Een voorbeeld van een dergelijke aanval is Prime and Probe.

De volgorde van de aanval:- t0: De aanvaller vult de hele gegevenscache van het slachtofferproces.
- t1: Het slachtoffer voert code uit met geheugenverzoeken die afhankelijk zijn van vertrouwelijke gegevens van het slachtoffer (cryptografische sleutels). De keuze van de cachelijn gebeurt op basis van de waarde van keybit. In het voorbeeld in de afbeelding is keybit = 0 en wordt het adres X gelezen in cachelijn 2. De gegevens die in X zijn opgeslagen, worden in de cache geladen en verdringen de gegevens die daar eerder waren.
- t2: De aanvaller controleert welke van zijn cachelijnen zijn verdrongen ā lijnen die door het slachtoffer zijn gebruikt. Dit gebeurt door de toegangstijd te meten. Door deze operatie voor elke keybit te herhalen, verkrijgt de aanvaller de volledige sleutel.
Beveiliging tegen de aanval: In Intel SGX zijn er beveiligingen tegen zij-kanaalanvallen, die het monitoren van gebeurtenissen met betrekking tot de cache verbieden, maar de aanval Prime and Probe zal toch doorgaan, aangezien de aanvaller gebeurtenissen in de cache van zijn eigen proces observeert en de cache deelt met het slachtoffer.

Daarom bestaat er momenteel geen betrouwbare bescherming tegen deze aanval.
Er zijn ook aanvallen van het type Spectre en Foreshadow (L1TF), die vergelijkbaar zijn met Prime and Probe. Ze maken het mogelijk om gegevens uit de cache te lezen via een zij-kanaal. Er zijn beschermingen tegen de kwetsbaarheid Spectre-v2, die werkt tegen deze twee aanvallen.
In relatie tot DECO biedt de driefasige handdruk een veiligheidsgarantie:
- Prover-integriteit: een gehacked prover kan geen informatie over de herkomst van de server vervalsen en kan de server niet dwingen ongeldige verzoeken te accepteren of verkeerd te antwoorden op geldige verzoeken. Dit wordt mogelijk gemaakt door verzoeksjablonen tussen de server en de prover.
- Verifier-integriteit: een gehacked verifier kan de prover niet dwingen onjuiste antwoorden te ontvangen.
- Privacy: De gecompromitteerde verifier onderzoekt alleen openbare informatie (aanroep, servernaam).
Bij DECO zijn er alleen kwetsbaarheden gerelateerd aan verkeerinjectie. Aanvankelijk kan de verifier tijdens de drielandige handdruk de identiteit van de server vaststellen met behulp van een fresh nonce. Echter, na de handdruk moet de verifier vertrouwen op netwerklaagindicatoren (IP-adressen). Zo moet de verbinding tussen verifier en server beschermd zijn tegen verkeerinjectie. Dit wordt bereikt door gebruik te maken van een Proxy.
Vergelijking van orakels
Town Crier is gebaseerd op werk met een enclave aan de serverzijde, terwijl DECO authenticatie van de oorsprong van gegevens mogelijk maakt via een drielandige handdruk en versleuteling van gegevens met cryptografische sleutels. De vergelijking van gegevens van orakels is uitgevoerd op basis van de volgende criteria: snelheid, veiligheid, kosten en praktisch nut.
Town Crier
DECO
snelheid
Sneller (0,6s om te voltooien)
Langzamer (10,50s om het protocol te voltooien)
veiligheid
Minder veilig
Veiliger
prijs
Duurder
Goedkoper
praktisch nut
Vereist speciale hardware
Werkt met elke server die TLS ondersteunt
Snelheid: Voor het werken met DECO is configuratie van de drielandige handdruk vereist, bij configuratie via LAN duurt dit 0,37 seconden, voor interactie na het tot stand brengen van de verbinding is 2PC-HMAC effectief (0,13 s om te schrijven). De prestatie van DECO hangt af van de beschikbare TLS-ciphersuites, de grootte van persoonlijke gegevens en de complexiteit van bewijzen voor de specifieke toepassing. In het geval van de binaire optie-app van IC3: het voltooien van het protocol via LAN duurt ongeveer 10,50 s. Ter vergelijking, Town Crier heeft voor het uitvoeren van een vergelijkbare applicatie ongeveer 0,6 seconde nodig, wat betekent dat het ongeveer 20 keer sneller is dan DECO. Onder gelijke voorwaarden zal TC sneller zijn.
Beveiliging: Aanvallen op de Intel SGX-enclave (side-channel attacks) zijn effectief en kunnen aanzienlijke schade toebrengen aan deelnemers van het smart contract. Voor DECO zijn er kwetsbaarheden gerelateerd aan verkeerinjectie, maar het gebruik van proxies maakt deze aanvallen ongedaan. Daarom is DECO veiliger.
Cost: De kosten van hardware die Intel SGX ondersteunt, zijn hoger dan de kosten voor het instellen van het protocol in DECO. Daarom is TC duurder.
Praktisch nut: Voor het werken met Town Crier is speciale apparatuur vereist die TEE ondersteunt. Bijvoorbeeld, Intel SGX wordt ondersteund op processors van de Intel Core 6e generatie en nieuwer. DECO kan echter met elke apparatuur werken, hoewel er een DECO-instelling is die TEE gebruikt. Het opzetten van de drievoudige handdruk bij DECO kan enige tijd in beslag nemen, maar dit kan niet vergeleken worden met de hardwarebeperkingen voor TC, waardoor DECO praktischer is.
Conclusie
Bij het afzonderlijk bekijken van de twee oracle en het vergelijken op vier criteria, is duidelijk dat Town Crier op drie van de vier punten onderdoet voor DECO. DECO is betrouwbaarder vanuit een beveiligingsperspectief, goedkoper en praktischer, hoewel het opzetten van het drievoudige protocol enige tijd kan kosten en ook nadelen heeft, zoals extra bewerkingen met encryptiesleutels. TC werkt sneller dan DECO, maar de kwetsbaarheid gerelateerd aan side-channel attacks maakt het kwetsbaar voor privacyverlies. Het is belangrijk te overwegen dat DECO in januari 2020 werd gepresenteerd, en er is nog niet genoeg tijd verstreken om het als veilig te beschouwen. Town Crier is al 4 jaar onderworpen aan aanvallen en heeft veel controles doorstaan, waardoor het gebruik in veel projecten gerechtvaardigd is.
Bron: habr.com

