montana/Формальная Документация/07 Модель Угроз/Threat-Model.md

121 lines
8.3 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# Модель угроз Монтаны
**Версия:** черновик 1.0
**Базовый источник:** [SECURITY.md](../../Монтана-Протокол/SECURITY.md), [Montana Protocol v35.25.0 §Глобальные инварианты](../../Монтана-Протокол/Montana%20Protocol%20v35.25.0.md)
## 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](../10%20Формальная%20Верификация/)) |
## 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 Криптография](../02%20Криптография/)). Шор не работает.
**Граница:** 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 Криптография](../02%20Криптография/) обоснование примитивов.
- [01 Консенсус](../01%20Консенсус/) Safety/Liveness теоремы.
- [05 Сетевой слой](../05%20Сетевой%20Слой/) DDoS и eclipse детали.
- [08 Стимулы](../08%20Стимулы%20и%20Теория%20Игр/) атаки через стимулы.
- [09 Внешний аудит](../09%20Внешний%20Аудит/) нужен для подтверждения этой модели.
## 6. Источники
1. Lamport, L., Shostak, R., Pease, M. (1982). *The Byzantine Generals Problem*. TOPLAS.
2. Heilman, E., et al. (2015). *Eclipse Attacks on Bitcoin's Peer-to-Peer Network*. USENIX.
3. Daian, P., et al. (2020). *Flash Boys 2.0: Frontrunning, Transaction Reordering, and Consensus Instability in Decentralized Exchanges* (для MEV-контекста).
4. NIST FIPS 203, 204, 205 (2024).