Удалите ненужную скрытую криптографию с открытым ключом GPG

Question

Фон:

1. Некоторые существующие программы, такие как git-annex (шифрование git-annex) и pass, делегируют криптографию GPG, «полную и бесплатную реализацию стандарта OpenPGP ». В частности, эти программы используют идентификаторы ключей GPG как способ взаимодействия с GPG:

   • GPG используется для создания и управления парами открытых / закрытых ключей GPG.

   • Программа получает указание использовать определенную пару открытых / закрытых ключей GPG через идентификатор ключа.

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

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

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

4. Асимметричная криптография имеет два уровня безопасности:

   (а) закрытый ключ симметрично шифруется парольной фразой

   (б) (зашифрованный) закрытый ключ хранится в безопасном месте

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

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

   • генерировать частную случайную строку

   • симметрично зашифровать частную случайную строку, используя фразу-пароль, хранить в частном порядке

   • симметрично зашифровать сообщение с частной случайной строкой, хранить публично

5. Далее описывается, что происходит под капотом, когда такая программа, как pass использует GPG через идентификатор ключа GPG. (Предположим, что криптография с открытым ключом - это RSA, а симметричная криптография - это AES.) Во-первых, GPG используется для:

   (i) создать пару открытых / закрытых ключей RSA

   (ii) Открытый ключ RSA не зашифрован, хранится в частном порядке (жесткий диск) или публично (сервер ключей)

   (iii) AES-шифрованный закрытый ключ RSA с парольной фразой, хранится в частном порядке

   Далее, после шифрования OpenPGP, вот как работает шифрование:

   (iv) генерировать случайный ключ сеанса

   (v) AES-шифрованное сообщение с сеансовым ключом, хранится публично

   (vi) RSA-шифрованный сеансовый ключ с открытым ключом RSA, хранится публично

   Заметим , что сообщение скомпрометирован разбив либо (v) или (VI).

Ненужная потенциальная уязвимость:

Предположим, что в будущем квантовые компьютеры будут разработаны, а RSA сломана. (Для параноика, предположим, что RSA уже сломан.) Хотя это внесет изменения в то, как мы делаем такие вещи, как онлайн-банкинг, это также окажет совершенно ненужное негативное влияние на безопасность данных, создаваемых pass/git-annex .

Насколько это плохо, зависит от того, хранится ли открытый ключ RSA из (ii) выше публично или конфиденциально. Если они хранятся публично, данные уже скомпрометированы: злоумышленник может расшифровать (vi) получение ключа сеанса, а затем расшифровать (v) с помощью ключа сеанса, чтобы получить сообщение. Если открытый ключ RSA из (ii) фактически остается закрытым, безопасность данных снижается до (b) безопасности носителя, содержащего открытый ключ RSA, что эквивалентно выполнению асимметричного шифрования без ключевой фразы.

Эта уязвимость, вне зависимости от того, извлечена она или нет, совершенно не нужна, поскольку она вызвана ненужным использованием криптографии с открытым ключом, присущей существующему интерфейсу между такими программами, как pass/git-annex и GPG (через идентификаторы ключей GPG).

Вопрос:

Есть ли "относительно простой" способ:

• убрать использование асимметричного шифрования, когда GPG используется под капотом через идентификаторы ключей GPG

• продолжать использовать GPG для управления ключами, как и раньше

• поддерживать двухуровневую безопасность, упомянутую в 4 как (а) и (б)

Полная схема, которую я ищу:

(я) генерировать частную случайную строку

(ii ') AES-шифрует частную случайную строку с парольной фразой, хранит конфиденциально

(iii ') AES-шифрованное сообщение с частной случайной строкой, хранится публично

Я понимаю, как выполнить каждый из этих шагов отдельно, но то, о чем я спрашиваю, - это лучший способ включить такое "исправление" в способ, которым программы могут использовать GPG через идентификаторы ключей GPG. В частности, я ожидаю, что такие программы будут выполнять внешние вызовы в форме gpg --encrypt --recipient <keyid> и gpg --decrypt .

Вывод: кажется, что волшебной пули не существует, и перехват этих вызовов с помощью сценария-оболочки gpg - единственный путь. Возможно, GPG следует рассмотреть эту проблему в будущем.

Answer 1

Симметричная криптография в OpenPGP

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

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

Симметричное шифрование OpenPGP делает то же самое, но вместо этого получает ключ сессии из ключевой фразы. В зависимости от конфигурации, в этом процессе добавляется немного соли (и GnuPG имеет разумные значения по умолчанию). Здесь нет открытых или закрытых ключей (как у вас было бы с RSA). В GnuPG именно это возможно, применив параметр --symmetric .

Есть ли способ заставить gpg выполнять чисто симметричное шифрование таким образом, чтобы парольная фраза использовалась только для защиты закрытого ключа, как при асимметричном шифровании? Естественно, что для расшифровки понадобятся и пароль, и закрытый ключ.

Если вам нужно что-то вроде «могу ли я сохранить ключ сеанса отдельно, зашифрованный парольной фразой вместо использования функции строки-ключа OpenPGP, и зашифровать этот ключ сеанса парольной фразой»: нет, это невозможно в течение протокол OpenPGP. Но вы можете в значительной степени имитировать такую операцию, храня пару открытый / закрытый ключ в одном месте, все еще зашифрованную с помощью ключевой фразы. Фраза-пароль будет использоваться для расшифровки закрытого ключа всякий раз, когда он будет использоваться.

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

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

Переопределение ключей сеанса

В ваших обновлениях вы уточнили свои цели.

Полная схема, которую я ищу:

(я) генерировать частную случайную строку

(ii ') AES-шифрует частную случайную строку с парольной фразой, хранит конфиденциально

(iii ') AES-шифрованное сообщение с частной случайной строкой, хранится публично

Вы не можете точно достичь этого, но GnuPG знает (нестандартизированный) способ извлечения и определения ключей сеанса для использования. От man gpg:

--show-session-key

Показать сеансовый ключ, используемый для одного сообщения. См. --override-session-key для аналога этой опции.

Мы думаем, что ключ сделки является плохой вещью; однако пользователь должен иметь возможность самостоятельно решать, отправляться ли в тюрьму или раскрывать содержание одного конкретного сообщения без ущерба для всех сообщений, когда-либо зашифрованных для одного секретного ключа. НЕ ИСПОЛЬЗУЙТЕ ЕГО, ЕСЛИ ВЫ НЕ ДЕЙСТВИТЕЛЬНО ПРИВЯЗАНЫ ДЕЛАТЬ.

--override-session-key string

Не используйте открытый ключ, кроме строки сессионного ключа. Формат этой строки такой же, как и для печати --show-session-key . Эта опция обычно не используется, но удобна, если кто-то заставляет вас раскрыть содержимое зашифрованного сообщения; используя эту опцию, вы можете сделать это без раздачи секретного ключа.

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

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