Dnes už jen lenoch nenapsal o technologii blockchain, kryptoměnách a jak úžasná to je. Ale v tomto článku nebude chválení této technologie, bude se hovořit o jejích nedostatcích a způsobech jejich odstranění.
Během práce na jednom z projektů ve společnosti Altirix Systems vznikl úkol pro bezpečné, cenzuře odolné potvrzení dat z externího zdroje pro blockchain. Bylo třeba potvrzovat změny v záznamech třetího systému a na základě těchto změn provádět určitou logiku ve smart kontraktu. Úkol se na první pohled zdál poměrně triviální, ale když od výsledku jeho provedení závisí finanční stav jedné ze stran účastníků procesu, vyvstávají další požadavky. Především to je komplexní důvěra k takovému validačnímu mechanismu. Ale vše po pořádku.
Problém spočívá v tom, že blockchain je sám o sobě autonomním, uzavřeným objektem, takže smart kontrakty uvnitř blockchainu nic nevědí o vnějším světě. Zároveň jsou podmínky smart kontraktů často spojeny s informacemi o reálných událostech (zpoždění letu, kurz měn atd.). Pro správnou funkci smart kontraktů musí být informace získané z vnějšku blockchainu spolehlivé a ověřené. Tento problém se řeší využitím orákul, jako jsou Town Crier a DECO. Tyto orákuly umožňují smart kontraktu v blockchainové síti důvěřovat informacím z ověřeného webového serveru, lze říci, že to jsou poskytovatelé spolehlivých informací.
Orákuly
Představte si, že smart kontrakt posílá 0.001 btc na vaši bitcoinovou peněženku v případě vítězství vašeho oblíbeného fotbalového klubu v Ruském poháru. V případě skutečného vítězství je nutné smart kontraktu předat informaci o tom, který klub vyhrál, a zde nastává řada problémů: odkud vzít tuto informaci, jak ji bezpečně předat do smart kontraktu a jak se ujistit, že informace, které do smart kontraktu přicházejí, skutečně odpovídají realitě?
V otázce informačního zdroje mohou existovat 2 scénáře: připojení chytrého kontraktu k důvěryhodné webové stránce, na které jsou centralizovaně uloženy informace o výsledcích zápasů, a druhou možností je připojit několik webů a pak vybírat informace podle většiny zdrojů, které poskytují stejné údaje. Aby se zajistila správnost informací, používají se orákula, například Oraclize, které využívá TLSNotary (modifikace TLS pro prokázání pravosti dat). O Oraclize je dostatek informací na Googlu a na Habru je několik článků, dnes však budu hovořit o orákulech, které používají poněkud jiný přístup k přenosu informací: Town Crier a DECO. Článek popisuje principy fungování obou orákulů a také podrobné srovnání.
Town Crier
Town Crier (TC) byl představen IC3 (The Initiative for CryptoCurrencies and Contracts) v roce 2016 na CCS’16. Hlavní myšlenka TC je: předat informace z webové stránky chytrému kontraktu a ujistit se, že informace, které TC dodává, jsou shodné s těmi na webové stránce. TC využívá TEE (Trusted Execution Environment) pro pravost vlastnictví dat. V původní verzi TC je popsána práce s Intel SGX.
Town Crier se skládá z části uvnitř blockchainu a části v samotném operačním systému - TC Server.
TC Contract je umístěn v blockchainu a funguje jako front end pro TC. Přijímá žádosti od CU (chytrý kontrakt uživatele) a vrací odpověď od TC Serveru. Uvnitř TC Serveru se nachází Relay, který navazuje spojení enclavy s internetovou sítí (obousměrný provoz) a spojuje enclavu s blockchainem. Enclave obsahuje progencl, což je kód, který vykonává žádosti z blockchainu a vrací zprávy do blockchainu s digitálním podpisem, progencl obsahuje část kódu chytrého kontraktu a v podstatě vykonává některé z jeho funkcí.
Enclave Intel SGX lze považovat za obecnou knihovnu s API, která funguje prostřednictvím ecall. Ecall přenáší řízení do enclavy. Enclave vykonává svůj kód, dokud nedokončí, nebo dokud nedojde k výjimce. Pro volání funkcí definovaných mimo enclavu se používají ocall. Ocall se vykonává mimo enclavu a je zpracováván jako nespolehlivý volání. Po provedení ocall se řízení vrací do enclavy.
V části Enclave se nastavuje zabezpečený kanál s webovým serverem, přičemž Enclave sám provádí TLS handshake s cílovým serverem a provádí všechny kryptografické operace uvnitř sebe. Knihovna TLS (mbedTLS) a HTTP kód v zjednodušené podobě jsou exportovány do prostředí SGX. Dále Enclave obsahuje certifikáty root CA (sbírku certifikátů), aby ověřoval certifikáty vzdálených serverů. Request Handler přijímá požadavek datagramu ve formátu poskytovaném Ethereum, dešifruje jej a analyzuje. Poté generuje transakci Ethereum, která obsahuje požadovaný datagram, podepisuje ji pomocí skTC a předává ji do Relay.
Část Relay zahrnuje Client Interface, TCP, Blockchain Interface. Client Interface je potřebný pro attestaci kódu Enclave a spojení s klientem. Klient odesílá požadavek na attestaci pomocí ecall a získává časovou značku podepsanou skTC spolu s att (podpis attestace), následně je att potvrzena prostřednictvím Intel Attestation Service (IAS) a časová značka je ověřena důvěryhodnou časovou službou. Blockchain Interface ověřuje příchozí požadavky a umisťuje transakce do blockchainu pro doručení datagramů. Geth je oficiální klient Ethereum a umožňuje Relay interagovat s blockchainem přes RPC volání.
Při práci s TEE umožňuje TC spustit současně několik Enclave paralelně, čímž se zvyšuje rychlost zpracování informací třikrát. Pokud byla rychlost s jedním spuštěným Enclave 15 tx/sec, pak při 20 paralelně spuštěných Enclave se rychlost zvyšuje na 65 tx/sec; pro srovnání, maximální rychlost práce v blockchainu Bitcoin je 26 tx/sec.
DECO
DECO (Decentralized Oracles for TLS) byl představen na CCS’20 a funguje se stránkami, které podporují TLS spojení. Zajišťuje důvěrnost a integritu dat.
DECO c TLS používá symetrické šifrování, což znamená, že klient a webový server mají šifrovací klíče, a klient může, pokud si přeje, podvrhnout data relace TLS. K řešení tohoto problému DECO používá třístranný handshake protokol mezi prover (chytrý kontrakt), verifier (oracle) a webovým serverem (zdroj dat).
Princip fungování DECO spočívá v tom, že prover získá část dat D a potvrdí verifierovi, že D bylo přijato od TLS serveru S. Další problém spočívá v tom, že TLS nepodepisuje data a TLS klientovi je obtížné prokázat, že data byla získána právě z toho serveru (problém s prokázáním původu).
V protokolu DECO se používají šifrovací klíče KEnc a KMac. Klient odešle žádost Q na webový server, odpověď od serveru R přichází zašifrovaná, ale klient a server mají stejné KMac, takže klient může podvrhnout TLS zprávu. Řešením DECO je "ukrýt" KMac od klienta (prover), dokud nereaguje na žádost. Nyní je KMac rozdělen mezi prover a verifier — KpMac a KvMac. Server získá KMac pro šifrování odpovědi pomocí operace nad částmi klíče KpMac ⊕ KvMac = KMac.
Nastavením třístranného handshake bude výměna dat mezi klientem a serverem provedena s garantovanou bezpečností.
Pokud jde o systém decentralizovaných orákulů, nelze opomenout Chainlink, který se snaží vytvořit decentralizovanou síť uzlů orákulů kompatibilní s Ethereum, Bitcoin a Hyperledger, s ohledem na modularitu: každá část systému může být aktualizována. K zajištění bezpečnosti Chainlink navrhuje každému orákulu, které se účastní úkolu, vygenerovat kombinaci klíčů (veřejný a soukromý). Soukromý klíč se používá k vygenerování částečného podpisu, který obsahuje jejich řešení na žádost o data. Pro získání odpovědi je nezbytné sloučení všech částečných podpisů orákulů v síti.
Chainlink plánuje provést počáteční PoC DECO zaměřený na decentralizované finanční aplikace jako Mixicles. V době psaní tohoto článku se objevila zpráva na Forbes, že Chainlink získala DECO od Cornell University.
Útoky na orákuly
Z pohledu informační bezpečnosti byly zváženy následující útoky na Town Crier:
Vložení zlovolného kódu do smluv na uzlech TEE.
Podstatou útoku je zaslání záměrně nesprávného kódu smart kontraktu do TEE, čímž útočník, který získal přístup k uzlu, získá možnost provádět svůj (podvodný) smart kontrakt na dešifrovaných datech. Nicméně vrácené hodnoty budou zašifrovány pomocí soukromého klíče a jedinou možností přístupu k takovým datům je únik zašifrovaného textu při vrácení/výstupu.
Ochrana proti tomuto útoku spočívá v ověření správnosti kódu v aktuální adrese enclavem. Toho lze dosáhnout pomocí adresního schématu, kde je adresa kontraktu určena hashováním kódu kontraktu.Změny ciphertextu stavu kontraktu unikají.
Podstata útoku: Vlastníci uzlů, na kterých běží chytré smlouvy, mají přístup k stavu smlouvy v zašifrované podobě mimo enclavu. Útočník, který získá kontrolu nad uzlem, může porovnávat stav smlouvy před a po provedení transakce a může určit, jaké argumenty byly předloženy a jaká metoda chytré smlouvy byla použita, protože samotný kód chytré smlouvy a její technické specifikace jsou veřejně dostupné.
Ochrana při zajištění spolehlivosti samotného uzlu.Útoky bočního kanálu.
Speciální typ útoků, které využívají monitorování přístupu k paměti a cache enclavy v různých scénářích. Příkladem takového útoku je Prime and Probe.
Postup při provádění útoku:- t0: Útočník vyplní celou cache dat procesu oběti.
- t1: Oběť vykonává kód s přístupy do paměti, které závisí na důvěrných údajích oběti (kryptografické klíče). Výběr cache line se provádí podle hodnoty keybit. V příkladu na obrázku, keybit = 0 a byla přečtena adresa X v cache line 2. Data uložená v X se načtou do cache, a nahradí data, která tam byla předtím.
- t2: Útočník kontroluje, které z jeho cache řádků byly vytěsněny — řádky, které používá oběť. To se provádí měřením doby přístupu. Opakováním této operace pro každý keybit útočník získá celý klíč.
Ochrana před útokem: V Intel SGX existuje ochrana proti útokům bočního kanálu, která zakazuje monitorování událostí souvisejících s cache, přesto však útok Prime and Probe projde, protože útočník sleduje události ve své cache a sdílí cache s obětí.
V současné době tedy neexistuje spolehlivá ochrana proti tomuto útoku.
Existují také útoky typu Spectre a Foreshadow (L1TF), které jsou podobné Prime and Probe. Tyto útoky umožňují čtení dat z cache paměti prostřednictvím bočního kanálu. Existuje ochrana proti zranitelnosti Spectre-v2, která funguje proti těmto dvěma útokům.
Ve vztahu k DECO zajišťuje třístranné handshake bezpečnostní záruky:
- Prover Integrity: Zlomený prover nemůže falšovat informace o původu serveru a nemůže server přinutit přijímat neplatné požadavky nebo špatně odpovídat na platné požadavky. To je realizovatelné prostřednictvím vzorců požadavků mezi serverem a proverem.
- Verifier Integrity: Zlomený verifier nemůže donutit proveder, aby získal nesprávné odpovědi.
- Ochrana soukromí: Napadený verifier zkoumá pouze veřejně dostupné informace (dotaz, název serveru).
V DECO jsou možné pouze zranitelnosti spojené s injekcí provozu. Zpočátku, při trojstranném handshaku může verifier ověřit identitu serveru pomocí nového nonce. Nicméně po handshake musí verifier spoléhat na úrovňové ukazatele sítě (IP adres). Takže spojení mezi verifierem a serverem musí být chráněno proti injekci provozu. To se dosahuje používáním Proxy.
Srovnání oracle
Town Crier se zakládá na práci s enclave na serverové straně, DECO však umožňuje provádět autentizaci původu dat pomocí trojstranného handshaku a šifrování dat kryptografickými klíči. Srovnání dat oracle probíhalo podle následujících kritérií: výkon, bezpečnost, náklady a praktičnost.
Town Crier
DECO
výkon
Rychlejší (0,6 s na dokončení)
Pomalější (10,50 s na dokončení protokolu)
bezpečnost
Méně bezpečný
Více bezpečný
cena
Dražší
Levnější
praktičnost
Vyžaduje speciální hardware
Funguje s jakýmkoli serverem, který podporuje TLS
Výkon: Pro práci s DECO je potřeba nastavení trojstranného handshaku, při nastavení přes LAN to trvá 0,37 sekundy, pro interakci po navázání spojení je efektivní 2PC-HMAC (0,13 s na zápis). Výkon DECO závisí na dostupných sadách šifrování TLS, velikosti citlivých údajů a složitosti důkazů pro konkrétní aplikaci. Na příkladu aplikace binárních opcí od IC3: dokončení protokolu přes LAN trvá přibližně 10,50 s. Pro srovnání, Town Crier potřebuje pro provedení podobné aplikace přibližně 0,6 sekundy, což je asi 20krát rychlejší než DECO. Za stejných podmínek bude TC rychlejší.
Bezpečnost: Útoky na enclave Intel SGX (side-channel attacks) fungují a mohou způsobit skutečné škody účastníkům smart kontraktu. Co se týče DECO, jsou možné útoky spojené s injekcí provozu, ale použití proxy tyto útoky nulifikuje. Proto je DECO bezpečnější.
Náklady: Náklady na hardware podporující práci s Intel SGX jsou vyšší než náklady na nastavení protokolu v DECO. Proto je TC dražší.
Praktičnost: Pro práci s Town Crier je nezbytné speciální zařízení, které podporuje TEE. Například Intel SGX je podporován na procesorech rodiny Intel Core 6. generace a novějších. DECO umožňuje práci s jakýmkoli zařízením, i když existuje nastavení DECO s využitím TEE. Proces nastavení trojstranného handshake u DECO může chvíli trvat, ale to se nedá srovnávat s omezením hardwaru pro TC, proto je DECO praktičtější.
Závěr
Při zvažování dvou oracle odděleně a jejich porovnáním podle čtyř kritérií je evidentní, že Town Crier zaostává za DECO ve třech ze čtyř bodů. DECO je spolehlivější z pohledu informační bezpečnosti, levnější a praktičtější, ačkoli nastavení trojstranného protokolu může nějakou dobu trvat a má své nevýhody, například další operace s šifrovacími klíči. TC funguje rychleji než DECO, ale zranitelnost spojená s útoky pomocí bočních kanálů ho vystavuje riziku ztráty soukromí. Je třeba vzít v úvahu, že DECO byl představen v lednu 2020 a stále neuplynula dostatečná doba, abychom mohli považovat jeho bezpečnost za zaručenou. Town Crier byl již 4 roky vystaven útokům a prošel mnoha testy, takže jeho použití v mnoha projektech je oprávněné.
Zdroj: habr.com
