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; vi kommer att prata om dess brister och sätt att eliminera dem.

Under arbetet med ett av projekten på Altirix Systems, uppstod uppgiften med säker, censurbeständig bekräftelse av data från en källa utanför blockkedjan. Det var nödvändigt att bekräfta ändringar i det tredje systemets register och, baserat på dessa ändringar, exekvera en eller annan gren i den smarta kontraktslogiken. Uppgiften vid första anblicken är ganska trivial, men när den ekonomiska situationen för en av parterna som deltar i processen beror på resultatet av dess genomförande, dyker ytterligare krav upp. För det första är detta 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å de smarta kontrakten inuti blockkedjan vet ingenting om omvärlden. Samtidigt är villkoren för smarta kontrakt ofta relaterade 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 på blockchain-nätverket för att lita på information från en pålitlig webbserver; vi kan säga att dessa är leverantörer av pålitlig information.

Orakel

Föreställ dig att ett smart kontrakt ö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 överföra information om vilken klubb som vann, och här uppstår ett antal problem: var man får tag på denna information, hur man säkert överför den till smartkontraktet och hur man säkerställer att informationen mottagits i det smarta kontraktet är giltigt faktiskt sammanfaller med verkligheten?

När det kommer till informationskällan kan det finnas två scenarier: att koppla ett smart kontrakt till en betrodd webbplats där information om matchresultat 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 ger samma data. För att verifiera informationens riktighet används orakel, till exempel Oraclize, som använder TLSNotary (TLS Notary Modification to Prove the Authenticity of Data). Men det finns tillräckligt med information på Google om Oraclize, och det finns flera artiklar om Habré.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: överför information från en webbplats till ett smart kontrakt och se till att informationen som levereras av TC är densamma som på webbplatsen. TC använder TEE (Trusted Execution Environment) för att autentisera dataägande. Den ursprungliga versionen av TC beskriver hur man arbetar med Intel SGX.
Town Crier består av en del inuti blockkedjan och en del inuti själva OS - TC Server.

TC Contract finns på blockchain och fungerar som frontend för TC. Den accepterar förfrågningar från CU (user smart contract) och returnerar ett svar från TC-servern. Inuti TC-servern finns ett relä, som upprättar en förbindelse mellan enklaven och Internet (dubbelriktad trafik) och kopplar samman enklaven med blockkedjan. Enclave innehåller progencl, vilket är kod 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 körs via ecall. Ecall överför kontrollen till enklaven. Enklaven exekverar sin kod tills den avslutas eller tills ett undantag inträffar. ocall används för att anropa funktioner definierade utanför enklaven. Ocall exekveras utanför enklaven och behandlas som ett otillförlitligt samtal av den. Efter att ocall har utförts, återgår kontrollen till enklaven.

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

Relädelen inkluderar Client Interface, TCP, Blockchain Interface. Klientgränssnittet behövs för att certifiera 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ämpeln verifieras av en betrodd tidstjänst. Blockchain Interface verifierar inkommande förfrågningar och placerar transaktioner på blockchain för leverans av datagram. Geth är en officiell Ethereum-klient och låter Relay interagera med blockkedjan via RPC-samtal.

Genom att arbeta med TEE, låter TC dig köra flera enklaver 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 driftshastigheten i Bitcoin blockchain 26 tx/sek.

DECO

DECO (Decentralized Oracles for TLS) presenterades på CCS'20, arbetar med sajter som stöder TLS-anslutningar. Säkerställer datakonfidentialitet och integritet.
DECO med TLS använder symmetrisk kryptering, så 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).

Sättet DECO fungerar är att verifieraren tar emot en bit av 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 togs emot från exakt rätt server (härkomstsvårigheter).

DECO-protokollet använder KEnc- och KMac-krypteringsnycklar. Klienten skickar en begäran Q till webbservern, svaret från servern R kommer i krypterad form, men klienten och servern äger samma KMac, och klienten kan förfalska TLS-meddelandet. DECOs lösning är att "gömma" KMac från klienten (provaren) tills den svarar på begäran. Nu är KMac uppdelad mellan provare och verifierare - KpMac och KvMac. Servern tar emot KMac för att kryptera svaret med nyckeldelens operation KpMac ⊕ KvMac = KMac.

Genom att sätta upp en trevägshandskakning kommer datautbyte mellan klient och server att utföras med en garanti för säkerhet.

När man talar om ett decentraliserat orakelsystem kan man inte undgå att nämna Chainlink, som syftar till att skapa ett decentraliserat nätverk av orakelnoder som är kompatibelt med Ethereum, Bitcoin och Hyperledger, med hänsyn tagen till modularitet: varje del av systemet kan uppdateras. Samtidigt, för att säkerställa säkerheten, erbjuder Chainlink varje orakel som deltar i uppgiften att utfärda en kombination av nycklar (offentliga och privata). Den privata nyckeln används för att generera en partiell signatur som innehåller deras beslut till databegäran. För att få ett svar är det nödvändigt att kombinera alla delsignaturer för nätverkets orakel.

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

Attacker på orakel

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

1. Rogue smart-kontakt kodinjektion på TEE-noder.
   Kärnan i attacken: att överföra en avsiktligt felaktig smart kontraktskod till TEE, sålunda kommer en angripare som fick tillgång till noden att kunna utföra sitt eget (bedrägliga) smarta kontrakt på den dekrypterade datan. Returvä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 kontraktsadressen 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 har fått kontroll över en nod, kan jämföra kontakttillståndet före och efter transaktionen 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 noden.

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

   • t0: Angriparen fyller hela datacchen för offerprocessen.
   • t1: Offret exekverar kod med minnesåtkomster som beror på offrets känsliga data (kryptografiska nycklar). Cacheraden väljs baserat på nyckelbitvärdet. I exemplet i figuren läses keybit = 0 och adressen X i cache-rad 2. Data som lagras i X laddas in i cachen och förskjuter data som fanns där tidigare.
   • t2: Angriparen kontrollerar vilka av hans cache-rader som har vräkts – 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 en Prime and Probe-attack kommer fortfarande att fungera 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.

Attacker som Spectre och Foreshadow (L1TF), liknande Prime och Probe, är också kända. De låter dig läsa data från cacheminnet via en tredje parts kanal. Skydd mot Spectre-v2-sårbarheten tillhandahålls, vilket fungerar mot två av dessa attacker.

I förhållande till DECO ger trevägshandslaget en garanti för säkerhet:

1. Proverintegritet: En hackad provare kan inte förfalska serverns ursprungsinformation och kan inte få servern att acceptera ogiltiga förfrågningar eller svara felaktigt på giltiga förfrågningar. Detta görs genom förfrågningsmönster mellan server och provare.
2. Verifierarens integritet: En hackad verifierare kan inte få verifieraren att ta emot felaktiga svar.
3. Sekretess: Den hackade verifieraren undersöker endast offentlig information (begäran, servernamn).

I DECO är endast sårbarheter för trafikinjektion möjliga. För det första, med en trevägshandskakning, kan verifieraren fastställa serverns identitet med hjälp av en ny nonce. Efter handskakningen måste dock verifieraren förlita sig på nätverkslagsindikatorer (IP-adresser). Således måste kommunikationen mellan verifieraren och servern skyddas från trafikinjektion. Detta uppnås genom att använda proxy.

Jämförelse av orakel

Town Crier bygger på att arbeta med en enklav i serverdelen, medan DECO låter dig verifiera äktheten av datas ursprung med hjälp av ett trevägshandslag och datakryptering med kryptografiska nycklar. Jämförelse av dessa orakel utfördes enligt följande kriterier: prestanda, 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
Mer säker

kosta
Dyrare
Billigare

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

Hastighetsprestanda: För att arbeta med DECO krävs ett trevägshandslag, vid uppsättning via LAN tar det 0.37 sekunder, för interaktion efter att anslutningen upprättats är 2PC-HMAC effektiv (0,13 s per skrivning). DECOs prestanda beror på tillgängliga TLS-chiffersviter, storleken på privata data och komplexiteten i bevisen för en viss applikation. Att använda den binära optionen från IC3 som ett exempel: att slutföra protokollet via LAN tar cirka 10,50 sekunder. Som jämförelse tar Town Crier cirka 0,6 sekunder att slutföra en liknande applikation, vilket är cirka 20 gånger snabbare än DECO. Allt annat lika kommer TC att bli snabbare.

Безопасность: Attacker på Intel SGX-enklaven (sidokanalsattacker) fungerar och kan orsaka verklig skada på deltagarna i det smarta kontraktet. När det gäller DECO är attacker relaterade till trafikinjektion möjliga, men användningen av en proxy reducerar sådana attacker till ingenting. Därför är DECO säkrare.

Kostnad: Kostnaden för utrustning 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. Enligt installationsprocessen kan DECOs trevägshandskakning ta lite tid, men detta är ingenting jämfört med hårdvarubegränsningen för TC, 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 ur informationssäkerhetssynpunkt, billigare och mer praktiskt, även om det kan ta lite tid att sätta upp ett trepartsprotokoll och har sina nackdelar, till exempel ytterligare operationer med krypteringsnycklar. TC är snabbare än DECO, men sårbarheter i sidokanalsattacker gör den mottaglig för förlust av konfidentialitet. Man måste ta hänsyn till 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 gått igenom många tester, så dess användning i många projekt är motiverad.

Källa: will.com