Как безопасно сделать резервную копию закрытого ключа GPG?

Я нашел очень интересный менеджер паролей CLI, который называется pass . Чтобы использовать его, вы генерируете пару ключей GPG2 и используете этот инструмент, чтобы помочь вам хранить пароли в зашифрованных файлах gpg2.

Чтобы зашифровать файлы (добавить новый пароль), он использует открытый ключ.

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

Это прекрасно работает.

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

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

У меня такой вопрос: как мне безопасно сделать резервную копию закрытого и открытого ключей, чтобы в случае необходимости восстановить «базу данных» на другом компьютере? Могу ли я просто сохранить как открытый, так и закрытый ключи в моем git-репо и импортировать их позже на другой компьютер? Или считается небезопасной практикой хранить закрытый ключ в закрытом локальном репозитории git? Для доступа к git-репо требуется пароль. Закрытый ключ зашифрован и для его открытия требуется пароль. Безопасно ли это для хранения?

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

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

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

Признавая, что безопасность хранилища не идеальна, и тем более в современной среде, где люди регулярно выполняют резервное копирование в облачные сервисы (что буквально переводится как «чужой компьютер»), мы обычно защищаем наши секретные ключи с помощью парольных фраз. Я верю, что даже если вы используете, например, gpg-agent, вы делаете то же самое.

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

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

Я недавно рассматривал подобную установку. Прежде чем заняться вашим вопросом, позвольте мне указать, что беспокоит меня об этом. Это подробно объясняется здесь . Короче говоря, когда Pass вызывает GPG, он выполняет ненужную асимметричную (RSA / EC) криптографию под капотом. Ненужное - потому что здесь нет ненадежной стороны.

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

Чтобы смягчить эту слабость, по крайней мере, вы могли бы сохранить открытый ключ GPG, используемый также с Pass private, потому что, например, (потенциальной) квантовой атаке нужен этот открытый ключ: см. Здесь .

Что касается вашего реального вопроса, неясно, намереваетесь ли вы хранить git-репо (с паролями) публично или в частном порядке. Если вы хотите сохранить его в тайне, вы можете делать то, что хотите, и снизить безопасность закрытого ключа GPG до среды, на которой вы создаете резервную копию репо. Однако это может стать проблемой для курицы и яйца: если репозиторий является частным, как вы получите его обратно в случае сбоя? Другими словами, в случае «плохого сбоя», сначала должно быть что-то, что вы извлекаете . Таким образом, вы можете захотеть сохранить конфиденциальность git-репо, но сделайте резервную копию ключа GPG таким образом, чтобы вы могли сначала получить его независимо от чего-либо еще.

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

• Создайте супер-сильную фразу-пароль, которую нельзя вводить годами. Предложение: длинное, запоминающееся неправильное написание фразы, имеющей какое-то личное значение, или из книги, у которой не останется копий, если вам нужно ее найти.

• Создайте архив с вашим экспортированным секретным ключом GPG и, возможно, вашими учетными данными SSH.

• Зашифровать его симметрично кодовую фразу: gpg --symmetric --armor.

• Создайте бесплатный аккаунт на git хостинге.

• Создайте публичный репозиторий, который можно клонировать без учетных данных.

• Поместите зашифрованный и бронированный тарный шарик туда.

Чтобы восстановить его после «плохого сбоя»:

• Загрузите живую флешку.

• Клон публичного репо.

• gpg --decrypt,

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

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

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

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

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

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