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

3289
sampablokuper

Wenn überhaupt, unterscheiden sich SSH-Schlüssel von asymmetrischen Schlüsseln, die für andere Zwecke verwendet werden, z. B. für die E-Mail-Signatur?

Ich werde dazu aufgefordert, dies teilweise zu fragen, da unter OS X Apps zur Verwaltung von SSH-Schlüsseln (ssh-agent, SSHKeychain usw.) sowie von Apps zur Verwaltung von GPG-Schlüsseln (GPG Keychain Access usw.) verfügbar sind. und anscheinend treffen sich die beiden nicht. Ich glaube jedoch nicht, dass dies ein OS X-spezifisches Problem ist.

Ist dies eine Trennung der Bedenken, weil die Schlüssel ganz unterschiedlich sind oder an unterschiedlichen Orten gespeichert sind oder liegt dies aus einem anderen Grund oder einer Kombination von Gründen, z. B. aus historischen Gründen?

13

2 Antworten auf die Frage

14
grawity
  • 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 .pubDateiausgabe von ssh-keygenist im OpenSSH-spezifischen Format, dies ist jedoch irrelevant, 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 (von SSL, S / MIME verwendet) ist etwas komplizierter: Der "private" Schlüssel ist immer noch derselbe, aber statt einer bloßen Public-Key-Datei haben Sie ein "Zertifikat" - eine ASN.1-Struktur, die das enthält öffentlicher Schlüssel, Betreff- und Ausstellernamen, Gültigkeitsdatum. In X.509 v3-Zertifikaten sind Erweiterungen wie "Schlüsselverwendung" und "alternativer Betreffname" vorhanden. Das gesamte Zertifikat wird mit dem Schlüssel des Ausstellers signiert (oder selbst signiert, wenn es keinen separaten Aussteller gibt).

    Sie können problemlos eine X.509-Datei "Private Key" für SSH verwenden - OpenSSH verwendet sogar dasselbe Format.

    Sie können ein X.509-Zertifikat mit einem einfachen Schlüsselpaar erstellen und anschließend selbst signieren. Sie können auch eine "Zertifikatsanforderung" erstellen und diese zur Unterzeichnung durch eine Zertifizierungsstelle (Zertifizierungsstelle) einreichen.

    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" - Textetiketten, normalerweise in der Form "Name <E-Mail-Adresse>"
      • Mindestens eine davon 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 keine oder mehrere "Signaturen" von anderen Benutzern
      • Die selbstsignierten Pakete enthalten auch Ihre bevorzugten Algorithmen (SHA-1, AES usw.).
    • ein oder mehrere "Unterschlüssel" - zusätzliche Schlüsselpaare, die erste dient in der Regel zur Verschlüsselung
      • für jeden Unterschlüssel eine Signatur durch den Primärschlüssel
    • Null oder mehr "Foto-IDs" - JPEG- oder PNG-Anhänge, die Ihr Gesicht enthalten
      • wie Benutzer-IDs signiert
    • null oder mehr X.509-Zertifikate

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

    Um zu sehen, 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 gibt es in verschiedenen Formaten:

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

  • Dateien im "PEM" -Format enthalten die gleichen DER-codierten Daten, werden jedoch zusätzlich mit Base64 und zwischen "BEGIN THIS" und "END THAT" -Headern 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" (reiner 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, die sowohl das Zertifikat als auch den privaten Schlüssel (oft auch das Zertifikat des Ausstellers) speichern. Dieses Format wird von der meisten Software beim Exportieren oder "Sichern" von Zertifikaten mit privaten Schlüsseln verwendet.

Weniger verwirrend ist die Situation in OpenPGP: Alle Daten folgen dem gleichen Binärformat und sind optional "gepanzert" (mit Radix64 und zwischen PEM-artigen Headern codiert).

2
geekosaur

An verschiedenen Orten und in verschiedenen Formaten gespeichert (die von PGP, GnuPG sshund einigen verschiedenen X.509-Formaten verwendeten Formate sind sehr unterschiedlich). Es ist möglich, zwischen ihnen zu einem gewissen Grad durch Mischen und Anpassen der richtigen Optionen umcodieren ssh-keygen, pgp, gpg/ gpg2, openssletc .; Aber im Allgemeinen ist es die Mühe nicht wert. Außerdem unterstützen unterschiedliche Schlüsselformate unterschiedliche Informationsmengen mitsshmit den geringsten zusätzlichen Informationen und X.509-PEM- und DER-Formaten mit den meisten. Darüber hinaus ist der OSX-Schlüsselbund lediglich ein verschlüsselter Schlüssel- / Wertespeicher. Daher ist für jede Anwendung in der Regel ein anderer Mechanismus erforderlich, um zwischen dem systemeigenen Schlüssel- + Metadatenformat des Programms und einem Element zu konvertieren, das im Schlüsselbund gespeichert werden kann. (Ähnliche Bedenken gelten für die KDE-Geldbörse und den GNOME-Schlüsselbund.)

Es ist wichtig zu beachten, dass der zugrunde liegende Verschlüsselungsstandard ebenfalls unterschiedlich ist. gpg verwendet hauptsächlich DSA, während SSH hauptsächlich RSA verwendet. Es gibt eine begrenzte Anzahl asymmetrischer Standards, und die meisten Anwendungen unterstützen mehrere Standards. Die für verschiedene Anwendungen "normalen" Standards sind jedoch unterschiedlich. jcrawfordor vor 13 Jahren 0