Off-the-Record Messaging

Для обеспечения perfect forward secrecy пользователи постоянно обновляют ключ во время обмена сообщениями[13][14]. При передаче первого сообщения одна из сторон (например, сторона A) шифрует сообщение с помощью функции шифрования ${\displaystyle E}$ с ключом ${\displaystyle k_{11}}$, выбирает случайное число ${\displaystyle a_{2}}$ и передает B пару значений ${\displaystyle g^{a_{2}},E_{k_{11}}(M)}$. Для шифрования следующего сообщения используется ключ ${\displaystyle k_{21}=H(g^{a_{2}b_{1}})}$. В дальнейшем при передаче каждого сообщения A изменяет число ${\displaystyle a_{i}}$, а B изменяет число ${\displaystyle b_{j}}$, и ключ ${\displaystyle k_{ij}}$ обновляется.

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

Авторы статьи «Secure Off-the-Record Messaging» критиковали используемую в OTR схему обновления ключей как не предоставляющую дополнительной безопасности[17]. Так, в случае компрометации все ещё используемого эфемерного ключа ${\displaystyle k_{ij}}$, сторона, осуществляющая атаку «человек посередине», сможет модифицировать все последующие сообщения и используемые эфемерные ключи[18]. Также использование протокола Диффи — Хеллмана может требовать значительных (например, для устройств, питающихся от батареи) ресурсов[19]. Вместо этого было предложено использовать ту же схему, что и для ключа ${\displaystyle k_{11}}$, либо требующую меньше вычислительных ресурсов схему, основанную на хешировании[20].

Аутентификация всех эфемерных ключей, за исключением ${\displaystyle k_{11}}$, осуществляется вместе с аутентификацией сообщений и описана далее[21]. Для аутентификации ключа ${\displaystyle k_{11}}$ используются долговременные ключи. В первой версии OTR использовалась небезопасная схема аутентификации, которая была впоследствии изменена[22].

В первой версии протокола OTR для аутентификации начального ключа ${\displaystyle k_{11}}$ стороны подписывают соответствующие сообщения протокола Диффи — Хеллмана[23]. Также в этих сообщениях стороны передают свои долговременные открытые ключи.

${\displaystyle A\longrightarrow B\colon S_{A}(g^{a_{1}}),P_{A}}$

${\displaystyle B\longrightarrow A\colon S_{B}(g^{b_{1}}),P_{B}}$

Здесь ${\displaystyle S_{A}}$ и ${\displaystyle S_{B}}$ — цифровая подпись, ${\displaystyle P_{A}}$ и ${\displaystyle P_{B}}$ — открытые ключи сторон A и B соответственно.

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

${\displaystyle A\longrightarrow E\colon S_{A}(g^{a_{1}}),P_{A}}$

${\displaystyle E\longrightarrow B\colon S_{E}(g^{a_{1}}),P_{E}}$

${\displaystyle B\longrightarrow E\colon S_{B}(g^{b_{1}}),P_{B}}$

${\displaystyle E\longrightarrow A\colon S_{B}(g^{b_{1}}),P_{B}}$

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

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

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

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

${\displaystyle A\longrightarrow B\colon g^{a}}$

${\displaystyle B\longrightarrow A\colon g^{b}}$

${\displaystyle A\longrightarrow B\colon {\text{A}},S_{A}(g^{b},g^{a}),MAC_{H(g^{ab})}(0,{\text{A}}),P_{A}}$

${\displaystyle B\longrightarrow A\colon {\text{B}},S_{B}(g^{a},g^{b}),MAC_{H(g^{ab})}(1,{\text{B}}),P_{B}}$

Здесь A и B — идентификаторы, ${\displaystyle S_{A}}$ и ${\displaystyle S_{B}}$ — цифровые подписи, ${\displaystyle P_{A}}$ и ${\displaystyle P_{B}}$ — открытые ключи сторон A и B соответственно, а ${\displaystyle H}$ — криптографическая хеш-функция.

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

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

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

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

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

• Adium
• BitlBee[58]
• climm
• ChatSecure
• Conversations Legacy
• IM+
• Jitsi
• Xabber
• Psi и Psi+ (плагин)[59][60]
• LeechCraft[61][62]
• MCabber[63]
• Profanity[64]
• Gajim[65][66]

• irssi[67]
• Miranda IM[68]
• Pidgin
• Vacuum-IM (плагин)[69]
• Kopete
• Tkabber (плагин)[70]

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