Как проверить сертификат SK-keyservers HKPS?

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 и доступ в интернет.

Мои вопросы:

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

Ответы:

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 вместе с ним. И если бы кто-то мог вставить поддельный открытый ключ на веб-сайт, он мог бы загрузить этот же ключ на сервер ключей.

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

(Знать что человек управляет пулом 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
grawity
источник
Прежде всего, спасибо за этот информативный ответ. Я понимаю, что большая часть того, о чем я спрашиваю, не нужна, но все же хочу знать это для моего собственного образования. У меня есть только один дополнительный вопрос: как именно я могу проверить мой загруженный сертификат по отпечатку пальца и SKI, предоставленным на сайте?
CBlew
Отпечаток первичного ключа: [около 32-х символьного хэша] gpg2 --verify $ file.asc $ file, а также убедитесь, что первичный отпечаток соответствует ТОЧНО тому, что сайт утверждает, что это должно быть
linuxdev2013