Security for all - #34 - 27 июня 2019

С глазу на глаз - протокол OTR

Сегодня

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

OTR

Repudiation

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

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

Если он захочет рассказать эту информацию кому-то еще, мы не сможем этому помешать. Но даже если он расскажет то, что мы ему поведали, он не сможет доказать правдивость и то, что эта информация исходила именно от нас. Мы можем отказаться от авторства.

PGP и S/MIME

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

Под эти критерии подходят протоколы PGP или S/MIME. Но они используют долгоживущие ключи. Поэтому если в последующем ключ одного или нескольких участников переписки будет скомпрометирован, то часть или даже вся предыдущая переписка может быть расшифрована. Это представляет определенные риски. А свойство, которое в данном случае не выполняется называется forward secrecy или по-русски прямая секретность.

Мессенджеры

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

Одним из протоколов, который позволяет это, является протокол OTR - off the record. “Не для записи”, если переводить дословно, или как мы обычно говорим - не для протокола. В основе лежит достаточно распространенный механизм.

Сессионный ключ

Раз нужно шифровать данные, значит нужен симметричный ключ шифрования, который будут использовать обе стороны. Передавать этот ключ, пусть и в зашифрованном асимметричным алгоритмом виде, по открытому каналу не стоит. Иначе этот ключ, и как следствие зашифрованную им переписку, можно будет расшифровать, если будет скомпрометирован приватный ключ получателя.

Выработать ключ, не передавая его, поможет алгоритм Диффи-Хеллмана, о котором я рассказывал в 19 выпуске (https://stuw.github.io/2018/08/09/19-dh.html). Кратко напомню суть. Стороны договариваются об общем компоненте и каждая генерирует свою секретную часть. Затем каждая из сторон общий компонент смешивает со своей секретной частью и отправляет собеседнику. После смешивания полученной от собеседника информации со своей секретной частью получается секретный ключ. Если обобщить, то окажется, что каждая сторона передает свою приватную часть собеседнику. Но не в открытом виде, а уже объединенную математически с общим компонентом. В результате каждая сторона имеет общий компонент и два секретных - свой и собеседника. Следовательно они могут получить одинаковый ключ.

Цифровая подпись

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

Подпись сообщений - MAC

Хорошо, теперь мы выработали ключ и можем шифровать дальнейшие сообщения. Но тут нас поджидает еще одна проблема - если сообщение будет изменено по пути следования, то мы не сможем этого отследить, потому что само по себе шифрование не предоставляет такой возможности. Чтобы отслеживать целостность сообщений в протоколе OTR применяется подпись сообщений с помощью кодов аутентификации - MAC, Message Authentication Codes. Для формирования кодов также нужен ключ. Использовать один ключ и для шифрования, и для кодов аутентификации не очень хорошо. Поэтому в рассматриваемом протоколе ключ аутентификации получается из ключа шифрования применением хеш функции - это позволит во-первых иметь разные ключи, а во-вторых, если потом ключ подписи сделать доступным, то это не скомпрометирует ключ шифрования. Ведь функция хеширования односторонняя и не позволит восстановить исходные данные, зная значение хеша.

Ротация ключей

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

У ключей симметричного шифрования есть время жизни. Чем дольше живет ключ, тем тем большее количество сообщений можно будет расшифровать при его компрометации. Следовательно менять его нужно как можно чаще.

Чтобы это реализовать, в протоколе OTR каждая сторона сразу генерирует новую секретную часть для алгоритма Диффи-Хеллмана, смешивает с общим компонентом и отправляет вместе с сообщением собеседнику. Отправляемое сообщение будет зашифровано и подписано с помощью первоначально выработанного ключа.

После отправки первого сообщения у вас есть два ключа шифрования: первый состоит из публичной части собеседника и изначально сгенеренного вами компонента второй - из публичной части собеседника и вашего нового компонента

Изначальный ключ забывать пока нельзя - ведь все еще может прийти сообщение от собеседника, который создал его с использованием изначального ключа. Ведь отправить его он мог до того, как получил ваш новый компонент.

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

Постоянная генерация новых секретных компонентов гарантирует постоянную смену ключей шифрования.

Заключение

Давайте кратко повторим схему протокола. В самом начале у сторон имеются публичные ключи друг друга. Эти ключи проверены и им можно доверять.

Далее вырабатывается сессионный ключ по алгоритму Diffie-Hellman’а. На этом этапе сообщения протокола подписываются, чтобы исключить человека посередине (MITM).

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

По мере отправки сообщений вырабатываются новые сессионные ключи шифрования, а старые удаляются.

Протокол OTR позволяет использовать шифрование и аутентификацию сообщений. И при этом не позволяет доказать авторство сообщения третьей стороне.

Ссылки по теме

https://otr.cypherpunks.ca/otr-wpes.pdf

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

До следующего выпуска.