Այսօր միայն ծույլերը չեն գրել բլոկչեյն տեխնոլոգիայի, կրիպտոարժույթների և այն մասին, թե որքան լավն է այն։ Բայց այս հոդվածը չի գովաբանի այս տեխնոլոգիան, մենք կխոսենք դրա թերությունների և դրանց վերացման ուղիների մասին:
Altirix Systems-ի նախագծերից մեկի վրա աշխատելիս խնդիր առաջացավ ապահով, գրաքննության դիմացկուն տվյալների հաստատում բլոկչեյնից դուրս աղբյուրից: Անհրաժեշտ էր հաստատել երրորդ համակարգի գրառումների փոփոխությունները և այդ փոփոխությունների հիման վրա կատարել այս կամ այն ճյուղը խելացի պայմանագրի տրամաբանության մեջ: Խնդիրն առաջին հայացքից բավականին տրիվիալ է, բայց երբ գործընթացին մասնակցող կողմերից մեկի ֆինանսական վիճակը կախված է դրա իրականացման արդյունքից, առաջանում են լրացուցիչ պահանջներ։ Առաջին հերթին սա համապարփակ վստահություն է նման վավերացման մեխանիզմի նկատմամբ: Բայց առաջին հերթին առաջինը:
Խնդիրն այն է, որ բլոկչեյնն ինքնին ինքնավար, փակ կազմավորում է, ուստի բլոկչեյնի ներսում խելացի պայմանագրերը ոչինչ չգիտեն արտաքին աշխարհի մասին: Միևնույն ժամանակ, խելացի պայմանագրերի պայմանները հաճախ կապված են իրական բաների մասին տեղեկատվության հետ (չվերթի ուշացում, փոխարժեք և այլն): Որպեսզի խելացի պայմանագրերը ճիշտ աշխատեն, բլոկչեյնից դուրս ստացված տեղեկատվությունը պետք է լինի հուսալի և ստուգված: Այս խնդիրը լուծվում է օրակուլների միջոցով, ինչպիսիք են Town Crier-ը և DECO-ն: Այս օրակուլները թույլ են տալիս խելացի պայմանագրին բլոկչեյն ցանցի վրա վստահել վստահելի վեբ սերվերի տեղեկատվությանը, մենք կարող ենք ասել, որ դրանք հուսալի տեղեկատվության մատակարարներ են:
Օրակուլներ
Պատկերացրեք, որ խելացի պայմանագիրը փոխանցում է 0.001 btc ձեր բիթքոյն դրամապանակին, եթե ձեր սիրելի ֆուտբոլային ակումբը հաղթի Ռուսաստանի գավաթը: Իրական հաղթանակի դեպքում խելացի պայմանագիրը պետք է փոխանցի տեղեկատվություն այն մասին, թե որ ակումբն է հաղթել, և այստեղ մի շարք խնդիրներ են առաջանում. Ստացված խելացի պայմանագրում վավեր է, իրականում համընկնում է իրականության հետ:
Ինչ վերաբերում է տեղեկատվության աղբյուրին, ապա կարող է լինել 2 սցենար՝ խելացի պայմանագիրը միացնել վստահելի կայքին, որտեղ խաղի արդյունքների մասին տեղեկությունները կենտրոնացված են պահվում, և երկրորդ տարբերակը միանգամից մի քանի կայքեր միացնելն է և այնուհետև ընտրել տեղեկատվությունը շատ աղբյուրներից։ որոնք տալիս են նույն տվյալները։ Տեղեկատվության ճշգրտությունը ստուգելու համար օգտագործվում են օրակլեր, օրինակ՝ Oraclize, որն օգտագործում է TLSNotary (TLS Notary Modification to Prove the Authenticity of Data): Բայց Google-ում բավականաչափ տեղեկատվություն կա Oraclize-ի մասին, և կան մի քանի հոդվածներ Habré-ի մասին:Այսօր ես կխոսեմ օրակուլների մասին, որոնք օգտագործում են տեղեկատվության փոխանցման մի փոքր այլ մոտեցում՝ Town Crier և DECO: Հոդվածում ներկայացված են երկու օրակուլների գործառնական սկզբունքների նկարագրությունը, ինչպես նաև մանրամասն համեմատություն:
Town Crier
Town Crier (TC)-ը ներկայացվել է IC3-ի (The Initiative for Cryptocurrencies and Contracts) կողմից 2016 թվականին CCS'16-ում: TC-ի հիմնական գաղափարը. տեղեկատվությունը կայքից փոխանցել խելացի պայմանագրին և համոզվել, որ TC-ի կողմից տրամադրված տեղեկատվությունը նույնն է, ինչ կայքում: TC-ն օգտագործում է TEE (Trusted Execution Environment) տվյալների սեփականության իրավունքը հաստատելու համար: TC-ի բնօրինակ տարբերակը նկարագրում է, թե ինչպես աշխատել Intel SGX-ի հետ:
Town Crier-ը բաղկացած է բլոկչեյնի ներսում գտնվող մի մասից և հենց ՕՀ-ի ներսում՝ TC Server-ից:
TC պայմանագիրը բլոկչեյնի վրա է և գործում է որպես TC-ի ճակատային վերջ: Այն ընդունում է հարցումները ՄՄ-ից (օգտագործողի խելացի պայմանագիր) և պատասխան է տալիս TC սերվերից: TC Server-ի ներսում կա Relay, որը կապ է հաստատում անկլավի և ինտերնետի միջև (երկուղղորդված տրաֆիկ) և կապում է անկլավը բլոկչեյնի հետ։ Enclave-ը պարունակում է progencl, որը ծածկագիր է, որը հարցումներ է կատարում բլոկչեյնից և հաղորդագրություններ է վերադարձնում բլոկչեյնին թվային ստորագրությամբ, progencl-ը պարունակում է խելացի պայմանագրի կոդի մի մասը և, ըստ էության, կատարում է դրա որոշ գործառույթներ:
Intel SGX անկլավը կարելի է համարել որպես ընդհանուր գրադարան՝ ecall-ի միջոցով աշխատող API-ով: Ecall-ը վերահսկողությունը փոխանցում է անկլավին: Անկլավը գործարկում է իր կոդը մինչև դուրս գալը կամ մինչև բացառություն տեղի ունենա: ocal-ն օգտագործվում է անկլավից դուրս սահմանված ֆունկցիաները կանչելու համար: Ocall-ը կատարվում է անկլավից դուրս և համարվում է նրա կողմից որպես անվստահելի զանգ: Ocall-ի կատարումից հետո հսկողությունը վերադարձվում է անկլավ:
Enclave մասում անվտանգ ալիքը կազմաձևվում է վեբ սերվերի հետ, անկլավն ինքն է կատարում TLS ձեռքսեղմում թիրախային սերվերի հետ և կատարում է բոլոր գաղտնագրման գործողությունները ներքին: TLS գրադարանը (mbedTLS) և կրճատված HTTP կոդը արտահանվել են SGX միջավայր: Նաև Enclave-ը պարունակում է արմատային CA վկայագրեր (վկայագրերի հավաքածու)՝ հեռավոր սերվերների վկայագրերը ստուգելու համար: Request Handler-ն ընդունում է Ethereum-ի տրամադրած ձևաչափով տվյալների գծապատկերի հարցումը, վերծանում և վերլուծում է այն: Այնուհետև այն ստեղծում է Ethereum գործարք, որը պարունակում է պահանջվող datagram-ը, ստորագրում է այն skTC-ով և փոխանցում այն Relay-ին:
Ռելեի մասը ներառում է Հաճախորդի ինտերֆեյս, TCP, Blockchain ինտերֆեյս: Հաճախորդի ինտերֆեյսը անհրաժեշտ է անկլավային ծածկագիրը հաստատելու և հաճախորդի հետ հաղորդակցվելու համար: Հաճախորդը ատեստավորման հարցում է ուղարկում ecall-ի միջոցով և ստանում է skTC-ի կողմից ստորագրված ժամանակի դրոշմակնիք att-ի հետ միասին (ատեստավորման ստորագրություն), այնուհետև att-ը ստուգվում է Intel Attestation Service-ի (IAS) միջոցով, իսկ ժամանակի դրոշմը ստուգվում է վստահելի ժամանակային ծառայության կողմից: Blockchain ինտերֆեյսը ստուգում է մուտքային հարցումները և տեղադրում է գործարքներ բլոկչեյնի վրա՝ տվյալների գծապատկերների առաքման համար: Geth-ը Ethereum-ի պաշտոնական հաճախորդ է և թույլ է տալիս Relay-ին համագործակցել բլոկչեյնի հետ RPC զանգերի միջոցով:
Աշխատելով TEE-ի հետ՝ TC-ն թույլ է տալիս զուգահեռաբար գործարկել մի քանի անկլավներ՝ դրանով իսկ 3 անգամ ավելացնելով տեղեկատվության մշակման արագությունը: Եթե մեկ վազող անկլավով արագությունը 15 թքս/վրկ էր, ապա 20 զուգահեռ ընթացող անկլավների դեպքում արագությունը աճում է մինչև 65 թքս/վրկ, համեմատության համար նշենք, որ բիթքոյն բլոկչեյնում առավելագույն գործառնական արագությունը 26 թքս/վ է։
DECO
DECO (Decentralized Oracles for TLS) ներկայացվել է CCS'20-ում, աշխատում է կայքերի հետ, որոնք աջակցում են TLS միացումներին: Ապահովում է տվյալների գաղտնիությունը և ամբողջականությունը:
DECO-ն TLS-ով օգտագործում է սիմետրիկ գաղտնագրում, այնպես որ հաճախորդը և վեբ սերվերն ունեն գաղտնագրման բանալիներ, և հաճախորդը կարող է կեղծել TLS սեսիայի տվյալները, եթե ցանկանա: Այս խնդիրը լուծելու համար DECO-ն օգտագործում է եռակողմ ձեռքսեղմման արձանագրություն պրովերի (խելացի պայմանագիր), ստուգիչի (oracle) և վեբ-սերվերի (տվյալների աղբյուր) միջև։
DECO-ի աշխատանքի ձևն այն է, որ ստուգիչը ստանում է D-ի մի հատված և հաստատում է ստուգողին, որ D-ն եկել է TLS սերվերից S: Մեկ այլ խնդիր այն է, որ TLS-ը չի ստորագրում տվյալները, և TLS հաճախորդի համար դժվար է ապացուցել, որ տվյալները ստացվել են ճիշտ ճիշտ սերվերից (ծագման դժվարություն):
DECO արձանագրությունն օգտագործում է KEnc և KMac կոդավորման բանալիներ: Հաճախորդը Q հարցում է ուղարկում վեբ սերվերին, R սերվերի պատասխանը գալիս է կոդավորված ձևով, բայց հաճախորդը և սերվերը պատկանում են նույն KMac-ին, և հաճախորդը կարող է կեղծել TLS հաղորդագրությունը: DECO-ի լուծումը KMac-ը «թաքցնելն» է հաճախորդից (պրովեր), քանի դեռ նա չի պատասխանում հարցումին: Այժմ KMac-ը բաժանված է պրովերի և ստուգիչի՝ KpMac-ի և KvMac-ի միջև: Սերվերը ստանում է KMac պատասխանը գաղտնագրելու համար՝ օգտագործելով KpMac ⊕ KvMac = KMac հիմնական մասի գործողությունը:
Ստեղծելով եռակողմ ձեռքսեղմում, կիրականացվի տվյալների փոխանակում հաճախորդի և սերվերի միջև անվտանգության երաշխիքով։
Ապակենտրոնացված Oracle համակարգի մասին խոսելիս չի կարելի չհիշատակել Chainlink-ը, որի նպատակն է ստեղծել Ethereum-ի, Bitcoin-ի և Hyperledger-ի հետ համատեղելի Oracle հանգույցների ապակենտրոնացված ցանց՝ հաշվի առնելով մոդուլյարությունը. համակարգի յուրաքանչյուր մաս կարող է թարմացվել: Միևնույն ժամանակ, անվտանգության ապահովման համար Chainlink-ը առաջադրանքին մասնակցող յուրաքանչյուր օրակուլին առաջարկում է թողարկել բանալիների համակցություն (հանրային և մասնավոր): Մասնավոր բանալին օգտագործվում է մասնակի ստորագրություն ստեղծելու համար, որը պարունակում է տվյալների հարցման վերաբերյալ նրանց որոշումը: Պատասխան ստանալու համար անհրաժեշտ է միավորել ցանցի օրակուլների բոլոր մասնակի ստորագրությունները։
Chainlink-ը նախատեսում է իրականացնել նախնական PoC DECO՝ կենտրոնանալով ապակենտրոնացված ֆինանսական հավելվածների վրա, ինչպիսիք են Mixicles-ը: Գրելու պահին Forbes-ում լուրեր հայտնվեցին, որ Chainlink-ը ձեռք է բերել DECO-ն Կոռնելի համալսարանից:
Հարձակումներ օրակուլների վրա
Տեղեկատվական անվտանգության տեսանկյունից դիտարկվել են հետևյալ հարձակումները Town Crier-ի վրա.
-
Խարդախ խելացի կոնտակտային կոդի ներարկում TEE հանգույցների վրա:
Հարձակման էությունը. դիտավորյալ սխալ խելացի պայմանագրի կոդ փոխանցելը TEE-ին, այդպիսով, հարձակվողը, ով մուտք է ստացել հանգույց, կկարողանա կատարել իր սեփական (խարդախ) խելացի պայմանագիրը վերծանված տվյալների վրա: Այնուամենայնիվ, վերադարձվող արժեքները կոդավորված կլինեն մասնավոր բանալիով, և այդպիսի տվյալների մուտք գործելու միակ միջոցը վերադարձի/ելքի գաղտնագրման տեքստի արտահոսքն է:
Այս հարձակումից պաշտպանությունը բաղկացած է նրանից, որ անկլավը ստուգում է ընթացիկ հասցեում գտնվող կոդի ճիշտությունը: Դրան կարելի է հասնել հասցեավորման սխեմայի միջոցով, որտեղ պայմանագրի հասցեն որոշվում է պայմանագրի ծածկագիրը հաշելու միջոցով: -
Պայմանագրի պետական ծածկագրային տեքստի փոփոխությունների արտահոսք:
Հարձակման էությունը. Հանգույցների սեփականատերերը, որոնց վրա կատարվում են խելացի պայմանագրեր, մուտք ունեն պայմանագրային վիճակ գաղտնագրված ձևով անկլավից դուրս: Հարձակվողը, ձեռք բերելով հանգույցի կառավարումը, կարող է համեմատել կոնտակտային վիճակը գործարքից առաջ և հետո և կարող է որոշել, թե որ փաստարկներն են մուտքագրվել և որ խելացի պայմանագրի մեթոդն է օգտագործվել, քանի որ խելացի պայմանագրի կոդը և դրա տեխնիկական բնութագրերը հանրությանը հասանելի են:
Պաշտպանություն բուն հանգույցի հուսալիության ապահովման գործում: -
Կողմնակի ալիքի հարձակումներ.
Հարձակման հատուկ տեսակ, որն օգտագործում է անկլավային հիշողության և քեշի հասանելիության մոնիտորինգ տարբեր սցենարներում: Նման հարձակման օրինակ են Prime and Probe-ը:
Հարձակման կարգը.- t0. հարձակվողը լրացնում է զոհի գործընթացի տվյալների ամբողջ քեշը:
- t1. Տուժողը գործարկում է կոդը հիշողության հասանելիությամբ, որը կախված է զոհի զգայուն տվյալներից (կրիպտոգրաֆիկ բանալիներ): Քեշի գիծը ընտրվում է՝ հիմնվելով ստեղնաշարի արժեքի վրա: Նկարի օրինակում կարդում են ստեղնի բիթ = 0 և X հասցեն քեշի տող 2-ում: X-ում պահվող տվյալները բեռնվում են քեշում՝ տեղահանելով նախկինում այնտեղ եղած տվյալները:
- t2. Հարձակվողը ստուգում է, թե իր քեշի որ տողերն են վտարվել. տողերն օգտագործվում են զոհի կողմից: Դա արվում է մուտքի ժամանակի չափման միջոցով: Կրկնելով այս գործողությունը յուրաքանչյուր ստեղնաշարի համար, հարձակվողը ստանում է ամբողջ բանալին:
Պաշտպանություն հարձակումից. Intel SGX-ն ունի պաշտպանություն կողմնակի ալիքի հարձակումներից, որը կանխում է քեշի հետ կապված իրադարձությունների մոնիտորինգը, սակայն Prime և Probe հարձակումը դեռ կաշխատի, քանի որ հարձակվողը վերահսկում է իր գործընթացի քեշի իրադարձությունները և կիսում է քեշը զոհի հետ:
Այսպիսով, այս պահին չկա հուսալի պաշտպանություն այս հարձակման դեմ։
Հայտնի են նաև այնպիսի հարձակումներ, ինչպիսիք են Spectre-ը և Foreshadow-ը (L1TF), որոնք նման են Prime-ին և Probe-ին: Նրանք թույլ են տալիս կարդալ տվյալները քեշի հիշողությունից երրորդ կողմի ալիքի միջոցով: Ապահովված է պաշտպանություն Specter-v2 խոցելիությունից, որն աշխատում է այս հարձակումներից երկուսի դեմ:
DECO-ի հետ կապված եռակողմ ձեռքսեղմումը ապահովում է անվտանգության երաշխիք.
- Պրովերի ամբողջականություն. կոտրված պրովերը չի կարող կեղծել սերվերի ծագման տեղեկատվությունը և չի կարող ստիպել սերվերին ընդունել անվավեր հարցումներ կամ սխալ պատասխանել վավեր հարցումներին: Սա արվում է սերվերի և պրովերի միջև հարցումների ձևերի միջոցով:
- Ստուգիչի ամբողջականություն. կոտրված ստուգիչը չի կարող ստիպել, որ պրովերը ստանա սխալ պատասխաններ:
- Գաղտնիություն. կոտրված ստուգիչը ուսումնասիրում է միայն հանրային տեղեկատվությունը (հարցում, սերվերի անվանումը):
DECO-ում հնարավոր են միայն երթեւեկության ներարկման խոցելիություններ: Նախ՝ եռակողմ ձեռքսեղմումով, ստուգիչը կարող է հաստատել սերվերի ինքնությունը՝ օգտագործելով թարմ նոնս: Այնուամենայնիվ, ձեռքսեղմումից հետո ստուգիչը պետք է հիմնվի ցանցի շերտի ցուցիչների վրա (IP հասցեներ): Այսպիսով, ստուգիչի և սերվերի միջև հաղորդակցությունը պետք է պաշտպանված լինի երթևեկության ներարկումից: Սա ձեռք է բերվում Proxy-ի միջոցով:
Պատգամների համեմատություն
Town Crier-ը հիմնված է սերվերի մասում անկլավի հետ աշխատելու վրա, մինչդեռ DECO-ն թույլ է տալիս ստուգել տվյալների ծագման իսկությունը՝ օգտագործելով եռակողմ ձեռքսեղմում և տվյալների գաղտնագրում գաղտնագրման բանալիներով: Այս օրակուլների համեմատությունն իրականացվել է հետևյալ չափանիշների համաձայն՝ կատարողականություն, անվտանգություն, արժեք և գործնականություն:
Town Crier
DECO
կատարումը
Ավելի արագ (0.6 վրկ մինչև ավարտը)
Ավելի դանդաղ (արձանագրությունն ավարտելու համար 10.50 վրկ.)
անվտանգություն
Ավելի քիչ ապահով
Ավելի ապահով
արժենալ
Ավելի թանկ
Ավելի էժան
գործնականությունը
Պահանջում է հատուկ սարքավորում
Աշխատում է ցանկացած սերվերի հետ, որն աջակցում է TLS
ԿատարումDECO-ի հետ աշխատելու համար անհրաժեշտ է եռակողմ ձեռքսեղմում, LAN-ի միջոցով կարգավորելիս դա տևում է 0.37 վայրկյան, կապի հաստատումից հետո փոխազդեցության համար 2PC-HMAC-ն արդյունավետ է (0,13 վրկ մեկ գրելու համար): DECO-ի կատարումը կախված է առկա TLS ծածկագրային փաթեթներից, մասնավոր տվյալների չափից և որոշակի հավելվածի ապացույցների բարդությունից: IC3-ից երկուական օպցիոն հավելվածի օգտագործումը որպես օրինակ. LAN-ի միջոցով արձանագրությունը լրացնելը տևում է մոտ 10,50 վայրկյան: Համեմատության համար՝ Town Crier-ին տևում է մոտավորապես 0,6 վայրկյան նմանատիպ հավելվածը լրացնելու համար, ինչը մոտավորապես 20 անգամ ավելի արագ է, քան DECO-ն: Եթե բոլոր բաները հավասար լինեն, TC-ն ավելի արագ կլինի:
БезопасностьIntel SGX անկլավի վրա հարձակումները (կողային ալիքի հարձակումները) գործում են և կարող են իրական վնաս հասցնել խելացի պայմանագրի մասնակիցներին: Ինչ վերաբերում է DECO-ին, ապա հնարավոր են հարձակումներ՝ կապված երթևեկության ներարկման հետ, սակայն վստահված անձի օգտագործումը նվազեցնում է նման հարձակումները: Հետևաբար DECO-ն ավելի անվտանգ է:
ԱրժենալՍարքավորումների արժեքը, որն աջակցում է Intel SGX-ին, ավելի բարձր է, քան DECO-ում արձանագրության տեղադրման արժեքը: Դրա համար էլ TC-ն ավելի թանկ է։
ԳործնականությունըTown Crier-ի հետ աշխատելու համար անհրաժեշտ է հատուկ սարքավորում, որն աջակցում է TEE-ին: Օրինակ, Intel SGX-ն ապահովված է 6-րդ սերնդի Intel Core պրոցեսորների ընտանիքում և ավելի ուշ: DECO-ն թույլ է տալիս աշխատել ցանկացած սարքավորման հետ, թեև կա DECO կարգավորում՝ օգտագործելով TEE: Համաձայն տեղադրման գործընթացի, DECO-ի եռակողմ ձեռքսեղմումը կարող է որոշ ժամանակ պահանջել, բայց դա ոչինչ է TC-ի ապարատային սահմանափակման համեմատությամբ, ուստի DECO-ն ավելի գործնական է:
Ամփոփում
Երկու օրակուլներին առանձին նայելով և չորս չափանիշներով համեմատելով՝ պարզ է դառնում, որ Town Crier-ը զիջում է DECO-ին չորս կետերից երեքով։ DECO-ն տեղեկատվական անվտանգության տեսանկյունից ավելի հուսալի է, ավելի էժան և գործնական, չնայած եռակողմ արձանագրության ստեղծումը կարող է որոշ ժամանակ տևել և ունի իր թերությունները, օրինակ՝ լրացուցիչ գործողություններ գաղտնագրման բանալիներով: TC-ն ավելի արագ է, քան DECO-ն, սակայն կողմնակի ալիքի հարձակման խոցելիությունը այն դարձնում է գաղտնիության կորստի ենթակա: Պետք է հաշվի առնել, որ DECO-ն ներդրվել է 2020 թվականի հունվարին, և այն անվտանգ համարելու համար բավարար ժամանակ չի անցել։ Town Crier-ն արդեն 4 տարի ենթարկվել է հարձակման և անցել է բազմաթիվ փորձարկումների միջով, ուստի դրա օգտագործումը շատ նախագծերում արդարացված է:
Source: www.habr.com