En quoi, le cas échéant, les clés SSH diffèrent-elles des clés asymétriques utilisées à d'autres fins?

En quoi, le cas échéant, les clés SSH diffèrent-elles des clés asymétriques utilisées à d'autres fins, par exemple la signature d'e-mails?

Je suis invité à poser cette question, en partie, car sous OS X, il existe des applications disponibles pour gérer les clés SSH (ssh-agent, SSHKeychain, etc.) ainsi que des applications conçues pour gérer les clés GPG (GPG Keychain Access, etc.), et apparemment jamais les deux se rencontrent. Cependant, je ne pense pas que ce soit un problème spécifique à OS X.

Cette séparation des préoccupations est-elle due au fait que les clés sont de types très différents, ou parce qu'elles sont stockées dans des endroits différents, ou est-ce pour une autre raison ou une combinaison de raisons, par exemple des raisons historiques?

• Les clés SSH sont simplement des paires de clés asymétriques RSA, DSA ou ECDSA. Une telle paire de clés générée par OpenSSH peut déjà être utilisée par OpenSSL et la plupart des autres programmes.

  (Le .pubfichier généré par ssh-keygenest au format spécifique à OpenSSH, mais cela n'est pas pertinent car le fichier "privé" contient déjà des clés privées et publiques.)

  D'autres logiciels SSH peuvent avoir leurs propres formats de stockage, tels que RFC 4716 ou PPK de PuTTY , mais ils stockent les mêmes informations RSA / DSA / ECDSA.

• X.509 (utilisé par SSL, S / MIME) est légèrement plus compliqué: la clé "privée" est toujours la même, mais au lieu d'un fichier de clé publique nue, vous avez un "certificat" - une structure ASN.1 contenant le clé publique, noms des sujets et des émetteurs, dates de validité. Dans les certificats X.509 v3, des extensions telles que «utilisation des clés» et «autre nom de sujet» seront présentes. L'ensemble du certificat est signé par la clé de l' émetteur (ou auto-signé s'il n'y a pas d'émetteur distinct).

  Vous pouvez facilement utiliser un fichier "clé privée" X.509 pour SSH - OpenSSH utilise même le même format.

  Vous pouvez créer un certificat X.509 à partir d'une simple paire de clés, puis le signer automatiquement, ou vous pouvez créer une "demande de certificat" et la soumettre à la signature d'une autorité de certification (autorité de certification).

  Pour afficher les informations dans un certificat X.509, utilisez:

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

  ( certtoolfait partie de GnuTLS.)

• Les clés OpenPGP (utilisées par GPG) sont les plus compliquées. Ce que vous appelez une "clé PGP" ou "paire de clés PGP" est une structure complexe appelée "certificat OpenPGP", contenant:

  • une "clé primaire" - une paire de clés asymétriques, généralement utilisée pour la signature
  • un ou plusieurs "ID utilisateur" - étiquettes textuelles, généralement sous la forme de "Nom <adresse e-mail @>"
    • au moins l'un d'entre eux est marqué comme "ID utilisateur principal"
    • pour chaque ID utilisateur, une "auto-signature" - signature par votre propre clé primaire
    • pour chaque ID utilisateur, zéro ou plusieurs «signatures» d'autres utilisateurs
    • les paquets d'auto-signature contiennent également vos algorithmes préférés (SHA-1, AES, etc.)
  • une ou plusieurs "sous-clés" - paires de clés supplémentaires, la première sert généralement au chiffrement
    • pour chaque sous-clé, une signature par la clé primaire
  • zéro ou plusieurs "pièces d'identité avec photo" - pièces jointes JPEG ou PNG contenant votre visage
    • signé de la même manière que les ID utilisateur
  • zéro ou plusieurs certificats X.509

  Toutes les paires de clés ont des dates d'expiration et des bits d'utilisation: signer les données, certifier (signer) les clés, chiffrer, authentifier auprès des services. Par défaut, la clé primaire a des bits "signer" et "certifier" et la première sous-clé est de "chiffrer". Si vous ajoutez une sous-clé "d'authentification", vous pouvez l'utiliser gpg-agentpour l'authentification SSH.

  Pour voir ce que contient votre certificat:

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

  ( certtoolfait partie de GnuTLS.)

Les certificats X.509 et leurs clés privées associées se présentent sous plusieurs formats:

• DER est un codage binaire d'une structure ASN.1 du certificat. Ces fichiers ont généralement des extensions de nom de fichier .crtou .cer( .derest moins courant mais pas invisible).

• Les fichiers au format "PEM" contiennent les mêmes données encodées DER, mais également encodées en utilisant Base64 et entre les en-têtes "BEGIN THIS" et "END THAT". Une extension de nom de fichier commune est .pem, bien que les deux .crtet .cersoient parfois utilisées ici aussi (mais jamais .der).

• Pour les clés privées appartenant aux certificats, le format "PEM" est généralement utilisé - Base64 entouré d'en-têtes "BEGIN PRIVATE KEY" (clé dans une structure PKCS # 7) ou "BEGIN RSA (ou DSA) PRIVATE KEY" (clé nue, OpenSSL format). Parfois, la clé se trouve dans un .keyfichier séparé , parfois elle est fournie avec le certificat.

• PKCS # 12 et le PFX légèrement plus ancien sont des conteneurs chiffrés stockant à la fois le certificat et la clé privée (souvent le certificat de l'émetteur également). Ce format est utilisé par la plupart des logiciels lors de l'exportation ou de la «sauvegarde» de certificats avec des clés privées.

Une situation moins déroutante est dans OpenPGP: toutes les données suivent le même format binaire, et sont éventuellement "blindées" (encodées avec Radix64 et entre les en-têtes de type PEM).

Stocké à différents endroits et dans différents formats (les formats utilisés par PGP, GnuPG sshet plusieurs formats X.509 différents, entre autres, sont assez différents). Il est possible de transcoder entre eux dans une certaine mesure en mélangeant les options à droite ssh-keygen, pgp, gpg/ gpg2, openssl, etc .; mais en général ça ne vaut pas la peine. En outre, différents formats de clés prennent en charge différentes quantités d'informations, avecsshportant le moins d'informations supplémentaires et les formats X.509 PEM et DER portant le plus. De plus, le trousseau OSX est simplement un stockage de clé / valeur crypté, donc un mécanisme différent est généralement requis par chaque application pour convertir entre la clé native + le format de métadonnées du programme et quelque chose qui peut être stocké dans le trousseau. (Des préoccupations similaires s'appliquent au portefeuille KDE et au trousseau GNOME.)