id: Гость   вход   регистрация
текущее время 09:36 22/07/2019
Автор темы: Гость, тема открыта 17/12/2010 17:00 Печать
Категории: анонимность, инфобезопасность, политика
http://www.pgpru.com/Форум/РаботаСGnuPG/GPGВНедружественнойСреде
создать
просмотр
ссылки

GPG в недружественной среде

Здравствуйте!
Вопрос: Имеет ли возможность отправитель данных узнать сессионный ключ в самом банальном случае
gpg -e -r someoneelse somedata
с целью уличить получателя gpg сообщения в нечестности, если он "отказывается" расшифровывать ваше сообщение, под предлогом "испорченности сообщения".
Спасибо!


 
На страницу: 1, 2, 3, 4, 5 След.
Комментарии
— Беня (25/09/2013 21:50)   <#>
Кстати, gpg в жаббе — не самое умное решение. Только если поверх OTR-плагина, т.е. для перестраховки.
— Гость (25/09/2013 23:11)   <#>

Опять начали пафос разводить? Мой обходной манвёр хорош хотя бы тем, что не требует недокументированных костылей. Это можно сделать универсально и достаточно безопасно, а в вашем случае есть, по меньшей мере, тот минус, что трудно получить полное описание чёрного ящика по такому выхлопу. Вот окажется, что в каких-то нетипичных случаях вызов gpg не таков, как думали, и все keyid'ы утекли. Полностью поручиться за безопасность этой схемы можно, только детально проанализировав код джаббер-клиента, а это непросто. В любом случае, как один из вариантов решения проблемы он принимается, спасибо за пояснение.


OTR — это тоже не самое умное решение хотя бы потому, что там
  1. Жёсткая завязка на AES-128, который не поменять даже на AES-256.
  2. Нельзя писать в оффлайн.
  3. Поддержка OTR менее (IMHO) распространена среди jabber-клиентов, чем PGP.
  4. Требуются дополнительные телодвижения по сверке отпечатков. Всё равно на практике доверие, как правило, устанавливается через PGP, и только через него уже — к отпечаткам ключей OTR.
Первые два пункта разруливаются нестандартными велосипедами, но для этого надо писать код и положить орган на несовместимость с другими клиентами. Или у вас есть какие-то другие аргументы? Для PFS в PGP можно время от времени менять подключи шифрования. Это костыль, но он, IMHO, приемлем и с лихвой покрывает те минусы, что озвучены в п.1 и 2. Пункты 3 и 4 — номинально мелочь, упомянуты к слову.
— sentaus (25/09/2013 23:48, исправлен 25/09/2013 23:49)   профиль/связь   <#>
комментариев: 1060   документов: 16   редакций: 32
OTR — это тоже не самое умное решение хотя бы потому, что там

1. Это не столь существенная проблема. Серьёзно, проблема из пункта 2 куда более существенна на практике.
2. Это последствия мер против всяких атак с повторной передачей сообщения. Кстати, openpgp для джаббера не предусмотрено стандартного способа передачи шифрованных+подписанных сообщений. В принципе, очевидный костыль вкручивается легко, только кто ж его сам сделает при реализации XEP?

— Беня (26/09/2013 00:47)   <#>

Да он дерьма не стоит. По сравнению с проксированием вызовов gpg. Вначале для трассировки и принятия решения о том надлежащим ли образом жабба-клиент использует gpg. А потом для автоматизированного парсинга и контроля того, с какими параметрами на самом деле будет шифроваться переписка. Вплоть до корректировки на лету или явного запрета с выкидыванием алерт мессаджа. О том, что жабба-клиент взломан и стал вызывать gpp со странными параметрами.

Модель доверие через PGP гораздо хуже протокола социалиста миллионера в OTR.
Использовать замену подключей вместо настоящего perfect forward secrecy может только идиот с большим самомнением. Не говоря уже о том, что при регулярной замене подключей вообще не должно быть никакой суеты вокруг throw-keyids при использовании gpg в жабба-клиентах. Если охота анонимности от владельцев жабба-сервака, то и надо использовать pgp-ключи сгенеренные специально для использования в жаббе. Либо вообще юзать gpg/pgp-шифрование внутри OTR-сессии.

Развели от нехрен делать демагогию, как и с неубиваемыми визитками.
— SATtva (26/09/2013 07:22)   профиль/связь   <#>
комментариев: 11543   документов: 1036   редакций: 4088
Чуваки, давайте-ка без перехода на личности.

Для PFS в PGP можно время от времени менять подключи шифрования.

Подключи в OpenPGP не дают свойства PFS. Разве что передавать ключ получателю, минуя сервер ключей, и требовать, чтобы он удалял старые подключи со связки (причём безопасным образом). В общем, забудьте.
— Гость (26/09/2013 09:42)   <#>
Подключи в OpenPGP не дают свойства PFS
А разве нельзя удалить у себя secret key к старому подключу? Тогда получится PFS.
— SATtva (26/09/2013 09:49)   профиль/связь   <#>
комментариев: 11543   документов: 1036   редакций: 4088
Можно (с аналогичными требованиями к процедуре удаления), но и корреспондент должен делать то же самое со своим ключом, у вас ведь с ним не односторонняя связь.
— sentaus (26/09/2013 11:12)   профиль/связь   <#>
комментариев: 1060   документов: 16   редакций: 32
Да и желательно будет делать всю эту процедуру перед каждым новым сеансом, и в результате опять писать в оффлайн нельзя, иначе хотя бы одно сообщение будет со старым ключом. В общем сложно это все, и думать много надо на каждом шагу.
— Гость (27/09/2013 06:25)   <#>

В свете новостей от АНБ я бы не был столь категоричен, но да, большинство считает именно так, как вы написали.


А что, в OTR сообщения подписываются и есть защита от переотправок? Не слышал о таком. В любом случае, я не вижу связи между возможностью писать в оффлайн и атаками с повторной передачей сообщений (разве что защита от последних реализована такими кривыми костылями, что затрагивает первое?).


Разработчики tkabber, вестимо. Им плевать на XEP. SATtva подтверждает.


Беня, gyhsal, Рус и Славянин — одно лицо? До их прихода тут никто не ставил точки от балды:
<> не стоит. По сравнению с <>. Вначале для <>. А потом <>. Вплоть до <> мессаджа. О том, что <>.»
в то время как правильный вариант:
не стоит по сравнению с <> вначале для <>, а потом <> вплоть до <> мессаджа о том, что <>.
B все до одного — фанаты винды. Совпадение? :)

То, о чём вы пишете, это, конечно, прекрасно, но это другая, более серьёзная модель защиты. Отвечать этим на моё — это как на вопрос о проверке уязвимостей в коде отвечать «А ты компилятор проверил? Вдруг в нём баги, Проверка кода на ошибки дерьма не стоит, надо проверять компилятор».

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

С грязными хаками в коде я уже однажды напарывался на проблемы, когда хотел отключить информацию о типе и версии jabber-клиента. Один добрый хакер поглядел код, сказал, какие строчки в нём поправить, я ему поверил, исправил и перекомпилил. До поры до времени всё было хорошо, на request version jabber-клиент действительно молчал как рыба, но потом ВНЕЗАПНО выяснилось (а могло бы и не выясниться, сойдись звёзды по-другому), что при коннекте (выходе из offline в online) jabber-клиент всё-таки рассылает информацию о том, кто он есть. И абоненты того же Psi, если наведут мышкой на ростер, эту информацию (по крайней мере, в некоторых случаях) отчётливо увидят после первого коннекта. В общем, кулхацкерство без понимания — это очень плохо. Умение «читать код» (чем тут многие кичатся) без понимания всей системы, протокола, архитктуры программы и связи между её компонентами не даёт ровным счётом почти ничего. Очень велика вероятность сделать своими правками только ещё хуже.


It is often used as a cryptographic protocol that allows two parties to verify the identity of the remote party through the use of a shared secret, avoiding a man-in-the-middle attack without the inconvenience of manually comparing public key fingerprints through an outside channel. In effect a relatively weak password/passphrase in natural language can be used.

Для отрицаемости в смысле OTR оно, конечно, лучше, но вообще это настолько разные звери, что их сравнивнение не очень осмысленно. Идея PGP в том, что у вас есть один ключ для всех абонентов и, более того, он публично известен, при SM же (socialist millionaire) свой предрасшаренный секрет надо иметь для каждой пары абонентов. Кроме того, нет никакой формальной процедуры установления доверия при утере или компрометации секрета, что есть в PGP (при компрометации текущих подключей PGP можно сгенерить новые, пользуясь главным ключом, хранящимся на неподключенных к сети машинах/носителях).


Why not?


throw-keyids — это, конечно, рюшечки поверх остального. Однако, если их можно сделать, и от этого никому не станет хуже, то почему бы не сделать? throw-keyids — скользкий момент хотя бы потому, что скрытие своего ключа определяется настройками gpg вашего абонента, а не вашими. Тем не менее, никто не запрещает создать специальный анонимный PGP-ключ, передать его абонентам по шифрованному каналу, попросив абонентов не выкладывать его на сервера ключей, а потом сверху ещё и включить throw-keyids. И, да, это может ещё и сочетаться со сменой подключей в PGP-связке.


Одно не отменяет другого, как я вам выше написал.


Да, тоже можно, хотя это и не будет полноценным OTR в том смысле, что злонамеренный абонент в этом случае имеет все те же рычаги, что и при голом PGP без OTR.


Какой-то терминологический спор получается. Что конкретно вы понимаете под PFS? Невозможность расшифровать старые сообщения? Это гарантируется тем, что подключи время от времени отзываются, копии их отовсюду удаляются, а на связку добавляются новые подключи. Естественно, в идеале это должны проделывать оба абонента, но если проделывает только один, то это тоже имеет смысл. На все претензии к выдаче ключа шифрования к сообщениям будет стандартный ответ: они были зашифрованы старыми подключами (что, в том числе, подтвердят и логи jabber-сервера), подключи отозваны (если противник получит доступ к PGP-ключу, он сам в этом убедится), а старых копий более нет (в этом его не убедить, конечно, но если сам всё честно стёр так, что восстановить не можешь, то уже не выдашь старые подключи даже под пытками). Конечно, остаётся риск выдачи текущих подключей, но на них будет завязано лишь небольшое количество информации (например, за последнюю неделю или месяц). Выдача текущих подключей в том или ином виде присутствует и в каноническом OTR: если противник перехватит живую сессию, то OTR не спасёт. Разница здесь лишь в том, что одна сессия в OTR — это промежуток непрерывного онлайна (вроде во время сессии OTR не меняет ключи, но могу ошибаться), а в PGP со сменой подключей — время действия подключей. Параллелизм сохраняется в любом случае.

Если же вы под PFS понимаете невозможность доказать авторство (в том смысле, в каком оно есть в OTR), то это тоже решается. Для этого достаточно тотально выпилить подписи из jabber-клиента, воспользовавшись PGP-ключом, который не поддерживает ЭЦП. Лично не тестировал такой способ, но поидее он должен работать. Может быть, jabber-клиент при этом будет ругаться, но если работать продолжит, то, думаю, всё ОК. В любом случае, из-за XEP сообщения в почти всех клиентах не подписывались и ранее, так что ничего не теряем, кроме подписи статусов, но последнее, IMHO — вообще рюшечка, скорей всего, сделанная только для того, чтобы jabber-клиенты могли автоматически распознавать, у кого какой keyid на jid'е, и автоматически выбирать нужный ключ из связки.

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


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


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

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

при первом же следующем выходе абонента в онлайн ключи могли бы меняться на другие [rekeying или как там это в протоколах называется, ротация ключей короче ;)]

Я именно эти аргументы имел ввиду выше во фразе

Первые два пункта разруливаются нестандартными велосипедами, но для этого надо писать код и положить орган на несовместимость с другими клиентами.
— sentaus (27/09/2013 08:00, исправлен 27/09/2013 08:01)   профиль/связь   <#>
комментариев: 1060   документов: 16   редакций: 32
А что, в OTR сообщения подписываются и есть защита от переотправок?

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


Если он всю эту информацию соберёт вместе и выдаст третьему лицу, докажет ли он этим самым, что общался конкретно с тем абонентом, или нет

Вообще нет. MAC может сгенерировать любая сторона.


Разработчики tkabber, вестимо. Им плевать на XEP.

В общем, всё плохо с совместимостью. Примерно как с браузерами во времена IE.


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

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

— Гость (27/09/2013 08:13)   <#>

Понятно.


Хорошо было бы это проверить в реальных имплементациях OTR на реальных jabber-клиентах, а то вдруг не поругаются на переотправку...


Некоторые jabber-клиенты умеют включать одновременно как OTR, так и PGP. Когда-то разбирались, но я в упор не помню, что идёт внутри, а что снаружи при таком нестандарте. Ну, ещё могут всякие неожиданные сюрпризы вылезти в таком «каскаде» — всё-таки протоколы писались не под этот случай, мало ли на что это повиляет... а то как бы ни получилось, что будет хуже, чем каждый из методов (PGP и OTR) по отдельности.
— SATtva (27/09/2013 08:55)   профиль/связь   <#>
комментариев: 11543   документов: 1036   редакций: 4088
Тем не менее, никто не запрещает создать специальный анонимный PGP-ключ, передать его абонентам по шифрованному каналу, попросив абонентов не выкладывать его на сервера ключей, а потом сверху ещё и включить throw-keyids.

Либо вообще юзать gpg/pgp-шифрование внутри OTR-сессии.
Да, тоже можно, хотя это и не будет полноценным OTR в том смысле, что злонамеренный абонент в этом случае имеет все те же рычаги, что и при голом PGP без OTR.

Определитесь с моделью угрозы. Непонятно, входят в неё атаки со стороны корреспондента или нет.

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

Тут, очевидно, от корреспондента требуется не просто следование коммуникационному протоколу, а полное соблюдение операционной безопасности. В зависимости от модели угрозы (а она у Вас, насколько понимаю, очень жёсткая), схема PFS с PGP-ключами получается очень хрупкой, она не выдерживает случайный fuck up со стороны корреспондента или его системы.

Хоть PFS, формально, не требует рилтаймовости, это всё-таки важное свойство. В том же OTR сеансовый ключ вырабатывается сторонами интерактивно (именно по этой причине нельзя писать в оффлайн), хранится только в ОЗУ, параметры не сохраняются. В случае с OpenPGP исходный материал лежит на диске; его можно уничтожить (или изначально размещать в tmpfs), но это уже нетривиальная задача, которую обязаны исполнять оба корреспондента. Если противник сможет восстановить материал удалённых подключей у любого корреспондента, свойство PFS (невозможность ретроактивной расшифровки коммуникаций) рушится как минимум для сообщений одного из корреспондентов. На мой взгляд, такая хрупкость полностью противоречит подразумеваемой модели угрозы, я бы на Вашем месте так не рисковал.

Если же вы под PFS понимаете невозможность доказать авторство (в том смысле, в каком оно есть в OTR), то это тоже решается.

Это уже отрицаемость, а не PFS, такой смысл я не вкладывал.

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

Именно.
— Гость (27/09/2013 11:03)   <#>
OTR глючное какое-то во многих jabber-клиентах. Например, в ответ на команду /otrpolicy default always выдаёт

(process:XXXX): GLib-CRITICAL **: g_hash_table_foreach: assertion `version == hash_table->version' failed

хотя otrpolicy меняется. Если класть OTR поверх PGP, то глюки ещё больше множатся.

Есть ещё проблема первого сообщения:

(default|jid) (plain|manual|opportunistic|always)
Sets either the default policy or the policy for the given jid The plain policy should never be used, because you won’t be able to receive or send any OTR encrypted messages. If you set the policy to manual, you or your chat partner have to start the OTR encryption by hand (e.g. with /otr start). The policy "opportunistic" does that itself by sending a special whitespace-sequence at the end of unencrypted messages. So the other OTR-enabled chat client knows, that you want to use OTR. Note that the first message will always be unencryted, if you use this policy. With the policy "always" no message will be sent in plain text. If you try to sent the first message unencrypted, mcabber will try to establish an OTR channel. Please resend your message, when you get the information that the channel was established. If someone sends you plaintext messages while the policy is set to "always", you’ll be able to read the message but it won’t be saved to the history.
© man mcabber

Вроде бы для always проблемы первого сообщения нет, но всё равно остаётся какое-то чувство неуверенности. И в чём отличие opportunistic от always? Почему во втором случае оно может начать протокол само без посылки нешифрованных сообщений, а в первом нет?

Для работы с оффлайном OTR мог бы иметь отдельный ключ, который бы менялся только во время online-сессий, а шифрование сообщений, посылаемых в online, могло бы происходить так же, как оно работает сейчас.

Ещё один минус OTR — его ключи. Приватный ключ OTR хранится в виде простого текстового нешифрованного файла. Никаких тут пассфраз, аналогов gpg-агента и прочего. Т.е. безопасность OTR-ключа заведомо низкая.
— SATtva (27/09/2013 11:27, исправлен 27/09/2013 11:39)   профиль/связь   <#>
комментариев: 11543   документов: 1036   редакций: 4088
Вроде бы для always проблемы первого сообщения нет, но всё равно остаётся какое-то чувство неуверенности. И в чём отличие opportunistic от always?

По-видимому, в том, что opportunistic даёт сигнал отвечающей стороне инициировать OTR-сессию, если там в клиенте есть поддержка OTR, но если поддержки нет, отвечающая сторона сможет прочитать сообщение; always же принудительно запускает OTR-сессию отправителем: если отвечающая сторона не поддерживает OTR, то прочитать ничего не сможет.


Для работы с оффлайном OTR мог бы иметь отдельный ключ, который бы менялся только во время online-сессий, а шифрование сообщений, посылаемых в online, могло бы происходить так же, как оно работает сейчас.

Посоветуйте это разработчикам OTR. Думаю, они не стали добавлять поддержку оффлайна, чтобы чрезмерно не усложнять протокол.

— Гость (27/09/2013 11:45)   <#>

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


В худшем случае противник получит, допустим, историю сообщений, взятую с диска. Этого часто «достаточно» почти для всего. OTR не запрещает писать историю. Кто-то может историю не писать, другие — стирать её время от времени, но смысл остаётся: этот факт непроверяем для другой стороны.


Естественно, но никто этого не отрицал. С другой стороны, доступ к приватному ключу можно получить, только имея доступ к компьютеру абонента, но имея последний, необходимость что-либо расшифровывать часто пропадает, т.к. есть файлы истории отправленных/полученных сообщений. Если мы вынуждены верить в то, что они вовремя трутся, а не хранятся годами, почему мы не можем поверить в то, что трутся бэкапы старых секретных подключей? В общем, PFS на практике не работает. :-) С юридической отрицаемостью всё совсем плохо, а техническая отрицаемость полагается на непроверяемые аргументы типа «абонент не пишет историю сообщений».


PFS защищает от редкого катастрофического события. Если оно не произлошло, допустим, за минувший год, то нет никакой разницы между тем, когда стороны использовали OTR и и не писали историю, и тем, когда стороны использовали PGP с временными подключами, которые были позже уничтожены, а история потёрта. И то и то — могила для информации. Если атака происходит во время условной «сессии», то да, тут есть некоторые отличия, но опять же... ИБ — оценка рисков. Стоит ли так мучиться со стандартным OTR, если вероятность такого развития событий достаточно мала? Может, целесообразней заменить OTR суррогатом с временными ключами? Вроде как ничего не теряем в функциональности, и в то же время оно «по духу почти PFS», хоть и на других временных масштабах.


Я понимаю, как оно по смыслу, но вопрос в том, почему так. Могло бы быть и иначе: при opportunistic клиенты обмениваются служебными пакетами данных, и если установить канал удаётся, то все сообщения, включая первое, отсылаются только после установления OTR-канала; если же клиенты выясняют, что поддержки OTR одна из сторон не имеет, то они не насилуют друг друга и всё шлют без шифрования (как первое сообщение, так и последующие). В такой схеме opportunistic шифровало бы всё в точности как always (хоть и без подстраховки), если оба клиента умеют OTR, а не так как сейчас.
На страницу: 1, 2, 3, 4, 5 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3