Автор: Максим Завгородний, Solution-архитектор, DataArt

Меня зовут Максим Завгородний, уже семь лет я работаю в компании DataArt, последние три года выступаю в роли Solution-архитектора. Область профессиональных интересов: ML/AI. До этого был вовлечен в проектирование и разработку децентрализованных систем на базе блокчейна, где вплотную занимался вопросами безопасности.

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

Решения на основе технологии блокчейн активно используют в проектах финансовой сферы, например, при проектировании платежных систем, бирж, криптовалютных торговых площадок. Но блокчейн с тем же успехом можно применять в страховании, здравоохранении и других областях бизнеса. При этом клиенты, заинтересованные в использовании относительно новой и популярной технологии, часто недостаточно осведомлены о проблемах безопасности, возникающих в блокчейн-проектах. Именно поэтому их приложения так часто становятся объектами взлома. Например, в 2019 году было взломано более 30 крупных торговых платформ.

Начнем с того, что значение кибербезопасности в криптовалютных проектах выглядит очевидным. Но как насчет других областей? Давайте рассмотрим основные аспекты технологии блокчейн, требующие реализации в соответствии с высокими стандартами безопасности — вне зависимости от характера бизнеса заказчика приложения. Транзакции, сертификаты, создание и хранение приватных ключей — каждый аспект или процесс реализации может в равной степени оказаться недостаточно защищенным. Сами же эти аспекты остаются совершенно одинаковыми в любой блокчейн-инфраструктуре. Хорошая новость — лучшим практикам, наработанным в финансовой сфере, можно благополучно следовать, например, в медицинских проектах.

Самый простой и быстрый способ обеспечения безопасности блокчейн-проекта связан с использованием существующих библиотек с открытым исходным кодом (таких как bitcoinJ) или RPC-интеграцией с такими продуктами, как, например, Electrum или Geth. Это позволит нам манипулировать ключами, транзакциями, сидами и т. д. посредством существующего RPC. Этот подход действительно может быть оправдан на этапе Proof of Concept, когда сроки и бюджет обычно бывают ограничены. Но в режиме продакшна рассматривать такой вариант не стоит.

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

Вот список аспектов безопасности, которые должны быть охвачены при проектировании системы:

1. Генерация ключей/сидов.
2. Создание кошелька.
3. Хранение ключей.
4. Использование ключей.

Давайте в общих чертах рассмотрим, чего именно требуют высокие стандарты безопасности по каждому из этих пунктов.

1. ГЕНЕРАЦИЯ КЛЮЧА И/ИЛИ СИДА

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

1.1 Созданный оператором ключ/сид

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

В случае с централизованным приложением (онлайн-кошельки или классические криптовалютные биржи) процесс создания будет выполняться на этих централизованных платформах.

Методологии генерации должны быть проверены, чтобы исключить детерминизм. Безопасность алгоритмов генерации конфиденциальной криптографической информации должны быть подтверждены независимыми аудиторами.

Генерация ключевого сида должна выполняться в соответствующей демилитаризованной зоне (DMZ) или в автономной системе. Резервные копии криптографических секретов должны быть зашифрованы и переданы в секретное хранилище доверенному лицу для организации бекапов и восстановления.

1.2 Генератор псевдослучайных чисел (DRBG)

Мы рассматриваем генерацию ключей, которые следует использовать с утвержденными криптографическими алгоритмами.

Например, генерация случайных чисел (TRNG), как и детерминированные генераторы случайных битов (DRBG), в индустрии считаются признанным стандартом. Ключи генерируются с использованием математической обработки на выходе с помощью генераторов случайных битов и дополнительных параметров. Более подробную информацию вы можете найти в Рекомендациях по генерации криптографических ключей (специальная публикация НИСТ 800-133).

2. СОЗДАНИЕ КОШЕЛЬКА

Логика реализации кошелька или хранилища приватных ключей для работы с блокчейн-транзакциями должна охватывать набор вопросов: управление адресами, использование приватных ключей для подтверждения операции, внедрение мультиподписи.

Также кошелек может быть внедрен для каждой отдельной учетной записи. Детерминистический способ позволяет создавать набор адресов/пары ключей в виде общего пула адресов из одного мастер-сида. Также при внедрении кошелька необходимо обратить внимание на различные риски, такие как потеря, кража, компрометация ключей. Объединение кошелька со счетом конкретного пользователя должно сопровождаться внедрением дополнительных уровней идентификации.

2.1 Реализация иерархического детерминированного (HD) кошелька

Значение корневого сида (master seed) можно использовать для создания достаточного количества уникальных адресов, связанных только с помощью алгоритма генерации, т. е. независимых друг от друга для стороннего наблюдателя. Каждый дочерний адрес получает место в разветвленной структуре и ассоциируется с определенным путем через HD-дерево. Важно, что реализация HD-кошелька должна соответствовать стандарту, например — BIP44.

2.2 Уникальный адрес для каждой транзакции

Для анонимной операции с транзакциями должен быть сгенерирован уникальный адрес.

2.3 Мультиподпись. Несколько ключей для подписи

Для любого адреса, который генерирует HD-кошелек, обязательны как минимум две подписи, чтобы использовать входные данные для транзакции. Причем чтобы обезопасить средства пользователя от попыток хищения, необходимо разместить ключи в изолированных друг от друга демилитаризованных зонах.

2.4 Резервный ключ для восстановления

Общий метод — создание 2-х из 3-х возможных подписей для использования входных данных транзакции.

2.5 Использование иерархически детерминированных (HD)

кошельков

Все адреса назначаются детерминировано на основе сидов, которые должны быть приватными.

2.6 Резервное копирование кошельков

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

2.7 Шифрование кошелька

Все данные кошелька должны быть зашифрованы с помощью надежных алгоритмов. Данные для расшифровки должны располагаться на отдельных нодах с надежными политиками безопасности, например, Identity service, Vault HashiCorp и т. д.

3. ХРАНЕНИЕ КЛЮЧЕЙ

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

3.1 Первичные ключи хранятся в зашифрованном виде

Для хранения ключей и/или сидов необходимо использовать надежный уровень шифрования. Например, AES-256-CBC.

3.2 Место хранения ключей

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

3.3 Резервный ключ

Необходимо создать резервные копии ключей/сидов (цифровые, аппаратные, бумажные и т. д.).

3.4 Политика резервного копирования ключей

Ключи необходимо обезопасить от риска физического уничтожения, в том числе, от стихийных бедствий и техногенных катастроф: наводнений, пожаров и т. д. Храните резервные копии в местах, географически удаленных от места использования. Все резервные копии должны быть защищены средствами контроля доступа.

4. ИСПОЛЬЗОВАНИЕ КЛЮЧЕЙ

Все операции по взаимодействию с сидами должны выполняться безопасным образом. Необходимо исключить возможность копирования или изменения ключей вредоносными программами.

Ключи должны быть защищены от недобросовестных пользователей, которые используют авторизованный доступ для несанкционированных транзакций. Реализация механизма дешифровки и подписи должна быть многоуровневой и надежной.

4.1 Для формирования ключей рекомендуется использовать путь: user/pass/nth factor

Доступ к использованию ключа должен быть защищен с помощью многофакторной модели аутентификации. Например, может потребоваться идентификатор (им может быть имя пользователя, электронная почта и т. д.), токены Google Authenticator, цифровые подписи с приватного ключа, личная проверка ID.

4.2 Ключи должны использоваться только в доверенной среде

Использование ключей исключительно в доверенной среде DMZ снижает риск несанкционированного копирования вредоносными программами, вставки копий и хранения ключей. Этот подход также защитит от попыток восстановления ключей злоумышленниками и кражи конфиденциальных данных.

4.3 Проверки рекомендаций оператора/security officer и журнала операций

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

4.4 Одно устройство — один ключ

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

4.5 Многофакторная аутентификация

Подписание транзакций должно быть защищено многофакторной аутентификацией.

4.7 Аудитор операций

Для важных транзакций необходимо добавить дополнительный уровень аутентификации с обязательным одобрением менеджера.

Мы рассмотрели основные уровни, необходимые для надежной защиты системы, основанной на решении с использованием блокчейн. Однако технической реализации для обеспечения безопасности недостаточно.

Кроме того, следует:

1. Охватить и задокументировать все операции с логами, системные аудиты, аудиты безопасности, процедуры и политики для ключевых пользователей. Все операции и изменения в системе должны регистрироваться в логах.
2. Обеспечить трассировку логирования транзакций и резервное копирование логов.