Чим взагалі відрізняються ключі SSH від асиметричних ключів, які використовуються для інших цілей?

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

Мені пропонується запитати це частково, тому що в OS X є доступні програми для управління ключами SSH (ssh-агент, SSHKeychain тощо), а також програми, призначені для управління ключами GPG (GPG Keychain Access тощо), і, мабуть, не зустрічаються твейн. Однак я не вірю, що це проблема, характерна для ОС X X.

Це поділ проблем, тому що ключі бувають зовсім різного роду, або тому, що вони зберігаються в різних місцях, чи це з якоїсь іншої причини чи поєднання причин, наприклад, історичних причин?

• Ключі 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 з простої клавіатури, а потім підписати його самостійно, або ви можете створити "запит на сертифікат" і подати його на підпис CA (органу з сертифікації).

  Щоб відобразити інформацію в сертифікаті 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 keypair", - це складна структура, яка називається "сертифікат OpenPGP", що містить:

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

  Усі клавішні файли мають термін придатності та біти використання: підписувати дані, сертифікувати (підписувати) ключі, шифрувати, автентифікувати послуги. У первинному ключі за замовчуванням є "знак" та "сертифікація" бітів, а перший підрозділ - "шифрування". Якщо ви додасте підрозділ "аутентифікація", ви можете використовувати його 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, оточений заголовками "ПОЧАК ПРИВАТНОГО КЛЮЧА" (ключ у структурі PKCS # 7) або "НАЧАЙТЕ РИСА (або DSA) ПРИВАТНИЙ КЛЮЧ" (головий ключ, 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 Keychain - це просто зашифроване зберігання ключів / значень, тому для кожної програми, як правило, потрібен інший механізм для перетворення між нативним ключем програми + форматом метаданих та тим, що може зберігатися у брелоку. (Аналогічні проблеми стосуються гаманця KDE та брелока GNOME.)