Duplicity — шифрование ключей GPG с несколькими устройствами

Duplicity — шифрование ключей GPG с несколькими устройствами

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

Что у меня есть сегодня:

  • Главный ключ GPG, сгенерированный в автономном режиме с помощью tails, следуя этому руководству:https://wiki.debian.org/GnuPG/AirgappedMasterKey
  • с2 защищенных паролем подключаемых ключа: один дляшифрование, и один дляподписание
  • Команды резервного копирования Duplicity запускаются с помощью Duply, который сохраняет зашифрованную резервную копию в удаленном облачном хранилище типа S3, размещенном Scaleway:https://www.scaleway.com/fr/object-storage/ Используя ключи шифрования, сгенерированные выше.

Мне удалось успешно отправить зашифрованные данные в удаленное хранилище и восстановить из него резервные копии файлов.

Теперь у меня есть 2 проблемы с этой настройкой:

  1. Мне приходится вводить ключевую фразу при каждой операции резервного копирования.

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

-> следует ли использовать подключ sign, который не защищен паролем? Это тоже не кажется правильным решением...

  1. Я хочу сделать резервную копию с нескольких устройств

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

Для начала, «не кладите яйца в одну корзину» можно также понимать так, что вам не следует полагаться на одну пару ключей PGP во всем. Например, вам следует создать пару ключей «резервное копирование/хранение» отдельно от пары ключей «электронная почта/Git». В конце концов, у них совершенно разное применение и требования — ваши резервные копии полностью внутренние, поэтому они в любом случае не выигрывают от подписи вашей «основной» парой ключей PGP.

=> Это имеет смысл, спасибо. Создание новой резервной копии определенной пары ключей кажется разумным.

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

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

-> Какова рекомендуемая стратегия? Насколько я понимаю, на сегодняшний день невозможно управлять несколькими шифрованием/подписями подключей с помощью одного и того же главного ключа GPG? Стоит ли мне генерировать несколько главных ключей для резервного копирования?

Попробую подвести итог:

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

Это имеет смысл? Еще раз спасибо за помощь!

решение1

Я хочу сделать резервную копию с нескольких устройств

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

Для начала, «не кладите яйца в одну корзину» можно также понимать так, что вам не следует полагаться на одну пару ключей PGP во всем. Например, вам следует создать пару ключей «резервное копирование/хранение» отдельно от пары ключей «электронная почта/Git». В конце концов, у них совершенно разное применение и требования — ваши резервные копии полностью внутренние, поэтому они в любом случае не выигрывают от подписи вашей «основной» парой ключей PGP.

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

Насколько я понимаю, на сегодняшний день невозможно управлять несколькими подключами шифрования/подписи с помощью одного и того же главного ключа GPG?

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

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

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

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

Найдите «ключевую фразу» каждого закрытого ключа из gpg -K --with-keygrip, а затем используйте ее gpg-connect-agentдля изменения его парольной фразы напрямую (минуя GnuPG):

gpg-connect-agent "passwd KEYGRIP" /bye

Связанный контент