Протоколы обеспечения безопасности сервиса «мгновенных сообщений»

From CryptoWiki
Jump to: navigation, search

Contents

Введение

Базовая архитектура IM сервисов

Сервис мгновенного обмена сообщениями или сервис мгновенных сообщений (англ. Instant messaging, IM) -- службы мгновенных сообщений (Instant Messaging Service, IMS), программы онлайн-консультанты (OnlineSaler) и программы-клиенты (Instant Messenger, IM) для обмена сообщениями в реальном времени через Интернет.

В функциям IM входят:

  • Прием и отправку текстовых сообщений;
  • Отправка аудио и видео записей;
  • Отправка изображений;
  • Звонки на компьютер собеседника, а также VoIP-телефония на стационарные телефоны;
  • Отправка SMS;
  • Введение истории переписки;
  • Могут производиться такие действия, как совместное рисование и игры;
  • Организация групповых текстовых чатов;
  • Организация видеоконференций.


Сервисы мгновенных сообщений, используются как альтернативное электронной почте средство общения. Прообразом IM были онлайн-чаты, использующиеся с начала 1990-х годов (из них был взят основной принцип работы - мгновенная доставка сообщений от собеседника к собеседнику). Первый Интернет-пейджер - ICQ сокращенная аббревиатура от англоязычной фразы "I seek you" (Я тебя ищу), русскоязычная форма - „ася“, „аська“), как вскоре стали называть подобные сервисы и программные клиенты, был запущен в ноябре 1996 компанией Mirabilis. Решение имело клиент-серверную архитектуру (стало классическим для подобных систем) - пользователь загружал бесплатную программу-клиент, которая подключалась к серверу, на котором хранились регистрационные данные (присвоенный системой шестизначный номер и пароль) и список контактов.

Постановка задачи защиты информации

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

Для достижения поставленной задачи были определены следующие подзадачи:

  • Рассмотреть принцип работы сервиса "мгновенных сообщений";
  • Рассмотреть протоколы обеспечения безопасности "мгновенных сообщений".

История развития

Логотип XMPP Standards Foundation

Практически сразу (в начале 1997 года) после появления сервиса ICQ, разработанного компанией Mirabilis, подобную систему мгновенного обмена сообщениями реализовал портал America Online (AOL), назвав его AIM. Отличительной особенностью последнего стала возможность не только передачи текстовых сообщений, но и поддержкой чатов с другими пользователями, незарегистрированными в сети AOL. В 1998 году AOL купила компанию Mirabilis, продолжив развитие ICQ. Параллельно с развитием AOL свои проекты в этой области стали развивать Microsoft и Yahoo!, выпустившие, соответственно, MSN (позже - Windows Live) Messenger и Yahoo! Messenger. В основу этих программ были положены все те же принципы (общение в режиме реального времени в виде текстовых сообщений, позже - в виде голосового общения, обмена файлами и видео), но в отличие от AIM/ICQ эти сервисы были жестко привязаны к регистрации на MSN.com и Yahoo.com.

В 2001 году компания America Online перешла под контроль Time Warner - в клиенте ICQ стала появляться реклама. Параллельно с коммерческим проектом стали развиваться и некоммерческие, преимущественно, open-source. Самый известный из них - проект Jabber был основан Джереми Миллером в начале 1998 года (первое сообщение о проекте датировано 4 января 1999 года). Вскоре после этого к проекту присоединилось несколько основных разработчиков, которые стали работать над сервером jabberd, клиентами Jabber для Windows и GNU/Linux, а также шлюзами в основные системы IM (AIM, ICQ, MSN, и Yahoo). В 2001 - 2007 годах было выпущено несколько реализаций сервера, созданы программные клиенты для разных операционных систем, в том числе и Microsoft Windows. В 2005 году знаковым событием для индустрии стало появление своего IM-клиента от Google - Google Talk. 17 января 2006 года разработчики Google подключили свой сервис к сети Jabber, таким образом унифицировав обмен сообщениями между пользователями любых серверов Jabber и GTalk.

В 2005 году ICQ (первой из всех IM-систем) появилась в России. Интересы компании ICQ в России стал представлять «Рамблер Интернет Холдинг», а российские пользователи получили возможность работать в локализованном программном клиенте (на основе версии ICQ 5). На тот момент времени крупнейшие IM-службы (ICQ, Yahoo!, MSN) позволяли пользователям обмениваться не только текстовой информацией и голосом, но и передавать файлы, SMS, играть в многопользовательские игры, устраивать видеоконференции. На этот же период приходится и появление и последовавший рост альтернативных программных клиентов (QIP, &RQ, Miranda IM).

Принцип работы сервиса мгновенных сообщений

Архитектура Jabber

Для работы в IM-системе пользователю необходимо получить идентификатор (для ICQ - это UIN, состоящий из цифр; для Jabber - это Jabber ID, состоящий из имени пользователя и сервера, например, user@grcc.jabber.ru; другие системы, как правило, используют адреса электронной почты) и установить на свой компьютер программный клиент.

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

Общение ведется одновременно между двумя собеседниками, в то же время другие пользователи их контакт-листа или просто другие участники сети могут также отправлять сообщение, которые будут отображаться в окнах чата программного клиента.

В ряде программ (например, Skype) допускаются многопользовательские чаты. Способ отображения других элементов интерфейса различаются в разных клиентах, но, как правило, в списке вместо номера контакта может показываться или имя, присвоенное собеседнику пользователем IM-клиента или ник, который сам пользователь указал при регистрации или изменении личных данных.

По окончании беседы пользователь может закрывать активное окно чата, а также выходить из сети. Сервер автоматически меняет статус в контакт-листах других участников, но продолжает принимать текстовые сообщения.

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

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

Широкому кругу пользователей известно некоторое количество популярных сетей (и клиентов) обмена сообщениями, таких как IRC, Skype, ooVoo, AIM, ICQ, MSN, Yahoo!, Jitsi, XMPP. Каждая из этих сетей разработана отдельной группой разработчиков, имеет отдельные серверы и протоколы, отличается своими правилами и особенностями. Между различными сетями обычно нет прямой связи (только в XMPP существует понятие межсетевого транспорта), таким образом, пользователь сети Skype не может связаться с пользователем сети ICQ, однако ничто не мешает быть одновременно пользователем нескольких сетей.

Почти для каждой из сетей есть свой мессенджер, разработанный той же командой разработчиков. Так, для пользования тремя последними из вышеуказанных сетей разработчиками предлагаются программы с одноимёнными названиями: ICQ, Windows Live Messenger, Yahoo! Messenger, а также Skype. Таким образом, если один из адресатов пользуется только сетью ICQ, а другой — только сетью MSN, то можно общаться с ними одновременно, установив на своем компьютере и ICQ, и MSN Messenger и зарегистрировавшись в обеих сетях (либо через соответствующие транспорты в XMPP).

Большинство IM-сетей используют закрытые протоколы, поэтому альтернативные клиенты теоретически могут обладать меньшим количеством базовых функций, чем официальные, хотя на практике чаще бывает наоборот. Однако при изменениях протокола на стороне сервера сети альтернативные клиенты могут внезапно перестать работать.

В качестве альтернативы проприетарным протоколам для IM был разработан открытый и хорошо расширяемый протокол XMPP (также известный как Jabber), используемый в таких сервисах, как Google Talk, Я.Онлайн и др. Этот протокол часто используется для организации общения в корпоративных и других локальных сетях и имеет ряд существенных преимуществ, как, например, шифрование сообщений и стабильность на неустойчивых каналах связи. Протокол децентрализованный, его архитектура напоминает электронную почту, где возможно общение между пользователями, имеющими аккаунты на разных серверах. Если нарушится работа одного сервера, то это не повлияет на работу всей сети.

Протокол Extensible Messaging and Presence Protocol (XMPP)

XMPP (Extensible Messaging and Presence Protocol - расширяемый протокол обмена сообщениями и информацией о присутствии), ранее известный как Jabber ("болтовня", "треп", "тарабарщина") - основанный на XML, открытый, свободный для использования протокол для мгновенного обмена сообщениями и информацией о присутствии в режиме, близком к режиму реального времени. Изначально спроектированный легко расширяемым, протокол, помимо передачи текстовых сообщений, поддерживает передачу голоса, видео и файлов по сети.

В отличие от коммерческих систем мгновенного обмена сообщениями, таких как AIM, ICQ и Yahoo!, XMPP является децентрализованной, расширяемой и открытой системой. Любой желающий может открыть свой сервер мгновенного обмена сообщениями, регистрировать на нём пользователей и взаимодействовать с другими серверами XMPP. На основе протокола XMPP уже открыто множество частных и корпоративных серверов XMPP. Среди них есть достаточно крупные проекты, такие как Facebook, Google Talk, Одноклассники.ru, QIP, LiveJournal, Juick и др.

Описание протокола

Схема устройства работы XMPP

Семейство протоколов XMPP принято как стандарт RFC 3920, 3921.

Для данного протокола по умолчанию используется порт 5222, также возможно использование порт 80 и/или 443, при возникновении проблем с межсетевым экраном.

Преимущества протокола

  • Децентрализация: Архитектура сети XMPP схожа с электронной почтой. Можно создать свой собственный XMPP-сервер и нет какого-либо определенного центрального сервера [11].
  • Открытый стандарт: Существует множество реализаций серверов и клиентов, а также библиотек с открытым исходным кодом [11].
  • Безопасность: XMPP серверы могут быть изолированы от публичных сетей XMPP (например, во внутренней сети компании) и хорошо защищены (благодаря использованию SASL и TLS) встроенными в ядро XMPP спецификациями. Для поддержки использования шифрования канала XMPP Standards Foundation также использовал вспомогательный certification authority в xmpp.net, обеспечивая цифровые сертификаты для администраторов XMPP серверов при содействии StartCom Certification Authority (который является основным хранителем сертификатов для всех вспомогательных). Многие реализации серверов используют SSL при обмене между клиентом и сервером, и немало клиентов поддерживают шифрование с помощью PGP/GPG внутри протокола [11].
  • Гибкость: Настраиваемая функциональность может быть надстроена поверх XMPP; для поддержки возможности взаимодействия различных сетей стандартные расширения поддерживаются XMPP Software Foundation. Приложения XMPP в дополнение к функциональности клиента сетевого общения включают в себя администрирование сети, распределение ресурсов, утилиты для совместной работы, обмен файлами, игры и мониторинг удалённых систем [11].

Слабые стороны протокола

  • Избыточность передаваемой информации: Как правило, более 70 % межсерверного трафика XMPP составляют сообщения о присутствии, около 60 % которых являются излишними. XMPP на данный момент создаёт избыточный трафик при доставке сообщений о присутствии (то есть «статус-сообщений») нескольким пользователям. Для решения этой проблемы разрабатываются новые протоколы. Также решением является расширение XEP-0138 — компрессия передаваемых данных протокола алгоритмами lzw и zlib, а также использование компрессии в рамках шифрования соединения TLS.
  • Масштабируемость: XMPP сейчас страдает от фактически той же проблемы избыточности, но применительно к чат-комнатам и возможностям публикации информации. Решение этих проблем также ожидается в виде XEP-расширений. Пока они не введены, большие чат-комнаты интенсивно образуют избыточный трафик.
  • Неэффективность передачи бинарных данных: Так как XMPP является, по сути, одним длинным XML-документом, невозможно передать немодифицированную двоичную информацию. В результате этого, для передачи файлов стараются использовать дополнительные протоколы, например, HTTP. Для передачи же файлов и другой бинарной информации непосредственно в XMPP потоке используется кодирование base64. С другой стороны, некоторые клиентские программы, например Gajim, для передачи используют технологии p2p, не задействуя при этом сервер.

Протокол Off-the-Record Messaging (OTR)

Off-the-Record Messaging (OTR) - это криптографический протокол который обеспечивает шифрование данных при использовании сервиса мгновенных сообщений. OTR использует комбинацию AES со 128-битным ключом, Diffie–Hellman key exchange со 1536-битным ключом и SHA-1. В дополнение к аутентификации и шифрования, OTR обеспечивает вперед идущую безопасность.

Согласование ключей

Для передачи сообщений с использованием OTR участники протокола должны установить общий секретный ключ. Для этого используется протокол аутентифицированного распределения ключей (англ. Authenticated Key Exchange), основанный на протоколе Диффи — Хеллмана [3].

В начале протокола участники A и B выбирают простое число P.png и генератор G.png группы Group.png. A выбирает случайное число A1.png и отправляет B результат вычисления Gmodp.png. B выбирает случайное число B1.png и отправляет A результат вычисления Gbmodp.png. Затем участники используют общий эфемерный ключ Key.png, где H.png — криптографическая хеш-функция SHA-1 [1].

Обновление ключей

Для обеспечения perfect forward secrecy пользователи постоянно обновляют ключ во время обмена сообщениями [1][3]. При передаче первого сообщения одна из сторон (например, сторона A) шифрует сообщение с помощью функции шифрования E.png с ключом K11.png, выбирает случайное число A2.png и передает B пару значений Ek(m).png. Для шифрования следующего сообщения используется ключ Key-k21.png. В дальнейшем при передаче каждого сообщения A изменяет число Ai.png, а B изменяет число Bj.png, и ключ Kij.png обновляется.

На практике сообщения доходят не мгновенно, поэтому после отправки сообщения от A к B и обновления ключа на стороне A, A все еще может получить сообщение от B, зашифрованное старым ключом. Участник A может быть уверен в том, что B обновил ключ, только тогда, когда получит от B сообщение, зашифрованное новым ключом. Поэтому A хранит достаточное количество старых ключей, чтобы иметь возможность расшифровать все сообщения, которые еще не дошли. Для того, чтобы ключи все же обновлялись достаточно часто, сторона, у которой нет сообщений для отправки, время от времени передает пустые сообщения [1].

Аутентификация ключей

Аутентификация всех эфемерных ключей, за исключением K11.png , осуществляется вместе с аутентификацией сообщений [1]. Для аутентификации ключа K11.png используются долговременные ключи. В первой версии OTR использовалась небезопасная схема аутентификации, которая была впоследствии изменена [3].

Оригинальная версия протокола

В первой версии протокола OTR для аутентификации ключа K11.png стороны подписывают соответствующие сообщения [1]. Также в этих сообщениях стороны передают друг другу свои открытые ключи, как показано на схему ниже.

Scheme1.png
Scheme2.png

Здесь Sa.png и Sb.png — цифровая подпись, Pa.png и Pb.png — открытые ключи сторон A и B соответственно.

Данная версия протокола содержит уязвимость [2][3]. Сторона E может выполнить аутентификацию одновременно со сторонами A и B, при этом выдав себя одной из сторон (например, B) за другую сторону (например, A), как показано далее.

Scheme3.png
Scheme4.png
Scheme5.png
Scheme6.png

После этого E не может читать сообщения, так как они зашифрованы известным только A и B ключом, но B считает, что он разговаривает с E, хотя на самом деле разговаривает с A [1].

Более безопасные протоколы, такие как SKEME, рассматривались при реализации первой версии протокола OTR, но вместо этого был реализован собственный протокол [1].

Вторая версия протокола

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

Вариант протокола SIGMA, называемый SIGMA-R, работает следующим образом [2]:

Scheme7.png
Scheme8.png
Scheme9.png
Scheme10.png

Здесь A и B — идентификаторы, Sa.png и Sb.png — цифровые подписи, Pa.png и Pb.png — открытые ключи сторон A и B соответственно, а H — криптографическая хеш-функция.

Аутентификация сообщений

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

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

Когда сторона A передает сообщение M другой стороне B, вместе с сообщением она передает вычисленное с помощью общего ключа значение HMAC(M, K). Сторона B, получив сообщение, может также вычислить HMAC(M, K). Если оно совпадает с полученным значением, то сторона B знает, что сообщение было передано либо стороной A, либо стороной B, но так как сторона B знает, что она сообщение не посылала, то она может быть уверена, что сообщение действительно было отправлено стороной A. В то же время использование HMAC обеспечивает отрицаемость: даже раскрыв ключ K, B не может доказать третьей стороне, что сообщение было отправлено стороной A. Сообщение также могло быть подделано стороной B и любой стороной, которая знает ключ K.

Шифрование сообщений

Для шифрования сообщений используется алгоритм AES в режиме счетчика [2]. Использование, построенного таким образом, поточного шифра обеспечивает спорное шифрование (англ. malleable encryption). Это значит, что любой, кто перехватит сообщение, сможет выборочно изменить любые биты в сообщении. В частности, если сообщение стало известно, его можно изменить на любое другое сообщение такой же длины [1].

Спорное шифрование требуется для обеспечения отрицаемости шифрования [2]. Благодаря спорному шифрованию участники протокола OTR могут утверждать, что любое из переданных сообщений было изменено третьей стороной.

Обзор безопасности сервисов мгновенных сообщений

Название клиента Open Source лицензия Без центрального сервера Симметричное шифрование (AES, Camellia) Асимметричное шифрование: RSA, DSA Асимметричное шифрование: NTRU Асимметричное шифрование: ElGamal Размер ключа по умолчанию (асим. шифр.) Макс. размер ключа (асим. шифр.) Вперед идущая безопасность Мультишифрование Клиентское шифрование Шифрование группового чата Шифрование при передачи файлов Открытый ключ не прикрепляется к IP? TCP UDP
Kik нет нет нет  ? нет нет  ?  ?  ? нет  ? нет  ? да да  ?
RetroShare GPL да нет да нет нет 2048  ? нет нет да да да нет да да
Sicher нет нет да да нет нет 2048 2048 нет нет да да да нет да нет
Surespot GPLv3 да нет да нет нет 1024 2048 да нет да нет нет нет да нет
Telegram GPL v2 (client), closed source (server) да нет да нет нет 1024 2048 да нет да нет нет нет да нет
TextSecure GPLv3 да да да нет нет 2048 2048 да да да да да да да нет
WASTE GPL да нет да нет нет 1024 1024 нет нет да нет да нет да нет
HushHush нет нет да да нет нет 1024 1024  ? да да да да да да  ?

Описание табличных критериев

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

  • Открытый исходный код: Алгоритмы шифрования должны быть прозрачными. Поэтому статус открытого исходного кода приложения является существенным. Открытый исход код позволяет найти ошибки и недостатки в коде, тем самым можно проверить реализуется шифрование надлежащим образом или нет. В целом рекомендуется не доверять приложениям с закрытым исходным кодом.
  • Децентрализованная модель: Месенджер выдаст ошибку, если центральный сервер будет закрыт. Чтобы такого не происходило была разработана децентрализованная серверная архитектура, потому что такая архитектура (где не все сообщения проходят через центральный сервер) имеет большой плюс в отношении безопасности.
  • Симметричное шифрование: В симметричной криптографии используется один и тот же ключ для шифрования и дешифрования. Знание этого ключа должно быть ограничено двумя партнерами, между которыми происходит обмен сообщениями, для обеспечения конфиденциальности.
  • Альтернативы в асимметричном шифровании: Асимметричное шифрование означает, что у каждого участника есть закрытый и открытый ключи.
  • Размер ключа: Размер ключа описывает длину необходимой математической операции. Проще говоря, чем больше длина ключа, тем больше времени потребуется, чтобы взломать его. В настоящее время рекомендованная длина ключа составляет 2048 бит.
  • Вперед идущая безопасность: Вперед идущая безопасность описывает возможность изменения ключа шифрования для каждой сессии или даже мгновенное изменение ключа.
  • Мультишифрование: Мультишифрование описывает несколько уровней шифрования. Например, Вы можете добавить симметричное шифрование в асимметричное шифрование.
  • Шифрование клиента: Шифрование должно производиться на устройстве пользователя, а не на удаленном сервере в сети, т.е. преобразование открытого текста в шифртекст, должно производиться на устройстве пользователя.
  • Групповой чат и передача файлов: Некоторые клиенты предлагают возможность групповых чатов, а также возможность передачи файлов. Эти возможности также должны использовать шифрование.
  • Открытый ключ не прикрепляется к IP?: Открытые ключи используются для идентификации пользователей. IP-адрес пользователя в некоторых случаях может быть связан с открытым ключом. Месенджеры в которых ключ пользователя не прикрепляется к IP-адресу, считаются более безопасными. Если злоумышленник знает IP-адрес, связанный с открытым ключом, то он может попытаться получить на удаленной машине, загрузить и расшифровать закрытый ключ и, таким образом, расшифровать все зашифрованные сообщения.
  • Транспортные протоколы: Не все клиенты поддерживают популярные транспортные протоколы такие как TCP, UPD и SCTP.

Практическое задание

Доступно для скачивания приложение, демонстрирующее работу Socialist Millionaire Protocol (SMP), который используется в протоколе Off-The-Record Messaging (OTR) для проверки подлинности противоположной стороны, зная какой-то общий секрет. Данный протокол позволяет удостоверится в том, что участники знают какую-то общую информацию (пароль, ответ на вопрос известный только им) не разглашая её напрямую.

Исходный код демонстрационной программы: File:SMP.zip

Исполняемые файлы демонстрационной программы: File:SMP(.exe).zip

Глоссарий

TLS

p2p

Эфемерный ключ

SKEME

AES

HMAC

Хеширование

Поточный шифр

Режим счетчика

Открытый стандарт

OSCAR

Клиент-серверные технологии

Библиографический указатель

Перейти к списку литературы

Вернуться на главную страницу

Вернуться к оглавлению


Игонькин Н.А.

Букач В.В.

2014

Назад