Техническое FAQ

Этот раздел FAQ рассчитан на продвинутых пользователей. Можете также почитать обычное FAQ.

Общие вопросы

Почему вы используете собственный протокол?

MTProto использует оригинальный метод для того, чтобы достичь надёжности в ныне уязвимой мобильной связи и скорости в доставке больших файлов (например, фотографий, видеороликов и документов размером до 1 ГБ). Этот документ предназначен для разъяснения деталей нашей системы и рассмотрения элементов, которые на первый взгляд трудно понять.

Где я могу почитать про протокол?

Детальная документация протокола доступна на этой странице. Если у вас есть вопросы — пишите в Твиттер.

mtproto_encryption_large.svg

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

Note 2: Смотрите дополнительные комментарии по поводу использования IGE, SHA-1 и модифицированной схемы encrypt-and-mac.

Почему вы не используете X [ваш вариант]

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

Почему вы опираетесь на классические криптоалгоритмы?

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

Я — эксперт в области безопасности, и я считаю, что ваш протокол небезопасен.

Вы можете принять участие в нашем конкурсе: Павел Дуров предлагает $200 000 в биткойнах тому, кто первый взломает MTProto. Можете ознакомиться с объявлением и Конкурсным FAQ. Если у вас есть другие замечания, будем рады услышать их на security@telegram.org.

Защита от известных атак

Атаки на основе открытых текстов (Known-Plaintext Attacks)

Согласно определению, атака на основе открытого текста — вид криптоаналитической атаки, при которой у атакующего есть обе версии текста: зашифрованная и исходная. Используемый в MTProto AES IGE устойчив к таким атакам. К тому же незашифрованный текст в MTProto всегда содержит соль сервера и идентификатор сессии.

Атака на основе адаптивно подобранного открытого текста

Согласно определению, атака на основе адаптивно подобранного открытого текста — вид атаки в криптоанализе, предполагающий, что криптоаналитик может выбирать открытый текст и получать соответствующий ему шифротекст. MTProto использует AES в режиме IGE, который безопасен против таких атак. Известно, что IGE неустойчив к blockwise-adaptive атакам, но MTProto исправляет это нижеописанным способом. Каждое сообщение с открытым текстом, которое предстоит зашифровать, содержит следующие данные, которые проверяются при расшифровке:

Вдобавок к этому, чтобы заменить открытый текст, также придётся использовать верные AES-ключ и вектор инициализации, зависящие от auth_key. Это делает MTProto устойчивым против атак на основе адаптивно подобранного открытого текста.

Атаки на основе подобранного шифротекста

Согласно определению, атака на основе подобранного шифротекста — это криптографическая атака, при которой криптоаналитик собирает информацию о шифре путём подбора зашифрованного текста и получения его расшифровки при неизвестном ключе. При такой атаке злоумышленник может ввести в систему один или несколько известных шифротекстов и получить открытые тексты. При помощи этих данных атакующий может попытаться восстановить ключ, используемый для расшифровки. В MTProto при каждой дешифровке сообщения производится проверка на соответствие msg_key к SHA-1 расшифрованных данных. Открытый текст (дешифрованные данные) также всегда содержит информацию о длине сообщения, его порядкового номера и соли сервера. Это сводит на нет атаки на основе подобранного шифротекста.

Атаки повторного воспроизведения

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

Атака «Человек посередине» (MitM)

Telegram имеет два режима общения: обычные чаты, использующие шифрование клиент-сервер, и секретные чаты, использующие оконечное шифрование и защищённые от атак посредника. Передача данных между клиентом и сервером защищена от подобных атак во время генерации ключей по протоколу Диффи —Хеллмана благодаря алгоритму с открытым ключом RSA, который встроен в клиенты Telegram. После этого, если клиенты собеседников доверяют программному обеспечению сервера, секретные чаты между ними защищаются сервером от атак посредника. Специально для тех, кто не доверяет серверу, в приложении доступно сравнение секретных кодов. Ключи визуализируются в виде изображений. Сравнивая визуализированные ключи, пользователи могут удостовериться, что атака «человек посередине» не была осуществлена.

Шифрование

Вы используете IGE? Он же взломан!

Да, мы используем IGE, но в нашей реализации с ним всё в порядке. Тот факт, что мы не используем IGE вместе с другими элементами нашей системы так же, как и MAC, делает попытки взлома IGE бессмысленными. IGE, ровно как и распространённый режим сцепления блоков шифротекста (CBC), подвержен blockwise-adaptive атакам. Но адаптивные атаки являются угрозой лишь тогда, когда один и тот же ключ используется в нескольких сообщениях (в MTProto это не так).

Адаптивные атаки даже теоретически невозможны в MTProto, потому что для расшифровки сообщений последние должны быть сперва полностью набраны, так как ключ сообщения зависит от его содержания. Что же касается неадаптивных CPA-атак, IGE защищён от них, как и CBC.

Вы используете схему Encrypt-then-MAC, MAC-then-Encrypt или Mac-and-Encrypt?

Наша схема близка к MAC-and-Encrypt, но имеет значительную модификацию: ключ шифрования и вектор инициализации зависят от хэша.

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

Почему вы используете SHA-1 вместо MAC?

С технической точки зрения в нашей реализации SHA-1 можно назвать особой разновидностью MAC (но не HMAC), так как он используется и в качестве ключа шифрования. Мы используем SHA-1, потому что он быстрее, особенно в случаях, когда нужно отправить большие фотографии или видеозаписи (Telegram поддерживает отправку файлов размером до 1 ГБ). Компромисс кажется оправданным, так как это означает, что по-прежнему требуется минимум 2^128 операций (вместо, скажем, 2^256 с SHA-2) только для того, чтобы начать попытки взлома схемы.

Аутентификация

Является ли проверка ключа между клиентами обязательной?

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

Поддерживается ли прямая секретность?

Прямая секретность доступна в секретных чатах, но в данный момент требует дополнительных действий от пользователя: придётся удалить секретный чат и создать новый или выйти из своей учётной записи (это удалит все секретные чаты). Прямая секретность поддерживается протоколом: примитивный p_q_inner_data_temp может использоваться для генерирования временных ключей с ограниченным TTL для достижения PFS. Мы работаем над нашими приложениями, чтобы добавить прямую секретность и в обычные чаты Telegram. В данный момент есть возможность создать клиент, поддерживающий прямую секретность, через наш API.