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

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

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

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

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

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

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

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

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

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

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

TL; DR

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

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

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

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

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

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

Плюсы:

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

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

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

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

Соответствующая часть из Вики Debian Subkey

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

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

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

   • Найдите свой ключ ID: 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 шифрует только для самого последнего подраздела шифрования, а не для всех известных и не отозванных подразделов шифрования.

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

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

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

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

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

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

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

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