id: Гость   вход   регистрация
текущее время 13:58 27/02/2020
Владелец: 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 След.
Комментарии [скрыть комментарии/форму]
— Гость (29/09/2013 20:32)   <#>

Завтра в заголовке от wired: "FBI призналось в контроле за PGP ключами"
Послезавтра в заголовке от цэнюз: "Спецслужбы контролируют переписку PGP".
— Гость (29/09/2013 22:22, исправлен 29/09/2013 22:36)   <#>
Завтра в заголовке от wired: "FBI призналось в контроле за PGP ключами"
Послезавтра в заголовке от цэнюз: "Спецслужбы контролируют переписку PGP".

Такая вероятность есть, специалисты это понимают и решено, что для официальных целей шифровать можно только ГОСТом.

— unknown (29/09/2013 23:49)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
2 SATtva и spinore: спасибо за правки и виртуозную работу с разметкой :)
— Гость (30/09/2013 02:20)   <#>

Про новость



Ну вы досокращались! Вычисление доверяемого пути вычисляет доверяемый путь, само по себе это отношение к чтению переписки не имеет. Читаем оригинал:

Edward's GPG client then computes a fully trusted path from Bruce to Roger to the fake Glenn, and Edward then sends an encrypted email to fake Glenn that is then subsequently read by the network systems administrator.

Т.е. «…и затем Эдвард посылает зашифрованное сообщение Глену, которое, соответственно, читаемо (расшифровываемо) системным администратором».

Так-то Майк правильно говорит, что сеть доверия не апскейлится на слепое доверие. Неслепое доверие — это то, при котором доверяешь подписям только тех людей, которых знаешь лично, и у которых спрашиваешь, подписывали ли они тот или иной ключ. Если подписывали, то пусть вышлют правильный отпечаток.


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

Мне кажется, Майк видит в PGP-сети некий уязвимый аналог Tor-сети, оттуда и речь про «заверение статистики» (заверение всей сети доверия) и т.д., но идея-то в том, что сеть доверия принципиально распределённая, и здесь не может быть никакой стороны, заверяющей связи между ключами, тут сама модель доверия другая. Т.е. если сеть доверия и есть аналог какой-то анонимной сети, то только той, которая полностью распределённая, и в которой отсутствуют довлеющие над всем ключи подписи статистики, а доверие при этом выставляется по каким-то другим механизмам. Может быть, это скорее аналог F2F-сети типа Freenet (на новых версиях её протокола).

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

Про проверку ключа


Ну, и раз тема про смену ключа, то про сам ключ:
gpg> list
 
pub  8192R/683686CC  created: 2013-09-11  expires: never       usage: SC  
                     trust: unknown       validity: undefined
sub  4096R/0E3A92E4  created: 2013-09-11  expires: 2014-09-11  usage: S   
sub  4096R/BC40FFA0  created: 2013-09-11  expires: 2014-09-11  usage: E   
[  undef ] (1). Mike Perry (Regular use key) <mikeperry@torproject.org>
Почему он сделал главный ключ SC, а не просто C? Не могу сходу придумать реалистичных сценариев, где главный ключ должен иметь ещё и право подписи данных, а не только ключей. Он хочет создавать подписи, которые будут проверяемы всегда при всех версиях ключа (независимо от того, какие на текущий момент используются подключи)?

Длина в 8192 бит тоже удивила. Кстати, как он это сделал? Включение --expert всё равно не даёт выбрать больше, чем 4096.

Ну, и насчёт проверки ключа:**



Это максимум, который удаётся выжать из GnuPG. Как мне получить полный отпечаток для использованных ключей подписи? Или он физически вообще не хранится в PGP-пакетах? Опция --list-packets тоже показывает только 16 цифр отпечатка, а не все 40. Нетрудно придумать сценарий, при котором противник с достаточными вычислительными ресурсами создаёт ключ, отпечаток которого совпадает с настоящим только в 16-ти последних цифрах, и уже этим ключом проставляет подписи на своих фальшивках.




Спасибо, поржал. ☻


И вам спасибо за перевод. ☺

P.S.:
• Могу ошибаться, но вроде бы есть сокращения PGP и GnuPG (как названия программ), есть pgp и gpg (названия исполнимых файлов), но GPG нету, хотя в оригинале у Майка написано именно так.
• Меня несколько удивляет, почему unknown в сносках внизу текста ставит дополнительный пробел между цифрой сноски и «расшифровкой» сноски. Вроде в книгах я такого нигде не замечал: сноска ставится вплотную к слову как в самом тексте, так и внизу страницы.

**T — это символ того, что к ключу выставлено доверие (trust) этим способом?
— Гость (30/09/2013 02:40)   <#>
Длина в 8192 бит тоже удивила. Кстати, как он это сделал?

Уже несколько лет не является удивительным. Размер ключа задается ручками.
— Гость (30/09/2013 02:45)   <#>

Я в курсе, но никогда не интересовался тем, как это сделать. Если правильно помню, то видел даже ключи длиной 16384 бит, кем-то сгенерированные ради хохмы.


Перед тем, как написать пост, я проверил gpg --expert --gen-key. Команда ругается, если руками задаю для главного RSA-ключа 8192 бит. Может быть, у меня старая версия GnuPG? (1.4.12).
— Гость (30/09/2013 02:56)   <#>

Когда планировалась целенаправленная атака на ключи участников PGPru.com, все эти нюансы обсуждались. Выводы были следующими:
  1. Подобрать 8-значаный keyid (168 = 232) вполне реально (быстро делается на одном ПК).
  2. Полностью подобрать раскраску (12 цифр ⤇ 1612 = 248) уже тяжелее, но, в принципе, тоже реалистично (понадобится кластер). И это будут полноценные ключи, которыми можно шифровать и подписывать.
  3. 16 цифр (1616 = 264) подобрать любительским способом (мощные кластеры, но не на full time, плюс кластеры на видеокартах) уже совсем нереально, это на грани современных возможностей. Однако, если у кого-то есть лишние 2M$ на разработку и 2M$ на производство, можно сделать специальные ASIC'и под эту задачу, и тогда подбор станет реальным (эта задача очень близка к задаче генерации биткоинов). Для АНБ это не деньги.

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

Отдельно стоит отметить то, что поиск коллизий можно вести сразу на всём множестве ключей — на скорость подбора это не влияет. Т.е. противник может загрузить с серверов ключей все ключи к себе и начать бессрочный поиск коллизий: если чей-то ключ совпадает с уже существующим на серверах ключей минимум в n последних цифрах отпечатка, противник его сохраняет и продолжает генерировать ключи дальше. Далее при планировании целенаправленных атак противник будет делать запрос в свою БД на предмет «имеется ли к такому-то ключу коллизия, и если да, то насколько качественная». Если ключ с нужной коллизией есть, он может быть использован в атаках.

Что касается ASIC'ов, оценки следующие: берем за основу лучший из существующих. Cпецификация чипа: технология — 55 нм, производительность — 3 Gh/s, потребление — 0.85-1.6 Вт на 1 Gh/s. Умножаем производительность на 8 (такова примерная разница сложности double sha512 и sha1), получаем 24 гигахэша в секунду на чип, потребление примерно 3Вт. Сами чипы для биткоина под эту задачу не годятся, надо делать новые, но задача крайне близкая. 18446744073709551616/24000000000 = 768614336 секунд брутфорса на одном чипе, т.е. примерно 24 года, причём на это будет затрачено энергии: 768614336 секунд = 213503 часов, умножить на потребление 3Вт ⇒ 640 кВт•ч.

Итак, на одном ASIC-чипе получается 24 года, но такие чипы по одному не выпускаются, и минимальная партия — несколько тысяч штук. Если поделить на размер партии, можно получить, сколько понадобится времени на буртфорс. Энергии при этом потребуется совсем крохи: если учесть неидеальность систем питания (КПД около 60%), то можно умножить в два раза, но это всё равно копейки по сравнению с бюджетом на изготовление железа. Грубо говоря, энергетическая стоимость подбора 16-символьного ID – мВт•час, а по деньгам это доступно для любителей, у которых завалялась пара-тройка лишних мегабаксов, и к так сгенерированным ключам их приватные будут в наличии.

Что касается самого алгоритма брутфорса, 232 вариантов можно подобрать, просто меняя timestamp, а дальше перегенерировать ключ можно быстрым методом с нарушением безопасности, т.е. сами ключи не нужно генерировать заново на каждый шаг. Хэш в PGP берется от такой структуры:
typedef struct _key_block
{
    unsigned char o99;
    unsigned char hiLen;
    unsigned char loLen;
    unsigned char version;
    unsigned long timestamp;
    unsigned char algorithm;
    unsigned char n_bitlength_04;
    unsigned char n_bitlength_00;
    unsigned char n_bits[128];
    unsigned char e_bitlength_00;
    unsigned char e_bitlength_11;
    unsigned char e_bits[3];
} key_block;
Из всех параметров нам в ней доступны для изменения только поля timestamp и n_bits. Ещё можно что-то выжать в плане оптимизации, используя нестандартные E. Генерировать сами ключи на ASIC'е, увы, не получится — только простой брутфорс полей структуры.

Если заморочиться с математикой, то, может быть, можно как-нибудь хитро генерировать число N так, чтобы его кусок можно было бинарно изменять, и чтобы к нему потом можно было вычислить приватный ключ. Думаю, математики могут придумать способ брута N, и на закуску остается возможность брута E, но ключ получится нестандартный (непонятно, как его примут программы). Интересно, что брутфорс N даже перспективнее с точки зрения оптимизации микросхемы, т.к. всегда легче брутфорсить поле, которое ближе к концу, чем к началу. Остальные поля будут фиксированы, брутфорсить их не получится. Ещё стоит отметить, что хоть брутфорс timestamp'а и самое простое решение, ключ получится подозрительным, атакуемый сможет заметить неладное (но можно играть на невнимательности).

Наконец, что касается одновременного подбора коллизий ко многим ID, будет аппаратное ограничение на их количество. В микросхему не запихнуть миллион блоков сравнения, но 20-30 одновременно подбираемых ID — IMHO, разумная величина.
— Беня (30/09/2013 04:29)   <#>
Команда ругается, если руками задаю для главного RSA-ключа 8192 бит. Может быть, у меня старая версия GnuPG? (1.4.12).

Только что проверено на GnuPG 1.4.11

— где EOF вводится через Ctrl+D на юнихах/прыщиках и через Ctrl+Z на виндах.
— Гость (30/09/2013 04:45)   <#>
Беня, вот тебе вальерьянки:



Не буянь так больше.
— Беня (30/09/2013 05:08)   <#>

Сложно быть лаймером? Все вокруг злые и обидеть норовят?
Batch Mode & unattended key generation
Потому идешь в крестовый поход воевать за тупость с невнимательностью?
— Гость (30/09/2013 05:32)   <#>

Как раз невнимателен здесь ты, потому что в man gpg нет ни слова про связь ограничений на длину ключа и batch mode, что я естественно проверил перед тем, как писать ответ:

--batch
--no-batch
Use batch mode. Never ask, do not allow interactive commands. --no-batch disables this option. Note that even with a filename given on the command line, gpg might still need to read from STDIN (in particular if gpg figures that the input is a detached signature and no data file has been specified). Thus if you do not want to feed data via STDIN, you should connect STDIN to ‘/dev/null’.

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


Да-да, и по этой ссылке тоже нет ничего про связь между неинтерактивным способом генерации ключей и возможностью выбора длинных ключей. Откуда, по-твоему, должны о таких недокументированных возможностях узнавать пользователи, из астрала?

Жду от тебя рассказа о том, как повторить трюк в интерактивном режиме работы с gpg, а также рассказа о том, почему в batch эта возможность незабанена, а в интерактиве забанена (даже в expert mode), и в чём здесь логика разработчиков GnuPG. Ты же у нас, как кул-хакер, любишь незадокументированные возможности и считаешь, что все их должны знать, вот расскажи теперь логику этих возможностей.
— Гость (30/09/2013 06:48)   <#>
Ограничение для интерактивного режима (http://git.gnupg.org/cgi-bin/g.....ygen.c;hb=HEAD#l1984 заложено в код)), без исправления и пересборки не избавиться. Это хак в целях сохранения природы, наверно.
— Гость (30/09/2013 07:15)   <#>
А есть ли смысл брать ключи длиннее 4096? Компьютер при их генерации постоянно ругается на недостаток энтропии. Как бы ни случилось так, что из-за недостатка оной 8192-битные ключи окажутся хуже обычных 4096-битных (или моя параноя необоснованная?).
— SATtva (30/09/2013 07:39, исправлен 30/09/2013 07:40)   профиль/связь   <#>
комментариев: 11545   документов: 1036   редакций: 4092
Жду от тебя рассказа о том, как повторить трюк в интерактивном режиме работы с gpg, а также рассказа о том, почему в batch эта возможность незабанена, а в интерактиве забанена (даже в expert mode), и в чём здесь логика разработчиков GnuPG.

Это хак в целях сохранения природы, наверно.

Может быть и просто баг: для unattended ограничение сняли по просьбам трудящихся, для интерактивного экспертного режима — забыли. Напишите багрепорт, сами разработчики это не исправят, если никто об этом не просит.


А есть ли смысл брать ключи длиннее 4096?

Зависит от степени Вашей паранойиинформированности.


Как бы ни случилось так, что из-за недостатка оной 8192-битные ключи окажутся хуже обычных 4096-битных

В какой ОС генерируете? В *nix чтение из /dev/random блокирующее, если энтропии нет, то ничего оттуда и не прочитается.

— Гость (30/09/2013 07:58)   <#>

Linus Debilan Wheezy. Ну, тот хриплый дистр, который страдает одышкой и астмой.


Вы бы стали так делать, если бы генерировали свой ключ не несколько лет назад, а сейчас? Прям хоть опрос устраивай. ☻
На страницу: 1, 2, 3, 4 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3