Чем, если вообще, SSH-ключи отличаются от асимметричных ключей, используемых для других целей?

Чем, если вообще, SSH-ключи отличаются от асимметричных ключей, используемых для других целей, например для подписи по электронной почте?

Мне предлагается спросить об этом, частично потому, что в OS X есть приложения, доступные для управления ключами SSH (ssh-agent, SSHKeychain и т. Д.), А также приложения, предназначенные для управления ключами GPG (доступ к GPG Keychain и т. Д.), и, видимо, они не встречались. Однако я не верю, что это проблема OS X.

Это разделение интересов, потому что ключи имеют совершенно разные виды, или потому что они хранятся в разных местах, или это по какой-то другой причине или комбинации причин, например, исторических причин?

Источник

2 ответа

Решение

  • Ключи SSH - это просто пары несимметричных ключей RSA, DSA или ECDSA. Такая пара ключей, сгенерированная OpenSSH, уже может использоваться OpenSSL и большинством других программ.

    (The .pub вывод файла ssh-keygen в формате, специфичном для OpenSSH, но это не имеет значения, поскольку "закрытый" файл уже содержит как закрытые, так и открытые ключи.)

    Другое программное обеспечение SSH может иметь свои собственные форматы хранения, такие как RFC 4716 или PPK PuTTY, но они хранят ту же информацию RSA/DSA/ECDSA.

  • X.509 (используется SSL, S/MIME) немного сложнее: "закрытый" ключ остается тем же, но вместо чистого файла открытого ключа у вас есть "сертификат" - структура ASN.1, содержащая открытый ключ, имя субъекта и эмитента, сроки действия. В сертификатах X.509 v3 будут присутствовать такие расширения, как "использование ключа" и "альтернативное имя субъекта". Весь сертификат подписывается ключом эмитента (или самозаверяющим, если нет отдельного эмитента).

    Вы можете легко использовать файл "закрытого ключа" X.509 для SSH - OpenSSH даже использует тот же формат.

    Вы можете создать сертификат X.509 из простой пары ключей и затем самостоятельно подписать его, или вы можете создать "запрос сертификата" и отправить его для подписи в ЦС (центр сертификации).

    Чтобы отобразить информацию в сертификате X.509, используйте:

    certtool -i < foo.pem
certtool -i --inder < foo.crt

openssl x509 -noout -text < foo.pem
openssl x509 -noout -text -inform der < foo.crt

    (certtool является частью GnuTLS.)

  • Ключи OpenPGP (используемые GPG) являются наиболее сложными. То, что вы называете "ключом PGP" или "парой ключей PGP", представляет собой сложную структуру, называемую "сертификат OpenPGP", содержащую:

    • один "первичный ключ" - пара асимметричных ключей, обычно используемая для подписи
    • один или несколько "идентификаторов пользователя" - текстовые метки, обычно в форме "Имя <адрес электронной почты @">
      • по крайней мере один из них помечен как "основной идентификатор пользователя"
      • для каждого идентификатора пользователя "самоподпись" - подпись под собственным первичным ключом
      • для каждого идентификатора пользователя ноль или более "подписей" других пользователей
      • пакеты самоподписи также содержат ваши предпочтительные алгоритмы (SHA-1, AES и т. д.)
    • один или несколько "подразделов" - дополнительные пары ключей, первый обычно для шифрования
      • для каждого подключа подпись по первичному ключу
    • ноль или более "идентификаторов фотографий" - вложения в формате JPEG или PNG, содержащие ваше лицо
      • подписан так же, как идентификаторы пользователей
    • ноль или более сертификатов X.509

    Все пары ключей имеют даты истечения срока действия и биты использования: подписывать данные, сертифицировать (подписывать) ключи, шифровать, аутентифицировать сервисы. Первичный ключ по умолчанию имеет биты "sign" и "certify", а первый подраздел должен "шифровать". Если вы добавляете "аутентификационный" подраздел, вы можете использовать его через gpg-agent для аутентификации SSH.

    Чтобы увидеть, что содержит ваш сертификат:

    gpg --export joe@example.com | gpg -vv

gpg --export joe@example.com | certtool --pgp-certificate-info

    (certtool является частью GnuTLS.)

Сертификаты X.509 и связанные с ними закрытые ключи представлены в нескольких форматах:

  • DER - это двоичное кодирование структуры сертификата ASN.1. Такие файлы обычно имеют .crt или же .cer расширения имени файла (.der менее распространен, но невидим).

  • Файлы формата "PEM" содержат те же данные в кодировке DER, но дополнительно кодируются с использованием Base64 и между заголовками "BEGIN THIS" и "END THAT". Общее расширение имени файла .pemхотя оба .crt а также .cer иногда используются и здесь (но никогда .der).

  • Для закрытых ключей, принадлежащих сертификатам, обычно используется формат "PEM" - Base64, окруженный заголовками "BEGIN PRIVATE KEY" (ключ в структуре PKCS#7) или "BEGIN RSA (или DSA) PRIVATE KEY" (голый ключ, OpenSSL) формат). Иногда ключ находится в отдельном .key файл, иногда в комплекте с сертификатом.

  • PKCS # 12 и немного более старый PFX являются зашифрованными контейнерами, в которых хранятся как сертификат, так и закрытый ключ (часто также сертификат эмитента). Этот формат используется большинством программного обеспечения при экспорте или "резервном копировании" сертификатов с закрытыми ключами.

Менее запутанная ситуация в OpenPGP: все данные следуют одному и тому же двоичному формату и могут быть "защищены" (закодированы в Radix64 и между PEM-подобными заголовками).

Источник

Хранятся в разных местах и ​​в разных форматах (форматы, используемые PGP, GnuPG, sshи несколько разных форматов X.509, среди прочего, довольно разные). Возможно в некоторой степени перекодировать их, смешивая и подбирая правильные параметры для ssh-keygen, pgp, gpg/gpg2, openssl, так далее.; но в целом это не стоит усилий. Кроме того, различные ключевые форматы поддерживают разные объемы информации, с ssh несут наименьшую дополнительную информацию, а форматы X.509 PEM и DER несут больше всего. Кроме того, цепочка для ключей OSX является просто зашифрованным хранилищем ключ / значение, поэтому каждому приложению обычно нужен свой механизм для преобразования между собственным ключом программы + форматом метаданных и чем-то, что может храниться в цепочке для ключей. (Аналогичные проблемы касаются кошелька KDE и цепочки для ключей GNOME.)

Источник
Другие вопросы по тегам