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

Question

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

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

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

Answer 1

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

  ( Вывод файла .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-подобными заголовками).

Answer 2

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