Разработка безопасного корпоративного мессенджера

О проекте

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

Задача

Перед командой стояла задача за 6 месяцев разработать мессенджер, который по уровню безопасности не уступал бы мировым лидерам индустрии, таким как WhatsApp или Telegram.

Решение 

Индивидуальные и групповые чаты:

Обмен сообщениями, файлами и медиаконтентом.

Аудиозвонки:

Возможность совершать звонки внутри приложения.

Понятный интерфейс:

Перенос привычных пользователям паттернов из популярных мессенджеров для быстрого освоения продукта.

Масштабируемость:

Приложение включает 15 модулей и более 120 нативных экранов на каждую платформу

Технические вызовы 

Аудиоконференции по схеме MCU (многоточечный блок управления): многоточечный блок управления позволяет значительно сократить расход трафика пользователей по сравнению с FM (Full Mesh (полносвязная топология) — все участники соединены между собой и отправляют и получают аудио попарно) и SFU (Selective Forwarding Unit (селективный сервер пересылки) — участники отправляет свое аудио один раз на сервер и получают входящее аудио от всех других участников по отдельному каналу) и сделать его не зависящим от количества участников конференции.
Для схемы MCU (многоточечного блока управления) на каждого абонента приходится всего 2 аудио-канала, исходящий и входящий, смиксованный из каналов других участников. Сервер совершает дополнительную работу по декодированию, миксованию и кодированию потоков, но трафик каждого участника постоянен и не зависит от размера конференции. Это позволяет создавать аудиоконференции с любым количеством контактов.
Наши исследования также показали, что, при использовании современных кодеков и количестве участников больше 8, нагрузка на сервер оказывается даже ниже, чем при использовании SFU (селективного сервера пересылки).

Протокол Диффи — Хеллмана разорван во времени для генерации сессионного ключа с пользователем, находящимся вне сети:

Мы хотели предоставить нашим пользователям максимальный уровень конфиденциальности переписки и решили, что нам необходимо иметь, так называемую, совершенную прямую безопасность (Perfect Forward Secrecy или PFS). Совершенно прямая безопасность заключается в том, что долгосрочная ключевая информация, хранимая на устройствах пользователей, не используется для шифрования сообщений и документов. Вместо этого, между пользователями создается временный (эфемерный) ключ, который меняется с каждым новым сообщением, а долгосрочные ключи используются только для взаимной аутентификации.
Таким образом, утечка долгосрочных ключей может скомпрометировать переписку пользователей, которая состоится после факта утечки, но не позволит злоумышленнику расшифровать трафик, сформированный до утечки ключей.
Проблема совершенной прямой безопасности заключается в необходимости присутствия двух пользователей в момент начала коммуникации для согласования эфемерного ключа по процедуре Диффи — Хеллмана. Очевидно, что пользователи мобильных устройств могут быть иногда недоступны (поэтому, например, если вы пользуетесь секретными чатами Телеграм, то, при создании такого чата, вы видите сообщение «Ждем, когда собеседник будет онлайн» — это связано с тем, что приложению необходимо согласовать эфемерный ключ).
Для решения этой проблемы мы применили методику «разрыва» процедуры Диффи — Хеллмана во времени. Каждый пользователь публикует свои «частичные» ключи (которые при стандартной процедуре он должен отправлять в ответ на запрос согласования) заранее на сервере (разумеется, снабжая их своей подписью и временем жизни), и, если мы хотим создать защищенную сессию с новым контактом, то мы забираем «частичный» ключ и считаем его «ответом» пользователя на наш запрос согласования, то есть можем сформировать полный ключ и начать отправлять сообщения и документы.
Получатель сессии, будучи онлайн, загрузит с сервера запрос на создание сессии и «доформирует» его до эфемерного ключа (суть протокола Диффи — Хеллмана в том, что этот эфемерный ключ будет таким же, какой получил инициатор сессии) и сможет расшифровывать входящие сообщения.

Локальная история сообщений:

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

Long Poll (длинные опросы) для доставки асинхронных уведомлений по принципу Weak Updates (слабые обновления):

В ходе использования приложения, возникает огромное количество событий, о которых мы хотим уведомить пользователей моментально. Например, если другой пользователь начал печатать, сменил аватарку, поменял имя или прислал нам новое сообщение, а может, просто вышел онлайн.
Доставка таких уведомлений — серьезная нагрузка на сервер. Существует множество подходов и нами был выбран тот, который позволит обслуживать огромные пулы пользователей и горизонтально масштабироваться с ростом аудитории — так называемый Weak Messaging (слабая модель обмена сообщениями).
Если время сессии (продолжительность взаимодействия пользователя с приложением) невелико и составляет 10−20 минут в день, допустим подход с периодическим запросом изменений. В этом случае обновления доставляются «псевдо-асинхронно», это создает достаточно большую паразитную нагрузку на сеть, батарею устройства и сервер.
В приложениях, где требуется «честная» асинхронная доставка обновлений используют два подхода: Strong Messaging (строгая модель обмена сообщениями)  и Weak Messaging (слабая модель обмена сообщениями). Разница заключается в том, что в Strong Messaging (строгой модели обмена сообщениями) любое состояние приложения может быть обновлено до текущего актуального состояния. Этот подход значительно проще реализовать как на клиенте, так и на сервере, однако он имеет предел пользовательской базы, поскольку создает большую нагрузку на базу данных сервера.
Weak Messaging (слабая модель обмена сообщениями), напротив, позволяет обновить пользователя до актуального состояния только в определенном (небольшом) временном интервале, поэтому в нем различается синхронизация «холодного» старта, которая осуществляется запросом текущего состояния, и «горячая» синхронизация, осуществляемая отправкой обновлений. Этот подход обладает преимуществом Strong Messaging (строгой модели обмена сообщениями)  — асинхронную доставку атомарных обновлений — и не создает высокой нагрузки на диски / базу данных сервера, поскольку «слабые» обновления существуют только в оперативной памяти (этим и вызвано ограничение во времени на окно синхронизации). Если клиентское приложение по каким-либо причинам вышло за пределы окна синхронизации, оно будет вынуждено повторно провести «холодную» синхронизацию, чтобы вернуться к «горячим» обновлениям.