ДокументацияDocs Home БезопасностьSecurity ПрозрачностьTransparency
Модель угроз / Ревизия 2026-03-01 / v1.1

Модель угроз и границы безопасности

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

Оглавление

1. Цели безопасности

  • Клиент ДОЛЖЕН обеспечивать конфиденциальность E2E-полезной нагрузки сообщений и звонков на недоверенном транзите.
  • Клиент ДОЛЖЕН обеспечивать целостность и аутентичность E2E-пакетов.
  • Система СЛЕДУЕТ обеспечивать прямую секретность для сообщений и эволюцию ключей для звонков.
  • Система ДОЛЖНА отделять E2E-контент от транспортных и сервисных метаданных.

2. Модель нарушителя

2.1 Пассивный сетевой наблюдатель

  • Наблюдает IP/порт/время/объем трафика, но НЕ ДОЛЖЕН получать E2E-полезную нагрузку в открытом виде.

2.2 Активный сетевой нарушитель

  • Может вставлять, удалять и повторять пакеты; клиент ДОЛЖЕН отклонять невалидные AEAD-пакеты и повторы вне допустимого окна.

2.3 Недоверенный ретрансляционный узел или компрометированный промежуточный узел

  • Может наблюдать и маршрутизировать шифротекст, но НЕ ДОЛЖЕН обладать ключами расшифровки E2E-контента.

2.4 Принудительная правовая среда

  • Раскрытию подлежат только фактически доступные данные; модель не предполагает серверного хранения открытого E2E-содержимого.

3. Границы доверия

  • Доверенная зона: исполняемая среда клиента, локальное защищенное хранилище ключей, криптографические примитивы.
  • Частично доверенная зона: API и ретрансляционный узел как маршрутизаторы и координаторы состояний.
  • Недоверенная зона: публичная сеть, провайдерский транзит, промежуточные узлы доставки.

4. Вне области защиты

  • Компрометация конечного устройства (вредоносное ПО, получение повышенных привилегий, перехват экрана, кейлоггеры).
  • Полное сокрытие всех сетевых метаданных от любых наблюдателей.
  • Абсолютная доступность сервиса при глубокой фильтрации трафика и маршрутизационных ограничениях.

5. Проверка ключей и доверие при первом использовании (TOFU)

  • Первый контакт действует в модели TOFU; при отсутствии внешней проверки сохраняется риск атаки посредника при первом контакте.
  • Клиенту СЛЕДУЕТ предоставлять проверку через SAS/QR и предупреждение о смене ключа.
  • При смене ключа собеседника клиент ДОЛЖЕН перестроить доверие и СЛЕДУЕТ явно помечать риск до повторного подтверждения ключа.

6. Нормативные требования

  • Клиент НЕ ДОЛЖЕН отправлять голосовой или видеопоток звонка в открытом виде.
  • Клиент ДОЛЖЕН использовать монотонные счетчики `nonce` в пределах активной эпохи ключа.
  • Сервер ДОЛЖЕН обрабатывать E2E-пакеты как непрозрачный шифротекст.
  • Удаление локального ключевого материала ДОЛЖНО делать ранее защищенные данные недоступными для расшифровки на этом устройстве.
Изменение требований уровня «ДОЛЖЕН/НЕ ДОЛЖЕН» требует новой ревизии и синхронного обновления зависимых спецификаций.
Далее: KSMP Whisper Ultra OOB.
Threat Model / Revision 2026-03-01 / v1.1

Threat Model and Security Boundaries

This document defines threat actors, trust boundaries, and mandatory invariants for message and call security.

Contents

1. Security goals

  • Clients MUST provide confidentiality of E2E message/call payloads on untrusted transit paths.
  • Clients MUST provide integrity and authenticity of E2E packets.
  • System SHOULD provide forward secrecy for messages and key evolution for calls.
  • System MUST separate E2E content from transport/service metadata.

2. Adversary model

2.1 Passive network observer

  • Can observe IP/port/time/volume metadata but should not obtain plaintext E2E payloads.

2.2 Active network attacker

  • Can inject/drop/replay packets; clients MUST reject invalid AEAD packets and replay outside accepted window.

2.3 Malicious relay or compromised intermediate node

  • Can route and observe ciphertext but should not possess E2E decryption keys.

2.4 Coercive legal environment

  • Only data actually possessed can be disclosed; model does not assume server-side plaintext retention for E2E payloads.

3. Trust boundaries

  • Trusted: client runtime, local protected key storage, cryptographic primitives.
  • Partially trusted: API and relay as routing/state coordination components.
  • Untrusted: public network, ISP transit, intermediate delivery paths.

4. Non-goals

  • Compromised endpoints (malware, root/jailbreak, screen capture, keylogging).
  • Full anonymity of all metadata against all observers.
  • Absolute availability under DPI/filtering/routing constraints.

5. Key verification and TOFU

  • First contact uses TOFU assumptions; without out-of-band verification, first-contact MITM risk remains.
  • Client SHOULD provide SAS/QR verification and key-change warnings.
  • On peer key change, client MUST rebuild trust and SHOULD surface risk until re-verification.

6. Normative requirements

  • Client MUST NOT send call media in plaintext.
  • Client MUST use monotonic nonce counters within active key epoch.
  • Server MUST process E2E packets as opaque ciphertext.
  • Local key-material deletion MUST render previously protected data undecryptable on that device.
Changing MUST / MUST NOT requirements requires a new revision and synchronized updates across dependent specs.
Next: KSMP Whisper Ultra OOB.