Авторизация и шифрование

Прежде чем сообщение (или сообщение из нескольких частей) будет передано через сеть с использованием транспортного протокола, оно шифруется определённым образом, и вверху сообщения добавляется внешний заголовок, который представляет собой: 64-битный идентификатор ключа (который уникально идентифицирует ключ авторизации для сервера, а также для юзера) и 128-битный ключ сообщения. Ключ юзера вместе с клюсом сообщения определяет актуальный 256-битный ключ, который шифрует сообщение, используя AES-256 шифрование. Обратите внимание, что исходная часть сообщения, которая должна быть зашифрована, содержит непостоянные данные (сесия, ID сообщения, порядковый номер сообщения, соль сервера) которые очевидно влияют на ключ сообщения (и таким образом гп AES ключ и iv). Ключ сообщения определяется как 128 битами нижнего порядка от SHA1 тела сообщения (включающего ID сессии и сообщения и т.д.) Сообщения из неск. частей шифруются как одно сообщение.

Технически подробности см. здесь https://core.telegram.org/mtproto/description

Первое, что должен делать клиент приложения, это создать ключ авторизации (https://core.telegram.org/mtproto/auth_key) который обычно генерируется в момент первого запуска и обычно никогда не меняется.

[Примечание от переводчика: по некоторым сведениям, в последних обновлениях этот ключ меняется через каждые 100 отправленных сообщений - https://twitter.com/durov/status/539489480676085760]

Главным недостатком протокола является то, что нарушитель может присвоить ключ авторизации (например, украв девайс) и сможет расшифровать все принятые сообщения пост фактум. Возможно, это не такая уж большая проблема (украв девайс, нарушитель также получает доступ ко всей информации, кэшированной на девайсе даже не расшифровывая ничего); тем не менее, следующие шаги могут быть предприняты для преодоления этого недостатка:

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

- защитите ключ, сохранённый на девайсе с приложением с помощью (текстового) пароля; этот пароль не сохраняется в памяти и вводится юзером при входе в приложение или чаще (в зависимости от настроек приложения).

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