id: Гость   вход   регистрация
текущее время 18:48 29/03/2024
создать
просмотр
редакции
ссылки

Создание и использование ключа 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 (04/03/2015 05:55, исправлен 04/03/2015 05:56)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118

Боюсь, это Вы не поняли, что я хотел сказать. :) Вы несколько раз писали, что для реализации такой схемы достаточно помахать шестнадцатеричным редактором. Так вот в ответ на это я пытаюсь донести, что этого недостаточно: в gpg нет пользовательских инструментов для генерации subkey binding signature (primary key binding signature, если она отсутствует, можно сгенерировать командой cross-certify, хотя её-то в этой схеме как раз менять и не требуется).



Связывающие подписи генерируются непосредственно на ключевом материале: главного ключа в случае primary key binding signature и подключа в случае subkey binding signature.

— Гость (07/03/2015 15:37)   <#>

Он понадобится, в том числе, но не только. Для меня вопрос инструментов вторичен, важна принципиальная осуществимость в рамках (Open)PGP-стандарта.


Почему это? Я не уверен, что ключи, у которых будет левая primary key binding signature, будут хотя бы формально работоспособными. А если перегенерить подпись на свой главный ключ, то всё будет ОК точно. Впрочем, в man gpg про cross-certify пишут

All new keys generated have this signature by default, so this option is only useful to bring older keys up to date.

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


Т.е., переводя на ваш язык, я опасался случая, когда подписи генерятся «на» третьих сущностях, выводимых из ключевого материала обоих ключей (главного и подключа) (?). Сама фраза «подпись генерируется непосредственно на ключевом материале» мне плохо понятна.
— unknown (10/03/2015 09:41, исправлен 10/03/2015 10:48)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Возвращаясь к старому вопросу.



Проверил, всё так и есть.



Добавлял недавно подключ и вспомнил, что я вам тогда ответил не полностью. Всё у вас с GnuPG правильно, может это и ещё кому-то будет полезно.


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


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

— Гость (10/03/2015 14:03)   <#>

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

GnuPG ведёт себя логично.
— unknown (13/03/2015 09:32)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
В экспорте ключей ещё и баги находят если вместо корректного имени попытаться задать нечто злонамеренное.

Multiple issues in GnuPG found through keyring fuzzing (TFPA 001/2015):

GnuPG allows to specify a non-standard keyring on the command line. Fuzzing GPG with

led to the detection of various issues. (Please note that the keyring parameter needs the full path and does not like filenames with unusual characters like the ones generated by american fuzzy lop.)
— Гость (13/03/2015 13:25)   <#>
Опцию --keyring всегда можно обойти, указав нужную переменную $HOME.


Неудивительно, GnuPG — тяжёлый и сложный комбайн, где наворотили столько всего... и ещё хотят наворотить.
— unknown (20/03/2015 15:57)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
По поводу key capabilities


Создадим вручную в экспертном режиме, ключ вида:



Как пишет spinore в коментариях, которые невозможно найти гуглом:

теперь я решил не делать главные ключи с S-capability, придерживаясь правила «одна capability — один ключ».


  1. Т.е., подпись м.б. сделана только подключом 0x12345678. Но через год этот подключ не продлят, а вместо него заведут другой. Следовательно, все кто импортирует ключ 0x01234567 через год этот подключ при импорте вообще не получат, а значит не смогут проверить старые подписи?
  2. Поскольку на главном ключе 0x01234567 есть только "C" и нет "S", то подписать этим ключом другой ключ для сети доверия принципиально нельзя? По идее для этого надо иметь "S" и именно на главном, подключи не годятся.

Иначе говоря, "CS" по умолчанию на главном нужно только для того, чтобы:

  1. Всегда иметь возможность делать проверяемую (даже после истечения срока действия или аннулирования ключа) подпись.
  2. Для подписывания ключей других пользователей.
— Гость (21/03/2015 02:44)   <#>

Решили продолжить тренд? :)


Как это не получат? А куда ж они денутся? Даже если подключ будет отозван, он останется на серверах ключей и будет каждый раз выкачиваться при --refresh-keys, если у вас по какой-то причине его нет на связке. Соответственно, старые подписи будут сверяться, просто будет писаться предупреждение «ключ подписи отозван/устарел» и т.п.

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


Как это нельзя? C-capability — это и есть возможность подписи (чужих) ключей (certify). S-capability — подпись данных.


Чтобы было чуть больше удобства в плане создания и проверки некоторых подписей, сделанных главным ключом? Чтобы их можно было проверять без обновления ключа? Деление по capability вроде как изначально было вызвано чисто криптографическими требованиями, т.е. нехорошо шифровать тем же ключом, каким и подписываем (это вам должно быть виднее, чем мне). Ранее все главные ключи были CSA, подключей не было. Это до сих пор видно по старым ключам на связках. Потом добавили подключи, чтобы, если помню правильно, удовлетворить жаждующих их депонирования с законным принуждением. SATtva в своё время это всё здесь рассказывал. Правда, непонятно, зачем нужно такое депонирование, если полицейский режим разглашения сессионных ключей и так есть. Ну, может, для ещё большего удобства.

При депонировании обычно требуется ключ шифрования, а не подписи — это первое, второе — то, что и сертификация C и подпись S отвечают за подпись, поэтому навешивая их на один ключ, мы не смешиваем шифрование каких-либо данных с их подписыванием. Видимо, это определило то, что до сих пор при генерации ключей по умолчанию создаётся лишь один подключ (шифрования), а главный ключ получает CS-capability. Т.е. это минимальная схема, удовлетворяющая вышеозвученным требованиям. Не думаю, что в это есть что-то большее.

Из вашего вопроса естественным образом вытекает другой вопрос — можно ли сделать главный ключ без C-capability? Проверил: GnuPG не позволяет (не знаю, позволяет ли стандарт OpenPGP — SATtva, наверно, мог бы сказать).

Unknown пытается оправдать некоторые цитаты из комментария, получается неплохо. :)
— SATtva (21/03/2015 10:39)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118

Не менее важной причиной была необходимость отвязаться от RSA в эпоху патентных войн. С помощью RSA можно и шифровать, и подписывать, с помощью DSA — уже нет.


Эта опция — расширение GnuPG, а стандарт появился намного раньше. Но самое главное, что нет никаких ограничений, по которым следствие может требовать только сеансовые ключи от конкретных сообщений, а не асимметричный ключ целиком.


Нет, конечно. Вы же в таком случае не сможете связать метаданные сертификата воедино.
— Гость (21/03/2015 12:29)   <#>

Получается, "C" связывает, в том числе, подключи и др. PGP-пакеты в единый ключ? Иными словами говоря, C — то и только то, что делает ключ главным ключом связки? Наверно, подключи с C-capability нельзя создать.

Ещё я не понимаю, почему в GnuPG жёстко зашита невозможность поменять capability главного ключа и подключей после их генерации. Это можно сделать технически в рамках стандарта (написав свой код) или нет? Что такое capability подключа на техническом уровне? Тоже какой-то дополнительный PGP-пакет? Или это глубже зашито?
— SATtva (21/03/2015 12:50)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118

Ограниченность реализации. Capabilities — атрибут self-signature, так что нет особых причин, почему их нельзя было бы изменять, как cipher preferences, например. Имейте в виду, что, хотя GnuPG — довольно гибкая реализация и позволяет делать значительно больше, чем, скажем, коммерческий PGP, но даже она не реализует всех элементов, поддерживаемых стандартом. Посмотрите хотя бы на перечень capabilities (Key Flags в терминологии стандарта) в fileразделе 5.2.3.21.
— Гость (21/03/2015 13:10)   <#>

Да это я уже давно понял...


Спасибо, познавательно. Интересно, если самому сделать ключ по стандарту с теми «Key flags» (capabilities), какие ещё не поддерживается GnuPG, как она их отобразит при редактировании ключа? Просто ничего не напишет про неизвестные capabilities, раз их не опознала?
— Гость (21/03/2015 13:24)   <#>
Хотел спросить, почему
$ gpg -k --list-options show-usage
не работает. Разгадка, похоже, оказалась, как всегда, предельно банальной.
— monomah (28/07/2015 22:00)   профиль/связь   <#>
комментариев: 5   документов: 0   редакций: 0
Хорошо бы описать в статье процедуру обновления подключей при условии модификации публичной связки, отделенной от главного ключа. Думаю, не только я столкнулся с определенными трудностями.
— pgprubot (28/07/2015 23:56, исправлен 28/07/2015 23:58)   профиль/связь   <#>
комментариев: 511   документов: 2   редакций: 70

В статье описан только один конкретный вариант разделения связки и её последующего использования, а их может быть множество. Например, можно не подсоединять связку с секретным ключом к основному юзеру, а завести отдельного юзера для работы с главным секретным ключом связки. А ещё можно gpg-remote нагромоздить поверх этого всего. Вариантов много. Тем не менее, основное в статье ухвачено верно, и формально всё, что там предлагается, остаётся рабочим по сей день. Достаточно взять голову и сделать всё правильно под свой конкретный случай. Единственный нетривиальный факт в комментариях — этот. Конечно, можно сделать ещё один обширный документ с рекомендациями на тему того, как правильно отделять ключи, как их хранить, мержить и генерировать, никто не воспрещает.

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