- Регистрация
- 17 Февраль 2007
- Сообщения
- 678
- Реакции
- 1.026
- Баллы
- 93
Сквозное шифрование, или end-to-end encryption (E2EE), считается панацеей от настойчивых попыток хакеров и силовых ведомств ознакомиться с онлайновой перепиской. Смысл E2EE часто сводится к тому, что ключи хранятся только на устройствах собеседников и не попадают на сервер… но это не совсем так. Давай посмотрим, как в действительности обстоят дела с E2EE, на примере популярных мессенджеров.
Шифрование в мессенджерах
Написать эту статью меня подтолкнуло исследование Obstacles to the Adoption of Secure Communication Tools (PDF). Как выяснили его авторы, «подавляющее большинство участников опроса не понимают основную концепцию сквозного шифрования». Проще говоря, люди обычно выбирают мессенджер сердцем, а не мозгом.
Начнем с того, что E2EE имеет свои особенности в каждом мессенджере. В Signal оно почти образцовое. В WhatsApp формально такое же, как в Signal, за исключением одного очень важного момента: смена основного ключа абонента WhatsApp не блокирует отправку ему сообщений. Максимум можно включить бесполезное уведомление (которое отключено в дефолтных настройках). В Viber сквозное шифрование неактивно по умолчанию, да и появилось только в шестой версии. В Telegram E2EE также используется только в секретных чатах, причем реализованы они довольно странно.
Конфликт Роскомнадзора с Telegram вообще создал отличную рекламу последнему. Рядовые пользователи теперь считают творение Дурова настоящей занозой в спине спецслужб (или чуть пониже нее), которые ничего не могут сделать с пуленепробиваемым инновационным сервисом. Поклонники Telegram сравнивают его с Signal и утверждают о превосходстве первого.
Однако в криптографии не бывает чудес, и особенно — в прикладной. Многие математически красивые идеи оказываются безнадежно испорчены реализацией, когда удобство и подконтрольность ставят выше безопасности и приватности (а так происходит практически всегда).
Исходно в мессенджерах применялся протокол OTR (Off-the-Record). Он использует симметричное шифрование AES в режиме CTR, протокол обмена ключами DH и хеш-функцию SHA-1. Схема AES-CTR обеспечивает так называемое «спорное» (в хорошем смысле) шифрование и возможность отрицания авторства текста, если его перехватят. Всегда можно сослаться на то, что перехвативший трафик сам изменил шифротекст так, чтобы он соответствовал другому варианту расшифровки той же длины. Например, вместо «сходи за хлебом» получилось «отрави королеву» — технически это возможно, и такое свойство специально заложено в алгоритм.
Протокол OTR выполняет аутентификацию собеседников и шифрует переписку между ними. Он безопасен до тех пор, пока участники разговора регулярно проверяют отпечатки открытых ключей друг друга и противостоят атакам по другим векторам (включая социальный инжиниринг).
Главный недостаток OTR заключается в том, что после отправки нового ключа требуется дождаться подтверждения от собеседника. Если он офлайн, то связь будет временно невозможна. Одним из выходов стал алгоритм Double Ratchet (DR), разработанный пять лет назад Тревором Перрином и Мокси Марлинспайком в Open Whisper Systems. Сегодня DR используется в Signal, WhatsApp, Viber и многих других мессенджерах, поддерживающих сквозное шифрование по умолчанию или как отдельную опцию (секретные чаты).
Упрощенная схема алгоритма Double Ratchet (источник: signal.org). Алиса и Боб начинают сессию, обмениваясь публичными ключами
Сквозное шифрование
Схема E2EE использует комбинацию из криптографических систем с открытым и закрытым ключом. Она очевидна в общих чертах и довольно сложна на уровне деталей. В ней используется масса взаимосвязанных ключей, часть из которых обязательно попадает на сервер и, более того, обязательно загружается на него до начала переписки, чтобы ее можно было начать в произвольный момент. Давай рассмотрим ее подробнее.
Начало схемы ты наверняка знаешь, поскольку оно стандартно для всех систем асимметричного шифрования, — генерируется пара ключей. Это необходимо потому, что криптосистемы с одним ключом (вроде AES) использовать в переписке в чистом виде слишком трудно. С ними пришлось бы как-то организовывать защищенный канал для передачи ключа (например, встречаться лично), а потом делать это снова при каждой его смене.
Тут же все как в привычном PGP: есть два собеседника (Алиса и Боб), каждый из которых генерирует свою пару ключей. Затем они обмениваются публичными ключами, сохраняя в тайне парные им секретные. Публичные ключи передаются по открытому каналу (на то они и публичные, пусть перехватывают на здоровье) и служат для двух целей: они позволяют зашифровать сообщение и проверить его подпись. Соответственно, секретные ключи используются для расшифровки и формирования подписи.
Термин «сообщение» используется здесь в широком смысле. Сообщением может быть текст, медиафайл или служебные метаданные, которыми мессенджер обменивается с сервером. Часть этих данных содержит временные метки, состояние клиентского приложения и новые ключи.
Такая криптосистема кое-как работает в электронной почте, поскольку это сервис для доставки отдельных зашифрованных сообщений произвольной длины. Пользуясь им, собеседники не обязаны одновременно быть онлайн. Все сообщения накапливаются на сервере и скачиваются с него по требованию после того, как пользователь успешно пройдет авторизацию. Расшифровка происходит локально при помощи секретных ключей, которые никуда не передаются. Почта с PGP популярна, но работает далеко не идеально. Почему? См. статью «Алиса и Боб в стране PGP».
К сожалению, в чистом виде схема асимметричного шифрования также не годится для мессенджеров, поскольку эти сервисы ориентированы на интенсивную онлайновую переписку в виде цепочки коротких сообщений. Они должны отображаться в строго определенном порядке, а собеседник может в любое время оказаться офлайн и нарушить структуру диалога.
К тому же шифровать множество коротких сообщений одним ключом — плохая идея. Всего за день переписки их создаются сотни (если не тысячи). Во многих сообщениях количество шифротекста минимальное и предсказуемое (смайлик, стикер). Также у них есть стандартные заголовки, которые упрощают криптоанализ.
Особенность переписки в мессенджерах в том, что из-за типовых метаданных за короткое время атакующий может перехватить большой объем предсказуемого шифротекста. Его львиная доля будет соответствовать известному открытому тексту. Если она будет шифроваться одним ключом, то при успешной атаке окажутся скомпрометированными все ранее написанные сообщения, и даже те, которые собеседники напишут в будущем.
Чтобы этого не происходило, в мессенджерах предусмотрены такие свойства, как прямая и обратная секретность. Они подразумевают невозможность прочитать отправленные ранее и написанные в будущем сообщения, имея на руках только текущий ключ шифрования. Для этого используется многослойное шифрование с переходом от асимметричной к симметричной криптографии и дополнительные ключи с разным временем жизни.
Диффи, Хеллман! Дайте три!
Из открытой документации известно, что в Telegram аутентифицированное распределение ключей обеспечивает классический протокол Диффи — Хеллмана (DH). Он создает мост между асимметричным (RSA) и симметричным (AES) шифрованием, давая возможность энному количеству собеседников вести зашифрованную переписку, передав только публичные ключи по открытому каналу. Для этого в нем генерируются сессионные ключи, представляющие собой общий секрет или общий эфемерный ключ. Он вычисляется на основе секретного ключа одного собеседника и публичного ключа другого. Эфемерные ключи аутентифицируются долговременными открытыми ключами.
В DH канал передачи может быть не защищен от прослушивания (пассивного наблюдения), но обязан иметь защиту от атаки подмены. Если атакующая сторона может подменить трафик (выполнить активную атаку MITM), то вся схема летит к черту.
Поэтому для своего мессенджера Signal компания Open Whisper Systems использует метод тройного преобразования Диффи — Хеллмана X3DH c Curve25519 (эллиптическая кривая Бернстайна для быстрого DH) или X448. В качестве других криптографических примитивов в X3DH используется HMAC-SHA-256 и AES-256.
Протокол Extended Triple Diffie — Hellman устанавливает общий секретный ключ между двумя сторонами, которые взаимно аутентифицируют друг друга на основе открытых ключей. Дополнительно ключи сверяются сразу после установки сессии и перед началом передачи сообщений. Это сводит к минимуму риск MITM-атак, делая их очень сложными.
В X3DH используются четыре типа ключей, три из которых постоянно меняются:
Смена вспомогательных ключей в X3DH происходит по алгоритму Double Ratchet. Он пришел на смену OTR и ввел понятие цепочки, или пула, ключей. На случай, если собеседник будет офлайн, предусмотрено создание пула OPK. Несколько разовых эфемерных ключей заранее загружаются на сервер и расходуются по мере общения. Это позволяет серверу принимать зашифрованные сообщения, аутентифицируя их отправителя по новой паре ключей, даже когда получатель не в сети. Если пул OPK исчерпан, то сервер использует запасной EK.
Название «двойной храповик» — отсылка к устройству шифровальной машины Enigma с зубчатыми колесиками, которые исключали обратное движение и повторное использование прежних значений. Цифровая аналогия в том, что DR используется для генерирования новых эфемерных ключей, которыми шифруется следующее сообщение (или небольшая порция сообщений). При этом эфемерные ключи гарантированно отличаются, не повторяют предыдущие и не могут быть предсказаны за разумное время атаки.
На X3DH основан протокол TextSecure, который позже был переименован в Signal. В чистом или слегка модифицированном виде протокол Signal используется в одноименном мессенджере, а также в WhatsApp, Viber и других. Разработчики могут давать протоколам собственные названия, но по сути это все тот же X3DH с варьирующимся набором хеш-функций, ГПСЧ и иных криптографических примитивов.
Проблема групповых чатов
Организация групповых чатов в мессенджерах подробно разобрана в свежей статье «More is Less: On the End-to-End Security of Group Chats in Signal, WhatsApp, and Threema» (PDF). Приведу основные выводы из нее.
Наш систематический анализ выявил, что целостность коммуникаций (представленная целостностью всех сообщений) и групповая принадлежность (определяемая возможностью членов группы управлять ими) не имеют end-to-end-защиты. Кроме того, мы показали, что обратная секретность (ключевое свойство безопасности) не сохраняется при использовании протокола Signal для групповых чатов.
Пояснение: краеугольный камень сквозного шифрования — аутентифицированное распределение ключей по классическому или усиленному протоколу DH. Оно работает только для двух собеседников, формирующих общий секрет. Ожидаемо, что в мессенджерах DH не используется в групповых чатах, а структура обмена сообщениями в них лишена основных криптографических свойств.
Шифрование в групповых чатах. A — отправитель, B — получатель, G — группа пользователей
Авторы показывают, какие манипуляции может выполнять контролируемый злоумышленником сервер в групповых чатах из-за отсутствия в них E2EE. Свои исследования они проводили на примере Signal и WhatsApp, но вряд ли стоит ожидать, что у других мессенджеров эта проблема имеет какое-то изящное решение.
Странности Telegram
С Telegram все покрыто завесой тайны. О протоколе MTProto 2.0 есть только частичные сведения. Его внешний аудит не выполнялся, а опенсорсная модель Telegram используется в сильно искаженном виде и исключительно с маркетинговыми целями. Ниже я поясню, почему так считаю.
Судя по официальному описанию, все недоставленные сообщения временно (мы надеемся) хранятся на серверах Telegram, которые часто разбросаны по миру и объединены в виртуальное облако. Они синхронизируются между собой, чтобы упорядочить и доставить сообщения одному или нескольким (в случае группового чата) собеседникам в определенном порядке, как только они появятся в сети. Поэтому шифрование делится на два этапа: на участках клиент — сервер и сервер — сервер. Это обычная схема, но в ней странно то, что прямое соединение клиентов не используется вообще никогда.
В Telegram трафик передается через серверы даже при открытии секретного чата, для которого логичнее было бы сделать P2P-соединение. Напрашивается вывод, что без постоянного использования серверов Telegram связь в этом мессенджере вообще не работает. Другие мессенджеры могут использовать свои серверы только на начальном этапе — для сопоставления текущих IP-адресов собеседников и организации между ними прямого соединения. Telegram так не умеет, и это чертовски похоже на MITM by design.
Почему-то все рассуждения о стойкости MTProto 2.0 крутятся вокруг того, что алгоритм DH надежно защищает от перехвата. Это не так. Алгоритм Диффи — Хеллмана как раз уязвим для атаки MITM. Более того, в случае Telegram он, вероятно, дополнительно ослаблен на уровне ГПСЧ.
Проблема в том, что клиентское приложение Telegram руководствуется очень невнятной оценкой энтропии. Вместо того чтобы локально генерировать псевдослучайные числа и отсеивать качественные простые, клиент запрашивает их с сервера. Что за ГПСЧ используется на сервере, насколько удачные простые числа он генерирует и нет ли на сервере механизмов избирательной отправки простых чисел с определенными свойствами отдельным клиентам — вопросы без ответа. Клиентское приложение лишь выполняет проверку присланного случайного числа, причем упрощенную, поскольку на тщательный тест prime numbers за разумное время у смартфона банально не хватит вычислительных ресурсов.
Другой частый аргумент в пользу безопасности Telegram — открытые исходники. Однако в них нет исходного кода серверной части, а код клиентской обычно неактуален. Репозитории Telegram обновляются с большой задержкой (разве что урезанная веб-версия более-менее живая), и в них всегда лежат только старые версии. Нет даже возможности проверить, действительно ли из исходников компилируется то, что сейчас раздается как готовый дистрибутив.
Поэтому говорить про аудит мессенджера фактически бессмысленно. Пока специалисты несколько месяцев копаются в старом коде, выйдет десяток новых версий Telegram, где будут переписаны огромные куски кода. Чтобы сделать уязвимой всю систему шифрования, достаточно замены одного байта — например, одного условного перехода.
Хакатоны, которые устраивает Дуров, не заменят аудит, поскольку ничего не доказывают. В их заданиях создается искусственная ситуация, в которой у атакующей стороны есть только одно зашифрованное сообщение. В реальной жизни таких ограничений нет и для атаки на мессенджер есть множество других векторов.
Тысяча и одна уязвимость
Signal — один из немногих мессенджеров, чей протокол проходил внешний аудит (PDF). Отчет о его результатах очень объемный, поэтому процитирую главные выводы в своем переводе.
Наш анализ показывает, что [протокол] Signal удовлетворяет стандартным криптографическим предположениям и свойствам безопасности. Мы не обнаружили серьезных недостатков в его дизайне, что очень обнадеживает. При реальном использовании Signal остаются неопределенности. Поэтому невозможно сказать, всегда ли [приложение] Signal достигает заявленных целей.
Нужно осознавать, что анализ протокола передачи сообщений — важный этап аудита, но далеко не единственная составляющая безопасности. Любой мессенджер работает в реальной и очень уязвимой среде. Обычно он запускается на не самой свежей версии Android, параллельно с сотней левых приложений (часть из которых наверняка злоупотребляют разрешениями или даже содержат троянские закладки), а сам аккаунт привязан к номеру мобильного телефона.
Огромная брешь заключается в том, что коды подтверждения приходят в SMS. Их можно перехватить через известную уязвимость в протоколе сотовой связи SS7. Так атакующий получит доступ ко всей переписке, не зная ключей шифрования и даже не пытаясь взломать Signal/Proteus/MTProto/другойсекьюрныйпротокол. Сервер мессенджера сам сменит ключ и услужливо дешифрует последнюю переписку (как минимум, недоставленные сообщения). Даже твои стикерпаки восстановит. Главное же — удобство, верно?
Еще одна зияющая дыра в модели безопасности — push-уведомления. Без них ты не узнаешь, что тебе пришло сообщение, пока вручную не запустишь мессенджер. С ними ты превращаешь сервер push-уведомлений в легализованного «человека посередине». Например, чтобы в iMessage работали уведомления, он отправляет ключи шифрования на серверы Apple. Уже они выполняют аутентификацию пользователей и (как минимум) дешифровку заголовков сообщений. Восстанови учетку Apple на другом устройстве, и ты получишь все как было — вплоть до переписки и паролей от Wi-Fi. Почти такая же ситуация с серверами Google и Microsoft. Или ты еще веришь в сквозное шифрование с привязкой к номеру мобильного и основному аккаунту на смартфоне?
Проблема небезопасного управления ключами и большой поверхности атаки касается вообще всех мессенджеров. WhatsApp, Viber и многие другие позволяют создавать копии переписки (в том числе облачные) и не шифруют метаданные (а иногда сам факт разговора важнее его содержания). У Signal дела обстоят чуть лучше, но и его я не считаю идеальным мессенджером по целому ряду причин:
Как видишь, сторонним и тем более проприетарным мессенджерам доверять сложно, даже если их рекомендовали Сноуден, Ассанж и EFF. Поэтому некоторые организуют общение через свой мессенджер — с опенсорсом и плагинами. Для простой переписки годится плагин OTR, но он не поддерживает групповые чаты. Есть родственные протоколы mpOTR и GOTR, в которых добавлена эта функция.
Так или иначе, для коллективного общения удобнее использовать открытый протокол XMPP (Extensible Messaging and Presence Protocol), который ранее назывался Jabber. XMPP переводится как «расширяемый протокол обмена сообщениями и информацией о присутствии», это очень емкое название. Открытость означает полную доступность исходных кодов. Ты можешь поднять свой сервер XMPP, ни от кого не зависеть и ничего за это не платить. Также есть уйма готовых серверов и клиентов на любой вкус — например, десктопный Pidgin и Xabber для Android.
Расширяемость подразумевает возможность передачи не только текста, но и данных другого типа, а также добавление разных функций и схем шифрования. Например, по XMPP легко передать голосовые сообщения, видео и файлы, при желании зашифровав их средствами TLS или PGP. Не так давно на базе XMPP был создан протокол расширения OMEMO, в котором используется тот же DR от Open Whisper Systems, что и в Signal и WhatsApp, но без прочих недостатков последних.
Выводы
В современных мессенджерах заявлена поддержка сквозного шифрования, но часто оказывается, что она реализована со странностями. К тому же в их коде много других дыр, которые были оставлены случайно либо намеренно. Последнее куда вероятнее, если учесть, сколько денег и труда профессионалов было вложено в их разработку. Я стараюсь соблюдать баланс между комфортом и привычным наслаждением паранойей. Использую разные мессенджеры (какие удобнее моим собеседникам), но никогда не веду через них действительно приватных бесед. Для этого есть множество опенсорсных альтернатив.
Источник
Шифрование в мессенджерах
Написать эту статью меня подтолкнуло исследование Obstacles to the Adoption of Secure Communication Tools (PDF). Как выяснили его авторы, «подавляющее большинство участников опроса не понимают основную концепцию сквозного шифрования». Проще говоря, люди обычно выбирают мессенджер сердцем, а не мозгом.
Начнем с того, что E2EE имеет свои особенности в каждом мессенджере. В Signal оно почти образцовое. В WhatsApp формально такое же, как в Signal, за исключением одного очень важного момента: смена основного ключа абонента WhatsApp не блокирует отправку ему сообщений. Максимум можно включить бесполезное уведомление (которое отключено в дефолтных настройках). В Viber сквозное шифрование неактивно по умолчанию, да и появилось только в шестой версии. В Telegram E2EE также используется только в секретных чатах, причем реализованы они довольно странно.
Конфликт Роскомнадзора с Telegram вообще создал отличную рекламу последнему. Рядовые пользователи теперь считают творение Дурова настоящей занозой в спине спецслужб (или чуть пониже нее), которые ничего не могут сделать с пуленепробиваемым инновационным сервисом. Поклонники Telegram сравнивают его с Signal и утверждают о превосходстве первого.
Однако в криптографии не бывает чудес, и особенно — в прикладной. Многие математически красивые идеи оказываются безнадежно испорчены реализацией, когда удобство и подконтрольность ставят выше безопасности и приватности (а так происходит практически всегда).
Исходно в мессенджерах применялся протокол OTR (Off-the-Record). Он использует симметричное шифрование AES в режиме CTR, протокол обмена ключами DH и хеш-функцию SHA-1. Схема AES-CTR обеспечивает так называемое «спорное» (в хорошем смысле) шифрование и возможность отрицания авторства текста, если его перехватят. Всегда можно сослаться на то, что перехвативший трафик сам изменил шифротекст так, чтобы он соответствовал другому варианту расшифровки той же длины. Например, вместо «сходи за хлебом» получилось «отрави королеву» — технически это возможно, и такое свойство специально заложено в алгоритм.
Протокол OTR выполняет аутентификацию собеседников и шифрует переписку между ними. Он безопасен до тех пор, пока участники разговора регулярно проверяют отпечатки открытых ключей друг друга и противостоят атакам по другим векторам (включая социальный инжиниринг).
Главный недостаток OTR заключается в том, что после отправки нового ключа требуется дождаться подтверждения от собеседника. Если он офлайн, то связь будет временно невозможна. Одним из выходов стал алгоритм Double Ratchet (DR), разработанный пять лет назад Тревором Перрином и Мокси Марлинспайком в Open Whisper Systems. Сегодня DR используется в Signal, WhatsApp, Viber и многих других мессенджерах, поддерживающих сквозное шифрование по умолчанию или как отдельную опцию (секретные чаты).
Упрощенная схема алгоритма Double Ratchet (источник: signal.org). Алиса и Боб начинают сессию, обмениваясь публичными ключами
Сквозное шифрование
Схема E2EE использует комбинацию из криптографических систем с открытым и закрытым ключом. Она очевидна в общих чертах и довольно сложна на уровне деталей. В ней используется масса взаимосвязанных ключей, часть из которых обязательно попадает на сервер и, более того, обязательно загружается на него до начала переписки, чтобы ее можно было начать в произвольный момент. Давай рассмотрим ее подробнее.
Начало схемы ты наверняка знаешь, поскольку оно стандартно для всех систем асимметричного шифрования, — генерируется пара ключей. Это необходимо потому, что криптосистемы с одним ключом (вроде AES) использовать в переписке в чистом виде слишком трудно. С ними пришлось бы как-то организовывать защищенный канал для передачи ключа (например, встречаться лично), а потом делать это снова при каждой его смене.
Тут же все как в привычном PGP: есть два собеседника (Алиса и Боб), каждый из которых генерирует свою пару ключей. Затем они обмениваются публичными ключами, сохраняя в тайне парные им секретные. Публичные ключи передаются по открытому каналу (на то они и публичные, пусть перехватывают на здоровье) и служат для двух целей: они позволяют зашифровать сообщение и проверить его подпись. Соответственно, секретные ключи используются для расшифровки и формирования подписи.
Термин «сообщение» используется здесь в широком смысле. Сообщением может быть текст, медиафайл или служебные метаданные, которыми мессенджер обменивается с сервером. Часть этих данных содержит временные метки, состояние клиентского приложения и новые ключи.
Такая криптосистема кое-как работает в электронной почте, поскольку это сервис для доставки отдельных зашифрованных сообщений произвольной длины. Пользуясь им, собеседники не обязаны одновременно быть онлайн. Все сообщения накапливаются на сервере и скачиваются с него по требованию после того, как пользователь успешно пройдет авторизацию. Расшифровка происходит локально при помощи секретных ключей, которые никуда не передаются. Почта с PGP популярна, но работает далеко не идеально. Почему? См. статью «Алиса и Боб в стране PGP».
К сожалению, в чистом виде схема асимметричного шифрования также не годится для мессенджеров, поскольку эти сервисы ориентированы на интенсивную онлайновую переписку в виде цепочки коротких сообщений. Они должны отображаться в строго определенном порядке, а собеседник может в любое время оказаться офлайн и нарушить структуру диалога.
К тому же шифровать множество коротких сообщений одним ключом — плохая идея. Всего за день переписки их создаются сотни (если не тысячи). Во многих сообщениях количество шифротекста минимальное и предсказуемое (смайлик, стикер). Также у них есть стандартные заголовки, которые упрощают криптоанализ.
Особенность переписки в мессенджерах в том, что из-за типовых метаданных за короткое время атакующий может перехватить большой объем предсказуемого шифротекста. Его львиная доля будет соответствовать известному открытому тексту. Если она будет шифроваться одним ключом, то при успешной атаке окажутся скомпрометированными все ранее написанные сообщения, и даже те, которые собеседники напишут в будущем.
Чтобы этого не происходило, в мессенджерах предусмотрены такие свойства, как прямая и обратная секретность. Они подразумевают невозможность прочитать отправленные ранее и написанные в будущем сообщения, имея на руках только текущий ключ шифрования. Для этого используется многослойное шифрование с переходом от асимметричной к симметричной криптографии и дополнительные ключи с разным временем жизни.
Диффи, Хеллман! Дайте три!
Из открытой документации известно, что в Telegram аутентифицированное распределение ключей обеспечивает классический протокол Диффи — Хеллмана (DH). Он создает мост между асимметричным (RSA) и симметричным (AES) шифрованием, давая возможность энному количеству собеседников вести зашифрованную переписку, передав только публичные ключи по открытому каналу. Для этого в нем генерируются сессионные ключи, представляющие собой общий секрет или общий эфемерный ключ. Он вычисляется на основе секретного ключа одного собеседника и публичного ключа другого. Эфемерные ключи аутентифицируются долговременными открытыми ключами.
В DH канал передачи может быть не защищен от прослушивания (пассивного наблюдения), но обязан иметь защиту от атаки подмены. Если атакующая сторона может подменить трафик (выполнить активную атаку MITM), то вся схема летит к черту.
Поэтому для своего мессенджера Signal компания Open Whisper Systems использует метод тройного преобразования Диффи — Хеллмана X3DH c Curve25519 (эллиптическая кривая Бернстайна для быстрого DH) или X448. В качестве других криптографических примитивов в X3DH используется HMAC-SHA-256 и AES-256.
Протокол Extended Triple Diffie — Hellman устанавливает общий секретный ключ между двумя сторонами, которые взаимно аутентифицируют друг друга на основе открытых ключей. Дополнительно ключи сверяются сразу после установки сессии и перед началом передачи сообщений. Это сводит к минимуму риск MITM-атак, делая их очень сложными.
В X3DH используются четыре типа ключей, три из которых постоянно меняются:
- IK (identity keys). Секретные ключи, которые создаются один раз и служат основой для формирования всех остальных;
- EK (ephemeral key). Эфемерный ключ, который нужен для проверки личности собеседника (без разглашения истинной);
- SPk (signed public key, signed proof of knowledge) — по сути, это эфемерный ключ, подписанный секретным. Обычно в мессенджерах он меняется с частотой от одного дня до недели. Иногда вместо времени жизни SPk задают число сообщений, после которого он меняется;
- OPK (one-time public key) — одноразовый эфемерный ключ. Он создается отправителем перед установкой сеанса связи и удаляется сразу после успешного «рукопожатия» (handshake).
Смена вспомогательных ключей в X3DH происходит по алгоритму Double Ratchet. Он пришел на смену OTR и ввел понятие цепочки, или пула, ключей. На случай, если собеседник будет офлайн, предусмотрено создание пула OPK. Несколько разовых эфемерных ключей заранее загружаются на сервер и расходуются по мере общения. Это позволяет серверу принимать зашифрованные сообщения, аутентифицируя их отправителя по новой паре ключей, даже когда получатель не в сети. Если пул OPK исчерпан, то сервер использует запасной EK.
Название «двойной храповик» — отсылка к устройству шифровальной машины Enigma с зубчатыми колесиками, которые исключали обратное движение и повторное использование прежних значений. Цифровая аналогия в том, что DR используется для генерирования новых эфемерных ключей, которыми шифруется следующее сообщение (или небольшая порция сообщений). При этом эфемерные ключи гарантированно отличаются, не повторяют предыдущие и не могут быть предсказаны за разумное время атаки.
На X3DH основан протокол TextSecure, который позже был переименован в Signal. В чистом или слегка модифицированном виде протокол Signal используется в одноименном мессенджере, а также в WhatsApp, Viber и других. Разработчики могут давать протоколам собственные названия, но по сути это все тот же X3DH с варьирующимся набором хеш-функций, ГПСЧ и иных криптографических примитивов.
Проблема групповых чатов
Организация групповых чатов в мессенджерах подробно разобрана в свежей статье «More is Less: On the End-to-End Security of Group Chats in Signal, WhatsApp, and Threema» (PDF). Приведу основные выводы из нее.
Наш систематический анализ выявил, что целостность коммуникаций (представленная целостностью всех сообщений) и групповая принадлежность (определяемая возможностью членов группы управлять ими) не имеют end-to-end-защиты. Кроме того, мы показали, что обратная секретность (ключевое свойство безопасности) не сохраняется при использовании протокола Signal для групповых чатов.
Пояснение: краеугольный камень сквозного шифрования — аутентифицированное распределение ключей по классическому или усиленному протоколу DH. Оно работает только для двух собеседников, формирующих общий секрет. Ожидаемо, что в мессенджерах DH не используется в групповых чатах, а структура обмена сообщениями в них лишена основных криптографических свойств.
Шифрование в групповых чатах. A — отправитель, B — получатель, G — группа пользователей
Авторы показывают, какие манипуляции может выполнять контролируемый злоумышленником сервер в групповых чатах из-за отсутствия в них E2EE. Свои исследования они проводили на примере Signal и WhatsApp, но вряд ли стоит ожидать, что у других мессенджеров эта проблема имеет какое-то изящное решение.
Странности Telegram
С Telegram все покрыто завесой тайны. О протоколе MTProto 2.0 есть только частичные сведения. Его внешний аудит не выполнялся, а опенсорсная модель Telegram используется в сильно искаженном виде и исключительно с маркетинговыми целями. Ниже я поясню, почему так считаю.
Судя по официальному описанию, все недоставленные сообщения временно (мы надеемся) хранятся на серверах Telegram, которые часто разбросаны по миру и объединены в виртуальное облако. Они синхронизируются между собой, чтобы упорядочить и доставить сообщения одному или нескольким (в случае группового чата) собеседникам в определенном порядке, как только они появятся в сети. Поэтому шифрование делится на два этапа: на участках клиент — сервер и сервер — сервер. Это обычная схема, но в ней странно то, что прямое соединение клиентов не используется вообще никогда.
В Telegram трафик передается через серверы даже при открытии секретного чата, для которого логичнее было бы сделать P2P-соединение. Напрашивается вывод, что без постоянного использования серверов Telegram связь в этом мессенджере вообще не работает. Другие мессенджеры могут использовать свои серверы только на начальном этапе — для сопоставления текущих IP-адресов собеседников и организации между ними прямого соединения. Telegram так не умеет, и это чертовски похоже на MITM by design.
Почему-то все рассуждения о стойкости MTProto 2.0 крутятся вокруг того, что алгоритм DH надежно защищает от перехвата. Это не так. Алгоритм Диффи — Хеллмана как раз уязвим для атаки MITM. Более того, в случае Telegram он, вероятно, дополнительно ослаблен на уровне ГПСЧ.
Проблема в том, что клиентское приложение Telegram руководствуется очень невнятной оценкой энтропии. Вместо того чтобы локально генерировать псевдослучайные числа и отсеивать качественные простые, клиент запрашивает их с сервера. Что за ГПСЧ используется на сервере, насколько удачные простые числа он генерирует и нет ли на сервере механизмов избирательной отправки простых чисел с определенными свойствами отдельным клиентам — вопросы без ответа. Клиентское приложение лишь выполняет проверку присланного случайного числа, причем упрощенную, поскольку на тщательный тест prime numbers за разумное время у смартфона банально не хватит вычислительных ресурсов.
Другой частый аргумент в пользу безопасности Telegram — открытые исходники. Однако в них нет исходного кода серверной части, а код клиентской обычно неактуален. Репозитории Telegram обновляются с большой задержкой (разве что урезанная веб-версия более-менее живая), и в них всегда лежат только старые версии. Нет даже возможности проверить, действительно ли из исходников компилируется то, что сейчас раздается как готовый дистрибутив.
Поэтому говорить про аудит мессенджера фактически бессмысленно. Пока специалисты несколько месяцев копаются в старом коде, выйдет десяток новых версий Telegram, где будут переписаны огромные куски кода. Чтобы сделать уязвимой всю систему шифрования, достаточно замены одного байта — например, одного условного перехода.
Хакатоны, которые устраивает Дуров, не заменят аудит, поскольку ничего не доказывают. В их заданиях создается искусственная ситуация, в которой у атакующей стороны есть только одно зашифрованное сообщение. В реальной жизни таких ограничений нет и для атаки на мессенджер есть множество других векторов.
Тысяча и одна уязвимость
Signal — один из немногих мессенджеров, чей протокол проходил внешний аудит (PDF). Отчет о его результатах очень объемный, поэтому процитирую главные выводы в своем переводе.
Наш анализ показывает, что [протокол] Signal удовлетворяет стандартным криптографическим предположениям и свойствам безопасности. Мы не обнаружили серьезных недостатков в его дизайне, что очень обнадеживает. При реальном использовании Signal остаются неопределенности. Поэтому невозможно сказать, всегда ли [приложение] Signal достигает заявленных целей.
Нужно осознавать, что анализ протокола передачи сообщений — важный этап аудита, но далеко не единственная составляющая безопасности. Любой мессенджер работает в реальной и очень уязвимой среде. Обычно он запускается на не самой свежей версии Android, параллельно с сотней левых приложений (часть из которых наверняка злоупотребляют разрешениями или даже содержат троянские закладки), а сам аккаунт привязан к номеру мобильного телефона.
Огромная брешь заключается в том, что коды подтверждения приходят в SMS. Их можно перехватить через известную уязвимость в протоколе сотовой связи SS7. Так атакующий получит доступ ко всей переписке, не зная ключей шифрования и даже не пытаясь взломать Signal/Proteus/MTProto/другойсекьюрныйпротокол. Сервер мессенджера сам сменит ключ и услужливо дешифрует последнюю переписку (как минимум, недоставленные сообщения). Даже твои стикерпаки восстановит. Главное же — удобство, верно?
Еще одна зияющая дыра в модели безопасности — push-уведомления. Без них ты не узнаешь, что тебе пришло сообщение, пока вручную не запустишь мессенджер. С ними ты превращаешь сервер push-уведомлений в легализованного «человека посередине». Например, чтобы в iMessage работали уведомления, он отправляет ключи шифрования на серверы Apple. Уже они выполняют аутентификацию пользователей и (как минимум) дешифровку заголовков сообщений. Восстанови учетку Apple на другом устройстве, и ты получишь все как было — вплоть до переписки и паролей от Wi-Fi. Почти такая же ситуация с серверами Google и Microsoft. Или ты еще веришь в сквозное шифрование с привязкой к номеру мобильного и основному аккаунту на смартфоне?
Проблема небезопасного управления ключами и большой поверхности атаки касается вообще всех мессенджеров. WhatsApp, Viber и многие другие позволяют создавать копии переписки (в том числе облачные) и не шифруют метаданные (а иногда сам факт разговора важнее его содержания). У Signal дела обстоят чуть лучше, но и его я не считаю идеальным мессенджером по целому ряду причин:
- Во-первых, Signal также использует гугловский сервис push-уведомлений. Поэтому на смартфоне без сервисов Google (например, все китайские модели для внутреннего рынка без GApps) он просто не работает.
- Во-вторых, для голосового общения в Signal используется закрытый сервер RedPhone.
- В-третьих, Signal (как и многие другие мессенджеры) позволяет открыть параллельную сессию на другом устройстве, просто отсканировав QR-код.
- В-четвертых, на HITBSecConf2017 рассказали (PDF) про ряд концептуальных проблем Signal и продемонстрировали успешную атаку на него.
Как видишь, сторонним и тем более проприетарным мессенджерам доверять сложно, даже если их рекомендовали Сноуден, Ассанж и EFF. Поэтому некоторые организуют общение через свой мессенджер — с опенсорсом и плагинами. Для простой переписки годится плагин OTR, но он не поддерживает групповые чаты. Есть родственные протоколы mpOTR и GOTR, в которых добавлена эта функция.
Так или иначе, для коллективного общения удобнее использовать открытый протокол XMPP (Extensible Messaging and Presence Protocol), который ранее назывался Jabber. XMPP переводится как «расширяемый протокол обмена сообщениями и информацией о присутствии», это очень емкое название. Открытость означает полную доступность исходных кодов. Ты можешь поднять свой сервер XMPP, ни от кого не зависеть и ничего за это не платить. Также есть уйма готовых серверов и клиентов на любой вкус — например, десктопный Pidgin и Xabber для Android.
Расширяемость подразумевает возможность передачи не только текста, но и данных другого типа, а также добавление разных функций и схем шифрования. Например, по XMPP легко передать голосовые сообщения, видео и файлы, при желании зашифровав их средствами TLS или PGP. Не так давно на базе XMPP был создан протокол расширения OMEMO, в котором используется тот же DR от Open Whisper Systems, что и в Signal и WhatsApp, но без прочих недостатков последних.
Выводы
В современных мессенджерах заявлена поддержка сквозного шифрования, но часто оказывается, что она реализована со странностями. К тому же в их коде много других дыр, которые были оставлены случайно либо намеренно. Последнее куда вероятнее, если учесть, сколько денег и труда профессионалов было вложено в их разработку. Я стараюсь соблюдать баланс между комфортом и привычным наслаждением паранойей. Использую разные мессенджеры (какие удобнее моим собеседникам), но никогда не веду через них действительно приватных бесед. Для этого есть множество опенсорсных альтернатив.
Источник
