1

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

Итак, серверы ключей SKS предоставляют свой сертификат HKPS вместе с этими частями информации:

  1. Ссылка для скачивания сертификата
  2. Ссылка для скачивания подписи OpenPGP
  3. Ссылка для скачивания CRL (список отзыва сертификатов ??)
  4. Отпечаток сертификата: 79:1B:27:A3:8E:66:7F:80:27:81:4D:4E:68:E7:C4:78:A4:5D:5A:17
  5. X509v3 Идентификатор ключа субъекта: E4 C3 2A 09 14 67 D8 4D 52 12 4E 93 3C 13 E8 A0 8D DA B6 F3

Все, что я имею на моей стороне, это gpg (GnuPG) 2.2.10 и доступ в интернет.

Мои вопросы:

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

1 ответ1

0

Во-первых, обратите внимание, что вы можете полностью пропустить весь процесс, поскольку сертификат CA пула SKS связан с последними дистрибутивами GnuPG, обычно расположенными по адресу /usr/share/gnupg/sks-keyservers.netCA.pem .

Во-вторых, обратите внимание, что использование HKPS не аутентифицирует данные, хранящиеся в пуле. Это всего лишь мера конфиденциальности (чтобы предотвратить раскрытие всего набора ключей с помощью ключа --refresh-keys). Но фактические блоки ключей PGP, полученные с серверов ключей, все еще должны проверяться так же, как вы всегда это делали. То есть вы все равно должны проверять отпечаток каждого импортированного ключа или полагаться на Web-of-Trust или gofu.db GnuPG.

Так что когда дело доходит до:

Как мне выяснить, чей открытый ключ я должен загрузить с сервера ключей отдельно (чтобы я не доверял их веб-сайту в одиночку)?

Если бы кто-то мог скомпрометировать сайт, чтобы загрузить поддельный CA.pem, он мог бы также загрузить поддельную подпись CA.pem.asc вместе с ней. И если бы кто-то мог вставить поддельный открытый ключ на веб-сайт, он мог бы загрузить этот же ключ на сервер ключей.

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

( Для того, чтобы знать , что человек управляет SKS бассейн, я бы сказал , что технические средства не являются достаточными. Мой подход состоит в том, чтобы собирать информацию из разных источников, например, спрашивать других людей или проверять web.archive.org, или запрашивать на канале IRC GnuPG (если вы доверяете случайным пользователям IRC). Если вы продолжаете видеть одного и того же человека "Кристиан Фискерстранд" повсюду, это, вероятно, правильный вариант.)

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

Возможно, вы можете проверить различные моментальные снимки на веб-сайте по адресу web.archive.org (чтобы увидеть, существовал ли тот же ключ в течение последних нескольких месяцев или лет).

Как предполагается использовать каждый фрагмент информации?

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

Чтобы просмотреть отпечаток сертификата (SHA1):

openssl x509 -in $file -noout -fingerprint -sha1
certtool --fingerprint < $file
cat $file | sed "/^-/d" | base64 -d | sha1sum

Для просмотра идентификатора ключа субъекта X.509v3 необходимо обратить внимание на разницу между вычислением хэша SPKI самостоятельно (как показано в разделе "Другая информация") по сравнению с простым просмотром встроенного в расширения X.509 (как показано в разделе "Расширения"):

certtool -i < $file | grep -C3 "Public Key ID"

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

Подпись сделана владельцем веб-сайта и может быть использована для проверки файла CA.pem, если у вас уже есть другие средства проверки для ключа PGP владельца. Простая загрузка его с того же сайта не добавляет много.

Чтобы проверить подпись:

gpg --verify sks-keyservers.netCA.pem.asc

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .