Ma már csak a lusták nem írtak a blokklánc technológiáról, a kriptovalutákról és arról, hogy milyen menő. De ez a cikk nem dicséri ezt a technológiát; beszélünk hiányosságairól és azok kiküszöbölésének módjairól.

Az Altirix Systems egyik projektjén dolgozva felmerült a feladat a blokkláncon kívüli forrásból származó adatok biztonságos, cenzúraálló megerősítése. Szükséges volt a harmadik rendszer rekordjaiban bekövetkezett változások megerősítése, és ezek alapján végrehajtani az intelligens szerződéses logika egyik vagy másik ágát. A feladat első ránézésre meglehetősen triviális, de amikor a folyamatban részt vevő egyik fél anyagi helyzete a végrehajtás eredményétől függ, további követelmények jelennek meg. Először is ez egy ilyen érvényesítési mechanizmusba vetett átfogó bizalom. De először a dolgok.

A probléma az, hogy maga a blokklánc egy autonóm, zárt entitás, így a blokkláncon belüli intelligens szerződések semmit sem tudnak a külvilágról. Ugyanakkor az okosszerződések feltételei gyakran valós dolgokkal kapcsolatos információkhoz kapcsolódnak (járatkésés, árfolyamok stb.). Az intelligens szerződések megfelelő működéséhez a blokkláncon kívülről kapott információknak megbízhatónak és ellenőrzöttnek kell lenniük. Ezt a problémát olyan orákumok segítségével oldják meg, mint a Town Crier és a DECO. Ezek az orákulumok lehetővé teszik a blokklánc-hálózaton kötött intelligens szerződések számára, hogy megbízzanak egy megbízható webszervertől származó információkban; mondhatjuk, hogy megbízható információk szolgáltatói.

Orákuszok

Képzelje el, hogy egy intelligens szerződés 0.001 btc-t utal át a bitcoin pénztárcájába, ha kedvenc futballklubja megnyeri az Orosz Kupát. Valódi győzelem esetén az intelligens szerződésnek információt kell továbbítania arról, hogy melyik klub nyert, és számos probléma merül fel itt: honnan szerezhető be ez az információ, hogyan lehet biztonságosan átvinni az okosszerződésbe, és hogyan lehet biztosítani, hogy az információ az intelligens szerződésben kapott összeg valóban egybeesik a valósággal?

Ami az információforrást illeti, két forgatókönyv lehetséges: egy intelligens szerződés csatlakoztatása egy megbízható webhelyhez, ahol központilag tárolják a mérkőzések eredményeivel kapcsolatos információkat, a második lehetőség pedig több webhely összekapcsolása, majd a legtöbb forrásból való információ kiválasztása. amelyek ugyanazokat az adatokat szolgáltatják. Az információ helyességének ellenőrzésére orákulumokat használnak, például az Oraclize-t, amely a TLSNotary-t (TLS Notar Modification to Prove the Authenticity of Data) használja. De van elég információ a Google-on az Oraclize-ról, és több cikk is található a Habré-ról.Ma azokról az orákulumokról fogok beszélni, amelyek egy kicsit más megközelítést alkalmaznak az információ továbbítására: Town Crier és DECO. A cikk mindkét orákulum működési elvének leírását, valamint részletes összehasonlítását tartalmazza.

Rikkancs

A Town Crier-t (TC) az IC3 (The Initiative for CryptoCurrencies and Contracts) vezette be 2016-ban a CCS'16-on. A TC fő gondolata: információk átvitele egy webhelyről egy intelligens szerződésbe, és győződjön meg arról, hogy a TC által szállított információ megegyezik a webhelyen található információval. A TC a TEE-t (Trusted Execution Environment) használja az adatok tulajdonjogának hitelesítésére. A TC eredeti verziója leírja, hogyan kell dolgozni az Intel SGX-szel.
A Town Crier a blokkláncon belüli részből és magában az operációs rendszeren belüli részből áll - TC Server.

A TC Contract a blokkláncon található, és a TC kezelőfelületeként működik. Elfogadja a CU-tól (felhasználói intelligens szerződés) érkező kéréseket, és választ küld a TC-kiszolgálótól. A TC Szerver belsejében van egy Relay, amely kapcsolatot létesít az enklávé és az Internet között (kétirányú forgalom), és összeköti az enklávét a blokklánccal. Az Enclave tartalmazza a progencl-t, ami egy olyan kód, amely kéréseket küld a blokkláncból, és üzeneteket küld vissza a blokkláncnak digitális aláírással, a progencl tartalmazza az intelligens szerződés kódjának egy részét, és lényegében ellátja egyes funkcióit.

Az Intel SGX enklávé egy megosztott könyvtárnak tekinthető, amely egy ecall-on keresztül futó API-val rendelkezik. Az Ecall átadja az irányítást az enklávénak. Az enklávé addig hajtja végre a kódját, amíg ki nem lép, vagy amíg kivétel nem történik. Az ocall az enklávén kívül definiált függvények meghívására szolgál. Az Ocall az enklávén kívül kerül végrehajtásra, és nem megbízható hívásként kezeli. Az ocal végrehajtása után a vezérlés visszakerül az enklávéhoz.

Az Enclave részben egy biztonságos csatorna van konfigurálva egy webszerverrel, maga az enklávé TLS-kézfogást hajt végre a célszerverrel és minden titkosítási műveletet belsőleg hajt végre. A TLS-könyvtár (mbedTLS) és a csökkentett HTTP-kód exportálásra került az SGX-környezetbe. Az Enclave gyökér CA-tanúsítványokat is tartalmaz (tanúsítványok gyűjteménye) a távoli kiszolgálók tanúsítványainak ellenőrzésére. A Request Handler elfogad egy datagram kérést az Ethereum által biztosított formátumban, dekódolja és elemzi. Ezután létrehoz egy Ethereum tranzakciót, amely tartalmazza a kért datagramot, aláírja az skTC-vel, és továbbítja a Relay-nek.

A Relay rész tartalmazza a kliens felületet, a TCP-t és a blokklánc interfészt. A kliens interfész az enklávé kód hitelesítéséhez és az ügyféllel való kommunikációhoz szükséges. Az ügyfél hitelesítési kérelmet küld az ecall használatával, és kap egy, az skTC által aláírt időbélyeget az att-vel együtt (igazolási aláírás), majd az att-t az Intel Attestation Service (IAS) segítségével ellenőrzi, az időbélyeget pedig egy megbízható időszolgáltatás. A Blockchain Interface ellenőrzi a bejövő kéréseket, és tranzakciókat helyez el a blokkláncon a datagramok kézbesítéséhez. A Geth egy hivatalos Ethereum kliens, és lehetővé teszi a Relay számára, hogy RPC-hívásokon keresztül kommunikáljon a blokklánccal.

A TEE-vel együttműködve a TC lehetővé teszi több enklávé párhuzamos futtatását, ezáltal háromszorosára növeli az információfeldolgozás sebességét. Ha egy futó enklávéval 3 tx/sec volt a sebesség, akkor 15 párhuzamosan futó enklávéval a sebesség 20 tx/sec-re nő; összehasonlításképpen a Bitcoin blokkláncban a maximális működési sebesség 65 tx/sec.

DECO

A CCS'20-on bemutatták a DECO-t (Decentralized Oracles for TLS), amely olyan oldalakkal működik, amelyek támogatják a TLS-kapcsolatokat. Biztosítja az adatok titkosságát és integritását.
A TLS-szel rendelkező DECO szimmetrikus titkosítást használ, így a kliens és a webszerver rendelkezik titkosítási kulccsal, és az ügyfél ha akarja, hamisíthatja a TLS munkamenet adatait. A probléma megoldására a DECO háromutas kézfogási protokollt használ a prover (intelligens szerződés), a hitelesítő (Oracle) és a webszerver (adatforrás) között.

A DECO úgy működik, hogy a hitelesítő kap egy D adatot, és megerősíti a hitelesítőnek, hogy D az S TLS szerverről származik. További probléma, hogy a TLS nem írja alá az adatokat, és a TLS kliens nehezen tudja bizonyítani, hogy az adatok pontosan a megfelelő szerverről érkeztek (származási nehézség).

A DECO protokoll KEnc és KMac titkosítási kulcsokat használ. A kliens Q kérelmet küld a webszervernek, a válasz az R szervertől titkosított formában érkezik, de a kliens és a kiszolgáló ugyanazt a KMac-et birtokolja, és az ügyfél hamisíthatja a TLS üzenetet. A DECO megoldása az, hogy "elrejti" a KMac-et a kliens (próbáló) elől, amíg az nem válaszol a kérésre. A KMac most meg van osztva bizonyító és ellenőrző - KpMac és KvMac között. A kiszolgáló megkapja a KMac-ot, hogy titkosítsa a választ a KpMac ⊕ KvMac = KMac kulcsrész művelettel.

A háromirányú kézfogás felállításával a kliens és a szerver közötti adatcsere a biztonság garantálásával valósul meg.

Ha egy decentralizált oracle rendszerről beszélünk, nem hagyhatjuk figyelmen kívül a Chainlink-et, amely az Ethereummal, Bitcoinnal és Hyperledgerrel kompatibilis oracle csomópontok decentralizált hálózatát kívánja létrehozni, figyelembe véve a modularitást: a rendszer minden része frissíthető. Ugyanakkor a biztonság érdekében a Chainlink minden, a feladatban részt vevő orákulumnak felajánlja a kulcsok (nyilvános és privát) kombinációjának kiadását. A privát kulcs egy részleges aláírás létrehozására szolgál, amely tartalmazza az adatigényléssel kapcsolatos döntésüket. A válasz megszerzéséhez össze kell kapcsolni a hálózat orákulumainak összes részleges aláírását.

A Chainlink azt tervezi, hogy a kezdeti PoC DECO-t olyan decentralizált pénzügyi alkalmazásokra összpontosítja, mint a Mixicles. A cikk írásakor olyan hír jelent meg a Forbes-on, 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ő Town Crier elleni támadásokat vették figyelembe:

1. Rogue intelligens érintkező kód befecskendezés a TEE csomópontokra.
   A támadás lényege: szándékosan hibás intelligens szerződés kód továbbítása a TEE-nek, így a csomóponthoz hozzáférő támadó saját (csalás) intelligens szerződését tudja végrehajtani a visszafejtett adatokon. A visszatérési értékek azonban titkos kulccsal lesznek titkosítva, és az ilyen adatokhoz való hozzáférés egyetlen módja a titkosított szöveg kiszivárogtatása a visszatérés/kimenet során.
   A támadás elleni védelem abból áll, hogy az enklávé ellenőrzi az aktuális címen található kód helyességét. Ez egy olyan címzési sémával érhető el, ahol a szerződés címét a szerződés kódjának kivonatolása határozza meg.

2. A szerződés állapotának titkosított szövege kiszivárog.
   A támadás lényege: Az intelligens szerződéseket végrehajtó csomópontok tulajdonosai titkosított formában hozzáférhetnek a szerződés állapotához az enklávén kívül. A támadó, miután megszerezte az irányítást egy csomópont felett, össze tudja hasonlítani a kapcsolatfelvételi állapotot a tranzakció előtt és után, és meg tudja határozni, hogy mely argumentumok kerültek beírásra, és melyik intelligens szerződés módszert használta, mivel maga az intelligens szerződés kódja és annak műszaki specifikációi nyilvánosan elérhetők.
   Védelem magának a csomópontnak a megbízhatóságának biztosításában.

3. Oldalsó csatornás támadások.
   Egy speciális típusú támadás, amely az enklávémemória és a gyorsítótár-hozzáférés figyelését használja különböző forgatókönyvekben. Ilyen támadásra példa a Prime és a Probe.
   
   Támadási sorrend:

   • t0: A támadó kitölti az áldozati folyamat teljes adatgyorsítótárát.
   • t1: Az áldozat olyan memória-hozzáféréssel kódot hajt végre, amely az áldozat érzékeny adataitól (kriptográfiai kulcsoktól) függ. A gyorsítótár sor kiválasztása a kulcsbit értéke alapján történik. Az ábra példájában a keybit = 0 és a cache 2. sorban az X cím kerül beolvasásra. Az X-ben tárolt adatok betöltődnek a gyorsítótárba, kiszorítva a korábban ott lévő adatokat.
   • t2: A támadó ellenőrzi, hogy mely gyorsítótár-vonalait ürítették ki – az áldozat által használt vonalakat. Ez a hozzáférési idő mérésével történik. Ezt a műveletet minden kulcsbitre megismételve a támadó megkapja a teljes kulcsot.

Támadásvédelem: Az Intel SGX rendelkezik olyan védelemmel az oldalcsatornás támadások ellen, amely megakadályozza a gyorsítótárral kapcsolatos események figyelését, de a Prime and Probe támadás továbbra is működik, mert a támadó figyeli folyamatának gyorsítótár-eseményeit, és megosztja a gyorsítótárat az áldozattal.

Így jelenleg nincs megbízható védelem e támadás ellen.

A Prime-hoz és a Probe-hoz hasonló támadások is ismertek, mint például a Spectre és a Foreshadow (L1TF). Lehetővé teszik a gyorsítótárból származó adatok beolvasását egy harmadik féltől származó csatornán keresztül. A Spectre-v2 sebezhetőség elleni védelem biztosított, amely két ilyen támadás ellen is működik.

A DECO-val kapcsolatban a háromirányú kézfogás garantálja a biztonságot:

1. Prover integritása: A feltört hitelesítő nem hamisíthatja meg a kiszolgáló eredetére vonatkozó információkat, és nem képes arra, hogy a kiszolgáló érvénytelen kéréseket fogadjon el, vagy hibásan válaszoljon az érvényes kérésekre. Ez a szerver és a próbaverzió közötti kérési mintákon keresztül történik.
2. Az ellenőrző integritása: A feltört ellenőrző nem okozhatja azt, hogy a bizonyító helytelen válaszokat kapjon.
3. Adatvédelem: A feltört ellenőrző csak nyilvános információkat (kérés, szerver neve) vizsgál.

A DECO-ban csak a forgalominjekciós sebezhetőségek lehetségesek. Először is, egy háromirányú kézfogással az ellenőrző egy friss nonce segítségével megállapíthatja a szerver azonosságát. A kézfogás után azonban az ellenőrzőnek a hálózati rétegjelzőkre (IP-címekre) kell hagyatkoznia. Így a hitelesítő és a szerver közötti kommunikációt védeni kell a forgalominjektálástól. Ez a proxy használatával érhető el.

Orákulumok összehasonlítása

A Town Crier a szerverrészben lévő enklávéval való együttműködésen alapul, míg a DECO lehetővé teszi az adatok eredetének hitelességének ellenőrzését háromirányú kézfogással és kriptográfiai kulcsokkal történő adattitkosítással. Ezeknek az orákulumoknak az összehasonlítása a következő kritériumok szerint történt: teljesítmény, biztonság, költség és praktikusság.

Rikkancs
DECO

teljesítmény
Gyorsabb (0.6 másodperc a befejezésig)
Lassabb (10.50 másodperc a protokoll befejezéséhez)

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

költség
Drágább
Olcsóbb

gyakorlatiasság
Speciális hardvert igényel
Minden olyan szerverrel működik, amely támogatja a TLS-t

Teljesítmény: A DECO-val való munkához háromirányú kézfogás szükséges, LAN-on keresztüli beállításnál 0.37 másodperc, a kapcsolat létrejötte utáni interakcióhoz a 2PC-HMAC hatékony (0,13 s írásonként). A DECO teljesítménye a rendelkezésre álló TLS titkosítási csomagoktól, a privát adatok méretétől és az adott alkalmazás bizonyítékainak összetettségétől függ. Példaként használva az IC3 bináris opciós alkalmazását: a protokoll LAN-on keresztüli befejezése körülbelül 10,50 másodpercet vesz igénybe. Összehasonlításképpen, a Town Crier körülbelül 0,6 másodpercet vesz igénybe egy hasonló alkalmazás végrehajtásához, ami körülbelül 20-szor gyorsabb, mint a DECO. Ha minden egyenlő, a TC gyorsabb lesz.

biztonság: Az Intel SGX enklávé elleni támadások (oldalcsatornás támadások) működnek, és valós károkat okozhatnak az okosszerződés résztvevőinek. A DECO-val kapcsolatban a forgalominjektáláshoz kapcsolódó támadások lehetségesek, de a proxy használata semmivé csökkenti az ilyen támadásokat. Ezért a DECO biztonságosabb.

Költség: Az Intel SGX-et támogató berendezések költsége magasabb, mint a DECO protokoll beállításának költsége. Ezért drágább a TC.

gyakorlatiasság: A Town Crierrel való munkához speciális, TEE-t támogató berendezésre van szükség. Például az Intel SGX támogatja a 6. generációs Intel Core processzorcsaládot és újabbakat. A DECO lehetővé teszi, hogy bármilyen berendezéssel dolgozzon, bár létezik DECO beállítás a TEE használatával. A beállítási folyamat szerint a DECO háromirányú kézfogása eltarthat egy ideig, de ez semmi a TC hardveres korlátaihoz képest, így a DECO praktikusabb.

Következtetés

Ha a két jóslatot külön-külön nézzük, és négy kritérium alapján hasonlítjuk össze, egyértelmű, hogy a Town Crier négyből három pontban alulmúlja a DECO-t. A DECO információbiztonsági szempontból megbízhatóbb, olcsóbb és praktikusabb, bár egy háromoldalú protokoll felállítása eltarthat egy ideig, és megvannak a maga hátrányai, például a titkosítási kulcsokkal végzett további műveletek. A TC gyorsabb, mint a DECO, de az oldalcsatornás támadások sebezhetősége miatt ki van téve a titoktartásnak. Figyelembe kell venni, hogy a DECO-t 2020 januárjában vezették be, és nem telt el elég idő ahhoz, hogy biztonságosnak tekintsék. A Town Crier-t 4 éve támadják, és számos teszten ment keresztül, így használata sok projektben indokolt.

Forrás: will.com