Как перенести pgp на другой компьютер

Обновлено: 08.01.2025

Авторизуясь в LiveJournal с помощью стороннего сервиса вы принимаете условия Пользовательского соглашения LiveJournal

I. GPG

Установка и настройка:

1. Скачиваем инсталлятор: ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w 32cli-1.4.7.exe
2. Устанавливаем GPG.
3. Чтобы установленный gpg можно было использовать как системную команду, добавим путь к каталогу, в котором он лежит в переменную окружения PATH:
Мой компьютер -> Свойства -> Дополнительно -> Переменные среды
В переменную PATH добавляем путь к каталогу с gpg.exe (по умолчанию - C:\Program files\GNU\GnuPG\).
Чтобы проверить, что всё сделали правильно, запускаем Пуск -> Выполнить -> cmd и набираем gpg --help. На экране должна появиться справка по gpg.
4. Чтобы пользоваться серверами ключей, добавим их в конфигурационный файл:
Создаём файл C:/Documents and Settings/<имя пользователя>/Application Data/g
nupg\gpg.conf
В файл добавляем строчку "keyserver hkp://subkeys.pgp.net".

Теперь GPG установлен и настроен. Нужно сгенерировать ключи.

Генерация ключей:

0. Открываем консоль (Пуск -> Выполнить -> cmd) и все дальнейшие действия производим в ней.
1. Генерируем основной ключ (будет использоваться только для подписи):
Запускаем gpg с параметром --gen-key и отвечаем на вопросы:
Тип ключа - RSA
Длина - 4096
Срок действия - ставим 0.
Дальше у нас спросят имя, e-mail адрес и комментарий, из которых будет сгенерирован UID вида "Имя (комментарий) <адрес>". В качестве адреса вводим свой jid.
В заключение нужно ввести пароль, которым будет зашифрован секретный ключ. Этот пароль будет запрашиваться каждый раз, когда мы будем производить какие-либо манипуляции над секретным ключом (в том числе, при запуске приложений, использующих GPG-шифрование).

Некоторое время уйдёт на генерацию ключа, после чего gpg выведет информацию о сгенерированном ключе, из которой мы можем узнать его идентификатор (он понадобится нам для дальнейших манипуляций с ключом).
Ищем строчку вида:
pub <размер><алгоритм>/<идентификатор> <дата>
например:
pub 2048R/6DB1613F 2007-12-08

2. Генерируем дополнительный ключ (будет использоваться для шифрования):
gpg --edit-key <идентификатор основного ключа>
addkey
<пароль к основному ключу>
ElGamal
4096
0
Принять
save

Работа с серверами ключей:

1. Загрузка ключа на сервер:
gpg --send-key <идентификатор основного ключа>

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

2. Поиск чужого ключа:
gpg --search "строка"
Можно искать, например, по имени.
Если какие-то ключи будут найдены, мы увидим их список с предложением выбрать необходимый ключ. Выбранный ключ будет загружен с сервера и импортирован.

3. Импортирование ключа по известному идентификатору:
gpg --recv-key <идентификатор>
Если такой ключ есть на сервере, он будет загружен и импортирован.

Перенос секретных ключей на другой компьютер:

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

1. Экспортируем секретный ключ в файл:
gpg --export-secret-keys <идентификтаор> > файл
2. Копируем полученный файл на сменный носитель и удаляем с диска.
3. На другом компьютере делаем:
gpg --import < файл
После чего удаляем файл.

Дополнительный софт:

II. PSI

Я прочитала эта статья, которая очень хорошо объяснила, как настроить pgp на osx, но я планирую использовать сгенерированные ключи для подписания коммитов git, поэтому я считаю, что мне нужно перенести ключи на другой компьютер. Правильно ли это? и если да, то как я могу передать ключи?

да, вам нужно будет передать ключи. Mac и Linux работают одинаково, сохраняя ключи в

/.gnupg . Самый безопасный способ передачи файлов с помощью scp (часть ssh):

, вы должны иметь ssh работает.

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

Я не знаю о местоположении каталога в Windows. Документация gpg скажет, и содержание почти наверняка будет таким же.

копирование всего кольца ключей выполняется быстро и легко, но иногда вы хотите иметь возможность перемещать отдельные ключи между машинами без перезаписи всего кольца ключей и потери ключей, которые уже там. Копирование отдельных ключей выборочно можно сделать с помощью gpg --export-secret-key и gpg --import . Если у вас есть ssh-доступ к целевой машине, вы можете сделать это с помощью канала и не нужно хранить промежуточный ключ в любом месте:

если ты на машине, которая уже имеет ключ:

если вы находитесь на машине, которая нуждается в ключе:

если gpg не находится в одном из мест по умолчанию на удаленной машине (например, в /opt/local/bin на Mac), вы будете должен дать полный путь к ssh или символически связать его с одним из стандартных мест, таких как /usr/local/bin .

обратите внимание, что передаваемые данные по-прежнему защищены парольной фразой, и ключ будет иметь ту же парольную фразу в месте назначения, что и в источнике. Если вы хотите иметь разные парольные фразы в каждом месте, вам нужно будет изменить парольную фразу в месте назначения или временно изменить ее в источнике перед экспортом. Мне нужно было поделиться секретным ключом с коллега, чтобы дать ему возможность обновить РЕПО пакета Debian, которым мы оба управляем, но я не хотел делиться с ним своей парольной фразой. Поэтому я изменил парольную фразу на что-то временное, отправил ему экспортированный ключ (по GPG-зашифрованной электронной почте!), сказал ему временную парольную фразу устно и попросил его установить новую парольную фразу сразу после импорта ключа. Затем я изменил кодовую фразу на моей копии ключа обратно на то, что было изначально.

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

Я читал эту статью, которая очень хорошо объясняла, как настроить pgp на osx, но я планирую использовать сгенерированные ключи для подписания git фиксируется, поэтому я полагаю, что мне нужно перенести ключи на другой компьютер. Это верно? и если да, то как мне перейти на передачу ключей?

спросил(а) 2020-03-17T15:34:12+03:00 1 год, 8 месяцев назад

Да, вам нужно будет перенести ключи. Mac и Linux работают одинаково, сохраняя ключи в

/.gnupg . Самый безопасный способ передачи файлов - использовать scp (часть ssh):

Однако сначала вам понадобится ssh .

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

Я не знаю о расположении каталога в Windows. Документация gpg скажет, и содержимое почти наверняка будет таким же.

Копирование всего брелка происходит быстро и просто, но иногда вы хотите, чтобы иметь возможность перемещать отдельные клавиши между машинами, не перезаписывая весь брелок и не теряя ключи, которые уже есть. Копирование отдельных клавиш выборочно можно выполнить с помощью gpg --export-secret-key и gpg --import . Если у вас есть доступ ssh к машине назначения, вы можете сделать это с помощью канала и не нужно хранить промежуточный ключ в любом месте:

Если вы находитесь на машине, у которой уже есть ключ:

Если вы находитесь на машине, которой нужен ключ:

Если gpg не находится в одном из мест по умолчанию на удаленном компьютере (например, в /opt/local/bin на Mac), вам нужно будет указать полный путь к ssh или поместить его в один из стандартные места, такие как /usr/local/bin .

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

Хотя население в целом практически не использует OpenPGP, но это критический элемент безопасности, особенно для дистрибутивов Linux. Например, центральный репозиторий Debian проверяет каждый пакет с помощью OpenPGP-ключей мейнтейнера, а затем подписывает его своим ключом. Если у пакетов, которые включаются в ветку, тоже есть такие подписи, то создаётся полноценная цепочка доверия от изначального разработчика до пользователей. Кроме того, пулл-реквесты в ядро Linux тоже верифицируются цифровыми подписями. Поэтому ставки высоки: если скомпрометирован ключ для подписи релиза или хотя бы ключ единственного мейнтейнера, следствием может стать разрушительная атака на много машин.

Это привело сообщество Debian к лучшему пониманию хороших практик работы с криптографическими подписями (которые обычно создаются в программе GNU Privacy Guard, также известной как GnuPG или GPG). Например, слабые (менее 2048 бит) и уязвимые ключи PGPv3 в 2015 году удалили из связок ключей, а среди разработчиков Debian широко распространена практика взаимной подписи ключей при личной встрече. Но даже у разработчиков Debian, кажется, отсутствуют общепринятые правила хранения критического секретного материала, как видно по дискуссии в списке рассылки debian-project. Эта дискуссия сводится к единственному простому требованию: где взять «руководство по хранению электронных ключей для чайников»? Электронные аппаратные ключи или карты-ключи, как мы их здесь называем — это маленькие устройства, позволяющие хранить ключи в офлайне и представляющие собой один из вариантов защиты секретного материала, то есть ключа. В этой статье я постараюсь поделиться своим опытом в данной области и разъяснить проблему, как хранить эти драгоценные секретные ключи, которые в случае компрометации подвергают опасности миллионы компьютеров по всему миру.

Прежде чем мы в подробностях разберём хранение паролей в офлайне, полезно будет вкратце вспомнить, как работает стандарт OpenPGP. Ключи OpenPGP создаются из главной пары открытого и закрытого ключей, ключа сертификации, который подписывает идентификаторы пользователей, и подключей. Мой публичный ключ, показанный ниже, содержит обычный ключ сертификации/подписи (помечен как SC), а также подключ шифрования (помечен как E), отдельный ключ подписи (S) и два ключа аутентификации (помечены как A), которые я использую в качестве ключей RSA для авторизации на серверах по SSH, спасибо проекту Monkeysphere.

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

Учитывая компромиссы безопасности, для снижения риска предлагается хранить критические ключи в офлайне. Но где конкретно? Джонатан Макдауэлл, член группы обслуживания связки ключей Debian, говорит о трёх вариантах: внешний LUKS-зашифрованный том, отключенная от всех каналов связи изолированная система или карта-ключ.

Полнодисковое шифрование вроде LUKS добавляет дополнительный уровень безопасности, скрывая ключ от злоумышленника. Даже хотя секретные связки ключей обычно защищаются парольной фразой, легко распознать, что это — связка ключей. Но если том полностью зашифрован, то злоумышленнику сразу не очевидно, что на устройстве имеются ключи. По словам Шона Уиттона, ещё одним преимуществом LUKS перед обычным шифрованием связки ключей в GnuPG является то, что при создании раздела LUKS вы можете передать аргумент --iter-time для увеличения задержки на формирование ключа (key derivation), что сильно усложняет брутфорс. В самом деле, у GnuPG 2.x нет опции для конфигурации алгоритма формирования ключа, хотя недавно был представлен патч, который позволяет настраивать задержку формирования ключа во время компиляции gpg-agent . Он теперь отвественен за все операции с секретным ключом.

Недостаток внешних томов — излишняя сложность. GnuPG усложняет процесс извлечения секретов из связки с ключами, что делает первичную установку мудрёной и подверженной ошибкам. В версиях 2.x процедура упростилась благодаря новой системе хранения и соответствующим файлам keygrip , но она по-прежнему требует тайного знания внутреннего устройства GPG. Также неудобно использовать секретные ключи, которые хранятся за пределами вашей основной связки ключей. Когда они действительно нужны, GPG не знает, где их теперь найти.

Другой вариант — установить для операций сертификации отдельную изолированную систему. В качестве примера можно привести проект «чистой комнаты» PGP, это действующая система на базе Debian, которую разработал Дэниэл Покок, чтобы запустить центр сертификации OpenPGP и X.509 на обычном оборудовании. Основной принцип — хранить секретные ключи на отдельной машине, которая никогда не подключается к сети и поэтому не подвержена атакам, по крайней мере, в теории. Лично я отвергаю этот вариант, потому что мне кажется, что изолированные системы дают ложное чувство безопасности: всё-таки данные должны как-то попадать в систему и извлекаться оттуда, даже если речь идёт только об извлечении подписей, что подвергает систему атакам.

Точно так же осложняются обновления ОС: чтобы система оставалась безопасной, на изолированный от сети компьютер нужно своевременно устанавливать обновления. Обычно информация распространяется через USB-флешки, что даёт возможность заразить систему через уязвимости вроде BadUSB. С момента заражения есть куча экзотических способов снимать данные, используя светодиоды, инфракрасные камеры или старую добрую атаку TEMPEST. Поэтому я пришёл к выводу, что выгоды с упрощением процедуры, которые даёт изолированная система, не стоят того. Более того, с изолированными системами на самом деле не так просто работать: дже хотя «чистая комната» PGP прошла долгий путь разработки, у неё по-прежнему нет простых скриптов доля подписи или передачи ключей, то есть здесь такая же проблема, как у подхода с внешними зашифрованными томами LUKS.

Я выбрал подход с использованием криптографических ключей-карт: это внешнее устройство, которое обычно подключается через разъём USB, оно хранит секретный ключ и выполняет критические криптографические операции от имени хоста. Например, карта-ключ FST-01 выполняет дешифровку в схемах асимметричного шифрования RSA и ECC, не выдавая хосту материал секретного ключа. По сути, карта-ключ — это миниатюрный компьютер, который выполняет ограниченный набор вычислений для другого хоста. Карты-ключи обычно поддерживают несколько «слотов» для хранения подключей. Стандарт OpenPGP устанавливает три подключа по умолчанию: для подписи, аутентификации и шифрования. В конце концов, на карте-ключе может находиться реальная физическая вспомогательная клавиатура для ввода паролей, так что потенциальный кейлоггер здесь бессилен, хотя мне в руки не попадались карты-ключи с такими клавиатурами.

Можно легко провести параллель между картами-ключами и изолированной системой; по сути, карта-ключ — это изолированная система в миниатюре, которая страдает от таких же проблем. Злоумышленник может перехватить данные на хосте и атаковать устройство таким же способом, если не проще, потому что карта-ключ в реальности находится «в онлайне» (то есть явно не изолирована) после подключения. Однако преимущество перед полностью изолированным компьютером состоит в том, что карта-ключ выполняет только ограниченный набор операций. Так что создать архитектуру открытого аппаратного и программного обеспечения, которое прошло аудит и проверку, гораздо проще, чем с компьютером общего назначения.

Как и изолированные системы, карты-ключи мешают злоумышленнику получить доступ к секретному ключу. Он может обманом заставить карту-ключ подписать или расшифровать какие-то данные, но это возможно только тогда, когда устройство физически подключено к компьютеру, и карта-ключ запросит у пользователя пароль перед совершением операции, хотя может какое-то время кэшировать пароль. В сущности, офлайновые атаки становятся невозможны: чтобы подобрать брутфорсом пароль к ключу, злоумышленник должен получить доступ к компьютеру жертвы и попытаться подобрать пароль здесь, в то время как карта-ключ допускает только ограниченное количество попыток. Она также предоставляет ясный и стандартный интерфейс для хранения ключей в офлайне: одной командой GnuPG материал секретного ключа перемещается на карту-ключ (команда keytocard в интерфейсе --edit-key ), в то время как перемещение материала на зашифрованное устройство LUKS или изолированный компьютер представляет собой более сложную процедуру.

Карты-ключи также более полезны при работе с несколькими компьютерами. Общая проблема при использовании GnuPG на нескольких машинах — как безопасно копировать и синхронизировать материал секретного ключа на нескольких устройствах, что порождает новые проблемы безопасности. В конце концов, «правило хорошего тона в криминалистической лаборатории», согласно Роберту Хансену из списка рассылки GnuPG — это «хранить как можно меньше персональных данных на своих системах». Карта-ключ здесь хороша с обеих сторон: вы можете использовать свой секретный ключ на нескольких компьютерах, но не будете хранить его многократные копии. На самом деле Майк Гервиц более категоричен:

«Для пользователей, которым ключ GPG нужен на нескольких машинах, я считаю смарт-карту необходимым устройством. В ином случае пользователь просто увеличивает риск компрометации».

Как заметил Гервиц, в использовании карты-ключа всё-таки есть несколько отрицательных моментов. Другой разработчик Debian Вутер Верхельст чётко их сформулировал:

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

Смарт-карты — это ещё и заноза в заднице. Они гарантируют, что секретная половина вашего ключа никогда не попадёт на жёсткий диск или любой другой обычный носитель, а вместо этого лежит у вас в кошельке, так что каждый раз, когда нужен доступ к ней, вам придётся доставать кошелёк, что занимает больше времени, чем просто запустить GnuPG. Если в вашем ноутбуке нет встроенного кард-ридера, то придётся ещё и доставать кард-ридер из рюкзака или откуда-то ещё».

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

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

Заметьте, что в отличие от изолированных систем, сгенерированный картой ключ невозможно забэкапить по определению. Для подключей это не проблема, потому что им не нужны резервные копии (кроме ключей шифрования). Но для ключа сертификации это означает, что пользователь должен сгенерировать ключ на хосте и скопировать его на карту, то есть хост должен обеспечить достаточную энтропию для генерации криптографически стойких случайных чисел, например. Также имейте в виду возможность сочетания разных подходов: например, вы можете использовать карту-ключ для повседневных операций, но хранить резервную копию ключа сертификации на LUKS-зашифрованном офлайновом томе.

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

Наконец, карты-ключи могут поощрять пользователей доверять свои секреты многим машинам, что противоречит принципу «минимального количества персональных данных». Полностью противоположный подход называется Trusted Physical Console (TPC): здесь вместо того, чтобы пытаться доставить секретный ключ на все машины, у вас есть единственная машина, которая используется для всех криптографических операций. В отличие от карты-ключа, TPC — это реальный компьютер, например, ноутбук, которому не требуются специальные процедуры для управления ключами. Недостаток, конечно, в том, что вам придётся везде носить с собой этот ноутбук, что может оказаться проблематичным, особенно в некоторых корпоративных окружениях, где запрещено приносить собственные компьютеры.

Записать ключи на карту достаточно просто:

Существуют неформальные руководства по оптимальному использованию OpenPGP, и кое-где рекомендуют хранение ключей в офлайне, но там редко объясняют, что конкретно имеется в виду. Хранение основного секретного ключа в офлайне очень важно с учётом возможных рисков компрометации, и здесь мы рассмотрели основные способы такого хранения: на изолированной системе, в LUKS-зашифрованной связке ключей или с использованием карт-ключей. Каждый из этих способов имеет свои недостатки, но я рекомендую освоить работу с картами, если вы используете несколько компьютеров и хотите получить стандартный интерфейс с минимальными проблемами конфигурации.

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

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

Читайте также: