Dnes už lenivý nepísal o technológii blockchain, kryptomenách a ako sú úžasné. Ale v tomto článku nebude ospevovanie tejto technológie, skôr sa budeme zaoberať jej nedostatkami a spôsobmi ich odstránenia.
Počas práce na jednom z projektov v spoločnosti Altirix Systems sa objavila úloha zabezpečeného, cenzúre odolného potvrdenia údajov z externého zdroja pre blockchain. Bolo potrebné potvrdzovať zmeny v záznamoch tretej strany a na základe týchto zmien vykonávať určité smerovanie v logike smart kontraktu. Úloha sa na prvý pohľad zdala dosť triviálna, ale keď od výsledku závisí finančná situácia jednej zo strán zapojených do procesu, objavujú sa dodatočné požiadavky. Predovšetkým je to celkové dôveryhodnosť takéhoto mechanizmu validácie. Ale poďme poriadne.
Problém spočíva v tom, že blockchain je sám osebe autonómny, uzavretý objekt, takže smart kontrakty v rámci blockchainu nič nevedia o vonkajšom svete. Zároveň sú podmienky smart kontraktov často viazané na informácie o reálnych udalostiach (meškanie letu, kurz meny a pod.). Pre správnu funkciu smart kontraktov musí byť informácia získaná zvonka blockchainu spoľahlivá a overená. Tento problém sa rieši pomocou oracle, ako sú Town Crier a DECO. Tieto oracle umožňujú smart kontraktu v sieťach blockchainu dôverovať informáciám z overeného webového servera, môžeme povedať, že sú to dodávatelia dôveryhodných informácií.
Oracle
Predstavte si, že smart kontrakt vykonáva prevod 0.001 btc na vašu bitcoinovú peňaženku v prípade víťazstva vášho obľúbeného futbalového klubu v pohári Ruska. V prípade skutočného víťazstva musí smart kontraktu poskytnúť informácie o tom, ktorý klub vyhral, a tu sa objavuje niekoľko problémov: kde získať tieto informácie, ako ich bezpečne preniesť do smart kontraktu a ako sa uistiť, že informácia, ktorú dostal smart kontrakt, skutočne zodpovedá realite?
V otázke zdroja informácií môžu existovať dva scenáre: pripojenie smart kontraktu k dôveryhodnej webovej stránke, na ktorej je centralizovane uložená informácia o výsledkoch zápasov, a druhá možnosť — pripojiť niekoľko stránok a potom robiť výber informácií z väčšiny zdrojov poskytujúcich rovnaké údaje. Na overenie správnosti informácií sa používajú orákuly, ako napríklad Oraclize, ktorý využíva TLSNotary (modifikáciu TLS na preukázanie pravosti dát). O Oraclize je dostatok informácií na Googli a na Habré sú niektoré články; dnes však hovorím o orákulách, ktoré používajú trochu iný prístup k prenášaniu informácií: Town Crier a DECO. V článku je opísaná práca oboch orákulov a podrobné porovnanie.
Town Crier
Town Crier (TC) bol predstavený IC3 (Iniciatíva pre kryptomenu a kontrakty) v roku 2016 na CCS’16. Hlavná myšlienka TC: preniesť informácie z webovej stránky na smart kontrakt a uistiť sa, že informácia doručená TC je rovnaká, ako na webovej stránke. TC využíva TEE (Dôveryhodné výpočtové prostredie) na autentifikáciu vlastníctva dát. V pôvodnej verzii TC je popísaná práca s Intel SGX.
Town Crier pozostáva z časti v rámci blockchainu a časti v rámci samotného operačného systému — TC Server.
TC kontrakt sa nachádza v blockchain a funguje ako frontend pre TC. Prijíma požiadavky od CU (smart kontrakt užívateľa) a vracia odpoveď od TC Servera. Vnútri TC Servera sa nachádza Relay, ktorý zabezpečuje spojenie enklávy s internetovou sieťou (obojstranný prenos) a spája enklávu s blockchainom. Enkláva obsahuje progencl, čo je kód, ktorý vykonáva požiadavky z blockchainu a vracia správy do blockchainu s digitálnym podpisom; progencl obsahuje časť kódu smart kontraktu a v podstate vykonáva niektoré z jeho funkcií.
Enklávu Intel SGX je možné považovať za spoločnú knižnicu s API, ktorá funguje prostredníctvom ecall. Ecall predáva riadenie enkláve. Enkláva vykonáva svoj kód, kým sa neskončí alebo kým sa nevyskytne výnimka. Na vyvolanie funkcií definovaných mimo enklávy sa používajú ocall. Ocall sa vykonáva mimo enklávy a spracováva sa ako nedôveryhodný príkaz. Po vykonaní ocall sa riadenie vracia späť k enkláve.
V časti Enclave dochádza k nastaveniu secure channel s webovým serverom, pričom enclave vykonáva TLS handshake s cieľovým serverom a vykonáva všetky kryptografické operácie vo vnútri seba. Knižnica TLS (mbedTLS) a HTTP-kód v zjednodušenom variante sú exportované do prostredia SGX. Enclave obsahuje aj root CA certifikáty (kolekcia certifikátov) na overovanie certifikátov vzdialených serverov. Request Handler prijíma dopyt datagram vo formáte dodávanom Ethereum, dešifruje ho a analyzuje. Následne generuje transakciu Ethereum, ktorá obsahuje requested datagram, podpisuje ju pomocou skTC a prenáša do Relay.
Časť Relay zahŕňa Client Interface, TCP a Blockchain Interface. Client Interface je potrebný na atestáciu kódu enclave a komunikáciu s klientom. Klient odosiela dopyt na atestáciu pomocou ecall a dostáva timestamp, podpísaný skTC spolu s att (podpis atestácie), ktorý je následne overený prostredníctvom Intel Attestation Service (IAS), a timestamp je kontrolovaný dôveryhodnou časovou službou. Blockchain Interface overuje prichádzajúce dopyty a umiestňuje transakcie do blockchainu na doručenie datagrams. Geth je oficiálny klient Ethereum a umožňuje Relay interagovať s blockchainom prostredníctvom RPC volaní.
Práca s TEE, TC umožňuje spustiť niekoľko enclave paralelne, čím sa zvyšuje rýchlosť spracovania informácií trikrát. Ak bola rýchlosť pri jednom bežiacom enclave 15 tx/sec, pri 20 paralelne spustených enclaves rýchlosť vzrastá na 65 tx/sec, pre porovnanie, maximálna rýchlosť práce v blockchainu Bitcoin je 26 tx/sec.
DECO
DECO (Decentralized Oracles for TLS) bol predstavený na CCS’20, pracuje so stránkami, ktoré podporujú TLS pripojenie. Zabezpečuje dôvernosť a integritu dát.
DECO s TLS používa symetrické šifrovanie, čím majú klient a webový server šifrovacie kľúče, a klient, ak si bude želať, môže sfalšovať údaje relácie TLS. Na vyriešenie tohto problému DECO používa trojcestný protokol handshake medzi prover (smart kontrakt), verifier (oracle) a web-server (zdroj dát).
Princíp fungovania DECO spočíva v tom, aby prover získal časť dát D a potvrdil verifikátorovi (verifier), že D pochádza z TLS-servera S. Ďalším problémom je, že TLS nepodpisuje dáta a TLS-klientovi je ťažké dokázať, že dáta boli získané práve z toho servera (provenance difficulty).
V protokole DECO sa používajú šifrovacie kľúče KEnc a KMac. Klient posiela požiadavku Q na web server, odpoveď zo servera R prichádza v zašifrovanej podobe, ale klient a server majú rovnaké KMac, a klient môže falšovať správy TLS. Riešenie DECO spočíva v tom, že "skryje" KMac pred klientom (prover), kým neodpovie na požiadavku. Teraz je KMac rozdelený medzi prover a verifier — KpMac a KvMac. Server dostáva KMac na šifrovanie odpovede pomocou operácie s časťami kľúča KpMac ⊕ KvMac = KMac.
Nastavením trojstranného handshake sa výmena údajov medzi klientom a serverom uskutoční s garantovanou bezpečnosťou.
Ak hovoríme o systéme decentralizovaných oracle, nemožno opomenúť Chainlink, ktorý sa snaží vytvoriť decentralizovanú sieť uzlov oracle kompatibilnú s Ethereum, Bitcoin a Hyperledger, pričom zohľadňuje modularitu: každá časť systému môže byť aktualizovaná. Na zabezpečenie bezpečnosti Chainlink ponúka každému oracle účastnícemu úlohy udeliť kombináciu kľúčov (verejný a súkromný). Súkromný kľúč slúži na generovanie čiastočného podpisu, ktorý obsahuje ich riešenie na požiadavku údajov. Na získanie odpovede je potrebné zlúčenie všetkých čiastkových podpisov oracle siete.
Chainlink plánuje uskutočniť počiatočný PoC DECO so zameraním na decentralizované finančné aplikácie, ako sú Mixicles. V čase písania článku sa objavila správa na Forbes, že Chainlink získal DECO od Cornell University.
Útoky na oracle
Z hľadiska informačnej bezpečnosti boli preskúmané nasledujúce útoky na Town Crier:
Vstrekovanie škodlivého kódu smart contractu do uzlov TEE.
Podstata útoku: prenesenie zjavne nesprávneho kódu smart contractu do TEE, takže útočník, ktorý získal prístup k uzlu, bude mať možnosť vykonať vlastný (podvodný) smart contract na dešifrované údaje. Napriek tomu hodnoty, ktoré sa vracajú, budú zašifrované pomocou súkromného kľúča a jedinou možnosťou prístupu k týmto údajom je únik zašifrovaného textu pri vrátení/vyvedení.
Ochrana proti tomuto útoku spočíva v overení správnosti kódu nachádzajúceho sa na aktuálnej adrese prostredníctvom enclava. To môže byť dosiahnuté pomocou schémy adresovania, kde adresa kontraktu je určená hashovaním kódu kontraktu.Zmeny šifrovaného stavu kontraktu unikajú.
Povaha útoku: Majitelé uzlů, na nichž jsou prováděny smart kontrakty, mají přístup k stavu kontraktu v zašifrované podobě mimo enclave. Útočník, který získá kontrolu nad uzlem, může porovnat stav kontraktu před a po transakci a může zjistit, jaké argumenty byly uvedeny a který konkrétní metod smart kontraktu byl použit, protože samotný kód smart kontraktu a jeho technické specifikace jsou veřejně dostupné.
Ochrana pro zajištění spolehlivosti samotného uzlu.Útoky prostřednictvím bočního kanálu.
Zvláštní typ útoků využívající sledování přístupu k paměti a keši enclave v různých scénářích. Příkladem takového útoku je Prime and Probe.
Postup provedení útoku:- t0: Útočník zaplní celý cache dat procesu oběti.
- t1: Oběť vykonává kód s přístupy k paměti, které závisí na důvěrných údajích oběti (kryptografické klíče). Výběr cache line probíhá podle hodnoty keybit. V příkladu na obrázku, keybit = 0 a byl přečten adresa X v cache line 2. Data uložená v X jsou načtena do cache, vytlačující data, která tam byla předtím.
- t2: Útočník kontroluje, které z jeho řádků cache byly vytlačeny — řádky používané obětí. To se provádí měřením času přístupu. Opakováním této operace pro každý z keybitů útočník získá celý klíč.
Ochrana proti útoku: V Intel SGX existuje ochrana proti útokům prostřednictvím bočního kanálu, která zakazuje sledování událostí spojených s keší, ale útok Prime and Probe přesto projde, protože útočník sleduje události ve vlastní cache procesu a sdílí cache s obětí.
Tím pádem v současnosti neexistuje spolehlivá ochrana proti tomuto útoku.
Jsou známé také útoky typu Spectre a Foreshadow (L1TF), které jsou podobné Prime and Probe. Umožňují číst data z cache paměti prostřednictvím bočního kanálu. Je zajištěna ochrana proti zranitelnosti Spectre-v2, která funguje proti těmto dvěma útokům.
Pokud jde o DECO, trojstranné handshake poskytuje záruku bezpečnosti:
- Prover Integrity: Zlomený prover nemůže falšovat informace o původu serveru a nemůže donutit server přijímat neplatné požadavky nebo nesprávně odpovídat na platné požadavky. To je realizovatelné prostřednictvím vzorů požadavků mezi serverem a proverem.
- Verifier Integrity: Zlomený verifier nemůže donutit prover získávat nesprávné odpovědi.
- Ochrana osobných údajov: Hacked verifier skúma iba verejne dostupné informácie (požiadavka, názov servera).
V DECO sú možné iba zraniteľnosti súvisiace s injekciou prevádzky. Na začiatku, počas trojstranného handshake, môže verifier potvrdiť identitu servera pomocou fresh nonce. Avšak po handshake musí verifier spoliahnuť na indikátory na úrovni siete (IP adresy). Týmto spôsobom musí byť spojenie medzi verifierom a serverom chránené pred injekciou prevádzky. To sa dosahuje použitím Proxy.
Porovnávanie oracle
Town Crier je založený na práci s enclávom na strane servera, zatiaľ čo DECO umožňuje overenie pravosti údajov prostredníctvom trojstranného handshake a šifrovania údajov kryptografickými kľúčmi. Porovnanie údajov oracle sa vykonalo na základe nasledujúcich kritérií: výkon, bezpečnosť, cena a praktickosť.
Town Crier
DECO
výkon
Rýchlejší (0,6s na dokončenie)
Pomalší (10,50s na dokončenie protokolu)
bezpečnosť
Menej bezpečný
Viac bezpečný
cena
Drahší
Lacnejší
praktickosť
Vyžaduje špeciálny hardware
Funguje so všetkými servermi, ktoré podporujú TLS
Výkon: Na prácu s DECO je potrebné nastavenie trojstranného handshake, pri nastavení cez LAN to trvá 0,37 sekundy, pre interakciu po nadviazaní spojenia je efektívny 2PC-HMAC (0,13 s na zápis). Výkon DECO závisí od dostupných súborov šifier TLS, veľkosti osobných údajov a zložitosti dôkazu pre konkrétnu aplikáciu. Na príklade aplikácie binárneho opcia od IC3: dokončenie protokolu cez LAN trvá asi 10,50 s. Pre porovnanie, Town Crier vyžaduje na vykonanie podobnej aplikácie asi 0,6 sekundy, teda asi 20-krát rýchlejšie ako DECO. Za rovnakých podmienok, TC bude rýchlejší.
Bezpečnosť: Útoky na Intel SGX encláv (bočné kanálové útoky) fungujú a môžu spôsobiť skutočné škody účastníkom smart kontraktu. V prípade DECO sú možné útoky súvisiace s injekciou prevádzky, ale použitie proxy tieto útoky minimalizuje. Preto je DECO bezpečnejší.
Cena: Náklady na vybavenie, ktoré podporuje prácu s Intel SGX, sú vyššie ako náklady na nastavenie protokolu v DECO. Preto je TC drahší.
Praktickosť: Na prácu s Town Crier je potrebný špeciálny hardware, ktorý podporuje TEE. Napríklad, Intel SGX je podporovaný na procesoroch rodiny Intel Core 6. generácie a novších. DECO naopak umožňuje pracovať s akýmkoľvek hardwarom, hoci existuje nastavenie DECO, ktoré využíva TEE. Proces nastavenia trojstranného handshake u DECO môže trvať určitý čas, ale to sa nedá porovnať s obmedzením hardwaru pre TC, takže DECO je praktickejší.
Záver
Pri posudzovaní dvoch orákulov samostatne a ich porovnávaní podľa štyroch kritérií je zrejmé, že Town Crier zaostáva za DECO v troch z piatich bodov. DECO je bezpečnejší z hľadiska informačnej bezpečnosti, lacnejší a praktickejší, hoci nastavenie trojstranného protokolu môže trvať istý čas a má svoje nevýhody, ako sú dodatočné operácie s šifrovacími kľúčmi. TC je rýchlejší ako DECO, ale zraniteľnosť spojená so side-channel attack ho vystavuje riziku straty dôvernosti. Je potrebné zohľadniť, že DECO bol predstavený v januári 2020, a ešte neprešlo dostatok času na to, aby sa dalo považovať za bezpečný. Town Crier je už 4 roky vystavený útokom a prešiel množstvom overení, takže jeho použitie v mnohých projektoch je odôvodnené.
Zdroj: habr.com
