Когда делаешь приватный мессенджер, рано или поздно упираешься в неудобный вопрос: что именно защищает пользователя, ваши обещания или ваша архитектура. Обещания не проверить снаружи. Поэтому в RCQ мы старались, чтобы приватность держалась на устройстве и на структуре данных, а не на том, что мы хорошие ребята.
В этой статье разберём две вещи, которые из этого выросли: острова (свой сервер) и мультиличность (несколько независимых зашифрованных аккаунтов на одном телефоне). И отдельно, без прикрас, расскажем, где у этого подхода границы.
1. Фундамент: сервер, который мало что знает
Сначала коротко про основание, иначе дальше будет непонятно.
Идентификатор это UIN, просто число. Никакого номера телефона, никакой загрузки списка контактов. Аккаунт не привязан к личности, его можно сжечь и завести новый за секунды.
Sealed sender: отправитель запечатан внутри зашифрованного конверта, а не лежит в заголовке. На транспортном уровне сервер видит "кому доставить", но не "от кого". Кто это понимает, тот сразу видит, что граф общения на сервере не собирается.
Контент шифруется end-to-end: эфемерный X25519 на сообщение, HKDF, ChaCha20-Poly1305. Сервер пересылает шифротекст, ключей у него нет.
Идея простая: сервер это в основном тупая труба для шифротекста. Нет телефонов, нет графа, нет содержимого. Это важно для всего дальнейшего.
2. Острова: свой сервер вместо нашего
Раз сервер это тупая труба, его можно вынести куда угодно. Любая организация (редакция, юрфирма, команда, НКО) поднимает свой экземпляр RCQ, свой остров, и общается внутри него: свой сервер, свои UIN, своя история, свои группы, отдельно от публичной сети.
Что это даёт на практике:
Нет одной большой мишени. Публичная сеть это единая точка интереса. Сто отдельных островов это сто отдельных целей, и компрометация одного не трогает остальные.
Метаданные (то немногое, что вообще есть) остаются у владельца острова, а не у нас.
Снимается вопрос "а если на вас надавят". Если сервер ваш, давить надо на вас, а не на нас, и вы сами решаете, что на нём хранится. А хранить, напомню, почти нечего.
Технически клиент не прибит к нашему домену: адрес сервера это параметр. Подключиться к острову можно прямо при регистрации или добавить аккаунт на нём позже. Что подводит ко второй части.
3. Мультиличность: несколько вас на одном телефоне
Задача звучала так: дать на одном устройстве набор полностью независимых личностей. Не темы оформления, а разные аккаунты: у каждого свой сервер, свой UIN, свои ключи, свои контакты и своя история. Рабочая на корпоративном острове, личная на публичной сети, ещё одна под что-то третье. И переключение между ними мгновенное, без перелогинов и без перезапуска приложения.
Главная сложность тут не в UI, а в том, чтобы личности реально не протекали друг в друга. Сделаешь спустя рукава, и данные одной всплывут в другой, и вся затея бессмысленна. Поэтому изоляция идёт до самого низа, и ключ всего этого это локальный UUID аккаунта:
Реестр аккаунтов хранит только метаданные маршрутизации: этот UUID, адрес сервера, метку. Секретов в нём нет.
Секреты каждого аккаунта (UIN, токен, приватные ключи) лежат в зашифрованном хранилище под префиксом его UUID. Файл физически один, но слоты не пересекаются.
База сообщений у каждого аккаунта своя, отдельным файлом с UUID в имени. Треды не смешиваются на уровне файловой системы.
Избранное, архив, счётчики непрочитанного тоже разложены по этому префиксу.
Переключение это горячая пересборка: рвём текущее соединение, перенаводим все хранилища на UUID другого аккаунта, перечитываем его базу, поднимаем сокет заново. Снаружи это выглядит как мгновенная смена личности, внутри это аккуратная замена того, на какие данные смотрит работающий процесс.
Отдельная возня была с апгрейдом старых установок. У кого уже был один аккаунт со старой схемой (без префиксов), он при первом запуске молча оборачивается в первый аккаунт реестра: генерим UUID, переносим под него ключи, переименовываем файл базы. Со стороны пользователя не происходит ничего, и это правильно, апгрейд не должен ничего ронять.
4. Честно: от чего это НЕ спасает
Эту часть обычно стыдливо пропускают. Мы считаем, что без неё текст про безопасность это враньё, поэтому она тут.
Это не спасает от заражённого устройства. Если на телефон прилетел Pegasus или похожий имплант уровня ядра, он читает всё уже после расшифровки, прямо с экрана и из памяти. От этого не защищает ни один мессенджер, ни Signal, ни мы. End-to-end защищает данные от сети и сервера, но не от того, кто уже владеет вашим телефоном. Любой, кто обещает иммунитет к Pegasus, говорит неправду.
Forward secrecy у нас разъехалась по платформам, и это надо сказать прямо. На iOS установленные сессии идут по Double Ratchet, то есть полноценный forward secrecy уже есть. На Android сейчас более простая схема v=1 без forward secrecy: при утечке долговременного ключа прошлая переписка к нему раскрывается. Перенос Double Ratchet на Android это наша ближайшая криптографическая задача.
Независимого аудита пока нет. Примитивы стандартные и проверенные, но "мы написали аккуратно" это не то же самое, что "это проверили снаружи". Аудит в планах, ищем под него финансирование. До него мы не говорим "доказано безопасно", и вам не советуем верить тем, кто говорит.
Приватный мессенджер, который не проговаривает свои границы, опаснее честного: он создаёт ложное чувство защищённости.
Где это всё лежит
Острова и мультиличность уже работают, это та часть, которую мы довели. Forward secrecy на Android и сверка отпечатков ключей (чтобы закрыть подмену ключа на стороне сервера) в ближайших планах, аудит дальше.
Код клиентов открыт, ссылки под статьёй. Если вы из тех, кто перед тем как доверять смотрит в исходники, мы только за.
Ссылки (всё под AGPL-3.0):
iOS-клиент: https://github.com/rcq-messenger/rcq-ios
Android-клиент: https://github.com/rcq-messenger/rcq-android
Референс сервера: https://github.com/rcq-messenger/rcq-server-ref
Спецификация протокола: https://github.com/rcq-messenger/rcq-spec