mirror of https://github.com/ospab/ostp.git
136 lines
16 KiB
Markdown
136 lines
16 KiB
Markdown
# Спецификация Ospab Stealth Transport Protocol (OSTP)
|
||
|
||
**Версия:** 1.0 (Май 2026)
|
||
**Авторы:** Георгий С., Ospab Foundation
|
||
**Статус:** Стабильный, Информационный
|
||
|
||
---
|
||
|
||
## 1. Введение
|
||
|
||
**Ospab Stealth Transport Protocol (OSTP)** — это высокоэнтропийный мультиплексируемый транспортный протокол 4-го уровня, разработанный для безопасной и отказоустойчивой передачи данных между распределенными узлами в сетях с сильными помехами и агрессивным глубоким анализом трафика (DPI).
|
||
|
||
Стандартные туннельные протоколы (такие как OpenVPN, WireGuard) генерируют паттерны трафика, которые легко распознаются системами DPI по статичным «магическим байтам», фиксированным размерам рукопожатий или предсказуемым последовательностям. OSTP решает эту проблему, применяя математическое маскирование состояния и рандомизированное выравнивание границ пакетов перед отправкой в сеть. Главная цель архитектуры — достижение **максимальной равномерной энтропии**, при которой UDP-датаграммы статистически неотличимы от чистого белого шума.
|
||
|
||
---
|
||
|
||
## 2. Криптографические примитивы
|
||
|
||
OSTP построен исключительно на базе стандартизированных современных криптографических алгоритмов:
|
||
|
||
| Компонент | Примитив / Стандарт | Назначение |
|
||
|---|---|---|
|
||
| **Рукопожатие (Handshake)** | Noise Protocol Framework (`Noise_NNpsk0`) | Взаимная аутентификация и обмен ключами с прямой секретностью (Forward Secrecy). |
|
||
| **Обмен ключами** | X25519 (RFC 7748) | Эфемерный протокол Диффи-Хеллмана на эллиптических кривых. |
|
||
| **Симметричное шифрование** | ChaCha20-Poly1305 (RFC 8439) | Аутентифицированное шифрование (AEAD) для всех полезных данных. |
|
||
| **Хеширование** | BLAKE2s (RFC 7693) | Внутреннее хеширование состояний в рамках фреймворка Noise. |
|
||
| **Маскирование заголовков** | HMAC-SHA-256 (RFC 2104) | Динамическое искажение заголовков каждого пакета для устранения статических сигнатур. |
|
||
|
||
---
|
||
|
||
## 3. Архитектура протокола
|
||
|
||
OSTP работает в парадигме клиент-сервер поверх одного двунаправленного UDP-сокета:
|
||
* **Relay Bridge (Клиент / Инициатор):** Устанавливает соединения, генерирует идентификаторы сессий (Session ID) и инициирует криптографическое рукопожатие.
|
||
* **Collector Node (Сервер / Отвечающий):** Принимает соединения, проверяет ключи доступа и ретранслирует трафик прикладного уровня.
|
||
|
||
OSTP поддерживает **внутреннее криптографическое мультиплексирование**, позволяя передавать несколько логических потоков данных через единый сокет без эффекта блокировки начала очереди (Head-of-Line blocking).
|
||
|
||
---
|
||
|
||
## 4. Формат кадра (Спецификация заголовков)
|
||
|
||
Сериализованный пакет OSTP соответствует физическим ограничениям MTU. Кадр состоит из предварительно замаскированного заголовка и зашифрованной полезной нагрузки с выравнивающим отступом (padding). Все многобайтовые поля используют сетевой порядок байт (big-endian).
|
||
|
||
```text
|
||
0 1 2 3
|
||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
| Замаскированный Session ID (32 бита) |
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
| |
|
||
+ Открытый Nonce (64 бита) +
|
||
| |
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
| |
|
||
~ AEAD-шифротекст (Переменная длина) ~
|
||
| |
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
| 16-байтный тег Poly1305 |
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
```
|
||
|
||
### 4.1 Описание полей
|
||
|
||
* **Замаскированный Session ID (32 бита):** Идентификатор сессии, замаскированный операцией XOR с использованием псевдослучайного потока, сгенерированного через HMAC-SHA-256.
|
||
* **Открытый Nonce (64 бита):** Монотонно возрастающий счетчик, используемый для отслеживания пакетов в ARQ и в качестве вектора инициализации (IV) для шифра AEAD. Передается в открытом виде, но полностью защищен от подмены (аутентифицирован как AAD в AEAD).
|
||
* **AEAD-шифротекст:** Внутренняя полезная нагрузка, зашифрованная ChaCha20-Poly1305.
|
||
* **Тег аутентификации (MAC):** 16-байтный код, гарантирующий целостность шифротекста и заголовков.
|
||
|
||
---
|
||
|
||
## 5. Обфускация трафика (IPMS)
|
||
|
||
Чтобы гарантировать статистическую независимость поля Session ID в последовательных пакетах, OSTP использует метод **In-Place Matrix Scrambling (IPMS)** на базе HMAC-SHA-256.
|
||
|
||
1. **Генерация ключа обфускации:**
|
||
Оба узла независимо генерируют 8-байтный ключ обфускации (`K_obf`) из общего ключа доступа перед началом рукопожатия:
|
||
`K_obf = SHA-256(access_key || "obfusca")[0..7]`
|
||
|
||
2. **Попакетное маскирование:**
|
||
Session ID маскируется уникальным псевдослучайным значением для каждого пакета:
|
||
`mask[0..3] = HMAC-SHA-256(K_obf, Nonce)[0..3]`
|
||
`Masked_SID = SID_raw XOR mask`
|
||
|
||
Так как `Nonce` уникален для каждого пакета, маска криптографически независима для каждой датаграммы. Пассивный анализатор (DPI) не может связать пакеты в единую сессию без знания `K_obf`.
|
||
|
||
---
|
||
|
||
## 6. Рукопожатие и криптографическая синхронизация
|
||
|
||
OSTP использует Noise Protocol Framework с паттерном `Noise_NNpsk0_25519_ChaChaPoly_BLAKE2s`.
|
||
|
||
1. Регистрационный ключ доступа (`access_key`) преобразуется в 32-байтный строгий предварительно распределенный ключ (PSK) через HKDF-SHA-256.
|
||
2. PSK применяется на нулевой позиции паттерна, обеспечивая авторизацию и шифрование самой первой датаграммы рукопожатия.
|
||
3. Выполняется эфемерный обмен ключами Curve25519 (`ee`), и два однонаправленных транспортных ключа берутся из `Split()` протокола Noise над финальным chaining key `ck`.
|
||
|
||
> **Прямая секретность (Forward Secrecy).** Транспортные ключи выводятся из
|
||
> chaining key `ck`, который вбирает результат эфемерного обмена Диффи-Хеллмана
|
||
> `ee`. Они **не** выводятся из handshake hash `h` протокола Noise: `h` вбирает
|
||
> только публичные данные транскрипта (эфемерные публичные ключи и шифртексты с
|
||
> провода) и никогда — сам DH-секрет, поэтому ключи, выведенные из `h`, дали бы
|
||
> держателю PSK возможность расшифровать любую записанную сессию. Вывод из `ck`
|
||
> привязывает каждую сессию к её эфемерным приватным ключам, которые
|
||
> уничтожаются после рукопожатия: злоумышленник, скомпрометировавший PSK позже,
|
||
> всё равно не сможет расшифровать прошлый трафик. Это свойство ломает
|
||
> совместимость и защищено внутренней версией протокола (сейчас 5): узлы более
|
||
> старой версии выводят другие ключи и не могут взаимодействовать.
|
||
|
||
Первичная полезная нагрузка рукопожатия содержит Unix-отметку времени для защиты от атак повторного воспроизведения (Replay Attacks). Сервер контролирует окно синхронизации (±300 секунд, 5 минут) и дополнительно фиксирует принятые рукопожатия в множестве защиты от повтора на время этого окна.
|
||
|
||
---
|
||
|
||
## 7. Надежность и канал передачи данных
|
||
|
||
### 7.1 Selective-Repeat ARQ
|
||
OSTP обеспечивает надежную доставку поверх UDP с помощью механизма **Selective-Repeat ARQ**:
|
||
* Приемник поддерживает буфер переупорядочивания (по умолчанию: 8192 пакета).
|
||
* Неподтвержденные пакеты отправляются повторно после адаптивного тайм-аута (RTO).
|
||
* Подтверждения (ACK) встраиваются в исходящие кадры данных (piggybacking) для минимизации накладных расходов.
|
||
* Протокол динамически применяет "обратное давление" (backpressure), ограничивая чтение новых данных, если число неподтвержденных кадров в полете слишком велико.
|
||
|
||
### 7.2 Адаптивный Padding
|
||
Для защиты от анализа длин пакетов (Packet Length Analysis, PLA), OSTP добавляет выравнивающий отступ к открытому тексту перед AEAD-шифрованием. Байты отступа берутся из криптографически стойкого генератора псевдослучайных чисел ОС. Протокол поддерживает динамическое выравнивание вплоть до полного размера MTU (например, 1400 байт), сглаживая узнаваемые всплески трафика приложений и превращая их в подобие CBR (Constant Bit Rate) потока.
|
||
|
||
### 7.3 IP-роуминг (IP Roaming)
|
||
Сервер поддерживает бесшовную смену сетей (например, переключение со смартфона с Wi-Fi на LTE). Если сервер получает пакет с новым IP-адресом отправителя, но пакет успешно проходит AEAD-аутентификацию с использованием текущих ключей, сервер автоматически привязывает эту сессию к новому IP-адресу без обрыва соединения.
|
||
|
||
---
|
||
|
||
## 8. Безопасность (Security Considerations)
|
||
|
||
* **Исчерпание Nonce:** Поле Nonce имеет размер 64 бита. Реализации ОБЯЗАНЫ разрывать сессию до переполнения Nonce, чтобы предотвратить катастрофическое повторное использование гаммы AEAD-шифра.
|
||
* **DDoS и исчерпание ресурсов:** Серверы ДОЛЖНЫ применять жесткий лимит на количество одновременных сессий (например, 1024) и молча отбрасывать запросы на рукопожатие при превышении лимита, предотвращая атаки на исчерпание памяти.
|
||
* **CPU-DoS на пути перебора рукопожатия:** Поскольку на проводе нет открытого идентификатора ключа (намеренное свойство скрытности), датаграмму от неизвестного источника приходится пробно расшифровывать каждым зарегистрированным ключом. Серверы ОБЯЗАНЫ ограничивать эту работу: OSTP кэширует производные секреты каждого ключа и его junk-маркеры для текущего временно́го окна (поэтому одна попытка — это дешёвое сравнение плюс одна попытка AEAD на ключ, а не новые HKDF/HMAC), и ограничивает путь перебора глобальным token bucket (по умолчанию 100/с), так что флуд с подменённых адресов не может навязать неограниченную криптографию на пакет. Быстрый путь установленных сессий и путь IP-роуминга под этот лимит не попадают.
|
||
* **Целостность заголовка:** Механизм маскирования обеспечивает только скрытность, а не целостность. Целостность заголовков математически гарантируется 16-байтным тегом аутентификации Poly1305, который покрывает 12-байтный заголовок как присоединенные данные (AAD).
|