Системы мгновенного обмена сообщениями (мессенджеры) в современном понимании стали продолжением систем IRC (1988 год) и ICQ (1996 год), а сегодня они переживают бум своего развития, вызванный ростом скорости, доступности и стабильности систем беспроводной связи. Всем известны WhatsApp, Viber, iMessages, Facebook Messenger. В России в свое время обсуждался проект по созданию государственного мессенджера, который могли бы использовать чиновники и сотрудники госкомпаний. Однако после обнародования материалов Эдварда Сноудена внимание общественности и научного сообщества привлекли вопросы обеспечения конфиденциальности и сохранения тайны личной переписки. Как следствие, появился протокол безопасного обмена мгновенными сообщениями Signal, который был интегрирован в мессенджеры WhatsApp и Facebook Messenger.

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

  • Конфиденциальность разговора. Вербальный разговор между собеседниками можно считать конфиденциальным при условии, что никто не слышит беседы участников.
  • Идентификация и аутентификация участника разговора. Собеседника мы обычно узнаем (идентифицируем) по его персональным особенностям (голос, внешность и пр.), запоминаем их вместе с именем участника диалога при первом знакомстве, а впоследствии убеждаемся в том, что перед нами именно тот человек, за которого он себя выдает.
  • Аутентификация источника данных. Проверка и подтверждение того, что информация создана именно заявленным участником разговора. Обычно в разговоре можно определить, кто и что сказал, однако при цифровом общении это не очевидно. В рамках данного свойства также выделяют понятие «целостность» — отсутствие изменения в передаваемой информации, то есть подтверждение того, что мы услышали ровно то, что сказано. Обычно собеседники при вербальном разговоре не задумываются об этом свойстве, однако при цифровом общении, когда данные легко сохранять и изменять, оно становится крайне важным.
  • Возможность отказа от авторства. При вербальном разговоре двух лиц третье лицо, при условии выполнения свойства конфиденциальности, может узнать содержание беседы только со слов одного из участников. При этом, при отсутствии подслушивающих лиц и записывающих устройств, нет возможности доказать, что конкретный участник вербального разговора говорил именно то, что утверждается третьим лицом. Таким образом, для цифрового общения надо исключить возможность кого-либо доказать авторство сообщения и, более того, доказать сам факт разговора.

Логично, что перечисленные свойства вербального разговора должны соблюдаться и при цифровом общении, что обеспечивается соответствующими криптографическими механизмами — алгоритмами шифрования и имитозащиты (контроля целостности). Тем не менее нельзя исключать возможности попадания секретных ключей таких алгоритмов в руки злоумышленников, например, из-за уязвимостей в программном обеспечении или из-за иных факторов. Поэтому требуется минимизировать потенциальный вред от подобных ситуаций, что обычно достигается частой сменой ключа. Например, в протоколе Signal для каждого сообщения вырабатывается новый секретный ключ шифрования, и логично требовать от подобных алгоритмов свойств обеспечения защиты от чтения назад (perfect forward secrecy) и вперед (post-compromise security). При обеспечении данных свойств, даже если злоумышленнику стал известен секретный ключ, по алгоритму смены ключа он не должен ничего узнать ни о предыдущих, ни о последующих секретных ключах.

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

Принципы построения мессенджеров

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

Все системы мгновенного обмена сообщениями по своей архитектуре можно разделить на две группы: с симметричным (например, Briar [1]) и асимметричным каналом связи (например, WhatsApp [2]). При использовании систем первой группы обмен сообщениями между двумя пользователями возможен, только когда оба подключены к общему каналу передачи данных, а в случае применения систем второй группы обмен сообщениями между пользователями возможен при условии, когда хотя бы один из них имеет доступ к общему каналу передачи данных. Построение асимметричного канала требует наличия сервиса доставки — устройства, постоянно подключенного к каналу связи, хранящего сообщения (если получатель «не в сети») и пересылающего их пользователю, когда он появится в сети. Впервые основы построения систем мгновенного обмена сообщениями с симметричным каналом связи с криптографической точки зрения были изложены в работе [3].

Процесс взаимодействия двух участников разговора A и B начинается с выработки общего секрета и аутентификации абонентов. Выработка общего секретного ключа осуществляется c помощью протокола Диффи — Хеллмана с параметрами p и g в группе Zp, где p — некоторое простое число, а g — образующий элемент подгруппы группы Zp. Стороны A и B вырабатывают секретные ключи xA, xB и передают друг другу открытые ключи gxAи gxB, а общим секретом является величина gxAxB. Общий секрет используется для выработки секретных ключей алгоритмов шифрования и имитозащиты. По наблюдаемым в канале связи значениям gxAи gxB злоумышленнику достаточно сложно определить общий секрет gxAxB, однако он может реализовать атаку «человек посередине». Для ее исключения при первом выполнении протокола Диффи — Хеллмана происходит аутентификация абонентов путем применения схемы электронной подписи:

A → B : Sign(gxA,kA), KA;

B → A : Sign(gxB,kB), KB,

где kA и KA — соответственно секретный и открытый ключи абонента A, kB и KB — соответственно секретный и открытый ключи абонента B, а Sign — процедура вычисления электронной подписи.

Обратим внимание на то, что уже говорилось о возможных угрозах обеспечению свойства отказа от авторства при использовании схем электронной подписи, однако в современных системах зачастую набор величин gxA и gxB , подписанный соответствующими пользователями, опубликован заранее, и для установления разговора нужно взять уже «общеизвестные» величины Sign(gxA,kA), KA с указанием второму пользователю, какие именно ключи он хочет использовать для соединения. В этом случае уже будет невозможно доказать даже факт попытки установления разговора.

Следующий этап процесса взаимодействия двух участников разговора A и B — выработка ключей шифрования и имитозащиты. Эти ключи вырабатываются из общего секрета путем применения однонаправленной функции — например, хеш-функции, использование которой позволяет в случае необходимости «расширить» общий секрет до нужного размера, получив ключи шифрования и имитозащиты. На ключи шифрования накладываются требования о коротком сроке их эксплуатации: предлагается менять их как можно чаще, например после каждого сообщения. При этом использованные ключи должны сразу удаляться из памяти устройства, а для обеспечения защиты от чтения вперед также необходимо по протоколу Диффи — Хеллмана постоянно вырабатывать новые общие секреты.

Далее выполняется этап передачи сообщений, шифруемых с помощью блочного шифра, например, работающего в режиме CTR (Counter mode — режим счетчика) или GCM (Galois/Counter Mode). Первый режим обеспечивает только конфиденциальность передаваемых данных, и для обеспечения аутентификации источника данных дополнительно используют ключевые хеш-функции — например, HMAC (Hash-based Message Authentication Code). Она вырабатывает имитовставку — «контрольную сумму» сообщения, по которой обладатель секретного ключа может проверить, является ли полученное сообщение неповрежденным и неизмененным. Причем сформировать «правильную» имитовставку может только обладатель секретного ключа имитозащиты. Режим GCM позволяет шифровать сообщения и одновременно вырабатывать имитовставку с помощью только одного секретного ключа. Подобные режимы называются «режимами шифрования с имитозащитой».

Таким образом, конфиденциальность сообщений обеспечивается за счет их шифрования алгоритмами блочного шифрования, аутентификация источника данных и контроль целостности сообщений — за счет использования ключевой хеш-функции или режима шифрования с имитозащитой, а отказ от авторства достигается либо за счет разглашения использованных секретных ключей имитозащиты, как в протоколе OTR (Off-the-Record Messaging), либо за счет разглашения открытых ключей из протокола Диффи — Хеллмана, как в протоколе Signal.

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

Во втором случае злоумышленник может составить переписку, «неотличимую от настоящей». Никто, кроме владеющих секретным ключом xA или xB по ключам gxAи gxB, не может проверить, что некий заявленный общий секрет ga действительно равен величине gxA и gxB. Соответственно, без разглашения секретных ключей пользователя невозможно доказать сам факт разговора между конкретными пользователями. Даже в случае разглашения одним из пользователей своего секретного ключа, другой участник разговора может отказаться от авторства всех переданных сообщений. Действительно, по ключам xA и gxB можно выработать общий секрет gxAxB и «идентичную настоящей» переписку.

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

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

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

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

В целом подход с симметричным каналом похож на идею «криптоанархии»: никто друг другу не доверяет, и система зависит только от самих участников и поддерживается только их силами. К минусам подхода следует отнести высокую нагрузку на устройство пользователя, которому требуется постоянно вычислять новые ключи, выполнять шифрование и хранить сообщения до появления адресата в сети. Также необходимо доверять инфраструктуре открытых ключей, которая будет хранить значения Sign(gxA,kA), KA, либо требуется личная встреча для обмена значениями Sign(gxA,kA), KA.

В качестве примера такой системы можно назвать проект Briar [1] по созданию приложения для обмена сообщениями, предназначенного для всех, кому нужен безопасный, простой и надежный способ общения. В отличие от традиционных инструментов обмена сообщениями, таких как электронная почта, Twitter или Telegram, Briar не использует центральный сервер: сообщения передаются напрямую между устройствами пользователей. Структура Briar похожа на протокол OTR [2], но с существенным отличием: после выработки общего секрета все новые ключи шифрования и имитозащиты вырабатываются с помощью однонаправленной функции из старых ключей без «подмешивания» нового общего секрета. Таким образом, если злоумышленник в какой-то момент узнал один ключ шифрования, то он сможет читать всю последующую переписку пользователей.

Все привычные и наиболее распространенные мессенджеры относятся к системам с асимметричным каналом связи, а их популярность во многом обусловлена удобством: можно отправлять сообщения и получать их вне зависимости от того, в каком режиме находится другой пользователь (онлайн или офлайн). Однако для обеспечения такого свойства требуется дополнительный участник системы — сервис доставки, то есть устройство, всегда подключенное к сети. В процессе обмена сообщениями пользователь отправляет сообщение не напрямую адресату, а сервису доставки, который хранит у себя полученное сообщение и пересылает его адресату, когда тот появится в сети. С точки зрения удобства логично также предоставить пользователям возможность асинхронно аутентифицировать друг друга и вырабатывать общие ключи. Иными словами, для выработки общего секрета пользователям необязательно быть одновременно в сети, но тогда требуется еще и сервис аутентификации, обеспечивающий создание и хранение (регистрацию) идентификатора пользователя, сертификатов открытых ключей, а также предоставление всей этой информации другим пользователям. Зачастую сервер аутентификации и сервер доставки данных представляют собой одно устройство, тем не менее их стоит разделять по функционалу.

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

Далее пользователь B проверяет подпись полученных в сообщении открытых ключей пользователя А и по ним вырабатывает общий секрет и расшифровывает сообщение. Для отправки нового сообщения пользователь B вырабатывает новый открытый ключ, с помощью полученного ранее открытого ключа пользователя А вырабатывает новый общий секрет по протоколу Диффи — Хеллмана и с его помощью шифрует свое новое сообщение. Пользователь В вместе с зашифрованным сообщением также передает свой новый открытый ключ пользователю А. Ситуация повторяется зеркально: для отправки нового сообщения пользователь А вырабатывает новый открытый ключ, с помощью полученного ранее открытого ключа пользователя В вырабатывает новый общий секрет по протоколу Диффи — Хеллмана и с его подписью шифрует свое новое сообщение. Пользователь А вместе с зашифрованным сообщением также передает свой новый открытый ключ пользователю В. Здесь задействованы два основополагающих протокола для построения асимметричного безопасного канала связи: X3DH и Double Ratchet.

Протокол X3DH (Extended Triple Diffie-Hellman) — это асинхронный протокол согласования ключей, позволяющий двум участникам выработать общий секрет на основе открытых ключей и одновременно провести аутентификацию участников протокола. В данном протоколе пользователь А запрашивает три подписанных ключа пользователя В, которые тот заблаговременно (например, при свой регистрации) разместил на сервисе аутентификации, и для каждого подписанного ключа выполняет протокол Диффи — Хеллмана. Новый общий секрет получается путем объединения (конкатенации) результатов работы трех протоколов Диффи — Хеллмана.

Double Ratchet — протокол, позволяющий двум участникам с помощью предварительно распределенного общего секрета, выработанного по протоколу X3DH, обмениваться зашифрованными сообщениями. В данном протоколе один участник вырабатывает новый общий секрет по протоколу Диффи — Хеллмана с помощью старого открытого ключа другого пользователя (полученного, например, в предыдущей итерации данного протокола, выполненного другим участником) и своего нового секретного ключа (вырабатываемого в процессе выполнения данного протокола; при этом соответствующий открытый ключ пересылается в открытом виде другому участнику вместе с зашифрованным сообщением).

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

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

В криптографии предполагается, что если что-то может пойти «не так», то рано или поздно это случится. Например, если сервису аутентификации теоретически доступна возможность читать переписку пользователей, то рано или поздно он начнет это делать. В связи с чем, с точки зрения криптографа, нельзя считать подобные системы надежными.

Мессенджеры: риски и проблемы

В современных системах мгновенного обмена сообщениями имеется ряд рисков и нерешенных проблем.

Никто не знает, что именно реализовано в его устройстве. На заре появления систем мгновенного обмена сообщениями, для обеспечения безопасности информации зачастую криптографические механизмы либо вовсе не использовались, либо использовались протоколы, стойкость которых основана на принципе «security through obscurity», то есть защищенность обеспечивалась не свойствами протокола, а отсутствием его описания в открытых источниках. Как следствие, подробный анализ свойств данных приложений широким академическим сообществом не выполнялся. На сегодняшний день данная проблема частично решена благодаря использованию протоколов OTR (первая версия появилась в 2004 году) и Signal (первая версия появилась в 2013 году), которые постоянно дорабатываются.

Никто не знает, как именно реализованы протоколы. Стойкость протоколов основана на предположении о том, что некоторые величины выбираются случайно и равновероятно, но на практике они выбираются генератором псевдослучайных чисел, конструкция и статистические свойства которого в протоколах не определяются. Однако именно генераторы наиболее уязвимы для внедрения различного рода «закладок» [4–6]. Даже если система реализует стойкий, проверенный временем протокол, злоумышленник может получить доступ ко всей переписке, если в алгоритме генерации ключей есть закладка. К сожалению, в открытом доступе зачастую отсутствуют спецификации датчиков, используемых в наиболее популярных мессенджерах, и конечный пользователь вынужден доверять их разработчикам. В криптографии же постулируется: «если мы не знаем, как конкретно реализована та или иная функция, то значит, она может быть реализована плохо».

Никто не знает, соответствует ли реализация протокола его заявленному описанию. Нередко о наличии того или иного протокола в мессенджере становится известно лишь из заявлений его авторов. При этом проверить наличие протокола в конкретной версии мессенджера или корректности реализации протокола зачастую не представляется возможным. Однако, даже если на стороне клиента все реализовано корректно, невозможно проверить, что сервис аутентификации неукоснительно следует заявленному протоколу. Например, сервис аутентификации может выступать в качестве «человека посередине». Для защиты от подобного рода атак некоторые мессенджеры предлагают пересылать проверочные коды по «доверенному каналу связи». Например, в WhatsApp пользователи могут проверять совпадение на устройствах «кода безопасности» из 60 цифр. Данный подход требует либо личной встречи, либо существования такого «доверенного канала связи» между пользователями. Тем не менее лишь немногие пользователи действительно регулярно используют данную функцию, а еще меньше проверяют, что данные коды безопасности действительно сформированы так, как это заявлено в спецификации этого мессенджера [2].

***

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

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

Литература

1. URL: htpps://briarproject.org (дата  обращения:  19.11.2020).

2. WhatsApp Encryption Overview. Technical white paper. URL: https://scontent.whatsapp.net (дата  обращения:  19.11.2020).

3. Nikita Borisov, Ian Goldberg and Eric A. Brewer. Off-the-record communication, or, why not to use PGP. In Proceedings of the 2004 ACM Workshop on Privacy in the Electronic Society, WPES 2004, Washington, DC, USA, October 28, 2004,  P. 77–84,  2004.

4. Маркелова А. Внедрение  закладок в генератор ключей  RSA. Презентация  с конференции «РусКрипто’2019».

5. КриптоПро. Кое-что  о закладках, или Как АНБ следит за  пользователями. URL:  https://www.cryptopro.ru/blog/2015/11/10/koe-chto-o-zakladkah-ili-kak-anb-sledit-za-polzovatelyami  (дата обращения: 19.11.2020). 

6. Anderson R. A practical RSA  trapdor //  Electronics  Letters. — 1993. — Vol. 29, N. 11. — P. 995. 

Дмитрий Богданов (bogdanovds@rambler.ru) — ассистент, МИФИ; Владислав Ноздрунов (nozdrunov_vi@tc26.ru) — эксперт, Технический комитет по стандартизации «Криптографическая защита информации» (ТК 26) (Москва).

DOI: 10.26295/OS.2020.51.98.002