Представляем автоматическую верификацию ключей

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

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

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

Чтобы опробовать эту функцию, откройте профиль контакта в Signal, выберите пункт «Посмотреть номер безопасности» и нажмите кнопку «Верифицировать автоматически» под заголовком «Автоматическая верификация ключей». Когда функция доступна и верификация проходит успешно, на кнопке появляется зеленая галочка и надпись «Шифрование подтверждено». Со временем эта проверка в сочетании с проверками, непрерывно выполняемыми вашим контактом в Signal и независимыми аудиторами, обеспечивает согласованность ключа этого контакта во всей экосистеме Signal.

Эта функция основана на концепции, известной как «прозрачность ключей». Этот термин мы будем использовать на протяжении остальной части данной публикации, объясняя, почему мы создали систему прозрачности ключей, и давая общее представление о принципах ее работы.

Краткий вводный курс по публичным и приватным ключам

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

Представьте, что у вас есть запертый почтовый ящик с прорезью. Ваш публичный ключ похож на адрес вашего почтового ящика — вы можете поделиться им с любым, кто хочет отправить вам письмо. Ваш приватный ключ похож на ключ от почтового ящика. Он есть только у вас, и вы можете использовать его для чтения отправленных вам сообщений. Любой может опустить письмо в ваш почтовый ящик (зашифровать вашим публичным ключом), но только вы можете открыть его и прочитать (расшифровать вашим приватным ключом). Адрес вашего почтового ящика должен быть общедоступным; вы не сможете получать письма, если никто не знает, куда их отправлять.

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

Атака «злоумышленник посередине» (Mallory in the middle)

Отправка сообщений требует получения публичных ключей получателей, а получение публичных ключей означает опору на центральный каталог. Теоретически злонамеренный оператор каталога мог бы осуществить так называемую атаку «злоумышленник посередине» (Mallory in the middle), хотя для этого постороннему лицу потребовалось бы обойти защиту крупных облачных провайдеров или привилегированному инсайдеру — целенаправленно скомпрометировать конкретную учетную запись. И хотя это очень сложная и маловероятная атака, мы все равно хотим защититься от нее. Мы продолжим использовать аналогию с почтовым ящиком, чтобы проиллюстрировать, как гипотетически работала бы эта атака.

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

Внося изменения, Мэлори может изменить, например, местоположение кофейни или время встречи, в результате чего Алиса придет в неправильное место или в неверное время. У Алисы не будет никаких признаков того, что сообщение было перехвачено или изменено, поэтому ей покажется, что сообщение пришло напрямую от Боба. Тем временем Боб будет напрасно ждать появления Алисы. И даже если бы Мэлори решила не изменять сообщение Боба, сама ее способность прочитать его представляет собой серьезное нарушение конфиденциальности связи.

Путаница с кофе имеет относительно малые ставки, но этот вид атаки может нанести гораздо больший вред в других контекстах.

Эта атака работает потому, что Боб никогда на самом деле не верифицировал адрес Алисы. Боб просто поверил, что почтовый ящик, указанный в каталоге, принадлежит ей, что является вполне разумным предположением.

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

Итак, как Боб может верифицировать адрес Алисы, если он не может встретиться с ней лично или воспользоваться вторичным каналом?

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

Аналогия для проектирования системы прозрачности ключей

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

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

Использование реестра

Для любого заданного адреса у клиентов почтового отделения есть два способа взаимодействия с реестром:

• Клиент, подобный Бобу, может искать адреса других людей (например, Алисы).
• Клиент, подобный Алисе, может найти свой собственный адрес, чтобы убедиться в точности реестра.

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

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

Если Алиса и Боб живут в оживленном городе, где люди часто меняют адреса, им обоим придется проделать непомерный объем работы, чтобы пользоваться книгой, перелистывая ее по одной странице за раз. Нам нужен более эффективный способ взаимодействия Алисы и Боба с бухгалтерской книгой.

Представляем указатели

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

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

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

При такой структуре Боб теперь может гораздо проще искать адрес Алисы в бухгалтерской книге с помощью стратегии «бинарного поиска», лучше всего иллюстрируемой на конкретном примере.

Допустим, за определенный период времени появилось 100 новых или обновленных адресов, поэтому в книге 100 страниц, а клерк опубликовал 100 различных изданий указателя. Для простоты мы будем считать, что адрес Алисы появляется в книге только один раз, когда она только переехала в город.

Боб начинает с того, что открывает книгу посередине. Затем он проверяет указатель, связанный с этой страницей. Указатель отсортирован по алфавиту, поэтому найти нужное имя не составляет труда. Если имя Алисы есть в этом указателе, то это либо первое издание указателя, содержащее запись об Алисе, либо ее первое появление находится в более раннем издании и, следовательно, на более ранней странице книги.

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

Этот процесс поиска имеет несколько преимуществ, первое из которых — его эффективность. В книге с миллиардом страниц вместо того, чтобы (в худшем случае) листать назад все миллиард страниц, Бобу нужно изучить максимум 30 разных страниц, чтобы найти адрес Алисы. Работа Боба теперь стала намного проще, чем раньше.

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

Это подводит нас ко второму преимуществу процесса поиска: он детерминирован, когда Алиса и Боб смотрят на книгу с одинаковым количеством страниц. Все становится сложнее, если клерк добавляет новые страницы между поисками Боба и Алисы, но основная идея остается прежней. В книге с миллиардом страниц Алиса может выполнять тот же процесс поиска, что и Боб, проверять те же страницы, что и он, и гарантировать, что ни одна из них не содержит неверной информации о ее адресе.

Договорившись о процессе поиска по бухгалтерской книге, Алиса и Боб создали способ взаимодействия с ней, который позволяет им практически достигать своих целей. По мере роста книги у Боба появляется эффективный способ найти адрес Алисы, а у Алисы — эффективный способ убедиться, что найденный Бобом адрес является точным.

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

Как насчет клерка?

До сих пор мы описывали процесс поиска так, будто Алиса и Боб лично листают страницы книги и проверяют указатели. На практике это нереалистично, так как книга и указатели слишком велики, чтобы Алиса или Боб могли работать с ними напрямую. Вместо этого Алиса и Боб просят клерка выполнить поиск за них и сообщить результаты.

Но почтовое отделение может быть скомпрометировано злоумышленником вроде Мэлори, которая выдает себя за клерка и хочет в конечном итоге обмануть Боба, заставив его думать, что адрес Алисы — это на самом деле дом Мэлори. В результате Алиса и Боб не могут просто доверять клерку; они должны иметь возможность самостоятельно проверять процесс поиска.

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

Перепроверка работает только в том случае, если данным, возвращаемым клерком, можно доверять, что поднимает очевидный вопрос: что, если Мэлори, притворяясь клерком, лжет о содержании записей? Например, Мэлори может вести секретную вторую бухгалтерскую книгу, в которой записан неверный адрес Алисы, или опубликовать два разных издания указателя для одной и той же страницы книги. Мэлори может предоставить данные из одной версии Алисе, а данные из другой версии — Бобу, обманув их и заставив подтвердить предоставленные данные, не осознавая обмана Мэлори.

Алисе и Бобу нужен независимый свидетель, который заставит клерка быть честным.

Сторонние аудиторы

Чтобы помешать Мэлори предоставлять разные данные Алисе и Бобу, они полагаются на сторонних аудиторов. Эти аудиторы похожи на нотариусов, которые следят за работой клерка, когда тот добавляет каждую новую страницу в книгу и публикует соответствующее издание указателя.

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

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

В реализации прозрачности ключей для Signal Cloudflare и Trail of Bits выступают в качестве независимых сторонних аудиторов.

Мониторинг

Сторонние аудиторы гарантируют, что клерк предоставляет Алисе и Бобу одинаковый набор данных, но они не могут проверить точность записанных данных. Например, Мэлори может попытаться добавить в реестр страницу с поддельным изменением адреса для Алисы. С точки зрения аудитора, это легитимное изменение, если Мэлори правильно добавляет новую страницу реестра и публикует новое издание индексной книги. Однако, когда Боб ищет адрес Алисы в реестре, он находит эту поддельную запись и считает ее настоящим адресом Алисы.

Здесь на помощь приходит мониторинг. Напомним, что у пользователей есть два способа взаимодействия с реестром: поиск чужого адреса и поиск собственного. Мониторинг требует, чтобы Алиса и Боб регулярно выполняли оба этих действия, причем каждый из них обнаруживает свой тип подделки.

Алиса отслеживает свои собственные данные в реестре, периодически выполняя поиск и проверяя свою самую последнюю запись об адресе. Если она обнаруживает непредвиденный адрес, она должна предупредить Боба через второй, доверенный канал о том, что полученный им адрес ненадежен.

Боб также должен периодически искать самый последний адрес Алисы и проверять, совпадает ли он с тем, что он получил ранее. Это важно, поскольку после вставки поддельного изменения адреса Мэлори может попытаться замести следы, позже добавив запись, восстанавливающую правильный адрес Алисы.

Важно отметить, что с точки зрения Боба обнаружение другого адреса Алисы выглядит точно так же, как легитимное изменение адреса, что является гораздо более распространенным объяснением. Тем не менее, ему следует подтвердить с Алисой по дополнительному каналу, действительно ли она переехала. Если нет, ему следует считать предыдущий адрес ненадежным.

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

Возвращаясь к Signal

Итак, как все это связано с прозрачностью ключей в Signal?

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

Когда пользователи Signal регистрируются, меняют номер телефона или имя пользователя либо пересоздают свою учетную запись, Signal фиксирует изменения в дереве журналов («реестре») и упрощает поиск по дереву журналов с помощью префиксных деревьев («индексных книг»). и Trail of Bits выступают в качестве независимых аудиторов этих двух типов деревьев, которые вместе формируют журнал прозрачности ключей.

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

Ваше приложение Signal автоматически и периодически проверяет ваши собственные публичные идентификаторы в этом журнале, но для проверки идентификаторов контактов необходимо запустить процесс на экране «Просмотр номера безопасности». Все запросы на поиск идентификаторов в журнале не проходят аутентификацию, поэтому они не привязаны к конкретной учетной записи пользователя.

Хотя в этой публикации мы не будем вдаваться в детали реализации, заинтересованные читатели могут найти их в нашем репозитории с открытым исходным кодом, который создан на основе раннего черновика протокола прозрачности ключей IETF и содержит доработки под сценарии использования Signal.

Прозрачность ключей на практике сегодня

Прозрачность ключей означает, что все устройства в экосистеме Signal разделяют единое представление о связи между идентификатором и его публичным ключом шифрования. Это не подтверждает личность пользователя, которому принадлежит определенный номер телефона или имя пользователя. Конкретно это означает, что Алиса и Боб могут выполнять проверки прозрачности ключей, чтобы убедиться в наличии у каждого из них правильного публичного ключа для заданной учетной записи, но для выявления ситуации, когда Мэлори полностью захватила учетную запись Алисы, по-прежнему необходима дополнительная проверка (например, обратная связь после изменения номера безопасности).

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

Вероятно, у вас есть номер телефона вашего контакта в Signal, если выполняется любое из следующих условий:

• Вы начали чат в Signal с этим человеком, используя параметр «Найти по номеру телефона».
• Контакт этого человека сохранен в адресной книге вашего телефона (и он разрешил находить себя по номеру телефона в Signal).
• Ваш контакт выбрал параметр, позволяющий всем видеть его номер телефона в Signal (по умолчанию его не видит никто).

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

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

В качестве меры по умолчанию, ориентированной на конфиденциальность, мы делаем автоматическую верификацию ключей недоступной во всех этих случаях и рекомендуем пользователям использовать существующую систему номеров безопасности, которая позволяет пользователям вручную проверять, что они используют один и тот же набор ключей шифрования с определенным контактом, путем сканирования QR-кода или сравнения длинного проверочного номера. Пользователи, которые предпочитают не полагаться на какие-либо сторонние организации, включая Signal и аудиторов, могут отключить функцию автоматической верификации ключей в настройках через «Конфиденциальность» > «Дополнительно» > «Автоматическая верификация ключей» и продолжить использовать ручную верификацию номеров безопасности.

Заключение

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

Эта работа представляет собой значительное сотрудничество внутри Signal и за его пределами, и мы особенно благодарны Cloudflare и Trail of Bits за выполнение роли независимых аудиторов. Мы благодарим их и многих других людей в нашей экосистеме, которые сделали эту работу возможной.

• На практике Signal на самом деле генерирует несколько различных видов пар ключей и производных ключей, которые работают вместе как часть протокола Signal, а не полагается на одну единственную пару открытого/закрытого ключей. ↩

На практике Signal на самом деле генерирует несколько различных видов пар ключей и производных ключей, которые работают вместе как часть протокола Signal, а не полагается на одну единственную пару открытого/закрытого ключей. ↩

• На платформе Signal это аналогично нашей существующей функции «Номер безопасности», которая требует личной проверки или сравнения номеров безопасности через вторую доверенную платформу. ↩

На платформе Signal это аналогично нашей существующей функции «Номер безопасности», которая требует личной проверки или сравнения номеров безопасности через вторую доверенную платформу. ↩

• В физическом мире подписи можно легко подделать. Но в системе прозрачности ключей, которую описывает эта аналогия, сторонние аудиторы Signal используют криптографические подписи, которые нельзя легко подделать. ↩

В физическом мире подписи можно легко подделать. Но в системе прозрачности ключей, которую описывает эта аналогия, сторонние аудиторы Signal используют криптографические подписи, которые нельзя легко подделать. ↩