Tegenwoordig hebben alleen de luie mensen nog niet geschreven over blockchain-technologie, cryptocurrencies en hoe cool het is. Maar dit artikel zal deze technologie niet prijzen; we zullen praten over de tekortkomingen ervan en manieren om deze te elimineren.

Terwijl ik aan een van de projecten bij Altirix Systems werkte, ontstond de taak van het veilig, censuurbestendig bevestigen van gegevens van een bron buiten de blockchain. Het was noodzakelijk om wijzigingen in de records van het derde systeem te bevestigen en, op basis van deze wijzigingen, een of andere tak in de slimme contractlogica uit te voeren. De taak is op het eerste gezicht vrij triviaal, maar wanneer de financiële toestand van een van de partijen die aan het proces deelnemen afhankelijk is van het resultaat van de implementatie ervan, verschijnen er aanvullende vereisten. In de eerste plaats is dit een alomvattend vertrouwen in een dergelijk validatiemechanisme. Maar eerst dingen eerst.

Het probleem is dat de blockchain zelf een autonome, gesloten entiteit is, waardoor de slimme contracten binnen de blockchain niets weten over de buitenwereld. Tegelijkertijd houden de voorwaarden van slimme contracten vaak verband met informatie over echte zaken (vluchtvertragingen, wisselkoersen, enz.). Om slimme contracten goed te laten werken, moet informatie die van buiten de blockchain wordt ontvangen betrouwbaar en geverifieerd zijn. Dit probleem wordt opgelost door gebruik te maken van orakels zoals Town Crier en DECO. Deze orakels maken het mogelijk dat een slim contract op het blockchain-netwerk informatie van een vertrouwde webserver vertrouwt; we kunnen zeggen dat dit leveranciers van betrouwbare informatie zijn.

Orakels

Stel je voor dat een slim contract 0.001 btc naar je bitcoin-portemonnee overmaakt als je favoriete voetbalclub de Russische beker wint. In het geval van een echte overwinning moet het slimme contract informatie overdragen over welke club heeft gewonnen, en hier doen zich een aantal problemen voor: waar deze informatie te verkrijgen is, hoe deze veilig naar het slimme contract kan worden overgebracht en hoe ervoor kan worden gezorgd dat de informatie ontvangen in het slimme contract is geldig en komt het overeen met de werkelijkheid?

Als het om de informatiebron gaat, kunnen er 2 scenario’s zijn: een slim contract verbinden met een vertrouwde website waar informatie over wedstrijdresultaten centraal wordt opgeslagen, en de tweede optie is om meerdere sites tegelijk te verbinden en vervolgens informatie uit de meeste bronnen te selecteren. die dezelfde gegevens opleveren. Om de juistheid van de informatie te verifiëren, wordt gebruik gemaakt van orakels, bijvoorbeeld Oraclize, dat gebruik maakt van TLSNotary (TLS Notary Modification to Prove the Authenticity of Data). Maar er is genoeg informatie op Google over Oraclize, en er zijn verschillende artikelen over Habré. Vandaag zal ik het hebben over orakels die een iets andere benadering gebruiken bij het doorgeven van informatie: Town Crier en DECO. Het artikel geeft een beschrijving van de werkingsprincipes van beide orakels, evenals een gedetailleerde vergelijking.

Stadsomroeper

Town Crier (TC) werd in 3 geïntroduceerd door IC2016 (The Initiative for CryptoCurrencies and Contracts) tijdens CCS'16. Het hoofdidee van TC: breng informatie van een website over naar een smart contract en zorg ervoor dat de door TC aangeleverde informatie dezelfde is als op de website. TC gebruikt TEE (Trusted Execution Environment) om het eigendom van gegevens te verifiëren. De originele versie van TC beschrijft hoe u met Intel SGX kunt werken.
Town Crier bestaat uit een deel binnen de blockchain en een deel binnen het besturingssysteem zelf: TC Server.

TC Contract bevindt zich op de blockchain en fungeert als front-end voor TC. Het accepteert verzoeken van de CU (user smart contract) en retourneert een antwoord van de TC-server. Binnenin de TC Server bevindt zich een Relay, die een verbinding tot stand brengt tussen de enclave en het internet (bidirectioneel verkeer) en de enclave verbindt met de blockchain. Enclave bevat progencl, een code die verzoeken doet vanuit de blockchain en berichten terugstuurt naar de blockchain met een digitale handtekening. Progencl bevat een deel van de slimme contractcode en voert in wezen enkele van zijn functies uit.

De Intel SGX-enclave kan worden gezien als een gedeelde bibliotheek met een API die via ecall draait. Ecall draagt ​​de controle over aan de enclave. De enclave voert zijn code uit totdat deze wordt afgesloten of totdat er een uitzondering optreedt. ocall wordt gebruikt om functies aan te roepen die buiten de enclave zijn gedefinieerd. Ocall wordt buiten de enclave uitgevoerd en wordt door deze als een niet-vertrouwde oproep behandeld. Nadat ocall is uitgevoerd, wordt de controle teruggegeven aan de enclave.

In het Enclave-gedeelte wordt een beveiligd kanaal geconfigureerd met een webserver, de enclave voert zelf een TLS-handshake uit met de doelserver en voert alle cryptografische bewerkingen intern uit. De TLS-bibliotheek (mbedTLS) en de gereduceerde HTTP-code zijn geëxporteerd naar de SGX-omgeving. Enclave bevat ook root-CA-certificaten (een verzameling certificaten) om de certificaten van externe servers te verifiëren. Request Handler accepteert een datagramverzoek in het formaat van Ethereum, decodeert het en parseert het. Vervolgens genereert het een Ethereum-transactie met het gevraagde datagram, ondertekent het met skTC en verzendt het naar Relay.

Het Relay-gedeelte omvat Client Interface, TCP, Blockchain Interface. De clientinterface is nodig om de enclavecode te certificeren en met de client te communiceren. De client verzendt een attestationverzoek met behulp van ecall en ontvangt een tijdstempel ondertekend door skTC samen met att (attestationhandtekening). Vervolgens wordt att geverifieerd met behulp van Intel Attestation Service (IAS) en wordt de tijdstempel geverifieerd door een vertrouwde tijdservice. Blockchain Interface verifieert inkomende verzoeken en plaatst transacties op de blockchain voor levering van datagrammen. Geth is een officiële Ethereum-client en stelt Relay in staat om via RPC-oproepen met de blockchain te communiceren.

Door met TEE te werken, kunt u met TC meerdere enclaves parallel laten draaien, waardoor de snelheid van informatieverwerking drie keer wordt verhoogd. Als bij één draaiende enclave de snelheid 3 tx/sec was, dan neemt bij 15 parallel lopende enclaves de snelheid toe tot 20 tx/sec; ter vergelijking: de maximale werksnelheid in de Bitcoin blockchain is 65 tx/sec.

DECO

DECO (Decentralized Oracles for TLS) werd gepresenteerd op CCS'20 en werkt met sites die TLS-verbindingen ondersteunen. Garandeert de vertrouwelijkheid en integriteit van gegevens.
DECO met TLS maakt gebruik van symmetrische codering, zodat de client en webserver coderingssleutels hebben en de client TLS-sessiegegevens kan vervalsen als hij dat wil. Om dit probleem op te lossen, gebruikt DECO een drieweg-handshake-protocol tussen de prover (smart contract), verifier (orakel) en webserver (gegevensbron).

De manier waarop DECO werkt is dat de verificateur een stukje data D ontvangt en aan de verificateur bevestigt dat D afkomstig is van de TLS-server S. Een ander probleem is dat TLS de gegevens niet ondertekent en het voor de TLS-client moeilijk is om te bewijzen dat de de gegevens zijn van precies de juiste server ontvangen (probleem met herkomst).

Het DECO-protocol maakt gebruik van KEnc- en KMac-coderingssleutels. De client stuurt een verzoek Q naar de webserver, het antwoord van de server R komt in gecodeerde vorm, maar de client en de server bezitten dezelfde KMac en de client kan het TLS-bericht vervalsen. De oplossing van DECO is om de KMac te "verbergen" voor de client (prover) totdat deze op het verzoek reageert. Nu is KMac verdeeld tussen bewijzer en verificateur: KpMac en KvMac. De server ontvangt KMac om het antwoord te coderen met behulp van de sleutelbewerking KpMac ⊕ KvMac = KMac.

Door het opzetten van een drieweg-handshake wordt de gegevensuitwisseling tussen de client en de server uitgevoerd met een veiligheidsgarantie.

Als we het hebben over een gedecentraliseerd orakelsysteem, kan men niet anders dan Chainlink noemen, dat tot doel heeft een gedecentraliseerd netwerk van orakelknooppunten te creëren die compatibel zijn met Ethereum, Bitcoin en Hyperledger, rekening houdend met de modulariteit: elk onderdeel van het systeem kan worden bijgewerkt. Om de veiligheid te garanderen, biedt Chainlink tegelijkertijd elk orakel dat aan de taak deelneemt de mogelijkheid om een ​​combinatie van sleutels (openbaar en privé) uit te geven. De privésleutel wordt gebruikt om een ​​gedeeltelijke handtekening te genereren die hun beslissing op het gegevensverzoek bevat. Om een ​​antwoord te verkrijgen, is het noodzakelijk om alle gedeeltelijke handtekeningen van de orakels van het netwerk te combineren.

Chainlink is van plan een eerste PoC DECO uit te voeren met de nadruk op gedecentraliseerde financiële toepassingen zoals Mixicles. Op het moment van schrijven kwam er op Forbes het nieuws naar buiten dat Chainlink DECO van Cornell University had overgenomen.

Aanvallen op orakels

Vanuit het oogpunt van informatiebeveiliging werden de volgende aanvallen op Town Crier overwogen:

1. Rogue smart-contact code-injectie op TEE-knooppunten.
   De essentie van de aanval: het verzenden van een opzettelijk onjuiste smart contract-code naar TEE, waardoor een aanvaller die toegang heeft gekregen tot het knooppunt zijn eigen (frauduleuze) smart contract kan uitvoeren op de gedecodeerde gegevens. De geretourneerde waarden worden echter gecodeerd met een privésleutel, en de enige manier om toegang te krijgen tot dergelijke gegevens is door de cijfertekst bij retour/uitvoer te lekken.
   Bescherming tegen deze aanval bestaat erin dat de enclave de juistheid van de code op het huidige adres controleert. Dit kan worden bereikt met behulp van een adresseringsschema waarbij het contractadres wordt bepaald door de contractcode te hashen.

2. Contractstatus cijfertekstwijzigingen lekken.
   De essentie van de aanval: eigenaren van knooppunten waarop slimme contracten worden uitgevoerd, hebben buiten de enclave in gecodeerde vorm toegang tot de contractstatus. Een aanvaller, die de controle over een knooppunt heeft verworven, kan de contactstatus voor en na de transactie vergelijken en bepalen welke argumenten zijn ingevoerd en welke slimme contractmethode is gebruikt, aangezien de slimme contractcode zelf en de technische specificaties ervan publiekelijk beschikbaar zijn.
   Bescherming bij het garanderen van de betrouwbaarheid van het knooppunt zelf.

3. Zijkanaalaanvallen.
   Een speciaal type aanval waarbij in verschillende scenario's gebruik wordt gemaakt van monitoring van enclavegeheugen en cachetoegang. Een voorbeeld van zo’n aanval is Prime en Probe.
   
   Aanvalsvolgorde:

   • t0: De aanvaller vult de volledige gegevenscache van het slachtofferproces.
   • t1: Het slachtoffer voert code uit met geheugentoegang die afhankelijk is van de gevoelige gegevens van het slachtoffer (cryptografische sleutels). De cacheregel wordt geselecteerd op basis van de keybitwaarde. In het voorbeeld in de afbeelding wordt keybit = 0 gelezen en wordt het adres X gelezen in cacheregel 2. De gegevens die zijn opgeslagen in X worden in de cache geladen, waardoor de gegevens die er eerder waren, worden vervangen.
   • t2: De aanvaller controleert welke van zijn cacheregels zijn verwijderd: regels die door het slachtoffer worden gebruikt. Dit wordt gedaan door de toegangstijd te meten. Door deze handeling voor elke sleutelbit te herhalen, verkrijgt de aanvaller de volledige sleutel.

Aanvalsbescherming: Intel SGX heeft bescherming tegen zijkanaalaanvallen die het monitoren van cachegerelateerde gebeurtenissen voorkomen, maar een Prime- en Probe-aanval zal nog steeds werken omdat de aanvaller de cachegebeurtenissen van zijn proces bewaakt en de cache deelt met het slachtoffer.

Op dit moment is er dus geen betrouwbare bescherming tegen deze aanval.

Ook aanvallen als Spectre en Foreshadow (L1TF), vergelijkbaar met Prime en Probe, zijn bekend. Hiermee kunt u gegevens uit het cachegeheugen lezen via een kanaal van derden. Er wordt bescherming geboden tegen de Spectre-v2-kwetsbaarheid, die tegen twee van deze aanvallen werkt.

Met betrekking tot DECO biedt de drievoudige handdruk een garantie voor veiligheid:

1. Prover-integriteit: Een gehackte prover kan de oorsprongsinformatie van de server niet vervalsen en kan er niet voor zorgen dat de server ongeldige verzoeken accepteert of onjuist reageert op geldige verzoeken. Dit gebeurt via verzoekpatronen tussen server en prover.
2. Verifier-integriteit: Een gehackte verifier kan er niet voor zorgen dat de prover onjuiste antwoorden ontvangt.
3. Privacy: De gehackte verificateur onderzoekt alleen openbare informatie (verzoek, servernaam).

In DECO zijn alleen kwetsbaarheden voor verkeersinjectie mogelijk. Ten eerste kan de verificateur met een drieweghandshake de identiteit van de server vaststellen met behulp van een nieuwe nonce. Na de handshake moet de verificateur echter vertrouwen op netwerklaagindicatoren (IP-adressen). De communicatie tussen de verificateur en de server moet dus worden beschermd tegen verkeersinjectie. Dit wordt bereikt door gebruik te maken van Proxy.

Vergelijking van orakels

Town Crier is gebaseerd op het werken met een enclave in het servergedeelte, terwijl u met DECO de authenticiteit van de herkomst van gegevens kunt verifiëren met behulp van een drieweghandshake en gegevensversleuteling met cryptografische sleutels. De vergelijking van deze orakels werd uitgevoerd op basis van de volgende criteria: prestatie, veiligheid, kosten en bruikbaarheid.

Stadsomroeper
DECO

prestatie
Sneller (0.6s tot finish)
Langzamer (10.50 seconden om het protocol te voltooien)

veiligheid
Minder veilig
Veiliger

kosten
Duurder
Goedkoper

uitvoerbaarheid
Vereist speciale hardware
Werkt met elke server die TLS ondersteunt

Snelheid prestaties: Om met DECO te werken is een drieweg-handshake vereist, bij het instellen via LAN duurt dit 0.37 seconden, voor interactie nadat de verbinding tot stand is gebracht is 2PC-HMAC effectief (0,13 s per schrijven). De prestaties van DECO zijn afhankelijk van de beschikbare TLS-coderingssuites, de omvang van de privégegevens en de complexiteit van het bewijsmateriaal voor een bepaalde toepassing. Met de binaire optie-applicatie van IC3 als voorbeeld: het voltooien van het protocol via LAN duurt ongeveer 10,50 seconden. Ter vergelijking: Town Crier heeft ongeveer 0,6 seconde nodig om een ​​soortgelijke aanvraag te voltooien, wat ongeveer 20 keer sneller is dan DECO. Als alles gelijk blijft, zal TC sneller zijn.

veiligheid: Aanvallen op de Intel SGX-enclave (zijkanaalaanvallen) werken en kunnen echte schade toebrengen aan de deelnemers aan het slimme contract. Wat DECO betreft, zijn aanvallen gerelateerd aan verkeersinjectie mogelijk, maar het gebruik van een proxy reduceert dergelijke aanvallen tot niets. Daarom is DECO veiliger.

kosten: De kosten van apparatuur die Intel SGX ondersteunt, zijn hoger dan de kosten voor het opzetten van het protocol in DECO. Daarom is TC duurder.

uitvoerbaarheid: Om met Town Crier te werken is speciale apparatuur vereist die TEE ondersteunt. Intel SGX wordt bijvoorbeeld ondersteund op de 6e generatie Intel Core-processorfamilie en hoger. Met DECO kun je met alle apparatuur werken, al is er wel een DECO-instelling met behulp van TEE. Volgens het installatieproces kan de drievoudige handshake van DECO enige tijd duren, maar dit is niets vergeleken met de hardwarebeperking van TC, dus DECO is praktischer.

Conclusie

Als we de twee orakels afzonderlijk bekijken en op vier criteria vergelijken, wordt het duidelijk dat Town Crier op drie van de vier punten inferieur is aan DECO. DECO is vanuit het oogpunt van informatiebeveiliging betrouwbaarder, goedkoper en praktischer, hoewel het opzetten van een driepartijenprotocol enige tijd kan duren en nadelen heeft, bijvoorbeeld extra handelingen met encryptiesleutels. TC is sneller dan DECO, maar kwetsbaarheden bij zijkanaalaanvallen maken het gevoelig voor verlies van vertrouwelijkheid. Er moet rekening mee worden gehouden dat DECO in januari 2020 is geïntroduceerd en dat er niet genoeg tijd is verstreken om het als veilig te beschouwen. Town Crier wordt al vier jaar aangevallen en heeft veel tests ondergaan, dus het gebruik ervan in veel projecten is gerechtvaardigd.

Bron: www.habr.com