Wie unterscheiden sich SSH-Schlüssel, wenn überhaupt, von asymmetrischen Schlüsseln, die für andere Zwecke verwendet werden?


13

Wie unterscheiden sich SSH-Schlüssel, wenn überhaupt, von asymmetrischen Schlüsseln, die für andere Zwecke verwendet werden, z. B. zum Signieren von E-Mails?

Ich werde dazu aufgefordert, zum Teil, weil es unter OS X Apps zum Verwalten von SSH-Schlüsseln (ssh-agent, SSHKeychain usw.) sowie Apps zum Verwalten von GPG-Schlüsseln (GPG Keychain Access usw.) gibt. und anscheinend treffen sich nie die beiden. Ich glaube jedoch nicht, dass dies ein OS X-spezifisches Problem ist.

Handelt es sich um eine Trennung von Bedenken, weil die Schlüssel ganz unterschiedlicher Art sind oder weil sie an verschiedenen Orten aufbewahrt werden, oder aus einem anderen Grund oder einer Kombination von Gründen, z. B. aus historischen Gründen?

Antworten:


14
  • SSH-Schlüssel sind nur einfache asymmetrische RSA-, DSA- oder ECDSA-Schlüsselpaare. Ein solches von OpenSSH generiertes Schlüsselpaar kann bereits von OpenSSL und den meisten anderen Programmen verwendet werden.

    (Die .pubDatei, die von ausgegeben ssh-keygenwird, hat ein OpenSSH-spezifisches Format, das jedoch keine Rolle spielt, da die "private" Datei bereits sowohl private als auch öffentliche Schlüssel enthält.)

    Andere SSH-Software verfügt möglicherweise über eigene Speicherformate, z. B. RFC 4716 oder PuTTYs PPK , speichert jedoch dieselben RSA / DSA / ECDSA-Informationen.

  • X.509 (verwendet von SSL, S / MIME) ist etwas komplizierter: Der "private" Schlüssel ist immer noch derselbe, aber anstelle einer bloßen öffentlichen Schlüsseldatei haben Sie ein "Zertifikat" - eine ASN.1-Struktur, die die Name des öffentlichen Schlüssels, des Antragstellers und des Ausstellers, Gültigkeitsdatum. In X.509 v3-Zertifikaten sind Erweiterungen wie "Schlüsselverwendung" und "Alternativer Antragstellername" vorhanden. Das gesamte Zertifikat wird vom Schlüssel des Ausstellers signiert (oder selbst signiert, wenn es keinen separaten Aussteller gibt).

    Sie können problemlos eine X.509-Datei mit "privatem Schlüssel" für SSH verwenden - OpenSSH verwendet sogar dasselbe Format.

    Sie können ein X.509-Zertifikat aus einem einfachen Schlüsselpaar erstellen und dann selbst signieren oder eine "Zertifikatsanforderung" erstellen und zur Signierung durch eine Zertifizierungsstelle (Zertifizierungsstelle) senden.

    Verwenden Sie zum Anzeigen der Informationen in einem X.509-Zertifikat Folgendes:

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

    ( certtoolIst ein Teil von GnuTLS.)

  • OpenPGP-Schlüssel (von GPG verwendet) sind die kompliziertesten. Was Sie als "PGP-Schlüssel" oder "PGP-Schlüsselpaar" bezeichnen, ist eine komplexe Struktur, die als "OpenPGP-Zertifikat" bezeichnet wird und Folgendes enthält:

    • Ein "Primärschlüssel" - ein asymmetrisches Schlüsselpaar, das normalerweise zum Signieren verwendet wird
    • eine oder mehrere "Benutzer-IDs" - Textbezeichnungen, normalerweise in Form von "Name <email @ address>"
      • Mindestens einer von ihnen ist als "primäre Benutzer-ID" gekennzeichnet.
      • für jede Benutzer-ID eine "Selbstsignatur" - Signatur durch Ihren eigenen Primärschlüssel
      • für jede Benutzer-ID null oder mehr "Signaturen" von anderen Benutzern
      • Die Selbstsignaturpakete enthalten auch Ihre bevorzugten Algorithmen (SHA-1, AES usw.).
    • ein oder mehrere "Unterschlüssel" - zusätzliche Schlüsselpaare, der erste dient normalerweise der Verschlüsselung
      • für jeden Unterschlüssel eine Signatur des Primärschlüssels
    • null oder mehr "Foto-IDs" - JPEG- oder PNG-Anhänge, die Ihr Gesicht enthalten
      • auf die gleiche Weise wie Benutzer-IDs signiert
    • null oder mehr X.509-Zertifikate

    Alle Schlüsselpaare haben Ablaufdaten und Verwendungsbits: Daten signieren, Schlüssel zertifizieren, verschlüsseln und gegenüber Diensten authentifizieren. Der Primärschlüssel hat standardmäßig die Bits "sign" und "certify" und der erste Unterschlüssel dient zum "Verschlüsseln". Wenn Sie einen Unterschlüssel "authentication" hinzufügen, können Sie ihn gpg-agentfür die SSH-Authentifizierung verwenden.

    So sehen Sie, was Ihr Zertifikat enthält:

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

    ( certtoolIst ein Teil von GnuTLS.)


X.509-Zertifikate und die zugehörigen privaten Schlüssel liegen in verschiedenen Formaten vor:

  • DER ist eine binäre Codierung einer ASN.1-Struktur des Zertifikats. Solche Dateien haben normalerweise .crtoder .cerDateinamenerweiterungen ( .derist seltener, aber nicht unsichtbar).

  • Dateien im "PEM" -Format enthalten dieselben DER-codierten Daten, sind jedoch zusätzlich mit Base64 und zwischen den Headern "BEGIN THIS" und "END THAT" codiert. Eine gemeinsame Dateinamenerweiterung ist .pem, obwohl beide .crtund .cermanchmal auch hier verwendet werden (aber nie .der).

  • Für private Schlüssel, die zu den Zertifikaten gehören, wird normalerweise das "PEM" -Format verwendet - Base64, umgeben von Headern "BEGIN PRIVATE KEY" (Schlüssel in einer PKCS # 7-Struktur) oder "BEGIN RSA (oder DSA) PRIVATE KEY" (bloßer Schlüssel, OpenSSL) Format). Manchmal befindet sich der Schlüssel in einer separaten .keyDatei, manchmal wird er mit dem Zertifikat gebündelt.

  • PKCS # 12 und die etwas ältere PFX sind verschlüsselte Container, in denen sowohl das Zertifikat als auch der private Schlüssel (häufig auch das Zertifikat des Ausstellers) gespeichert sind. Dieses Format wird von den meisten Programmen beim Exportieren oder "Sichern" von Zertifikaten mit privaten Schlüsseln verwendet.

Eine weniger verwirrende Situation gibt es in OpenPGP: Alle Daten folgen demselben Binärformat und sind optional "gepanzert" (mit Radix64 codiert und zwischen PEM-ähnlichen Headern).


2

An verschiedenen Orten und in verschiedenen Formaten gespeichert (die sshFormate, die unter anderem von PGP, GnuPG und verschiedenen X.509-Formaten verwendet werden, sind sehr unterschiedlich). Es ist möglich, Transcodierungs zwischen ihnen zu einem gewissen Grad durch Mischen und Anpassen der richtigen Optionen ssh-keygen, pgp, gpg/ gpg2, openssletc .; Aber im Allgemeinen ist es die Mühe nicht wert. Außerdem unterstützen verschiedene Schlüsselformate unterschiedliche Informationsmengensshmit den wenigsten zusätzlichen Informationen und den meisten X.509 PEM- und DER-Formaten. Darüber hinaus ist der OSX-Schlüsselbund einfach eine verschlüsselte Schlüssel- / Wertespeicherung, sodass im Allgemeinen von jeder Anwendung ein anderer Mechanismus benötigt wird, um zwischen dem systemeigenen Schlüssel- und Metadatenformat des Programms und etwas zu konvertieren, das im Schlüsselbund gespeichert werden kann. (Ähnliche Bedenken gelten für die KDE-Brieftasche und den GNOME-Schlüsselbund.)


Es ist wichtig zu beachten, dass der zugrunde liegende Verschlüsselungsstandard auch anders ist. gpg verwendet hauptsächlich DSA, während SSH hauptsächlich RSA verwendet. Es gibt eine begrenzte Anzahl von asymmetrischen Standardstandards, und die meisten Anwendungen unterstützen mehrere Standards, aber die Standards, die für verschiedene Anwendungen "normal" sind, variieren.
jcrawfordor
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.