id: Гость   вход   регистрация
текущее время 10:41 25/11/2017
Владелец: unknown (создано 29/09/2013 19:19), редакция от 29/09/2013 22:48 (автор: spinore) Печать
Категории: софт, pgp, gnupg, openpgp, tor, стандарты
создать
просмотр
редакции
ссылки

Почему сети доверия PGP беспомощны



"Почему сети доверия так беспомощны",
© 2013 Mike Perry.
Перевод © 2013 unknown

В форуме PGPru.com неоднократно поднимались вопросы, касающиеся недостатков сетей доверия OpenPGP. В частности, звучали мнения о необходимости отказаться от их использования и сверять ключи только по отпечаткам из-за ненадёжности этой схемы аутентификации. Помимо этого, участие в сетях доверия приводит к утечке массы метаданных о личности пользователя, социальных связях, круге его текущих контактов, что подрывает его анонимность. Ради этого некоторые пользователи создают анонимные ключи, а также не обмениваются ключами через открыто доступные серверы ключей. Схожие проблемы начали волновать одного из ведущих разработчиков Tor-браузера. Когда Майк Перри сделал объявление о смене своего PGP-ключа, он отметил своё негативное мнение о сетях доверия. Позднее, он дал разъяснение своей позиции по этому вопросу, перевод которого1 имеет смысл привести полностью.



Сети доверия имеют три основные проблемы:


  1. Они приводят к утечке информации.

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

  1. Они содержат множество точек, каждая из которых способна привести к полному краху.

    Поскольку по умолчанию GPG использует кратчайший взвешенный путь установления доверия к ключу и кроме этого ничто не аутентифицирует полный граф сети доверия, то это приводит к тому, что каждый участник прочного набора выступает в роле сертификационного или удостоверяющего центра (Certification Authority — CA), особенно для ключей, которые лишь слабо связаны с прочным набором. Стоит вам скомпрометировать хотя бы один из этих ключей, как вы сможете использовать его для заверения любого ключа на любое выбранное вами имя.

    Чтобы понять в какой мере и почему это является проблемой, пройдёмся по типичному сценария взаимодействия в сети доверия.

    Предположим, существует GPG-пользователь Эдвард2, который хочет отправить шифрованное сообщение журналисту, с которым он никогда не встречался ранее, по поводу злоупотреблений гигантского масштаба, творящихся по месту его работы. Назовём этого журналиста, допустим, Гленн3. Ради нашего примера представим, что было бы, если бы они активно участвовали в сети доверия.

    Эдвард также знает, что системные администраторы с его работы очень изощрённы и перехватывают все его шифрованные коммуникации с целью атаки подмены «человеком посредине» (MITM) и получения таким образом доступа к содержимому сообщений. Эдвард решает загрузить ключ Глена с сервера subkeys.pgp.net и предоставляет gpg-клиенту возможность определить уровень доверия к ключу Глена.

    Но системные администраторы сетей на его рабочем месте4 уже предусмотрели это. На этот случай у них заготовлены скомпрометированные сертификаты HTTPS от центров аутентификации (CA), также как и скомпрометирована некоторая часть высокодоверяемых ключей из сети доверия5. Назовём один из этих GPG-ключей именем Роджер6.

    Теперь, как только Эдвард начинает загружать ключ для связи с Гленом, сисадмины подменяют его на подложный ключ, сгенерированный на лету. Сисадмины также подписывают подложный ключ скомпрометированным ключом Роджера. Они также блокируют загрузку для Эдварда подлинного ключа Глена.

    GPG-клиент Эдварда доверяет некоторым ключам. Он определяет, что один из его доверяемых ключей, с именем Брюс7, имеет полное доверие к ключу Роджера (к его скомпрометированному варианту).

    Затем GPG-клиент Эдварда вычисляет полностью доверяемый путь от Брюса до Роджера и от Роджера до фальшивого Глена, что позволит системному администратору незамедлительно читать всю переписку.

    Для Эдварда игра окончена :/.

    Такой сценарий возможен против произвольных ключей, используя любой из ключей с сильным набором доверия. Эффективно функционируя в режиме единственной точки отказа, такие ключи работают в режиме CA для сети доверия, подрывая её полезность как независимого механизма аутентификации.

  1. Сети доверия плохо масштабируются на сценарий глобальной популяции.

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

Что делать вместо этого?


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


Есть множество способов использования многопутевой аутентификации, не страдающих от недостатков сетей доверия*.


Несколько примеров:


  1. Каждый раз, когда вы загружаете ключ GPG, сделайте несколько контрольных перезагрузок через сеть Tor с разными цепочками этой сети — это поможет вам убедиться, что каждый раз вы получаете одинаковый ключ.
  2. Каждый раз я проверяю подпись на присылаемом мне по почте сообщении. Если сообщение приходит на адрес, который не является моим (например через общедоступные списки почтовой рассылки), то мой почтовый клиент добавляет немного доверия к этому ключу (поскольку каждое новое открыто опубликованное письмо с электронной подписью по факту своей загрузки отражает наблюдаемую картину ключа через потенциально различные сетевые пути, которые должны быть доступны различным людям, включая самого отправителя).
  3. Каждый раз перед тем как я шифрую почту каким-либо ключом, я проверяю на серверах, что ключ для этого адреса не поменялся (в стиле того, как проверяется в SSH/TOFU).
  4. После загрузки ключа я проверяю, что связь между данным ключом и адресом электронной почты не поменялась на множестве серверов ключей, TLS-сертификаты которых заверены независимо и не зашиты непосредственно в исходники самого пакета GPG (многопутевая криптографическая аутентификация в стиле Perspectives/Notary).

* Сеть доверия сама по себе технически позволяет использовать многопутевую аутентификацию, но только в том случае, если вы позаботитесь о том, чтобы все множественные пути обязательно существовали. К сожалению, полностью ничто не аутентифицирует всю сеть доверия, так что её невозможно использовать, чтобы убедиться, что множественные пути к ключу действительно существуют и являются правильными.



Примечания к переводу:


1 "Why the Web of Trust Sucks" в оригинале.
2 Если кто-то ещё не забыл имена этих персонажей, то понятно, на какого Эдварда намекает Майк.
3 Вероятный прототип персонажа для этого примера.
4 Реальный Эдвард не стал бы устраивать переписку со своего рабочего места, но Майк, вероятно, упрощает ситуацию, не уточняя, что работодатель Эдварда может следить за ним повсюду.
5 Не такое уж сильное допущение, если рассматривать модель реалистичного сильного противника.
6 Возможный намёк на другую персону. С учётом того, что все имена и характер их взаимоотношений в этом примере взяты с реальных событий, намёк на компрометацию именно ключа Роджера выглядит несколько вызывающе-ироничным со стороны Майка. Впрочем, как и весь пример в целом.
7 Скорее всего, имя для намёка взято от этой персоны.


 
Много комментариев (47) [показать комментарии/форму]
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3