В Signal появилась функция «автоматическая проверка ключей», которая дополняет существующую систему номеров безопасности. В Signal всегда используется сквозное шифрование, а автоматическая проверка ключей предоставляет дополнительный, оптимизированный способ убедиться, что между вами и другим «концом» сеанса со сквозным шифрованием нет посторонних лиц.
Она работает через систему проверок, выполняемых вами, вашими контактами в Signal и сторонними аудиторами, которые вместе обеспечивают ту же уверенность, что и ручная проверка номеров безопасности. В отличие от номеров безопасности, эти проверки выполняются независимо и не требуют личной встречи или использования вторичного канала связи.
Эта система проверок гарантирует, что связь между номером телефона или именем пользователя и его открытым ключом шифрования является глобально согласованной и прозрачной для всех участников экосистемы Signal. Это защищает от сценариев, при которых ключ подменяется без ведома владельца — например, если злоумышленник взломал Signal и связал другой ключ с номером телефона вашего контакта.
Чтобы увидеть эту функцию в действии, перейдите в профиль контакта в Signal, нажмите «Посмотреть номер безопасности» и выберите кнопку «Проверить автоматически» в разделе «Автоматическая проверка ключей». Когда функция доступна и проверка прошла успешно, кнопка отобразит зеленую галочку и надпись «Шифрование проверено». Со временем эта проверка в сочетании с проверками, постоянно выполняемыми вашим контактом в Signal и сторонними аудиторами, обеспечивает согласованность ключа этого контакта во всей экосистеме Signal.
Эта функция построена на концепции, известной как «прозрачность ключей» (key transparency). Мы будем использовать этот термин на протяжении всей оставшейся части статьи, объясняя, почему мы создали систему прозрачности ключей и предоставляя общий обзор того, как она работает.
Введение в открытые и закрытые ключи
Асимметричная криптография позволяет вам отправлять сообщения другу, которые может прочитать только он. Она включает в себя пару математически связанных ключей, называемых открытым и закрытым ключами, которые могут использоваться в различных приложениях, включая отправку и получение сообщений.
Представьте, что у вас есть запирающийся почтовый ящик с прорезью. Ваш открытый ключ — это как адрес вашего почтового ящика: вы можете поделиться им с любым, кто хочет отправить вам письмо. Ваш закрытый ключ — это как ключ от почтового ящика. Только вы владеете им и можете использовать его для чтения сообщений, отправленных вам. Любой может опустить письмо в ваш ящик (зашифровать с помощью вашего открытого ключа), но только вы можете открыть его и прочитать (расшифровать с помощью вашего закрытого ключа). Адрес вашего ящика должен быть общедоступным; вы не сможете получать письма, если никто не знает, куда их отправлять.
Когда вы регистрируетесь в Signal, приложение Signal генерирует для вас пару открытого и закрытого ключей в процессе регистрации1. Закрытый ключ остается на вашем устройстве — только у вас, а не у Signal или кого-либо еще, есть доступ к этому закрытому ключу. Ваш открытый ключ отправляется в Signal, который выступает в качестве центрального каталога для открытых ключей всех пользователей. Когда вы хотите отправить сообщение другому пользователю Signal, вы запрашиваете у Signal открытый ключ вашего контакта и шифруете свое сообщение с помощью ключа, который предоставляет Signal, и вашего закрытого ключа.
Атака «человек посередине» (Mallory in the middle)
Отправка сообщений требует получения открытых ключей получателей, а получение открытых ключей означает доверие центральному каталогу. Теоретически злоумышленник, управляющий каталогом, мог бы осуществить атаку, называемую «Mallory in the middle» (Мэлори посередине), хотя для этого потребовалось бы, чтобы посторонний обошел безопасность крупных облачных провайдеров или привилегированный инсайдер намеренно нацелился на конкретную учетную запись. Но даже несмотря на то, что это очень сложная и маловероятная атака, мы все равно хотим защититься от нее. Мы продолжим использовать аналогию с почтовым ящиком, чтобы проиллюстрировать, как гипотетически работала бы эта атака.
Представьте, что Боб хочет отправить приглашение на кофе своей подруге Алисе, поэтому Боб ищет адрес ее почтового ящика в центральном каталоге. Если каталог каким-то образом скомпрометирован злоумышленником (Мэлори), он может направить Боба к почтовому ящику Мэлори вместо ящика Алисы. Когда Боб отправляет письмо туда, где, по его мнению, находится ящик Алисы, оно на самом деле попадает в ящик Мэлори. Затем Мэлори использует свой собственный ключ от ящика, чтобы забрать сообщение Боба, прочитать его, изменить, если захочет, положить в новый конверт и переслать в ящик Алисы.
В своем изменении Мэлори могла бы, например, изменить местоположение кофейни или время встречи, из-за чего Алиса пришла бы не в то место или не в то время. У Алисы не было бы никаких признаков того, что сообщение было перехвачено или изменено, поэтому ей кажется, что сообщение пришло прямо от Боба. Тем временем Боб будет ждать Алису, которая так и не появится. И даже если бы Мэлори решила не изменять сообщение Боба, сама ее способность прочитать его представляет собой серьезное нарушение конфиденциальности общения.
Недопонимание по поводу кофе — это относительно незначительные последствия, но такого рода атака может нанести гораздо больший вред в других контекстах.
Эта атака работает, потому что Боб никогда не проверял адрес Алисы. Боб просто доверился тому, что ящик, указанный в каталоге, принадлежит ей, что является разумным предположением.
Но если бы Боб хотел быть особенно осторожным, он мог бы спросить адрес у Алисы напрямую, либо во время личной встречи, либо через какой-то вторичный доверенный канал связи2, что может быть невозможно, если Алиса и Боб — только переписывающиеся друзья.
Итак, как Боб может проверить адрес Алисы, если он не может встретиться с ней лично или использовать вторичный канал?
В оставшейся части этой статьи мы расскажем, как мы разработали систему, которая позволяет Бобу автоматически проверять данные в центральном каталоге без необходимости напрямую общаться с Алисой.
Аналогия для проектирования системы прозрачности ключей
Один из способов помочь Бобу убедиться, что в каталоге указан правильный адрес Алисы, — это вести запись каждого изменения, когда-либо внесенного в каталог. Если кто-то изменит адрес Алисы в каталоге, это будет зафиксировано в этом хронологическом журнале и, следовательно, будет обнаружено. Чтобы сделать это наглядным, давайте расширим аналогию с почтовым ящиком.
Допустим, клерк записывает изменения адресов всех людей в публичной бухгалтерской книге в городском почтовом отделении. Всякий раз, когда кто-то получает новый адрес или обновляет существующий, клерк добавляет новую страницу в конец постоянно растущей книги и записывает там изменение адреса. Клерк делает это перманентным маркером, чтобы после того, как что-то написано, никто не мог вернуться к странице и вырвать ее или изменить ее содержимое. Любой может посетить почтовое отделение и найти адрес в книге, включая свой собственный.
Использование книги
Для любого заданного адреса есть два способа, которыми клиенты почтового отделения могут взаимодействовать с книгой:
- Клиент, такой как Боб, может искать адреса других людей (например, Алисы).
- Клиент, такой как Алиса, может проверить свой собственный адрес, чтобы убедиться, что книга точна.
Чтобы Боб нашел текущий адрес Алисы, ему пришлось бы начать с последней страницы реестра и листать назад по одной странице, пока он не найдет страницу Алисы. Боб начинает с конца реестра и движется в обратном порядке, потому что ему нужен самый актуальный адрес Алисы, а адрес Алисы мог со временем измениться. По мере добавления новых страниц в реестр, это может стать для Боба очень трудоемкой задачей, особенно если Алиса давно не обновляла свой адрес, а в реестре много изменений адресов других людей, которые Бобу приходится просматривать.
Реестр позволяет Алисе убедиться, что ее собственный адрес указан правильно, но для этого ей приходится просматривать все новые страницы, появившиеся с момента ее последнего визита, и проверять, что в них нет ошибок в ее адресе. Как и в случае с Бобом, это становится очень трудоемким процессом по мере добавления новых страниц в реестр.
Если Алиса и Боб живут в оживленном городе, где люди часто меняют адреса, им обоим пришлось бы проделать непомерно большую работу, чтобы пользоваться реестром, листая его по одной странице за раз. Нам нужен более эффективный способ взаимодействия Алисы и Боба с реестром.
Представляем индексные книги
В реальной жизни книги часто содержат алфавитный указатель, который позволяет читателям быстро находить то, что они ищут. Мы можем применить ту же идею к нашему реестру, введя алфавитный указатель (индексную книгу) по именам всех людей, чьи адреса были включены в реестр на данный момент.
По мере добавления новых страниц в реестр для отражения новых адресов или их изменений, индексная книга также должна обновляться. Поэтому клерк публикует новую копию индексной книги каждый раз, когда добавляет страницу в реестр, включая в нее список людей, чьи адреса были внесены в реестр по состоянию на эту страницу. Это создает огромную библиотеку всех прошлых индексных книг, доступных общественности.
Пока что предположим, что Алиса и Боб всегда смотрят на одну и ту же индексную книгу для любой конкретной страницы реестра. В следующем разделе мы обсудим другой компонент системы, который позволит Алисе и Бобу проверить это предположение.
Благодаря такой структуре Боб теперь может легче находить адрес Алисы в реестре с помощью стратегии «бинарного поиска», которую лучше всего проиллюстрировать на конкретном примере.
Допустим, за определенный период времени появилось 100 новых или обновленных адресов, поэтому в реестре 100 страниц, а клерк опубликовал 100 различных изданий индексной книги. Для простоты скажем, что адрес Алисы появляется в реестре только один раз, когда она впервые переехала в город.
Боб начинает с того, что открывает середину реестра. Затем он проверяет индексную книгу, связанную с этой страницей. Индексная книга отсортирована по алфавиту, поэтому найти имя человека легко. Если имя Алисы есть в этой индексной книге, то это либо первое издание индексной книги, содержащее запись об Алисе, либо ее первое появление находится в более раннем издании и, следовательно, на более ранней странице реестра.
В любом случае Боб может игнорировать вторую половину реестра и повторять процесс с первой половиной, пока не найдет ту самую страницу реестра, где произошло изменение адреса Алисы. В частности, поиск Боба завершится, когда он найдет две соседние индексные книги, где в первой нет адреса Алисы, а во второй он есть.
Этот процесс поиска имеет несколько преимуществ, первое из которых — эффективность. В реестре из миллиарда страниц вместо того, чтобы листать назад (в худшем случае) через все миллиард страниц, Бобу нужно изучить максимум 30 различных страниц, чтобы найти адрес Алисы. Работа Боба теперь намного проще, чем раньше.
Алиса по-прежнему хочет быть уверенной, что клерк никогда не добавит новые страницы с неверным адресом. Однако Алисе не нужно проверять каждую страницу реестра и индексную книгу. Ей достаточно проверить те же самые, которые просматривал Боб при поиске ее адреса, что гарантирует, что адрес, который нашел Боб, был подтвержден самой Алисой.
Это подводит нас ко второму преимуществу процесса поиска: он детерминирован, когда Алиса и Боб смотрят на реестр с одинаковым количеством страниц. Все становится сложнее, если клерк добавляет новые страницы между поисками Боба и Алисы, но основная идея остается прежней. В реестре из миллиарда страниц Алиса может следовать тому же процессу поиска, что и Боб, проверять те же страницы, что и Боб, и убедиться, что ни одна из них не содержит неверной информации о ее адресе.
Договорившись о процессе поиска по реестру, Алиса и Боб установили способ взаимодействия с ним, который позволяет им практически достичь своих целей. По мере роста реестра у Боба появляется эффективный способ найти адрес Алисы, а у Алисы — эффективный способ убедиться, что найденный Бобом адрес точен.
Эта аналогия упрощена для ясности. На практике Алиса может обновлять свой адрес несколько раз, и поддержка такого поиска требует хранения в индексных книгах большего объема данных, чем просто имена. Мы создали сервер прозрачности ключей с открытым исходным кодом, который применяет эти же идеи к обмену сообщениями в Signal.
А как насчет клерка?
До сих пор мы описывали процесс поиска так, будто Алиса и Боб лично листают страницы реестра и проверяют индексные книги. На практике это нереалистично, так как реестр и индексные книги слишком велики, чтобы Алиса или Боб могли работать с ними напрямую. Вместо этого Алиса и Боб просят клерка выполнить поиск от их имени и сообщить результаты.
Но почтовое отделение может быть скомпрометировано злоумышленником, таким как Мэллори, которая выдает себя за клерка и хочет обманом заставить Боба думать, что адрес Алисы — это на самом деле дом Мэллори. В результате Алиса и Боб не могут просто доверять клерку; они должны иметь возможность самостоятельно проверять процесс поиска.
Для этого они просят клерка вернуть все данные с конкретных страниц реестра и индексных книг, которые клерк просматривал во время процесса поиска, и сами перепроверяют результаты.
Перепроверка работает только в том случае, если данным, которые возвращает клерк, можно доверять, что поднимает очевидный вопрос: что, если Мэллори, выдавая себя за клерка, лжет о том, что говорят записи? Например, Мэллори могла бы вести секретный второй реестр, в котором записан неверный адрес Алисы, или публиковать два разных издания индексной книги для одной и той же страницы реестра. Мэллори могла бы предоставить данные из одного представления Алисе, а данные из другого — Бобу, обманом заставив их подтвердить предоставленные данные, не осознавая обмана Мэллори.
Алисе и Бобу нужен независимый свидетель, чтобы клерк оставался честным.
Сторонние аудиторы
Чтобы помешать Мэллори предоставлять разные данные Алисе и Бобу, они полагаются на сторонних аудиторов. Эти аудиторы подобны нотариусам, которые следят за клерком, когда тот добавляет каждую последующую страницу в реестр и публикует соответствующее издание индексной книги.
Они проверяют, что каждое издание книги индексов содержит все те же данные, что и предыдущее, за исключением одной записи, и что клерк не удалил и не изменил тайно какие-либо предыдущие страницы в реестре. Если эти условия соблюдены, аудитор подписывает эту страницу реестра и книгу индексов, подтверждая, что запись была добавлена корректно.
Аудиторы подписывают каждую страницу и книгу индексов только один раз, поэтому, если клерк попытается показать Алисе и Бобу разные версии 50-го издания книги индексов, он сможет предоставить действительную подпись аудитора только для одной из этих версий. Проверяя наличие и подлинность этих подписей аудиторов, Алиса и Боб могут быть уверены, что клерк ведет только один реестр и соответствующий набор книг индексов, и что они видят один и тот же набор записей.
В реализации прозрачности ключей Signal в качестве доверенных сторонних аудиторов выступают Cloudflare и Trail of Bits.
Мониторинг
Сторонние аудиторы гарантируют, что клерк предоставляет Алисе и Бобу один и тот же набор данных, но они не могут проверить точность самих записанных данных. Например, Мэлори может попытаться добавить в реестр страницу с фальшивым изменением адреса Алисы. С точки зрения аудитора, это законное изменение, если Мэлори правильно добавила новую страницу в реестр и опубликовала новое издание книги индексов. Однако, когда Боб будет искать адрес Алисы в реестре, он найдет эту фальшивую запись и поверит, что это настоящий адрес Алисы.
Здесь на помощь приходит мониторинг. Напомним, что у пользователей есть два способа взаимодействия с реестром: поиск чужого адреса и поиск собственного. Мониторинг требует, чтобы Алиса и Боб регулярно выполняли оба этих действия, каждое из которых позволяет обнаружить свой тип вмешательства.
Алиса отслеживает свои данные в реестре, периодически просматривая и проверяя свою последнюю запись об адресе. Если она обнаружит неожиданный адрес, ей следует предупредить Боба по вторичному, доверенному каналу о том, что полученный им адрес недостоверен.
Боб также должен периодически проверять последний адрес Алисы и сверять его с тем, что он получил ранее. Это важно, потому что после вставки фальшивого адреса Мэлори может попытаться замести следы, позже добавив запись, восстанавливающую правильный адрес Алисы.
Важно отметить, что с точки зрения Боба обнаружение другого адреса Алисы выглядит идентично законному изменению адреса, что является гораздо более распространенным объяснением. Тем не менее, ему следует подтвердить у Алисы по вторичному каналу, что она действительно переехала. Если это не так, он должен считать предыдущий адрес недостоверным.
Алиса выполняет самопроверку регулярно, а Боб проверяет реестр по своему собственному графику, поэтому никто из них не гарантирует обнаружение вмешательства Мэлори в тот же момент, когда оно происходит. Но эти два вида мониторинга в сочетании со сторонним аудитом образуют полноценную систему обнаружения: аудит гарантирует, что Алиса и Боб видят одни и те же данные, а мониторинг гарантирует, что оба они регулярно проверяют эти данные на точность. Вместе они обеспечивают своевременное обнаружение вмешательства со стороны Мэлори.
Связь с Signal
Итак, как все это связано с прозрачностью ключей в Signal?
В Signal вы можете выбрать, быть ли доступным по номеру телефона или по имени пользователя, если решите его создать. Если вы решите быть доступным по номеру телефона или имени пользователя, кто-то может ввести ваш номер или имя в Signal, чтобы отправить запрос на переписку. Signal хранит центральный каталог, который в конечном итоге сопоставляет эти публичные идентификаторы с публичным ключом пользователя, точно так же, как «имя» и «адрес» в нашей аналогии с почтовым ящиком.
Когда пользователи Signal регистрируются, меняют номер телефона или имя пользователя, либо воссоздают свою учетную запись, Signal записывает изменения в дерево логов («реестр») и облегчает поиск по дереву логов с помощью префиксных деревьев («книг индексов»). Cloudflare и 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 используют криптографические подписи, которые невозможно легко подделать. ↩