Dodnes jen líní nenapsali o blockchainové technologii, kryptoměnách a o tom, jak je to cool. V tomto článku ale nebude žádná chvála této technologie, bude jen o jejích nedostatcích a způsobech, jak je odstranit.
Při práci na jednom z projektů ve společnosti Altirix Systems vyvstal úkol bezpečného potvrzování dat ze zdroje mimo blockchain odolným vůči cenzuře. Bylo nutné potvrdit změny v záznamech třetího systému a na základě těchto změn provést jednu či druhou větev v logice smart kontraktů. Úkol je to na první pohled celkem triviální, ale když finanční situace jedné ze stran účastnících se procesu závisí na výsledku jeho realizace, objeví se další požadavky. Především je to komplexní důvěra v takový validační mechanismus. Ale nejdřív.
Problém je v tom, že samotný blockchain je autonomní, uzavřená entita, takže chytré kontrakty uvnitř blockchainu nevědí nic o vnějším světě. Podmínky smart kontraktů jsou přitom často spojeny s informacemi o reálných věcech (zpoždění letu, směnné kurzy atd.). Aby chytré smlouvy správně fungovaly, musí být informace získané mimo blockchain spolehlivé a ověřené. Tento problém je vyřešen pomocí věštců, jako je Town Crier a DECO. Tyto věštce umožňují inteligentní smlouvě v blockchainové síti důvěřovat informacím z důvěryhodného webového serveru, můžeme říci, že se jedná o spolehlivé poskytovatele informací.
Věštci
Představte si, že chytrý kontrakt převede 0.001 BTC do vaší bitcoinové peněženky, pokud váš oblíbený fotbalový klub vyhraje ruský pohár. V případě skutečného vítězství potřebuje smart kontrakt přenést informace o tom, který klub vyhrál, a zde nastává řada problémů: kde tyto informace získat, jak je bezpečně přenést do smart kontraktu a jak zajistit, aby informace získané v chytré smlouvě na skutečně odpovídají skutečnosti?
V problému se zdrojem informací mohou nastat 2 scénáře: připojení chytré smlouvy k důvěryhodnému webu, který centrálně ukládá informace o výsledcích zápasů, a druhou možností je propojit více webů najednou a následně vybrat informace z většiny zdroje, které poskytují stejná data. Aby se zajistilo, že informace jsou správné, používají se věštci, jako je Oraclize, který používá TLSNotary (TLS Modification to Prove Data Authenticity). Informací o Oraclize je ale na Googlu dost a o Habrém je několik článků, ale dnes budu mluvit o věštcích, které používají trochu jiný přístup k přenosu informací: Town Crier a DECO. Článek přináší popis principů fungování obou věštců a také podrobné srovnání.
Městský křikloun
Town Crier (TC) byl představen organizací IC3 (Iniciativa pro kryptoměny a smlouvy) v roce 2016 na CCS'16. Hlavní myšlenkou TC je předat informace z webu do chytré smlouvy a zajistit, aby informace poskytované TC byly stejné jako na webu. TC používá k ověření vlastnictví dat TEE (Trusted Execution Environment). Původní verze TC popisuje, jak pracovat s Intel SGX.
Town Crier se skládá z části uvnitř blockchainu a části uvnitř samotného OS – TC Server.
Smlouva TC je na blockchainu a funguje jako frontend pro TC. Přijímá požadavky z CU (User Smart Contract) a vrací odpověď z TC Serveru. Uvnitř serveru TC je relé, které připojuje enklávu k internetu (obousměrný provoz) a připojuje enklávu k blockchainu. Enclave obsahuje progencl, což je kód, který dělá požadavky z blockchainu a vrací zprávy digitálně podepsanému blockchainu, progencl obsahuje část kódu chytré smlouvy a ve skutečnosti vykonává některé z jeho funkcí.
Enklávu Intel SGX si lze představit jako sdílenou knihovnu s API běžícím přes ecal. Ecall přenáší kontrolu na enklávu. Enkláva provádí svůj kód, dokud se neskončí nebo dokud nenastane výjimka. Chcete-li volat funkce definované mimo enklávu, použijte ocall. Ocall běží mimo enklávu a enkláva s ním zachází jako s nedůvěryhodným hovorem. Po provedení hovoru se řízení vrátí do enklávy.
V části Enkláva je s webovým serverem konfigurován zabezpečený kanál, samotná enkláva provádí TLS handshake s cílovým serverem a provádí všechny kryptografické operace v sobě. Knihovna TLS (mbedTLS) a minifikovaná verze kódu HTTP byly exportovány do prostředí SGX. Enclave také obsahuje kořenové certifikáty CA (sbírka certifikátů) pro kontrolu certifikátů vzdálených serverů. Obsluha požadavku přijímá datagramový požadavek ve formátu poskytovaném Ethereem, dešifruje jej a analyzuje. Poté vygeneruje transakci Ethereum obsahující požadovaný datagram, podepíše jej pomocí skTC a odešle do Relay.
Část Relay zahrnuje klientské rozhraní, TCP, blockchain rozhraní. Klientské rozhraní je potřeba k ověření kódu enklávy a komunikaci s klientem. Klient odešle žádost o atest pomocí ecal a obdrží časové razítko podepsané skTC spolu s att (atestační podpis), poté je att ověřeno pomocí Intel Attestation Service (IAS) a časové razítko je ověřeno důvěryhodnou časovou službou. Blockchain Interface ověřuje příchozí požadavky a umísťuje transakce na blockchain, aby doručoval datagramy. Geth je oficiální Ethereum klient a umožňuje Relay komunikovat s blockchainem prostřednictvím RPC volání.
Při práci s TEE vám TC umožňuje provozovat několik enkláv paralelně, čímž se rychlost zpracování informací 3krát zvyšuje. Jestliže u jedné pracovní enklávy byla rychlost 15 tx/sec, pak u 20 paralelně běžících enkláv se rychlost zvyšuje na 65 tx/sec, pro srovnání, maximální rychlost v blockchainu Bitcoinu je 26 tx/sec.
DECO
DECO (Decentralized Oracles for TLS) byl představen na CCS'20 a spolupracuje s weby, které podporují připojení TLS. Zajišťuje důvěrnost a integritu dat.
DECO s TLS používají symetrické šifrování, takže klient a webový server mají šifrovací klíče a klient může falšovat data relace TLS, pokud chce. K vyřešení tohoto problému používá DECO třícestný protokol handshake mezi dokazovatelem (smart contract), ověřovatelem (oracle) a webovým serverem (zdroj dat).
DECO funguje tak, že ověřovatel obdrží část dat D a potvrdí ověřovateli, že D pochází ze serveru TLS S. Dalším problémem je, že TLS nepodepisuje data a pro klienta TLS je obtížné prokázat, že data byla přijata z tohoto serveru (obtížnost původu).
Protokol DECO používá šifrovací klíče KEnc a KMac. Klient odešle požadavek Q na webový server, odpověď ze serveru R je zašifrována, ale klient a server vlastní stejný KMac a klient může zfalšovat zprávu TLS. Řešením DECO je „skrýt“ KMac před klientem (proverem), dokud neodpoví na požadavek. Nyní je KMac rozdělen mezi ověřovatele a ověřovatele - KpMac a KvMac. Server obdrží KMac k zašifrování odpovědi pomocí operace KpMac ⊕ KvMac = KMac na částech klíče.
Nastavením třícestného handshake bude výměna dat mezi klientem a serverem provedena se zárukou bezpečnosti.
Když už mluvíme o decentralizovaném systému oracle, nelze nezmínit Chainlink, jehož cílem je vytvořit decentralizovanou síť uzlů oracle kompatibilních s Ethereem, Bitcoinem a Hyperledgerem, s ohledem na modularitu: každou část systému lze upgradovat. Zároveň pro zajištění bezpečnosti Chainlink nabízí každému orákulu účastnícímu se úkolu vydání kombinace klíčů (veřejného a soukromého). Soukromý klíč se používá ke generování částečného podpisu, který obsahuje jejich rozhodnutí vyžádat si data. Pro získání odpovědi je nutné zkombinovat všechny dílčí podpisy věštců sítě.
Chainlink plánuje počáteční PoC DECO se zaměřením na decentralizované finanční aplikace jako Mixicles. V době psaní tohoto článku byly na Forbesu zprávy, že Chainlink získal DECO od Cornell University.
útoky na orákula
Z hlediska bezpečnosti informací byly zvažovány následující útoky na Town Crier:
-
Nečestné vkládání kódu chytrého kontaktu do uzlů TEE.
Podstata útoku: zaslání vědomě nesprávného kódu smart kontraktu do TEE, takže útočník, který získal přístup k uzlu, bude moci provést svůj vlastní (podvodný) smart kontrakt na dešifrovaná data. Vrácené hodnoty však budou zašifrovány soukromým klíčem a jediný způsob, jak se k takovým datům dostat, je únik šifrovaného textu při návratu/výstupu.
Ochrana proti tomuto útoku spočívá v kontrole správnosti kódu umístěného na aktuální adrese enklávou. Toho lze dosáhnout pomocí schématu adresování, kde je adresa smlouvy určena hašováním kódu smlouvy. -
Únik změn šifrového textu smluvního stavu.
Podstata útoku: Vlastníci uzlů, na kterých se smart kontrakty provádějí, mají přístup ke stavu kontraktu v zašifrované podobě mimo enklávu. Útočník, který získal kontrolu nad uzlem, může porovnat stav kontaktu před a po transakci a může určit, které argumenty byly zadány a která metoda inteligentní smlouvy byla použita, protože samotný kód inteligentní smlouvy a jeho technické specifikace jsou veřejně dostupné.
Ochrana při zajišťování spolehlivosti samotného uzlu. -
Útoky postranním kanálem.
Speciální typ útoku, který využívá monitorování paměti enklávy a přístupu do mezipaměti v různých scénářích. Příkladem takového útoku je Prime a Probe.
Pořadí útoku:- t0: Útočník zaplní celou datovou mezipaměť procesu oběti.
- t1: Oběť spustí kód s přístupy do paměti, které závisí na citlivých datech oběti (kryptografických klíčích). Řádek mezipaměti je vybrán hodnotou klíčového bitu. V příkladu na obrázku je klíčový bit = 0 a načtete adresu X v řádku 2 mezipaměti. Data uložená v X se načtou do mezipaměti, čímž se nahradí data, která tam byla předtím.
- t2: Útočník zkontroluje, které z jeho cache linek byly vyřazeny - linky používané obětí. To se provádí měřením doby přístupu. Opakováním této operace pro každý z klíčových bitů útočník získá celý klíč.
Ochrana před útoky: Intel SGX má ochranu proti útokům z postranního kanálu, která zakazuje sledování událostí souvisejících s mezipamětí, ale útok Prime a Probe stále projde, protože útočník sleduje události mezipaměti svého procesu a sdílí mezipaměť s obětí.
V tuto chvíli tedy neexistuje spolehlivá ochrana proti tomuto útoku.
Známé jsou také útoky Spectre and Foreshadow (L1TF) podobné Prime a Probe. Umožňují vám číst data z mezipaměti prostřednictvím kanálu třetí strany. Je poskytována ochrana proti zranitelnosti Spectre-v2, která funguje proti těmto dvěma útokům.
Ve vztahu k DECO poskytuje třícestný handshake záruku bezpečnosti:
- Integrita ověřovatele: Narušený zkoušeč nemůže zfalšovat informace o původu serveru a nemůže způsobit, že server bude přijímat neplatné požadavky nebo nesprávně reagovat na platné požadavky. To se provádí prostřednictvím vzorů požadavků mezi serverem a dokazovatelem.
- Integrita ověřovatele: Napadený ověřovatel nemůže způsobit, že dokazatel dostane nesprávné odpovědi.
- Soukromí: Hacknutý ověřovatel zkoumá pouze veřejně dostupné informace (požadavek, název serveru).
V DECO jsou možné pouze zranitelnosti injektáže provozu. Za prvé, pomocí třístranného podání ruky může ověřovatel zjistit identitu serveru pomocí nového nonce. Po handshake se však ověřovatel musí spoléhat na indikátory síťové vrstvy (IP adresy). Komunikace mezi ověřovatelem a serverem tedy musí být chráněna před injekcí provozu. Toho je dosaženo pomocí proxy.
Srovnání věštců
Town Crier je založen na práci s enklávou v back-endu, zatímco DECO umožňuje ověřit původ dat pomocí třícestného handshake a šifrovat data pomocí kryptografických klíčů. Porovnání těchto věštců bylo provedeno podle následujících kritérií: rychlost, bezpečnost, cena a praktičnost.
Městský křikloun
DECO
výkon
Rychlejší (0.6 s do konce)
Pomalejší (10.50 s na dokončení protokolu)
zabezpečení
Méně bezpečné
Více zabezpečeno
náklady
Dražší
Levnější
praktičnost
Vyžaduje speciální hardware
Funguje s jakýmkoli serverem, který podporuje TLS
Rychlost výkonuA: DECO vyžaduje nastavení 0.37-cestného handshake, trvá 2 sekundy při nastavení přes LAN, 0,13PC-HMAC (3 s na zápis) je efektivní pro komunikaci po navázání spojení. Výkon DECO závisí na dostupných šifrovacích sadách TLS, velikosti soukromých dat a složitosti nátisků pro konkrétní aplikaci. Použití binární aplikace od IC10,50 jako příklad: dokončení protokolu přes LAN trvá asi 0,6 sekundy. Pro srovnání, Town Crier trvá přibližně 20 sekundy, než dokončí podobnou aplikaci, což je asi XNUMXkrát rychleji než DECO. Za stejných podmínek bude TC rychlejší.
zabezpečení: Útoky na enklávu Intel SGX (útoky postranním kanálem) fungují a mohou způsobit skutečné škody účastníkům inteligentní smlouvy. S ohledem na DECO jsou možné útoky injekce provozu, ale použití proxy takové útoky zruší. Proto je DECO bezpečnější.
Stát: Náklady na hardware, který podporuje práci s Intel SGX, jsou vyšší než náklady na konfiguraci protokolu v DECO. Proto je TC dražší.
Praktičnost: Pro práci s Town Crier je nutné speciální vybavení, které podporuje TEE. Například Intel SGX je podporován na procesorech rodiny Intel Core 6. generace a novějších. DECO vám umožňuje pracovat s jakýmkoli zařízením, i když existuje nastavení DECO pomocí TEE. Podle procesu nastavení může třícestný handshake DECO nějakou dobu trvat, ale to není nic ve srovnání s hardwarovým omezením pro TC, takže DECO je praktičtější.
Závěr
Když se podíváme na dvě věštce samostatně a porovnáme je podle čtyř kritérií, je jasné, že Town Crier je ve třech bodech ze čtyř horší než DECO. DECO je spolehlivější z hlediska zabezpečení informací, levnější a praktičtější, i když nastavení třícestného protokolu může nějakou dobu trvat a má své nevýhody, jako jsou dodatečné operace s šifrovacími klíči. TC je rychlejší než DECO, ale zranitelnost útoku na postranní kanál ho ohrožuje ztrátou soukromí. Mějte na paměti, že DECO bylo představeno v lednu 2020 a neuplynulo dost času na to, aby bylo považováno za bezpečné. Town Crier je napadán již 4 roky a prošel mnoha testy, takže jeho použití v mnoha projektech je oprávněné.
Zdroj: www.habr.com