На сьогодні лише лінивий не написав про технологію блокчейн, криптовалюти та наскільки це круто. Але в цій статті не буде вихваляння даної технології, йтиметься саме про її недоліки і способи їх усунення.
Під час роботи над одним із проектів у компанії Альтірікс системс, з'явилося завдання захищеного, цензуростійкого підтвердження даних із зовнішнього для блокчейн джерела. Необхідно було підтверджувати зміни у записах третьої системи та на основі цих змін виконувати ту чи іншу гілку у логіці смарт-контракту. Завдання на перший погляд досить тривіальне, але коли від результату його виконання залежить фінансовий стан однієї зі сторін-учасниць процесу, з'являються додаткові вимоги. Насамперед це всебічна довіра до такого механізму валідації. Але про все по порядку.
Проблема полягає в тому, що блокчейн сам по собі є автономним, замкнутим об'єктом, тому смарт-контракти всередині блокчейну нічого не знають про зовнішній світ. Водночас умови смарт-контрактів часто пов'язані з інформацією про реальні речі (flight delay, курс валют тощо). Для правильної роботи смарт-контрактів, інформація, отримана ззовні блокчейна, має бути надійною та перевіреною. Ця проблема вирішується за допомогою використання оракулів, таких як Town Crier та DECO. Дані оракули дозволяють смарт-контракту в мережі блокчейн довіряти інформації з перевіреного веб-сервера, можна сказати, що це постачальники надійної інформації.
Оракули
Уявіть, що смарт-контракт виконує переклад 0.001 btc на bitcoin-гаманець у разі перемоги вашого улюбленого футбольного клубу в кубку Росії. У разі дійсної перемоги, смарт-контракту необхідно передати інформацію про те, який клуб переміг, і тут виникає низка проблем: де взяти цю інформацію, як її безпечно передати до смарт-контракту та як переконатися, що інформація, що надійшла до смарт-контракту на насправді збігається з дійсністю?
У питанні з джерелом інформації можуть бути два сценарії: підключення смарт-контракту до довіреного веб-сайту, на якому централізовано зберігається інформація про результати матчів і другий варіант — підключити відразу кілька сайтів і далі робити вибір інформації з більшості джерел, які надають однакові дані. Для того, щоб переконатися в правильності інформації, використовуються оракули, наприклад Oraclize, що використовує TLSNotary (TLS модифікація для доказу справжності даних). Але про Oraclize інформації в Google досить, і на Хабрі є кілька статей, я ж сьогодні розповім про оракулах, які використовують трохи інший підхід до передачі інформації: Town Crier і DECO. У статті описано принципи роботи обох оракулів, а також детальне порівняння.
Міський криєр
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 Contract знаходиться у блокчейні та діє як front end для TC. Він приймає запити від CU (смарт-контракт користувача) та повертає відповідь від TC Server. Усередині TC Server знаходиться Relay, який встановлює зв'язок анклаву з мережею інтернет (двонаправлений трафік) та зв'язує анклав із блокчейном. Enclave містить progencl, який є кодом, що виконує запити з блокчейна і повертає повідомлення в блокчейн з цифровим підписом, progencl містить частину коду смарт-контракту і по суті виконує деякі з його функцій.
Анклав Intel SGX можна розглядати як загальну бібліотеку з API, що працює за допомогою ecall. Ecall передає керування анклаву. Анклав виконує свій код, доки не завершиться, або поки не станеться виняток. Для виклику функцій, визначених поза анклавом, використовуються ocall. Ocall виконується поза анклавом та обробляється ним як ненадійний виклик. Після виконання ocall управління повертається анклаву.
У частині Enclave відбувається налаштування secure channel з веб-сервером, анклав сам виконує TLS handshake з цільовим сервером та виконує всі криптографічні операції у собі. Бібліотека TLS (mbedTLS) та HTTP-код у зменшеному варіанті експортовані у середовище SGX. Також Enclave містить root CA certificates (колекція сертифікатів), щоб перевіряти сертифікати віддалених серверів. Request Handler приймає запит datagram у форматі Ethereum, розшифровує його та аналізує. Потім генерує транзакцію Ethereum, що містить requested datagram, підписує її за допомогою skTC і передає Relay.
Частина Relay включає Client Interface, TCP, Blockchain Interface. Client Interface необхідний атестації коду анклаву і з клієнтом. Клієнт відправляє запит на атестацію за допомогою ecall і отримує timestamp, підписаний skTC разом з att (сигнатура атестації), далі att підтверджується за допомогою Intel Attestation Service (IAS), а timestamp перевіряється довіреним time service. Blockchain Interface перевіряє запити, що надходять, і розміщує транзакції в блокчейн для доставки datagrams. Geth є офіційним клієнтом Ethereum і дозволяє Relay взаємодіяти з блокчейном через RPC calls.
Працюючи з TEE, TC дозволяє запустити відразу кілька анклавів паралельно, цим збільшуючи швидкість обробки інформації в 3 разу. Якщо при одному працюючому анклаві швидкість була 15 tx/sec, то при 20 паралельно запущених анклавах швидкість зростає до 65 tx/sec, для порівняння, максимальна швидкість роботи в блокчейні Bitcoin - 26 tx/sec.
DECO
DECO (Decentralized Oracles for TLS) був представлений на CCS'20, працює з сайтами, що підтримують з'єднання TLS. Забезпечує конфіденційність та цілісність даних.
DECO c TLS використовують симетричне шифрування, тим самим клієнт і веб-сервер мають ключі шифрування, і клієнт, якщо захоче, може підробити дані сеансу TLS. Для вирішення цієї проблеми DECO використовує тристоронній протокол рукостискання між prover (смарт-контракт), verifier (оракул) та web-server (джерело даних).
Принцип роботи DECO полягає в тому, щоб перевіряючий (prover) отримав частину даних D та підтвердив верифікатору (verifier), що D надійшов від TLS-сервера S. Ще одна проблема полягає в тому, що TLS не підписує дані та TLS-клієнту складно довести , що дані отримані саме з сервера (provenance difficulty).
У протоколі 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:
-
Rogue smart-contact code injection on TEE nodes.
Суть атаки: передача в TEE свідомо невірного коду смарт-контракту, таким чином, зловмисник, який отримав доступ до вузла, матиме змогу виконати власний (шахрайський) смарт-контракт на дешифровані дані. Проте значення, що повертаються, будуть зашифровані за допомогою private key, і єдиний варіант доступу до таких даних полягає в витоку зашифрованого тексту при поверненні/виведенні.
Захист від цієї атаки полягає у перевірці анклавом правильності коду, що знаходиться за поточною адресою. Це може бути досягнуто за допомогою схеми адресації, де адреса контракту визначається шляхом кодування хешування контракту. -
Contract state ciphertext changes leak.
Суть атаки: Власники вузлів, на яких виконуються смарт-контракти, мають доступ до contract state у зашифрованій формі поза анклавом. Зловмисник, отримавши управління вузлом, може порівнювати contact state до і після виконання транзакції і може визначити, які аргументи були внесені і який метод смарт-контракту використаний, оскільки сам код смарт-контракту та його технічні специфікації загальнодоступні.
Захист у забезпеченні надійності самого вузла. -
Side-channel attacks.
Особливий тип атак, що використовує моніторинг доступу до пам'яті та кешу анклаву у різних сценаріях. Приклад такої атаки – Prime and Probe.
Порядок проведення атаки:- t0: Зловмисник заповнює весь кеш даних процесу жертви.
- t1: Жертва виконує код із зверненнями до пам'яті, які залежать від конфіденційних даних жертви (криптографічні ключі). Вибір cache line відбувається за значенням keybit. У прикладі на малюнку, keybit = 0 і прочитана адреса X в cache line 2. Дані, що зберігаються в X, завантажуються в кеш, витісняючи дані, які були там до цього.
- t2: Зловмисник перевіряє, які з його рядків кеша були витіснені — рядки жертви. Це робиться за допомогою вимірювання часу доступу. Повторюючи цю операцію для кожного keybit, зловмисник отримує весь ключ.
Захист від атаки: Intel SGX має захист від side-channel attacks, який забороняє моніторинг подій, пов'язаних з кешем, але атака Prime and Probe все одно пройде, оскільки зловмисник спостерігає за подіями кешу свого процесу і розділяє кеш з жертвою.
Таким чином, наразі надійного захисту від цієї атаки немає.
Відомі також атаки типу Spectre та Foreshadow (L1TF), схожі на Prime and Probe. Вони дозволяють читати дані з кеш-пам'яті через сторонній канал. Передбачено захист від уразливості Spectre-v2, що працює проти двох даних атак.
Щодо DECO, тристоронній рукостискання надає гарантію безпеки:
- Prover Integrity: зламаний prover не може підробити інформацію про походження server і не може змусити приймати server неприпустимі запити або неправильно відповідати на дійсні запити. Це можливо через шаблони запитів між server і prover.
- Verifier Integrity: зламаний verifier не може змусити prover отримувати неправильні відповіді.
- Конфіденційність: Зламаний verifier вивчає лише загальнодоступну інформацію (запит, ім'я сервера).
У DECO можливі лише уразливості, пов'язані з ін'єкцією трафіку. Спочатку, при тристоронньому рукостисканні verifier може встановити ідентичність сервера за допомогою fresh nonce. Однак, після рукостискання Verifier повинен покладатися на індикатори мережного рівня (IP-адреси). Таким чином, зв'язок між verifier та server повинен бути захищений від ін'єкції трафіку. Це досягається за допомогою Proxy.
Порівняння оракулів
Town Crier заснований на роботі з анклавом в серверній частині, а DECO дозволяє проводити перевірку справжності походження даних за допомогою тристороннього рукостискання та шифрування даних криптографічними ключами. Порівняння даних оракулів проводилося за такими критеріями: швидкодія, безпека, вартість та практичність.
Міський криєр
DECO
швидкодія
Швидше (0.6s to finish)
Повільніше (10.50s to finish the protocol)
безпеку
Менш безпечний
Більш безпечний
вартість
дорожче
дешевше
практичність
Потребує спеціальний hardware
Працює з будь-яким сервером, який підтримує TLS
Прискорення роботи сайту: Для роботи з DECO потрібно налаштувати тристороннє рукостискання, при налаштуванні через LAN це займає 0.37 секунд, для взаємодії після встановлення зв'язку ефективний 2PC-HMAC (0,13 с на запис). Продуктивність DECO залежить від доступних наборів шифрів TLS, розміру особистих даних та складності доказів для конкретної програми. Приклад програми бінарного опціону від IC3: завершення протоколу через LAN займає близько 10,50 з. Для порівняння, Town Crier потрібно для виконання аналогічного додатку приблизно 0,6 секунд, тобто приблизно в 20 разів швидше, ніж DECO. За рівних умов, TC буде швидше.
Безпека: Атаки на анклав Intel SGX (side-channel attacks) працюють і можуть завдати реальної шкоди учасникам смарт-контракту Щодо DECO можливі атаки, пов'язані з ін'єкцією трафіку, але використання proxy зводить такі атаки нанівець. Тому DECO безпечніший.
Вартість: Вартість обладнання, що підтримує роботу з Intel SGX вище за вартість налаштування протоколу в DECO. Тому TC дорожче.
практичність: Для роботи з Town Crier обов'язково спеціальне обладнання, що підтримує TEE. Наприклад, Intel SGX підтримується на процесорах сімейства Intel Core 6-го покоління та новіше. DECO дозволяє працювати з будь-яким обладнанням, хоча є налаштування DECO з використанням TEE. За процесом налаштування тристоронній рукостискання у DECO може зайняти деякий час, але це не йде ні в яке порівняння з обмеженням у hardware для TC, тому DECO більш практичний.
Висновок
Розглянувши два оракули окремо і порівнявши їх за чотирма критеріями, видно, що Town Crier поступається DECO за трьома пунктами з чотирьох. DECO більш надійний з точки зору інформаційної безпеки, дешевший і практичніший, хоча налаштування тристороннього протоколу може зайняти деякий час і має свої мінуси, наприклад, додаткові операції з ключами шифрування. TC працює швидше DECO, але вразливість, пов'язана з side-channel attack робить його схильним до ризику втрати конфіденційності. Потрібно враховувати, що DECO був представлений у січні 2020 року, і ще не пройшло достатньо часу, щоб вважати його безпечним. Town Crier вже 4 роки піддається атакам і пройшов через безліч перевірок, тому його застосування в багатьох проектах виправдане.
Джерело: habr.com