{"id":93794,"date":"2020-09-10T07:42:27","date_gmt":"2020-09-10T05:42:27","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/town-crier-vs-deco-kakoj-orakul-ispolzovat-v-blokchejne"},"modified":"2020-09-10T07:42:27","modified_gmt":"2020-09-10T05:42:27","slug":"town-crier-vs-deco-kakoj-orakul-ispolzovat-v-blokchejne","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/town-crier-vs-deco-kakoj-orakul-ispolzovat-v-blokchejne","title":{"rendered":"Town Crier vs DECO: hvilken oracle skal bruges i blockchain?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

I dag har kun de dovne ikke skrevet om blockchain-teknologi, kryptovalutaer og hvor fantastisk det er. Men i denne artikel vil der ikke v\u00e6re noget ros af denne teknologi; vi vil derimod tale om dens ulemper og m\u00e5der at l\u00f8se dem p\u00e5. <\/p>\n

<\/p>\n

\"Town<\/p>\n

<\/p>\n

Under arbejdet med et af projekterne i Altiriks Systems opstod der en opgave om beskyttet, censurresistent bekr\u00e6ftelse af data fra en ekstern blockchain-kilde. Det var n\u00f8dvendigt at bekr\u00e6fte \u00e6ndringer i poster fra et tredje system og udf\u00f8re forskellige handlinger i smart-kontraktens logik baseret p\u00e5 disse \u00e6ndringer. Opgaven virker umiddelbart ret trivial, men n\u00e5r resultatet af den afh\u00e6nger af den finansielle situation for en af parterne i processen, opst\u00e5r der yderligere krav. F\u00f8rst og fremmest kr\u00e6ves der en bred tillid til en s\u00e5dan valideringsmekanisme. Men lad os tage det skridt for skridt. <\/p>\n

<\/a><\/noindex><\/p>\n

Problemet er, at blockchain i sig selv er et autonomt, lukket system, s\u00e5 smart-kontrakter inden for blockchain ikke har kendskab til den ydre verden. Samtidig er betingelserne for smart-kontrakter ofte forbundet med information om virkelige forhold (f.eks. forsinkelse af fly, valutakurser osv.). For at smart-kontrakter kan fungere korrekt, skal den eksterne information v\u00e6re p\u00e5lidelig og verificeret. Dette problem l\u00f8ses ved at anvende orakler som Town Crier og DECO. Disse orakler g\u00f8r det muligt for smart-kontrakten i blockchain-netv\u00e6rket at stole p\u00e5 information fra en kontrolleret webserver; man kan sige, at de er leverand\u00f8rer af p\u00e5lidelig information. <\/p>\n

<\/p>\n

Orakler<\/h1>\n

<\/p>\n

Forestil dig, at en smart-kontrakt overf\u00f8rer 0,001 btc til din bitcoin-tegnebog, hvis dit yndlingsfodboldhold vinder den russiske pokal. I tilf\u00e6lde af en reelt sejr skal smart-kontrakten have information om, hvilket hold der vandt, og her opst\u00e5r der en r\u00e6kke problemer: hvor skal man finde denne information, hvordan kan man sikkert overf\u00f8re den til smart-kontrakten, og hvordan kan man sikre, at den information, som kommer ind i smart-kontrakten, faktisk stemmer overens med virkeligheden? <\/p>\n

<\/p>\n

N\u00e5r det kommer til kilden til information, kan der v\u00e6re to scenarier: at forbinde smartkontrakten til en betroet hjemmeside, hvor information om kampenes resultater er centralt opbevaret, eller den anden mulighed \u2013 at forbinde flere hjemmesider og derefter v\u00e6lge information fra de fleste kilder, der giver de samme data. For at sikre informationens korrekthed anvendes orakler, eksempelvis Oraclize, der bruger TLSNotary (en modification af TLS til at bevise datagennemsigtighed). Men der er rigeligt med information om Oraclize p\u00e5 Google, og der er adskillige artikler p\u00e5 Habr\u00e9; i dag vil jeg dog fort\u00e6lle om orakler, der benytter en lidt anden tilgang til informationsoverf\u00f8rsel: Town Crier og DECO. Artiklen indeholder en beskrivelse af arbejdsprincipperne for begge orakler samt en detaljeret sammenligning. <\/p>\n

<\/p>\n

Town Crier<\/h1>\n

<\/p>\n

Town Crier (TC) blev pr\u00e6senteret af IC3 (Initiative for CryptoCurrencies and Contracts) i 2016 p\u00e5 CCS'16. Den grundl\u00e6ggende id\u00e9 med TC er at overf\u00f8re information fra et website til smartkontrakten og sikre sig, at den information, der leveres af TC, er identisk med den, der er p\u00e5 websitet. TC anvender TEE (Trusted Execution Environment) til datagennemsigtighed. I den originale version beskrives brugen af Intel SGX.
\nTown Crier best\u00e5r af en del inden for blockchain og en del inden i operation systemet selv \u2013 TC Server.
\n\"Town
\nTC Contract ligger i blockchain og fungerer som front-end for TC. Den modtager foresp\u00f8rgsler fra CU (brugerens smartkontrakt) og returnerer svar fra TC Server. Inden i TC Server findes Relay, som etablerer forbindelsen mellem enclaven og internettet (tovejs trafik) og forbinder enclaven med blockchain. Enclaven indeholder progencl, som er koden, der udf\u00f8rer foresp\u00f8rgsler fra blockchain og sender meddelelser tilbage til blockchain med digital signatur; progencl indeholder en del af koden fra smartkontrakten og udf\u00f8rer hovedsagelig nogle af dens funktioner. <\/p>\n

<\/p>\n

Intel SGX-enclaven kan betragtes som et generelt bibliotek med API, der fungerer via ecall. Ecall overf\u00f8rer kontrol til enclaven. Enclaven k\u00f8rer sin kode, indtil den er f\u00e6rdig eller indtil der opst\u00e5r en undtagelse. For at kalde funktioner, der er defineret uden for enclaven, anvendes ocall. Ocall udf\u00f8res uden for enclaven og behandles som et usikkert kald. Efter udf\u00f8relsen af ocall returneres kontrollen til enclaven.
\n\"Town
\nI Enclave-konfigurationen oprettes der en sikker forbindelse til webserveren, hvor selve enclave'en udf\u00f8rer TLS handshake med den m\u00e5lserver og udf\u00f8rer alle kryptografiske operationer internt. TLS-biblioteket (mbedTLS) og HTTP-koden er forkortet og eksporteret til SGX-milj\u00f8et. Desuden indeholder Enclave root CA-certifikater (en samling af certifikater) for at verificere certifikater fra fjerntliggende servere. Request Handler modtager en datagramforesp\u00f8rgsel i det format, som Ethereum leverer, dekrypterer det og analyserer det. Derefter genereres en Ethereum-transaktion, der indeholder den \u00f8nskede datagram, den signeres med skTC og sendes til Relay.<\/p>\n

<\/p>\n

Relay-delen inkluderer Client Interface, TCP, Blockchain Interface. Client Interface er n\u00f8dvendig for at attestere enclave-koden og kommunikationen med klienten. Klienten sender en foresp\u00f8rgsel om attestering via ecall og modtager et tidsstempel, der er signeret med skTC sammen med att (attestationssignatur), hvorefter att bekr\u00e6ftes ved hj\u00e6lp af Intel Attestation Service (IAS), og tidsstemplet kontrolleres af en betroet tidsservice. Blockchain Interface kontrollerer indkommende foresp\u00f8rgsler og placerer transaktioner i blockchain for levering af datagrammer. Geth er den officielle Ethereum-klient og giver Relay mulighed for at interagere med blockchain via RPC-kald. <\/p>\n

<\/p>\n

N\u00e5r man arbejder med TEE, giver TC mulighed for at starte flere enclaves parallelt, hvilket \u00f8ger hastigheden p\u00e5 databehandlingen med 3 gange. Hvis hastigheden med \u00e9n aktiv enclave var 15 tx\/sek, stiger hastigheden til 65 tx\/sek med 20 parallelt k\u00f8rte enclaves, til sammenligning er den maksimale hastighed for Bitcoin-blockchain 26 tx\/sek.<\/p>\n

<\/p>\n

DECO<\/h1>\n

<\/p>\n

DECO (Decentralized Oracles for TLS) blev pr\u00e6senteret p\u00e5 CCS\u201920, og det fungerer med sider, der underst\u00f8tter TLS-forbindelse. Det sikrer fortrolighed og integritet af data.
\nDECO med TLS anvender symmetrisk kryptering, s\u00e5 b\u00e5de klienten og webserveren har krypteringsn\u00f8gler, og klienten kan, hvis den \u00f8nsker, forfalske TLS-sessiondata. For at l\u00f8se dette problem bruger DECO en treparts h\u00e5ndtrykprotokol mellem prover (smartkontrakt), verifier (oracle) og webserver (datakilde).<\/p>\n

<\/p>\n

\"Town<\/p>\n

<\/p>\n

DECO's arbejdsprincip er, at verificatoren (prover) f\u00e5r en del data D og bekr\u00e6fter over for verificatoren (verifier), at D stammer fra TLS-serveren S. Et andet problem er, at TLS ikke signerer data, og det er sv\u00e6rt for TLS-klienten at bevise, at dataene er modtaget fra netop den server (provenance difficulty). <\/p>\n

<\/p>\n

I protokollen DECO benyttes krypteringsn\u00f8glerne KEnc og KMac. Klienten sender en anmodning Q til webserveren<\/a>, svaret fra serveren R kommer i krypteret form, men klienten og serveren ejer de samme KMac, og klienten kan forfalske TLS-besked. L\u00f8sningen fra DECO er at \"skjule\" KMac for klienten (prover), indtil han svarer p\u00e5 anmodningen. Nu er KMac delt mellem prover og verifier \u2014 KpMac og KvMac. Serveren f\u00e5r KMac til at kryptere svaret ved hj\u00e6lp af en operation p\u00e5 delene af n\u00f8glen KpMac \u2295 KvMac = KMac.<\/p>\n

<\/p>\n

N\u00e5r der er etableret en trevejs h\u00e5ndtryk, vil dataudvekslingen mellem klienten og serveren finde sted med sikkerhedsgaranti.
\n\"Town
\nN\u00e5r man taler om et system af decentraliserede orakler, kan man ikke undlade at n\u00e6vne Chainlink, som str\u00e6ber efter at skabe et decentraliseret netv\u00e6rk af orakel-noder, kompatibelt med Ethereum, Bitcoin og Hyperledger, med hensyn til modularitet: hver del af systemet kan opdateres. For at sikre sikkerhed tilbyder Chainlink hver orakel, der deltager i opgaven, at udstede en kombination af n\u00f8gler (offentlig og privat). Den private n\u00f8gle bruges til at generere en delvis signatur, der indeholder deres l\u00f8sning p\u00e5 anmodningen om data. For at f\u00e5 et svar kr\u00e6ves en sammenl\u00e6gning af alle dele af signaturerne fra netv\u00e6rkets orakler.<\/p>\n

<\/p>\n

Chainlink planl\u00e6gger at gennemf\u00f8re en indledende PoC DECO med fokus p\u00e5 decentraliserede finansapplikationer som Mixicles. P\u00e5 tidspunktet for skrivningen blev der offentliggjort en nyhed p\u00e5 Forbes om, at Chainlink har k\u00f8bt DECO fra Cornell University.<\/p>\n

<\/p>\n

Angreb p\u00e5 orakler<\/h1>\n

<\/p>\n

\"Town<\/p>\n

<\/p>\n

Set fra et informationssikkerhedsperspektiv er f\u00f8lgende angreb p\u00e5 Town Crier blevet overvejet:<\/p>\n

<\/p>\n

    \n
  1. \n

    Rogue smart-contract kodeinjektion p\u00e5 TEE noder.
    \nEssensen af angrebet: transmission af falsk smart-contract kode til TEE, s\u00e5ledes at en angriber, der f\u00e5r adgang til noden, vil have mulighed for at udf\u00f8re sin egen (svindel) smart-contract p\u00e5 dekrypterede data. Ikke desto mindre vil de returnerede v\u00e6rdier v\u00e6re krypteret med den private n\u00f8gle, og den eneste m\u00e5de at f\u00e5 adgang til s\u00e5danne data p\u00e5 er, hvis den krypterede tekst l\u00e6kkes under returneringen\/udtr\u00e6kningen.
    \nBeskyttelse mod dette angreb best\u00e5r i at kontrollere at koden p\u00e5 den nuv\u00e6rende adresse er korrekt verificeret af enclaven. Dette kan opn\u00e5s med en adresseringsskema, hvor kontraktens adresse bestemmes ved hj\u00e6lp af hashing af kontraktens kode. <\/p>\n

    \n<\/li>\n

  2. \n

    Contract state ciphertext changes leak.
    \nAngrebs essens: Ejere af noder, hvor smarte kontrakter udf\u00f8res, har adgang til contract state i krypteret form uden for enclave. En angriber, der opn\u00e5r kontrol over en node, kan sammenligne contract state f\u00f8r og efter udf\u00f8relsen af en transaktion og kan bestemme, hvilke argumenter der blev indsendt, og hvilken specifik metode der blev brugt i den smarte kontrakt, da selve koden for den smarte kontrakt og dens tekniske specifikationer er offentligt tilg\u00e6ngelige.
    \nBeskyttelse af node selv for at sikre p\u00e5lidelighed.<\/p>\n

    \n<\/li>\n

  3. \n

    Sidekanalangreb.
    \nEn s\u00e6rlig type angreb, der bruger overv\u00e5gning af adgang til hukommelse og cache af enclave i forskellige scenarier. Et eksempel p\u00e5 et s\u00e5dant angreb er Prime and Probe.
    \n\"Town
    \nForl\u00f8bet af angrebet:<\/p>\n

    <\/p>\n