Русский
Русский
English
Статистика
Реклама

Y messenger

Recovery mode Архитектура Y messenger

18.06.2020 12:21:50 | Автор: admin


Y messenger разрабатывается чтобы быть одновременно и защищенным на уровне Tox, BitMessage, и удобным на уровне Telegram и WhatsApp. В этой статье я опишу как выглядит архитектура и какие решения были использованы чтобы достичь поставленных целей.


Какие преимущества современных мессенджеров мы собрали в нашем продукте:


  • Общение
    • Отправка текста, фото, файлов, голосовых сообщений;
    • Отправка сообщений, защищенных сквозным шифрованием (включая фото и файлы);
    • Реализация диалогов, многопользовательских чатов и каналов;
    • Получение push-уведомлений о новых сообщениях;
    • Высокая скорость отправки сообщений;
    • Возможность отображения онлайна пользователей и индикации набора текста;
    • Иерархия ролей пользователей в групповых чатах и каналах;
  • Регистрация и авторизация пользователей:
    • Возможность анонимной регистрации без номера телефона / эл.почты;
    • Возможность регистрации по номеру телефона / почте;
    • Возможность скрыть персональные данные или ограничить видимость определенным группам;
    • Возможность просматривать список сессий пользователя;
    • Отсутствие жесткой привязки пользователя к серверу и возможность переноса данных пользователя между серверами;
  • Работа с пользователями:
    • Поиск пользователей по доступным данным (имя, почта, телефон);
    • Поиск пользователей по идентификатору;
    • Хранение списка контактов и групп контактов;
  • Администрирование:
    • Возможность разворачивания собственного сервера;
    • Автообновление серверного приложения;
    • Автоматическое создание резервных копий;
    • Настройка под местные требования (законов и внутренних политик владельцев);
    • Возможность настройки доступности шифрования для пользователей сервера;
    • Возможность просмотра незашифрованных диалогов администратором сервера;
    • Хранение статических файлов в облаке.

Сетевая архитектура


Взаимодействие всех участников сети мы строим на базе протокола WebSocket. Файлы передаются по протоколу HTTP. Описание протокола доступно в нашем репозитории на GitHub.


Цели и задачи


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

Решение


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


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


Схема связи хабов и пользователей


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


Аналогичную сетевую архитектуру образуют почтовые сервера (E-mail).


Хабы


Задачи хабов:


  1. Авторизация, регистрация и верификация пользователей.
  2. Хранение данных о пользователе (профиль, сообщения, контакты, настройки).
  3. Обеспечение передачи данных между пользователями.
  4. Предоставление информации о пользователе в соответствии с его настройками конфиденциальности.
  5. Маршрутизация запросов от других хабов и пользователей.
  6. Хранение файлов (у себя или в S3-совместимом хранилище).
  7. Поддержание распределенного хранилища Blockchain.
  8. Резервное копирование данных.
  9. Проксирование запросов между пользователей других хабов при сбое хаба, к которому они принадлежат.
  10. Администрирование своих пользователей.

Хаб может быть запущен кем угодно, подобно серверу электронной почты. Команда разработчиков Y messenger не имеет доступа к хабам пользователей и не может читать / записывать / изменять / удалять данные в этих хабах.


Прочие элементы сети


Помимо хабов и пользователей, в сети Y messenger существуют общие микросервисы (shared microservice), к которым обращаются хабы:


  • Push shared microservice микросервис push-уведомлений. Обеспечивает отправку уведомлений на устройства пользователей по распоряжению хаба пользователя. Защищает пользователей от отправки спама через Push-уведомления.
  • Balancer shared microservice микросервис балансировки сети. Обеспечивает целостность сети и является одним из источников информации о действующих хабах. Обеспечивает верификацию хабов и защиту от подделки запросов хаба при взаимодействии хаб <-> хаб и хаб <-> пользователь.

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


Архитектура хранилища данных


Цели и задачи


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

Решение


Для достижения всех поставленных целей нам приходится использовать комбинацию разных хранилищ. На клиенте локальная СУБД. На хабах классическая РСУБД, распределенный блокчейн и кэш для быстрой отдачи горячих данных.


Для хранения блокчейна и данных мы используем PostgreSQL, а для кэша Redis. Эти продукты оптимальны с точки зрения безопасности, скорости работы и удобства администрирования, кроме того они являются свободным ПО.


Где что хранится


  • Данные пользователей. Хранятся на устройствах и на привязанном хабе. Хаб шифрует данные на своем ключе и отправляет в блокчейн. Другие хабы не получают доступа к информации о пользователе, они видят только привязку ID пользователя <-> ID хаба для маршрутизации.
  • Незащищенные личные сообщения. Хранятся на устройстве пользователя и в СУБД на хабах собеседников. В блокчейн не отправляются, т.к. блокчейн не приспособлен для обработки быстрых вставок, а ожидание синхронизации между хабами сделает доставку сообщений неприемлемо долгой. При общении между пользователями разных хабов сообщения хранятся на обоих хабах.
  • Приватные ключи пользователя. Хранятся только на устройствах клиентов. Могут передаваться между устройствами пользователя через хаб в зашифрованном виде (на ключах пользователя), поэтому передача через хаб безопасна.
  • Ключи оконечного шифрования. Хранятся на устройствах собеседников. Могут храниться в зашифрованном виде на хабе, но для расшифровки нужен приватный ключ пользователя.
  • Оконечно зашифрованные сообщения. Хранятся на устройствах пользователей. Опционально могут храниться в зашифрованном виде на хабе.
  • Информация о групповых чатах и каналах. Хранится на хабах всех участников. Отправляется в блокчейн хабом администратора в зашифрованном виде.
  • Сообщения групповых чатов и каналов. Хранятся на хабах всех участников. При подключении нового участника чата / канала, его хаб загружает последние сообщения и подгружает более старые по запросу пользователя. Поиск сообщений в групповом чате выполняет поиск только по локальной копии истории сообщений на хабе запросившего пользователя.
  • Список участников чата/канала. Хранится на хабах всех участников чатов. Отправляется в блокчейн хабом администратора в зашифрованном виде.
  • Контакты пользователя и группы контактов. Хранятся на устройстве. При необходимости могут храниться на хабе и синхронизироваться.

Шифрование


Компоненты шифрования реализованы на базе OpenSSL. В своей работе Y messenger использует следующие алгоритмы шифрования и подписи AES-CBC, RSA-OAEP, RSA-PSS. Эти алгоритмы реализованы в большом количестве криптопровайдеров, а следовательно, у желающих и/или не доверяющих есть больше шансов самостоятельно разобраться в функционировании системы или выпустить свой альтернативный клиент.


Ключи


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


  • ключи подписи (публичные и приватные);
  • ключи шифрования (публичные и приватные);
  • ключи симметричного шифрования.

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


В настоящее время Y messenger использует для асиметричной криптографии ключи, полученные из модуля длинной 8192 бита. Большинство продуктов в данный момент используют ключи на базе модуля 4096 бит, хотя известны случаи применения ключей на базе модуля 16384 бита и более. Мы решили, что 8192 бита будет достаточно. Дальнейшее увеличение длины критическое увеличение времени работы алгоритмов, что негативно сказывается на пользовательском опыте.


Хранение ключей


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


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


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


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


Сквозное шифрование


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


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


Как происходит обмен симметричными ключами:


  1. Alice хочет отправить Bob'у зашифрованное сообщение.
  2. Alice получает со своего хаба публичный ключ асимметричного шифрования Bob'а.
  3. Alice генерирует симметричный ключ.
  4. Alice шифрует симметричный ключ на публичном ключе Bob'а и подписывает своим приватным ключом подписи.
  5. Alice отправляет Bob'у сообщение, в которое вкладывает зашифрованный симметричный ключ.
  6. Следом Alice уже может отправлять оконечно зашифрованные сообщения, шифруя их на сгенерированном симметричном ключе.
  7. Bob получает сообщение с вложенным зашифрованным симметричным ключом.
  8. Bob проверяет подпись с помощью публичного ключа подписи Alice.
  9. Bob расшифровывает вложение на своем приватном ключе.
  10. Bob получает симметричный ключ и может с его помощью расшифровывать сообщения, полученные от Alice.

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


Обмен ключами между устройствами


Современный мессенджер должен быть cross-device, чтобы пользователь мог начать переписку на одном устройстве и продолжить ее на другом. При использовании хабов, сделать cross-device нешифрованную переписку не составляет никакого труда. Реализовать cross-device зашифрованную переписку становится сложнее из-за того, что контент зашифрован, а ключи шифрования находятся на другом устройстве. Существует несколько способов решения (список не конечный, но достаточный):


  1. Использовать один симметричный ключ на всех устройствах.
  2. Расшифровывать сообщения на одном устройстве и передавать их через хаб в незащищенном виде.
  3. Перекинуть ключи шифрования между устройствами через хаб.
  4. Перекинуть ключи шифрования между устройствами напрямую.

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


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


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


  1. Пользователь начал переписку на устройстве A.
  2. Пользователь решил перейти на устройство B (с ПК на телефон).
  3. Устройство B авторизировано и имеет свой набор ключей асимметричного шифрования и подписи, которые уже отправлены на хаб.
  4. Устройство B отправляет на хаб сообщение с командой передать ключи, передает один из своих публичных ключей асимметричного шифрования, идентификатор ключа подписи, подписывая всю команду своим приватным ключом подписи.
  5. Хаб определяет все подключенные устройства пользователя и отправляет им команду подготовить ключи для передачи на устройство B и передает им данные из предыдущего этапа.
  6. Устройство A получает команду от хаба и проверяет что запрос был создан с устройства пользователя путем проверки подписи (запрашивает с хаба публичный ключ по переданному идентификатору).
  7. Устройство A генерирует одноразовый симметричный ключ, шифрует его на полученном публичном асимметричном ключе.
  8. Устройство A шифрует набор ключей на созданном симметричном ключе и подписывает данные (зашифрованный симметричный ключ, зашифрованный набор ключей устройства, идентификатор ключа подписи) своим приватным ключом подписи и отправляет на хаб.
  9. Хаб отправляет эту информацию на устройство B.
  10. Устройство B проверяет подпись и расшифровывает одноразовый симметричный ключ на своем приватном ключе шифрования.
  11. Устройство B расшифровывает набор ключей с помощью симметричного.

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


Остается вероятность что при "взломе" аккаунта и успешной авторизации, злоумышленник может быстро получить доступ к зашифрованной переписке. Решается либо ручным подтверждением пересылки ключей устройством А, либо временным недоверием устройству B (устройство А не доверяет устройству B пока пользователь не авторизует сессию на устройстве А).


Исходный код


Мы опубликовали исходный код наших разработок:


Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru