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

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

Проблема заключается в том, что блокчейн сам по себе является автономным, замкнутым объектом, поэтому смарт-контракты внутри блокчейна ничего не знают о внешнем мире. В то же время условия смарт-контрактов часто связаны с информацией о реальных вещах (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 года подвергается атакам и прошел через множество проверок, так что его применение во многих проектах оправдано.

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