Реализация безопасности

Модель безопасности VIZ Ledger опирается на три столпа: верификация authority на основе порогов, детерминированная валидация подписей и зашифрованный транспорт между пирами. На этой странице описывается каждая подсистема и даются рекомендации для операторов и разработчиков плагинов.

Модель authority

У каждого аккаунта есть три уровня authority — master, active и regular — каждый из которых представлен взвешенным набором ключей и/или ссылок на аккаунты с пороговым весом.

Authority {
    weight_threshold: uint32
    key_auths:     { PublicKey → weight }
    account_auths: { AccountName → weight }
}

Операция авторизована, когда сумма весов предоставленных подписей (с рекурсивным разрешением authority аккаунтов) достигает или превышает weight_threshold.

Глубина рекурсии ограничена во избежание бесконечных циклов в цепочках вложенных authority аккаунтов.

Та же структура authority хранится в разделяемой памяти как SharedAuthority с использованием межпроцессных аллокаторов, совместимых с отображаемыми файлами Boost.Interprocess.

Валидация подписей

Валидация подписей транзакций использует детерминированную ECDSA secp256k1:

Дайджест: sha256(chain_id || serialized_transaction)
Восстановление: secp256k1_recover(signature, digest) → публичный ключ
Проверка authority: sign_state.check_authority(account, level) обходит дерево authority и проверяет, что восстановленный набор ключей удовлетворяет порогу.

Движок sign_state:

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

Для разработчиков плагинов: Используйте API check_authority_signature плагина auth_util для проверки подписей перед обработкой чувствительных операций:

json

{
  "method": "auth_util.check_authority_signature",
  "params": ["alice", "regular", "<hex_digest>", ["<sig1>", "<sig2>"]]
}

Возвращает набор верифицированных ключей подписи при удовлетворении authority или ошибку в противном случае.

Шифрование транспорта пиров

Все peer-to-peer соединения используют обмен ключами ECDH + потоковое шифрование AES:

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

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

Реализация находится в stcp_socket (libraries/network/stcp_socket.cpp).

Открытие API

Плагин webserver предоставляет JSON-RPC через HTTP и WebSocket. Конфигурация безопасности:

ini

# Привязать к loopback только для внутреннего доступа
webserver-http-endpoint = 127.0.0.1:8090
webserver-ws-endpoint = 127.0.0.1:8091

# Использовать обратный прокси (nginx, caddy) для публичного доступа с TLS

Размер пула потоков: Веб-сервер работает с настраиваемым числом потоков. Установите webserver-thread-pool-size в соответствии с ожидаемой нагрузкой одновременных запросов. Недостаточный размер вызывает очередь запросов; избыточный — расход ресурсов.

ini

webserver-thread-pool-size = 4

Сетевые меры безопасности

Зашифрованные каналы: Все соединения пиров зашифрованы (ECDH + AES). Пассивное прослушивание невозможно.
База данных пиров: P2P-узел ведёт базу данных пиров и метаданные времени распространения.
Мягкие баны: Пиры, ведущие себя некорректно (отправляющие невалидные блоки, только данные форков без прогресса), получают временные мягкие баны вместо постоянного отключения.
Ограничения пропускной способности: Настраиваются через max-send-buffer-size и связанные P2P-параметры.

Оценка уязвимостей

Типичные риски:

Риск	Мера противодействия
Обход authority через некорректные подписи	Ограниченная глубина рекурсии; строгая проверка весовых порогов
Слабая случайность в эфемерных ключах	Использует детерминированную генерацию ключей secp256k1
MitM на незашифрованном RPC	Привязка веб-сервера к loopback; TLS-прокси для публичных эндпоинтов
DoS через большие полезные нагрузки	Ограничения размера JSON-RPC; пул потоков веб-сервера контролирует параллелизм
Исчерпание вложенных authority	Максимальная глубина рекурсии принудительно применяется в `sign_state`

Контрольный список тестирования на проникновение:

Отправлять некорректные или неполные подписи для проверки защиты от обхода authority.
Тестировать ограничения глубины рекурсии с глубоко вложенными цепочками authority аккаунтов.
Проверять шифрование транспорта с помощью захвата сети (на канале не должно быть открытого текста).
Нагружать эндпоинт веб-сервера для проверки исчерпания памяти и насыщения очереди.

Лучшие практики безопасности для разработки плагинов

Валидация входных данных:

Отклонять некорректные или слишком большие JSON-RPC полезные нагрузки на границах плагина.
Валидировать все параметры по ожидаемым типам и диапазонам перед обработкой.

Аутентификация:

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

Сравнения в постоянное время:

Использовать fc::crypto::secure_compare или аналог для сравнений секретов во избежание тайминговых атак по сторонним каналам.

Никаких учётных данных в открытом виде:

Никогда не хранить приватные ключи в состоянии плагина или логах.
Генерировать эфемерные ключи на каждую сессию; никогда не повторно использовать.

Модель угроз по уровням authority:

regular authority: социальные/контентные операции — минимальные привилегии.
active authority: средства, стейкинг, голосование — средние привилегии.
master authority: ротация ключей, восстановление — максимальные привилегии. Требовать явного подтверждения пользователя в любом UI.

Мониторинг и реагирование на инциденты

Метрики для мониторинга:

Количество соединений пиров и частота смены.
Глубина очереди пула потоков веб-сервера и задержка ответа.
Частота сбоев валидации подписей (видна в логах на уровне warn).
Пропускная способность на соединение пира.

Реагирование на инциденты:

Изолировать затронутый эндпоинт (ограничить webserver-http-endpoint до loopback).
Ротировать ключи подписи через master authority при компрометации ключа валидатора.
Повторно валидировать authority аккаунтов после ротации ключей.
Проверить логи вокруг сбоев sign_state и необычных цепочек authority.

Ротация ключей:

Ключ подписи валидатора: операция update_validator с новым ключом подписи.
Ключи аккаунта: update_account с новыми ключами master/active/regular.
Все изменения ключей вступают в силу немедленно со следующего блока.

См. также: Разработка плагинов, Типы данных, Валидаторы, Плагин webserver.

Реализация безопасности ​

Модель authority ​

Валидация подписей ​

Шифрование транспорта пиров ​

Открытие API ​

Сетевые меры безопасности ​

Оценка уязвимостей ​

Лучшие практики безопасности для разработки плагинов ​

Мониторинг и реагирование на инциденты ​