Днес само мързеливите не са писали за блокчейн технологията, криптовалутите и колко е готино. Но тази статия няма да хвали тази технология, ще говорим за нейните недостатъци и начини за тяхното отстраняване.
Докато работех по един от проектите в 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 (TC) беше представен от IC3 (Инициативата за криптовалути и договори) през 2016 г. на CCS'16. Основната идея на TC: прехвърлете информация от уебсайт към интелигентен договор и се уверете, че информацията, предоставена от TC, е същата като на уебсайта. TC използва TEE (надеждна среда за изпълнение) за удостоверяване на собствеността върху данните. Оригиналната версия на TC описва как да работите с Intel SGX.
Town Crier се състои от част вътре в блокчейна и част вътре в самата операционна система - TC Server.
TC Contract е в блокчейна и действа като преден край за TC. Той приема заявки от CU (потребителски интелигентен договор) и връща отговор от TC сървъра. Вътре в TC сървъра има реле, което установява връзка между анклава и интернет (двупосочен трафик) и свързва анклава с блокчейна. Enclave съдържа progencl, който е код, който прави заявки от блокчейна и връща съобщения към блокчейна с цифров подпис, progencl съдържа част от кода на интелигентния договор и по същество изпълнява някои от неговите функции.
Анклавът Intel SGX може да се разглежда като споделена библиотека с API, работещ чрез ecall. Ecall прехвърля контрола на анклава. Анклавът изпълнява кода си, докато излезе или докато не възникне изключение. ocall се използва за извикване на функции, дефинирани извън анклава. Ocall се изпълнява извън анклава и се третира като ненадеждно повикване от него. След като ocall бъде изпълнен, контролът се връща на анклава.
В частта Enclave защитен канал е конфигуриран с уеб сървър, самият анклав изпълнява TLS ръкостискане с целевия сървър и изпълнява всички криптографски операции вътрешно. TLS библиотеката (mbedTLS) и намаленият HTTP код са експортирани в средата SGX. Също така, Enclave съдържа главни CA сертификати (колекция от сертификати) за проверка на сертификатите на отдалечени сървъри. Request Handler приема заявка за дейтаграма във формата, предоставен от Ethereum, дешифрира я и я анализира. След това генерира Ethereum транзакция, съдържаща исканата дейтаграма, подписва я със skTC и я предава на Relay.
Частта 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
DECO (Decentralized Oracles for TLS) беше представен на CCS'20, работи със сайтове, които поддържат TLS връзки. Гарантира поверителност и цялост на данните.
DECO с TLS използва симетрично криптиране, така че клиентът и уеб сървърът имат ключове за криптиране и клиентът може да фалшифицира данни за TLS сесия, ако иска. За да разреши този проблем, DECO използва тристранен протокол за ръкостискане между доказващия (интелигентен договор), верификатора (оракул) и уеб сървъра (източник на данни).
Начинът, по който работи 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 планира да проведе първоначален PoC DECO с фокус върху приложения за децентрализирано финансиране като Mixicles. По време на писането на Forbes излезе новина, че Chainlink придоби DECO от университета Корнел.
Атаки срещу оракули
От гледна точка на информационната сигурност бяха разгледани следните атаки срещу Town Crier:
-
Измамно инжектиране на код за интелигентен контакт на TEE възли.
Същността на атаката: предаване на умишлено неправилен код на интелигентен договор към TEE, като по този начин нападател, получил достъп до възела, ще може да изпълни свой собствен (измамен) интелигентен договор върху дешифрираните данни. Върнатите стойности обаче ще бъдат криптирани с частен ключ и единственият начин за достъп до такива данни е изтичането на шифрования текст при връщане/извеждане.
Защитата срещу тази атака се състои в това, че анклавът проверява коректността на кода, намиращ се на текущия адрес. Това може да се постигне с помощта на схема за адресиране, при която адресът на договора се определя чрез хеширане на кода на договора. -
Изтичане на промени в шифрования текст на състоянието на договора.
Същността на атаката: Собствениците на възли, на които се изпълняват интелигентни договори, имат достъп до състоянието на договора в криптирана форма извън анклава. Нападателят, придобил контрол над възел, може да сравни състоянието на контакта преди и след транзакцията и може да определи кои аргументи са въведени и кой метод на интелигентен договор е използван, тъй като самият код на интелигентен договор и неговите технически спецификации са публично достъпни.
Защита при осигуряване на надеждността на самия възел. -
Атаки по страничен канал.
Специален тип атака, която използва наблюдение на паметта на анклава и достъпа до кеша в различни сценарии. Пример за такава атака са Prime и Probe.
Ред за атака:- t0: Нападателят запълва целия кеш с данни на процеса на жертвата.
- t1: Жертвата изпълнява код с достъп до паметта, който зависи от чувствителните данни на жертвата (криптографски ключове). Редът на кеша се избира въз основа на стойността на ключовия бит. В примера на фигурата keybit = 0 и се чете адресът X в кеш линия 2. Данните, съхранени в X, се зареждат в кеша, измествайки данните, които са били там преди.
- t2: Нападателят проверява кои от редовете му в кеша са били изгонени – редове, използвани от жертвата. Това става чрез измерване на времето за достъп. Повтаряйки тази операция за всеки ключов бит, нападателят получава целия ключ.
Защита от атаки: Intel SGX има защита срещу странични канални атаки, които предотвратяват наблюдението на събития, свързани с кеша, но атаката Prime и Probe все още ще работи, тъй като атакуващият следи кеша събитията на своя процес и споделя кеша с жертвата.
По този начин в момента няма надеждна защита срещу тази атака.
Атаки като Spectre и Foreshadow (L1TF), подобни на Prime и Probe, също са известни. Те ви позволяват да четете данни от кеш паметта чрез канал на трета страна. Предоставена е защита срещу уязвимостта Spectre-v2, която работи срещу две от тези атаки.
По отношение на DECO, тристранното ръкостискане осигурява гаранция за сигурност:
- Целостта на доказателя: Хакнат доказател не може да фалшифицира информацията за произхода на сървъра и не може да накара сървъра да приема невалидни заявки или да отговаря неправилно на валидни заявки. Това се прави чрез шаблони на заявки между сървъра и доказателя.
- Целостта на верификатора: Хакнат верификатор не може да накара проувъра да получи неправилни отговори.
- Поверителност: Хакнатият верификатор проверява само публична информация (заявка, име на сървър).
В DECO са възможни само уязвимости при инжектиране на трафик. Първо, с тристранно ръкостискане верификаторът може да установи самоличността на сървъра, използвайки нов nonce. След ръкостискането обаче верификаторът трябва да разчита на индикатори на мрежовия слой (IP адреси). По този начин комуникацията между верификатора и сървъра трябва да бъде защитена от инжектиране на трафик. Това се постига чрез използване на прокси.
Сравнение на оракули
Town Crier се основава на работа с анклав в сървърната част, докато DECO ви позволява да проверите автентичността на произхода на данните с помощта на тристранно ръкостискане и криптиране на данни с криптографски ключове. Сравнението на тези оракули беше извършено според следните критерии: производителност, сигурност, цена и практичност.
Градски викач
DECO
скорост
По-бързо (0.6 секунди до край)
По-бавно (10.50 секунди за завършване на протокола)
безопасност
По-малко сигурен
По-сигурно
цена
По-скъпо
По-евтино
практичност
Изисква специален хардуер
Работи с всеки сървър, който поддържа 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 (атаки от страничен канал) работят и могат да причинят реални щети на участниците в интелигентния договор. По отношение на DECO са възможни атаки, свързани с инжектиране на трафик, но използването на прокси намалява такива атаки до нищо. Следователно 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 години и е преминал през много тестове, така че използването му в много проекти е оправдано.
Източник: www.habr.com