Шифрование данных сообщений: разбор протоколов и вердикт

Интерфейс не объясняет причину, поддержка говорит о проблемах синхронизации, а в журнале изменений появляются осторожные формулировки про оптимизацию ключей. Но настоящая причина обычно сидит глубже: групповое сквозное шифрование — это не тот же самый сценарий, что защищённый диалог один на один.

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

Это невидимый налог сквозного шифрования, о котором мессенджеры редко говорят подробно. Пользователю обещают защищённую переписку, но практический вопрос в другом: что именно происходит под капотом? Почему протоколы, отлично работающие в диалогах, сложнее масштабировать на большие группы? Зачем инженеры несколько лет разрабатывали отдельный стандарт — RFC 9420, опубликованный в июле 2023 года, — и действительно ли MLS способен изменить архитектуру групповых чатов?

И неудобное продолжение: что E2EE прячет, а что оставляет на виду?

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

Механика сквозного шифрования: от X3DH до Double Ratchet

Сквозное шифрование — не магическая кнопка «сделать безопасно». Это набор процедур, которые решают разные задачи: знакомят устройства, договариваются о начальном секрете, обновляют ключи, защищают сообщения при компрометации и восстанавливают доверие после атаки.

Когда вы отправляете сообщение в мессенджере с E2EE, текст шифруется на вашем устройстве. Сервер получает зашифрованный набор данных и пытается доставить его адресату, но в штатной модели не должен иметь возможности прочитать содержимое. Это не означает, что сервер ничего не знает. Он может видеть технические параметры доставки, идентификаторы устройств, время отправки и другие метаданные — об этом будет ниже.

В классической архитектуре Signal Protocol важную роль играют X3DH и Double Ratchet.

X3DH: как начать разговор без одновременного подключения

X3DH (Extended Triple Diffie–Hellman) — протокол установления начального общего секрета. Его сильная сторона в том, что собеседникам не обязательно находиться онлайн одновременно.

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

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

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

Double Ratchet: ключ не должен жить вечно

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

Практический смысл здесь в двух свойствах.

• Прямая секретность (Forward Secrecy). Если атакующий сегодня получит долгосрочный ключ или содержимое текущего состояния, это не должно автоматически открыть ему всю историю сообщений. Старые ключи удаляются или перестают использоваться после продвижения цепочки.
• Защита после компрометации (Post-Compromise Security). Если устройство было временно скомпрометировано, последующие обмены могут восстановить состояние, неизвестное атакующему. Для этого стороны должны снова обмениваться свежим ключевым материалом.

Формулировка «ключ на каждое сообщение» удобна для объяснения, но технически упрощает картину. В реальном протоколе есть цепочки, пропуски, обработка сообщений не по порядку и отдельные состояния для отправки и получения. Мессенджер должен уметь принять сообщение, которое пришло позже предыдущего, не разрушив всю сессию.

Отсюда же растут требования к резервным копиям и переносу аккаунта. Если пользователь меняет телефон, добавляет новое устройство или восстанавливает историю, приложению нужно не просто скачать сообщения. Оно должно корректно восстановить доверенные состояния, проверить новые ключи и не открыть старую переписку серверу или случайному владельцу номера.

Для диалогов один на один такая конструкция хорошо масштабируется. У неё есть понятное состояние двух сторон, относительно предсказуемый расход ресурсов и ясная логика обновления ключей. Поэтому Signal Protocol стал ориентиром для большого числа защищённых коммуникационных систем, хотя конкретные реализации и дополнительные механизмы у сервисов могут отличаться.

Сквозное шифрование — это не кнопка «включить защиту», а протокол с конкретной арифметикой. От его архитектуры зависит не только стойкость переписки, но и то, как мессенджер переживает смену телефона, потерю связи и рост группового чата.

Проблема масштабируемости: почему групповые чаты требуют иного подхода

Группа — это не просто личный чат, к которому добавили ещё несколько адресатов. В ней появляется отдельное измерение безопасности: каждый участник должен получать будущие сообщения, но удалённый участник не должен иметь возможности расшифровать то, что будет отправлено после его выхода.

Самая наивная модель предполагает отдельную защищённую сессию между каждой парой участников. Для группы из пяти человек это десять пар. Для пятидесяти — уже 1225 пар, если считать каждую пару один раз. Для двухсот — почти двадцать тысяч. Это не значит, что каждый современный мессенджер буквально хранит именно такое число полноценных независимых чатов: реальные протоколы используют оптимизации. Но сама комбинаторная проблема никуда не исчезает, если архитектура строится вокруг попарного обмена.

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

Поэтому в групповых протоколах обычно применяются специальные механизмы, например sender keys — ключи отправителя. Упрощённо говоря, участник получает возможность шифровать свои сообщения с помощью собственного группового ключа, а этот ключ доставляется другим участникам через защищённые каналы. Такой подход заметно эффективнее, чем отдельное шифрование каждого сообщения для каждого получателя.

Но sender keys не отменяют проблему управления составом группы. Если участник покинул чат, его старый ключ нельзя продолжать считать доверенным. Нужно обновить ключевой материал и доставить его оставшимся участникам так, чтобы бывший член группы не получил доступ к будущим сообщениям. Если добавилось новое устройство, ему, напротив, нужно передать актуальное состояние, не раскрыв лишнее.

Именно здесь разговор об «O(N) против O(log N)» требует аккуратности. В учебной схеме попарных сессий изменение состава может затрагивать линейное число связей — O(N). В практической системе отдельные операции могут быть дешевле благодаря sender keys, кэшированию и пакетной обработке. Но чем больше группа и чем чаще меняется её состав, тем тяжелее становится координация ключей, устройств и подтверждений. MLS предлагает не косметическую оптимизацию, а другую структуру управления этим состоянием.

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

Именно поэтому разработчики годами искали компромисс между сильными свойствами E2EE и приемлемой стоимостью групповых операций. Это не вопрос лени или нежелания включать шифрование. Групповая криптография действительно сложнее личной переписки.

Стандарт RFC 9420 и протокол MLS

В июле 2023 года IETF опубликовала RFC 9420, стандартизировавшую протокол MLS (Messaging Layer Security). Его проектировали именно для защищённых групповых коммуникаций, а не как простое расширение протокола диалогов.

Ключевая конструкция MLS — Ratchet Tree, или дерево храповиков. Участники группы занимают позиции в дереве, а узлы выше них содержат производные ключевые значения. Когда участник меняет своё состояние или из группы нужно кого-то удалить, протокол обновляет не все связи со всеми участниками, а путь от изменённого узла к корню дерева.

В идеализированной модели это даёт логарифмический масштаб обновления: количество затронутых узлов растёт примерно как глубина дерева, а не как полный размер группы. Для большой группы разница между несколькими уровнями дерева и сотнями отдельных операций становится принципиальной.

MLS решает несколько задач одновременно:

• поддерживает добавление и удаление участников;
• позволяет обновлять ключевой материал при изменениях состава;
• учитывает несколько устройств и криптографических идентичностей;
• сохраняет свойства прямой секретности;
• предусматривает восстановление защиты после компрометации;
• формализует состояние группы и порядок операций над ним.

Однако «O(log N)» не означает, что любое действие в MLS всегда занимает ровно логарифмическое время и мгновенно выполняется на телефоне. Есть стоимость сериализации сообщений, доставки commit-операций, проверки подписей, хранения состояния и синхронизации с участниками, которые были офлайн. Кроме того, производительность зависит от реализации и от того, как конкретный сервис организует серверную часть.

MLS — стандарт протокола, а не готовый мессенджер. Наличие RFC само по себе не означает, что приложение автоматически стало защищённым. Нужно корректно реализовать криптографические примитивы, управление идентичностями, защиту устройств, восстановление аккаунта, уведомления о смене ключей и пользовательский интерфейс. Ошибка на любом из этих уровней способна свести преимущества математической модели на нет.

Работа над интеграцией MLS в коммерческие продукты и коммуникационные платформы продолжается. Крупные игроки отрасли изучают и реализуют разные варианты поддержки групповой криптографии, в том числе в сценариях, связанных с RCS и другими платформами обмена сообщениями. Какие именно продукты, в каком объёме и в какие сроки перейдут на MLS, зависит от их архитектуры, требований совместимости и решений по управлению ключами. Публично объявленные планы не равны завершённому развёртыванию, поэтому заявления о конкретном внедрении стоит отделять от факта доступности функции для всех пользователей.

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

Сравнение криптографических моделей: O(N) против O(log N)

Сравнивать эти два подхода как «старый плохой» и «новый хороший» было бы неправильно. Попарные протоколы и sender keys уже доказали практическую работоспособность в миллиардах пользовательских диалогов и групп. Они хорошо подходят для систем, где состав групп относительно стабилен, а сервис контролирует собственную реализацию.

MLS интересен там, где группы большие, часто меняются и должны оставаться защищёнными без пропорционального роста служебных операций. Он делает состояние группы более формальным и предсказуемым. Но цена этой предсказуемости — более сложная реализация. Нельзя просто заменить одну библиотеку на другую и считать задачу закрытой.

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

Почему размер группы — не единственный показатель

Количество участников заметно влияет на стоимость криптографических операций, но оно не единственный параметр. Группа из ста человек, которые годами остаются на своих устройствах, может быть проще для системы, чем чат из двадцати пользователей, каждый из которых регулярно меняет телефоны, подключает ноутбук и восстанавливает аккаунт из резервной копии.

На практике нагрузку формируют несколько факторов:

• Частота изменений состава. Постоянные добавления и удаления заставляют систему чаще создавать новые эпохи и обновлять ключи.
• Количество устройств. Безопасность нужно обеспечивать не абстрактному пользователю, а каждому конкретному устройству с отдельным состоянием.
• Офлайн-режим. Участник может несколько дней не подключаться, а затем должен получить актуальное состояние группы без возврата к старым ключам.
• Медиафайлы и вложения. Текст сообщения обычно невелик, тогда как фотографии, видео и документы требуют отдельного управления ключами объектов хранения.
• Миграция аккаунта. Перенос на новый телефон — один из самых неприятных сценариев для E2EE: удобство восстановления часто конфликтует с желанием не передавать ключи серверу.
• Модерация. В больших сообществах нужны администраторы, роли и автоматические действия. Каждая такая функция должна быть встроена в модель доверия, а не добавлена поверх неё как обычная серверная логика.

Иными словами, «в группе включено E2EE» ещё не описывает архитектуру достаточно подробно. Нужно знать, как распределяются ключи, когда они обновляются, что получает новый участник, что происходит с удалённым пользователем и могут ли администраторы читать сообщения.

Последний вопрос особенно важен для корпоративных систем. Организация может требовать архивирование переписки, поиск по сообщениям и юридическое хранение данных. Эти требования плохо сочетаются с идеей, что только конечные устройства владеют ключами расшифровки. В результате сервисы предлагают отдельные режимы, корпоративные ключи или серверные политики. С точки зрения управления это может быть оправданно, но называть такую систему полностью закрытой от инфраструктуры уже нельзя.

Границы приватности: что E2EE не защищает в мессенджерах

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

Маркетинговая формула часто звучит шире, чем реальная гарантия. Если текст сообщения зашифрован от сервера, это не означает, что сервер не знает, кто автор, кому адресовано сообщение и когда оно было отправлено. Не означает это и того, что содержимое нельзя прочитать на разблокированном телефоне или в облачной резервной копии.

Даже при корректно работающем E2EE могут оставаться доступны:

• Метаданные общения. Кто с кем взаимодействует, в какое время, как часто и в какой последовательности. По этим данным можно восстановить структуру команды, рабочий график или факт контакта между людьми.
• Идентификаторы и сведения об аккаунте. Номер телефона, адрес электронной почты, имя пользователя и данные регистрации могут быть связаны с перепиской независимо от шифрования текста.
• IP-адрес и сетевые параметры. Если сервис сам принимает соединение от вашего устройства, он может видеть сетевую информацию. VPN или Tor меняют картину, но добавляют собственные риски и не защищают содержимое устройства.
• Состав группы. Серверу обычно нужно знать, кто входит в чат и кому доставлять сообщения. Это не то же самое, что чтение текста, но для анализа социальных связей данных уже достаточно.
• Резервные копии. История переписки, выгруженная в облако без отдельного сквозного шифрования, становится самостоятельной точкой риска. Защита транспортного канала мессенджера не распространяется автоматически на каждый внешний бэкап.
• Уведомления и экран блокировки. Фрагмент сообщения может появиться в push-уведомлении или журнале операционной системы. В этот момент угрозой становится не криптографический протокол, а настройка интерфейса.
• Конечные устройства. Вредоносная программа, расширение с лишними правами или человек, получивший доступ к разблокированному телефону, способны увидеть сообщение после расшифровки.

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

Закрытый исходный код не доказывает автоматически, что приложение небезопасно. Но пользователю приходится сильнее полагаться на заявления разработчика и на качество внешнего аудита. В случае с открытыми протоколами вроде Signal Protocol или MLS можно изучать спецификацию и реализации, хотя это всё равно не отменяет необходимости проверять конкретный продукт.

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

Шифрование закрывает содержимое сообщения. Кто, кому, когда и откуда пишет, где хранится резервная копия и что происходит на разблокированном устройстве — это уже другие задачи, для которых одного E2EE недостаточно.

Как читать заявления о защищённой переписке

Для пользователя важны не только названия алгоритмов, но и ответы на несколько вполне приземлённых вопросов.

Во-первых, включено ли E2EE по умолчанию. Если его нужно активировать вручную, часть переписки неизбежно останется в другом режиме. Так устроены некоторые сервисы, где защищённые диалоги существуют отдельно от обычных.

Во-вторых, защищены ли групповые чаты и одинаков ли режим для разных типов сообщений. Текст, звонки, файлы, реакции, предпросмотры ссылок и резервные копии могут использовать разные механизмы. Значок замка в интерфейсе не раскрывает всех деталей.

В-третьих, как пользователь проверяет устройства собеседника. Криптография может быть безупречной, но если приложение молча принимает подменённый ключ, человек не заметит атаку посредника. Надёжная система должна уведомлять о смене ключей и давать способ сверить идентичность через безопасный канал.

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

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

Что в итоге

Шифрование данных сообщений в середине двадцатых — зрелая технология для личных коммуникаций и продолжающий развиваться набор решений для больших групп. Signal Protocol с X3DH и Double Ratchet остаётся убедительной архитектурой для диалогов один на один: она умеет работать асинхронно, регулярно обновляет ключи и предусматривает восстановление защиты после компрометации.

Но групповые чаты добавляют другую задачу. Нужно защищать не только содержание сообщений, но и постоянно меняющееся состояние группы, устройства участников и права доступа к будущим эпохам ключей. Sender keys и другие оптимизации уже позволяют строить рабочие групповые системы, однако рост размера и динамичности чата всё равно повышает стоимость координации.

RFC 9420 и MLS предлагают более системный ответ. Ratchet Tree переводит управление группой из набора многочисленных связей в структурированную древовидную модель, где изменение участника может обрабатываться по пути к корню, а не через полное перебалансирование всех отношений. Это не волшебное ускорение и не гарантия безопасности конкретного приложения, но важный шаг к масштабируемому E2EE.

Мой вердикт такой: для личной переписки мессенджер с проверенной реализацией Signal-подобного протокола остаётся разумным выбором по умолчанию. Для рабочих чатов и больших сообществ нужно смотреть не только на обещание «сквозного шифрования», но и на групповую архитектуру, управление устройствами, резервные копии и обработку изменений состава.

Работу над интеграцией MLS в коммерческие продукты и коммуникационные платформы действительно продолжают, но конкретные сроки и полнота развёртывания зависят от каждого поставщика. Пока это не повод приписывать стандарт всем крупным мессенджерам авансом. Сначала нужно проверить, включён ли он в нужном продукте, для нужного типа чата и для нужного числа устройств.

И последнее: E2EE закрывает одну дверь — доступ к содержимому сообщения для сервера и постороннего перехватчика. Остальные двери остаются: метаданные, IP-адреса, резервные копии, уведомления и само устройство. Приватность начинается не с красивого значка замка, а с понимания того, какую именно угрозу этот замок действительно закрывает.