Այսօր միայն ծույլերը չեն գրել բլոկչեյն տեխնոլոգիայի, կրիպտոարժույթի և դրա զովության մասին: Սակայն այս հոդվածում մենք չենք գովաբանի այս տեխնոլոգիան, մենք կխոսենք դրա թերությունների և դրանք վերացնելու եղանակների մասին:

Altirix Systems-ում նախագծերից մեկի վրա աշխատելիս խնդիր առաջացավ ապահովել բլոկչեյնի համար արտաքին աղբյուրից տվյալների գրաքննությանը դիմացկուն հաստատում: Անհրաժեշտ էր հաստատել երրորդ համակարգի գրառումների փոփոխությունները և, այդ փոփոխությունների հիման վրա, իրականացնել այս կամ այն ​​ճյուղը խելացի պայմանագրի տրամաբանությամբ: Առաջին հայացքից խնդիրը բավականին պարզ է, բայց երբ գործընթացի կողմերից մեկի ֆինանսական վիճակը կախված է դրա իրականացման արդյունքից, ի հայտ են գալիս լրացուցիչ պահանջներ: Նախևառաջ, սա նման վավերացման մեխանիզմի նկատմամբ համապարփակ վստահություն է: Բայց նախևառաջ՝ ամեն ինչ:

Խնդիրն այն է, որ բլոկչեյնն ինքնին ինքնավար, փակ օբյեկտ է, ուստի բլոկչեյնի ներսում գտնվող խելացի պայմանագրերը ոչինչ չգիտեն արտաքին աշխարհի մասին: Միևնույն ժամանակ, խելացի պայմանագրերի պայմանները հաճախ կապված են իրական բաների մասին տեղեկատվության հետ (թռիչքի ուշացում, փոխարժեքներ և այլն): Որպեսզի խելացի պայմանագրերը ճիշտ աշխատեն, բլոկչեյնից դուրս ստացված տեղեկատվությունը պետք է լինի հուսալի և ստուգված: Այս խնդիրը լուծվում է Town Crier-ի և DECO-ի նման գուշակությունների միջոցով: Այս գուշակությունները թույլ են տալիս բլոկչեյն ցանցում գտնվող խելացի պայմանագրին վստահել ստուգված վեբ սերվերից ստացված տեղեկատվությանը, կարող ենք ասել, որ դրանք հուսալի տեղեկատվության մատակարարներ են:

Օրակուլներ

Պատկերացրեք խելացի պայմանագիր, որը 0.001 բիթքոյն է փոխանցում ձեր բիթքոյն դրամապանակին, եթե ձեր սիրելի ֆուտբոլային ակումբը հաղթի Ռուսաստանի գավաթը։ Եթե իրական հաղթանակ լինի, խելացի պայմանագրին պետք է տրվի տեղեկատվություն այն մասին, թե որ ակումբն է հաղթել, և սա մի շարք խնդիրներ է առաջացնում. որտեղի՞ց կարող եմ ստանալ այս տեղեկատվությունը, ինչպե՞ս կարող եմ այն ​​անվտանգ կերպով փոխանցել խելացի պայմանագրին, և ինչպե՞ս կարող եմ համոզվել, որ խելացի պայմանագրի կողմից ստացված տեղեկատվությունը իրականում համապատասխանում է իրականությանը։

Տեղեկատվության աղբյուրի հարցում կարող են լինել 2 սցենար՝ խելացի պայմանագիրը միացնել վստահելի կայքին, որտեղ կենտրոնացված կերպով պահվում է համընկնման արդյունքների մասին տեղեկատվությունը, իսկ երկրորդ տարբերակը՝ միաժամանակ մի քանի կայքեր միացնելն է, ապա նույն տվյալները տրամադրող աղբյուրների մեծ մասից տեղեկատվություն ընտրելը։ Տեղեկատվության ճշգրտությունը ստուգելու համար օգտագործվում են օրակուլներ, օրինակ՝ Oraclize-ը, որն օգտագործում է TLSNotary-ը (տվյալների իսկությունը ապացուցելու TLS մոդիֆիկացիա)։ Սակայն Google-ում Oraclize-ի մասին բավարար տեղեկատվություն կա, և Habr-ի վերաբերյալ կան մի քանի հոդվածներ, բայց այսօր ես կխոսեմ այն ​​օրակուլների մասին, որոնք օգտագործում են տեղեկատվություն փոխանցելու մի փոքր այլ մոտեցում՝ Town Crier և DECO։ Հոդվածում նկարագրվում են երկու օրակուլների գործունեության սկզբունքները, ինչպես նաև մանրամասն համեմատություն է կատարվում։

Town Crier

Town Crier-ը (TC) ներկայացվել է IC3-ի (Կրիպտոարժույթների և պայմանագրերի նախաձեռնություն) կողմից 2016 թվականին՝ CCS'16-ում: TC-ի հիմնական գաղափարն է կայքից տեղեկատվությունը փոխանցել խելացի պայմանագրի և ստուգել, ​​որ TC-ի կողմից տրամադրված տեղեկատվությունը նույնն է, ինչ կայքում: TC-ն օգտագործում է TEE (Trusted Execution Environment)՝ տվյալների սեփականության իսկությունն ապահովելու համար: TC-ի սկզբնական տարբերակը նկարագրում է Intel SGX-ի հետ աշխատանքը:
Town Crier-ը բաղկացած է բլոկչեյնի ներսում գտնվող մասից և օպերացիոն համակարգի ներսում գտնվող մասից՝ TC Server-ից։

TC պայմանագիրը գտնվում է բլոկչեյնում և գործում է որպես TC-ի առջևի մաս։ Այն ընդունում է հարցումներ CU-ից (օգտատիրոջ խելացի պայմանագիր) և վերադարձնում է պատասխան TC սերվերից։ TC սերվերի ներսում գտնվում է Relay-ը, որը հաստատում է անկլավի կապը ինտերնետի հետ (երկուղղված երթևեկություն) և միացնում անկլավը բլոկչեյնին։ Էնկլավը պարունակում է progencl-ը, որը կոդ է, որը կատարում է բլոկչեյնից ստացված հարցումները և թվային ստորագրությամբ վերադարձնում է հաղորդագրությունները բլոկչեյն։ Progencl-ը պարունակում է խելացի պայմանագրի կոդի մի մասը և էապես կատարում է դրա որոշ գործառույթներ։

Intel SGX անկլավը կարելի է դիտարկել որպես API-ով համատեղ օգտագործվող գրադարան, որը գործում է ecall-ի միջոցով: Ecall-ը կառավարումը փոխանցում է անկլավին: Անկլավը կատարում է իր կոդը մինչև դրա ավարտը կամ մինչև բացառության առաջացումը: Անկլավից դուրս սահմանված ֆունկցիաները կանչելու համար օգտագործվում են ocalls: Ocall-ը կատարվում է անկլավից դուրս և անկլավի կողմից դիտարկվում է որպես անվտանգ կանչ: Ocall-ի կատարումից հետո կառավարումը վերադառնում է անկլավ:

Enclave մասը կարգավորում է վեբ սերվերի հետ անվտանգ ալիքը, անկլավն ինքն է կատարում TLS ձեռքսեղմում նպատակային սերվերի հետ և ներքին կարգով կատարում է բոլոր կրիպտոգրաֆիկ գործողությունները: TLS գրադարանը (mbedTLS) և HTTP կոդը կրճատված տարբերակով արտահանվում են SGX միջավայր: Բացի այդ, Enclave-ը պարունակում է root CA վկայականներ (վկայականների հավաքածու)՝ հեռակա սերվերների վկայականները ստուգելու համար: Հարցման մշակիչը ընդունում է Ethereum-ի կողմից տրամադրված ձևաչափով տվյալների գրամայի հարցումը, վերծանում է այն և վերլուծում: Այնուհետև այն ստեղծում է Ethereum գործարք, որը պարունակում է հարցված տվյալների գրամը, ստորագրում է այն skTC-ի միջոցով և փոխանցում է այն Relay-ին:

Ռելեի մասը ներառում է Հաճախորդի ինտերֆեյս, TCP, Blockchain ինտերֆեյս: Հաճախորդի ինտերֆեյսը անհրաժեշտ է անկլավային կոդի ատեստավորման և հաճախորդի հետ հաղորդակցման համար: Հաճախորդը էլեկտրոնային կանչի միջոցով ուղարկում է ատեստավորման հարցում և ստանում է skTC-ի կողմից ստորագրված ժամանակային դրոշմանիշ՝ att-ի (հաստատման ստորագրություն) հետ միասին, այնուհետև att-ն ստուգվում է Intel Attestation Service (IAS)-ի միջոցով, և ժամանակային դրոշմանիշը ստուգվում է վստահելի ժամանակային ծառայության կողմից: Blockchain Interface-ը ստուգում է մուտքային հարցումները և կատարում գործարքներ բլոկչեյնում՝ դատագրամի առաքման համար: Geth-ը Ethereum-ի պաշտոնական հաճախորդն է և թույլ է տալիս Ռելեյին փոխազդել բլոկչեյնի հետ RPC զանգերի միջոցով:

TEE-ի հետ աշխատելով՝ TC-ն թույլ է տալիս զուգահեռաբար աշխատեցնել մի քանի անկլավներ, դրանով իսկ 3 անգամ մեծացնելով տեղեկատվության մշակման արագությունը։ Եթե մեկ գործող անկլավի դեպքում արագությունը կազմում էր 15 tx/վրկ, ապա 20 զուգահեռ գործող անկլավների դեպքում արագությունը մեծանում է մինչև 65 tx/վրկ, համեմատության համար՝ Bitcoin բլոկչեյնում աշխատանքի առավելագույն արագությունը 26 tx/վրկ է։

DECO

CCS'20-ում ներկայացվեց DECO-ն (TLS-ի համար ապակենտրոնացված օրակարգեր)՝ այն աշխատում է TLS կապը աջակցող կայքերի հետ։ Ապահովում է տվյալների գաղտնիությունը և ամբողջականությունը։
TLS-ով DECO-ն օգտագործում է սիմետրիկ կոդավորում, ուստի հաճախորդը և վեբ սերվերը ունեն կոդավորման բանալիներ, և հաճախորդը կարող է կեղծել 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:

Եռակողմանի ձեռքսեղմում կարգավորելով՝ հաճախորդի և սերվերի միջև տվյալների փոխանակումը կիրականացվի անվտանգության երաշխիքով։

Խոսելով ապակենտրոնացված օրակուլ համակարգերի մասին, չենք կարող չհիշատակել Chainlink-ը, որի նպատակն է ստեղծել Ethereum-ի, Bitcoin-ի և Hyperledger-ի հետ համատեղելի օրակուլ հանգույցների ապակենտրոնացված ցանց՝ հաշվի առնելով մոդուլայինությունը. համակարգի յուրաքանչյուր մասը կարող է թարմացվել: Միևնույն ժամանակ, անվտանգությունն ապահովելու համար Chainlink-ը առաջարկում է առաջադրանքին մասնակցող յուրաքանչյուր օրակուլին տրամադրել բանալիների համադրություն (հանրային և մասնավոր): Մասնավոր բանալին օգտագործվում է մասնակի ստորագրություն ստեղծելու համար, որը պարունակում է տվյալների հարցման լուծումը: Պատասխանը ստանալու համար ցանցում օրակուլների բոլոր մասնակի ստորագրությունները պետք է համատեղվեն:

Chainlink-ը նախատեսում է անցկացնել DECO-ի նախնական PoC-ն՝ կենտրոնանալով ապակենտրոնացված ֆինանսական ծրագրերի վրա, ինչպիսին է Mixicles-ը: Գրության պահին Forbes-ի լրատվական հոդվածում հաղորդվում էր, որ Chainlink-ը ձեռք է բերել DECO-ն Կոռնելի համալսարանից:

Հարձակումներ Օրակլների վրա

Տեղեկատվական անվտանգության տեսանկյունից դիտարկվել են Town Crier-ի վրա հետևյալ հարձակումները.

1. TEE հանգույցների վրա անհիմն խելացի կոնտակտային կոդի ներարկում։
   Հարձակման էությունը՝ միտումնավոր սխալ խելացի պայմանագրի կոդի փոխանցում TEE-ին, որպեսզի հանգույց մուտք գործած հարձակվողը կարողանա կատարել իր սեփական (խարդախ) խելացի պայմանագիրը վերծանված տվյալների վրա։ Սակայն վերադարձված արժեքները կծածկագրվեն մասնավոր բանալիով, և նման տվյալներին մուտք գործելու միակ միջոցը վերադարձի/հետ կանչելու ժամանակ կոդավորված տեքստի արտահոսքն է։
   Այս հարձակման դեմ պաշտպանությունն այն է, որ անկլավը ստուգի, որ ընթացիկ հասցեի կոդը ճիշտ է: Սա կարելի է իրականացնել հասցեավորման սխեմայի միջոցով, որտեղ պայմանագրի հասցեն որոշվում է պայմանագրի կոդի հեշավորմամբ:

2. Պայմանագրի վիճակի գաղտնագրված փոփոխությունների արտահոսք։
   Հարձակման էությունը. այն հանգույցների սեփականատերերը, որոնց վրա կատարվում են խելացի պայմանագրեր, ունեն պայմանագրի վիճակին մուտք կոդավորված ձևով՝ անկլավից դուրս: Հարձակվողը, հանգույցի վրա վերահսկողություն ստանալով, կարող է համեմատել կոնտակտի վիճակը գործարքի կատարումից առաջ և հետո և կարող է որոշել, թե որ արգումենտներն են մուտքագրվել և որ խելացի պայմանագրի մեթոդն է օգտագործվել, քանի որ խելացի պայմանագրի կոդն ինքնին և դրա տեխնիկական բնութագրերը հրապարակայնորեն հասանելի են:
   Պաշտպանություն՝ ապահովելով միավորի հուսալիությունը։

3. Կողմնակի ալիքային հարձակումներ։
   Հարձակման հատուկ տեսակ, որն օգտագործում է անկլավի հիշողությանը և քեշին մուտքի մոնիթորինգը տարբեր սցենարներում: Նման հարձակման օրինակ են Prime-ը և Probe-ը:
   
   Հարձակման կարգը.

   • t0: Հարձակվողը լցնում է զոհի պրոցեսի ամբողջ տվյալների քեշը։
   • t1: Զոհը կատարում է կոդ՝ հիշողությանը մուտք գործելու հնարավորություններով, որոնք կախված են զոհի զգայուն տվյալներից (գաղտնագրված բանալիներ): Քեշի տողը ընտրվում է keybit արժեքի հիման վրա: Նկարում պատկերված օրինակում keybit = 0 է, և կարդացվում է քեշի 2-րդ տողում գտնվող X հասցեն: X-ում պահված տվյալները բեռնվում են քեշի մեջ՝ տեղահանելով նախկինում այնտեղ եղած տվյալները:
   • t2: Հարձակվողը ստուգում է, թե իր քեշի գծերից որո՞նք են ջնջվել՝ զոհի կողմից օգտագործված գծերը: Սա արվում է մուտքի ժամանակը չափելով: Այս գործողությունը կրկնելով յուրաքանչյուր բանալու համար, հարձակվողը ստանում է ամբողջ բանալին:

Հարձակման պաշտպանություն. Intel SGX-ը ունի կողային ալիքային հարձակումներից պաշտպանություն, որը կանխում է քեշի հետ կապված իրադարձությունների մոնիթորինգը, սակայն Prime և Probe հարձակումը դեռ կհաջողվի, քանի որ հարձակվողը մոնիթորինգ է անում իր պրոցեսի քեշի իրադարձությունների հետ և կիսվում է քեշով զոհի հետ։

Այսպիսով, այս պահին այս հարձակման դեմ հուսալի պաշտպանություն չկա։

Կան նաև հայտնի հարձակումներ, ինչպիսիք են Spectre-ը և Foreshadow-ը (L1TF), նման Prime-ին և Probe-ին: Դրանք թույլ են տալիս կարդալ տվյալները քեշ հիշողությունից կողային ալիքի միջոցով: Կա պաշտպանություն Spectre-v2 խոցելիության դեմ, որը գործում է այս երկու հարձակումների դեմ:

DECO-ի դեպքում եռակողմ ձեռքսեղմումը ապահովում է անվտանգության երաշխիք.

1. Ապացուցողի ամբողջականություն. Կոտրված ապացուցողը չի կարող կեղծել սերվերի ծագման մասին տեղեկատվությունը և չի կարող ստիպել սերվերին ընդունել անվավեր հարցումներ կամ սխալ պատասխանել վավեր հարցումներին: Սա արվում է սերվերի և ապացուցողի միջև հարցման ձևանմուշների միջոցով:
2. Ստուգիչի ամբողջականություն. կոտրված ստուգիչը չի կարող ստիպել ապացուցողին սխալ պատասխաններ ստանալ։
3. Գաղտնիություն. կոտրված ստուգիչը ուսումնասիրում է միայն հրապարակայնորեն մատչելի տեղեկատվությունը (հարցում, սերվերի անուն):

DECO-ում հնարավոր են միայն երթևեկության ներարկման խոցելիությունները: Սկզբում, եռակողմանի ձեռքսեղմման ժամանակ, ստուգիչը կարող է հաստատել սերվերի ինքնությունը՝ օգտագործելով թարմ ոչ մի կապ: Այնուամենայնիվ, ձեռքսեղմումից հետո, ստուգիչը պետք է հենվի ցանցային մակարդակի ցուցիչների վրա (IP հասցեներՀետևաբար, ստուգիչի և սերվերի միջև կապը պետք է պաշտպանված լինի երթևեկության ներարկումից: Սա իրականացվում է պրոքսիի միջոցով:

Օրհներգերի համեմատություն

Town Crier-ը հիմնված է սերվերի մասում անկլավի հետ աշխատանքի վրա, մինչդեռ DECO-ն թույլ է տալիս ստուգել տվյալների ծագման իսկությունը՝ օգտագործելով եռակողմ ձեռքսեղմում և տվյալների կոդավորում՝ օգտագործելով կրիպտոգրաֆիկ բանալիներ: Այս գուշակությունների համեմատությունը կատարվել է հետևյալ չափանիշներով՝ արագություն, անվտանգություն, արժեք և գործնականություն:

Town Crier
DECO

կատարողականություն
Ավելի արագ (0.6 վայրկյան ավարտելու համար)
Ավելի դանդաղ (10.50 վայրկյան՝ արձանագրությունն ավարտելու համար)

անվտանգություն
Ավելի քիչ անվտանգ
Ավելի անվտանգ

արժենալ
Ավելի թանկ
Ավելի էժան

գործնականությունը
Պահանջում է հատուկ սարքավորում
Աշխատում է ցանկացած սերվերի հետ, որը աջակցում է TLS-ին

ԿատարումDECO-ն պահանջում է եռակողմ ձեռքսեղմում, 0.37 վայրկյան LAN-ի միջոցով, իսկ 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