Белая книга по безопасности iman Messenger: протокол, модель угроз и ограничения

Охват: что защищено сквозным шифрованием, а что нет

Функции, для которых серверу нужно читать содержимое, например опросы и геопозиция в реальном времени, в секретных чатах недоступны. Секретные чаты есть в веб-приложении и приложении для Android. О других клиентах в этом документе утверждений нет.

Протокол и примитивы

• Согласование ключей: X3DH (Extended Triple Diffie-Hellman). У каждого устройства есть ключ идентичности, подписанный prekey, набор одноразовых prekey и резервный (last-resort) prekey.
• Шифрование сообщений: Double Ratchet, который даёт прямую секретность и восстановление защиты ключей сообщений после компрометации.
• Реализация: веб-приложение использует открытую библиотеку @privacyresearch/libsignal-protocol-typescript — это порт сообщества на TypeScript. На Android используется signal-protocol-java 2.8.1 (org.whispersystems). Собственных шифров для содержимого сообщений iman не реализует. Примитивы — те, что описаны в документации этих библиотек (Curve25519 и XEdDSA, AES-CBC с HMAC-SHA256 для тел сообщений).
• Формат на проводе: в секретных чатах сервер принимает только метки алгоритма signal-v1 (одно устройство) и signal-v1-md (по одному конверту на устройство получателя). Открытый текст, ссылки на GIF и стикеры и опросы там отклоняются.
• Гигиена prekey: подписанный prekey меняется примерно раз в неделю, закрытая часть прежнего хранится 14 дней, чтобы запоздавшие первые сообщения ещё расшифровались, затем удаляется. Одноразовые prekey пополняются, когда сервер сообщает о малом остатке.
• Доказательство владения при регистрации ключей: новое устройство или заменённый ключ идентичности должны доказать владение закрытым ключом идентичности (подпись XEdDSA над фиксированной строкой контекста, метка времени в пределах 5 минут и одноразовый nonce). Это не даёт другой учётной записи зарегистрировать скопированный публичный набор. Сервер требует это после включения даты обязательности в своих настройках.

Модель угроз

Секретные чаты рассчитаны на защиту содержимого сообщений и файлов от:

• любого, кто наблюдает за сетью (TLS плюс сквозное шифрование);
• того, кто получил копию базы данных iman или резервную копию сервера;
• сервера iman, который лишь хранит и пересылает сообщения, при условии что вы сверили код безопасности собеседника.

Они не защищают от:

• скомпрометированного, разблокированного или заражённого устройства, а также снимка экрана или копии, сделанных другим участником;
• злонамеренного сервера, подменяющего ключи до того, как вы сверили код безопасности (доверие при первом использовании);
• изменённого кода клиента: веб-приложение загружается с сервера iman при каждом открытии, поэтому скомпрометированный сервер мог бы отдать изменённый JavaScript;
• анализа трафика и метаданных (см. «Метаданные»);
• правового или иного принуждения оператора в отношении всего, что хранится в облачных чатах.

Проверка ключей: коды безопасности и коды звонка

• Код безопасности: 60-значный числовой отпечаток Signal (версия 2), который вычисляется на вашем устройстве из обоих ключей идентичности и обоих идентификаторов пользователей (SHA-512, 5 200 итераций). Его не считает сервер, поэтому сервер не может его подделать. Обе стороны видят одно и то же число.
• Доверие при первом использовании, отдельно для каждого устройства: первый увиденный ключ устройства собеседника принимается. Новое устройство собеседника показывается как уведомление. Если вы проверили собеседника, непроверенное новое устройство блокирует отправку, пока вы его не проверите. Изменившийся ключ идентичности выводится на экран, и приложение просит вас его проверить.
• Несколько устройств: у каждого устройства свой код безопасности. Общее значение для нескольких ключей — собственное расширение iman (дайджесты ключей свёрнуты через XOR), для него нет эталонных тестовых векторов.
• Код звонка: 6-значный код, полученный из DTLS-отпечатков двух конечных точек звонка (алгоритм iman-dtls-sha256-6d-v1). Это проверка с вероятностью одна на миллион, без шага обязательства (commitment); это не ZRTP, и она ничего не говорит о ключе покадрового шифрования, который приходит по каналу Signal.
• Журнала прозрачности ключей нет. Проверка выполняется вручную.

Метаданные

Даже в секретных чатах сервер неизбежно обрабатывает идентификаторы аккаунтов, принадлежность сообщения к беседе, состав участников, время, размеры сообщений и файлов, IP-адреса, а также данные регистрации устройства и push. Сквозное шифрование защищает содержимое, но не эти сведения. Настройки приватности, например «был(а) в сети», определяют, что видят другие пользователи, а не что видит сервер.

Содержимое обычных чатов, групп и каналов хранится на сервере в зашифрованном при хранении виде (см. «Хранение на устройствах, резервные копии и восстановление аккаунта»).

Sealed sender: статус и ограничения

• Что делает: для секретных чатов запечатанное сообщение сохраняется без личности отправителя. В записи сообщения, в поле отправителя последнего сообщения беседы, в журнале синхронизации, в очереди повторной доставки и в данных, отправляемых получателю, нет идентификатора отправителя. Настоящий отправитель всё равно может удалить сообщение для всех, предъявив доказательство авторства (author proof), которое сервер хранит только как хэш.
• Как доставляется: если ключ собеседника это позволяет, веб-приложение отправляет сообщение через неаутентифицированную конечную точку доставки с правом доступа для конкретной беседы (capability) вместо токена. Если этот путь не сработал, веб-приложение не отправляет сообщение тихо повторно с аутентификацией; вы можете сами выбрать такой повтор для отдельного сообщения.
• Чего не делает: это не сетевая анонимность и не скрывает отправителя от оператора. Незадолго до этого отправитель делал аутентифицированные запросы ключей, IP-адрес и время видны, а в чате из двух человек отправитель определяется методом исключения как второй участник.
• Границы проверки: мы проверили это поведение в веб-клиенте и коде сервера. Одинаковое поведение на Android здесь не утверждается.

Push-уведомления

• Секретные чаты: текст уведомления — фиксированная общая фраза («You have a new message»). Идентификаторы чата и отправителя удаляются до передачи push платформенному провайдеру, идентификатор потока уведомлений не задаётся.
• Обычные чаты, группы и каналы: уведомление может содержать имя отправителя и фрагмент текста. Они проходят через push-сервисы Google и Apple.
• На наших серверах текст ожидающего push хранится в зашифрованном виде и очищается после доставки push.

Звонки

• Каждый звонок использует WebRTC с DTLS-SRTP. Звонки один на один могут идти напрямую или через ретранслятор; звонки через медиасервер (SFU) расшифровываются на нём, поэтому защищены только на уровне транспорта, а не сквозным шифрованием.
• Секретные звонки один на один могут добавлять покадровое сквозное шифрование: AES-256-GCM на каждый медиакадр через Insertable Streams, ключи потоков получаются через HKDF-SHA256 из секрета звонка, который два клиента обмениваются внутри сообщения, зашифрованного Signal. Сервер этого ключа не имеет.
• Честная маркировка: сервер сообщает о покадровом шифровании, только если чат секретный и все стороны заявили о поддержке. Клиент показывает метку сквозного шифрования, только если его собственный шифр работает и ключ звонка получен. В остальных случаях звонок помечается как защищённый только на уровне транспорта.
• Статус: веб-приложение это реализует. На Android путь покадрового шифрования находится за флагом сборки (SECRET_CALL_FRAME_E2EE), который по умолчанию выключен, поэтому звонки на Android защищены на уровне транспорта, если сборка не включает этот флаг.
• Для обычных и групповых звонков сквозное шифрование не заявляется.

Хранение на устройствах, резервные копии и восстановление аккаунта

• На веб-устройстве: ключи Signal, сессии и расшифрованные данные сообщений в IndexedDB браузера защищены AES-256-GCM под неэкспортируемым ключом WebCrypto. Необязательный PIN оборачивает ключи через PBKDF2-HMAC-SHA256 (по умолчанию 600 000 итераций). Ограничение: код, выполняемый в том же origin, может использовать ключ, пока приложение разблокировано, а скомпрометированное устройство обходит эту защиту.
• Резервных копий секретных чатов нет: ни серверной копии, ни депонирования ключей. Секретные чаты существуют только на устройствах, где они созданы. Если вы потеряете их все, история исчезнет. Повторная регистрация с тем же номером возвращает облачные чаты, но не секретные.
• Облачные чаты на сервере: текст и вложения хранятся в зашифрованном виде с аутентифицированным шифрованием под набором ключей на стороне сервера. Это защищает от кражи диска или копии базы, но не от оператора, у которого есть ключи.

Несколько устройств

• У каждого устройства свой ключ идентичности и свой идентификатор устройства Signal. Отправитель шифрует отдельно для каждого устройства получателя (конверт signal-v1-md).
• В настройках показан список устройств, которые могут читать ваши секретные чаты. Удаление устройства прекращает доставку сообщений на него и завершает его сессии.
• История секретных чатов на новое устройство не переносится.
• Когда проверенный собеседник добавляет устройство, которое вы не проверили, отправка блокируется, пока вы не сравните код безопасности этого устройства.

Исчезающие сообщения

В секретном чате таймер чата может задать любой из участников. Сообщения с истёкшим сроком физически удаляются с сервера периодической очисткой. Таймер не может заставить устройство собеседника удалить копию, снимок экрана или пересланное сообщение.

Известные ограничения и пробелы

• Группы, каналы и обычные чаты не защищены сквозным шифрованием.
• Секретные чаты бывают только один на один и только в веб-приложении и приложении для Android.
• Пока вы не сверили код безопасности, злонамеренный сервер мог бы подменить ключи. Журнала прозрачности ключей нет.
• Sealed sender — это не сетевая анонимность.
• Веб-приложение доверяет коду, который сервер отдаёт при каждой загрузке.
• Звонки: сквозное шифрование только у согласованных секретных звонков один на один; на Android путь по умолчанию выключен; код звонка — небольшая проверка.
• Код безопасности для нескольких устройств — собственное расширение без эталонных векторов.
• Размеры сообщений, время и социальный граф видны серверу.
• Криптография опирается на сторонние библиотеки, чьи аудиты мы не контролируем, и независимого аудита того, как iman их использует, мы не публиковали.

Статус аудита, тестирования и bug bounty

• Независимый сторонний аудит безопасности: по состоянию на 2026-10-08 не опубликован.
• Внешняя экспертиза криптографического дизайна: не опубликована.
• Внутренняя работа: автоматические тесты покрывают код безопасности, доверие к ключам, prekey и sealed sender, а мессенджер был проверен внутренним обзором 2026-10-03. Внутренний обзор не является независимым аудитом; считайте утверждения этого документа заявлениями самой компании.
• Bug bounty: платной программы сейчас нет.
• Если что-то из этого изменится, этот раздел и история изменений будут обновлены.

Ответственное раскрытие уязвимостей

Если вы нашли уязвимость, напишите по контакту безопасности ниже: укажите, что вы обнаружили, как это воспроизвести и на какой платформе. Пожалуйста, не обращайтесь к данным других людей, не нарушайте работу сервиса и не публикуйте сведения о проблеме до того, как мы успеем ответить. Мы не предлагаем вознаграждения и пока не публикуем обязательств по срокам ответа. Машиночитаемый контакт находится в /.well-known/security.txt.

Контакт по безопасности: privacy@iman.tj

Как проверить код безопасности собеседника в секретном чате iman

Сравните 60-значный код безопасности с собеседником, чтобы убедиться, что никто не подменил ключи шифрования вашего секретного чата.

1. 1. Откройте секретный чат

   Создайте или откройте секретный чат с собеседником в веб-приложении или приложении для Android. Именно секретные чаты защищены сквозным шифрованием.

2. 2. Откройте код безопасности

   Откройте сведения о безопасности чата и выберите «Проверить» (Verify), чтобы увидеть код безопасности: 60 цифр группами по пять.

3. 3. Сравните его по отдельному каналу

   Сравните число с тем, что на экране собеседника: лично или во время звонка, где вы узнаёте его голос. Не сравнивайте через этот же чат.

4. 4. Отметьте как проверенный, только если всё совпало

   Если числа совпадают, отметьте собеседника как проверенного. Если нет, не подтверждайте: у каждого устройства свой код, поэтому убедитесь, что сравниваете код того устройства, которым пользуется собеседник, а устойчивое несовпадение считайте возможным перехватом.

5. 5. Проверьте заново после уведомления об изменении

   Если iman показывает, что код безопасности изменился или собеседник зарегистрировал новое устройство, сравните снова, прежде чем отправлять что-либо важное.

6. 6. По желанию проверьте код звонка

   Во время звонка так же сравните 6-значный код звонка с собеседником. Он проверяет соединение звонка, а не ключи сообщений.

Вопросы и ответы

Есть ли в iman Messenger сквозное шифрование?

Только в секретных чатах: это чаты один на один в веб-приложении и приложении для Android на протоколе Signal. Обычные чаты, группы, каналы и большинство звонков шифруются при передаче и при хранении на сервере, но сквозного шифрования у них нет.

Может ли iman читать мои обычные чаты?

Технически да. Обычные чаты, группы и каналы хранятся на сервере в зашифрованном при хранении виде, а ключ находится на стороне сервера. Для разговоров, которые iman не должен мочь прочитать, используйте секретный чат.

Какой протокол шифрования iman использует в секретных чатах?

Протокол Signal: согласование ключей X3DH и Double Ratchet, реализованные готовыми библиотеками семейства libsignal, а не собственными шифрами.

Защищены ли групповые чаты сквозным шифрованием?

Нет. Группы и каналы — облачные чаты, групповые ключи отправителя в них не используются.

Раскрывают ли уведомления содержимое сообщений?

Для секретных чатов уведомление — общая фраза без идентификаторов чата и отправителя. Для остальных чатов оно может содержать имя отправителя и фрагмент текста, которые проходят через push-сервисы Google или Apple.

Проходил ли iman независимый аудит?

Пока нет. Независимый аудит не опубликован, платной программы bug bounty нет. Мессенджер проходил только внутреннюю проверку.

Как сообщить об уязвимости?

Напишите по контакту безопасности на этой странице или по адресу из /.well-known/security.txt. Укажите шаги воспроизведения и затронутую платформу.

История изменений

• 2026-10-08: Первая публикация. Документ описывает поведение кода клиентов и сервера iman на эту дату.
• 2026-10-04: Исправления по итогам внутренней проверки, присутствующие в коде, с которого написан этот документ: доказательство владения при регистрации ключей, право доставки (capability) для sealed sender, разделяющее секрет получателя и учётные данные отправителя, отсутствие тихого перехода от sealed-отправки к аутентифицированной и доверие при первом использовании для каждого устройства, блокирующее отправку проверенному собеседнику на его непроверенное новое устройство.
• 2026-10-03: Завершён внутренний обзор безопасности мессенджера. Это не независимый аудит.