Tänapäeval pole keegi, kes ei oleks rääkinud plokiahela tehnoloogiast, krüptovaluutadest ja nende ülimusest. Kuid see artikkel ei kiida heaks seda tehnoloogiat, vaid käsitleb just selle puudusi ja võimalusi nende lahendamiseks.

Ükskõik millise projekti kallal töötades ettevõttes Altirix Systems, seisime silmitsi vajadusega kaitstud ja tsensuuri-kindlat kinnitust välisest plokiahela allikast. Tuli kinnitada muudatused kolmanda süsteemi kirjetes ja nende põhjal täita süsteemi nutilepingute loogikas erinevat haru. Esmapilgul näib ülesanne üsna triviaalne, kuid kui selle täitmise tulemus mõjutab ühe osalise finantsseisundit, tekivad täiendavad nõudmised. Kõigepealt on vajalik põhjalik usaldus sellise valideerimise mehhanismi vastu. Kuid kõigest järk-järgult.

Probleem on selles, et plokiahel on iseseisev, suletud objekt, seetõttu ei tea plokiahela sees olevad nutilepingud midagi välistest tingimustest. Samuti on nutilepingute tingimused sageli seotud tegelike asjadega (nt lennu hilinemine, valuutakurss jne). Nutilepingute korrektseks toimimiseks peab plokiahelast väljapoole saadud teave olema usaldusväärne ja kontrollitud. See probleem lahendatakse sellega, et kasutatakse orakleid, nagu Town Crier ja DECO. Need oraklid võimaldavad nutilepingul plokiahelas usaldada teavet usaldusväärselt veebiserverilt, mida võib pidada usaldusväärse teabe pakkujaks.

Oraklid

Kujutage ette, et nutileping viib teie bitcoin-rahakotile üle 0,001 btc, kui teie lemmik jalgpalliklubi võidab Venemaa karika. Kui võit on tõene, peab nutileping saama teavet selle kohta, milline klubi võitis, ja siin tekib mitu probleemi: kust saada see teave, kuidas see turvaliselt nutilepingusse edastada ning kuidas veenduda, et nutilepingusse saabunud teave vastab tõele?

Teabeallika allika kohta võib olla kaks stsenaariumi: nutileping ühendatakse usaldusväärse veebisaidiga, kus keskelt hallatakse mängutulemuste kohta teavet, või ühendatakse kohe mitu saiti, et seejärel valida teavet enamiku samade andmeid pakkuvate allikate hulgast. Teabe täpsuse kontrollimiseks kasutatakse oraakleid, näiteks Oraclize, mis kasutab TLSNotary't (TLS modifikatsioon andmete autentimise tõendamiseks). Kuid Oraclize kohta on Google'is piisavalt teavet ning Habr's on mitu artiklit; täna räägin oraaklitest, mis kasutavad veidi teistsugust lähenemist teabe edastamiseks: Town Crier ja DECO. Artiklis on kirjeldatud mõlema oraakli tööpõhimõtteid ning koos põhjaliku võrdluse.

Town Crier

Town Crier (TC) esitati IC3 (The Initiative for CryptoCurrencies and Contracts) 2016. aastal CCS’16 konverentsil. TC põhieesmärk on edastada teavet veebisaidilt nutilepingule ja veenduda, et TC edastatud informatsioon on sama, mis veebisaidil. TC kasutab andmete autentsuse tagamiseks TEE (Trusted Execution Environment). Algversioonis on TC kirjeldatud koostööd Intel SGX-iga.
Town Crier koosneb osast, mis on blockchainis, ja osast, mis asub operatsioonisüsteemis — TC Server.

TC leping asub blockchainis ja toimib TC esidena. See võtab vastu päringud CU-lt (kasutaja nutileping) ja tagastab vastuse TC Serverilt. TC Serveris on Relay, mis loob sideme anklaviga internetivõrgus (kahepoolne liiklus) ja seob anklavi blockchainiga. Anklav sisaldab progencl-i, mis on kood, mis täidab päringud blockchainist ja tagastab sõnumid blockchaini koos digitaalse allkirjaga; progencl sisaldab osa nutilepingu koodist ja täidab põhimõtteliselt osa selle funktsioonidest.

Intel SGX enclave võib pidada üldiseks teegiks, millel on API, mis töötab ecall'i kaudu. Ecall edastab kontrolli enclave'ile. Enclave täidab oma koodi, kuni see lõpetatakse või kuni tekib erand. Funktsioonide väljakutseteks, mis on määratletud väljaspool enclave'i, kasutatakse ocall'i. Ocall viiakse läbi enclave'i välispoolselt ja töödeldakse seal kui ebausaldusväärset kutset. Pärast ocall'i täitmist tagastatakse kontroll enclave'ile.

Enclave'is toimub turvakanali seadistamine veebiserveriga, enclave ise teostab TLS handshake'i sihtserveriga ja viib kõik krüptograafilised toimingud läbi enda sees. TLS teek (mbedTLS) ja HTTP-kood on lühendatud versioonis eksporditud SGX keskkonda. Samuti sisaldab enclave root CA sertifikaate (sertifikaatide kogum) kaugserverite sertifikaatide kontrollimiseks. Request Handler võtab vastu datagrammi päringu Ethereum'i pakutavas formaadis, dekrüpteerib selle ja analüüsib. Seejärel genereeritakse Ethereum'i tehing, mis sisaldab nõutud datagrammi, allkirjastatakse see skTC abil ja edastatakse Relay'le.

Relay osa sisaldab Klientide Liidest, TCP-d ja Plokiahela Liidest. Klientide Liides on vajalik anklavikoodide atesteerimiseks ja kliendiga suhtlemiseks. Klient saadab atesteerimissoovi ecall'i kaudu ning saab skTC poolt allkirjastatud ajatempleid koos att (atesteeringu allkiri) - seejärel kinnitatakse att Intel Attestation Service (IAS) kaudu ja ajatempli usaldusväärsust kontrollib usaldusväärne ajateenistus. Plokiahela Liides kontrollib sissetulevaid päringuid ja salvestab tehingud plokiahelasse datagrammide edastamiseks. Geth on ametlik Ethereum'i klient, mis võimaldab Relay'l plokiahelaga suhelda RPC-kutsungite kaudu.

TEE töötamisel võimaldab TC käivitada mitmeid anklave korraga, suurendades seeläbi info töötlemise kiirus kolm korda. Kui ühe töötava anklaviga oli kiirus 15 tx/sek, siis 20 paralleelselt töötava anklaviga tõuseb kiirus 65 tx/sek, võrdluseks Bitcoin'i plokiahela maksimaalne kiirus on 26 tx/sek.

DECO

DECO (Decentralized Oracles for TLS) esitati CCS’20-l, töötab veebilehtedel, mis toetavad TLS ühendust. Tagab andmete konfidentsiaalsuse ja terviklikkuse.
DECO c TLS kasutab sümmeetrilist krüptimist, mistõttu kliendil ja veebiserveril on krüpteerimisvõtmed ning klient võib soovi korral TSL sessiooni andmeid valeandmetega petta. Selle probleemi lahendamiseks kasutab DECO kolmekülgset käepigistuse protokolli prover (nutileping), verifier (oraakel) ja veebiserver (andmeallikas).

DECO tööpõhimõte seisneb selles, et kontrollija (prover) saab osa andmetest D ja kinnitab valideerijale (verifier), et D on saadud TLS-serverilt S. Veel üks probleem on see, et TLS ei allkirjasta andmeid ning TLS-klientidel on keeruline tõestada, et andmed on saadud just sellelt serverilt (provenance difficulty).

DECO protokollis kasutatakse krüpteerimisvõtmeid KEnc ja KMac. Klient saadab päringu Q veebiserver, serverist saabuv vastus R tuleb krüpteeritud kujul, kuid nii kliendil kui serveril on samad KMac, ja klient võib TLS sõnumit petta. DECO lahendus seisneb KMac 'peitmises' kliendi (prover) eest, kuni ta vastab päringule. Nüüd on KMac jagatud prover'i ja verifier'i vahel — KpMac ja KvMac. Server saab KMac vastuse krüpteerimiseks, kasutades võtmeosade operatsiooni KpMac ⊕ KvMac = KMac.

Kolmepoolse käepigistuse seadistamisel toimub andmevahetus kliendi ja serveri vahel garanteeritud turvalisusega.

Rääkides detsentraliseeritud oraklite süsteemist, ei saa mainimata jätta Chainlinki, mille eesmärk on luua detsentraliseeritud oraklite sõlmede võrk, mis on ühilduv Ethereumiga, Bitcoiniga ja Hyperledgeriga, arvestades modularsust: iga osa süsteemist saab uuendada. Samuti, et tagada turvalisus, pakub Chainlink igale ülesandes osalevale oraklile võtmete (avatud ja suletud) kombinatsiooni väljastamist. Suletud võtit kasutatakse osalise allkirja genereerimiseks, mis sisaldab nende lahendust andmete taotlusele. Vastuse saamiseks on vajalik kõikide võrgus olevate oraklite osaliste allkirjade ühendamine.

Chainlink plaanib teostada esialgse PoC DECO, keskendudes detsentraliseeritud finantss rakendustele, nagu Mixicles. Artikli kirjutamise hetkel ilmus Forbesis uudis, et Chainlink omandas DECO Cornell Universitylt.

Rünnakud oraklitele

Infoturbe seisukohalt on käsitletud järgmisi rünnakuid Town Crierile:

1. Pahaloomulise nutika lepingu koodi sisestamine TEE sõlmedesse.
   Rünnaku olemus: vale nutilepingukoodi edastamine TEE-sse, võimaldades seega ründajal, kes on saanud juurdepääsu sõlmele, käivitada oma (petlik) nutilepingud dekodeeritud andmete jaoks. Tagastatavad väärtused aga krüpteeritakse privaatvõtmega, ja ainus juurdepääs nendele andmetele on krüpteeritud teksti lekke kaudu tagastamisel/väljastamisel.
   Kaitse selle rünnaku eest seisneb selles, et kontrolleks anklav koodi õigsust, mis asub praeguses aadressis. Seda saab saavutada aadressindusskeemi abil, kus lepinguaadress määratakse lepingukoodi hashimise teel.

2. Lepinguriigi salakoodide muutused lekitavad.
   Rünnaku olemus: sõlmed, kus nutilepingud töötavad, pääsevad ligi lepinguriigile krüpteeritud kujul väljaspool anklavit. Ründaja, kes saab sõlmest juhtimise, saab võrrelda lepinguriiki enne ja pärast tehingut ning tuvastada, milliseid argumente esitati ja millist nutilepingute meetodit kasutati, kuna nutilepingukood ja selle tehnilised spetsifikatsioonid on üldiselt kergesti kättesaadavad.
   Usaldusväärsuse tagamise kaitse nodi.

3. Külgkanali rünnakud.
   Eri tüüpi rünnakud, mis kasutavad juurdepääsu jälgimist mälu ja vahemälu kaudu enklaavi erinevates stsenaariumites. Üks näide sellisest rünnakust on Prime and Probe.
   
   Rünnaku läbiviimise järjestus:

   • t0: Ründaja täidab kõik kahjustatud protsessi andmete vahemälu.
   • t1: Ohver täidab koodi, mille mälu juurdepääs sõltub ohvri konfidentsiaalsetest andmetest (krüptograafilised võtmed). Vahemälu rida valitakse keybit'i väärtuse alusel. Näites on keybit = 0 ja aadress X on loetud vahemälu reas 2. Xis hoitud andmed laaditakse vahemälu, asendades seal varem olnud andmed.
   • t2: Ründaja kontrollib, millised tema vahemälu read on asendatud — read, mida ohver kasutas. Seda tehakse juurdepääsuaja mõõtmisega. Korrates seda tegevust iga keybit'i jaoks, saab ründaja kogu võtme.

Kaitse rünnaku eest: Intel SGX-s on kaitse külgkanali rünnakute vastu, mis takistab vahemälu seonduvate sündmuste jälgimist, kuid rünnak Prime and Probe läbib ikkagi, kuna ründaja jälgib oma protsessi vahemälu sündmusi ja jagab vahemälu ohvriga.

Seega pole praegu selle rünnaku vastu tõhusat kaitset.

On teada ka Spectre ja Foreshadow (L1TF) rünnakud, mis on sarnased Prime and Probe'ile. Need võimaldavad andmete lugemist vahemälust kõrvalkanali kaudu. Spectre-v2 haavatavuse eest on olemas kaitse, mis kaitseb ka kahe eespool nimetatud rünnaku eest.

DECO puhul annab kolmeosalise käepigistuse turvalisuse garandi:

1. Prover Integrity: häkitud prover ei saa vale teavet serveri päritolu kohta valevärbamise kaudu, samuti ei saa ta sundida serverit aktsepteerima kehtetuid päringuid või vastama õigesti kehtetele päringutele. See on teostatav päringute mallide kaudu serveri ja prover'i vahel.
2. Verifier Integrity: häkitud verifier ei saa sundida proverit saama vale vastuseid.
3. Privaatsus: häkitud verifier uurib ainult avalikku teavet (päring, serveri nimi).

DECO-s on võimalikud ainult rünnakud, mis on seotud liikluse sissetoomisega. Algselt, kolmeosalise käepigistuse ajal võib verifier serveri identiteedi kindlaks teha värskendatud nonce'i abil. Küll aga peab verifier pärast käepigistust toetuma võrgu tasandi indikaatoritele.IP-aadressid). Seega peab verifier ja server vaheline ühendus olema kaitstud liikluse sisestamise eest. See saavutatakse Proxy kasutamisega.

Oracle'ide võrdlemine

Town Crier põhineb töötlusel serveripoolse enclave'i kaudu, samas kui DECO võimaldab andmete päritolu autentimist kolmiköövõtmise ja krüpteerimise abil krüptograafiliste võtmete kaudu. Oracle'ide andmete võrdlemine toimus järgmiste kriteeriumide alusel: töökiirus, turvalisus, hind ja kasulikkus.

Town Crier
DECO

töökiirus
Kiirem (0.6s lõppeda)
Aeglasem (10.50s protokolli lõpetamiseks)

turvalisus
Mugavam
Turvalisem

hind
Kallim
Odavam

kasulikkus
Nõuab spetsiaalset riistvara
Töötleb igat serverit, mis toetab TLS-i

Töökiirus: DECO tööks on vajalik kolmik-käepigistus, LAN-i kaudu seadistamisel kestab see 0,37 sekundi. Pärast ühenduse loomist on tõhus 2PC-HMAC (0,13 s kirjutamiseks). DECO jõudlus sõltub TLS-i krüptograafilistest komplektidest, isikuandmete suurusest ja tõendusmaterjali keerukusest konkreetse rakenduse jaoks. Näiteks IC3 binaarsete optsioonide rakenduse puhul kestab protokolli lõpuleviimine LAN-i kaudu umbes 10,50 s. Võrdluseks, Town Crier vajab sarnase rakenduse täitmiseks umbes 0,6 sekundit, mis on umbes 20 korda kiiremini kui DECO. Samadel tingimustel on TC kiirem.

Ohutus: Intel SGX klastrite rünnakud (külgkanali rünnakud) toimivad ja võivad tekitada tõelist kahju nutilepingute osalistele. DECO-ga on võimalikud rünnakud, mis on seotud liikluse sissetoomisega, kuid proxy kasutamine kõrvaldab sellised rünnakud. Seega on DECO turvalisem.

Hind: Intel SGX-iga töötavat seadmete maksumus ületab DECO protokolli seadistamise maksumuse. Seetõttu on TC kallim.

Praktilisus: Town Crieri kasutamiseks on vajalik spetsiaalne riistvara, mis toetab TEE-d. Näiteks toetavad Intel SGX 6. põlvkonna ja uuemate Intel Core'i protsessorite pered. DECO seevastu võimaldab töötamist igasuguste seadmetega, kuigi DECO-l on TEE kasutamiseks kohandatud seadistus. DECO kolmeosalise käepigistuse seadistusprotsess võib võtta aega, kuid see ei saa võrreldagi TC riistvara piirangutega, mistõttu on DECO praktilisem.

Kokkuvõte

Vaadates kahte oraklit eraldi ja võrreldes neid nelja kriteeriumi põhjal, on selge, et Town Crier jääb DECO-le alla kolmes neljast punktist. DECO on usaldusväärsem teabe turvalisuse osas, odavam ja praktilisem, kuigi kolmeosalise protokolli seadistamine võib võtta aega ja sellega on seotud mõned miinused, näiteks täiendavad šifreerimise võtmega seotud toimingud. TC töötab kiiremini kui DECO, kuid side-channel attack'iga seotud haavatavus muudab selle konfidentsiaalsuse kadumise riski alla. Tuleb arvestada, et DECO esitati jaanuaris 2020 ja pole veel piisavalt aega möödunud, et pidada seda ohutuks. Town Crier on juba 4 aastat olnud rünnakute all ja on läbinud mitmeid kontrolle, mistõttu on selle kasutamine paljudes projektides põhjendatud.

Allikas: habr.com