Русская Википедия:Off-the-Record Messaging

Материал из Онлайн справочника
Перейти к навигацииПерейти к поиску

Off-the-Record Messaging (OTR) — криптографический протокол для систем мгновенного обмена сообщениями, созданный в 2004 году Никитой Борисовым и Ианом Голдбергом (Шаблон:Lang-en).

Авторами создана библиотека, распространяемая под лицензией GNU Lesser GPL, используемая для поддержки OTR клиентами систем мгновенного обмена сообщениям. Также на основе этой библиотеки авторами создан плагин для Pidgin.

Фонд EFF рекомендует использовать OTR для защиты от прослушивания[1].

История

Первая версия протокола OTR и его реализация были представлены в 2004 году Никитой Борисовым и Ианом ГолдбергомШаблон:SfnШаблон:Sfn. В 2005 году была опубликована атака на первую версию протокола OTR и предложен исправленный протокол аутентификацииШаблон:Sfn. В том же году разработчики OTR представили вторую версию протокола с исправлением протокола аутентификации, также дополнительно улучшив егоШаблон:Sfn.

В 2007 году Оливер Гоффарт (Шаблон:Lang-en) опубликовал модуль mod_otr[2] для сервера ejabberd, позволяющий автоматически проводить атаку типа «человек посередине» на пользователей OTR, не проверяющих отпечатки открытых ключей друг друга. После этого разработчики улучшили OTR с использованием решения задачи «социалиста-миллионера» (Шаблон:Lang-en), позволяющего двум пользователям провести аутентификацию без обмена ключами или их отпечатками при условии, что они знают общий секретШаблон:Sfn.

Файл:Off-The-Record authentication dialog..png
Аутентификация с использованием вопроса и секретного ответа в Pidgin

Основные свойства протокола

Протокол OTR разрабатывался для того, чтобы обеспечить приватность переговоров, аналогичную переговорам без использования средств телекоммуникацийШаблон:Sfn Шаблон:Sfn. Для этого к разрабатываемому протоколу были предъявлены следующие требования:

  • шифрование сообщений — никто иной не сможет прочитать сообщения;
  • аутентификация собеседников — уверенность в том, кто является собеседником;
  • perfect forward secrecy — если потеряны секретные ключи, прошлая переписка не будет скомпрометирована;
  • возможность отречения — третье лицо не сможет доказать, что сообщения написаны кем-либо другому адресату.

Частично эти свойства реализованы в таких системах, как PGP и Trillian SecureIM. OTR отличается тем, что реализует все эти свойства в одном протоколеШаблон:Sfn.

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

Для передачи сообщений с использованием OTR участники протокола должны установить общий секретный ключ. Для этого используется протокол аутентифицированного распределения ключей (Шаблон:Lang-en), основанный на протоколе Диффи — ХеллманаШаблон:Sfn.

В начале протокола участники используют протокол Диффи — Хеллмана для установки секретного ключа, необходимого для передачи первого сообщения. Участники A и B выбирают простое число <math>p</math> и генератор <math>g</math> группы <math>\mathbb{Z}_p^*</math>. A выбирает случайное число <math>a_1</math> и отправляет B результат вычисления <math>g^{a_1} \bmod p</math>. B выбирает случайное число <math>b_1</math> и отправляет A результат вычисления <math>g^{b_1} \bmod p</math>. Затем участники используют общий эфемерный ключ <math>k_{11} = H(g^{a_1 b_1})</math>, где <math>H</math> — криптографическая хеш-функция SHA-1Шаблон:Sfn.

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

Для обеспечения perfect forward secrecy пользователи постоянно обновляют ключ во время обмена сообщениямиШаблон:SfnШаблон:Sfn. При передаче первого сообщения одна из сторон (например, сторона A) шифрует сообщение с помощью функции шифрования <math>E</math> с ключом <math>k_{11}</math>, выбирает случайное число <math>a_2</math> и передает B пару значений <math>g^{a_2}, E_{k_{11}}(M)</math>. Для шифрования следующего сообщения используется ключ <math>k_{21} = H(g^{a_2 b_1})</math>. В дальнейшем при передаче каждого сообщения A изменяет число <math>a_i</math>, а B изменяет число <math>b_j</math>, и ключ <math>k_{ij}</math> обновляется.

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

Авторы статьи «Secure Off-the-Record Messaging» критиковали используемую в OTR схему обновления ключей как не предоставляющую дополнительной безопасностиШаблон:Sfn. Так, в случае компрометации все ещё используемого эфемерного ключа <math>k_{ij}</math>, сторона, осуществляющая атаку «человек посередине», сможет модифицировать все последующие сообщения и используемые эфемерные ключиШаблон:Sfn. Также использование протокола Диффи — Хеллмана может требовать значительных (например, для устройств, питающихся от батареи) ресурсовШаблон:Sfn. Вместо этого было предложено использовать ту же схему, что и для ключа <math>k_{11}</math>, либо требующую меньше вычислительных ресурсов схему, основанную на хешированииШаблон:Sfn.

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

Аутентификация всех эфемерных ключей, за исключением <math>k_{11}</math>, осуществляется вместе с аутентификацией сообщений и описана далееШаблон:Sfn. Для аутентификации ключа <math>k_{11}</math> используются долговременные ключи. В первой версии OTR использовалась небезопасная схема аутентификации, которая была впоследствии измененаШаблон:Sfn.

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

В первой версии протокола OTR для аутентификации начального ключа <math>k_{11}</math> стороны подписывают соответствующие сообщения протокола Диффи — ХеллманаШаблон:Sfn. Также в этих сообщениях стороны передают свои долговременные открытые ключи.

<math>A \longrightarrow B \colon S_A(g^{a_1}), P_A</math>
<math>B \longrightarrow A \colon S_B(g^{b_1}), P_B</math>

Здесь <math>S_A</math> и <math>S_B</math> — цифровая подпись, <math>P_A</math> и <math>P_B</math> — открытые ключи сторон A и B соответственно.

Данная версия протокола содержит известную уязвимостьШаблон:SfnШаблон:Sfn. Сторона E, проводящая атаку «человек посередине», может выполнить аутентификацию одновременно со сторонами A и B, при этом выдав себя одной из сторон (например, B) за другую сторону (например, A), как показано далее.

<math>A \longrightarrow E \colon S_A(g^{a_1}), P_A</math>
<math>E \longrightarrow B \colon S_E(g^{a_1}), P_E</math>
<math>B \longrightarrow E \colon S_B(g^{b_1}), P_B</math>
<math>E \longrightarrow A \colon S_B(g^{b_1}), P_B</math>

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

Более безопасные протоколы, такие как SKEME, рассматривались при реализации первой версии протокола OTR, но вместо этого был реализован собственный протокол, описанный вышеШаблон:Sfn.

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

Авторы статьи Secure Off-the-Record Messaging предложили изменить протокол согласования и аутентификации ключей на один из уже известных протоколов, таких как SIGMA, SKEME и HMQVШаблон:Sfn. Также в этих сообщениях стороны передают свои долговременные открытые ключи.

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

<math>A \longrightarrow B \colon g^{a}</math>
<math>B \longrightarrow A \colon g^{b}</math>
<math>A \longrightarrow B \colon \text{A}, S_A(g^{b}, g^{a}), MAC_{H(g^{ab})} (0, \text{A}), P_A</math>
<math>B \longrightarrow A \colon \text{B}, S_B(g^{a}, g^{b}), MAC_{H(g^{ab})} (1, \text{B}), P_B</math>

Здесь A и B — идентификаторы, <math>S_A</math> и <math>S_B</math> — цифровые подписи, <math>P_A</math> и <math>P_B</math> — открытые ключи сторон A и B соответственно, а <math>H</math> — криптографическая хеш-функция.

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

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

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

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

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

Раскрытие ключей аутентификации

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

Старые ключи, которые больше не будут использованы, могут быть уничтожены. Но ключи аутентификации также могут быть не только уничножены, но и раскрыты. Авторы OTR добавили раскрытие старых ключей: вместе с сообщением пересылается старый ключ аутентификации, если известно, что он больше не будет использованШаблон:Sfn. Такое решение объясняется требованиями отрицаемости протокола OTRШаблон:SfnШаблон:Sfn.

В работе Secure Off-the-Record Messaging указывается, что раскрытие ключей аутентификации излишне усложняет протокол и может негативно быть небезопасно, как нестандартный для криптографии методШаблон:Sfn. Автор основанного на OTR протокола TextSecure, известный под псевдонимом Шаблон:Iw также указывает на излишнюю сложность и неэффективность раскрытия ключей аутентификации для обеспечения отрицаемостиШаблон:Sfn.

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

Для шифрования сообщений используется алгоритм AES в режиме счётчикаШаблон:Sfn. Использование построенного таким образом поточного шифра обеспечивает спорное шифрование (Шаблон:Lang-en). Это значит, что любой, кто перехватит сообщение, сможет выборочно изменить любые биты в сообщении. В частности, если сообщение стало известно, его можно изменить на любое другое сообщение такой же длиныШаблон:Sfn.

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

Многопользовательский OTR

Протокол OTR разработан для использования только двумя сторонами. Таким образом, его невозможно использовать в каналах IRC, конференциях XMPP и т. д.

OTR невозможно просто расширить для случая нескольких собеседников из-за используемых криптографических примитивов. Например, коды аутентификации сообщений не предоставляют аутентификации источника сообщений в многопользовательском случаеШаблон:Sfn.

Существуют расширения протокола, предоставляющие возможность использования протокола несколькими пользователямиШаблон:SfnШаблон:SfnШаблон:Sfn.

Одно из расширений протокола OTR, называемое GOTR (Group OTR), основано на идее создания «виртуального сервера»Шаблон:Sfn. Один из участников назначается «виртуальным сервером», обменивается ключами с другими участниками и в дальнейшем все сообщения между участниками конференции пересылаются через него. Недостатком протокола GOTR является то, что «виртуальный сервер» может изменять содержание сообщений, добавлять и удалять сообщения, поэтому все участники конференции должны доверять емуШаблон:Sfn.

Позже Иан Голдберг с другими авторами предложили протокол mpOTRШаблон:Sfn. В отличие от протокола GOTR, протокол mpOTR работает без выделенного центрального сервераШаблон:Sfn.

Реализации OTR

Шаблон:Карточка программы

Основной реализацией OTR является библиотека libotr, созданная командой разработчиков OTR. На её основе теми же разработчиками создан плагин для клиента Pidgin, позволяющий использовать OTR с любым из протоколов, поддерживаемых этим клиентом. Также существуют реализации протокола на языках Go, Java, JavaScript, Python, Scheme[3].

Поддержка в мессенджерах

Встроенная поддержка

Следующие клиенты имеют встроенную поддержку протокола OTR[4].

С использованием плагина

Прокси

Для клиентов, поддерживающих протокол AIM/ICQ, командой разработчиков OTR был разработан пакет otrproxy, представляющий собой локальный прокси-сервер[18]. Он позволял использовать OTR в клиентах, не имеющих собственной поддержки OTR. В настоящее время данный пакет не поддерживается, разработчики рекомендуют использовать клиенты с поддержкой OTR.

Примечания

Шаблон:Примечания

Литература

Ссылки