Как управлять ключами GPG в разных системах?

Question

Я новичок в использовании GnuPG и пытаюсь понять, как лучше его использовать. Я рассмотрел краткое, простое для понимания объяснение GPG/PGP для нетехнических людей?, но большинство руководств объясняют PGP с точки зрения одной машины.

Я хочу использовать GnuPG на трех вычислительных устройствах: ПК с Linux, ноутбуке с Linux и телефоне на Android.

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

Я полагаю, что мой выбор:

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

2. Создайте мастер-ключ (с --gen-key) для представления моей личности, затем создайте отдельный одноразовый ключ (снова с --gen-key) для шифрования / дешифрования писем и подписанный с помощью мастер-ключа. Первый находится только на моем ПК, последний распространяется на каждое устройство. Пока мои мобильные устройства не взломаны, одноразовый ключ остается в силе.

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

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

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

Извините за действительно длинный вопрос. :-)

TL; DR

Является ли пароль достаточной защитой для хранения моего главного закрытого ключа на нескольких устройствах?

Возможен ли мой план по варианту № 2? Я что-то не так понял или можно улучшить?

Если вариант № 2 является плохой идеей, то каковы лучшие практики при использовании GnuPG для одного пользователя на нескольких устройствах?

Answer 1

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

Исследуя, что такое подключи и почему они могут использоваться вместо --gen-key, я наткнулся на этот камень: http://wiki.debian.org/subkeys.

В вики Debian объясняется, как реализовать опцию № 2 (см. OP) с использованием мастер-ключа с подключами, а также объясняется, как удалить мастер-ключ из любой системы после сохранения его на резервном носителе (например, на флэш-диске). Подключи могут быть распределены среди моих ключей на каждом устройстве.

Плюсы:

1. Не полагается в основном на пароль для защиты главного ключа,

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

3. Это практика, применяемая командой разработчиков Debian.

4. Использует функцию подключа GnuPG. Который кажется немного более организованным, чем куча свободных ключей на вашей связке ключей, да?

Соответствующая часть из Вики-раздела Debian

1. Сделайте резервные копии ваших существующих файлов GnuPG ($ HOME/.gnupg). Держите их в безопасности. Если что-то пойдет не так во время следующих шагов, вам может понадобиться это, чтобы вернуться в известное хорошее место. (примечание: umask 077 приведет к ограничению разрешений для резервного копирования.)

   • umask 077; tar -cf $HOME/gnupg-backup.tar -C $HOME .gnupg

2. Создайте новый подраздел для подписи.

   • Найдите свой идентификатор ключа: gpg --list-keys yourname
   • gpg --edit-key YOURMASTERKEYID
   • В приглашении gpg> addkey
   • Это попросит вашу фразу-пароль, введите его.
   • Выберите тип ключа «RSA (только подпись)».
   • Было бы разумно выбрать размер ключа в 4096 (или 2048) бит.
   • Выберите дату истечения срока действия (вы можете вращать свои подразделы чаще, чем мастер-ключи, или сохранять их в течение всего срока действия мастер-ключа без истечения срока действия).
   • GnuPG (в конце концов) создаст ключ, но вам, возможно, придется подождать, пока он наберет достаточно энтропии для этого.
   • Сохранить ключ: save

3. Вы можете повторить это и создать дополнительный ключ «RSA (только шифрование)», если хотите.

4. Теперь скопируйте $HOME/.gnupg на ваши USB-накопители.

5. Здесь начинается сложная часть. Вам необходимо удалить закрытый мастер-ключ, и, к сожалению, GnuPG не предоставляет удобный способ сделать это. Нам нужно экспортировать подключ, удалить закрытый ключ и импортировать подраздел обратно.

   • Экспортируйте подключи: gpg --export-secret-subkeys YOURMASTERKEYID >secret-subkeys (чтобы выбрать, какие подключи нужно экспортировать, укажите каждый из идентификаторов подключей с восклицательным знаком: gpg --export-secret-subkeys SUBKEYID! [SUBKEYID! ..])
   • Удалите ваш главный секретный ключ: gpg --delete-secret-key YOURMASTERKEYID
   • Импортируйте подключи обратно: gpg --import secret-subkeys
   • Убедитесь, что gpg -K показывает sec# вместо sec для вашего личного ключа. Это означает, что секретный ключ на самом деле не существует. (См. Также наличие фиктивного пакета OpenPGP в выходных данных gpg --export-secret-key YOURMASTERKEYID | gpg --list-packets).
   • При необходимости измените фразу-пароль, защищающую подключи: gpg --edit-key YOURMASTERKEYID passwd . (Обратите внимание, что материал закрытого ключа в резервной копии, включая закрытый главный ключ, останется защищенным старой парольной фразой.)

Ваш компьютер теперь готов к нормальному использованию.

Когда вам нужно использовать мастер-ключи, подключите зашифрованный USB-накопитель и установите переменную среды GNUPGHOME:

export GNUPGHOME=/media/something
gpg -K

или используйте аргумент командной строки --home:

gpg --home=/media/something -K

Последняя команда должна теперь перечислить ваш закрытый ключ с sec а не sec# .

Несколько подключей на машину против одного отдельного подключа для всех машин

Выдержка из вики-раздела Debian. Первоначально отмечено в комментариях. [Перефразируя] и акцент мой.

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

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

Answer 2

Как человек, которому также не нравятся отдельные точки отказа (включая мастер-ключи и особенно пароли), я бы так и сделал. Это позволяет устройствам работать через сеть доверия, в то же время позволяя децентрализованную идентификацию.

Я не знаю, существует ли уже существующая система для этого, но я думаю, что она, вероятно, может быть уничтожена вместе с работой cron и несколькими строками Bash.

В этой системе у вас есть два класса пар ключей: пары устройств и таймфреймы. Одна пара ключей устройства генерируется для пользователя на каждом устройстве и остается на этом устройстве в течение всего срока его службы. Пара ключей таймфрейма генерируется центральным сервером через регулярные интервалы (ежемесячно, ежедневно, ежечасно - зависит от того, каким параноиком вы хотите быть). Открытый ключ объявляется публично (сам сервер имеет собственную пару ключей устройства для подписи), а закрытый ключ распространяется в зашифрованном виде с открытым ключом каждого устройства, которое должно иметь доступ к этому ключу. (Это распределение должно быть как можно более приватным, например, иметь устройства, подключенные к серверу напрямую.)

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

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

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

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

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