PIN-код и доверие Илону — всё, что защищает сообщения в XChat

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

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

Не менее тревожным является способ хранения ключей. Вместо того чтобы позволить пользователю хранить секретные ключи только на своём устройстве, как делают большинство безопасных мессенджеров, XChat сохраняет их на собственных серверах. Доступ к этим ключам осуществляется через ввод PIN-кода или пароля. Это решение объясняется необходимостью поддержки браузеров и других «безгосударственных» клиентов, но фактически создаёт ситуацию, при которой X получает возможность восстановить ключи — а значит, и расшифровать сообщения.

Для управления этими ключами используется протокол Juicebox — система распределённого шифрования, превращающая слабые пароли в стойкие ключи с помощью специальных серверов, называемых «realms». При регистрации пользовательский PIN-код (часто 6-значный) проходит через криптографическую процедуру, известную как пороговая псевдослучайная функция (t-OPRF), и преобразуется в стойкий ключ. Однако 6 цифр дают максимум 20 бит энтропии — этого недостаточно, чтобы остановить перебор, особенно если система реализована без аппаратных защит.

По замыслу авторов, Juicebox должен обеспечивать безопасность за счёт ограничения количества попыток ввода пароля. После 10 неверных попыток аккаунт блокируется или уничтожается. Но уже здесь начинаются проблемы. Если злоумышленник угадает девять PIN-кодов, а затем настоящий пользователь успешно войдёт в систему, счётчики обнуляются. Это даёт атакующему возможность начать цикл заново. В условиях частых автоматических входов, например из браузеров, такая атака становится вполне реалистичной.

Весь смысл Juicebox строится на распределённой архитектуре: пользовательский PIN-код должен проверяться на нескольких серверах, и только при достижении порогового количества положительных ответов (например, 2 из 3) выдаётся результат. Это нужно, чтобы система оставалась безопасной даже при компрометации одного или двух серверов. Но, как выяснилось, в случае X все Juicebox-серверы находятся под контролем самой компании.

Несмотря на наличие в открытом коде Juicebox поддержки аппаратных модулей безопасности (например, Entrust nShield Solo XC), анализ показывает, что X использует исключительно программную реализацию. Это подтверждает и специалистка по протоколу Juicebox Нора Трапп. По её словам, проект давно не развивается, а открытые серверы X (realm-a, realm-b, realm-east1, realm-west1) используют устаревший код, причём два из них явно реализованы в виде «софтварных» realm’ов, которые даже не используют криптографический протокол Noise. Остальные два используют код из Juicebox HSM, но с большой вероятностью тоже работают в режиме эмуляции.

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

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

Есть и ещё одна уязвимость , обнаруженная при анализе. При успешном входе клиент отправляет каждому серверу специальный тег (unlockKeyTag), подтверждающий, что пользователь ввёл правильный PIN. Каждый тег привязан к конкретному серверу через уникальный идентификатор realm ID. Однако если злоумышленник заставит клиента обращаться к поддельным серверам с теми же идентификаторами, он сможет перехватить корректные теги и использовать их для обнуления счётчиков на настоящих серверах. Это позволит атакующему бесконечно угадывать PIN-код, что полностью ломает защиту. Хотя на практике такую атаку сложно реализовать, сама возможность говорит о хрупкости архитектуры.

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

* Социальная сеть запрещена на территории Российской Федерации.