id: Гость   вход   регистрация
текущее время 15:09 28/03/2024
Автор темы: thesis, тема открыта 01/05/2013 16:13 Печать
Категории: криптография, софт, pgp, openpgp, управление ключами, стандарты
https://www.pgpru.com/Форум/ТехническиеВопросы/ПодключиОбъяснитеНаПальцахPls
создать
просмотр
ссылки

Подключи: объясните на пальцах, pls


Я полагал, что понимаю как устроены ключи [open]pgp и каковы принципы работы этой системы.
Секретный ключ S[ecure] – хранимое в тайне и безопасности дополнение ключа P[ublic] открытого.
Связь между S и P – забота владельца.
К ключу P прицеплены всякие реквизиты владельца – имя, емейл, фото и т.п.
Эта связь между Р-ключом и реквизитами утверждается подписью владельца, созданной S-ключом, а подтверждается подписями других людей.


S используется для подписывания и расшифрования, P для шифрования и проверки подписи. Всё наглядно и логично.


Как в эту схему вписываются подключи?


Понятно, что каждый подключ – это все же S-P _пара_ ключей.


_Зачем_ это делается, я в общих чертах понял.
https://www.pgpru.com/chernowi.....mi/podkljuchiopenpgp


А вот дальше всё тонет в тумане непонимая.


Чем определена и подтверждена связь между главным ключом и подключами?


Почему это стало обязательным? PGP версий 9.x вообще не позволяет создать S-P-пару без подключей. Позволяет создать сколько угодно подключей, но не дает возможности выбрать какой именно [под]ключ надо использовать для той или иной операции.



 
На страницу: 1, 2 След.
Комментарии
— SATtva (01/05/2013 19:03)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Чем определена и подтверждена связь между главным ключом и подключами?

Подписями, как и в случае записей сертификата и прочих метаданных типа списка предпочтений.
— thesis (01/05/2013 20:24, исправлен 01/05/2013 20:24)   профиль/связь   <#>
комментариев: 27   документов: 9   редакций: 3

Подписями
Подпись владельца всей этой конструкции, сделанная при помощи главного ключа?

— SATtva (01/05/2013 20:28)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Перекрёстными: главный ключ подписывает подключ, подключ (если это подключ подписи, шифровальных это не касается) подписывает главный ключ. Всё это выполняется автоматически при генерации подключа.
— Гость (01/05/2013 21:37)   <#>
не дает возможности выбрать какой именно [под]ключ надо использовать для той или иной операции.

Опция -u в gpg позволяет выбирать в т.ч. и подключ, о чём по вашей же ссылке и сказано. Про PGP не в курсе.
— thesis (02/05/2013 01:09)   профиль/связь   <#>
комментариев: 27   документов: 9   редакций: 3
Опция -u в gpg позволяет выбирать в т.ч. и подключ, о чём по вашей же ссылке и сказано. Про PGP не в курсе.

Ну, я win-юзер. Почту пишу-читаю иногда через theBat, но как правило через веб-интерфейс. В таких условиях пользоватся gpg с командной строки – это просто какой-то закат Солнца вручную.

PGP desktop версии 9.8 и младше – нет, не позволяет.

Перекрёстными

Что-то такое я и предполагал. Поэтому недоумеваю.

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

Откуда следует, что сами подключи заверены исключительно и только мастер-ключом. Даже если не сразу, то со временем – ведь предлагается подключи делать короткоживущими.

Очевидные недостатки такого решения:
а) нет совместимости со старыми программами (не поддерживающими подключи)
б) _полноценная_ работа с подключами есть (на текущий момент) только в командной строке gpg
в) повышенная сложность в работе
Достоинства описаны в вышеупомянутой статье.

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

Сделать один ключ (S-P пару ключей — это называется сертификат?). Заверить его у разных людей.
Создать себе второй (третий, безднадцатый) сертификат, заверить его первым.
Первый просто экспортировать на флешку, со связки удалить, флешку кинуть в сейф. Доставать обратно только если нужно создать и заверить еще один ключ.
Вторым (третьим и т.п.) ключами пользоваться по своему разумению.
Им можно даже названия дать соответствующие. "Иван Помидоров, ЭЦП для документов ООО <Вектор>" :)

Итог такой же. Мастер-ключ в сейфе. Остальные в работе. Мастер-ключ заверен разными чужими. Остальные заверены мастер-ключом.
Просто, наглядно.

Так чего ради затеяны все эти сложности?
— sentaus (02/05/2013 01:47)   профиль/связь   <#>
комментариев: 1060   документов: 16   редакций: 32
а) нет совместимости со старыми программами (не поддерживающими подключи)

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

Просто, наглядно.

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

Так чего ради затеяны все эти сложности?

Собственно ради эти двух вещей и затеяны: не факт, что главный ключ вообще можно использовать для шифрования и для автоматического подтверждения подлинности подключей при подтверждении подлинности главного.
— thesis (02/05/2013 02:30)   профиль/связь   <#>
комментариев: 27   документов: 9   редакций: 3
Подключи в спецификации обязательны

Вот я и пытаюсь понять – зачем. Если вы понимаете – зачем, то объясните мне, пожалуйста, в подробностях.

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

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

Существующая схема: мастер-ключ + его подключи, заверенные только мастером. Дальний пользователь видит их как единое целое. Пользователь _обязан_ выставить мастер-ключу доверие, иначе он не сможет воспользоваться подключами для зашифрования или проверки подписи.

Гипотетическая схема: мастер-ключ + вторые самостоятельные ключи, заверенные только мастером. Дальний пользователь видит их как разные сущности. Пользователь _обязан_ выставить мастер-ключу доверие, иначе он не сможет воспользоваться вторыми для зашифрования или проверки подписи.

В обоих случаях юзер должен доверять мастер-ключу.

Вы разницу видите? Я – нет.

Ну и шифрование ещё работать не будет, если это будут DSA-ключи

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

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

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

и для автоматического подтверждения подлинности подключей при подтверждении подлинности главного.

А вот это уже "теплее". Но почему? Не понимаю.
— Гость (02/05/2013 03:19)   <#>
Ну, я win-юзер. Почту пишу-читаю иногда через theBat, но как правило через веб-интерфейс. В таких условиях пользоватся gpg с командной строки – это просто какой-то закат Солнца вручную.

Поставьте gpg4win, gpg является его частью. В командной строке каждый раз задавать все опции было бы неудобно, поэтому в Linux люди создают скрипты или алиасы. Равно и в win никто вам не запрещает создать батник, в котором будет запускаться gpg с вам нужными опциями и делать то, что требуется.

Итог такой же. Мастер-ключ в сейфе. Остальные в работе. Мастер-ключ заверен разными чужими. Остальные заверены мастер-ключом.
Просто, наглядно.

Так чего ради затеяны все эти сложности?

Думаю, для удобства. Нужен универсальный способ связывания мастер-ключа с подключами. То, что один ключ подписан другим, ещё ничего не означает. В текущей архитектуре PGP вам придётся лично договариваться с абонентами о том, что значат ваши подписи. Если же делать унифицированную систему связывания мастер-ключа с подключами, они вместе начинают выглядеть, как единый ключ, что удобно. Соответственно, абоненты сразу получают все нужные публичные ключи в связке. Ещё кое-какие идеи извучивались в /comment4784.

В современных версиях gpg и обвязок, его использующих, всё работает прозрачно. Метод примерно такой (могу ошибаться в деталях, но на уровне сути так), делается с целью достижения этого:
  1. Создаёте ключ, причём мастер-ключ с правом только подписи, но не шифрования.
  2. Создаёте один подключ, которым абоненты будут шифровать.
  3. Отдаёте абонентам свою связку публичных ключей.
  4. Делаете копию связки, которой будете пользоваться. Оригинал связки кладёте в сейф, а с его её копии удаляете мастер-ключ совсем.
  5. Абоненты будут вынуждены шифровать всё вашим подключом, т.к. других опций у них нет, а вы будете расшифровывать их сообщения, не пользуясь мастер-ключом вообще.
  6. Время от времени вы меняете подключ на другой (удаляете старый и создаёте новый) и просите своих абонентов обновить ваш ключ. Для этого:
    1. Вы подгружаете мастер-ключ из сейфа в безопасное место, где будет связка, и производите нужные действия.
    2. Вашим абонентам ничего дополнительно сообщать не надо: абоненты загрузят последнюю версию вашего публичного ключа с сервера ключей, и подключ обновится автоматически (потому что адресация идёт по ID мастер-ключа, который не меняется при обновлении).
  7. Во всех современных версиях PGP/gpg всё вышеописанное должно работать, причём автоматически. И, более того, для ваших абонентов всё должно быть прозрачно, т.е. в командную строку не надо будет лезть ни им, ни вам (за исключением вас в редкий момент, когда нужно сменить подключ или сгенерировать исходную пару ключей).

Пару раз [1,2] на форуме менялись ключи приблизительно в соответствии с этим правилом, можете почитать детали.
— sentaus (02/05/2013 12:43)   профиль/связь   <#>
комментариев: 1060   документов: 16   редакций: 32
Существующая схема: мастер-ключ + его подключи, заверенные только мастером. Дальний пользователь видит их как единое целое. Пользователь _обязан_ выставить мастер-ключу доверие,

Нет. Доверие выставлять не нужно. Нужно только подвердить подлинность. А в случае с несколькими ключами нужно и подлинность подтвердить, и доверие выставить. Прочитайте про различие validity(подлинность) и trust(доверие).
— unknown (02/05/2013 20:54)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Вот вы видите в форуме отпечаток ключа некоторых пользователей. Также, вам достаточно распечатать такой отпечаток на визитке, футболке и пр., на встречу пользователей для взаимного подписания придти — это чисто обмен бумажками. Кстати, даже QR-коды не нужны: достаточно распечатать длинный отпечаток, а пользователю набрать в поиске на ключевых сервисах короткую часть, а затем уже сравнить полный отпечаток найденного в поиске с распечатанным на бумажке. Опять же, "консоль рулит" из-за тонкости различия опций --search-keys и --recv-key, которые могут быть криво реализованы в неконсольных интерфейсах.

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

Удобство ещё и в том, что предположим, паранойя перед сильным противником требует регулярной смены ключа (хотя бы раз в год). Вдруг он факторизует RSA и всё расшифрует? Тогда ему надо каждый год уметь взламывать хотя бы по одному ключу. Но можно не менять главный ключ, который только для подписи связки и попытки подмены которого и изменения в связке могут быть заметны (кстати, ещё один довод: все действия над связкой, проведённые главным ключом в ней остаются и публичная часть их всем видна на серверах ключей; даже если противник украдёт главный ключ, ему будет трудно незаметно от владельца устроить изменения в связке, по крайней мере, если пользователи-корресподенты достаточно опытны и внимательны. Или ему придёться быть глобальным активным противником: отслеживать соединения всех корреспондентов через интернет и каждому индивидуально подменять подключи в связке, чтобы никто ничего не заподозрил, что малореально даже для сильного противника). А подключи подписей и шифрования можно менять хоть каждый день.
— thesis (05/05/2013 04:55)   профиль/связь   <#>
комментариев: 27   документов: 9   редакций: 3
Подводя итоги. Я, вроде бы, разобрался. "Несколько независимых ключей" действительно не годятся

Со стороны владельца выглядит, кажется, неплохо

-а-
Создание главного ключа и одного или более дополнительных.
Отдельное хранение закрытой части мастер-ключа.
Внесение изменений в главный ключ.

Любая версия любого ПО. Даже по RFC-1991, если надо.
Никаких фокусов. Очень просто.
И каждый ключ может обладать собственным характерным названием.
Например "для шифрования 2012 год", "для подписи \должность\"


-б-
Применение ключа для расшифрования или подписи.

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

-а-
Первоначальное получение ключа.
Получение [новых] дополнительных ключей.
Проверка подписи

Любой openpgp-совместимый софт.
Абонент должен будет либо поднять trust для главного ключа (что, как уже было отмечено, может быть нежелательно)
либо самому поставить на дополнительных ключах свою подпись (неэкспортируемую).
Не очень хорошо, но в целом приемлемо.


-б-
Шифрование.

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



Кстати, почему gpg2win в командной строке выводит русский (зачем?!) текст в кодировке win-1251, хотя именно для консольных приложений винды нужна CP866 и ничто иное?
Консоль gpg2win выглядит вот так:
— Гость (05/05/2013 05:16)   <#>

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


/comment41107 & /comment48259
— thesis (05/05/2013 06:35, исправлен 05/05/2013 06:36)   профиль/связь   <#>
комментариев: 27   документов: 9   редакций: 3
Создаёте ключ, причём мастер-ключ с правом только подписи, но не шифрования.

Я имел в виду:

Любая версия любого ПО. Даже по RFC-1991, если надо.

comment41107 & /comment48259

Хорошо, спасибо.

— Гость (05/05/2013 07:12)   <#>

Если что, время от времени здесь появлялись жалующиеся на то, что создали ключ, а зашифровать им не могут. Гуй каких-то утилит легко (и чуть ли не по умолчанию) давал им создавать ключи, не предназначенные для шифрования (а только для подписи).
— MONOmah (17/07/2013 17:46)   <#>

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