Сквозное шифрование при обмене сообщениями играет важную роль для реализации полноценной безопасности на мобильных платформах. Google готовится выпустить новый протокол MLS, который позволит реализовать поддержку без ограничений по числу участников. Но все ли готовы идти по этому пути?
- Введение
- Риски безопасности для систем сквозного шифрования
- Зачем понадобился MLS?
- Принцип работы MLS и возможные несовместимости
- Какие риски нарушения безопасности учтены в MLS риски
- Одновременная поддержка протоколов MLS и RCS
- Внедрение RCS в России
- Apple и поддержка RCS
- И снова о необходимости внедрения Messaging Layer Security
- Выводы
Введение
Те, кто следят за развитием технологий безопасности для мобильных платформ, наверняка знают о готовящемся принятии нового инструмента для групповых чатов — протокола Messaging Layer Security (MLS). Его разработкой Google занимается с начала 2018 года и ранее собирался сделать его стандартом осенью 2024 года.
Рисунок 1. История разработки MLS
Протокол MLS призван обеспечить совместимость для различных вариантов реализации принципов безопасности и конфиденциальности через технологию сквозного шифрования (end-to-end encryption, E2EE) для всех участников совместных обсуждений (обмена сообщениями). Его самое большое достижение — это безопасное масштабирование сервиса для больших и очень больших групп участников.
Согласно официальному графику развития этого механизма, рабочей версией сейчас является Version 14. Что из намеченного уже достигнуто? В чём состоит усиление защищённости по сравнению с существующими средствами защиты? Какие планы на участие в процессе развития технологии групповых чатов у Apple? Об этом пойдет речь далее.
Риски безопасности для систем сквозного шифрования
Прежде чем рассматривать детально технологию MLS, коснёмся сначала самого принципа сквозного шифрования (E2EE) — способа передачи данных, при котором доступ к контенту передаваемых сообщений могут получить только адресные пользователи, участвующие в общении. Доступа к информации со стороны третьих лиц нет благодаря отсутствию у них криптографических закрытых ключей, применяемых для асимметричного или открытого шифрования. Это обеспечивает безопасную связь, лишённую рисков доступа к данным пользователей со стороны не только хакеров, но и поставщиков интернет-услуг (ISP) и других участвующих в передаче данных служб.
Протокол MLS был предложен инженерной группой Интернета (IETF) в качестве стандарта для решения задач обеспечения конфиденциальности, безопасности и целостности данных в групповых чатах. Надо отметить, что формально большинство существующих популярных служб обмена сообщениями уже и так предоставляют защиту с применением сквозного шифрования (E2EE), но они достаточно уязвимы для группового общения, где число участников существенно больше двух человек.
Расшифровать и прочитать сообщение при использовании E2EE с помощью закрытого ключа формально могут только отправитель и получатель. Но используя различные уловки, в том числе различные формы компрометации безопасности на стороне получателя или отправителя, можно реализовать уязвимость. Злоумышленники могут украсть в этом случае открытый ключ и получить возможность подслушать разговор, осуществив ту или иную форму фальсификации и выдав себя за другого человека. Можно также таким путём подделать сообщения.
Ещё одним недостатком классических систем E2EE является то, что протокол не скрывает их метаданные. То есть даже не имея доступа к содержимому сообщений, злоумышленник может собирать информацию об участниках разговоров и типах передаваемых данных. При статическом анализе этих данных можно извлечь много полезной информации.
Зачем понадобился MLS?
Главной целью внедрения нового протокола MLS (класса Group Key Agreement) является распространение новой архитектуры для реализации безопасного группового обмена сообщениями. Она призвана помочь выстроить защиту от подслушивания, фальсификации, подделки сообщений через реализацию сквозного механизма поддержки секретности передачи сообщений (Forward Secrecy, FS) и сохранения безопасности среды в условиях даже произошедшего взлома (Post-Compromise Security, PCS).
Готовящийся к принятию проект представляет собой руководство по построению коммуникационных систем на базе MLS. В нём содержится обсуждение компромиссов, связанных с безопасностью и конфиденциальностью, которые следует принимать во внимание при одновременном использовании сразу нескольких защитных механизмов безопасности, входящих в состав MLS (например, функции выбора частоты ротации открытого ключа шифрования). Приведены рекомендации по модернизации поддержки групповых чатов (необязательных для внедрения) для инфраструктур, которые не были ранее адаптированы для внедрения MLS.
Потребность внедрения MLS объясняется тем, что несмотря на широкое применение метода сквозного шифрования (E3EE) для систем обмена сообщениями, совершения звонков и видеоконференций, реально достигаемый уровень защищённости для пользователей оказывается достаточно условным. Секретные сообщения часто могут быть легко «вскрыты» со стороны, например, оператора, отвечающего за поддержку самой системы обмена сообщениями.
Принцип работы MLS и возможные несовместимости
Новый протокол MLS не требует замены существующих систем для обмена сообщениями. Он предназначен для встраивания на уровне их криптографической защиты. Но из-за этого потенциально могут возникнуть проблемы несовместимости при внедрении, связанные со спецификой действующих систем защиты сообщений.
Как уже отмечалось, MLS позволяет формировать группы для безопасного общения. Размер групп может составлять от двух до сотен тысяч участников. С точки зрения архитектуры, группа представляет собой дерево, листья которого могут динамически объединяться в различные подмножества. За каждым участников закрепляется объект LeafNode, содержащий его идентификатор, учётные данные и список возможностей. Предоставление криптографических ключей происходит через сервис KeyPackage, в параметрах которого указываются идентификаторы LeafNode и электронные подписи Signature Key. Текущее состояние конфигурации называют «эпохой» (epoch). Все отправленные сообщения распространяются в условиях текущей «эпохи».
Если в конфигурацию вводятся изменения, то затем инициируется запрос (Proposal), после выполнения которого происходит переход к новой «эпохе». Это требует выполнения команды Handshake всеми участниками, которые подготавливают общий Commit.
Сразу надо отметить, что сквозное шифрование в MLS не является обязательным (хотя большинство участников наверняка будут пользоваться им постоянно). MLS также не ограничивает формат содержимого сообщений и позволяет использовать любую полезную нагрузку.
К непосредственной поддержке MLS привлекается поставщик телеком-услуг. Но в этой роли могут выступать также федеративная система (например, единый государственный поставщик сервиса обмена сообщений), а также корпоративная служба, на эксплуатации которой находится одноранговая система обмена сообщений.
Рисунок 2. Упрощённый вид процесса обмена сообщениями на базе MLS
Для непосредственной работы MLS должны быть привлечены две отдельные службы:
- Служба аутентификации (Authentication Service, AS), позволяющая генерировать и проверять учётные данные с учётом открытого ключа.
- Служба доставки сообщений (Delivery Service, DS), которая отвечает за распространение сообщений между членами группы, а также за хранение открытого ключа, благодаря которому клиенты MLS получают групповой секретный ключ.
MLS не накладывает также специальных ограничений на особенности реализации AS и DS. Эти службы могут располагаться как на одном, так и распределёно на разных серверах, могут быть даже предусмотрены требования к выполнению каких-либо дополнительных команд со стороны пользователей.
MLS не требует от DS доставлять сообщения в определённом порядке. Приложения могут устанавливать собственные политики контроля, например, на этическое соответствие сообщений требованиям сообщества. В случае блокировки сообщения могут быть отброшены без участия службы доставки DS. Единственное существующее требование: все условия действуют в рамках одной «эпохи» (epoch), и при внесении изменений в правила сначала потребуется получить подтверждение со стороны всех участников и только потом произойдёт переход к новой «эпохе».
Рисунок 3. Процесс формирования групп и подключения участников к службе обмена сообщениями (MLS)
Какие риски нарушения безопасности учтены в MLS риски
В документе проекта MLS называются средства контроля для случаев компрометации, когда манипуляция происходит на уровне службы доставки DS. Это может выражаться, например, в переупорядочивании адресуемых сообщений или нарушении последовательности их подачи для разных пользователей в группе. Для таких «инцидентов» вводится т.н. счетчик «поколения» ("generation" counter), который позволяет обнаружить потери и контролировать упорядочивание для каждого отправителя.
Есть также специальные средства для контроля ситуации, если служба доставки (DS) вдруг начинает отказываться передавать сообщения определённому клиенту или получать от него сообщения. Обнаружить атаки такого типа «отказа в обслуживании» (DoS) другие клиенты не могут без дополнительной информации. MLS берёт на себя контроль этих рисков.
Безопасность протокола MLS стала предметом для проведения различных академических исследований. Части нового стандарта подвергались анализу на этапах выпуска Ver. 7 (2018 год), Ver. 11 (2021 год) и Ver. 12 (2020 год). Последняя проверка относилась, например, к изучению темы выявления инсайдера, сумевшего проникнуть в систему, использующую MLS.
К разработке проекта MLS привлекались также эксперты Cisco, Meta Platforms (запрещенная в России организация), CISPA, ряд оборонных исследовательских организаций (например, Naval Postgraduate School, Phoenix R&D и др.).
Одновременная поддержка протоколов MLS и RCS
Появление протокола MLS потребует получения ответа ещё на такой вопрос: что будет происходить с поддержкой уже используемого протокола Rich Communication Services (RCS)? Он был разработан для развития ранее существовавшего стандарта передачи текстовых сообщений (SMS). Стандарт RCS известен также под различными альтернативными названиями: Advanced Communications, Advanced Messaging, Message+, SMS+.
Внедрение RCS позволило добавить в своё время возможность передачи через сообщения фотографии и видео высокого разрешения, аудиосообщения, файлы больших размеров. Благодаря RCS появилось сквозное шифрование, что позволило повысить безопасность для групповых чатов, например.
Сейчас RCS используется во многих приложениях для обмена сообщениями. В частности, его поддержка имеется в Google Messages, часто используемым по умолчанию для групповых чатов на телефонах Android. Благодаря RCS, появилась поддержка шифрования в чатах, появилась защита для таких функций, как получение уведомлений о прочтении, обмен медиафайлов высокого разрешения, ввод эмодзи.
Но на мировой практике всё оказалось значительно сложней. Поддержка RCS требует не только внедрения на уровне приложений, но также поддержки со стороны сервера, то есть поставщиков телеком-услуг. Но в этой части возникли определённые трудности. Поэтому, объявляя поддержку RCS, пользователи фактически были вынуждены работать с профилем Google Messages Universal Profile 1.0, который внедряли у себя операторы телеком-услуг. Его особенность состоит в том, что он не поддерживает сквозного шифрования E2EE. В качестве обходного пути для реализации E2EE используется протокол Signal.
Рисунок 4. Внедрение RCS на платформе Android не сказывается на интерфейсе пользователя
Внедрение RCS в России
Внедрение RCS в России часто сопровождалось неопределённостью. Формально Google объявила о «глобальной доступности RCS» во второй половине 2020 г. Но параллельно на сайте Google появилась необычная карта доступности RCS. Согласно этим данным, RCS оказалась без поддержки для пользователей смартфонов Android в ряде стран.
По данным The Verge в список ограничений попали Россия и Китай. Мы нашли скриншот этой карты, где упоминаются также Иран, КНДР и Куба. Восстановить реальную картину сейчас не представляется возможным, какая-либо информация об этом отсутствует в сети, Google удалила свою карту доступности ещё в конце 2020 года. Поэтому вопрос о «глобальной доступности RCS» завис в неопределённости.
Рисунок 5. Карта доступности Google RCS (ноябрь, 2020)
Были непонятны также причины запрета. Если Google объявила о глобальной доступности, то логично предположить, что поддержку сервиса не предоставляли местные телеком-операторы (видимо, по требованиям регулятора). Но официально запрет для России связывали в местных СМИ с санкционными ограничениями со стороны властей США. Поэтому в России взамен ограничений российские операторы стали рассматривать возможность ввода собственных версий для поддержки RCS.
Рисунок 6. MTC Connect доступна пользователям смартфонов Samsung
В частности, в ноябре 2020 года о запуске собственной службы для обмена сообщениями MTC Connect объявила компания MTC, став первым и единственным на российском рынке оператором, который добавил собственную службу поддержки для безопасного обмена сообщениями с поддержкой RCS. Для этого использовалось отдельное приложение для доступа к функциям чата и переписки через SMS. В нём появилась возможность создавать групповые чаты, отправлять интерактивные сообщения, добавлять гифки, фото, локацию и звуковые сообщения, не платя при этом за чат-сообщения отдельно, как за SMS.
Но у службы MTC Connect появилось и неясное ограничение: сквозная защищённость сообщений поддерживалась только для смартфонов Samsung Galaxy, что было связано, по всей видимости, с наличием соответствующей поддержки на базе Samsung Knox. Если у собеседника не было поддержки RCS, то он получал сообщение как обычную SMS (с потерей защищённости контента, конечно). Это было неудобно, прежде всего, для пользователей iPhone, которые привыкли считать свои гаджеты самыми защищёнными, хотя фактически, забегая вперёд, возможности использования RCS отсутствуют у Apple до сих пор.
Но самым непонятным было то, что по официальным данным Google, поддержку RCS Universal Profile предоставляли на ноябрь 2020 г. все крупнейшие российские мобильные операторы. Мы попросили MTC RED прояснить эту ситуацию, но на текущий момент пока не получили комментариев по этим вопросам.
Рисунок 7. Телеком-операторы и вендоры, поддерживающие RCS Universal Profile (Google, ноябрь 2020)
Считаем, проехали. Тем более, на дворе сейчас лето 2024 года. На момент написания этого материала (июль, 2024) приложение Google Messages с поддержкой RCS свободно доступно для загрузки на территории России с маркет-плейса Google Play. Есть ли фактическая поддержка сквозного шифрования на стороне телеком-операторов — сказать сложно, вопрос требует отдельного исследования.
Apple и поддержка RCS
Отсутствие платформы Apple в экосистеме кросс-платформенного обмена сообщениями с использованием сквозного шифрования (RCS) создавало до сих пор проблему для безопасности всех без исключения пользователей во всём мире. Долгое время Apple уходила от ответа на этот вопрос и отказывалась назвать дату, когда проблема будет решена, хотя уделяла достаточно внимания поддержке E2EE.
Перемены произошли в конце прошлого года, когда наконец было объявлено, что поддержка RCS в приложении iPhone Messages появится осенью нынешнего 2024 года. Анонс запланирован вместе с запуском новой версии iOS 18.
Сейчас проверить наличие поддержки RCS уже можно на версии iOS 18 beta. Это делается по значению параметра IMS Status при выборе данных по своему оператору связи. Вместо прежнего значения «Voice & SMS» там должно появиться значение «Voice, SMS & RCS». Для использования RCS потребуется также включить опцию Advanced Data Protection.
Рисунок 8. Проверка поддержки RCS в iOS 18 Beta
Но за этим стоит ещё одна важная деталь. Как мы уже отмечали, RCS требует не только поддержки на стороне смартфона, но и со стороны телеком-оператора. Трудности с подключением RCS часто возникают только для MVNO-операторов, поскольку они не полностью транслируют весь функциональный ряд своих операторов-доноров.
Впрочем, для пользователей iPhone внедрение RCS может оказаться не таким безболезненным, как для пользователей Android, для которых практически ничего не поменялось с точки зрения интерфейса. Нынешний интерфейс iMessage содержит ряд функций, которые всё ещё несовместимы с RCS. Например, «межстрочные реплики» (inline replies).
Проблемы ждут также некоторые анимационные эффекты для iPhone, такие как «раскрывающиеся пузыри» (bubble effects), которые не поддерживаются на платформе Android. Поэтому при взаимном обмене сообщениями между смартфонами разных платформ отображение на iPhone будет не таким выразительным, как при взаимодействии только на платформе Apple.
И снова о необходимости внедрения Messaging Layer Security
Вероятно, у некоторых уже возник вопрос: зачем Google потребовалось создавать новый протокол MLS, если одна из его основных функций — поддержка сквозного шифрования — уже имеется в существующем протоколе RCS и даже не внедрена до сих пор у многих операторов в полном объёме? Зачем такая спешка?
В начале мы упоминали, что в MLS есть ещё и поддержка защищённого обмена сообщениями для большого числа участников. Но это скорей интересно для крупных корпораций, а для небольших компаний и тем более частных пользователей вполне хватает RCS.
Вопрос «Зачем» повис в воздухе… Попробуем дать своё объяснение.
Развитие стандарта в рамках консорциума GSMA требует получения согласия со стороны очень большого числа участников, причём в глобальном масштабе. Поэтому внедрение поддержки RCS со стороны телеком-операторов продвигалось так тяжело. Хотя сами смартфоны Android поддерживают сквозное шифрование, начиная с уже очень давно появившейся версии Android 8, реальная поддержка осуществляется на базе GSMA RCS Universal Profile.
Как мы уже отмечали ранее, этот профиль не поддерживает сквозного шифрования E2EE и в качестве обходного пути использует протокол Signal. Фактически отправляемые сообщения шифруются при передаче, но на стороне оператора можно прослушивать эти сообщения. Если там окажется злоумышленник или каким-то образом возникнет компрометация безопасности, то защита через шифрование будет бессмысленной.
Нельзя сказать, что до сих пор такая ситуация устраивала всех в мире. Но Google не мог сдвинуть её дальше. Сейчас многое может измениться на рынке после прихода в сегмент RCS Apple. Там уже заявили, что планируют начать работать с членами GSMA над реализацией поддержки сквозного шифрования в рамках профиля Universal Profile. Планируется сделать фреймворк для серверной части более безопасным. Поскольку экосистема безопасности теперь поддерживается со стороны Google и Apple, будущие шаги становятся осмысленными для практического внедрения.
Выводы
В манифесте текущей APK-сборки Google Message упоминает опция MLS. Это может служить явным свидетельством готовящегося появления поддержки MLS на платформе Android. Но официальных подтверждений от Google о сроках появления новой функции пока нет.
Одновременно Apple объявила о готовности внедрить поддержку RCS осенью этого года и начать активную работу с членами консорциума GSMA по полноценному внедрению сквозного шифрования для мобильной связи.
Какой стандарт станет основным в ближайшие годы и как пойдет развитие, мы узнаем, похоже, уже совсем скоро.
