Денес само мрзливите не пишуваат за блокчејн технологијата, криптовалутите и колку е кул. Но, оваа статија нема да ја пофали оваа технологија, ќе зборуваме за нејзините недостатоци и начини за нивно отстранување.
Додека работевте на еден од проектите во Altirix Systems, се појави задачата за безбедно, отпорно на цензура потврда на податоците од извор надвор од блокчејнот. Беше неопходно да се потврдат промените во записите на третиот систем и, врз основа на овие промени, да се изврши една или друга гранка во логиката на паметниот договор. Задачата на прв поглед е прилично тривијална, но кога финансиската состојба на една од страните што учествуваат во процесот зависи од резултатот од неговото спроведување, се појавуваат дополнителни барања. Пред сè, ова е сеопфатна доверба во таков механизам за валидација. Но, прво прво.
Проблемот е што самиот блокчејн е автономен, затворен ентитет, така што паметните договори во блокчејнот не знаат ништо за надворешниот свет. Во исто време, условите на паметните договори често се поврзани со информации за реални работи (доцнење на летот, девизни курсеви итн.). За паметните договори да функционираат правилно, информациите добиени надвор од блокчејнот мора да бидат сигурни и проверени. Овој проблем е решен со користење пророчки како што се Town Crier и DECO. Овие пророчи дозволуваат паметен договор на блокчејн мрежата да им верува на информациите од доверлив веб-сервер; можеме да кажеме дека тоа се даватели на веродостојни информации.
Оракли
Замислете дека паметен договор префрла 0.001 btc во вашиот биткоин паричник ако вашиот омилен фудбалски клуб го освои Купот на Русија. Во случај на вистинска победа, паметниот договор треба да пренесе информации за тоа кој клуб победил, и тука се појавуваат голем број проблеми: каде да се добијат овие информации, како безбедно да се пренесат на паметниот договор и како да се осигура дека информациите добиени во паметниот договор е валиден всушност се совпаѓа со реалноста?
Кога станува збор за изворот на информации, може да има 2 сценарија: поврзување паметен договор со доверлива веб-локација каде информациите за резултатите од натпреварите се централно складирани, а втората опција е да се поврзат неколку локации одеднаш и потоа да се изберат информации од повеќето извори. кои ги даваат истите податоци. Со цел да се потврди точноста на информациите, се користат пророци, на пример Oraclize, кој користи TLSNotary (TLS нотарска модификација за докажување на автентичноста на податоците). Но, на Google има доволно информации за Oraclize, а има и неколку статии на Habré.Денес ќе зборувам за пророци кои користат малку поинаков пристап за пренос на информации: Town Crier и DECO. Статијата дава опис на принципите на работа на двата пророка, како и детална споредба.
Таун Криер
Town Crier (TC) беше воведен од IC3 (Иницијативата за криптовалути и договори) во 2016 година на CCS'16. Главната идеја на TC: пренос на информации од веб-локација на паметен договор и уверете се дека информациите доставени од TC се исти како на веб-страницата. TC користи TEE (Trusted Execution Environment) за да ја потврди автентичноста на сопственоста на податоците. Оригиналната верзија на TC опишува како да се работи со Intel SGX.
Town Crier се состои од дел во внатрешноста на блокчејнот и дел во самиот ОС - TC Server.
Договорот за ТЦ е на блокчејн и делува како преден крај за ТЦ. Ги прифаќа барањата од CU (кориснички паметен договор) и враќа одговор од TC серверот. Внатре во ТЦ серверот има реле, кое воспоставува врска помеѓу енклавата и Интернет (двонасочен сообраќај) и ја поврзува енклавата со блокчејнот. Enclave содржи progencl, што е код кој прави барања од blockchain и враќа пораки до blockchain со дигитален потпис, progencl содржи дел од кодот на паметниот договор и во суштина извршува некои од неговите функции.
Интел SGX енклавата може да се смета како споделена библиотека со API што работи преку ecall. Ecall ја пренесува контролата во енклавата. Енклавата го извршува својот код додека не излезе или додека не се случи исклучок. ocal се користи за повикување на функции дефинирани надвор од енклавата. Ocall се извршува надвор од енклавата и се третира како недоверлив повик од него. Откако ќе се изврши околот, контролата се враќа во енклавата.
Во делот Enclave, безбеден канал е конфигуриран со веб-сервер, самата енклава врши TLS ракување со целниот сервер и ги извршува сите криптографски операции внатрешно. TLS библиотеката (mbedTLS) и намалениот HTTP код се извезени во SGX околината. Исто така, Enclave содржи root CA сертификати (збирка на сертификати) за да ги потврди сертификатите на оддалечените сервери. Управувачот со барања прифаќа барање за датаграм во формат обезбеден од Ethereum, го дешифрира и го анализира. Потоа генерира трансакција на Ethereum што го содржи бараниот датаграм, го потпишува со skTC и го пренесува на Relay.
Релејниот дел вклучува клиент интерфејс, TCP, блокчејн интерфејс. Клиентскиот интерфејс е потребен за да се потврди енклавниот код и да се комуницира со клиентот. Клиентот испраќа барање за атестирање користејќи ecall и добива временски печат потпишан од skTC заедно со att (потпис за атест), потоа att се проверува со помош на Intel Attestation Service (IAS), а временскиот печат се проверува од доверлива временска услуга. Блокчејн интерфејсот ги потврдува дојдовните барања и поставува трансакции на блокчејнот за испорака на датаграми. Geth е официјален клиент на Ethereum и му овозможува на Relay да комуницира со блокчејнот преку повици RPC.
Работејќи со TEE, TC ви овозможува да извршувате неколку енклави паралелно, а со тоа да ја зголемите брзината на обработка на информации за 3 пати. Ако со една трчана енклава брзината беше 15 tx/sec, тогаш со 20 паралелни енклави кои работат, брзината се зголемува на 65 tx/sec; за споредба, максималната работна брзина во блокчејнот на Bitcoin е 26 tx/sec.
ДЕКО
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, кој има за цел да создаде децентрализирана мрежа на Oracle јазли компатибилни со Ethereum, Bitcoin и Hyperledger, земајќи ја предвид модуларноста: секој дел од системот може да се ажурира. Во исто време, за да се осигури безбедноста, Chainlink му нуди на секој пророк кој учествува во задачата да издаде комбинација од клучеви (јавни и приватни). Приватниот клуч се користи за генерирање на делумен потпис кој ја содржи нивната одлука за барањето податоци. За да се добие одговор, неопходно е да се комбинираат сите делумни потписи на пророците на мрежата.
Chainlink планира да спроведе првично PoC DECO со фокус на децентрализираните финансиски апликации како што е Mixicles. Во моментот на пишувањето, на Форбс излезе вест дека Chainlink го купи DECO од Универзитетот Корнел.
Напади на пророци
Од гледна точка на безбедноста на информациите, беа разгледани следните напади врз Town Crier:
-
Нечесните инјекции на код за паметни контакти на ТЕЕ јазли.
Суштината на нападот: пренесување на намерно неточен код за паметен договор до TEE, на тој начин, напаѓачот кој добил пристап до јазолот ќе може да изврши свој (измамен) паметен договор на дешифрираните податоци. Сепак, вратените вредности ќе бидат шифрирани со приватен клуч, а единствениот начин за пристап до таквите податоци е да се протече шифрениот текст при враќање/излез.
Заштитата од овој напад се состои во тоа што енклавата ја проверува точноста на кодот лоциран на тековната адреса. Ова може да се постигне со помош на шема за адресирање каде што адресата на договорот се одредува со хаширање на кодот на договорот. -
Протекување на промените на шифрениот текст на состојбата на договорот.
Суштината на нападот: Сопствениците на јазли на кои се извршуваат паметните договори имаат пристап до состојбата на договорот во шифрирана форма надвор од енклавата. Напаѓачот, откако добил контрола над јазолот, може да ја спореди состојбата на контакт пред и по трансакцијата и може да одреди кои аргументи се внесени и кој метод на паметен договор е користен, бидејќи самиот код за паметен договор и неговите технички спецификации се јавно достапни.
Заштита во обезбедувањето на сигурноста на самиот јазол. -
Напади на страничен канал.
Посебен тип на напад кој користи следење на енклавната меморија и кеш пристап во различни сценарија. Пример за таков напад се Prime и Probe.
Наредба за напад:- t0: Напаѓачот ја пополнува целата кеш на податоци на процесот на жртвата.
- t1: Жртвата извршува код со мемориски пристапи кои зависат од чувствителните податоци на жртвата (криптографски клучеви). Линијата за кеш е избрана врз основа на вредноста на клучеви. На примерот на сликата се чита тастатурата = 0 и адресата X во кеш линијата 2. Податоците зачувани во X се вчитуваат во кешот, поместувајќи ги податоците што биле таму претходно.
- t2: Напаѓачот проверува кои од неговите кеш линии се исфрлени - линии што ги користи жртвата. Ова се прави со мерење на времето за пристап. Со повторување на оваа операција за секој клучен бит, напаѓачот го добива целиот клуч.
Заштита од напад: Intel SGX има заштита од напади на страничниот канал што го спречува следењето на настани поврзани со кешот, но нападот Prime и Probe сепак ќе функционира бидејќи напаѓачот ги следи настаните од кешот на неговиот процес и го споделува кешот со жртвата.
Така, во моментов нема сигурна заштита од овој напад.
Познати се и нападите како Spectre и Foreshadow (L1TF), слични на Prime и Probe. Тие ви дозволуваат да читате податоци од кеш меморијата преку канал од трета страна. Обезбедена е заштита од ранливоста Specter-v2, која работи против два од овие напади.
Во однос на DECO, тринасочното ракување обезбедува гаранција за безбедност:
- Интегритет на проверувачот: Хакиран проверувач не може да ги фалсификува информациите за потеклото на серверот и не може да предизвика серверот да прифаќа неважечки барања или да одговори погрешно на валидни барања. Ова се прави преку шеми на барања помеѓу серверот и проверувачот.
- Интегритет на проверувачот: Хакиран проверувач не може да предизвика доверителот да добие неточни одговори.
- Приватност: хакираниот проверувач ги испитува само јавните информации (барање, име на сервер).
Во DECO, можни се само пропусти на сообраќајно вбризгување. Прво, со тринасочно ракување, проверувачот може да го утврди идентитетот на серверот користејќи свежо нонс. Меѓутоа, по ракувањето, верификаторот мора да се потпре на индикаторите на мрежниот слој (IP адреси). Така, комуникацијата помеѓу проверувачот и серверот мора да биде заштитена од сообраќајно инјектирање. Ова се постигнува со користење на прокси.
Споредба на пророците
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. Сите работи се еднакви, ТК ќе биде побрз.
безбедност: Нападите на енклавата Intel SGX (напади од страничен канал) функционираат и можат да предизвикаат вистинска штета на учесниците во паметниот договор. Во однос на DECO, можни се напади поврзани со сообраќајно инјектирање, но употребата на прокси ги намалува таквите напади на ништо. Затоа DECO е побезбеден.
Цена: Цената на опремата што поддржува Intel SGX е повисока од цената за поставување на протоколот во DECO. Затоа ТК е поскап.
Практичност: За работа со Town Crier, потребна е специјална опрема што поддржува TEE. На пример, Intel SGX е поддржан на семејството процесори Intel Core од 6-та генерација и подоцна. DECO ви овозможува да работите со која било опрема, иако има поставка за DECO користејќи TEE. Според процесот на поставување, тринасочното ракување на DECO може да потрае некое време, но ова не е ништо во споредба со хардверското ограничување на TC, па затоа DECO е попрактично.
Заклучок
Гледајќи ги двата пророци одделно и споредувајќи ги по четири критериуми, јасно е дека Town Crier е инфериорен во однос на DECO во три од четири точки. DECO е посигурен од гледна точка на безбедноста на информациите, поевтин и попрактичен, иако поставувањето на протокол од три страни може да потрае некое време и има свои недостатоци, на пример, дополнителни операции со клучеви за шифрирање. TC е побрз од DECO, но ранливостите на нападите на страничниот канал го прават подложен на губење на доверливоста. Мора да се земе предвид дека DECO беше воведен во јануари 2020 година и не помина доволно време за да се смета за безбеден. Town Crier е нападнат веќе 4 години и помина низ многу тестови, па неговата употреба во многу проекти е оправдана.
Извор: www.habr.com