Astăzi, doar cei leneși nu au scris despre tehnologia blockchain, criptomonede și cât de tare este. Însă în acest articol nu va fi o laudă pentru această tehnologie, ci despre deficiențele ei și modalitățile de a le remedia.
În timpul lucrului la unul dintre proiectele din compania Altirix Systems, a apărut sarcina de a avea o confirmare protejată și rezistentă la cenzură a datelor provenite dintr-o sursă externă pentru blockchain. Era necesar să se confirme modificările în înregistrările unui sistem terț și, pe baza acestor modificări, să se execute o anumită ramificare în logica smart contractului. Sarcina pare destul de simplă la prima vedere, dar când rezultatul său afectează starea financiară a uneia dintre părțile implicate în proces, apar cerințe suplimentare. În primul rând, este vorba despre o încredere totală în acest mecanism de validare. Dar să le luăm pe rând.
Problema constă în faptul că blockchain-ul, în sine, este un obiect autonom și închis, iar smart contractele din interiorul blockchain-ului nu știu nimic despre lumea exterioară. În același timp, condițiile smart contractelor sunt adesea legate de informații despre evenimente reale (întârzierea unui zbor, cursul valutar etc.). Pentru ca smart contractele să funcționeze corect, informațiile obținute din afara blockchain-ului trebuie să fie fiabile și verificate. Această problemă este rezolvată prin utilizarea oracolelor, cum ar fi Town Crier și DECO. Aceste oracole permit smart contractului din rețeaua blockchain să aibă încredere în informațiile de pe un server web verificat, se poate spune că sunt furnizori de informații de încredere.
Oracole
Imaginați-vă că un smart contract efectuează un transfer de 0.001 btc către portofelul dumneavoastră bitcoin în cazul în care echipa dumneavoastră favorită câștigă Cupa Rusiei. În cazul unei victorii reale, smart contractul trebuie să primească informații despre echipa care a câștigat, iar aici apar mai multe probleme: de unde să obțineți această informație, cum să o transmiteți în siguranță către smart contract și cum să vă asigurați că informațiile transmise către smart contract coincid cu realitatea?
În ceea ce privește sursa de informații, pot exista 2 scenarii: conectarea unui smart contract la un site web de încredere, pe care este stocată centralizat informația despre rezultatele meciurilor, și a doua variantă — conectarea la mai multe site-uri și apoi selectarea informațiilor din majoritatea surselor care oferă date identice. Pentru a ne asigura de corectitudinea informației, se utilizează oracole, cum ar fi Oraclize, care folosește TLSNotary (o modificare TLS pentru a dovedi autenticitatea datelor). Dar despre Oraclize informațiile în Google sunt suficiente, iar pe Habr sunt câteva articole; astăzi voi vorbi despre oracolele care folosesc o abordare puțin diferită în transmiterea informațiilor: Town Crier și DECO. Articolul prezintă descrierea principiilor de funcționare a ambelor oracole, precum și o comparație detaliată.
Town Crier
Town Crier (TC) a fost prezentat de IC3 (The Initiative for CryptoCurrencies and Contracts) în 2016 la CCS’16. Ideea principală a TC: transmiterea informației de la un site web către smart contract și asigurarea că informația livrată de TC este aceeași ca pe site-ul web. TC utilizează TEE (Trusted Execution Environment) pentru autenticitatea proprietății datelor. În varianta sa originală, TC descrie lucrul cu Intel SGX.
Town Crier constă dintr-o parte în interiorul blockchain-ului și o parte în interiorul sistemului de operare — TC Server.
TC Contract se află în blockchain și acționează ca frontend pentru TC. Acesta primește cereri de la CU (smart contractul utilizatorului) și returnează un răspuns de la TC Server. În interiorul TC Server se află Relay, care stabilește o conexiune a enclavei cu internetul (trafic bidirecțional) și leagă enclavea de blockchain. Enclave conține progencl, care este codul care execută cereri din blockchain și returnează mesaje în blockchain cu semnătură digitală; progencl conține o parte a codului smart contractului și, în esență, execută unele dintre funcțiile acestuia.
Enclave-ul Intel SGX poate fi considerat ca o bibliotecă comună cu API, care funcționează prin ecalls. Ecall transmite controlul enclavei. Enclavea își execută codul până când se finalizează sau până când apare o excepție. Pentru a apela funcții definite în afara enclavei, se folosesc ocalls. Ocall se execută în afara enclavei și este tratată de aceasta ca un apel nesigur. După executarea ocall, controlul se întoarce enclavei.
În partea Enclave se configurează canalul sigur cu serverul web, iar enclava realizează singură handshake-ul TLS cu serverul țintă și efectuează toate operațiile criptografice în interiorul său. Biblioteca TLS (mbedTLS) și codul HTTP în variantă redusă sunt exportate în mediu SGX. De asemenea, Enclave conține certificate root CA (o colecție de certificate) pentru a verifica certificatele serverelor externe. Request Handler primește o solicitare datagram în formatul furnizat de Ethereum, o decriptează și o analizează. Apoi generează o tranzacție Ethereum, care conține datagramul solicitat, o semnează cu skTC și o transmite în Relay.
Partea Relay include Client Interface, TCP, Blockchain Interface. Client Interface este necesar pentru atestarea codului enclavei și pentru comunicarea cu clientul. Clientul trimite o solicitare de atestare prin ecall și primește un timestamp, semnat cu skTC împreună cu att (semnătura atestării), ulterior att este validat prin Intel Attestation Service (IAS), iar timestamp-ul este verificat de un serviciu de timp de încredere. Blockchain Interface verifică solicitările primite și plasează tranzacțiile în blockchain pentru livrarea datagramelor. Geth este clientul oficial Ethereum și permite Relay să interacționeze cu blockchainul prin apeluri RPC.
Lucrând cu TEE, TC permite să se ruleze simultan mai multe enclava în paralel, crescând astfel viteza de procesare a informațiilor de 3 ori. Dacă, cu o enclavă activă, viteza era de 15 tx/sec, cu 20 de enclava activate simultan, viteza crește la 65 tx/sec, pentru comparație, viteza maximă de funcționare în blockchainul Bitcoin este de 26 tx/sec.
DECO
DECO (Oracole Decentralizate pentru TLS) a fost prezentat la CCS’20, funcționează cu site-uri care suportă conexiune TLS. Asigură confidențialitatea și integritatea datelor.
DECO cu TLS folosește criptare simetrică, astfel încât clientul și serverul web au chei de criptare, iar clientul, dacă dorește, poate falsifica datele sesiunii TLS. Pentru a rezolva această problemă, DECO folosește un protocol de handshake în trei părți între prover (smart contract), verifier (oracle) și web-server (sursa de date).
Principiul de funcționare al DECO constă în faptul că verificatorul (prover) obține o parte din date D și confirmă verifier-ului (verifier) că D provine de la serverul TLS S. O altă problemă este că TLS nu semnează datele și clientului TLS îi este greu să demonstreze că datele au fost obținute de la acel server (dificultate de proveniență).
În protocolul DECO sunt utilizate cheile de criptare KEnc și KMac. Clientul trimite o cerere Q către server web, iar răspunsul de la server R vine criptat, dar atât clientul, cât și serverul au aceleași KMac, permițând clientului să falsifice mesajul TLS. Soluția oferită de DECO este de a „ascunde” KMac de client (prover) până când acesta răspunde cererii. Acum KMac este împărțit între prover și verifier — KpMac și KvMac. Serverul primește KMac pentru a cripta răspunsul prin operația asupra părților cheii KpMac ⊕ KvMac = KMac.
Configurând un handshake tripartit, schimbul de date între client și server se va desfășura cu garanția securității.
Vorbind despre sistemele de oracle-uri descentralizate, nu se poate să nu menționăm Chainlink, care își propune să creeze o rețea descentralizată de noduri oracle compatibile cu Ethereum, Bitcoin și Hyperledger, ținând cont de modularitate: fiecare parte a sistemului poate fi actualizată. În plus, pentru a asigura securitatea, Chainlink oferă fiecărui oracle participant la sarcină combinația de chei (publică și privată). Cheia privată este utilizată pentru a genera o semnătură parțială, care conține soluția lor la cererea de date. Pentru a obține răspunsul este necesară combinarea tuturor semnăturilor parțiale ale oracle-urilor din rețea.
Chainlink intenționează să realizeze un PoC inițial DECO axat pe aplicații financiare descentralizate, cum ar fi Mixicles. La momentul redactării acestui articol, a apărut o știre pe Forbes, conform căreia Chainlink a achiziționat DECO de la Universitatea Cornell.
Atacuri asupra oracle-urilor
Din perspectiva securității informațiilor, au fost analizate următoarele atacuri asupra Town Crier:
Injecția de cod malițios pe nodurile TEE prin smart contracte.
Esenta atacului: transmiterea unui cod de smart contract eronat în TEE, astfel încât un atacator care ar avea acces la nod ar putea executa propriul său smart contract (fraudulent) pe datele decriptate. Cu toate acestea, valorile returnate vor fi criptate cu cheia privată, iar singura modalitate de acces la aceste date constă în scurgerea textului criptat la returnare/încărcare.
Protecția împotriva acestui atac constă în verificarea de către enclavă a corectitudinii codului aflat la adresa curentă. Acest lucru poate fi realizat printr-un sistem de adresare, unde adresa contractului este definită prin hash-ul codului contractului.Schimbările în textul criptat al stării contractului scurg.
Esenta atacului: Proprietarii nodurilor care execută smart contracte au acces la contract state în formă criptată în afara enclavei. Un atacator, obținând controlul peste nod, poate compara contract state înainte și după execuția unei tranzacții și poate determina ce argumente au fost introduse și ce metodă a smart contractului a fost utilizată, deoarece codul smart contractului și specificațiile sale tehnice sunt publice.
Protecție în asigurarea fiabilității nodului în sine.Atacuri prin canal lateral.
Un tip special de atacuri care implică monitorizarea accesului la memoria și cache-ul enclavei în diferite scenarii. Un exemplu de astfel de atac este Prime and Probe.
Procedura de efectuare a atacului:- t0: Atacatorul umple tot cache-ul de date al procesului victimei.
- t1: Victima execută cod cu apeluri la memorie care depind de datele confidențiale ale victimei (chei criptografice). Se alege cache line pe baza valorii keybit. În exemplul din imagine, keybit = 0 și s-a citit adresa X în cache line 2. Datele stocate în X sunt încărcate în cache, înlocuind datele care au fost acolo înainte.
- t2: Atacatorul verifică care dintre liniile sale de cache au fost înlocuite — liniile utilizate de victimă. Acest lucru se face prin măsurarea timpului de acces. Repetând această operațiune pentru fiecare keybit, atacatorul obține întreaga cheie.
Protecție împotriva atacului: Intel SGX are protecție împotriva atacurilor prin canal lateral, care interzice monitorizarea evenimentelor legate de cache, dar atacul Prime and Probe va reuși în continuare, deoarece atacatorul observă evenimentele de cache ale procesului său și împărtășește cache-ul cu victima.
Astfel, în prezent nu există o protecție sigură împotriva acestui atac.
De asemenea, sunt cunoscute atacuri de tip Spectre și Foreshadow (L1TF), asemănătoare cu Prime and Probe. Acestea permit citirea datelor din cache prin intermediul unui canal lateral. Este prevăzută o protecție împotriva vulnerabilității Spectre-v2, care funcționează împotriva acestor două atacuri.
În raport cu DECO, strângerea de mâini în trei părți oferă o garanție de securitate:
- Integritatea Proverului: un prover spart nu poate falsifica informațiile despre originile serverului și nu poate determina serverul să accepte cereri nevalide sau să răspundă greșit la cereri valide. Acest lucru se poate realiza prin modele de cereri între server și prover.
- Integritatea Verificatorului: un verificator spart nu poate determina proverul să primească răspunsuri greșite.
- Confidențialitate: Verificatorul compromis analizează doar informațiile publice (cerere, numele serverului).
În DECO pot exista doar vulnerabilități legate de injectarea traficului. La început, în timpul handshake-ului trilateral, verificatorul poate stabili identitatea serverului folosind un nonce proaspăt. Cu toate acestea, după handshake, verificatorul trebuie să se bazeze pe indicatorii de nivel de rețea (adrese IP). Prin urmare, legătura dintre verificator și server trebuie protejată împotriva injectării trafic. Acest lucru se realizează prin utilizarea unui proxy.
Compararea oracle-urilor
Town Crier se bazează pe lucrul cu un enclave pe partea serverului, iar DECO permite validarea autenticității originii datelor printr-un handshake trilateral și criptarea datelor cu chei criptografice. Compararea datelor oracle-urilor a fost efectuată pe următoarele criterii: performanță, securitate, cost și practicitate.
Town Crier
DECO
performanță
Mai rapid (0,6s pentru finalizare)
Mai lent (10,50s pentru finalizarea protocolului)
securitate
Mai puțin sigur
Mai sigur
prețul
Mai scump
Mai ieftin
practicitate
Necesită hardware special
Funcționează cu orice server care suportă TLS
Performanță: Pentru a lucra cu DECO, este necesar să se configureze un handshake trilateral, configurarea prin LAN durează 0,37 secunde, iar pentru interacțiunea după stabilirea conexiunii, este eficient 2PC-HMAC (0,13 s pentru scriere). Performanța DECO depinde de seturile de cifrare TLS disponibile, de dimensiunea datelor personale și de complexitatea dovezilor pentru o aplicație specifică. De exemplu, pentru aplicația de opțiuni binare de la IC3: finalizarea protocolului prin LAN durează aproximativ 10,50 s. În comparație, Town Crier necesită pentru a realiza o aplicație similară aproximativ 0,6 secunde, adică de aproximativ 20 de ori mai rapid decât DECO. În condiții egale, TC va fi mai rapid.
Securitate: Atacurile asupra enclavei Intel SGX (atacuri de tip side-channel) funcționează și pot provoca daune reale participanților la contractul inteligent. În ceea ce privește DECO, pot exista atacuri legate de injectarea traficului, dar utilizarea unui proxy reduce astfel de atacuri. Prin urmare, DECO este mai sigur.
Preț: Costul echipamentului care suportă funcționarea cu Intel SGX este mai mare decât costul configurării protocolului în DECO. Prin urmare, TC este mai scump.
Practicitate: Pentru a lucra cu Town Crier, este necesară o echipare specială care să suporte TEE. De exemplu, Intel SGX este suportat pe procesoarele din familia Intel Core de a 6-a generație și mai recente. DECO, pe de altă parte, permite lucrul cu orice echipament, deși există o configurație DECO care utilizează TEE. În procesul de configurare, schimbul de chei în trei pași la DECO poate dura ceva timp, însă acest lucru nu se compară cu limitările hardware pentru TC, astfel că DECO este mai practic.
Concluzie
Analizând cele două oracle separat și comparându-le după patru criterii, se observă că Town Crier cedează în fața DECO la trei din cele patru puncte. DECO este mai fiabil din perspectiva securității informațiilor, mai ieftin și mai practic, deși configurarea protocolului în trei pași poate dura ceva timp și are propriile dezavantaje, cum ar fi operațiuni suplimentare cu chei de criptare. TC funcționează mai repede decât DECO, dar vulnerabilitatea asociată cu atacurile de tip side-channel îi expune riscurilor de pierdere a confidențialității. Trebuie să ținem cont că DECO a fost lansat în ianuarie 2020 și nu a trecut suficient timp pentru a-l considera complet sigur. Town Crier a fost supus atacurilor timp de 4 ani și a trecut prin numeroase verificări, astfel că utilizarea sa în multe proiecte este justificată.
Sursa: habr.com
