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

103

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

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

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

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

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

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

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

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

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

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

TL; DR

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

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

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

Джастин С
источник

Ответы:

59

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

Джастин С
источник
5
Хорошие вопросы и ответы, но AFAIK есть еще одна проблема с этой настройкой ... Это отлично подходит для подписи, но не для шифрования, если вы не хотите разделять один и тот же ключ enc между вашими различными устройствами, потому что, когда кто-то делает вас получателем зашифрованного сообщение, gpg по умолчанию использует последний не отозванный ключ enc. Невозможно заставить отправителей использовать определенный подраздел enc в зависимости от UID (домашний или рабочий, и т. Д.).
KurzedMetal
2
Возможно, это проблема. Мое самое большое беспокойство - потеря сети доверия, которую я строю вокруг своего мастер-ключа (который только подписывает). Конечно, ключ шифрования должен существовать на всех устройствах, которые я использую для чтения зашифрованных сообщений. Если мой ключ шифрования когда-либо скомпрометирован, то в процессе восстановления участвует только я; в отличие от потери моего основного ключа подписи и необходимости просить / убедить мою сеть доверия подписать новый ключ. Я не собирался перемещать подраздел шифрования в моем хранилище.
Джастин C
9

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

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

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

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

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

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

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

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

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