id: Гость   вход   регистрация
текущее время 23:00 30/03/2020
создать
просмотр
редакции
ссылки

Создание и использование ключа OpenPGP с подключами


Оглавление документа:

Основы


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


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


Позднее в стандарт была внесена концепция подключей (subkeys), и типичный ключ стал состоять из "главного" ключа подписи и сертификации (обычно DSA) и подключа шифрования (обычно Elgamal). В данном случае разглашение закрытого ключа шифрования влекло за собой отзыв и замену лишь данного подключа без утраты главного ключа сертификации и всех собранных подтверждающих подписей. С другой стороны, утрата секретности закрытой части главного ключа требовала его полной замены, при том, что ключ DSA достаточно уязвим к утечке при частом использовании из-за мелких, трудно обнаружимых ошибок реализации алгоритма подписи или из-за недобросовестной реализации алгоритма DSA, что тоже непросто обнаружить. Ограниченный размер модуля тоже снижает стойкость.


В этой статье предлагается конструкция ключа OpenPGP, использующая подключи как для шифрования, так и для подписи данных, и тем минимизирующая риск утраты главного сертифицирующего ключа. В приведенном примере для создания ключа используется программа GPG (она же GnuPG, или GNU Privacy Guard), но в других современных реализациях стандарта OpenPGP тоже есть возможность создания и использование такого ключа.

Создание ключа


В целях обеспечения повышенной безопасности чувствительного ключевого материала создавать ключ следует на отторгаемом носителе (например, на USB-брелоке), используя персональный компьютер, не подключенный к сети. Также убедитесь, что используете наиболее свежую стабильную версию GnuPG: ранние версии могут содержать уязвимости и ошибки и, кроме того, не иметь поддержки необходимых для нашей задачи инструментов управления ключами.


Сначала создадим новую папку на брелоке. Пример (UNIX, брелок монтирован на /mnt/pen):



Пример (DOS/Windows, брелок на E:):




Помимо этого, внесем небольшое временное дополнение в файл настроек GnuPG gpg.conf с тем, чтобы все дальнейшие действия с ключами производились в контексте сменного носителя, а не вашей основной связки (добавьте в конец файла):



Отсюда и далее все примеры будут для UNIX, но единственное существенное отличие от DOS/Windows — в различных путях к каталогам (также не забывайте менять прямые слэши на обратные).


Следующий шаг — генерирование мощного пароля. Этот пароль будет использоваться редко (только для сертификации и внесения изменений в состав ключа), и его следует записать на лист бумаги и хранить при себе или в сейфе. Ни в коем случае не сохраняйте его в файл.



Теперь генерируем главный ключ сертификации RSA:



Выбираем (5) RSA (sign only) и размер ключа как минимум 2048 бит. Выбор ключей с модулем более 2048 бит (предпочтительно 4096) безопаснее в долгосрочной перспективе (порядка десяти лет), но в редких случаях может создать проблемы с совместимостью. Главный ключ может быть бессрочным (выбор 0 = key does not expire). Указываем имя и фамилию без адреса электронной почты и записанный пароль. Через несколько минут или секунд, в зависимости от мощности процессора, ключ будет готов. Запишем его идентификатор (например, 1234ABCD).


Алгоритм RSA выбирается потому, что в нем отсутствует скрытый канал, через который может произойти утечка в случае недобросовестной или просто некачественной реализации. Адрес электронной почты опускается, чтобы не терять сертификации в случае его замены (позже можно добавить и почтовый адрес, и даже фотографию). Этот ключ (и пароль) долгосрочный, использоваться будет крайне редко.


Затем редактируем ключ:



Желательно командой adduid создать дополнительную запись сертификата с адресом электронной почты (или несколько записей, если у вас несколько адресов). Затем в получившемся списке UID выделить главную запись (без почтового адреса) и сделать ее первичной, введя команду primary.


Теперь с помощью команды addkey добавьте нужные подключи для шифрования и подписания данных. Важно, что шифровальный подключ должен быть только один, тогда как подключей подписи можно добавить несколько (но как минимум один), хотя обычно в этом нет существенной потребности. Эти ключи должны регулярно заменяться, и для них стоит заранее установить срок действия в один или два года. Ключей для подписи должно быть столько, на скольких системах вы ими желаете пользоваться (например, один домой, один на работу и т.д.). Типы и длины подключей можете выбрать самостоятельно, исходя из срока действия подключей и ваших специфических требований, однако лучше остановить выбор на типе 5 RSA (sign only) для подключей подписи и типе 6 RSA (encrypt only) для подключей шифрования.


Теперь схема вашего нового ключа будет иметь примерно такой вид:



Не забудьте сохранить произведенные изменения, введя команду save.

Отделение и импорт подключей


А теперь самое главное. Поскольку мы не хотим подвергать главный ключ новой ключевой пары риску компрометации, то должны хранить и применять его особо безопасным образом, в отличие от подключей подписи и шифрования, операционные условия которых могут быть значительно шире. Таким образом, нам необходимо "отделить" подключи от главного ключа, экспортировав их в отдельный файл. Этой цели служит специальная команда --export-secret-subkeys, реализованная в GnuPG 1.4.2.


Выполним (в DOS/Windows не забудьте скорректировать путь к каталогу на брелоке):



Эта команда заставит GnuPG экспортировать закрытые подключи созданного ключа (и только их) в файл subkeys.gpg. Прежде чем импортировать этот файл в основную связку ключей, вернем настройки программы в изначальное состояние — удалите из gpg.conf внесенные ранее строчки. Затем произведите импорт секретных частей подключей подписи и шифрования, а также весь открытый ключ целиком (заметьте, мы не трогаем секретную часть главного ключа):



Проверим результат:




Обратите внимание на второй листинг. В первой строке после обозначения закрытой части главного ключа стоит знак решетки: sec#. Это означает, что секретный материал данного ключа недоступен на связке (ведь мы импортировали только отделенные подключи), а есть лишь его сертификат. Если же вы не видите значка решетки, то что-то прошло не так, и закрытая часть главного ключа тоже как-то попала на связку (возможные причины: вы по ошибке импортировали файл seckey.gpg или забыли восстановить настройки в gpg.conf). В этом случае удалите ключ со связки и начните всё с самого начала, включая генерацию нового ключевого материала.


Если полученный результат верен, можете спокойно удалить только что импортированные файлы pubkey.gpg и subkeys.gpg с USB-брелока или иного носителя, где производили все действия. Файл seckey.gpg, содержащий закрытую часть главного ключа, обязательно сохраните и не резервируйте на основной системе, иначе вы потеряете все преимущества подобной схемы разделения ключа.

Использование ключа


Для передачи вам конфиденциальной информации корреспонденты могут использовать этот ключ, как и любой другой. Точно так же, и при получении от вас подписанного сообщения их программа скорее всего сообщит, что оно заверено подключом 0x12121212, относящимся к главному ключу 0x1234ABCD (исключение составляют только старые версии OpenPGP-совместимого ПО и некоторые почтовые клиенты с ограниченной поддержкой OpenPGP, которые могут не определить связь подключа подписи с главным ключом). При шифровании данных этим ключом вы тоже не обнаружите отличий от работы с обычным ключом. Нюансы появляются при подписании данных, заверении ключей и внесении изменений в сам сертификат ключа.


Во-первых, для выполнения двух последниx действий необходим доступ к закрытой части главного ключа, размещенной на отторгаемом носителе. Чтобы GnuPG знал, где искать материал ключа, используйте в своих командах параметр --secret-keyring [путь к файлу seckey.gpg] либо внесите его в gpg.conf, чтобы не указывать постоянно (не забывайте, что в файле настроек параметры указываются без предваряющих дефисов, т.е. в виде secret-keyring [путь к файлу seckey.gpg]).


Во-вторых, при подписании таким ключом файлов и текста используемая программа может столкнуться с неоднозначностью выбора: использовать для подписания главный ключ (не забывайте, это тоже ключ подписи) или подключ, предназначенный для подписи (а если их несколько, то который из них)? Поэтому, подписывая данные, предпочтительно задавать подключ подписи явно: -u 0x12121212 (это ID подключа подписи из нашего примера). Однако, заверяя другие ключи или редактируя собственный, такое принуждение не требуется: программе в любом случае понадобится секретная часть главного ключа 0x1234ABCD. Также ID не надо указывать, если вы создали только один подключ подписи и не указывали параметр secret-keyring [путь к файлу seckey.gpg] в файле настроек GnuPG: в этом случае программа не столкнется с неоднозначностью выбора, поскольку ID 0x1234ABCD будет связан только с одним ключом подписи — 0x12121212.


 
На страницу: 1, 2, 3, 4, 5, 6, 7 След.
Комментарии [скрыть комментарии/форму]
— SATtva (26/02/2015 23:23)   профиль/связь   <#>
комментариев: 11545   документов: 1036   редакций: 4094

У UID'ов нет подключей, это разные сущности, никак друг с другом не связанные. UID — просто элемент метаданных, используемый для упрощения идентификации ключа. Может, Вы имели в виду KeyID?


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


Штатно — нельзя из-за т.н. subkey binding signature, генерируемой главным ключом только в момент создания подключа (подключ без валидной подписи главного ключа, к которому он прикреплён, использоваться не будет). То есть чтобы такое провернуть, потребуется как минимум писать свою реализацию или патчить gpg.


Да, man gpg:
When using gpg an exclamation mark (!) may be appended to force using the specified primary or secondary key and not to try and calculate which primary or secondary key to use.


Не помню навскидку, но, кажется, gpg по умолчанию не показывает, каким подключом поставлена подпись, указывает только UID главного ключа. С учётом subkey binding signature, он должен будет показать UID того ключа, на который этот подключ был прикреплён в итоге, а не на каком ключе он был создан изначально.


Не вижу, как он это в принципе сможет сделать. После того, как подключ получил новую subkey binding signature, его связь с предыдущим ключом [по идее] должна потеряться.


Есть такая мысль.
— Гость (26/02/2015 23:55)   <#>

Да, оговорился.


Для уже сделанных подписей владелец подписанного ключа может посмотреть их срок?


Ну как же, всё показывается:
$ gpg --verify tor-browser-linux64-4.0.4_en-US.tar.xz.asc
gpg: assuming signed data in `tor-browser-linux64-4.0.4_en-US.tar.xz'
gpg: Signature made Wed 25 Feb 2015 07:55:16 AM UTC using RSA key ID F65C2036
gpg: Good signature from "Tor Browser Developers (signing key)
<torbrowser@torproject.org>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: EF6E 286D DA85 EA2A 4BA7  DE68 4E2C 6E87 9329 8290
     Subkey fingerprint: 5242 013F 02AF C851 B1C7  36B8 7017 ADCE F65C 2036
См. Subkey fingerprint.

Кажется, в GnuPG были какие-то механизмы сделать CA. И Unknown хочет чего-то такого. Что касается ring signatures, лучше дождаться их официальной реализации в стандарте и в GnuPG, вроде задумки такие были [1], как и задумки про PFS [2].
— Гость (27/02/2015 00:17)   <#>

Так никто и не пытается встрять в вашу дисскусию. просто решил пройтись по ману (Раздел – Создание ключа).
— Гость (28/02/2015 01:45)   <#>

Вообще, да, но SATtva бы не одобрил:

Похоже, gpg действительно не позволяет вывести отпечатки ключей подписи

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

Ручная сверка подписей, по-видимому, никогда не рассматривалась в качестве надёжного и необходимого средства


Сертификаты отзыва на главный ключ или подключ — это одно, а допустимые аргументы у опции --export-secret-subkeys — совсем другое. В моей 1.4.18 она принимать KeyID'ы ключей не умеет (по крайней мере, в man gpg на этот счёт молчок).


Могут.



Ниже некое резюме по предложению «Отделяемые совместно используемые подключи подписи» в предположении, что мы готовы сидеть с шестнадцатеричным редактором:


Можно.


Да.


Как мне кажется, анонимна, если используется hidden-recipient (есть ли его аналоги чисто для подписи?). В обычном случае KeyID главного ключа вроде всегда проставляется(?).


Вроде можно.


Не залезая в код и не проводя эксперименты, на это сложно дать ответ.


Только если

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


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




Я, если честно, не проверял, как работает слив подключей. Может быть, в каких-то экзотических случаях он всё же сработает. Если ответ sentaus'а [1] универсален, то это не сработает никогда. По крайней мере, при штатном добавлении новых секретных подключей он не срабатывает, но там связка без главного секретного ключа (вдруг это важно?). В принципе, связность связки ключей можно определить и по публичному ключу, секретный для этого не нужен, так что сложно сказать, кто тут всему виной, надо лезть в код.
— Гость (02/03/2015 08:11)   <#>

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

Как оно на самом деле внутри устроено — непонятно, но если уже кем-то сгенерированный подключ не требует для связывания с новым главным чего-то помимо владения секретной частью нового главного, то всё так. В принципе, могло бы быть и иначе, тогда чужой подключ в принципе к себе нельзя было бы повесить, не зная соответствующего ему секретного главного ключа связки.
— Гость (02/03/2015 09:07)   <#>
Выбираем (5) RSA (sign only)

У меня это пункт 4.


Там возникает чихарда с нумирацией,
у некоторых это 4 у других это 5.
Надо не смотреть на номера, а просто выбирать подходящее
по смыслу. Нам надо RSA (sign only), находим его в списке и берем и вводим его номер.
— Гость (02/03/2015 09:09)   <#>
> А они могут повесить этот подключ на свои личные ключи (?).

Могут.


А технические подробности?
Как это возможно?
Command Line?
— Гость (02/03/2015 09:13, исправлен 02/03/2015 11:57)   <#>
> gpg --gen-key
Может можно воспользоваться seahorse? В конечном счете я там все и вижу.

Можно и seahorse, тогда получите сразу главный ключ с подключом варианта RSA/RSA,
на подключ подписания все равно прийдется добавлять с консоли.

— SATtva (02/03/2015 12:02, исправлен 02/03/2015 12:04)   профиль/связь   <#>
комментариев: 11545   документов: 1036   редакций: 4094

Помимо пакета subkey binding signature, генерируемого главный ключом, есть также primary key binding signature — такой пакет содержит подпись материала главного ключа подключом подписи. Так что прекращайте этот наивняк. Переносить подключи между ключами просто так нельзя, и шестнадцатеричный редактор сам по себе в этом деле не поможет.

— Гость (03/03/2015 08:33)   <#>

Что ж вы раньше не сказали? Но если владелец админского ключа (по unknown'у) сам раздаёт секретный подключ другим владельцам, то это не проблема.
— SATtva (03/03/2015 13:28, исправлен 03/03/2015 16:32)   профиль/связь   <#>
комментариев: 11545   документов: 1036   редакций: 4094

Моя мысль была в том, что одной только склейкой имеющихся пакетов в редакторе Вы не обойдётесь, т.к. всё равно потребуется обновлять связывающие подписи. Даже если Вы по тем или иным причинам оставляете primary key binding signature от прежнего ключа (чтобы именно он был отображён при сверке подписей, сделанных подключом), всё равно придётся как-то обновить subkey binding signature, поскольку с неправильной подписью gpg, по идее, даже не должен импортировать такой подключ.


Хотя это сам по себе отдельный вопрос, требующий изучения: как gpg будет реагировать на разные нештатные комбинации связующих подписей. Как программа себя поведёт при импорте ключа, генерации и сверке подписей, если subkey binding signature не от того ключа, к которому прикреплён данный подключ? Как она себя поведёт, если primary key binding signature и subkey binding signature не образуют взаимную подпись? *



* Штатно, если мы имеем главный ключ A и его подключ подписи Ab, primary key binding signature должна быть Ab⟶A, а subkey binding signature — A⟶Ab. В том же сценарии, который мы тут рассматриваем, есть второй главный ключ C, и мы хотим перенести на него подключ подписи от A так, чтобы primary key binding signature была Cb⟶A, но при этом subkey binding signature была C⟶Cb.

— SATtva (03/03/2015 13:33)   профиль/связь   <#>
комментариев: 11545   документов: 1036   редакций: 4094
Кстати, возвращаясь к ранее обсуждавшемуся вопросу установки разных парольных фраз на подключи:


Этот последний шаг не нужен, можно просто прописать пути ко всем трём получившимся связкам с помощью secret-keyring — если кто-то забыл или не знал, их может быть произвольное количество.
— unknown (03/03/2015 14:41)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Т.е. primary ↔ subkey подписи взаимно сцепленные, а не односторонние, о чём я изначально не знал. Возможно, что это не просто перестраховка, в этом есть определённый смысл и если так взаимоподписывать присланный подключ, то это откроет какие-либо пути к атакам и на основной ключ. Т.е., лучше так не делать во избежание злоупотребления доверием, не говоря уже о практических сложностях с реализацией.
— SATtva (03/03/2015 16:14)   профиль/связь   <#>
комментариев: 11545   документов: 1036   редакций: 4094

Только в случае подключей подписи. Подключи шифрования, разумеется, главный ключ не подписывают.
— Гость (04/03/2015 00:18)   <#>

Вы не поняли, что я вам хотел сказать. Ещё раз обращаю внимание на цитату:

Но если владелец админского ключа (по unknown'у) сам раздаёт секретный подключ другим владельцам, то это не проблема.

Абоненты получают как публичный подключ, так и соответствующий ему приватный. Это позволяет сделать также primary key binding signature, когда они будут вешать этот подключ к себе на связки. А subkey binding signature каждый абонент, очевидно, тоже может сделать, потому что у него есть как публичный, так и приватный главный ключ его связки. Всё, что требуется абонентам от админского ключа — приватный подключ подписи.

Может быть, конечно, там есть какие-то тонкие технические нюансы,** из-за которых это не будет работать, но мне они неочевидны.


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

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