Внимательный читатель, перечитывая протокол Диффи — Хеллмана, может обратить внимание на строчку «Предполагается, что злоумышленник может получить оба этих значения (об открытых ключах), но не модифицировать их (то есть у него нет возможности вмешаться в процесс передачи)». Будучи паранойком, автор не мог просто проигнорировать это условие, потому что сервер Telegram (далее просто сервер) является активным участником взаимодействия. Запросы API идут к серверу, от него же пользователь получает ответ. Если гипотетически предположить, что сервер находится под контролем злоумышленника, протокол MTProto должен защищаться не просто от атаки MITM, а даже от подмены трафика.
Как такое возможно? Давайте разбираться.
Приведенные ниже рассуждения предполагают, что абсолютно все сообщения участников идут через сервер, что в реальности, возможно, не так, однако, как проверить это на 100% (то есть гарантировать алгоритмом) автор не знает, но будет рад услышать соображения на этот счет от более опытных товарищей.
Итак, представим себе Алису и Боба (A и B), которые решили пообщаться друг с другом через приватный чат. Наивные Алиса и Боб предполагают, что в коммуникации участвуют только они двое, в реальности же общаться будут четверо: специально для этой пары сервер сгенерит двух посредников As и Bs. A будет непосредственно общаться с Bs, B — c As. As и Bs, находясь рядом друг с другом на сервере, будут перекодировать трафик с одного ключа на другой.
Когда, Алиса решит инициировать общение, сервер выдаст Алисе и Бобу два числа p и g — открытое простое число и первообразный корень по модулю p. На данном этапе все честно. Алиса и Боб придумывают закрытые ключи a и b, соответственно, на основе которых вычисляют открытые:
A = g^a mod p
B = g^b mod p
и отправляют их серверу.
Будь сервер честным, он бы просто передал ключ A Бобу, а B — Алисе. Но коварный сервер поступит иначе — от лица посредников он придумает свои закрытые ключи (as и bs), по которым также вычислит открытые:
As = g^as mod p
Bs = g^bs mod p
и передаст Алисе Bs, As — Бобу.
Заметим, что ни Алиса, ни Боб не могут заподозрить неладное — все ключи сгенерены по правилам, понять действительного автора ключа невозможно. Поэтому Алиса и Боб просто следуют инструкции и вычисляют ключи для шифрования трафика:
s1=Bs^a mod p
s2=As^b mod p
Ровно ту же операцию проделывает и сервер, получая оба ключа. Ключи s1 и s2 — разные, но ни Алиса, ни Боб об этом никогда не узнают. Ведь отправленные Бобу сообщения от Алисы, будет получать сначала посредник Bs, который, зная s1 будет его декодировать, кодировать заново при помощи s2, и отправлять Бобу от лица As. То же происходит с сообщениями от Боба.
Если бы хотя бы одно из сообщений могло пройти мимо сервера, Алиса и Боб осознали бы подмену ключей, и остановили общение. Вот только как этого добиться? С точки зрения Алисы на другой стороне провода реально кто-то есть, физически он может располагаться на отдельной машине, и даже прямое соединение с собеседником (якобы в обход сервера) не гарантирует подлинность Боба.
PS. Автор, также не являясь экспертом в криптографии, приветствует конструктивную критику, указание о возможных ошибках в приведенной атаке, а также предложения по защите. Автор помимо этого не является экспертом в MTProto, поэтому мог пропустить возможную защиту в MTProto, специально для таких случаев. Комментарии разработчиков в этом случае приветствуются. Однако, даже если приведенный выше пример не опасен для MTProto, автор считает его полезным хотя бы в образовательных целях.
Автор: maximp
