I dag er det kun de dovne, der ikke har skrevet om blockchain-teknologi, kryptovalutaer og hvor fedt det er. Men denne artikel vil ikke rose denne teknologi; den vil fokusere på dens mangler og måder at eliminere dem på.

Under arbejdet på et af projekterne hos Altirix Systems opstod opgaven med sikker, censurbestandig bekræftelse af data fra en ekstern kilde til blockchainen. Det var nødvendigt at bekræfte ændringer i det tredje systems optegnelser og, baseret på disse ændringer, udføre en eller anden gren i den smarte kontrakts logik. Opgaven er ved første øjekast ret triviel, men når den økonomiske situation for en af ​​parterne i processen afhænger af resultatet af dens implementering, opstår der yderligere krav. Først og fremmest er det en omfattende tillid til en sådan valideringsmekanisme. Men først og fremmest.

Problemet er, at blockchainen i sig selv er en autonom, lukket enhed, så smarte kontrakter inde i blockchainen ved intet om omverdenen. Samtidig er vilkårene i smarte kontrakter ofte knyttet til information om virkelige ting (flyforsinkelse, valutakurser osv.). For at smarte kontrakter kan fungere korrekt, skal information modtaget uden for blockchainen være pålidelig og verificeret. Dette problem løses ved at bruge orakler som Town Crier og DECO. Disse orakler tillader en smart kontrakt i blockchain-netværket at have tillid til information fra en betroet webserver, så de kan kaldes pålidelige informationsudbydere.

Orakler

Forestil dig en smart kontrakt, der overfører 0.001 btc til din bitcoin-wallet, hvis din yndlingsfodboldklub vinder den russiske pokal. I tilfælde af en reel sejr skal smartkontrakten have information om, hvilken klub der vandt, og dette rejser en række problemer: Hvor kan disse oplysninger indhentes, hvordan kan de overføres sikkert til smartkontrakten, og hvordan kan vi sikre, at de oplysninger, der modtages af smartkontrakten, faktisk stemmer overens med virkeligheden?

I spørgsmålet om informationskilden kan der være to scenarier: at forbinde en smart kontrakt til et betroet websted, hvor information om resultaterne af matches er centralt lagret, og den anden mulighed er at forbinde flere websteder på én gang og derefter vælge information fra de fleste kilder, der leverer de samme data. For at sikre informationens korrekthed anvendes orakler, såsom Oraclize, der bruger TLSNotary (TLS Modification for Proving Data Authenticity). Men der er nok information om Oraclize i Google, og der er flere artikler om Habr, men i dag vil jeg tale om orakler, der bruger en lidt anderledes tilgang til at overføre information: Town Crier og DECO. Artiklen giver en beskrivelse af de to oraklers funktionsprincipper samt en detaljeret sammenligning.

Town Crier

Town Crier (TC) blev introduceret af IC3 (The Initiative for CryptoCurrencies and Contracts) i 2016 på CCS'16. Hovedideen bag TC er at videregive information fra et websted til en smart kontrakt og sikre, at de oplysninger, der leveres af TC, er de samme som dem på webstedet. TC bruger TEE (Trusted Execution Environment) til at sikre ægthed af dataejerskab. Den originale version af TC beskriver arbejdet med Intel SGX.
Town Crier består af en del inde i blockchainen og en del inde i selve operativsystemet - TC Server.

TC-kontrakten findes på blockchainen og fungerer som en frontend for TC. Den accepterer anmodninger fra CU (brugerens smarte kontrakt) og returnerer svar fra TC-serveren. Inde i TC-serveren er der et relæ, som etablerer en forbindelse mellem enklaven og internettet (tovejstrafik) og forbinder enklaven med blockchainen. Enclave indeholder progencl, som er den kode, der foretager anmodninger fra blockchainen og returnerer beskeder til blockchainen med en digital signatur, mens progencl indeholder en del af smartkontraktkoden og i bund og grund udfører nogle af dens funktioner.

Intel SGX-enklaven kan betragtes som et delt bibliotek med en API, der fungerer via ecall. Ecall overfører kontrollen til enklaven. Enklaven udfører sin kode, indtil den afsluttes, eller indtil der opstår en undtagelse. For at kalde funktioner defineret uden for enklaven bruges ocall. Ocall udføres uden for enklaven og behandles af den som et upålidelig opkald. Efter ocall er udført, vender kontrollen tilbage til enklaven.

I Enclave-delen konfigureres en sikker kanal med webserveren, enklaven udfører selv et TLS-handshake med målserveren og udfører alle kryptografiske operationer internt. TLS-biblioteket (mbedTLS) og den minificerede HTTP-kode er blevet eksporteret til SGX-miljøet. Enclave indeholder også rod-CA-certifikater (en samling af certifikater) til at verificere certifikater for eksterne servere. Request Handler accepterer en datagramanmodning i det format, der leveres af Ethereum, dekrypterer den og analyserer den. Derefter genererer den en Ethereum-transaktion, der indeholder det anmodede datagram, signerer det ved hjælp af skTC og sender det til Relay.

Relædelen inkluderer klientgrænseflade, TCP og blockchain-grænseflade. Klientgrænsefladen er nødvendig for at validere enklavekoden og kommunikere med klienten. Klienten sender en attestationsanmodning ved hjælp af ecall og modtager et tidsstempel signeret af skTC sammen med att (attestationssignatur). Derefter verificeres att ved hjælp af Intel Attestation Service (IAS), og tidsstemplet verificeres af en betroet tidstjeneste. Blockchain-grænsefladen verificerer indgående anmodninger og placerer transaktioner på blockchainen for at levere datagrammer. Geth er den officielle Ethereum-klient og tillader Relay at interagere med blockchainen via RPC-kald.

Ved at arbejde med TEE tillader TC at opsende flere enklaver parallelt, hvorved informationsbehandlingshastigheden øges med 3 gange. Hvis hastigheden med én kørende enklave var 15 tx/sek, så stiger hastigheden med 20 parallelt kørende enklaver til 65 tx/sek. Til sammenligning er den maksimale driftshastighed i Bitcoin-blockchainen 26 tx/sek.

DECO

DECO (Decentralized Oracles for TLS) blev præsenteret på CCS'20 og fungerer med websteder, der understøtter TLS-forbindelse. Sikrer dataenes fortrolighed og integritet.
DECO med TLS bruger symmetrisk kryptering, så både klienten og webserveren har krypteringsnøgler, og klienten kan forfalske TLS-sessionsdata, hvis den ønsker det. For at løse dette problem bruger DECO en trevejs-handshake-protokol mellem proveren (smart kontrakt), verifikatoren (oracle) og webserveren (datakilde).

Princippet bag DECO er, at beviseren modtager et dataelement D og bekræfter over for verifikatoren, at D kommer fra TLS-serveren S. Et andet problem er, at TLS ikke signerer dataene, og det er vanskeligt for TLS-klienten at bevise, at dataene kommer fra den pågældende server (proveniensvanskeligheder).

DECO-protokollen bruger krypteringsnøglerne KEnc og KMac. Klienten sender en anmodning Q til webserverSvaret fra server R ankommer krypteret, men klienten og serveren deler den samme KMac, og klienten kan forfalske TLS-beskeden. DECOs løsning er at "skjule" KMac'en for klienten (proveren), indtil den svarer på anmodningen. Nu er KMac'en delt mellem proveren og verifikatoren - KpMac og KvMac. Serveren henter KMac'en for at kryptere svaret ved hjælp af nøglepartitioneringsoperationen KpMac ⊕ KvMac = KMac.

Ved at oprette et trevejs-handshake vil dataudveksling mellem klienten og serveren blive udført med en garanti for sikkerhed.

Når vi taler om decentraliserede orakelsystemer, kan vi ikke lade være med at nævne Chainlink, som sigter mod at skabe et decentraliseret netværk af orakelnoder, der er kompatible med Ethereum, Bitcoin og Hyperledger, med modularitet i tankerne: hver del af systemet kan opgraderes. For at sikre sikkerhed kræver Chainlink, at hvert orakel, der deltager i opgaven, angiver en kombination af nøgler (offentlige og private). Den private nøgle bruges til at generere en delvis signatur, der indeholder deres svar på dataanmodningen. For at få et svar skal alle delvise signaturer fra netværkets orakler kombineres.

Chainlink planlægger at gennemføre en indledende PoC for DECO med fokus på decentraliserede finansielle applikationer såsom Mixicles. I skrivende stund kom der nyheder frem på Forbes om, at Chainlink har opkøbt DECO fra Cornell University.

Angreb på orakel

Fra et informationssikkerhedsperspektiv blev følgende angreb på Town Crier overvejet:

1. Uærlig smart-contact-kodeindsprøjtning på TEE-noder.
   Essensen af ​​angrebet: overførsel af en bevidst forkert smart kontraktkode til TEE'en, så en angriber, der har fået adgang til noden, vil være i stand til at udføre sin egen (svindelagtige) smart kontrakt på de dekrypterede data. De returnerede værdier vil dog blive krypteret med en privat nøgle, og den eneste måde at få adgang til sådanne data er at lække krypteringsteksten ved returnering/output.
   Beskyttelse mod dette angreb består i, at enklaven kontrollerer korrektheden af ​​den kode, der er placeret på den aktuelle adresse. Dette kan opnås ved hjælp af et adresseringsskema, hvor adressen på en kontrakt bestemmes ved at hashe kontraktkoden.

2. Lækage af ændringer i krypteret kontraktstilstand.
   Essensen af ​​angrebet: Ejere af noder, hvor smarte kontrakter udføres, har adgang til kontraktens tilstand i krypteret form uden for enklaven. En angriber, der får kontrol over en node, kan sammenligne kontakttilstanden før og efter transaktionen er udført og kan bestemme, hvilke argumenter der blev indtastet, og hvilken smart kontrakt-metode der blev brugt, da selve smart kontrakt-koden og dens tekniske specifikationer er offentligt tilgængelige.
   Beskyttelse ved at sikre selve enhedens pålidelighed.

3. Sidekanalangreb.
   En særlig type angreb, der bruger overvågning af adgang til enklavehukommelse og cache i forskellige scenarier. Et eksempel på et sådant angreb er Prime and Probe.
   
   Angrebets rækkefølge:

   • t0: Angriberen fylder hele offerprocessens datacache.
   • t1: Offeret udfører kode med hukommelsesadgange, der afhænger af offerets følsomme data (kryptografiske nøgler). Cache-linjen vælges baseret på keybit-værdien. I eksemplet i figuren er keybit = 0, og adresse X i cache linje 2 læses. Dataene, der er gemt i X, indlæses i cachen og erstatter de data, der var der før.
   • t2: Angriberen tjekker, hvilke af hans cachelinjer der er blevet fjernet - de linjer, som offeret har brugt. Dette gøres ved at måle adgangstiden. Ved at gentage denne operation for hver nøglebit, får angriberen adgang til hele nøglen.

Angrebsbeskyttelse: Intel SGX har beskyttelse mod sidekanalangreb, der forhindrer overvågning af cache-relaterede hændelser, men Prime- og Probe-angrebet vil stadig lykkes, fordi angriberen overvåger cachehændelserne i sin proces og deler cachen med offeret.

Der er derfor i øjeblikket ingen pålidelig beskyttelse mod dette angreb.

Spectre- og Foreshadow-angreb (L1TF), der ligner Prime og Probe, er også kendte. De tillader læsning af data fra cachehukommelsen via en tredjepartskanal. Der er en beskyttelse mod Spectre-v2-sårbarheden, der virker mod begge disse angreb.

I forhold til DECO giver trevejshåndtrykket en sikkerhedsgaranti:

1. Proverintegritet: En kompromitteret prover kan ikke forfalske oplysninger om en servers oprindelse og kan ikke få serveren til at acceptere ugyldige anmodninger eller reagere forkert på gyldige anmodninger. Dette er muligt via anmodningsskabeloner mellem server og prover.
2. Verifikatorintegritet: En hacket verifikator kan ikke forårsage, at en verifikator får forkerte svar.
3. Privatliv: Den hackede verifikator undersøger kun offentligt tilgængelige oplysninger (forespørgsel, servernavn).

I DECO er kun sårbarheder i form af trafikkinjektion mulige. I starten, under et trevejs-handshake, kan verifikatoren fastslå serverens identitet ved hjælp af en ny nonce. Efter handshaket skal verifikatoren dog stole på netværkslagsindikatorer (IP-adresserDerfor skal forbindelsen mellem verifikatoren og serveren beskyttes mod trafikkø. Dette opnås ved at bruge en proxy.

Sammenligning af orakel

Town Crier er baseret på at arbejde med en enklave i serverdelen, mens DECO muliggør verifikation af ægtheden af ​​dataoprindelsen ved hjælp af et trevejs-handshake og kryptering af data med kryptografiske nøgler. Sammenligningen af ​​disse orakler blev udført efter følgende kriterier: hastighed, sikkerhed, omkostninger og praktisk anvendelighed.

Town Crier
DECO

præstation
Hurtigere (0.6 sekunder til slut)
Langsommere (10.50 sekunder for at afslutte protokollen)

sikkerhed
Mindre sikker
Mere sikker

koste
Dyrere
Billigere

praktisk
Kræver særlig hardware
Fungerer med alle servere, der understøtter TLS

hastighedDECO kræver en trevejs handshake-opsætning, hvilket tager 0.37 sekunder ved opsætning via LAN, og 2PC-HMAC er effektiv til kommunikation efter tilslutning (0,13 sekunder pr. skrivning). DECOs ydeevne afhænger af de tilgængelige TLS-chiffersuiter, størrelsen af ​​de private data og kompleksiteten af ​​beviserne for en bestemt applikation. Ved at bruge eksemplet med den binære optionapplikation fra IC3 tager færdiggørelsen af ​​protokollen via LAN cirka 10,50 sekunder. Til sammenligning bruger Town Crier cirka 0,6 sekunder på at køre en lignende applikation, hvilket er cirka 20 gange hurtigere end DECO. Alt andet lige vil TC være hurtigere.

БезопасностьIntel SGX enklave sidekanalangreb virker og kan forårsage reel skade på smart kontrakt-deltagere. Trafikinjektionsangreb er mulige med DECO, men brug af en proxy vil neutralisere sådanne angreb. Derfor er DECO sikrere.

OmkostningerOmkostningerne ved hardware, der understøtter Intel SGX, er højere end omkostningerne ved at konfigurere protokollen i DECO. Derfor er TC dyrere.

praktiskFor at arbejde med Town Crier kræves der specielt udstyr, der understøtter TEE. For eksempel understøttes Intel SGX på 6. generations Intel Core-processorfamilie og nyere. DECO giver dig mulighed for at arbejde med ethvert udstyr, selvom der er en DECO-indstilling ved hjælp af TEE. Med hensyn til opsætningsprocessen kan DECOs trevejs-handshake tage lidt tid, men det er ingenting i forhold til TCs hardwarebegrænsning, så DECO er mere praktisk.

Konklusion

Hvis man ser på de to orakler separat og sammenligner dem på fire kriterier, er det tydeligt, at Town Crier er ringere end DECO på tre ud af fire punkter. DECO er mere pålidelig med hensyn til informationssikkerhed, billigere og mere praktisk, selvom det kan tage tid at oprette en trepartsprotokol og har sine ulemper, såsom yderligere operationer med krypteringsnøgler. TC er hurtigere end DECO, men en sårbarhed forbundet med et sidekanalangreb gør den modtagelig for tab af privatlivets fred. Det skal tages i betragtning, at DECO blev introduceret i januar 2020, og der er ikke gået tilstrækkelig tid til at betragte det som sikkert. Town Crier har været under angreb i 4 år og har gennemgået mange tests, så dens brug i mange projekter er berettiget.

Kilde: www.habr.com