id: Гость   вход   регистрация
текущее время 20:59 25/09/2018
создать
просмотр
редакции
ссылки

Создание и использование ключа 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 След.
Комментарии [скрыть комментарии/форму]
— Гость (26/02/2015 13:25)   <#>
Можно ли вообще повесить секретный подключ на чужой главный сертифицирующий ключ (владельцу закрытой части этого ключа, естественно)? Если нет, то вся идея бессмысленна изначально


Попробовал сделать так:
-сделал все по инструкции до момента экспортирования подключей
– далее сделал export-sub-sec-key указав ID этого подключа в ask через --armor

– переклинил конфиг на дефолт

– далле в чистую пустую хомедир перекинул этот ask + pubkeys.gpg
– все это импортирую
– лезу в консоль
– листаю keys + secret keys
– и что я вижу?




ТОЕСТЬ КАРТИНА ОНАЛОГИЧНА ДАННОМУ ПРИМЕРУ.

— ТОЕСТЬ я попытался выцепить только один подключ через его ID типа 0x12121212
А В ИТОГЕ получилось что экспортировались все закрытые подключи разом.

— НЕ ПОВЕРИЛ УВИДЕННОМУ, проверил, смог зашифр+расшифр подписать+проверить подписанное,
— А ДУМАЛ что смогу только подписывать, а на шифровку будет ругаться.

КИКИЕ БУДУТ СООБРАЖЕНИЯ

— Гость (26/02/2015 13:37)   <#>
Можно ли вообще повесить секретный подключ на чужой главный сертифицирующий ключ (владельцу закрытой части этого ключа, естественно)? Если нет, то вся идея бессмысленна изначально.


--import по офицц доке ринимает только ask или gpg
--edit-key по оффиц доке молчит насчет втюхивания импортирования при редактировании

Тут только залесть в исходники, и посмотреть как импорт идет. По идее он должен
импортировать и мержить на конкретный ID, но это можно утверждать только просмотрев исходники,
тогда вопрос полностью отпадет. Если жестко на сушествующий ID или с чистого листа, то нет. А если ему можно втюхать на какой ID повесить, то тогда да.
— unknown (26/02/2015 13:39, исправлен 26/02/2015 13:39)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

А если экспортнуть и переимпортнуть на временную связку, удалить лишние и ещё раз экспортнуть?

— Гость (26/02/2015 13:43)   <#>
А если экспортнуть и переимпортнуть на временную связку, удалить лишние и ещё раз экспортнуть?


Не догнал мысли, подробнее?
— unknown (26/02/2015 13:49, исправлен 26/02/2015 13:53)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

  1. Экспортируем все подключи вместе с главным сертифицирующим.
  2. Импортируем во временную связку.
  3. Удаляем лишние подключи в п.2.
  4. Снова экспортируем без главного сертифицирующего.
  5. Импортируем куда-надо из п.4.
  6. Удаляем временную связку.
— Гость (26/02/2015 13:50)   <#>
А если экспортнуть и переимпортнуть на временную связку, удалить лишние и ещё раз экспортнуть?


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

И на новой пустой кейринге у нас появится этот подключ, без секретной главной части железно.
— unknown (26/02/2015 13:52)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Может там их много и некоторые — нужны.
— Гость (26/02/2015 13:58, исправлен 26/02/2015 22:55)   <#>
Экспоритуруем все подключи вместе с главным сертифицирующим.
Импоритурем во временную связку.
Удаляем лишние.
Снова экспортируем без главного сертифицирующего.
Удаляем временную связку.
Импортируем куда-надо из п.4.

Типа вы хотите обмануть самого себя чели, это же одно и тоже


Экспоритуруем все подключи вместе с главным сертифицирующим.

принимается получаем закрытые части + открытые части
погнали далее


Импоритурем во временную связку.

лудше в пустую хомедир чтобы появились стандартные secring + pubring
принято погнали далее


Удаляем лишние.

принимаем. НО ТОЖЕ САМОЕ МОЖНО СДЕЛАТЬ ЕЩЕ ДО ЭТОГО ШАГА ЧЕРЕЗ ЕДИН КЕЙ


Снова экспортируем без главного сертифицирующего.

МАСЛО МАСЛЕННОЕ



Импортируем куда-надо из п.4.


РЕЗУЛЬТАТ БУДЕТ АНАЛОГИЧНЫЙ
получим конкретный подключ без главного ключа (типа только подк подписи иил подкл шифра)

— Гость (26/02/2015 14:01)   <#>

Может там их много и некоторые — нужны.


но ведь вы сами предлагаете

— unknown (26/02/2015 14:07)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Это вместо бэкапа основного ключа.
— Гость (26/02/2015 14:22)   <#>
Типа тут мудрить нечего, опыт показал явно, что секретные подключи экспортируются жахом,
хоть ты и при этом заранне несколько удалиш, все остальные сольются жахом, даже если указал на конкретный через ID.

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

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

Типа у нашего подключа ИД1 а при импортировании указать чебы он вклинился в ключ с ID2 типа отдельный самый по себе главный ключ.

Если по исходнику таое можно, то можно пересобрать исходник, и тогда +
иначе –
— Гость (26/02/2015 14:26)   <#>

У меня это пункт 4.
— Гость (26/02/2015 14:43)   <#>

Может можно воспользоваться seahorse? В конечном счете я там все и вижу.
— Гость (26/02/2015 14:45)   <#>


Уважаемый, не глумите ДЯДЬКАМ голову, вы не в теме,
мы парим совсем о друнгом
— Гость (26/02/2015 16:54, исправлен 26/02/2015 17:37)   <#>

Гость (26/02/2015 14:22), ты уже конкретно подза*бал. Намеренное искажение грамматики, удаффовский сленг, неструктурированная мысль (не владеешь темой и терминологией, хрен поймёшь, что ты сказал), капс без причины. Весь набор симптомов. Можеть все твои мессаги просто грохнуть и всё? Чище на сайте станет.

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