Открыть сервис
Главная → Блог → X3DH

X3DH

X3DH (Extended Triple Diffie-Hellman) — это криптографический протокол установления общего секретного ключа (key agreement protocol), предназначенный для асинхронного обмена ключами между двумя сторонами. Протокол обеспечивает прямое секретное совершенство (forward secrecy) и устойчивость к компрометации долговременных ключей (future secrecy или post-compromise security) при условии, что одна из сторон может быть офлайн. X3DH является расширением классического протокола Диффи — Хеллмана и используется в качестве основного механизма установления ключей в мессенджере Signal, а также в протоколах Matrix и других системах, требующих сквозного шифрования (end-to-end encryption) в асинхронном режиме.

История

Протокол X3DH был разработан в 2016 году командой Open Whisper Systems (разработчик Signal) под руководством криптографа Тревора Перрина (Trevor Perrin) и Мокси Марлинспайка (Moxie Marlinspike). Предпосылкой к созданию стало стремление обеспечить сквозное шифрование в мессенджере Signal, где сообщения могут быть отправлены пользователю, который в данный момент не в сети. Классические протоколы Диффи — Хеллмана требуют, чтобы обе стороны одновременно генерировали эфемерные ключи, что невозможно в асинхронном сценарии.

X3DH был впервые реализован в Signal в 2016 году. Впоследствии протокол был адаптирован для использования в протоколе Matrix (версия 1.0, 2019 год) и в ряде других систем, включая WhatsApp (продукт Meta, признанной экстремистской и запрещённой в РФ) (на базе Signal Protocol) и некоторые реализации протокола OMEMO (XMPP). В 2020 году протокол был формализован в виде спецификации (RFC-like) на сайте Signal.

Принцип работы

X3DH основан на комбинации трёх обменов Диффи — Хеллмана (DH) между долговременными и эфемерными ключами сторон. В протоколе участвуют два типа ключей: долговременные (Identity Key, IK) и эфемерные (Ephemeral Key, EK), а также предварительные ключи (Prekey, PK), которые публикуются заранее.

Ключи и их роли

Процесс установления ключа

  1. Публикация ключей: Алиса (инициатор) и Боб (получатель) заранее публикуют на сервере свои долговременные ключи (IK_A, IK_B), подписанные предварительные ключи (SPK_A, SPK_B) и пул одноразовых ключей (OPK_B). Сервер хранит эти ключи и предоставляет их по запросу.
  1. Запрос ключей: Алиса, желая отправить сообщение Бобу, запрашивает с сервера его долговременный ключ (IK_B), подписанный предварительный ключ (SPK_B) и один одноразовый ключ (OPK_B). Сервер удаляет OPK_B из пула после выдачи.
  1. Вычисление общего ключа: Алиса генерирует свой эфемерный ключ (EK_A) и выполняет три обмена Диффи — Хеллмана:
  1. Формирование общего секрета: Все полученные значения DH объединяются (например, конкатенацией) и подаются на вход криптографической хеш-функции (обычно SHA-256) для получения общего секретного ключа (SK). Этот ключ используется для дальнейшего симметричного шифрования.
  1. Подтверждение: Алиса отправляет Бобу сообщение, содержащее свой долговременный ключ (IK_A), эфемерный ключ (EK_A) и идентификатор использованного предварительного ключа (SPK_B). Боб, получив сообщение, восстанавливает общий секрет, выполняя аналогичные вычисления (с использованием своих приватных ключей). Если вычисленные значения совпадают, общий ключ считается установленным.

Свойства

Прямое секретное совершенство (Forward Secrecy)

Протокол X3DH обеспечивает прямое секретное совершенство, то есть компрометация долговременных ключей (IK) не позволяет расшифровать ранее перехваченные сообщения. Это достигается за счёт использования эфемерных ключей (EK_A, SPK_B), которые генерируются для каждой сессии и не хранятся после её завершения. Даже если злоумышленник получит IK_A и IK_B, он не сможет восстановить EK_A или SPK_B, так как они не были сохранены.

Устойчивость к компрометации (Future Secrecy)

X3DH также обеспечивает свойство, называемое future secrecy (или post-compromise security): если долговременные ключи были скомпрометированы, но затем заменены, протокол позволяет восстановить безопасность будущих сессий. Это достигается за счёт того, что каждый новый сеанс использует свежие эфемерные ключи, не связанные с предыдущими.

Асинхронность

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

Применение

Signal Protocol

X3DH является основным протоколом установления ключей в Signal Protocol, который используется в мессенджерах Signal, WhatsApp, Facebook Messenger (в режиме «секретных чатов») и других. В Signal Protocol X3DH применяется для начального обмена ключами, после чего дальнейшее шифрование сообщений осуществляется с помощью протокола Double Ratchet, обеспечивающего непрерывное обновление ключей.

Matrix

В протоколе Matrix (версия 1.0) X3DH используется в качестве механизма установления ключей для сквозного шифрования. Matrix реализует X3DH с некоторыми модификациями, включая поддержку нескольких устройств и использование подписанных предварительных ключей. Протокол Matrix также поддерживает механизм «перекрёстной подписи» (cross-signing) для верификации ключей.

OMEMO

Протокол OMEMO (XMPP) использует X3DH в сочетании с Double Ratchet для обеспечения сквозного шифрования в децентрализованных системах. OMEMO был впервые реализован в мессенджере Conversations (Android) и затем адаптирован для других клиентов XMPP.

Критика и ограничения

Зависимость от сервера

X3DH требует доверия к серверу, который хранит и предоставляет публичные ключи. Если сервер скомпрометирован или злонамерен, он может подменить ключи (например, выдать фальшивый SPK_B), что приведёт к атаке «человек посередине» (MITM). Для защиты от этого используются механизмы верификации ключей (например, сравнение отпечатков ключей по внешнему каналу).

Сложность управления ключами

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

Уязвимость к атакам на предварительные ключи

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

Интересные факты

Источники

BFOmetr — база данных и аналитика по компаниям России.

На главную BFOmetr →

Похожие материалы