Sot është që vetëm një person i lenë nuk ka shkruar për teknologjinë blockchain, kriptovalutat dhe sa të mrekullueshme janë këto. Por në këtë artikull nuk do të ketë lavdërime për këtë teknologji, do të flasim pikërisht për disavantazhet e saj dhe mënyrat për t'i kaluar ato.

Gjatë punës në një nga projektet në kompaninë Altiriks Systems, doli nevoja për një konfirmim të sigurt, të qëndrueshëm ndaj censurës të të dhënave nga një burim të jashtëm në blockchain. Duhej të konfirmoheshin ndryshimet në regjistrimet e një sistemi të tretë dhe në bazë të këtyre ndryshimeve të ekzekutohej një degë specifike në logjikën e kontratës smart. Detyra në shikim të parë duket mjaft triviale, por kur rezultati i saj ndikon në gjendjen financiare të një prej palëve pjesëmarrëse në proces, dalin kërkesa shtesë. Para së gjithash, kjo është besimi përfundimtar në një mekanizëm të tillë validimi. Por le të shkojmë sipas radhës.

Problemi qëndron në faktin se blockchain është një objekt autonom, i mbyllur, prandaj kontratat smart brenda blockchain-it nuk dinë asgjë për botën e jashtme. Në të njëjtën kohë, kushtet e kontratave smart shpesh lidhen me informacionin për ngjarje të vërteta (vonesa fluturimi, kursi i valutorëve, etj.). Për të funksionuar siç duhet, informacioni i marra jashtë blockchain-it duhet të jetë i besueshëm dhe i verifikuar. Ky problem zgjidhet duke përdorur orakuj, të tillë si Town Crier dhe DECO. Këta orakuj lejojnë që kontratat smart në rrjetin blockchain të besojnë informacionin nga një server web të verifikuar, mund të thuhet se janë furnizues të informacionit të besueshëm.

Orakuj

Mendoni se kontrata smart kryen një transferim prej 0.001 btc në portofolin tuaj bitcoin në rastin e fitores së klubit tuaj të preferuar të futbollit në Kupën e Rusisë. Në rastin e një fitoreje të vërtetë, kontratës smart i nevojitet të kalojë informacionin mbi cilin klub ka fituar, dhe këtu lind një sërë problemesh: ku ta gjejmë këtë informacion, si ta kalojmë atë në mënyrë të sigurt në kontratën smart dhe si të sigurohemi që informacioni që ka arritur në kontratën smart në të vërtetë përputhet me realitetin?

Në çështjen e burimit të informacionit mund të jenë 2 skenarë: lidhja e një smart kontrate me një uebfaqe të besuar, e cila ruan informacionin për rezultatet e ndeshjeve në mënyrë të centralizuar, dhe opsioni i dytë — lidhja e disa uebfaqeve në të njëjtën kohë dhe më pas zgjedhja e informacionit nga shumica e burimeve që ofrojnë të dhëna të njëjta. Për të siguruar saktësinë e informacionit, përdoren orakuj, për shembull Oraclize, që përdor TLSNotary (modifikimi i TLS për të provuar origjinalitetin e të dhënave). Por për Oraclize ka mjaft informacion në Google, dhe në Habr ka disa artikuj, sot do të flas për orakujt që përdorin një qasje pak më ndryshe për të transmetuar informacion: Town Crier dhe DECO. Artikulli përmban përshkrimin e principeve të funksionimit të dy orakujve, si dhe një krahasim të detajuar.

Town Crier

Town Crier (TC) u paraqit nga IC3 (Iniciativa për Kriptovalutat dhe Kontratat) në vitin 2016 në CCS’16. Ideja kryesore e TC: të transmetojë informacionin nga uebfaqja te smart kontrata dhe të sigurojë se informacioni i dorëzuar nga TC është i njëjtë me atë në uebfaqe. TC përdor TEE (Mjedisi i Besueshëm i Ekzekutimit) për të garantuar autenticitetin e pronësisë së të dhënave. Në versionin origjinal, TC përshkruan funksionimin me Intel SGX.
Town Crier përbëhet nga një pjesë brenda blockchain dhe një pjesë brenda vetë sistemit operativ — TC Server.

TC Contract ndodhet në blockchain dhe vepron si front end për TC. Ai pranon kërkesat nga CU (smart kontrata e përdoruesit) dhe kthen përgjigjen nga TC Server. Brenda TC Server ndodhet Relay, i cili krijon një lidhje midis enklavës dhe internetit (trafik me dy drejtime) dhe lidh enklavën me blockchain. Enclave përmban progencl, i cili është kodi që ekzekuton kërkesat nga blockchain dhe kthen mesazhe në blockchain me një nënshkrim digjital, progencl përmban një pjesë të kodit të smart kontratës dhe në thelb ekzekuton disa nga funksionet e saj.

Enklava Intel SGX mund të konsiderohet si një bibliotekë e përbashkët me API, e cila funksionon përmes ecall. Ecall transferon kontrollin në enklavë. Enklava ekzekuton kodin e saj derisa të përfundojë ose të ndodhë një përjashtim. Për thirrjen e funksioneve, të përcaktuara jashtë enklavës, përdoren ocall. Ocall ekzekutohet jashtë enklavës dhe trajtohet prej saj si një thirrje e pasigurt. Pas përfundimit të ocall, kontrolli kthehet në enklavë.

Në pjesën Enclave konfigurimi i kanalit të sigurt me serverin web, Enclave vetë kryen TLS handshake me serverin e synuar dhe kryen të gjitha operacionet kriptografike brenda vetes. Biblioteka TLS (mbedTLS) dhe kodi HTTP në versionin e reduktuar janë eksportuar në mjedisin SGX. Po ashtu, Enclave përmban certifikatat e root CA (koleksion të certifikatave) për të verifikuar certifikatat e serverëve të largët. Request Handler pranon kërkesat datagram në formatin e siguruar nga Ethereum, e dekripton dhe analizojnë. Pastaj gjeneron një transaksion Ethereum, që përmban datagramin e kërkuar, e nënshkruan atë me skTC dhe e dërgon në Relay.

Pjesa Relay përfshin Client Interface, TCP, Blockchain Interface. Client Interface është i nevojshëm për attestimin e kodit të Enclave dhe komunikimin me klientin. Klienti dërgon një kërkesë për attestim përmes ecall dhe merr një timestamp, i nënshkruar me skTC, së bashku me att (nënshkrimin e attestimit), më pas att konfirmohet përmes Intel Attestation Service (IAS), dhe timestamp verifikohet nga shërbimi i besueshëm të kohës. Blockchain Interface kontrollon kërkesat e pranuara dhe vendos transaksionet në blockchain për dërgimin e datagramëve. Geth është klienti zyrtar i Ethereum dhe lejon Relay të ndërveprojë me blockchain përmes thirrjeve RPC.

Duke punuar me TEE, TC lejon të aktivizohen disa Enclaves paralelisht, duke rritur kështu shpejtësinë e përpunimit të informacionit me 3 herë. Nëse me një Enclave në punë shpejtësia ishte 15 tx/sec, atëherë me 20 Enclaves të aktivizuara paralelisht shpejtësia rritet deri në 65 tx/sec; për krahasim, shpejtësia maksimale e punës në blockchain bitcoin është 26 tx/sec.

DECO

DECO (Decentralized Oracles for TLS) u prezantua në CCS’20, punon me faqet që përkrahin lidhjen TLS. Siguron konfidencialitetin dhe integritetin e të dhënave.
DECO me TLS përdor enkriptimin simetrik, kështu që klienti dhe serveri web kanë çelësat e enkriptimit, dhe klienti, nëse dëshiron, mund të falsifikojë të dhënat e sesionit TLS. Për të zgjidhur këtë problem, DECO përdor një protokoll të trefishtë të dorëzimit midis prover (kontraktës inteligjente), verifier (orakulli) dhe serverit web (burimi i të dhënave).

Parimi i funksionimit të DECO përfshin që provuesi (prover) të marrë një pjesë të të dhënave D dhe të konfirmojë përverifikuesin (verifier) që D ka ardhur nga serveri TLS S. Një tjetër problem është se TLS nuk nënshkruan të dhëna dhe është e vështirë për klientin TLS të provojë se të dhënat janë marrë pikërisht nga ai server (vështirësia e provanancës).

Në protokollin DECO, përdoren çelësat e enkriptimit KEnc dhe KMac. Klienti dërgon një kërkesë Q në serverin web, përgjigja nga serveri R vjen në formë të enkriptuar, por klienti dhe serveri kanë të njëjtët KMac, dhe klienti mund të falsifikojë mesazhin TLS. Zgjidhja nga DECO është që të "fshehë" KMac nga klienti (prover), derisa ai të përgjigjet në kërkesë. Tani KMac është i ndarë midis prover dhe verifier — KpMac dhe KvMac. Serveri merr KMac për enkriptimin e përgjigjes duke përdorur operacionin mbi pjesët e çelësit KpMac ⊕ KvMac = KMac.

Duke vendosur një dorëheqje trefishtë, shkëmbimi i të dhënave midis klientit dhe serverit do të zhvillohet me një garantim sigurie.

Duke folur për sistemet e oracleve të decentralizuara, nuk mund të mos përmendim Chainlink, i cili synon të krijojë një rrjet oracle të decentralizuar të nyjeve, të pajtueshme me Ethereum, Bitcoin dhe Hyperledger, duke marrë parasysh modularitetin: çdo pjesë e sistemit mund të përditësohet. Në të njëjtën kohë, për të siguruar sigurinë, Chainlink ofron që çdo oracle që merr pjesë në detyrë të lëshojë një kombinim çelësash (të hapur dhe të mbyllur). Çelësi i mbyllur përdoret për të gjeneruar një nënshkrim të pjesshëm, i cili përmban zgjidhjen e tyre për kërkesën e të dhënave. Për të marrë përgjigjen, është e nevojshme kombinimi i të gjitha nënshkrimeve të pjesëshme të oracleve të rrjetit.

Chainlink planifikon të realizojë një PoC fillestar DECO me fokus në aplikacionet e financave të decentralizuara, si Mixicles. Në momentin e shkruar të këtij artikulli, doli një lajm në Forbes, se Chainlink kishte blerë DECO nga Universitete Cornell.

Sulmet ndaj oracleve

Nga perspektiva e sigurisë informative, janë shqyrtuar sulmet e mëposhtme ndaj Town Crier:

1. Injeksioni i kodit të paligjshëm të kontratave të zgjuara në nyjat TEE.
   Thelbi i sulmit: dërgimi në TEE i një kodi të dhënë gabim të kontratës së zgjuar, në këtë mënyrë, që një sulmues, i cili ka akses në nyjë, do të kishte mundësi të realizonte kontratën e tij (të mashtruar) mbi të dhënat e dekoduar. Megjithatë, vlerat e kthyera do të jenë të enkriptuara me çelësin privat, dhe opsioni i vetëm për akses në të tilla të dhëna është rrjedhja e tekstit të enkriptuar gjatë kthimit/ekstraktimit.
   Mbrojtja nga ky sulm përfshin verifikimin nga enklava e saktësisë së kodit në adresën aktuale. Kjo mund të arrihet përmes një skeme adresimi, ku adresa e kontratës përcaktohet duke hash-uar kodin e kontratës.

2. Ndryshimet në enkriptimin e gjendjes së kontratës lëshojnë.
   The essence of the attack: Node owners, where smart contracts are executed, have access to the contract state in encrypted form outside the enclave. An attacker who gains control of a node can compare the contract state before and after the transaction execution and can determine which arguments were input and which specific method of the smart contract was used, as the smart contract code and its technical specifications are publicly available.
   Protection in ensuring the reliability of the node itself.

3. Ataqet mbi kanalin anësor.
   Një tip i veçantë sulmesh që përdor mbikëqyrjen e aksesit në memorien dhe cache-in e enklavës në skenarë të ndryshëm. Një shembull i tillë sulmi është Prime and Probe.
   
   Procedura e kryerjes së sulmit:

   • t0: Sulmuesi mbush gjithë cache-in e të dhënave të procesit viktimë.
   • t1: Vikimja ekzekuton kodin me qasje në memorien që varen nga të dhënat e fshehta të viktimës (çelësat kriptografikë). Zgjedhja e lined cache bëhet sipas vlerës keybit. Në shembullin në figurë, keybit = 0 dhe adresa X është lexuar në lined cache 2. Të dhënat e ruajtura në X ngarkohen në cache, duke përjashtuar të dhënat që ishin aty më parë.
   • t2: Sulmuesi kontrollon se cilat nga linjat e tij të cache-it janë përjashtuar — linjat që përdoren nga viktima. Kjo bëhet përmes matjes së kohës së aksesit. Duke përsëritur këtë operacion për secilin keybit, sulmuesi merr gjithë çelësin.

Mbrojtja nga sulmi: Intel SGX ka mbrojtje nga sulmet anësore, e cila ndalon mbikëqyrjen e ngjarjeve që lidhen me cache-in, por sulmi Prime and Probe do të kalojë gjithsesi, pasi sulmuesi vëzhgon ngjarjet e cache-it të procesit të tij dhe ndan cache-in me viktimën.

Prandaj, për momentin nuk ka mbrojtje të besueshme ndaj këtij sulmi.

Së bashku me to, janë të njohura edhe sulmet e tipit Spectre dhe Foreshadow (L1TF), të ngjashme me Prime and Probe. Ato lejojnë leximin e të dhënave nga cache-i përmes një kanali anësor. Ka mbrojtje për dobësinë Spectre-v2, e cila funksionon kundër këtyre dy sulmeve.

Në lidhje me DECO, dorëzimi i tre anëtarëve ofron garantimin e sigurisë:

1. Prover Integrity: një prover i kompromituar nuk mund të falsifikojë informacionin mbi origjinën e serverit dhe nuk mund të bëjë që serveri të pranojë kërkesa të papërfillshme ose të përgjigjet gabim në kërkesa të vlefshme. Kjo realizohet përmes modeleve të kërkesave midis serverit dhe proverit.
2. Verifier Integrity: një verifier i comprometuar nuk mund të bëjë që proveri të marrë përgjigje të gabuara.
3. Koncesioni: Verifikuesi i thyer studion vetëm informacionin publik (kërkesën, emrin e serverit).

Në DECO mund të ketë vetëm vulnerabilitete të lidhura me injeksionin e trafikut. Fillimisht, gjatë dorëzimit të trefishtë verifikuesi mund të përcaktojë identitetin e serverit përmes nonce të freskët. Megjithatë, pas dorëzimit verifikuesi duhet të mbështetet në treguesit e nivelit rrjetor (IP-адреса). Kështu, lidhja mes verifikuesit dhe serverit duhet të mbrohet nga injeksioni i trafikut. Kjo arrihet përmes përdorimit të Proxy.

Krahasimi i orakujve

Town Crier bazohet në punën me një enklavë në pjesën e serverit, ndërsa DECO lejon të verifikohet autenticiteti i burimeve të të dhënave përmes dorëzimit të trefishtë dhe kriptimit të të dhënave me çelësa kriptografikë. Krahasimi i të dhënave të orakujve është bërë sipas kritereve të mëposhtme: performanca, siguria, kostoja dhe prakticiteti.

Town Crier
DECO

performanca
Më shpejt (0.6s për të përfunduar)
Më ngadalë (10.50s për të përfunduar protokollin)

siguria
Më pak i sigurt
Më i sigurt

çmimi
Më i shtrenjtë
Më i lirë

prakticiteti
Kërkon hardware të veçantë
Funksionon me çdo server që mbështet TLS

Performanca: Për të punuar me DECO kërkohet konfigurimi i dorëzimit të trefishtë, duke u konfiguruar përmes LAN kjo merr 0.37 sekonda, për ndërveprimin pas vendosjes së lidhjes është efikas 2PC-HMAC (0.13s për të shkruar). Performanca e DECO varet nga setet e disponueshme të çelësave TLS, madhësia e të dhënave personale dhe kompleksiteti i provave për aplikacionin specifik. Në shembullin e aplikacionit të opsioneve binar të IC3: përfundimi i protokollit përmes LAN zgjat rreth 10.50 sekonda. Për krahasim, Town Crier ka nevojë për rreth 0.6 sekonda për të realizuar një aplikacion të ngjashëm, pra rreth 20 herë më shpejt se DECO. Në kushte të barabarta, TC do të jetë më i shpejtë.

Siguria: Sulmet ndaj enklavës Intel SGX (sulmet anësore) funksionojnë dhe mund të dëmtojnë realisht pjesëmarrësit e kontratës inteligjente. Në lidhje me DECO, mund të ketë sulme të lidhura me injeksionin e trafikut, por përdorimi i proxy e neutralizon këto sulme. Prandaj, DECO është më i sigurt.

Çmimi: Kostoja e pajisjeve që mbështesin punën me Intel SGX është më e lartë se kostoja e konfigurimit të protokollit në DECO. Prandaj, TC është më i shtrenjtë.

Prakticiteti: Për të punuar me Town Crier, është e nevojshme një pajisje speciale që mbështet TEE. Për shembull, Intel SGX mbështetet në procesorët e gjeneratës së gjashtë dhe më të reja të familjes Intel Core. DECO, nga ana tjetër, lejon punimin me çdo pajisje, megjithëse ka një konfigurim DECO që përdor TEE. Procesi i konfigurimit të dorëzimit të trepalësh në DECO mund të marrë njëkohësisht, por kjo nuk është asgjë krahasuar me kufizimin hardware për TC, prandaj DECO është më praktik.

Përfundim

Duke shqyrtuar dy orakujt veçmas dhe duke i krahasuar ata sipas katër kriteresh, është e qartë se Town Crier humb ndaj DECO në tre nga katër pika. DECO është më i besueshëm në aspektin e sigurisë informative, është më i lirë dhe më praktik, ndonëse konfigurimi i protokollit të dorëzimit të trepalësh mund të marrë disa kohë dhe ka disavantazhe të veta, për shembull, operacione shtesë me çelësat e enkriptimit. TC punon më shpejt se DECO, por dobësia që lidhet me sulmin nga kanalet e anashkalimit e bën atë të rrezikshëm për humbjen e privatësisë. Duhet të kemi parasysh se DECO u prezantua në janar 2020, dhe nuk ka kaluar ende mjaft kohë për ta konsideruar atë të sigurt. Town Crier është sulmuar tashmë për 4 vjet dhe ka kaluar përmes shumë kontrolleve, kështu që përdorimi i tij në shumë projekte është i justifikuar.

Burimi: habr.com