BlockChainConstruction

Предисловие

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

Архитектура

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

Эра блокчейна 1.0：

Архитектура: как показано на рисунке ниже

Представители: bitcoin, reborn coin, dogcoin, Leyte coin, MasterCard coin и т.д.

Эра блокчейна 2.0：

Архитектура: как показано на рисунке ниже

Представители: Ethereum, lisk, hyperledger и т.д.

Основные изменения:

• Уровень приложений: добавлены смарт-контракты
• Уровень стимулирования: сокращение времени формирования блока до 16 секунд
• Уровень консенсуса: добавлены dpos, POS, pbft
• Уровень данных: расширен блок, добавлена поддержка передачи данных и переменных, используются оптимизированные алгоритмы шифрования и дерево Меркла

Эра блокчейна 2.0

Архитектура: как показано на рисунке ниже

Представители: EOS, VaR, AE, ash, ELA, dfinity

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

Построение безопасности

Далее мы кратко рассмотрим проблемы, заслуживающие внимания при построении безопасности публичного блокчейна, в соответствии с архитектурой блокчейна. Около 75% из них привели к проблемам безопасности публичных блокчейнов, что также является моментами, достойными внимания при аудите безопасности публичного блокчейна. Здесь мы приводим их в форме вопросов, чтобы стимулировать размышления. Если вы хотите обсудить что-то подробнее, вы можете сделать это непосредственно в issue：

Уровень данных

Уровень данных — это технология нижнего уровня, основные функции которой — хранение данных, реализация учётных записей и транзакций, а также безопасность. Хранение данных в основном основано на дереве Меркла, которое реализуется структурой блоков и цепочек. Большинство из них хранится в базе данных kV, например, bitcoin и leveldb, используемые Ethereum.

На уровне данных стоит задуматься о следующем:

1. Разумна ли структура данных блока публичного блокчейна?
2. Соответствует ли алгоритм шифрования публичного блокчейна требованиям криптографии?
3. Разумна ли конструкция дерева Меркла?
4. Разумна ли схема CRUD для узлов дерева Меркла?
5. Разумна ли логика проверки временной метки блока публичного блокчейна?
6. Безопасность хранения данных и операций CURD в базе данных публичного блокчейна?
7. Достаточно ли безопасен алгоритм генерации открытого ключа/мнемоники?
8. Зашифрованы ли открытый ключ/мнемоника?
9. Возможны ли злоупотребления/остатки в памяти при работе с открытым ключом/мнемоникой?

Сетевой уровень

Основная цель сетевого уровня — обеспечить информационное взаимодействие между узлами сети блокчейна. Суть блокчейна — это одноранговая (P2P) сеть. Каждый узел может получать информацию, а также создавать её. Узлы поддерживают связь друг с другом за счёт ведения общего блокчейна. В сети блокчейна каждый узел может создать новый блок. После создания нового блока другие узлы уведомляются через широковещательную рассылку. В свою очередь, другие узлы проверяют этот узел. Когда более 51% пользователей сети блокчейна проходят проверку, новый блок добавляется в основную цепочку.

На сетевом уровне стоит задуматься о нескольких моментах

1. Разумен ли алгоритм обнаружения узлов публичного блокчейна?

2. Разумна ли конструкция узлов публичного блокчейна?

3. Разумна ли конструкция механизма наказания?

4. Разумен ли протокол связи?

5. Разумна ли схема обработки запросов узла публичного блокчейна?

6. Есть ли ограничение на размер пакета обработки запросов?

7. Разумен ли механизм коммуникации транзакций публичного блокчейна?

8. Разумен ли механизм синхронизации данных блоков?

9. Разумна ли логика обработки транзакций?

Уровень консенсуса

Уровень консенсуса позволяет сильно распределённым узлам достигать консенсуса относительно достоверности данных блоков в децентрализованной системе. Каждый работающий блокчейн нуждается в алгоритме консенсуса, чтобы гарантировать достоверность и порядок выдачи блоков. Распространённые алгоритмы консенсуса включают pow, POS, dpos, Poa, POC и т.д.

На уровне консенсуса следует учесть следующие моменты：

1. Безопасен ли алгоритм консенсуса публичного блокчейна?

2. Разумна ли схема проверки консенсуса публичного блокчейна?

3. Разумна ли схема конфискации при консенсусе публичного блокчейна?

4. Разумна ли схема комиссии за обслуживание в публичном блокчейне?

5. Разумна ли схема майнинга публичного блокчейна?

6. Разумна ли схема динамической регулировки сложности блока?

7. Разумна ли логика проверки сложности блока?

8. Разумна ли схема реорганизации цепочки, сброса цепочки, форка цепочки и т.д.?

Уровень стимулирования

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

На уровне стимулирования есть несколько моментов, заслуживающих нашего внимания

1. Разумна ли схема механизма эмиссии публичного блокчейна?

2. Разумна ли схема механизма наказания публичного блокчейна?

Уровень контрактов

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

На уровне контрактов следует учесть следующие моменты:

1. Безопасность виртуальной машины контрактов?

2. Развёртывание / выполнение / интерфейс контрактов?

3. Безопасность, связанная со смарт-контрактами?

Уровень приложений

Уровень приложений инкапсулирует различные сценарии и варианты применения блокчейна, что аналогично различным программным продуктам на компьютерах. Это продукт, которым обычные пользователи могут действительно пользоваться напрямую; его также можно понимать как браузер продуктов с архитектурой B / S.

На уровне приложений следует учесть следующие моменты (только публичный блокчейн, не кошельки App/Exchange/DEFI и т.д.):

Вопросы учётных записей

1. Логика CRUD для учётной записи кошелька?

2. Проверка прав на импорт и экспорт кошелька?

3. Сложность пароля кошелька?

4. Проверка корректности адреса учётной записи кошелька?

Вопросы RPC

1. Нужна ли публичному интерфейсу RPC внешняя публичная сеть?

2. Чётко ли разделены права доступа к интерфейсу RPC публичного блокчейна?

3. Есть ли у публичного интерфейса RPC операции чувствительного класса?

4. Корректно ли публичный интерфейс RPC обрабатывает исключения?

5. Каков максимальный предел объёма обрабатываемых данных интерфейса RPC публичного блокчейна?

6. Кодирование и декодирование данных запросов интерфейса RPC публичного блокчейна?

7. Включён ли SSL при обработке запросов к RPC публичного блокчейна?

Вопросы конкурентности

1. Схема обработки запросов при высокой конкурентности в публичном блокчейне?

2. Установлено ли максимальное количество соединений?

3. Разрешает ли интерфейс Web UI публичного блокчейна удалённый доступ?

4. Есть ли уязвимости веб-класса в интерфейсе webui публичного блокчейна?

5. Разрешает ли интерфейс webui публичного блокчейна локальное хранение паролей?

Уровень кода

Действительно, в публичном блокчейне нет "уровня кода". Здесь автор предлагает его в основном для классификации проблем, которые могут потребовать внимания в процессе разработки публичного блокчейна:

1. Особенности языка разработки публичного блокчейна, например, readall (), возможности append при чтении данных на языке go

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

3. Соблюдение стандартов кодирования при разработке публичного блокчейна, например, нулевые указатели, срезы, обработка исключений и другие операции

4. Обработка шифрования и дешифрования в публичном блокчейне, например, высокосложное кодирование и декодирование без проверки длины

5. Преобразование типов данных, например, hextobyte, integer. Parseint() и т.д.

6. Базовая бизнес-логика, например

Прочие вопросы

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

Безопасность узлов

1. Зашифровано ли хранилище данных?

2. Разумны ли права доступа к файлам?

3. Безопасна ли среда выполнения?

4. Запускается ли узел не от root?

5. Есть ли на стороне узла уязвимый веб-сервис?

6. Есть ли на серверной стороне узла небезопасные настройки?

7. Есть ли на серверной стороне узла уязвимость неавторизованного доступа?

8. Не утёк ли пароль учётной записи SSH на серверной стороне узла?

Атаки на вычислительные мощности

1. Атака 51%

2. Жёсткий форк публичного блокчейна

3. Угон вычислительных мощностей (заражение майнинг-машин червями)

Сторонние библиотеки

Используются ли сторонние библиотеки с уязвимостями, например, Jackson databind, fastjson и т.д.

Промежуточное ПО

Использование уязвимого промежуточного ПО, например, более старых версий tendermint

Требования к кросс-чейну

1. Надёжна ли и уместна ли схема кросс-чейна?

2. Схема реализации изоморфного кросс-чейна и гетерогенного кросс-чейна?

3. Повторение проблем безопасности из раздела выше

Поддержка

• Al1ex@Heptagram

Обсуждение

Принимайте непосредственное участие в обсуждении соответствующих вопросов в issue