Днес само ленивият не е писал за технологията на блокчейн, криптовалутите и колко е страхотно. Но в тази статия няма да има възхваляване на тази технология, а ще говорим точно за недостатъците ѝ и начина, по който те могат да бъдат отстранени.

По време на работа по един от проектите в компанията Алтирикс Системс се появи задача за защитено, цензуроустойчиво потвърдяване на данни от външен източник за блокчейн. Необходимо беше да се потвърдят промените в записките на трета система и на основата на тези промени да се извърши определен клон в логиката на смарт-контракта. Задачата на пръв поглед изглежда доста тривиална, но когато резултатът от нейното изпълнение зависи от финансовото състояние на една от страните участници в процеса, се появяват допълнителни изисквания. Първо, това е задълбочено доверие в подобен механизъм за валидация. Но всичко по ред.

Проблемът е в това, че самият блокчейн е автономен, затворен обект, поради което смарт-контрактите в рамките на блокчейна не знаят нищо за външния свят. В същото време условията на смарт-контрактите често са свързани с информация за реални неща (забавяне на полет, курс на валутите и др.). За да работят правилно смарт-контрактите, информацията, получена извън блокчейна, трябва да бъде надеждна и проверена. Този проблем се решава чрез използване на оракулите, като Town Crier и DECO. Тези оракули позволяват на смарт-контрактите в блокчейн мрежата да се доверят на информацията от проверен уебсървър, може да се каже, че това са доставчици на надеждна информация.

Оракули

Представете си, че смарт-контрактът извършва превод от 0.001 биткойн на вашия биткойн-кошелек в случай, че любимият ви футболен клуб победи в купата на Русия. В случай на действителна победа, в смарт-контракта трябва да бъдат предадени данни за това кой клуб е спечелил, и тук възникват редица проблеми: откъде да вземем тази информация, как да я предадем безопасно на смарт-контракта и как да сме сигурни, че информацията, постъпила в смарт-контракта, действително съвпада с действителността?

Въпросът за източника на информация може да има два сценария: свързване на смарт договор с доверен уебсайт, на който централно се съхранява информация за резултатите от мачове, и вторият вариант — директно свързване с няколко сайта и по-късно избор на информация от повечето източници, предоставящи еднакви данни. За да се потвърди правилността на информацията, се използват оракули, например Oraclize, който използва TLSNotary (модификация на TLS за доказване на автентичността на данните). Но за Oraclize има достатъчно информация в Google, а в Хабра има няколко статии, днес ще говоря за оракулите, използващи малко по-различен подход за предаване на информация: Town Crier и DECO. Статията предоставя описание на принципите на работа на двата оракула, както и подробно сравнение.

Town Crier

Town Crier (TC) беше представен от IC3 (Инициативата за криптовалути и договори) през 2016 г. на CCS’16. Основната идея на TC: да предаде информация от уебсайт на смарт договор и да се увери, че информацията, доставена от TC, е същата като на уебсайта. TC използва TEE (доверена изпълнителна среда) за автентичност на собствеността на данните. В оригиналния вариант TC е описана работата с Intel SGX.
Town Crier се състои от част в блокчейна и част в самата операционна система — TC Server.

TC Contract се намира в блокчейна и служи като фронт енд за TC. Той приема заявки от CU (смарт договор на потребителя) и връща отговор от TC Server. Вътре в TC Server се намира Relay, който установява връзка между анклава и интернет (двупосочен трафик) и свързва анклава с блокчейна. Enclave съдържа progencl, който представлява код, изпълняващ заявки от блокчейна и връщащ съобщения в блокчейн с цифров подпис, progencl съдържа част от кода на смарт договора и по същество изпълнява някои от неговите функции.

Анклавът Intel SGX може да се разглежда като обща библиотека с API, работеща чрез ecall. Ecall предава управлението на анклава. Анклавът изпълнява своя код, докато не приключи, или докато не настъпи изключение. За извикване на функции, определени извън анклава, се използват ocall. Ocall се изпълнява извън анклава и се обработва от него като ненадеждно извикване. След изпълнението на ocall, управлението се връща на анклава.

В частта Enclave се настройва защитен канал с уеб сървъра, анклавът извършва TLS handshake с целевия сървър и извършва всички криптографски операции в себе си. Библиотеката TLS (mbedTLS) и HTTP кодът в намален вариант са експортирани в средата SGX. Освен това, Enclave съдържа root CA сертификати (колекция от сертификати), за да проверява сертификатите на отдалечените сървъри. Request Handler приема датаграмни заявки в формата, предоставен от Ethereum, дешифрира ги и анализира. След това генерира Ethereum транзакция, съдържаща исканата датаграма, подписва я с помощта на skTC и я предава в Relay.

Частта Relay включва Client Interface, TCP, Blockchain Interface. Client Interface е нужен за атестация на кода на анклава и свързването с клиента. Клиентът изпраща искане за атестация с помощта на ecall и получава времеви печат, подписан с skTC заедно с att (сигнатура на атестацията), след което att се потвърдва чрез Intel Attestation Service (IAS), а времевият печат се проверява от доверена времева услуга. Blockchain Interface проверява постъпващите заявки и поставя транзакции в блокчейна за доставка на датаграми. Geth — официален клиент на Ethereum, който позволява на Relay да взаимодейства с блокчейна чрез RPC повици.

Работейки с TEE, TC позволява да се стартират наведнъж няколко анклава паралелно, увеличавайки скоростта на обработка на информацията 3 пъти. Ако при един работещ анклав скоростта е 15 tx/sec, то при 20 паралелно стартирани анклава скоростта нараства до 65 tx/sec; за сравнение, максималната работна скорост в блокчейна на Bitcoin е 26 tx/sec.

DECO

DECO (Decentralized Oracles for TLS) беше представен на CCS’20 и работи с уебсайтове, които поддържат TLS съединение. Осигурява конфиденциалност и целостност на данните.
DECO с TLS използва симетрично криптиране, така че клиентът и уеб сървърът имат ключове за криптиране, и клиентът, ако желае, може да фалшифицира данните от сесията TLS. За решаване на този проблем DECO използва тристранен протокол за ръкостискане между prover (умния контракт), verifier (оракул) и уеб сървъра (източника на данни).

Принципът на работа на DECO е, че проверяващият (prover) получава част от данните D и потвърдително съобщава на проверителя (verifier), че D е получен от TLS сървъра S. Още един проблем е, че TLS не подписва данните и на TLS клиента му е трудно да докаже, че данните са получени именно от този сървър (проблем с произхода).

В протокола DECO се използват ключове за криптиране KEnc и KMac. Клиентът изпраща запитване Q на уеб-сървър, отговорът от сървъра R пристига в криптиран вид, но клиентът и сървърът разполагат с едни и същи KMac, и клиентът може да фалшифицира TLS съобщение. Решението на DECO е да „скрие“ KMac от клиента (prover), докато той не отговори на запитването. Сега KMac е разделен между prover и verifier — KpMac и KvMac. Сървърът получава KMac за криптиране на отговора с помощта на операция с частите на ключа KpMac ⊕ KvMac = KMac.

Настройвайки тройна ръкопожатие, обменът на данни между клиента и сървъра ще бъде извършен с гаранция за безопасност.

Говорейки за системата на децентрализирани оракули, не може да не се спомене Chainlink, който се стреми да създаде децентрализирана мрежа от възли оракули, съвместима с Ethereum, Bitcoin и Hyperledger, с осъзнаване на модулността: всяка част от системата може да бъде обновена. В същото време, за да се осигури безопасност, Chainlink предлага на всеки оракул, който участва в задачата, да предостави комбинация от ключове (открит и закрит). Закритият ключ се използва за генериране на частична подписка, която съдържа тяхното решение по запитването за данни. За получаване на отговор е необходимо обединение на всички частични подписи на оралите от мрежата.

Chainlink планира да проведе първоначален PoC DECO, с акцент върху децентрализирани финансови приложения, като Mixicles. Към момента на написването на статията излезе новина във Forbes, че Chainlink е придобила DECO от Cornell University.

Атаки срещу оракули

От гледна точка на информационната безопасност, бяха разгледани следните атаки срещу Town Crier:

1. Инжекция на злонамерен код на смарт-контракт в TEE възли.
   Същността на атаката: предаване в TEE на предварително неверен код на смарт-контракт, по този начин злонамерен актьор, който е получил достъп до възела, ще има възможност да изпълни собствен (измамен) смарт-контракт върху дешифрирани данни. Въпреки това, връщаните стойности ще бъдат криптирани с помощта на частен ключ, и единственият начин за достъп до такива данни е изтичане на криптирания текст при връщането/извеждането му.
   Защита от тази атака се състои в проверка от анклава на коректността на кода, намиращ се на текущия адрес. Това може да се постигне с помощта на адресна схема, при която адресът на контракта се определя чрез хеширане на кода на контракта.

2. Промените в криптографската стойност на контракта изтичат.
   Същността на атаката: Собствениците на възли, на които се изпълняват смарт-контракти, имат достъп до contract state вEncrypted форма извън анклава. Злоумышленик, завладел възела, може да сравнява contact state преди и след изпълнението на транзакцията и може да определи какви аргументи са били въведени и кой точно метод на смарт-контракта е използван, тъй като самият код на смарт-контракта и неговите технически спецификации са публично достъпни.
   Защита, осигуряваща надеждността на самия възел.

3. Атаки чрез страничен канал.
   Специален тип атаки, които използват мониторинг на достъпа до памет и кеш на анклава в различни сценарии. Пример за такава атака е Prime and Probe.
   
   Процедура за провеждане на атаката:

   • t0: Злоумышленик запълва целия кеш на данните на жертвата.
   • t1: Жертвата изпълнява код с обращения към памет, които зависят от конфиденциални данни на жертвата (криптографски ключове). Изборът на cache line се извършва на базата на стойността на keybit. В примера на изображението, keybit = 0 и адрес X е прочетен в cache line 2. Данните, съхранявани в X, се зареждат в кеша, изхвърляйки данните, които са били там преди.
   • t2: Злоумышленик проверява кои от неговите кеш редове са били изхвърлени — редовете, използвани от жертвата. Това се прави чрез измерване на времето за достъп. Повтаряйки тази операция за всеки от keybit, злоумышленик получава целия ключ.

Защита от атака: В Intel SGX има защита срещу атаки чрез страничен канал, която забранява мониторинг на събития, свързани с кеша, но атаката Prime and Probe все пак ще премине, тъй като злонамереният наблюдава събитията от кеша на своя процес и споделя кеша с жертвата.

Следователно, в момента няма надеждна защита срещу тази атака.

Също така са известни атаки от типа Spectre и Foreshadow (L1TF), подобни на Prime and Probe. Те позволяват четене на данни от кеша чрез страничен канал. Предвидена е защита срещу уязвимостта Spectre-v2, която работи срещу двата типа атаки.

Относно DECO, тройното ръкостискане предоставя гаранция за сигурност:

1. Prover Integrity: Хакнатият prover не може да подправи информацията за произхода на server и не може да накара server да приема недопустими заявки или да отговаря неправилно на валидни заявки. Това е осъществимо чрез шаблони на заявките между server и prover.
2. Verifier Integrity: Хакнатият verifier не може да накара prover да получава неверни отговори.
3. Конфиденциалност: Хакнатият verifier изучава само обществено достъпна информация (заявка, име на сървъра).

В DECO могат да възникнат само уязвимости, свързани с инжекция на трафик. Първоначално, при тройно ръкописно, verifier може да установи идентичността на сървъра чрез fresh nonce. Въпреки това, след ръкописането, verifier трябва да разчита на индикатори на мрежово ниво (IP адреси). По този начин, връзката между verifier и server трябва да бъде защитена от инжекция на трафик. Това се постига чрез използването на Proxy.

Сравнение на оракулите

Town Crier е основан на работа с анклав на сървърната страна, докато DECO позволява проверка на произхода на данните чрез тройно ръкописно и криптиране на данните с криптографски ключове. Сравнението на данните за оракулите се проведе по следните критерии: бързина, безопасност, цена и практичност.

Town Crier
DECO

бързина
По-бързо (0.6s да завърши)
По-бавно (10.50s да завърши протокола)

безопасността
По-малко безопасен
По-безопасен

цената
По-скъп
По-евтин

практичност
Изисква специален hardware
Работи с всеки сървър, който поддържа TLS

Бързодействие: За работа с DECO е необходима настройка на тройно ръкописно. При настройката чрез LAN това отнема 0.37 секунди, а за взаимодействие след установяване на връзка е ефективен 2PC-HMAC (0.13 s за запис). Производителността на DECO зависи от наличните набори шифри TLS, размера на личните данни и сложността на доказателствата за конкретното приложение. Примерът на приложението за бинарни опции от IC3: завършване на протокола през LAN отнема около 10.50 секунди. За сравнение, на Town Crier му е нужно около 0.6 секунди за изпълнение на подобно приложение, тоест около 20 пъти по-бързо от DECO. При равни условия, TC ще бъде по-бърз.

Сигурност: Атаките на Intel SGX enclave (атаки по страничния канал) работят и могат да причинят реална вреда на участниците в смарт контракта. Що се отнася до DECO, възможни са атаки, свързани с инжекция на трафик, но използването на proxy неутрализира такива атаки. Затова DECO е по-безопасен.

Цена: Цената на оборудването, което поддържа работа с Intel SGX, е по-висока от цената на настройката на протокола в DECO. Следователно TC е по-скъп.

Практичност: За работата с 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 години е подложен на атаки и е преминал през множество проверки, така че приложението му в много проекти е оправдано.

Източник: habr.com