Надёжная криптография — основа современного интернета. Без криптографии нет безопасной связи, теряется возможность совершения надёжных транзакций в интернете. Мы не можем доверять даже собеседнику, если не установили защищённое соединение.
По мнению Google, в нынешней инфраструктуре публичной криптографии есть серьёзный изъян. Дело в том, что в случае компрометации сервера с ключами пользователям приходится вручную проверять ключи у собеседника. Это крайне неудобно и на практике не работает. Из-за таких сложностей некоторые энтузиасты криптографии вовсе отказываются от PGP — и их вполне можно понять.
Компания Google придумала решение: она предлагает всем задействовать прозрачный механизм поиска открытых ключей Key Transparency.
В чём проблема?
Проблема в том, что сеть доверия PGP для шифрования электронной почты создана более 20 лет назад, и многие пользователи до сих пор не могут или не желают её использовать.
Проблему хорошо описал специалист по криптографии Филиппо Валсорда в своей статье «Я отказался от PGP»:
Я ещё никогда, ни разу, не использовал сеть доверия для валидации публичного ключа. И помните, у меня хорошо связанный ключ. Я не проводил формального исследования, но почти уверен, что каждый, кто использовал PGP для связи со мной, сделал или мог бы сделать (если попросят) одну из следующих вещей:
- вытянул наиболее приглянувшийся ключ с сервера ключей, скорее всего даже не по TLS;
- использует другой ключ, если ответить ему со словами «это мой новый ключ»;
- перешлёт письмо в открытом виде, если попросить его с отговоркой вроде «я в поездке».
Поездки и путешествия особенно враждебны к долговременным ключам, делая невозможным такой тип старта с чистого листа.
Более того, я даже не уверен, что существует злоумышленник, против которого долговременные ключи имеют смысл. Ваш обычный средний враг вероятно не сможет провести MitM-атаку на личные сообщения в твиттере (это означает, что вы можете оппортунистически использовать личные сообщения для обмена отпечатками открытых ключей, всё ещё сохраняя приватность). Моссад сделает моссадовские вещи с вашей машиной, какой бы ключ вы ни использовали.
В конце концов, в наше время я больше забочусь о прямой секретности, возможности отказа и эфемерности, чем о нерушимом доверии. Вы уверены, что можете защищать долговременный ключ вечно? Потому что когда злоумышленник решит сделать вас своей мишенью и добьётся успеха, он получит доступ не только ко всем вашим сообщениям с этого момента, но ко всем прошлым сообщениям тоже.
Наверняка многие согласятся с таким мнением.
Что тут говорить, если сам автор PGP не использует PGP.
От той же проблемы с обменом ключами страдают мессенджеры, программы для файлообмена и системы доставки обновлений программного обеспечения.
Сотрудники подразделения Security and Privacy Engineering компании Google Райан Хёрст (Ryan Hurst) и Гери Белвин (Gary Belvin) пишут в официальном блоге, что одна из задач разработанной системы Key Transparency — сделать систему проще. Создать инфраструктуру, которая позволит даже неэкспертам надёжно использовать криптографические инструменты.
Идея в том, что связь между онлайн-идентификатором человека и его открытыми ключами должна автоматически проверяться и быть доступна для общественной проверки. Пользователь должен видеть все ключи, привязанные к конкретному аккаунту, а любые попытки подмены информации третьей стороной — хакером или государственными органами — должны быть сразу видны. Такая инфраструктура одновременно гарантирует, что отправитель для шифрования сообщения всегда использует те же самые открытые ключи получателя, которые верифицированы и привязаны к его аккаунту.
Key Transparency
«Key Transparency — прозрачный общедоступный каталог, с помощью которого разработчикам будет легко создавать системы любого вида с независимо проверяемым данными аккаунтов, — пишут Райан Хёрст и Гери Белвин. — Его можно использовать в различных сценариях, где данные нужно зашифровать или аутентифицировать. Его можно использовать для разработки понятных пользователю функций безопасности, в то же время с поддержкой важных нужд пользователя, как восстановление аккаунта».
По словам авторов, при разработке Key Transparency они совместили свойства Certificate Transparency и CONIKS.
Google Certificate Transparency — это открытый фреймворк для мониторинга и аудита SSL-сертификатов практически в реальном времени. Если центр сертификации по ошибке или умышленно выдал новые SSL-сертификаты, то они будут быстро обнаружены системой Certificate Transparency. Система также определяет, если центр сертификации выдаёт поддельные сертификаты.
С другой стороны, CONIKS — это система управления ключами для конечных пользователей, так что они могут сохранять защищённые каналы end-to-end шифрования даже в том случае, если к провайдеру или серверу нет доверия. То есть CONIKS хранит ключи шифрования пользователя в таком виде, что они доступны для проверки, а любая замена ключей мгновенно фиксируется.
Key Transparency от Google сочетает в себе свойства Certificate Transparency и CONIKS. Или можно сказать, что это фирменная версия CONIKS от компании Google, сделанная по образцу Certificate Transparency.
Более подробно свойства системы Key Transparency описаны на этой странице. Если описать принцип в двух словах, то два человека при запросе одного и того же открытого ключа для одного и того же аккаунта в одно и то же время должны получать одинаковый результат. Это означает, что в данном случае отсутствует вмешательство третьей стороны, которая подменяет собой этот аккаунт для одного из пользователей (Man in the Middle).
Google реализовала в системе Key Transparency автоматическую проверку такого рода, создав дерево Меркла, в котором вычисляется единый хэш для всей базы данных с аккаунтами пользователей и их публичными ключами, а результирующий хэш распространяется между пользователями.
Структура хэша продумана для эффективного практического использования информации, которая содержится в хэше. Приложения могут быстро проверять, что определённые результаты являются частью хэша. Это показано на иллюстрации ниже.
Хэш дерева Меркла доказывает, что лист А является частью хэша K. Проверка осуществляется путём хэширования листа А и сочетания результирующего хэша Е с промежуточными узлами F и J для вычисления K
Как показано на диаграммах, всё работает довольно просто — и эффективно при этом. Для каждого пользователя в дереве Меркла найдётся лист: узлы пронумерованы от 0 до 2256−1.
Таким образом, когда пользователь проверяет личность получателя перед отправкой сообщения, с помощью системы Key Transparency он может быть уверен, что прямо сейчас открытые ключи получателя соответствуют его аккаунту.
Google предлагает реализовать разработчикам приложений примерно такие сообщения для автоматического обнаружения новых ключей:
Для обновления базы в системе каждые несколько секунд строится новое дерево Меркла и вычисляется новый хэш.
Чтобы исключить подмену данных в Key Transparency, все старые снимки деревьев Меркла пополняют новое дерево Меркла с такой же структурой, как у обычного дерева Меркла в системе Certificate Transparency. Дерево заполняется слева направо, так что в его структуре содержится доказательство, что каждая новая версия является изменённым состоянием предыдущей версии.
В репозитории на Github опубликована инструкция по установке и использованию клиента Key Transparency и запуску кластера Key Transparency.
