Idag har bara de lata ännu inte skrivit om blockchain-teknologi, kryptovalutor och hur fantastiskt det är. Men i den här artikeln kommer det inte att handla om att hylla denna teknologi, utan snarare dess nackdelar och sätt att åtgärda dem.

Under arbetet med ett av projekten på Altirix Systems uppstod en uppgift som handlade om skyddad, censurstabil bekräftelse av data från en extern blockkedjekälla. Det var nödvändigt att bekräfta ändringar i poster från ett tredje system och baserat på dessa ändringar genomföra en viss gren i logiken för smarta kontrakt. Vid första anblicken verkar uppgiften ganska trivial, men när resultatet av dess utförande påverkar den ekonomiska situationen för en av parterna i processen, tillkommer ytterligare krav. Först och främst handlar det om ett omfattande förtroende för en sådan valideringsmekanism. Men mer om det senare.

Problemet ligger i att blockchain i sig är ett autonomt, slutet objekt, vilket innebär att smarta kontrakt inom blockkedjan inte har någon kännedom om den externa världen. Samtidigt är villkoren för smarta kontrakt ofta kopplade till information om verkliga händelser (flygförseningar, valutakurser osv.). För att smarta kontrakt ska fungera korrekt måste informationen som hämtas utanför blockkedjan vara pålitlig och verifierad. Detta problem löses genom att använda orakler, såsom Town Crier och DECO. Dessa orakler tillåter smarta kontrakt på blockchain-nätverket att lita på information från en verifierad webbserver, man kan säga att de är leverantörer av pålitlig information.

Orakler

Föreställ dig att ett smart kontrakt genomför en överföring av 0,001 btc till din bitcoin-plånbok om ditt favoritfotbollslag vinner den ryska cupen. Vid verklig seger måste smarta kontraktet få information om vilket lag som vann, och här uppstår en rad problem: var ska man få denna information, hur ska den överföras säkert till det smarta kontraktet och hur kan man försäkra sig om att den information som kommer in i det smarta kontraktet faktiskt stämmer överens med verkligheten?

När det gäller informationskällan kan det finnas två scenarier: att koppla en smart kontrakt till en betrodd webbplats där information om matchresultat lagras centraliserat, och det andra alternativet - att koppla flera webbplatser och sedan välja information baserat på de flesta källor som tillhandahåller samma data. För att säkerställa informationens korrekthet används orakler, till exempel Oraclize, som använder TLSNotary (en modifiering av TLS för att bevisa dators autenticitet). Men information om Oraclize är tillräcklig på Google, och det finns flera artiklar på Habré, idag kommer jag att berätta om orakler som använder en något annan metod för informationsöverföring: Town Crier och DECO. Artikeln beskriver principerna för arbetet hos båda oraklerna samt en detaljerad jämförelse.

Town Crier

Town Crier (TC) introducerades av IC3 (The Initiative for CryptoCurrencies and Contracts) 2016 vid CCS’16. Huvudidén med TC är att överföra information från en webbplats till en smart kontrakt och säkerställa att den information som levereras av TC är densamma som på webbplatsen. TC använder TEE (Trusted Execution Environment) för äktheten av dators ägande. I den ursprungliga versionen av TC beskrivs arbetet med Intel SGX.
Town Crier består av en del inom blockkedjan och en del inom själva operativsystemet - TC Server.

TC-kontraktet finns på blockkedjan och fungerar som front end för TC. Den tar emot förfrågningar från CU (användarens smart kontrakt) och returnerar svar från TC Server. Inuti TC Server finns Relay, som etablerar en anslutning mellan enklaven och internet (tvåvägstrafik) och kopplar enklaven med blockkedjan. Enklaven innehåller progencl, som är koden som utför förfrågningar från blockkedjan och returnerar meddelanden till blockkedjan med en digital signatur, progencl innehåller en del av smart kontrakts koden och utför i grunden vissa av dess funktioner.

Intel SGX-enklaven kan betraktas som ett gemensamt bibliotek med API som fungerar via ecall. Ecall överför kontrollen till enklaven. Enklaven kör sin kod tills den är klar eller ett undantag inträffar. För att anropa funktioner definierade utanför enklaven används ocall. Ocall utförs utanför enklaven och behandlas av den som ett osäker anrop. Efter att ocall har genomförts, återgår kontrollen till enklaven.

I Enclave konfigureras en säker kanal med webbservern; Enclaven själv utför TLS handshake med måservern och genomför alla kryptografiska operationer internt. TLS-biblioteket (mbedTLS) och HTTP-koden har exporteras i en reducerad version till SGX-miljön. Enclaven innehåller också root CA-certifikat (en samling certifikat) för att verifiera certifikat från externa servrar. Request Handler tar emot datagramförfrågningar i det format som tillhandahålls av Ethereum, dekrypterar det och analyserar. Den genererar sedan en Ethereum-transaktion som innehåller det begärda datagrammet, signerar det med skTC och vidarebefordrar det till Relay.

Relay-delen omfattar Client Interface, TCP, Blockchain Interface. Client Interface behövs för att attestera Enclave-koden och för kommunikation med klienten. Klienten skickar en begäran om attestering via ecall och får en tidsstämpel som är signerad med skTC tillsammans med att (attesteringssignatur), som sedan bekräftas via Intel Attestation Service (IAS), medan tidsstämpeln verifieras av en pålitlig tidsservice. Blockchain Interface kontrollerar inkommande förfrågningar och registrerar transaktioner i blockkedjan för att leverera datagram. Geth är den officiella Ethereum-klienten som gör det möjligt för Relay att interagera med blockkedjan via RPC-anrop.

Genom att arbeta med TEE tillåter TC att köra flera Enclaves parallellt, vilket ökar hastigheten för informationsbehandling med 3 gånger. Om hastigheten med en fungerande Enclave var 15 tx/sec, så ökar hastigheten upp till 65 tx/sec med 20 parallellt körda Enclaves; till exempel är den maximala hastigheten i Bitcoin-blockkedjan 26 tx/sec.

DECO

DECO (Decentralized Oracles for TLS) presenterades på CCS’20 och fungerar med webbplatser som stödjer TLS-anslutning. Det säkerställer konfidentialitet och dataintegritet.
DECO med TLS använder symmetrisk kryptering, vilket innebär att både klienten och webbservern har krypteringsnycklar, och klienten kan, om så önskas, fuska med TLS-sessionens data. För att lösa detta problem använder DECO ett tredelat handskakningsprotokoll mellan prover (smartkontrakt), verifierare (oracle) och webbserver (datakälla).

DECO:s arbetsprincip är att verifieraren (prover) får en del av data D och bekräftar för verifieraren (verifier) att D kom från TLS-servern S. Ett annat problem är att TLS inte signerade data, vilket gör det svårt för TLS-klienten att bevisa att data verkligen mottogs från den servern (provenance difficulty).

I protokollet DECO används nycklarna KEnc och KMac. Klienten skickar förfrågan Q till webbserver, svaret från servern R kommer i krypterad form, men både klienten och servern innehar samma KMac, och klienten kan förfalska TLS-meddelandet. Lösningen från DECO är att "dölja" KMac från klienten (prover) tills denne svarar på förfrågan. Nu är KMac delad mellan prover och verifierare — KpMac och KvMac. Servern får KMac för att kryptera svaret genom en operation på nyckeldelarna KpMac ⊕ KvMac = KMac.

Genom att ställa in en trepartshandshake kommer datakommunikationen mellan klienten och servern att genomföras med säkerhetsgaranti.

När man pratar om system för decentraliserade orakel får man inte glömma Chainlink, som strävar efter att skapa ett decentraliserat nätverk av orakelnoder som är kompatibelt med Ethereum, Bitcoin och Hyperledger, med moduläritet i åtanke: varje del av systemet kan uppdateras. För att säkerställa säkerhet erbjuder Chainlink varje oracle som deltar i uppdraget att utfärda en nyckelkombination (öppen och privat). 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 krävs en kombination av alla orakels nätverks partiella signaturer.

Chainlink planerar att genomföra en första PoC DECO med fokus på decentraliserade finansiella applikationer som Mixicles. Vid tidpunkten för skrivandet publicerades en nyhet på Forbes om att Chainlink har förvärvat DECO från Cornell University.

Attacker mot orakel

Ur perspektivet informationssäkerhet har följande attacker mot Town Crier övervägts:

1. Rogue smart-contract kodinjektion på TEE-noder.
   Angreppets kärna: att överföra uppenbart felaktig smart-contractkod till TEE, vilket innebär att en angripare som fått tillgång till noden kommer att kunna köra sin egen (bedrägliga) smart-contract på dekrypterade data. Emellertid kommer de återlämnade värdena att krypteras med den privata nyckeln, och det enda sättet att få tillgång till sådan data är genom läckage av den krypterade texten vid återlämnandet/utmatningen.
   Skydd mot denna attack är att kontrollera koden som finns på den aktuella adressen av enclaven. Detta kan uppnås genom en adresseringsschema där kontraktsadressen definieras genom att hashkoda kontraktskoden.

2. Contract state ciphertext changes leak.
   Angreppets kärna: Ägare av noder där smarta kontrakt körs har åtkomst till contract state i krypterad form utanför enclaven. En angripare som får kontroll över en nod kan jämföra contact state före och efter transaktionen och kan avgöra vilka argument som införts och vilken specifik metod av det smarta kontraktet som använts, eftersom själva koden för det smarta kontraktet och dess tekniska specifikationer är offentligt tillgängliga.
   Skydd för att säkerställa nodens tillförlitlighet.

3. Sidokanalattacker.
   En särskild typ av attacker som använder övervakning av åtkomst till minne och cache i enclaven i olika scenarier. Ett exempel på en sådan attack är Prime and Probe.
   
   Ordningen för att utföra attacken:

   • t0: Angriparen fyller hela datacachen för offrets process.
   • t1: Offret kör kod med minnesanrop som beror på konfidentiella data från offret (kryptografiska nycklar). Valet av cachelinje görs baserat på värdet av keybit. I exemplet på bilden, keybit = 0 och adress X har lästs i cachelinje 2. Data som lagras i X laddas in i cachen, vilket verdrar data som redan fanns där.
   • t2: Angriparen kontrollerar vilka av hans cachelinjer som har blivit verdrivna – de linjer som använts av offret. Detta görs genom att mäta åtkomsttiden. Genom att upprepa denna operation för varje keybit får angriparen hela nyckeln.

Skydd mot attacken: I Intel SGX finns skydd mot sidokanalattacker som förbjuder övervakning av cache-relaterade händelser, men attacken Prime and Probe kommer ändå att lyckas, eftersom angriparen observerar cachehändelser för sin egen process och delar cache med offret.

Således finns det för närvarande inget tillförlitligt skydd mot denna attack.

Även attacker av typen Spectre och Foreshadow (L1TF) är kända, vilka liknar Prime and Probe. De tillåter att läsa data från cacheminnet genom en sidokanal. Skydd mot sårbarhet Spectre-v2 finns, vilket fungerar mot dessa två attacker.

I relation till DECO ger det tredelade handslaget säkerhetsgaranti:

1. Prover Integrity: En hackad prover kan inte förfalska information om ursprunget till servern och kan inte få servern att ta emot ogiltiga förfrågningar eller svara felaktigt på giltiga förfrågningar. Detta åstadkoms genom förfrågningsmönster mellan server och prover.
2. Verifier Integrity: En hackad verifier kan inte få prover att få felaktiga svar.
3. Sekretess: Den hackade verifieraren granskar endast offentlig information (förfrågan, servernamn).

I DECO finns endast sårbarheter relaterade till trafikinjicering. Till en början, vid den tredubbla handskakningen kan verifieraren fastställa serverns identitet genom en ny nonce. Men efter handskakningen måste verifieraren förlita sig på indikatorer på nätverksnivå (IP-adresser). Således måste förbindelsen mellan verifieraren och servern skyddas mot trafikinjicering. Detta uppnås genom att använda en proxy.

Jämförelse av oraklar

Town Crier är baserat på arbete med en enclave på serversidan, medan DECO tillåter autentisering av dators ursprung genom tredubbla handskakningar och kryptering av data med kryptografiska nycklar. Jämförelsen av oraklars data genomfördes utifrån följande kriterier: prestanda, säkerhet, kostnad och praktisk användbarhet.

Town Crier
DECO

prestanda
Snabbare (0,6 s för att slutföra)
Långsammare (10,50 s för att slutföra protokollet)

säkerhet
Mindre säker
Mer säker

kostnaden
Dyrare
Billigare

praktisk användbarhet
Kräver specialiserad hårdvara
Fungerar med vilken server som helst som stöder TLS

Prestanda: För att arbeta med DECO krävs en konfiguration av tredubbla handskakningar, när man installerar via LAN tar det 0,37 sekunder, för interaktion efter etablering av förbindelse är 2PC-HMAC effektiv (0,13 s vid skrivning). DECO:s prestanda beror på tillgängliga TLS-krypteringsuppsättningar, storleken på personuppgifterna och komplexiteten i bevisen för en viss applikation. Med exemplet från IC3:s binära alternativapplikation: att slutföra protokollet via LAN tar cirka 10,50 s. I jämförelse kräver Town Crier cirka 0,6 sekunder för att utföra en liknande applikation, alltså ungefär 20 gånger snabbare än DECO. Under lika förhållanden kommer TC att vara snabbare.

Säkerhet: Angrepp på Intel SGX-enklaven (side-channel attacks) fungerar och kan orsaka verklig skada för deltagarna i smart kontrakt. Relaterat till DECO är angrepp relaterade till trafikinjicering möjliga, men användningen av proxy minskar sådana angrepp. Således är DECO mer säker.

Kostnad: Kostnaden för hårdvara som stöder arbete med Intel SGX är högre än kostnaden för att konfigurera protokollet i DECO. Därför är TC dyrare.

Praktisk användbarhet: För att arbeta med Town Crier krävs speciell utrustning som stöder TEE. Till exempel stöds Intel SGX på processorer av Intel Core 6:e generationen och nyare. DECO å sin sida fungerar med all utrustning, även om det finns en DECO-konfiguration som använder TEE. Vid konfigurationen kan DECO:s trevägshandslag ta lite tid, men det står inte i jämförelse med hårdvarubegränsningen för TC, vilket gör DECO mer praktiskt.

Slutsats

Genom att granska de två oraklen separat och jämföra dem utifrån fyra kriterier blir det tydligt att Town Crier underpresterar gentemot DECO på tre av fyra punkter. DECO är mer pålitligt när det gäller informationssäkerhet, billigare och mer praktiskt, även om konfigurationen av det tredubbla protokollet kan ta lite tid och har sina nackdelar, till exempel ytterligare operationer med krypteringsnycklar. TC fungerar snabbare än DECO, men sårbarheten kopplad till side-channel attack gör att det riskerar att förlora konfidentialitet. Det bör noteras att DECO presenterades i januari 2020, och det har ännu inte gått tillräckligt med tid för att anse det som säkert. Town Crier har redan utsatts för attacker i 4 år och genomgått många tester, så dess användning i många projekt är berättigad.

Källa: habr.com