{"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\/pl\/blog\/administrirovanie\/town-crier-vs-deco-kakoj-orakul-ispolzovat-v-blokchejne","title":{"rendered":"Town Crier vs DECO: kt\u00f3ry oracle wybra\u0107 w blockchainie?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Dzi\u015b tylko leniwy nie pisa\u0142 o technologii blockchain, kryptowalutach i o tym, jak niesamowite to jest. Jednak w tym artykule nie b\u0119dzie wychwalania tej technologii, lecz om\u00f3wi\u0119 jej wady i sposoby ich rozwi\u0105zania. <\/p>\n

<\/p>\n

\"Town<\/p>\n

<\/p>\n

Podczas pracy nad jednym z projekt\u00f3w w firmie Altirix Systems pojawi\u0142o si\u0119 zadanie dotycz\u0105ce zabezpieczonego, cenzuroodpornego potwierdzenia danych z zewn\u0119trznego \u017ar\u00f3d\u0142a do blockchaina. Nale\u017ca\u0142o potwierdza\u0107 zmiany w zapisach trzeciego systemu i na ich podstawie realizowa\u0107 r\u00f3\u017cne \u015bcie\u017cki w logice inteligentnego kontraktu. Zadanie na pierwszy rzut oka wydaje si\u0119 do\u015b\u0107 trywialne, ale gdy od wyniku jego realizacji zale\u017cy sytuacja finansowa jednej ze stron zaanga\u017cowanych w proces, pojawiaj\u0105 si\u0119 dodatkowe wymagania. Przede wszystkim jest to wszechstronne zaufanie do tego rodzaju mechanizmu walidacji. Ale wszystko po kolei. <\/p>\n

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

Problem polega na tym, \u017ce blockchain sam w sobie jest autonomicznym, zamkni\u0119tym obiektem, dlatego inteligentne kontrakty w ramach blockchaina nic nie wiedz\u0105 o zewn\u0119trznym \u015bwiecie. Jednocze\u015bnie warunki inteligentnych kontrakt\u00f3w cz\u0119sto s\u0105 zwi\u0105zane z informacjami o rzeczywistych zjawiskach (op\u00f3\u017anienia lot\u00f3w, kurs walut itp.). Aby inteligentne kontrakty dzia\u0142a\u0142y prawid\u0142owo, informacje uzyskane z zewn\u0105trz blockchaina musz\u0105 by\u0107 wiarygodne i zweryfikowane. Problem ten rozwi\u0105zuje si\u0119 poprzez wykorzystanie orakli, takich jak Town Crier i DECO. Te orakle pozwalaj\u0105 inteligentnym kontraktom w sieci blockchain ufa\u0107 informacjom z zaufanego serwera internetowego, mo\u017cna powiedzie\u0107, \u017ce to dostawcy wiarygodnych informacji. <\/p>\n

<\/p>\n

Orakle<\/h1>\n

<\/p>\n

Wyobra\u017a sobie, \u017ce inteligentny kontrakt dokonuje przelewu 0.001 btc na tw\u00f3j portfel bitcoinowy w przypadku zwyci\u0119stwa twojego ulubionego klubu pi\u0142karskiego w Pucharze Rosji. W przypadku rzeczywistego zwyci\u0119stwa do inteligentnego kontraktu nale\u017cy przes\u0142a\u0107 informacj\u0119 o tym, kt\u00f3ry klub wygra\u0142, a pojawia si\u0119 szereg problem\u00f3w: sk\u0105d wzi\u0105\u0107 t\u0119 informacj\u0119, jak bezpiecznie przes\u0142a\u0107 j\u0105 do inteligentnego kontraktu i jak upewni\u0107 si\u0119, \u017ce informacja przekazana do inteligentnego kontraktu faktycznie odpowiada rzeczywisto\u015bci? <\/p>\n

<\/p>\n

W kwestii \u017ar\u00f3d\u0142a informacji mog\u0105 istnie\u0107 dwa scenariusze: pod\u0142\u0105czenie smart kontraktu do zaufanej strony internetowej, na kt\u00f3rej centralnie przechowywane s\u0105 informacje o wynikach mecz\u00f3w, oraz drugi wariant \u2014 pod\u0142\u0105czenie kilku stron i nast\u0119pnie dokonanie selekcji informacji z wi\u0119kszo\u015bci \u017ar\u00f3de\u0142, kt\u00f3re dostarczaj\u0105 te same dane. W celu potwierdzenia prawid\u0142owo\u015bci informacji wykorzystuje si\u0119 orakule, na przyk\u0142ad Oraclize, korzystaj\u0105cy z TLSNotary (Modyfikacja TLS do udowodnienia autentyczno\u015bci danych). Jednak w Google jest wystarczaj\u0105co du\u017co informacji na temat Oraclize, a na Habrze znajduje si\u0119 kilka artyku\u0142\u00f3w; ja dzisiaj opowiem o orakulach, kt\u00f3re stosuj\u0105 nieco inne podej\u015bcie do przekazywania informacji: Town Crier i DECO. W artykule przedstawiono zasady dzia\u0142ania obu orakuli, a tak\u017ce szczeg\u00f3\u0142owe por\u00f3wnanie. <\/p>\n

<\/p>\n

Town Crier<\/h1>\n

<\/p>\n

Town Crier (TC) zosta\u0142 zaprezentowany przez IC3 (Inicjatywa na rzecz Kryptowalut i Um\u00f3w) w 2016 roku na CCS\u201916. G\u0142\u00f3wna idea TC: przekaza\u0107 informacje ze strony internetowej do smart kontraktu i upewni\u0107 si\u0119, \u017ce informacje dostarczone przez TC s\u0105 takie same jak te na stronie internetowej. TC wykorzystuje TEE (Trusted Execution Environment) dla autentyczno\u015bci w\u0142asno\u015bci danych. W oryginalnej wersji opisano prac\u0119 z Intel SGX.
\nTown Crier sk\u0142ada si\u0119 z cz\u0119\u015bci wewn\u0105trz blockchaina i cz\u0119\u015bci w samej OS \u2014 TC Server.
\n\"Town
\nKontrakt TC znajduje si\u0119 w blockchainie i dzia\u0142a jako front end dla TC. Przyjmuje \u017c\u0105dania od CU (smart kontrakt u\u017cytkownika) i zwraca odpowied\u017a od TC Server. Wewn\u0105trz TC Server znajduje si\u0119 Relay, kt\u00f3ry nawi\u0105zuje \u0142\u0105czno\u015b\u0107 z internetem (dwukierunkowy ruch) i \u0142\u0105czy enclave z blockchainem. Enclave zawiera progencl, kt\u00f3ry jest kodem wykonuj\u0105cym zapytania z blockchaina i zwracaj\u0105cym wiadomo\u015bci do blockchaina z cyfrowym podpisem; progencl zawiera cz\u0119\u015b\u0107 kodu smart kontraktu i w zasadzie wykonuje niekt\u00f3re z jego funkcji. <\/p>\n

<\/p>\n

Enclave Intel SGX mo\u017cna traktowa\u0107 jako og\u00f3ln\u0105 bibliotek\u0119 z API, dzia\u0142aj\u0105c\u0105 przez ecall. Ecall przekazuje kontrol\u0119 do enclave. Enclave wykonuje sw\u00f3j kod, a\u017c do jego zako\u0144czenia lub pojawienia si\u0119 wyj\u0105tku. Do wywo\u0142ywania funkcji zdefiniowanych poza enclave, u\u017cywa si\u0119 ocall. Ocall jest wykonywane poza enclave i traktowane przez ni\u0105 jako niebezpieczne wywo\u0142anie. Po zako\u0144czeniu ocall kontrola wraca do enclave.
\n\"Town
\nW cz\u0119\u015bci Enclave nast\u0119puje konfiguracja secure channel z serwerem WWW, a sam enclave wykonuje handshake TLS z docelowym serwerem i przeprowadza wszystkie operacje kryptograficzne w swoim wn\u0119trzu. Biblioteka TLS (mbedTLS) oraz kod HTTP w zmniejszonej wersji s\u0105 eksportowane do \u015brodowiska SGX. Ponadto Enclave zawiera certyfikaty root CA (zbi\u00f3r certyfikat\u00f3w), aby weryfikowa\u0107 certyfikaty zdalnych serwer\u00f3w. Request Handler przyjmuje \u017c\u0105danie datagramu w formacie dostarczanym przez Ethereum, odszyfrowuje je i analizuje. Nast\u0119pnie generuje transakcj\u0119 Ethereum zawieraj\u0105c\u0105 requested datagram, podpisuje j\u0105 za pomoc\u0105 skTC i przekazuje do Relay.<\/p>\n

<\/p>\n

Cz\u0119\u015b\u0107 Relay obejmuje interfejs klienta, TCP, interfejs blockchain. Interfejs klienta jest potrzebny do atestacji kodu enclave i komunikacji z klientem. Klient wysy\u0142a \u017c\u0105danie atestacji za pomoc\u0105 ecall i otrzymuje timestamp, podpisany skTC, razem z att (podpis atestacji), kt\u00f3ry nast\u0119pnie jest potwierdzany przez Intel Attestation Service (IAS), a timestamp weryfikowany przez zaufan\u0105 us\u0142ug\u0119 time service. Interfejs blockchain sprawdza nadchodz\u0105ce \u017c\u0105dania i umieszcza transakcje w blockchainie w celu dostarczenia datagram\u00f3w. Geth to oficjalny klient Ethereum, kt\u00f3ry pozwala Relay na interakcj\u0119 z blockchainem za po\u015brednictwem wywo\u0142a\u0144 RPC. <\/p>\n

<\/p>\n

Pracuj\u0105c z TEE, TC pozwala uruchomi\u0107 jednocze\u015bnie kilka enclave, zwi\u0119kszaj\u0105c w ten spos\u00f3b szybko\u015b\u0107 przetwarzania informacji trzykrotnie. Je\u015bli z jedn\u0105 dzia\u0142aj\u0105c\u0105 enclave pr\u0119dko\u015b\u0107 wynosi\u0142a 15 tx\/sec, to przy 20 r\u00f3wnolegle uruchomionych enclave pr\u0119dko\u015b\u0107 wzrasta do 65 tx\/sec, dla por\u00f3wnania, maksymalna pr\u0119dko\u015b\u0107 pracy w blockchainie Bitcoin wynosi 26 tx\/sec.<\/p>\n

<\/p>\n

DECO<\/h1>\n

<\/p>\n

DECO (Decentralized Oracles for TLS) zosta\u0142 zaprezentowany na CCS\u201920, dzia\u0142a z witrynami, kt\u00f3re obs\u0142uguj\u0105 po\u0142\u0105czenia TLS. Zapewnia poufno\u015b\u0107 i integralno\u015b\u0107 danych.
\nDECO z TLS wykorzystuje szyfrowanie symetryczne, dzi\u0119ki czemu klient i serwer WWW maj\u0105 klucze szyfrowania, a klient, je\u015bli chce, mo\u017ce podrobi\u0107 dane sesji TLS. Aby rozwi\u0105za\u0107 ten problem, DECO stosuje tr\u00f3jnasty protok\u00f3\u0142 handshake mi\u0119dzy prover (smart contract), verifier (oracle) i web-server (\u017ar\u00f3d\u0142o danych).<\/p>\n

<\/p>\n

\"Town<\/p>\n

<\/p>\n

Zasada dzia\u0142ania DECO polega na tym, \u017ce weryfikator (prover) uzyskuje cz\u0119\u015b\u0107 danych D i potwierdza weryfikatorowi (verifier), \u017ce D pochodzi od serwera TLS S. Innym problemem jest to, \u017ce TLS nie podpisuje danych, a klientowi TLS trudno jest udowodni\u0107, \u017ce dane zosta\u0142y uzyskane dok\u0142adnie z tego serwera (trudno\u015b\u0107 w udowodnieniu pochodzenia). <\/p>\n

<\/p>\n

W protokole DECO u\u017cywane s\u0105 klucze szyfrowania KEnc i KMac. Klient wysy\u0142a zapytanie Q do serwer www<\/a>, odpowied\u017a od serwera R przychodzi w zaszyfrowanej formie, ale klient i serwer maj\u0105 te same KMac, wi\u0119c klient mo\u017ce sfa\u0142szowa\u0107 wiadomo\u015b\u0107 TLS. Rozwi\u0105zanie DECO polega na tym, aby \"ukry\u0107\" KMac przed klientem (prover), a\u017c odpowie na zapytanie. Teraz KMac jest podzielony mi\u0119dzy prover a verifier \u2014 KpMac i KvMac. Serwer otrzymuje KMac do szyfrowania odpowiedzi poprzez operacj\u0119 na cz\u0119\u015bciach klucza KpMac \u2295 KvMac = KMac.<\/p>\n

<\/p>\n

Po skonfigurowaniu tr\u00f3jstronnej procedury uzgadniania, wymiana danych mi\u0119dzy klientem a serwerem b\u0119dzie przeprowadzona z zapewnieniem bezpiecze\u0144stwa.
\n\"Town
\nM\u00f3wi\u0105c o systemie zdecentralizowanych orakli, nie mo\u017cna pomin\u0105\u0107 Chainlink, kt\u00f3ry d\u0105\u017cy do stworzenia zdecentralizowanej sieci w\u0119z\u0142\u00f3w orakli, kompatybilnej z Ethereum, Bitcoin i Hyperledger, z uwzgl\u0119dnieniem modu\u0142owo\u015bci: ka\u017cda cz\u0119\u015b\u0107 systemu mo\u017ce by\u0107 aktualizowana. Aby zapewni\u0107 bezpiecze\u0144stwo, Chainlink oferuje ka\u017cdemu oraklowi bior\u0105cemu udzia\u0142 w zadaniu wydanie kombinacji kluczy (publicznego i prywatnego). Klucz prywatny jest wykorzystywany do generowania cz\u0119\u015bciowego podpisu, kt\u00f3ry zawiera ich rozwi\u0105zanie na zapytanie o dane. Aby uzyska\u0107 odpowied\u017a, konieczne jest po\u0142\u0105czenie wszystkich cz\u0119\u015bciowych podpis\u00f3w orakli sieci.<\/p>\n

<\/p>\n

Chainlink planuje przeprowadzi\u0107 wst\u0119pny PoC DECO z naciskiem na zdecentralizowane aplikacje finansowe, takie jak Mixicles. W momencie pisania artyku\u0142u ukaza\u0142a si\u0119 wiadomo\u015b\u0107 na Forbes, \u017ce Chainlink naby\u0142 DECO z Uniwersytetu Cornella.<\/p>\n

<\/p>\n

Ataki na orakle<\/h1>\n

<\/p>\n

\"Town<\/p>\n

<\/p>\n

Z perspektywy bezpiecze\u0144stwa informacji rozwa\u017cono nast\u0119puj\u0105ce ataki na Town Crier:<\/p>\n

<\/p>\n

    \n
  1. \n

    Injectowanie z\u0142o\u015bliwego kodu smart-contract na w\u0119z\u0142ach TEE.
    \nIstota ataku: przes\u0142anie do TEE fa\u0142szywego kodu smart-contract, w ten spos\u00f3b, intruz, kt\u00f3ry uzyska\u0142 dost\u0119p do w\u0119z\u0142a, b\u0119dzie mia\u0142 mo\u017cliwo\u015b\u0107 wykonania w\u0142asnego (oszuka\u0144czego) smart-contract na odszyfrowanych danych. Niemniej jednak zwracane warto\u015bci b\u0119d\u0105 szyfrowane za pomoc\u0105 klucza prywatnego, a jedyn\u0105 mo\u017cliwo\u015bci\u0105 dost\u0119pu do takich danych jest wyciek szyfrowanego tekstu podczas zwrotu\/wyj\u015bcia.
    \nOchrona przed tym atakiem polega na weryfikacji przez enclave poprawno\u015bci kodu znajduj\u0105cego si\u0119 pod bie\u017c\u0105cym adresem. Mo\u017cna to osi\u0105gn\u0105\u0107 za pomoc\u0105 schematu adresowania, w kt\u00f3rym adres kontraktu jest okre\u015blany przez haszowanie kodu kontraktu. <\/p>\n

    \n<\/li>\n

  2. \n

    Zmiany w szyfrogramie stanu kontraktu ujawniaj\u0105 wycieki.
    \nIstota ataku: W\u0142a\u015bciciele w\u0119z\u0142\u00f3w, na kt\u00f3rych wykonywane s\u0105 inteligentne kontrakty, maj\u0105 dost\u0119p do stanu kontraktu w zaszyfrowanej formie poza enklaw\u0105. Haker, zdobywaj\u0105c kontrol\u0119 nad w\u0119z\u0142em, mo\u017ce por\u00f3wnywa\u0107 stan kontraktu przed i po wykonaniu transakcji oraz okre\u015bli\u0107, jakie argumenty zosta\u0142y wprowadzone i kt\u00f3ry konkretny metod inteligentnego kontraktu zosta\u0142 u\u017cyty, poniewa\u017c sam kod inteligentnego kontraktu i jego specyfikacje techniczne s\u0105 publicznie dost\u0119pne.
    \nOchrona w zapewnieniu niezawodno\u015bci samego w\u0119z\u0142a.<\/p>\n

    \n<\/li>\n

  3. \n

    Ataki kana\u0142\u00f3w bocznych.
    \nSzczeg\u00f3lny typ atak\u00f3w, wykorzystuj\u0105cy monitorowanie dost\u0119pu do pami\u0119ci i pami\u0119ci podr\u0119cznej enklawy w r\u00f3\u017cnych scenariuszach. Przyk\u0142adem takiego ataku jest Prime and Probe.
    \n\"Town
    \nProcedura przeprowadzenia ataku:<\/p>\n

    <\/p>\n