id: Гость   вход   регистрация
текущее время 08:56 24/08/2019
Автор темы: gegel, тема открыта 20/11/2013 11:41 Печать
Категории: инфобезопасность, защита email
http://www.pgpru.com/Форум/Криптография/АналогPGPСОбеспечениемОтрицаемостиИНаперёдЗаданнойСекретностиОффлайн
создать
просмотр
ссылки

Аналог PGP с обеспечением отрицаемости и наперёд заданной секретности оффлайн?


Обсуждение в соседней теме натолкнуло на мысль: существует ли решение, аналогичное PGP и обеспечивающее для оффлайн-сообщений конфиденциальность и аутентификацию, но плюс отрицаемость и наперед заданную секретность (PFS), ну, и, желательно, тихое уведомление о прессинге. Нашел похожий вопрос на crypto.stackexchange: похоже, что готовых решений пока нет. Возможно, где-то на pgpru это уже обсуждалось, или что-то уже появилось?



 
На страницу: 1, 2, 3, 4, 5, ... , 16, 17, 18, 19, 20 След.
Комментарии
— SATtva (24/11/2013 13:44)   профиль/связь   <#>
комментариев: 11543   документов: 1036   редакций: 4090
Если использовать OpenPGP только для транспорта, то PFS можно надстроить в виде собственного легковесного механизма управления симметричными ключами (примерно как предлагалось выше: путём отправки собеседнику в каждом сообщении нескольких новых ключей или путём их выработки по KDF из даты и ранее согласованного краткосрочного секрета). Стандарт изначально разрабатывался низкоуровневым без привязки к конкретным приложениям, и авторы закладывали в него достаточную гибкость, чтобы при желании реализовывать в том числе и подобные схемы.
— gegel (24/11/2013 14:52)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
Короче, gegel, спасибо за свежий взгляд.


Если честно, я в этом пока ни черта не понимаю, поэтому могу позволить себе незаангажированно пофантазировать, если, конечно, это никого не напрягает.

Если у них есть общий секрет, то шифрование с открытым ключом им не нужно.


Это было вступление.
Теперь предположим, что общего секрета у Алисы и Боба нет, и они могут идентифицироваться друг перед другом и перед третьей стороной только своими публичными ключами, проверяемыми по PKI.
Алиса берет текст публичного ключа Боба, дописывает к нему нейтральную метку (например, версию данного протокола), и подписывает. Подпись будет Y.
Далее, как и выше, Алиса отправляет Бобу PGP-сообщение, содержащее X+Y, где X – определенный текст. Получив сообщение, Боб проверяет подпись Алисы и уверен, что X тоже написано ею. Но доказать это третьей стороне он по прежнему не может: Алиса может опровергнуть, сказав, что посылала Y Бобу ранее в контексте совсем другой беседы.
Примечание:
– честная Алиса должна тот час после отсылки сообщения Бобу удалить Y, если она не хочет, чтобы кто-то позже мог выдать Бобу себя за нее.
– честный Боб должен тот час после проверки подписи удалить Y, если он не хочет, чтобы кто-то позже мог представиться ему Алисой.
– но каждый из них может сжульничать, и это недоказуемо.

Пока верно? Если в принципе да, то продолжу.
— unknown (24/11/2013 15:15, исправлен 24/11/2013 15:17)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

2 SATtva:


Пусть PKA — открытый (публичный) асимметричный ключ стороны A.
SKA — закрытый (секретный) асимметричный ключ.


То что при асимметричном шифровании в нижележащем слое используется симметричное с одноразовым сеансовым ключом для простоты рассматривать не будем.


Сторона A подписывает и шифрует для B пароль: Encrypt_PKB (Sign_SKA (Pass)).


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


Если стороны согласовывают пароль из двух половинок, то схема чуть сильнее, потому что противнику нужно получить закрытые ключи с обеих сторон, чтобы восстановить начальные кратковременные ключи во всех перехваченных сеансах связи. Но всё равно — привязка кратковременных симметричных ключей к долговременным асимметричным — слабое место. Для PFS, но не для отрицаемости.


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


Полноценное PFS требует удаления всего использованного для шифрования ключевого материала.

— SATtva (24/11/2013 15:23)   профиль/связь   <#>
комментариев: 11543   документов: 1036   редакций: 4090

Не выйдет: с ЭЦП выползает такая прекрасная вещь, как метки времени, ломающие отрицаемость беседы. Боб может доказать, что получил сообщение от Алисы, если та специально не подделывала время (а это в общем случае не так). Опять же, зачем эти сложности с открытыми ключами? unknown же выше уже привёл протокол в общем виде. Короче, не совсем понимаю, к чему Вы ведёте.
— SATtva (24/11/2013 15:25)   профиль/связь   <#>
комментариев: 11543   документов: 1036   редакций: 4090
Если им помимо отрицаемости нужно ещё и PFS, то эта исходная шифровка, если будет перехваченной, то она останется зашифрованной долговременными асимметричными ключами, которые могут быть скомпрометированными или которые будут вызывать интерес у противника для выдачи под давлением.

Да, точно, поспешил с ответом.
— unknown (24/11/2013 15:30, исправлен 24/11/2013 15:31)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Алиса берет текст публичного ключа Боба, дописывает к нему нейтральную метку (например, версию данного протокола), и подписывает. Подпись будет Y.
Далее, как и выше, Алиса отправляет Бобу PGP-сообщение, содержащее X+Y, где X – определенный текст. Получив сообщение, Боб проверяет подпись Алисы и уверен, что X тоже написано ею.

Она может сразу выслать ему пароль для симметричного шифрования. в первом же сообщении.



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


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


Но перехватчик Ева знает какие сообщения реально ходили в канале связи, а какие были опубликованы отдельно.


P.S. У меня оказался немного другой взгляд на метки времени.

— SATtva (24/11/2013 15:37)   профиль/связь   <#>
комментариев: 11543   документов: 1036   редакций: 4090
Боб может доказать, что получил сообщение от Алисы, если та специально не подделывала время

Тут имеется в виду раскрытие в прямом эфире, при котором Боб сливает Еве содержимое беседы в её процессе. Даже обычная погрешность часов в несколько минут не позволит Алисе утверждать, что это трафик из какой-то совсем посторонней беседы.
— unknown (24/11/2013 15:45)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
В прямом эфире отрицаемость не даст никакой протокол, даже OTR. Об этом речь, когда говорят о бесполезности судебной отрицаемости: если вовремя поставить экспертов и понятых с видеокамерой и часами за спиной у подконтрольного, сотрудничающего или подставного Боба, то всё что выболтает Алиса, она отрицать не сможет. Алиса может только утверждать, что она расписалась в начале сеанса, а затем связь вели с подставным лицом, а не с ней, но суд скорее поверит в честность экспертов.
— SATtva (24/11/2013 15:51)   профиль/связь   <#>
комментариев: 11543   документов: 1036   редакций: 4090
Нет, такой сценарий я не рассматриваю. Но в более слабом, при котором Боб и Ева удалены друг от друга, и Боб может лишь транслировать ей трафик Алисы (допустим, он перепощивает её сообщения в Твиттер для публичного унижения), использование ЭЦП с метками времени либо только MDC/MAC будет иметь принципиальную разницу в доказательной силе.
— unknown (24/11/2013 20:06)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Небольшая модификация /comment73766.

Из man gpg:
--force-mdc
Force the use of encryption with a modification detection code. This is always used with the newer ciphers (those with a block size greater than 64 bits), or if all of the recipient keys indicate MDC support in their feature flags.


Т.е. mdc будет использоваться по-умолчанию итак практически всегда. В крайнем случае через можно посмотреть подробный выхлоп присланного сообщения и поискать в нём строку mdc_method.

Тогда, первые два пункта не меняются, остальные можно сделать лучше:
  1. Стороны ведут сначала переписку как обычно — неотрицаемо и с подписями.
  2. Затем кто-то решает, что часть вопросов хотелось бы обсудить с возможностью отрицания.
  3. Стороны согласовывают общий секретный пароль для аутентификации. Можно вывести его совместно из двух половинок, чтобы было никому не обидно, но это не обязательно: переслать общий пароль за своей подписью может и кто-то один.
  4. Стороны продолжают обмениваться сообщениями, зашифрованными асимметричным ключом получате{ля,лей} с опцией MDC, но не подписанными. Так что Ева по анализу трафика не заметит, что в их переписке что-то поменялось и они внезапно перешли на отрицаемое шифрование. Аутентифицирующий пароль они кладут в открытый текст письма, который затем шифруется открытым ключом получателя и отправляется без подписи. Стороны следят, чтобы заголовок не стал известен посторонним и следят за ошибками MDC.
— unknown (24/11/2013 20:30, исправлен 24/11/2013 20:32)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

С отрицаемостью вроде как всё хорошо. Даже как-то подозрительно и не верится, что всё так просто оказалось.


PFS можно сделать, высылая внутри OpenPGP сообщений одноразовые асимметричные открытые ключи OpenSSL и уничтожая их закрытую часть после использования. Чтобы шифровать сначала OpenSSL, а затем оборачивать OpenPGP. Правда это уже костыли и подпорки.

— gegel (24/11/2013 20:50, исправлен 24/11/2013 20:52)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
Скорее это схема для недоверяющих (потенциально нечестных друг перед другом сторон). Если третья сторона (Ева) перехватывает их сообщения и знает время отправки...

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


Она может сразу выслать ему пароль для симметричного шифрования. в первом же сообщении.

Без своей подписи? Если подпишет, теряется отрицаемость, если нет – доверие к паролю со стороны Боба. Предполагаем – общего секрета пока нет.


Не выйдет: с ЭЦП выползает такая прекрасная вещь, как метки времени, ломающие отрицаемость беседы.

Вот об этом даже не догадывался. Ну, тогда вместо ЭЦП Алиса может зашифровать текст публичного ключ Боба + версию протокола своим закрытым ключом (надеюсь, в OpenPGP это возможно) и вложить в сообщение: та же подпись, но без меток времени. Она проверяется расшифровкой ее публичным ключом.


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

К этому и веду. Расшарить с отрицанием хочу не симметричный ключ, а аутентификатор для последующих общих секретов DH:


Теперь все точно как и в предыдущий раз, но в начале Алиса генерирует временную пару ключей. X – публичний ключ из этой пары. Также Алиса придумывает случайный тег аутентификации, хеширует и добавляет к первому сообщению его хеш H. Также Алиса берет текст публичного ключа Боба, дописывает к нему нейтральную метку (например, версию данного протокола), и шифрует своим приватным ключем. Результат будет Y. Отправив сообщение, Алиса тот час удаляет Y.


Боб, получив сообщение проверяет Y и, удостоверившись, что оно написано Алисой, удаляет Y, сохраняет H, придумывает свой тег, шифрует его полученным в сообщении временным ключом и отправляет Алисе.


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


Получив его, Боб сверяет хеш тега Алисы и теперь уверен, что этот тег был придуман именно ею.
Алиса и Боб ксорят теги. Теперь у них них есть общий секрет всего за три хопа с использованием PGP при двухсторонней отрицаемости. В дальнейшем он будет использоваться для аутентификации DH-секретов (анти-MitM) с сохранением отрицаемости на случай, если один из участников соберет DH-материал с целью восстановить цепочку и скомпроментировать второго, доказав, что он аутентифицировал текущий общий секрет DH. Необходимости в PGP больше нет.


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

— gegel (24/11/2013 21:07)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
2. Стороны согласовывают общий секретный пароль для аутентификации. Можно вывести его совместно из двух половинок, чтобы было никому не обидно, но это не обязательно: переслать общий пароль за своей подписью может и кто-то один.


Обязательно вывести из половинок, т.к. сторона, назначающая ключ, может в качестве него подсунуть хеш от заявления, удостоверивающего ситуацию, а затем доказать, что другая сторона использовала именно этот ключ. Отрицаемость теряется.
— unknown (24/11/2013 21:10)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Она может сразу выслать ему пароль для симметричного шифрования. в первом же сообщении.
Без своей подписи? Если подпишет, теряется отрицаемость, если нет – доверие к паролю со стороны Боба.

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

Остальную часть вашего поста может быть разберу позднее.
— unknown (24/11/2013 21:15, исправлен 24/11/2013 21:16)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Обязательно вывести из половинок, т.к. сторона, назначающая ключ, может в качестве него подсунуть хеш от заявления, удостоверивающего ситуацию, а затем доказать, что другая сторона использовала именно этот ключ. Отрицаемость теряется.

На страницу: 1, 2, 3, 4, 5, ... , 16, 17, 18, 19, 20 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3