121 lines
8.3 KiB
Markdown
121 lines
8.3 KiB
Markdown
|
# Модель угроз Монтаны
|
|||
|
|
|
|||
|
|
**Версия:** черновик 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).
|