Ma már csak az írástudatlanok nem beszéltek a blokklánc technológiáról, a kriptovalutákról és arról, hogy mennyire nagyszerű ez. De ebben a cikkben nem az említett technológia dicséretével foglalkozunk, hanem éppen ellenkezőleg, a hátrányairól és azok kiküszöbölésének módjairól lesz szó.

Az Altirix Systems egyik projektje során felmerült a feladat, hogy védett, cenzúraálló adatmegerősítést alkalmazzunk egy blokkláncon kívüli forrástól. Szükség volt a harmadik rendszerben történt változások megerősítésére, és ezek alapján valamilyen ágat kell végrehajtani a smart contract logikájában. A feladat elsőre eléggé triviálisnak tűnik, de amikor a teljesítmény eredménye egy folyamat egyik résztvevőjének pénzügyi helyzetét befolyásolja, további követelmények merülnek fel. Elsősorban a validálási mechanizmus iránti teljes körű bizalom szükséges. De kezdjük az elején.

A probléma abban rejlik, hogy a blokklánc önálló, zárt objektum, így a blokkláncon belüli okos szerződéseknek nincs tudomása a külvilágról. Ugyanakkor az okos szerződések feltételei gyakran valós dolgokra vonatkozó információkkal vannak összefüggésben (pl. járat késése, devizaárfolyam stb.). Az okos szerződések megfelelő működéséhez a blokkláncon kívül beszerzett információnak megbízhatónak és ellenőrzöttnek kell lennie. Ezt a problémát orákulumok, például a Town Crier és a DECO használatával oldják meg. Ezek az orákulumok lehetővé teszik, hogy a blokklánc hálózatában lévő okos szerződés megbízható webkiszolgálóról származó információkra bízzon, mondhatni, hogy ezek a megbízható információk szolgáltatói.

Orákulumok

Képzelje el, hogy egy okos szerződés 0.001 BTC átutalását végzi az ön bitcoin pénztárcájára, ha a kedvenc focicsapata megnyeri a Orosz Kupát. A valódi győzelem esetén az okos szerződésnek át kell adnia információt arról, hogy melyik csapat nyert, és itt több probléma merül fel: honnan nyerjük az információt, hogyan tudjuk biztonságosan átadni az okos szerződésnek, és hogyan győződjünk meg arról, hogy az okos szerződéshez eljutott információ valóban megegyezik a valósággal?

Az információforrás esetében két forgatókönyv létezhet: egy megbízható weboldalhoz való csatlakozás, amelyen központilag tárolják a mérkőzések eredményeit, illetve a második lehetőség az, hogy több weboldalt csatlakoztatunk, és az információt a többségi források alapján választjuk ki, amelyek azonos adatokat szolgáltatnak. Az információ helyességének ellenőrzésére orákulumok használatosak, például az Oraclize, amely a TLSNotary-t alkalmazza (a TLS módosítása az adatok hitelesítésére). Az Oraclize-ról elegendő információ található a Google-ben, és a Habrán is van néhány cikk, ma azonban a Town Crier és a DECO orákulumokról fogok beszélni, amelyek egy kicsit más megközelítést alkalmaznak az információátvitel terén: a cikkben mindkét orákulum működési elveit és részletes összehasonlítását találod.

Town Crier

A Town Crier (TC) az IC3 (The Initiative for CryptoCurrencies and Contracts) által került bemutatásra 2016-ban a CCS’16-on. A TC alapvető ötlete: az információt a weboldalról a smart contracthoz kell eljuttatni, és biztosítani, hogy a TC által szállított információ megegyezzen a weboldalon találhatóval. A TC TEE-t (Trusted Execution Environment) használ az adatok hitelességének biztosítására. Az eredeti TC változat az Intel SGX-szel való munkát írja le.
A Town Crier része a blokkláncban és része magában az operációs rendszerben – a TC Server.

A TC szerződés a blokkláncon található, és front endként működik a TC számára. Kéréseket fogad a CU-tól (felhasználó smart contract) és választ ad a TC Server-től. A TC Server belsejében található egy Relay, amely kapcsolatot létesít az enclávéval az interneten (kétirányú forgalom), és összekapcsolja az enclávét a blokklánccal. Az enclave tartalmaz egy progencl-t, amely a blokkláncból érkező kéréseket hajtja végre, és a blokkba digitális aláírással visszaküldi az üzeneteket, a progencl tartalmazza a smart contract kódjának egy részét, és lényegében a funkcióinak egy részét végzi el.

Az Intel SGX enclávét egy közös API-val rendelkező könyvtárként lehet szemlélni, amely az ecall révén működik. Az ecall átadja a vezérlést az enclávénak. Az enclávé a saját kódját hajtja végre, amíg be nem fejeződik, vagy amíg kivétel nem történik. Az enclávén kívül definiált funkciók hívásához ocall-ek használatosak. Az ocall-t az enclávén kívül hajtják végre, és az enclávé megbízhatatlan hívásként kezeli. Az ocall végrehajtása után a vezérlés visszatér az enclávéhoz.

Az Enclave részben a biztonságos csatorna beállítása történik a webkiszolgálóval, az enclav maga hajtja végre a TLS kézfogást a célkiszolgálóval, és minden kriptográfiai műveletet önállóan végez. A TLS könyvtár (mbedTLS) és a HTTP-kód egy csökkentett változata exportálva van az SGX környezetbe. Az Enclave emellett root CA tanúsítványokat is tartalmaz (tanúsítványok gyűjteménye), hogy ellenőrizze a távoli kiszolgálók tanúsítványait. A Kérelmi Kezelő egy datagram kérelmet fogad el az Ethereum által szolgáltatott formátumban, majd dekódolja és elemzi azt. Ezután generál egy Ethereum tranzakciót, amely a kért datagramot tartalmazza, és azt az skTC segítségével aláírja, majd továbbítja a Relay-be.

A Relay rész tartalmazza a Kliencifelületet, TCP-t és a Blockchain Interface-t. A Kliencifelület szükséges az enclav kódjának tanúsításához és a klienssel való kapcsolattartáshoz. A kliens tanúsítványértékelési kérelmet küld ecall segítségével, és egy timestampet kap az skTC által aláírva, valamint az att (tanúsítási aláírás) kíséretében, amelyet ezután az Intel Tanúsítási Szolgáltatás (IAS) hitelesít, míg a timestampet egy megbízható időszolgáltatás ellenőrzi. A Blockchain Interface ellenőrzi a beérkező kérelmeket és tranzakciókat helyez el a blokkláncon a datagramok továbbítása érdekében. A Geth az Ethereum hivatalos kliense, amely lehetővé teszi a Relay számára, hogy RPC hívásokon keresztül kölcsönhatásba lépjen a blokklánccal.

A TEE-vel dolgozva a TC lehetővé teszi több enclav párhuzamos indítását, ezáltal háromszorosára növelve az információfeldolgozás sebességét. Míg egyetlen működő enclav mellett a sebesség 15 tx/s volt, 20 párhuzamosan futó enclav mellett a sebesség 65 tx/s-ra nő, összehasonlításképpen, a Bitcoin blokklánc maximális sebessége 26 tx/s.

DECO

A DECO (Decentralizált Orákulumok a TLS-hez) a CCS’20-on került bemutatásra, és olyan weboldalakkal működik, amelyek támogatják a TLS kapcsolatot. Biztosítja az adatok titkosságát és integritását.
A DECO TLS-sel szimmetrikus titkosítást használ, ezáltal a kliensnek és a webkiszolgálónak is vannak titkosító kulcsai, és a kliens, ha akarja, hamisíthatja a TLS munkamenet adatait. Ennek a problémának a megoldására a DECO egy háromoldalú kézfogási protokollt alkalmaz a prover (okosszerződés), verifier (orákulum) és web-kiszolgáló (adatforrás) között.

A DECO működési elve az, hogy a veriifikátorhoz (verifier) a prover egy részletet kap az adatokból D, és megerősíti, hogy D a TLS szerver S-től érkezett. További probléma, hogy a TLS nem írja alá az adatokat, és a TLS kliens számára nehéz bizonyítani, hogy az adatok pontosan attól a szervertől származnak (eredet nehézség).

A DECO protokollban a KEnc és KMac titkosító kulcsokat használják. A kliens Q lekérdezést küld webszerver, a szerver R válasza titkosítva érkezik, de a kliens és a szerver ugyanazzal a KMac-kel rendelkezik, így a kliens hamisítani tudja a TLS üzenetet. A DECO megoldása az, hogy "elrejtse" a KMac-ot a kliens elől (prove) egészen addig, amíg az nem válaszol a lekérdezésre. Most a KMac fel van osztva a prove és a verifier között — KpMac és KvMac. A szerver megkapja a KMac-ot a válasz titkosításához, a KpMac és KvMac részeinek művelete révén KpMac ⊕ KvMac = KMac.

A háromoldalú kézfogás beállításával a kliens és a szerver közötti adatcsere biztonságos lesz.

A decentralizált orákulum rendszeréről beszélve nem lehet figyelmen kívül hagyni a Chainlinket, amely decentralizált orákulum csomópontokból álló hálózat létrehozására törekszik, amely kompatibilis az Ethereum, Bitcoin és Hyperledger blokkláncokkal, figyelembe véve a modularitást: a rendszer minden része frissíthető. A biztonság érdekében a Chainlink ajánlja, hogy minden orákulum, amely részt vesz a feladatban, egy kulcskombinációt (nyilvános és privát) bocsásson rendelkezésre. A privát kulcsot a részleges aláírás generálására használják, amely tartalmazza a válaszra vonatkozó adatokra tett javaslatukat. A válasz megkapásához az összes orákulum részleges aláírásának egyesítése szükséges.

A Chainlink tervezi, hogy végrehajtja a DECO első PoC-ját, a decentralizált pénzügyi alkalmazások, például a Mixicles irányába összpontosítva. A cikk írásának időpontjában a Forbes hírt adott arról, hogy a Chainlink megvásárolta a DECO-t a Cornell Egyetemtől.

Támadások az orákulumok ellen

Információbiztonsági szempontból a következő támadásokat vizsgálták a Town Crier ellen:

1. Rogue smart-contact kód injekció a TEE csomópontokba.
   A támadás lényege: tudatosan hibás okos szerződés kód átadása a TEE-be, így a támadó, aki hozzáfért a csomóponthoz, lehetőséget kap arra, hogy a saját (csaló) okos szerződését végrehajtsa a dekódolt adatokra. Mindazonáltal a visszatérő értékek titkosítva lesznek a privát kulccsal, és az egyetlen mód a hozzáféréshez az, ha a titkosított szöveg szivárog a visszatérési/kibocsátási folyamat során.
   A védelem e támadás ellen a kód aktuális címének érvényességének ellenőrzésében rejlik. Ez egy címezési séma segítségével érhető el, ahol a szerződés címe a szerződés kódjának hash-elésével van meghatározva.

2. A szerződés állapotának titkosított adatainak megváltozása kiszivárogtat.
   A támadás lényege: Azok a csomópontok, ahol okos szerződések futnak, titkosított formában hozzáférnek a szerződés állapotához a zárt környezeten kívül. A támadó, ha ellenőrzés alá vonja a csomópontot, össze tudja hasonlítani a szerződés állapotát a tranzakció végrehajtása előtt és után, és meg tudja határozni, hogy milyen argumentumokat adtak meg, és pontosan melyik okos szerződés metódusát használták, mivel maguk az okos szerződések kódja és technikai specifikációi nyilvánosak.
   Védelem a csomópont megbízhatóságának biztosítására.

3. Oldalcsatornás támadások.
   Egy különleges támadási típus, amely a memória és a zárt környezet cache-hozzáférésének figyelését használja különböző forgatókönyveknél. Ilyen támadás például a Prime and Probe.
   
   A támadás végrehajtásának menete:

   • t0: A támadó feltölti a célzott folyamat adatait a cache-ben.
   • t1: A célpont kódot hajt végre, mely a titkos adatoktól (kriptográfiai kulcsok) függő memóriaeléréseket tartalmaz. A cache sor választása a keybit értéke alapján történik. A példán a keybit = 0, és az X címet olvasták a 2. cache sorban. Az X-ben tárolt adatokat a cache-be töltik, kiszorítva azokat, amik korábban ott voltak.
   • t2: A támadó ellenőrzi, hogy mely cache sorait szorították ki – azokat, amiket a célpont használt. Ezt az elérési idő mérésével hajtja végre. Ezt a műveletet minden egyes keybit esetén megismételve a támadó megkapja az összes kulcsot.

Védekezés a támadás ellen: Az Intel SGX rendelkezik védelemmel az oldalcsatornás támadások ellen, amely megtiltja a cache-hez kapcsolódó események figyelését, de a Prime and Probe támadás így is végrehajtható, mivel a támadó a saját folyamata cache-éből származó eseményeket figyelheti meg, és osztozik a célpont cache-én.

Jelenleg tehát megbízható védelem e támadás ellen nem létezik.

Ismert még Spectre és Foreshadow (L1TF) típusú támadások is, amelyek hasonlítanak a Prime and Probe-hoz, és lehetővé teszik az adatok olvasását a cache-ből oldalcsatornán keresztül. Létezik védelem a Spectre-v2 sérülékenység ellen, amely működik a két támadás ellen.

A DECO esetében a hárompontos kézfogás biztosítja a biztonság garanciáját:

1. Prover integritás: A feltört prover nem tudja hamisítani a server eredetéről szóló információt, és nem tudja rávenni a servert, hogy érvénytelen kéréseket fogadjon el, vagy helytelenül válaszoljon az érvényes kérésekre. Ez a server és a prover közötti kérési sablonok révén valósítható meg.
2. Verifier integritás: A feltört verifier nem tudja a prover-t hamis válaszokhoz kényszeríteni.
3. Adatvédelem: A feltört verifier csak nyilvános információkat vizsgál (lekérdezés, szerver neve).

A DECO esetében csak a forgalom injektálásával kapcsolatos sebezhetőségek lehetségesek. Először, a hárompontos kézfogás során a verifier megerősítheti a szerver hitelességét egy friss nonce segítségével. Azonban a kézfogás után a verifiernek a hálózati szintű mutatókra kell támaszkodnia (IP address). Így a kapcsolat a verifier és a server között védve kell legyen a forgalmi injektálással szemben. Ezt proxy használatával érik el.

Orákulumok összehasonlítása

A Town Crier a szerveroldai enclave munkáján alapul, míg a DECO lehetővé teszi az adatok származásának hitelesítését hárompontos kézfogással és adatainak titkosításával kriptográfiai kulcsokkal. Az orákulumok adatainak összehasonlítása a következő kritériumok alapján történt: teljesítmény, biztonság, költség és gyakorlatiasság.

Town Crier
DECO

teljesítmény
Gyorsabb (0,6 s a befejezéshez)
Lassabb (10,50 s a protokoll befejezéséhez)

biztonság
Kevésbé biztonságos
Biztonságosabb

ár
Drágább
Olcsóbb

gyakorlatiasság
Speciális hardver szükséges
Bármely TLS-t támogató szerverrel működik

Teljesítmény: A DECO használatához hárompontos kézfogás beállítása szükséges, LAN-on keresztül ez 0,37 másodpercet vesz igénybe, a kapcsolat létrejötte után a 2PC-HMAC (0,13 s írásra) hatékony. A DECO teljesítménye a rendelkezésre álló TLS titkosítási készletektől, a személyes adatok méretétől és a bizonyítékok összetettségétől függ egy adott alkalmazásra. Példa a IC3 bináris opciós alkalmazására: a protokoll befejezése LAN-on keresztül körülbelül 10,50 s. Összehasonlítva: a Town Crier hasonló alkalmazáshoz körülbelül 0,6 másodperc szükséges, ami körülbelül 20-szor gyorsabb, mint a DECO. Azonos feltételek mellett a TC gyorsabb lesz.

Biztonság: Az Intel SGX-enclavjára irányuló támadások (oldalcsatornás támadások) működnek, és valódi kárt okozhatnak az okos szerződés résztvevőinek. A DECO-val kapcsolatosan lehetséges a forgalom injektálásával kapcsolatos támadások, de a proxy használata megszünteti az ilyen támadásokat. Így a DECO biztonságosabb.

Ár: Az Intel SGX-t támogató hardver költsége magasabb, mint a DECO protokoll beállításának költsége. Így a TC drágább.

Gyakorlatiasság: A Town Crier működéséhez speciális hardver szükséges, amely támogatja a TEE-t. Például az Intel SGX az Intel Core 6. generációs és újabb processzorokban érhető el. A DECO viszont bármilyen hardveren működhet, bár van DECO konfiguráció TEE használatával. A háromoldalú kézfogás beállítása a DECO-nál eltarthat egy ideig, de ez semmi ahhoz képest, mint a TC esetében fellépő hardverkorlátozás, így a DECO praktikussága sokkal magasabb.

Zárás

Ha a két orákulumot külön-külön megvizsgáljuk és négy kritérium alapján összehasonlítjuk, látható, hogy a Town Crier három pontból hármat elveszít a DECO-val szemben. A DECO megbízhatóbb az információbiztonság szempontjából, olcsóbb és praktikusabb, bár a háromoldalú protokoll konfigurálása időigényes lehet és hátrányai is vannak, például a titkosítási kulcsokkal kapcsolatos további műveletek. A TC gyorsabban működik, mint a DECO, de a side-channel attack által okozott sebezhetőség miatt kockázatot jelent a magánélet védelmére. Fontos megjegyezni, hogy a DECO 2020 januárjában került bemutatásra, és még nem telt el elegendő idő ahhoz, hogy biztonságosnak lehessen tekinteni. A Town Crier már négy éve ki van téve támadásoknak, és számos ellenőrzésen átesett, ezért sok projektben indokolt a használata.

Forrás: habr.com