id: Гость   вход   регистрация
текущее время 21:41 28/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 След.
Комментарии [скрыть комментарии/форму]
— Гость (24/02/2015 16:27)   <#>
А как насчет Primary и пароля для подключа?
— unknown (24/02/2015 16:36)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Primary — это главный ключ ключа-связки, которым заверены все подключи. Паролей на отдельные подключи не бывает: если кто-то смог подобрать пароль на главный ключ, которым подписана связка с подключами, то он может делать атаки с аннулированием действительных и выпуском подставных подключей.
— SATtva (24/02/2015 18:16)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
В контексте заданного вопроса, команда primary задаёт основной UID, отображаемый по умолчанию (если их на ключе несколько).

Пароли на главный ключ и подключи легко могут быть разными: после отделения подключей от главного ключа их можно поменять командой passwd.
— Гость (25/02/2015 08:39)   <#>
В контексте заданного вопроса, команда primary задаёт основной UID, отображаемый по умолчанию (если их на ключе несколько).


Да да, поннятно. Ведь можно впихнуть сколько хочеш UID, даже после создания основного ключа.


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

А вот эт важно, очень хорошо. А то получается ка то не совсем правильно. Смысл тогда создавать главный ключ с подключами,
если ты подключи уносиш на отдельный комп, а там случается палево, и что тогда, ты теряеш подключи да еще потребуют от тебя
сказать пароль от подключа, а он такой же как и у главного, двойное палево получается. А че так скрывают разработчики такую возможность чели?
В сысле последующей семены пароля? В документации все обшарил, не нашел даже упоминания. Очень важная инфа.
— unknown (25/02/2015 09:56)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Даже на один и тот же ключ, но хранящийся в разных ключевых файлах, можно поставить разные пароли. Пароль нужен для шифрования закрытого ключа, чтобы им никто не воспользовался просто так. Следовательно, пароль можно менять, ключ будет перешифровываться.
— Гость (25/02/2015 10:04)   <#>
Попробовал сменить пароль на отделенных подключах.
Сделал Один главный + подключ шифрования + подключ подписания.

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

может че делаю не так?

Возможно разные пароли на подключи шифрования и подключи подписания?

— Гость (25/02/2015 12:49)   <#>
А PGP позволяет создавать главный ключ с подключами?
Или эьо возможно только в GPG?

А такой ключ с подключами совместим с PGP? Или он только совместим с GPG?
— SATtva (25/02/2015 17:46)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118

Вы там другой в принципе не создадите.


Если речь о подключах, как таковых, то да. Однако описанный в этой инструкции процесс отделения подключей от главного ключа — фирменная фича GnuPG: перенести такой закрытый ключ в PGP не удастся. Разумеется, на совместимости открытых ключей это никак не сказывается.
— Гость (26/02/2015 00:19)   <#>

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


Вопросы trust и validity ранее обсуждались [1], [2].


Да.


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


Бывает, и это никак не связано с вашим дальнейшим справедливым замечанием на эту тему.


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

Для начала, вам нужно отделить секретный ключ или подключи через --export-secret-subkeys. Я не уверен, что этой опции можно задать UID'ы подключей. Если нельзя, то она всегда будет экспортировать все подключи, и смена пароля будет происходить на все из них.

Допустим, вы создали один секретный подключ и экспортировали его таким образом куда-то на новую связку, там сменили ему пароль. Потом вы на связке с главным секретным ключом удалили этот подключ и создали другой. Его тоже экспортировали куда-то, и в новом месте сменили пароль. После этого со связки с главным ключом его можете удалить. Теперь у вас есть три связки со следующими секретными ключами:
  1. С главным ключом.
  2. С первым подключом.
  3. Со вторым подключом.
Пассфразы на всех трёх будут разными. Потом вы хотите сделать последний шаг — слить подключи с разными пассфразами на какую-то одну связку, чтобы получить желаемое: на один подключ чтоб был один пароль, а на другой — другой. Так вот, хрен вам, у вас ничего не получится, потому что GnuPG тупое [3].

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



P.S. У меня у самого есть вопросы по GnuPG:
  1. Когда делаешь gpg --edit-key, слева пишется [full], [unknown], [expired] и т.д. — что это означает? Особенно отличие full и unknown меня удивляет. Это имеет отношение к validity/trust [4]?
  2. Если главный ключ имеет конечный срок действия, и его кто-то подписал, после продления главного ключа подпись уже более не считается действительной [5]?
— unknown (26/02/2015 09:43, исправлен 26/02/2015 09:43)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Про такие извраты не знал.



Имеет, примерно так как и написано в той теме коментами выше/ниже. Правда, настоящие параноики этим не пользуются и сверяют все подписи на ключах вручную.



Можно проверить экспериментально, если так интересно. Возможно там есть ещё куча багов в этом механизме.


P.S.: У меня уже у самого возникают некоторые идеи по извратному использованию GnuPG, именно в плане подключей. Если соберусь, то возможно даже создам новую тему.

— Гость (26/02/2015 10:56, исправлен 26/02/2015 22:54)   <#>
Для начала, вам нужно отделить секретный ключ или подключи через --export-secret-subkeys. Я не уверен, что этой опции можно задать UID'ы подключей. Если нельзя, то она всегда будет экспортировать все подключи, и смена пароля будет происходить на все из них.

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

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

Тоесть делал экспорт открытых подключей/закрытых подключе через ID, вроде не ругался.
Но в итоге у всех asков содержимое было одинаковое, у всех асков с открытых подкючей они одинаковые,
у всех асков с закрытых подключей они тоже одинаковые, хотя все аски сейвил в разные файлы. Типа 2 аска открытых одинаковых,
плюс еще аски с закрытых,они отличны от открытых, но меж собой одинаковы.
— Гость (26/02/2015 11:14)   <#>
P.
S.: У меня уже у самого возникают некоторые идеи по извратному использованию GnuPG, именно в плане подключей. Если соберусь, то возможно даже создам новую тему.


Огласите идеи!
— Гость (26/02/2015 11:24)   <#>
Да, да, огласите весь список!
— unknown (26/02/2015 12:22, исправлен 26/02/2015 13:56)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Отделяемые совместно используемые подключи подписи


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


Пусть некий условный админ некоего/некоей открыт{ого/ой} несекретн{ого/ой} неанонимн{ого/ой} проекта/группы (вопрос: насколько и где это реально возможно и не/нужно?) может (?) сгенерировать общий ключ проекта, но никому закрытой части не давать. На ключе он может создать подключ подписи и экспортировать его. Далее, он может по безопасному каналу разослать закрытую часть этого подключа (вместе с паролем) всем членам проекта. А они могут повесить этот подключ на свои личные ключи (?).


  1. Можно ли вообще повесить секретный подключ на чужой главный сертифицирующий ключ (владельцу закрытой части этого ключа, естественно)? Если нет, то вся идея бессмысленна изначально.
  2. Реально ли владельцу ключа выбрать, каким именно подключом подписывать? Если нет, то идея также смысла не имеет. В частности, поэтому рискованно и практически бессмысленно использовать расшаренный подключ для шифрования — такое теоретически возможно, но здесь даже не рассматривается из-за фатальности в случае ошибок использования (весьма вероятных).
  3. Анонимна (псевдонимна) ли такая подпись (как групповая)? Если да, то идея, возможно, бессмысленна — проще расшарить общий главный ключ. Если нет, то можно ли (и насколько удобно это проверять) сказать, что ключ Алисы подписал сообщение подключом группы?
  4. При проверках и работе с общим подключом на разных ключах не будет ли OpenPGP выдавать ошибки? Будет ли корректно выкачивать обновления для всех ключей с одинаковым подключом?
  5. Может ли админ группы/проекта эффективно отзывать/перевыпускать/перерассылать подключ участникам группы, чтобы модерировать членство в группе? Легко ли и удобно (относительно) продвинутому стороннему пользователю проверить членство в такой открытой группе по обновлению отпечатка открытого подключа?

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


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

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