8.3 KiB
Модель угроз Монтаны
Версия: черновик 1.0 Базовый источник: SECURITY.md, Montana Protocol v35.25.0 §Глобальные инварианты
1. Кто может атаковать
| Актор | Возможности | Защита |
|---|---|---|
| Рядовой узел | Стандартные сообщения сети | Подписи + правила консенсуса |
| Майнер/оператор | Может крутить много VDF | f<n/3 BFT-граница |
| Оператор сговора | Координированные действия | f<n/3 BFT-граница |
| Государственный актор | Блокировка IP, давление на хостинг | Многосерверная архитектура (3 genesis в разных юрисдикциях) |
| Квантовый противник | Алгоритм Шора на дискретный логарифм | ML-DSA-65, ML-KEM-768 (FIPS 203/204) |
| Сетевой противник | DDoS, eclipse, man-in-the-middle | TLS-A pin, gossip избыточность, fail2ban |
| Имплементационный | Side-channel, ошибки кода | KAT, аудит, формальная верификация (см. 10) |
2. Какие атаки рассматриваются
2.1 51% / большинство hashrate
Не применимо. В Монтане нет hashrate. VDF не параллелится — больше железа не даёт больше времени.
2.2 Long-range attack
Защита: канонический порядок основан на VDF-цепи от Genesis. Альтернативная цепь от t=0 потребует пересчитать всё VDF от Genesis до текущего момента — невозможно за разумное время для атакующего, у которого нет времени-форы.
2.3 Eclipse attack
Угроза: изоляция отдельного узла, заполнение его пирами-атакующими, подача ему альтернативной "канона".
Защита:
- Жёсткие bootstrap peers (3 genesis-узла).
- Проверка VDF-цепи независимо: даже изолированный узел может проверить что подаваемая цепь корректна.
- При расхождении со своим VDF — узел знает что ему врут.
Открытый вопрос: формальный анализ устойчивости к долгому eclipse (когда атакующий имеет ресурс держать узел в изоляции дни-недели).
2.4 Nothing-at-stake
Не применимо. Нет стейка. Победа в лотерее не зависит от баланса. Множественное участие в нескольких ветках стоит времени, не балансу.
2.5 Time manipulation
Угроза: подделка локального времени узла для манипуляции восприятием τ-координаты.
Защита:
- Канон не зависит от локального clock узла. Канон = длина VDF-цепи.
- Локальное время используется только для UX (отображение).
2.6 Network partition
Угроза: сеть разделяется на две части, обе продолжают своё VDF.
Поведение: обе подсети имеют валидные VDF-цепи. Когда сеть восстанавливается, протокол выбирает более длинную цепь (стандартное правило fork choice). Часть операций в "проигравшей" ветке откатывается.
Граница безопасности: safety сохраняется на каждой из подсетей в отдельности; liveness одной подсети может пострадать.
2.7 Quantum attack
Защита: все примитивы постквантовые (см. 02 Криптография). Шор не работает.
Граница: SHA-256 при квантовом противнике даёт 128 бит preimage (Гровер, квадратичное ускорение) — всё ещё вне досягаемости.
2.8 Bribery / coercion
Угроза: атакующий подкупает оператора крутить альтернативную VDF-цепь.
Защита:
- Победа в лотерее не передаётся внешним способом — только через канон.
- Подкупленный оператор крутит свою VDF, но если он отступит от канонического порядка, его блок не примут.
- Протокольно — невозможно подкупить "будущее" поведение, только конкретные шаги.
2.9 Replay attack
Защита: seq в каждой операции аккаунта + привязка к τ-окну. Replay невозможен.
2.10 MEV (Maximal Extractable Value)
Состояние: в текущей версии MEV редуцируется к одному фактору — порядок операций внутри окна τ₁.
Защита:
- Внутри окна порядок выбирается победителем лотереи, который заранее не известен.
- Front-running через mempool — невозможен потому что нет публичного mempool в EVM-смысле.
Открытый вопрос: более глубокий анализ MEV-векторов в условиях когда прикладной слой развивается.
3. Что НЕ защищено протоколом (вне scope)
- Утечка пользовательского ключа (на стороне клиента).
- Социальная инженерия.
- Аппаратные атаки на устройство пользователя.
- Юридическое давление на конкретных операторов.
Эти векторы — задача клиентского слоя и operational security оператора, не протокола.
4. Допущения безопасности
| Допущение | Доказательство / источник |
|---|---|
| ML-DSA-65 EUF-CMA при f<n/3 | NIST FIPS 204 |
| SHA-256 collision resistance | NIST FIPS 180-4 |
| VDF несжимаемость | Pietrzak 2018 |
| Сеть после GST доставляет ≤ Δ | Стандартная модель Dwork-Lynch-Stockmeyer |
| Honest majority (n/3) | BFT consensus assumption |
5. Связанные документы
- 02 Криптография — обоснование примитивов.
- 01 Консенсус — Safety/Liveness теоремы.
- 05 Сетевой слой — DDoS и eclipse детали.
- 08 Стимулы — атаки через стимулы.
- 09 Внешний аудит — нужен для подтверждения этой модели.
6. Источники
- Lamport, L., Shostak, R., Pease, M. (1982). The Byzantine Generals Problem. TOPLAS.
- Heilman, E., et al. (2015). Eclipse Attacks on Bitcoin's Peer-to-Peer Network. USENIX.
- Daian, P., et al. (2020). Flash Boys 2.0: Frontrunning, Transaction Reordering, and Consensus Instability in Decentralized Exchanges (для MEV-контекста).
- NIST FIPS 203, 204, 205 (2024).