id: Гость   вход   регистрация
текущее время 12:51 28/03/2024
Владелец: 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 Скорее всего, имя для намёка взято от этой персоны.


 
На страницу: 1, 2, 3, 4 След.
Комментарии [скрыть комментарии/форму]
— SATtva (30/09/2013 08:19)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Вы бы стали так делать, если бы генерировали свой ключ не несколько лет назад, а сейчас?

Нет, до принятия новой версии OpenPGP (или его замены чем-нибудь новым) моя паранойя мне спать скорее всего не помешает.

Прям хоть опрос устраивай.

Вперёд! :)
— Гость (30/09/2013 08:31)   <#>

Подтверждайте.
В последнем варианте ответа забыл точку поставить. ☹
— unknown (30/09/2013 15:31)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Раньше большие ключи генерировали пропатченной и пересобранной версией. Если не хватает энтропии в /dev/random, то можете поставить Havege или сборщик энтропии со звуковой карты или веб-камеры. Правда, желательно поинтересоваться всеми очень тонкими подводными камнями относительно совместимости этого с вашим железом.

Что ещё беспокоит, так это то, что шифрование и подпись асимметричными ключами очень чуствительны к реализации режимов дополнений. Если в реализации какой-то баг, то для нестандартных размеров ключей он может не считаться багом и быть невыявленным.
— Гость (30/09/2013 16:13)   <#>

Что такое «режимы дополнений»?
— unknown (30/09/2013 17:31)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Имелись ввиду схемы RSA-padding.
— Гость (30/09/2013 19:01)   <#>
Вот самое обломное – что GPG отваливается при использование ключей нестандартной длины..(((
Когда уже новую версию выпустят...
— SATtva (30/09/2013 20:18)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Новый ключ Майка Перри почему-то же у всех работает, ничего не отваливается. Используйте более сильный клей.
— ressa (30/09/2013 22:16)   профиль/связь   <#>
комментариев: 1079   документов: 58   редакций: 59
SATtva, вероятно, что подразумевалось под "отваливается" – не сам GPG, а какие-нибудь мобильные почтовые клиенты. По себе знаю, что APG и k9-mail не поддерживает "длинные" ключи, а десктопные приложения, такие как Psi Plus, Thunderbird+Enigmail, и прочие – вполне себе справляются. ОСь – Linux.
— SATtva (01/10/2013 07:22, исправлен 01/10/2013 07:23)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118

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

— Гость (01/10/2013 08:50)   <#>
Так SATtva и unknown подтверждают проблему подписывания одних PGP-ключей другими или нет? Я имею в виду, что подпись целиком опирается на 16-ричные keyid'ы, а не на полные 40-символьные отпечатки.
— SATtva (01/10/2013 09:01)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
А открыть стандарт почитать? Подписываются не ID и отпечатки, а хэшированный материал ключа + хэшированный UID и ряд констант (см. RFC4880, раздел 5.2.4). Что там выводит GnuPG, никакого отношения к порядку выработки подписи не имеет.
— sentaus (01/10/2013 10:43)   профиль/связь   <#>
комментариев: 1060   документов: 16   редакций: 32
Openpgp, кстати, не определяет допустимую длину ключа, это оставлено на совести реализующего.
— SATtva (01/10/2013 10:49)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
В принципе, падение на каких-то длинах ключей можно рассматривать как нарушение стандарта. :)
— Гость (01/10/2013 12:49)   <#>

По-моему, вы не поняли вопрос. Он состоял в не в том, как подписывается, а в том, каков индентификатор подписывающего. Вопрос не в том, откуда берётся отпечаток ключа (40 цифр), а в том, что при формировании подписи на чужом ключе посторонний идентифицирует подпись только по 16-ричному keyid'у. Если атакующий может полностью подделать 16-ричный keyid, он может фактически полностью подделать подпись.

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

Если неправ, то скажите, в каком месте.
— SATtva (01/10/2013 13:08)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
По-моему, вы не поняли вопрос.

Так формулируете. :Р

Похоже, gpg действительно не позволяет вывести отпечатки ключей подписи с --list-sigs. Поводов для опасений я не вижу, поскольку это всего лишь ограничение при выводе списка. Формирование цепочек доверия всё равно производится по полным отпечаткам, а основывать своё доверие к ключу только на основе списка подписей будет для пользователя очень недальновидным. В Вашем примере, скачанный ключ получит флаг достоверности, только если реальный ключ 0x1234567890ABCDEF подписан мной, и владельцу доверено заверять другие ключи; если это не сделано, то скачанный ключ в любом случае не будет признан достоверным, независимо от наличия ключа противника на моей связке — ему же я такую функцию не доверял.
На страницу: 1, 2, 3, 4 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3