Як керувати ключами GPG в декількох системах?

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

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

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

Я думаю, що мої варіанти є:

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

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

Я можу бути надмірно параноїком і зробити це складнішим, ніж це має бути, але жартівте мене, будь ласка. Я вірю в те, що не класти всі яйця в один кошик.

Головним ключем повинен бути мій цифровий ідентифікатор. Багато зусиль буде витрачено на створення довіри навколо цієї ідентичності, і я скоріше зазнаю незручностей своєї паранойї, ніж втрачу свій ключ від необережності і мушу будувати довіру навколо нового головного ключа (можливо, це не так погано, як я подумайте, але я новачок у цьому) .

Я швидше втрачу ноутбук або телефон, ніж свій ПК. Якщо втрата == компроміс, я краще втрачу одноразову пару ключів (яку я можу відкликати), ніж мою основну пару ключів. Я завжди можу дарувати довіру свого головного ключа новому одноразовому ключу.

Вибачте за справді довге запитання. :-)

TL; DR

Чи достатній захист паролем для зберігання мого головного приватного ключа на кількох пристроях?

Чи можливий мій план варіанту №2? Я щось помилився чи це можна покращити?

Якщо варіант №2 - це погана ідея, то які найкращі практики використання GnuPG для одного користувача на кількох пристроях?

Ну, це трохи бентежить. Я витратив години протягом тижня, намагаючись вирішити цю проблему, і відповідь, схоже, лежить у підрозділах - тема, посібник GnuPG та FAQ часто закінчуються.

Досліджуючи, що таке підрозділи та чому їх можна використовувати замість --gen-key, я натрапив на цей самоцвіт: http://wiki.debian.org/subkeys .

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

Плюси:

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

2. Якщо будь-яка система порушена, головний ключ не одразу доступний (якщо тільки я не дурно залишатиму флешку підключеною або приєднаю згаданий диск до компрометованої системи),

3. Це практика, яку реалізує команда розробників Debian.

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

Відповідна частина від Debian Subkey Wiki

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, як кажуть, шифрується лише для останнього підрозділу шифрування, а не для всіх відомих і не відкликаних підрозділів шифрування.

Як хтось, хто також не любить поодинокі пункти відмови (включаючи головні ключі та особливо паролі), саме так я б це зробив. Це дозволяє пристроям працювати через мережу довіри, при цьому все ще дозволяє децентралізовану ідентичність.

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

У цій системі у вас є два класи керування клавішами : клавіатури пристроїв та клавіші часових кадрів . Для кожного пристрою генерується одна клавіша пристрою та залишається на цьому пристрої протягом усього життя. Таймфрейм пара ключів генерується центральним сервером в звичайних інтервалах (щомісяця, щодня, щогодини - залежить від того, як параноїк ви хочете бути). Відкритий ключ оголошується публічно (сам сервер має власну клавішу пристрою для підписання), а приватний ключ поширюється зашифрованим відкритим ключем кожного пристрою, який повинен мати доступ до цього ключа. (Цей розподіл повинен бути максимально приватним, наприклад, з пристроями, що підключаються безпосередньо до сервера.)

Для підписання повідомлень ви б використовували ключ пристрою будь-якого пристрою, з якого ви надсилаєте повідомлення. Якщо хтось хоче надіслати вам повідомлення, він може підписати його за допомогою вашого поточного відкритого ключа. (У них повинна бути автоматизована система, щоб не відставати від оголошень.) Потім ви можете прочитати їх повідомлення з будь-якого пристрою.

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

Якщо пристрій викрадено або зламано іншим чином, ви можете використовувати інший із своїх публічно довірених пристроїв, щоб створити повідомлення, підписане публічно, що підтверджує вашу особу (будь-якими способами, наприклад, зазначивши, що ви будете на публічній зустрічі та / або мати надійного друга, перевірити вас особисто) та відкликати компрометований ключ пристрою та будь-які ключі часових рамок, до яких він мав доступ. Відкликаючи ключ, ви також видаляєте викрадений пристрій із списку надійних пристроїв (із паролем та вашим довіреним ключем пристрою).

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

Якщо ваш сервер порушений, ви просто скасуєте його за тією ж процедурою, що описана для будь-якого іншого компрометованого пристрою (можливо, з більш сильною політикою, подібною до тієї, що стосується додавання нового пристрою), і використовувати повторно захищений або зовсім новий сервер (з нова клавіатура пристрою) йде вперед.