Мы знаем email адрес человека и хотим с ним безопасно связаться. Как узнать его публичный OpenPGP ключ?

++ Заранее обменяться ключами

   gpg --import MYKEYID.asc

Самый простой, самый надёжный вариант. Но не всегда практичный и удобный, так как физическая встреча людей далеко не всегда возможна. Узнать/получить можно не обязательно полностью ключ (он относительно больших размеров), но хотя бы его отпечаток чтобы его можно было аутентифицировать получив из сторонних источников.

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

   gpg --armor --output MYKEYID.asc --export MYKEYID

++ Получить ключ через один из множества ключевых серверов (keyserver)

   gpg --keyserver KEYSERVER --recv-keys SOME@BODY.COM

Технически ключевой сервер представляет из себя что-то типа публичного FTP-сервера который умеет импортировать/обрабатывать OpenPGP записи и производить по ним поиск, работает по OpenPGP HTTP Keyserver Protocol (HKP) протоколу. Многие из них синхронизируются между собой автоматически и, загрузив на один, ключ вскоре окажется и на других, но так происходит не всегда.

Проблема тут в том, что никто не обязывает загружать свои ключи на сервера: многие просто не хотят "светить" своей приватной информацией (email адрес, имя связанное с ним). Плюс заранее не известно какой ключевой сервер надо использовать.

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

Поддержка ключевых серверов имеется во множестве OpenPGP клиентов. Отправить ключ на сервер можно так:

   gpg --keyserver KEYSERVER_URL --send-keys MYKEYID

++ Получить ключ через DNS-based Authentication of Named Entities (DANE)

   gpg --auto-key-locate dane --locate-key SOME@BODY.COM

В этом варианте OpenPGP ключ полностью размещается внутри одной DNS записи hash(SOME)._openpgpkey.body.com. Из-за хэширования не утекает настоящее имя "SOME".

DANE требует возможность управления DNS записями и накладывает ограничения на сервер (TCP и EDNS расширения обязательны почти наверняка). Многие пользователи приобретают собственные домены, хотя DNS, почтовые и Web-сервера располагаются у сторонних лиц. Например, можно использовать собственное доменное имя, но почтовые сервера Google, при этом пользуясь DANE без сторонних ключевых серверов и потерь приватности.

DANE поддерживается клиентами не так широко, но его записи можно получить и самостоятельно drill/dig запросами и импортировать результат в OpenPGP программу.

Генерирование DANE CERT записи которую можно вставить в зону DNS делается просто:

   gpg --export --export-options export-dane MYKEYID

++  Получить ключ через Web Key Discovery (WKD)

   gpg --auto-key-locate wkd --locate-key SOME@BODY.COM

WKD протокол пока ещё на стадии утверждения и что-то может поменяться, но его реализация уже имеется в последних версиях GnuPG. Для получения ключа он использует HTTPS инфраструктуру. В данном примере команда приведёт к простому скачиванию бинарного (не Base64) ключа https://body.com/.well-known/openpgp/hu/hash(SOME).

WKD использует HTTPS и может быть более удобен для использования и публикации ключей по сравнению с DNS. В нём нет задержек от кэша DNS, статические файлы проще обновлять чем DNS записи, особенно если это хочется сделать как-то автоматизировано на всём домене для множества пользователей. Однако это ещё одна инфраструктура (кроме DNS) и обязательно работающая по TLS. Получение TLS сертификатов может являться проблемой.

WKD поддерживается пока ещё менее шире чем DANE, но получить ключ с HTTPS сервера можно любым HTTP клиентом и сразу же импортировав в OpenPGP программу.

Узнать хэш-часть до доменного имени под которой необходимо загрузить ключ на HTTPS сервер можно так:

   gpg --list-keys --with-wkd-hash MYKEYID

++ Получить ключ через LDAP

   gpg --auto-key-locate ldap --locate-key SOME@BODY.COM

В этом варианте будет обращение к LDAP серверу ldap://keys.body.com/ и поиском OpenPGP ключа на нём для заданного пользователя. Скорее всего, это имеет смысл для корпоративных решений, где LDAP применяется чаще, чем в масштабах Интернета.

Но у нас пока нет доверия к полученным по HKP (ключевой сервер)/DANE/WKD
ключам. Злоумышленник может иметь контроль над ними, может сделать MitM
атаку. Как проверить целостность и аутентичность полученного ключа?

++ Сравнить отпечаток с тем что вы получили напрямую от человека

Разместить отпечаток на визитке -- плёвое дело. Самый надёжный и простой вариант, но опять же не всегда возможен физический контакт людей.

Узнать отпечаток импортированного ключа можно так:

   gpg --list-keys --with-fingerprint MYKEYID

++ Узнать отпечаток у владельца по сторонним каналам связи

Использовать голосовую и/или видео связь, разные средства коммуникации (IRC, XMPP, PSYC, итд), телефонную связь, обычную почту с принимающей стороной. Компрометация всего и сразу маловероятна, но часто бывает так что ничего кроме собственно самой почты вы не знаете и не имеете никакой информации для аутентификации.

++ Сравнить отпечаток с полученным по PKA

   gpg --auto-key-locate pka --locate-key SOME@BODY.COM

PKA это DNS запись, но в отличии от DANE там размещён только отпечаток ключа, поэтому её можно переслать UDP пакетами, не накладывая особых требований на DNS сервер.

Генерирование PKA записи которую можно вставить в зону DNS делается просто:

   gpg --export --export-options export-pka MYKEYID

++ Желательно использовать DNSSEC и TLS

Записи DANE и PKA желательно аутентифицировать через DNSSEC. Это не даёт гарантий что MitM атака не возможна, но усложняет её. WKD например работает только поверх TLS.

++ Использовать HKP, PKA, DANE, WKD по разным каналам связи

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

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

Для того чтобы иметь хоть какое-то доверие, в OpenPGP используется:

++ Сеть доверия: Web-of-Trust (WoT)

Пользователи могут подписывать публичные ключи друг друга, тем самым, заверяя что аутентифицировали ту или иную информацию в ключе (например увидели паспорт с прописанным в нём именем, смогли отправить/получить электронную почту по указанным в ключе адресам, итд). WoT это граф таких связей основанных на подписях людей.

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

Чем больше подписей он имеет, тем выше вероятность что среди них есть подписи доверяемых вами ключей. Для расширения WoT многие часто проводят, так называемые, [[http://www.cypherpunks.ru/KSP-Chto-takoe.html Key Signing Party]].

Это не даёт полной гарантии доверия: например у вас есть известный и доверяемый ключ системного администратора вашей компании и он захочет устроить MitM атаку -- если у полученного ранее неизвестного вам ключа будет стоять только его подпись, то он успешно её проведёт. GnuPG в WoT находит кратчайший путь доверия -- это даёт потенциально множество точек отказа (MitM). Но в теории ничто не мешает аутентифицировать WoT полностью.

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

++ Модель Trust On First Use (TOFU)

В этой модели все факты успешного использования ключей сохраняются в локальной базе данных. При первом использовании ключа он просто запоминается. Далее каждый факт успешной проверки новой подписи с заданного email адреса сохраняется в БД. Если для известного email адреса будет замечено использование другого ключа, то это повод для предупреждения, возможной MitM атаки.

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

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

Но TOFU можно использовать и совместно c WoT -- как минимум для обнаружения неконсистентности связи используемых ключей и соответствующих email адресов.

Включить режим WoT и TOFU можно опцией: trust-model tofu+pgp.

++ Полностью ручное управление доверием

В этом случае вы не полагаетесь ни на статистику (TOFU), ни на WoT и подписи других людей (их можно вообще вырезать из импортируемых ключей для экономии места на жёстком диске), а просто самостоятельно в вашей локальной ключнице проставляете степень доверия UID-ам ключей. Для лишней безопасности вы можете подписывать доверяемые UID-ы чужих ключей, но делая локальную подпись, которая не попадёт в экспорт.

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

URL:
Обсуждается: http://www.opennet.dev/tips/info/2986.shtml