На сегодня только ленивый не написал про технологию блокчейн, криптовалюты и насколько это круто. Но в этой статье не будет восхваления данной технологии, речь пойдет как раз о ее недостатках и способах их устранения.



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


Проблема заключается в том, что блокчейн сам по себе является автономным, замкнутым объектом, поэтому смарт-контракты внутри блокчейна ничего не знают о внешнем мире. В то же время условия смарт-контрактов часто связаны с информацией о реальных вещах (flight delay, курс валют и т.д.). Для правильной работы смарт-контрактов, информация, полученная извне блокчейна, должна быть надежной и проверенной. Данная проблема решается с помощью использования оракулов, таких как Town Crier и DECO. Данные оракулы позволяют смарт-контракту в сети блокчейн доверять информации с проверенного веб-сервера, можно сказать, что это поставщики надежной информации.


Оракулы


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


В вопросе с источником информации могут быть 2 сценария: подключение смарт-контракта к доверенному веб-сайту, на котором централизованно хранится информация о результатах матчей и второй вариант — подключить сразу несколько сайтов и дальше делать выбор информации по большинству источников, предоставляющих одинаковые данные. Для того, чтобы удостовериться в правильности информации, используются оракулы, например Oraclize, использующий TLSNotary (Модификация TLS для доказательства подлинности данных). Но про Oraclize информации в гугл достаточно, и на Хабре есть несколько статей, я же сегодня расскажу об оракулах, использующих немного другой подход к передаче информации: Town Crier и DECO. В статье приведено описание принципов работы обоих оракулов, а также детальное сравнение.


Town Crier


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:


  1. Rogue smart-contact code injection on TEE nodes.
    Суть атаки: передача в TEE заведомо неверного кода смарт-контракта, таким образом, злоумышленник, который получил доступ к узлу, будет иметь возможность выполнить собственный (мошеннический) смарт-контракт на дешифрованный данные. Тем не менее возвращаемые значения будут зашифрованы с помощью private key, и единственный вариант доступа к таким данным заключается в утечке зашифрованного текста при возврате/выводе.
    Защита от данной атаки заключается в проверке анклавом правильности кода, находящегося по текущему адресу. Это может быть достигнуто с помощью схемы адресации, где адрес контракта определяется путем хеширования кода контракта.


  2. Contract state ciphertext changes leak.
    Суть атаки: Владельцы узлов, на которых выполняются смарт-контракты, имеют доступ к contract state в зашифрованной форме вне анклава. Злоумышленник, заполучив управление узлом, может сравнивать contact state до и после выполнения транзакции и может определить, какие аргументы были внесены и какой именно метод смарт-контракта использован, так как сам код смарт-контракта и его технические спецификации общедоступны.
    Защита в обеспечении надежности самого узла.


  3. 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, трехстороннее рукопожатие предоставляет гарантию безопасности:


  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 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 года подвергается атакам и прошел через множество проверок, так что его применение во многих проектах оправдано.