Китайская криптография. Анализ проприетарного протокола MMTLS из WeChat

Академическая исследовательская группа Citizen Lab из университета Торонто провела первый публичный анализ протокола шифрования MMTLS на предмет безопасности и конфиденциальности. Это основной протокол приложения WeChat, которым пользуется более 1,2 млрд человек (34% мобильного трафика в Китае в 2018 году).

Как выяснилось, MMTLS представляет собой модифицированную версию TLS 1.3, причём многие изменения, внесённые разработчиками, привели к появлению слабых мест.

Более того, в дополнение к MMTLS используется ешё менее безопасный, тоже проприетарный протокол, содержащий множество уязвимостей, в том числе детерминированные векторы инициализации в AES-GCM и отсутствие прямой секретности. Ниже он упоминается под названием Business-layer encryption.

Исследователи провели анализ мобильных приложений WeChat под Android версий 8.0.23 (APK “versionCode” 2160) от 26.05.2022 с сайта WeChat и 8.0.21 (APK “versionCode” 2103) от 07.04.2022 из Google Play Store. Спустя два года система шифрования в них не поменялась, а в ответ на получение данного отчёта компания-разработчик сообщила, что не считает уязвимости шифрования достаточно критичными, чтобы менять систему. В конце концов, исследователям так и не удалось показать работающий эксплоит, а все слабости являются лишь теоретическими.

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

Идентификация протокола MMTLS

Каждый пакет MMTLS содержит одну или несколько записей MMTLS (которые по структуре и назначению похожи на записи TLS. Это единицы сообщений, которые несут данные квитирования, данные приложения или данные сообщений о предупреждениях/ошибках в каждом пакете MMTLS.

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

Запись Handshake-Resumption19 f1 04 Запись Handshake16 f1 04 Запись Data17 f1 04 Запись Alert15 f1 04

Вот аннотированный пакет MMTLS от сервера с записью Handshake:

Пример записи Data, отправленной клиентом на сервер:

Шифрование MMTLS

Шифрование и дешифрование на Android осуществляются в отдельном процессе com.tencent.mm:push. Он в конечном итоге передаёт и получает данные по сети. Код для всего MMTLS-шифрования и сериализации взят из библиотеки libwechatnetwork.so. В частности, исследователи изучили центральную функцию Crypt(), название которой нашли в коде отладочного журнала. Они также проанализировали все вызовы HKDF_Extract() и HKDF_Expand(), функции OpenSSL для HKDF, чтобы понять, как извлекаются ключи.

Когда запускается процесс «:push», он запускает цикл событий HandshakeLoop(), который обрабатывает все исходящие и входящие записи MMTLS. Исследователи проверили все функции, которые вызываются этим циклом событий, чтобы понять, как обрабатывается каждая MMTLS-запись. Весь код, а также адреса внутренних функций можно найти в репозитории Github.

Общая схема обмена сетевыми запросами показана на диаграмме. Каждый прямоугольник представляет собой MMTLS-запись, а каждая стрелка — MMTLS-пакет, отправленный либо по каналу Longlink (т. е. одиночный пакет), либо Shortlink (т. е. в теле HTTP POST). После получения обеими сторонами ключа DH все дальнейшие записи шифруются.

Далее показана более старая схема шифрования Business-layer encryption, которая до сих пор используется в программе. Оно также тесно интегрировано с системой аутентификации пользователей WeChat. Пользователь должен войти в свою учётную запись, прежде чем клиент отправит запрос Autoauth. Для клиентов, которые не вошли в систему, используется исключительно асимметричный режим. Если они вошли в систему, первым пакетом Business-layer encryption чаще всего будет запрос Autoauth, зашифрованный с помощью асимметричного режима, однако второй и последующие пакеты бизнес-уровня шифруются с помощью симметричного режима:

На схеме 🔑secret генерируется с помощью DH (статический открытый ключ сервера, закрытый ключ клиента), также как 🔑new_secret (открытый ключ сервера, закрытый ключ клиента). При входе в систему 🔑session расшифровывается из первого ответа

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

Слабости проприетарного протокола MMTLS

Исследователи определили ряд проблем с безопасностью при использовании проприетарного шифрования MMTLS:

• Детерминированные векторы инициализации (IV)
• Отсутствие прямой секретности

У устаревшего Business-layer encryption проблем ещё больше:

• Утечка метаданных
• Возможность подделки подписи для шифротекста
• Возможность атаки оракула с заполнением (padding oracle) на AES-CBC
• Повторное использование ключей и векторов инициализации в режиме блочного шифра
• Проблемы с ключами шифрования
• Отсутствие прямой секретности

Почему не использовать TLS?

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

Согласно общедоступной документации (перевод), MMTLS («внешний уровень» шифрования) в значительной степени основан на TLS 1.3. Фактически, это исследование демонстрирует, что создатели MMTLS имеют приличное представление об асимметричной криптографии в целом.

Документация объясняет отказ от использования TLS тем, что WeChat требует что-то вроде возобновления сеанса 0-RTT, поскольку для передачи большинства данных WeChat используется только один цикл «запрос-ответ» (т. е. Shortlink). Согласно документу, в TLS 1.2 такой функциональности не было (на самом деле была). Китайские разработчики пишут, что функциональность появилась в TLS 1.3, но «TLS 1.3 пока находится в стадии черновика, и до его внедрения может быть ещё далеко».

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

Таково объяснение для разработки и внедрения проприетарного протокола.

История наглядно показывает, что отказ от общепризнанных проверенных методов криптографии (TLS) только ухудшает ситуацию. Несмотря на все усилия архитекторов MMTLS, протоколы безопасности WeChat, выглядят менее производительными и менее безопасными, чем TLS 1.3, считают авторы работы:

«Вообще говоря, разработка безопасного и производительного транспортного протокола — дело непростое. Проблема выполнения дополнительного раунда приёма-передачи (round-trip) для рукопожатия — извечная проблема для разработчиков приложений во всём мире. Рукопожатие TCP и TLS требует одного раунда, то есть каждый новый отправленный пакет занимает два раунда. Сегодня TLS-over-QUIC объединяет рукопожатия транспортного уровня и уровня шифрования, требуя только одного рукопожатия. Мы также отмечаем, что WeChat уже использует QUIC для загрузки некоторых больших файлов. Мы рекомендуем WeChat полностью перейти на стандартную реализацию TLS или QUIC+TLS.

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

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

Подтверждается мнение, что приложения в китайской экосистеме не используют передовые методы криптографии, предпочитая изобретать собственные, зачастую проблематичные схемы, считают исследователи. Таких примеров было множество (1, 2, 3, 4, 5, 6, 7, 8), и зачастую это приводило к серьёзным уязвимостям в криптосистемах (1, 2).

Технические инструменты и документация по методологии исследования опубликованы в репозитории Github. Как уже было упомянуто выше, эксперты настоятельно рекомендуют перейти на более надёжный и производительный протокол шифрования, такой как TLS или QUIC+TLS.