Протоколы

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

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

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

Коммуникации под своим управлением.

Matrix занимает особое место в нашей работе над системами связи.

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

Мы изучаем Matrix в контексте разных устройств и условий эксплуатации: от повседневной переписки до специализированных рабочих сред.

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

Содержимое доступно участникам обмена.

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

Такая защита требует внимания к каждому устройству, участвующему в обмене. Как подтвердить собеседника? Что происходит при подключении нового телефона? Как защищена резервная копия? Что делать при потере устройства?

Мы рассматриваем E2EE вместе с проверкой подлинности, управлением ключами и безопасностью конечных устройств. Отдельно учитываем метаданные: кто, когда и с кем взаимодействует. Защита содержимого сама по себе не скрывает все сведения об обмене.

Криптографическая основа E2EE в Matrix.

Olm используется для защищённых парных сессий между устройствами. Megolm обеспечивает шифрование группового обмена.

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

Мы изучаем эти механизмы вместе с реализациями, практиками интеграции и результатами независимого анализа. Безопасность системы зависит от того, как криптография встроена в приложение и как ею управляют в эксплуатации.

Защита, которая обновляется вместе с перепиской.

Семейство протоколов Signal представляет важное направление развития защищённых коммуникаций.

PQXDH используется для установления общего секрета и добавляет постквантовую защиту конфиденциальности на этом этапе.

Double Ratchet обновляет ключи в процессе обмена сообщениями. Это ограничивает последствия раскрытия отдельных ключей и при определённых условиях позволяет восстановить защищённость дальнейшего обмена после компрометации.

Triple Ratchet объединяет Double Ratchet с постквантовым механизмом SPQR. Такой подход развивает защиту переписки с учётом возможностей будущих квантовых компьютеров.

Мы изучаем эти решения с точки зрения их свойств, требований к устройствам и применимости в собственных архитектурах.

Сквозная защита для группового взаимодействия.

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

Messaging Layer Security, MLS, стандартизованный в RFC 9420, определяет механизм согласования ключей для защищённого группового обмена.

Он предусматривает обновление ключей при изменении группы и рассчитан на асинхронную работу участников. Среди его целей - защита прошлых сообщений и восстановление защищённости будущего обмена после компрометации при выполнении условий протокола.

Для RUS OS это направление исследований групповых коммуникаций между людьми, сервисами и устройствами.

Защищённые соединения.

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

TLS 1.3 обеспечивает шифрование транспортного канала, контроль целостности и аутентификацию сторон в соответствии с выбранной конфигурацией.

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

Транспортная защита и E2EE решают разные задачи. TLS защищает соединение между его конечными точками. Сквозное шифрование сохраняет защиту содержимого между участниками обмена через промежуточную инфраструктуру.

Защищённое взаимодействие устройств и сетей.

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

WireGuard использует схему из семейства Noise для создания защищённых сетевых туннелей.

Мы рассматриваем эти технологии в задачах соединения устройств, удалённого доступа и взаимодействия между сетевыми контурами.

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

Защита с учётом долгого срока жизни данных.

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

Мы изучаем постквантовые стандарты и способы перехода к ним:

• ML-KEM, FIPS 203 - механизм установления общего секрета.
• ML-DSA, FIPS 204 - алгоритм цифровой подписи.
• SLH-DSA, FIPS 205 - алгоритм цифровой подписи на основе хеш-функций.

Отдельное направление - гибридные схемы, объединяющие классические и постквантовые механизмы.

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

Доверие должно иметь жизненный цикл.

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

Мы рассматриваем управление ключами и идентичностью как самостоятельную часть архитектуры:

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

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

Связь может прерываться. Правила должны оставаться понятными.

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

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

Особое значение это имеет для интеллектуальных систем. Получить данные, предложить действие и выполнить его - разные полномочия. Их необходимо разделять и проверять в момент обращения.

Выбор протокола задаёт основу. Дальше идут реализация, интеграция, испытания и сопровождение.

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

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

Чтобы человек знал, кому доверяет система, что она защищает и как сохраняет контроль.