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

Хранение закрытого ключа 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.

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

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

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

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