Idag är det bara de lata som inte har skrivit om blockkedjeteknik, kryptovalutor och hur coolt det är. Men den här artikeln kommer inte att berömma denna teknik; den kommer att fokusera på sina brister och sätt att eliminera dem.

Under arbetet med ett av projekten på Altirix Systems uppstod uppgiften att säker, censurbeständig bekräftelse av data från en extern källa för blockkedjan. Det var nödvändigt att bekräfta ändringar i det tredje systemets register och, baserat på dessa ändringar, utföra en eller annan gren i logiken för det smarta kontraktet. Uppgiften är vid första anblicken ganska trivial, men när den ekonomiska situationen för en av parterna i processen beror på resultatet av dess genomförande, dyker ytterligare krav upp. För det första är det ett omfattande förtroende för en sådan valideringsmekanism. Men först till kvarn.

Problemet är att själva blockkedjan är en autonom, sluten enhet, så smarta kontrakt inuti blockkedjan vet ingenting om omvärlden. Samtidigt är villkoren för smarta kontrakt ofta kopplade till information om riktiga saker (flygförseningar, växelkurser etc.). För att smarta kontrakt ska fungera korrekt måste information som tas emot utanför blockkedjan vara tillförlitlig och verifierad. Detta problem löses genom att använda orakel som Town Crier och DECO. Dessa orakel tillåter ett smart kontrakt i blockchain-nätverket att lita på information från en pålitlig webbserver, så de kan kallas pålitliga informationsleverantörer.

Orakel

Föreställ dig ett smart kontrakt som överför 0.001 btc till din bitcoin-plånbok om din favoritfotbollsklubb vinner den ryska cupen. Vid en riktig seger behöver det smarta kontraktet ges information om vilken klubb som vann, och det väcker ett antal problem: var kan denna information fås, hur kan den på ett säkert sätt överföras till det smarta kontraktet, och hur kan vi säkerställa att informationen som det smarta kontraktet tar emot faktiskt stämmer överens med verkligheten?

I problemet med informationskällan kan det finnas två scenarier: att koppla ett smart kontrakt till en pålitlig webbplats där information om resultaten av matchningar lagras centralt, och det andra alternativet är att koppla ihop flera sajter samtidigt och sedan välja information från de flesta källor som tillhandahåller samma data. För att säkerställa informationens riktighet används orakel, såsom Oraclize, som använder TLSNotary (TLS Modification for Proving Data Authenticity). Men det finns tillräckligt med information om Oraclize i Google, och det finns flera artiklar om Habr, men idag ska jag prata om orakel som använder ett lite annorlunda tillvägagångssätt för att överföra information: Town Crier och DECO. Artikeln ger en beskrivning av funktionsprinciperna för båda oraklen, samt en detaljerad jämförelse.

Town Crier

Town Crier (TC) introducerades av IC3 (The Initiative for Cryptocurrencies and Contracts) 2016 på CCS'16. Huvudidén med TC är att skicka information från en webbplats till ett smart kontrakt och se till att informationen som levereras av TC är densamma som den på webbplatsen. TC använder TEE (Trusted Execution Environment) för att säkerställa att dataägandet är äkta. Den ursprungliga versionen av TC beskriver arbetet med Intel SGX.
Town Crier består av en del inuti blockkedjan och en del inuti själva OS - TC Server.

TC Contract ligger på blockkedjan och fungerar som en frontend för TC. Den accepterar förfrågningar från CU (user smart contract) och returnerar svar från TC Server. Inuti TC-servern finns ett relä, som upprättar en koppling mellan enklaven och Internet (dubbelriktad trafik) och kopplar enklaven till blockkedjan. Enclave innehåller progencl, vilket är koden som gör förfrågningar från blockkedjan och returnerar meddelanden till blockkedjan med en digital signatur, progencl innehåller en del av den smarta kontraktskoden och utför i huvudsak några av dess funktioner.

Intel SGX-enklaven kan ses som ett delat bibliotek med ett API som fungerar via ecall. Ecall överför kontrollen till enklaven. Enklaven exekverar sin kod tills den avslutas eller tills ett undantag inträffar. För att anropa funktioner definierade utanför enklaven, används ocall. Ocall exekveras utanför enklaven och behandlas av den som ett otillförlitligt samtal. Efter att ocall har utförts, återgår kontrollen till enklaven.

I Enclave-delen konfigureras en säker kanal med webbservern, enklaven själv utför ett TLS-handslag med målservern och utför alla kryptografiska operationer internt. TLS-biblioteket (mbedTLS) och minifierad HTTP-kod har exporterats till SGX-miljön. Enclave innehåller också rot-CA-certifikat (en samling certifikat) för att verifiera fjärrservercertifikat. Request Handler accepterar en datagrambegäran i formatet som tillhandahålls av Ethereum, dekrypterar den och analyserar den. Den genererar sedan en Ethereum-transaktion som innehåller det begärda datagrammet, signerar det med skTC och skickar det till Relay.

Relädelen inkluderar Client Interface, TCP, Blockchain Interface. Klientgränssnittet behövs för att validera enklavkoden och kommunicera med klienten. Klienten skickar en attestationsbegäran med ecall och får en tidsstämpel signerad av skTC tillsammans med att (attestationssignatur), sedan verifieras att med Intel Attestation Service (IAS) och tidsstämpel verifieras av en betrodd tidstjänst. Blockchain-gränssnittet verifierar inkommande förfrågningar och placerar transaktioner på blockkedjan för att leverera datagram. Geth är den officiella Ethereum-klienten och låter Relay interagera med blockkedjan via RPC-samtal.

Genom att arbeta med TEE tillåter TC flera enklaver att lanseras parallellt, vilket ökar hastigheten på informationsbearbetningen med 3 gånger. Om hastigheten med en löpande enklav var 15 tx/sek, så ökar hastigheten med 20 parallellt löpande enklaver till 65 tx/sek, för jämförelse är den maximala operationshastigheten i Bitcoin blockchain 26 tx/sek.

DECO

DECO (Decentralized Oracles for TLS) presenterades på CCS'20, arbetar med sajter som stöder TLS-anslutning. Säkerställer konfidentialitet och integritet för data.
DECO med TLS använder symmetrisk kryptering, så både klienten och webbservern har krypteringsnycklar, och klienten kan förfalska TLS-sessionsdata om den vill. För att lösa detta problem använder DECO ett trevägshandskakningsprotokoll mellan provaren (smart kontrakt), verifieraren (oracle) och webbservern (datakällan).

Principen för DECO är att provaren tar emot en bit data D och bekräftar för verifieraren att D kom från TLS-servern S. Ett annat problem är att TLS inte signerar data och det är svårt för TLS-klienten att bevisa att data kom från den servern (härkomstsvårigheter).

DECO-protokollet använder krypteringsnycklarna KEnc och KMac. Klienten skickar en begäran Q till webbserverSvaret från server R anländer krypterat, men klienten och servern delar samma KMac, och klienten kan förfalska TLS-meddelandet. DECOs lösning är att "dölja" KMac från klienten (provern) tills den svarar på begäran. Nu delas KMac mellan provern och verifieraren – KpMac och KvMac. Servern hämtar KMac för att kryptera svaret med hjälp av nyckelpartitioneringsoperationen KpMac ⊕ KvMac = KMac.

Genom att sätta upp en trevägshandskakning kommer datautbytet mellan klienten och servern att utföras med en garanti för säkerhet.

När vi pratar om decentraliserade orakelsystem kan vi inte låta bli att nämna Chainlink, som syftar till att skapa ett decentraliserat nätverk av orakelnoder som är kompatibla med Ethereum, Bitcoin och Hyperledger, med modularitet i åtanke: varje del av systemet kan uppgraderas. För att säkerställa säkerheten kräver Chainlink att varje orakel som deltar i uppgiften tillhandahåller en kombination av nycklar (offentliga och privata). Den privata nyckeln används för att generera en partiell signatur som innehåller deras svar på dataförfrågan. För att få svar måste alla delsignaturer av nätverkets orakel kombineras.

Chainlink planerar att genomföra en första PoC av DECO med fokus på decentraliserade finansiella applikationer som Mixicles. I skrivande stund kom nyheter på Forbes att Chainlink förvärvade DECO från Cornell University.

Attacker på Oracles

Ur ett informationssäkerhetsperspektiv övervägdes följande attacker mot Town Crier:

1. Rogue smart-kontakt kodinjektion på TEE-noder.
   Kärnan i attacken: överföring av en medvetet felaktig smart kontraktskod till TEE, så att en angripare som har fått tillgång till noden kommer att kunna utföra sitt eget (bedrägliga) smarta kontrakt på de dekrypterade data. De returnerade värdena kommer dock att krypteras med en privat nyckel, och det enda sättet att komma åt sådan data är att läcka chiffertexten vid retur/utmatning.
   Skydd mot denna attack består av att enklaven kontrollerar korrektheten av koden som finns på den aktuella adressen. Detta kan uppnås med hjälp av ett adresseringsschema där adressen till ett kontrakt bestäms genom att hasha kontraktskoden.

2. Kontrakt stat chiffertext ändringar läcka.
   Kärnan i attacken: Ägare av noder där smarta kontrakt exekveras har tillgång till kontraktstillståndet i krypterad form utanför enklaven. En angripare som får kontroll över en nod kan jämföra kontakttillståndet före och efter att transaktionen exekveras och kan avgöra vilka argument som angavs och vilken smart kontraktsmetod som användes, eftersom själva smarta kontraktskoden och dess tekniska specifikationer är allmänt tillgängliga.
   Skydd för att säkerställa tillförlitligheten hos själva enheten.

3. Sidokanalattacker.
   En speciell typ av attack som använder övervakning av åtkomst till enklavminne och cache i olika scenarier. Ett exempel på en sådan attack är Prime and Probe.
   
   Ordningen för attacken:

   • t0: Angriparen fyller hela datacchen för offerprocessen.
   • t1: Offret exekverar kod med minnesåtkomster som beror på offrets känsliga data (kryptografiska nycklar). Cacheminnet väljs baserat på nyckelbitvärdet. I exemplet i figuren läses keybit = 0 och adress X i cache-rad 2. Data som lagras i X laddas in i cachen och ersätter data som fanns där tidigare.
   • t2: Angriparen kontrollerar vilka av hans cache-rader som har vräkts - de rader som offret använder. Detta görs genom att mäta åtkomsttiden. Genom att upprepa denna operation för varje nyckelbit får angriparen hela nyckeln.

Attackskydd: Intel SGX har skydd mot sidokanalattacker som förhindrar övervakning av cache-relaterade händelser, men Prime- och Probe-attacken kommer fortfarande att lyckas eftersom angriparen övervakar cachehändelserna i sin process och delar cachen med offret.

För närvarande finns det alltså inget tillförlitligt skydd mot denna attack.

Spectre och Foreshadow (L1TF) attacker, liknande Prime och Probe, är också kända. De tillåter läsning av data från cacheminnet via en tredje parts kanal. Det finns ett skydd mot Spectre-v2-sårbarheten som fungerar mot båda dessa attacker.

I förhållande till DECO ger trevägshandslaget en säkerhetsgaranti:

1. Proverintegritet: En komprometterad provare kan inte förfalska information om en servers ursprung och kan inte få servern att acceptera ogiltiga förfrågningar eller svara felaktigt på giltiga förfrågningar. Detta är möjligt genom begäran mallar mellan server och prover.
2. Verifierarens integritet: En hackad verifierare kan inte få en provare att få felaktiga svar.
3. Sekretess: Den hackade verifieraren undersöker endast allmänt tillgänglig information (fråga, servernamn).

I DECO är endast sårbarheter för trafikknäckning möjliga. Inledningsvis, under en trevägshandskakning, kan verifieraren fastställa serverns identitet med hjälp av en ny nonce. Efter handskakningen måste verifieraren dock förlita sig på nätverkslagerindikatorer (IP-adresserDärför måste anslutningen mellan verifieraren och servern skyddas från trafikkontrombos. Detta uppnås genom att använda en proxy.

Jämförelse av Oracles

Town Crier bygger på att arbeta med en enklav i serverdelen, medan DECO möjliggör verifiering av äktheten av datas ursprung med hjälp av en trevägshandskakning och kryptering av data med kryptografiska nycklar. Jämförelsen av dessa orakel utfördes enligt följande kriterier: hastighet, säkerhet, kostnad och praktisk.

Town Crier
DECO

prestanda
Snabbare (0.6 s till slut)
Långsammare (10.50s för att avsluta protokollet)

säkerhet
Mindre säker
Säkrare

kosta
Dyrare
Billigare

praktiskhet
Kräver speciell hårdvara
Fungerar med alla servrar som stöder TLS

Hastighetsprestanda: DECO kräver en trevägshandskakningsinställning, som tar 0.37 sekunder vid installation via LAN, och 2PC-HMAC är effektiv för kommunikation efter anslutning (0,13 sekunder per skrivning). Prestandan för DECO beror på tillgängliga TLS-chiffersviter, storleken på privata data och komplexiteten hos bevisen för en viss applikation. Med exemplet med den binära optionen från IC3 tar slutförandet av protokollet via LAN cirka 10,50 s. Som jämförelse tar Town Crier cirka 0,6 sekunder att köra en liknande applikation, vilket är cirka 20 gånger snabbare än DECO. Allt annat lika kommer TC att bli snabbare.

Безопасность: Intel SGX-enklavens sidokanalsattacker fungerar och kan orsaka verklig skada för smarta kontraktsdeltagare. Trafikinjektionsattacker är möjliga med DECO, men att använda en proxy kommer att förneka sådana attacker. Därför är DECO säkrare.

Kostnad: Kostnaden för hårdvara som stöder Intel SGX är högre än kostnaden för att sätta upp protokollet i DECO. Det är därför TC är dyrare.

praktiskhet: För att arbeta med Town Crier krävs specialutrustning som stöder TEE. Till exempel stöds Intel SGX på 6:e generationens Intel Core-processorfamilj och senare. DECO låter dig arbeta med vilken utrustning som helst, även om det finns en DECO-inställning med TEE. När det gäller installationsprocessen kan DECOs trevägshandskakning ta lite tid, men det är ingenting jämfört med TC:s hårdvarubegränsning, så DECO är mer praktiskt.

Slutsats

Om man tittar på de två oraklen separat och jämför dem på fyra kriterier, är det tydligt att Town Crier är underlägsen DECO på tre av fyra punkter. DECO är mer pålitligt vad gäller informationssäkerhet, billigare och mer praktiskt, även om det kan ta lite tid att sätta upp ett trepartsprotokoll och har sina nackdelar, såsom ytterligare operationer med krypteringsnycklar. TC är snabbare än DECO, men en sårbarhet i samband med en sidokanalattack gör den mottaglig för förlust av integritet. Det bör beaktas att DECO introducerades i januari 2020 och att det inte har gått tillräckligt med tid för att betrakta det som säkert. Town Crier har varit under attack i 4 år och har genomgått många tester, så dess användning i många projekt är motiverad.

Källa: will.com