Czym w ogóle różnią się klucze SSH od kluczy asymetrycznych używanych do innych celów?

Czym w ogóle różnią się klucze SSH od kluczy asymetrycznych używanych do innych celów, np. Do podpisywania wiadomości e-mail?

Zostałem częściowo poproszony o to, ponieważ w OS X dostępne są aplikacje do zarządzania kluczami SSH (ssh-agent, SSHKeychain itp.), A także aplikacje zaprojektowane do zarządzania kluczami GPG (dostęp do pęku kluczy GPG itp.), i najwyraźniej nie spotykają się twainy. Jednak nie sądzę, że jest to problem związany z OS X.

Czy to rozdzielenie obaw, ponieważ klucze są całkiem innego rodzaju, czy dlatego, że są przechowywane w różnych miejscach, czy może z jakiegoś innego powodu lub kombinacji przyczyn, np. Przyczyn historycznych?

• Klucze SSH to zwykłe asymetryczne pary kluczy RSA, DSA lub ECDSA. Z takiej pary kluczy wygenerowanej przez OpenSSH może już korzystać OpenSSL i większość innych programów.

  (Dane .pubwyjściowe pliku ssh-keygensą w formacie specyficznym dla OpenSSH, ale nie ma to znaczenia, ponieważ plik „prywatny” zawiera już zarówno klucze prywatne, jak i publiczne.)

  Inne oprogramowanie SSH może mieć własne formaty pamięci, takie jak RFC 4716 lub PPK PuTTY , ale przechowują te same informacje RSA / DSA / ECDSA.

• X.509 (używany przez SSL, S / MIME) jest nieco bardziej skomplikowany: klucz „prywatny” jest nadal taki sam, ale zamiast pustego pliku klucza publicznego masz „certyfikat” - strukturę ASN.1 zawierającą klucz publiczny, nazwy podmiotów i emitentów, daty ważności. W certyfikatach X.509 v3 będą dostępne rozszerzenia takie jak „użycie klucza” i „alternatywna nazwa podmiotu”. Cały certyfikat jest podpisany kluczem wystawcy (lub samopodpisany, jeśli nie ma osobnego wystawcy).

  Możesz łatwo użyć pliku „klucza prywatnego” X.509 dla SSH - OpenSSH nawet używa tego samego formatu.

  Możesz utworzyć certyfikat X.509 za pomocą prostej pary kluczy, a następnie samopodpisać go lub możesz utworzyć „żądanie certyfikatu” i przesłać go do podpisania przez urząd certyfikacji.

  Aby wyświetlić informacje w certyfikacie X.509, użyj:

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

  ( certtooljest częścią GnuTLS.)

• Najbardziej skomplikowane są klucze OpenPGP (używane przez GPG). To, co nazywacie „kluczem PGP” lub „parą kluczy PGP”, to złożona struktura zwana „certyfikatem OpenPGP”, zawierająca:

  • jeden „klucz podstawowy” - asymetryczna para kluczy, zwykle używana do podpisywania
  • jeden lub więcej „identyfikatorów użytkowników” - etykiety tekstowe, zwykle w formie „Nazwa <adres e-mail @ adres>”
    • co najmniej jeden z nich jest oznaczony jako „główny identyfikator użytkownika”
    • dla każdego identyfikatora użytkownika „samopodpis” - podpis własnym kluczem podstawowym
    • dla każdego identyfikatora użytkownika zero lub więcej „podpisów” innych użytkowników
    • pakiety z podpisem własnym zawierają również preferowane algorytmy (SHA-1, AES itp.)
  • jeden lub więcej „podkluczy” - dodatkowe pary kluczy, pierwszy zwykle służy do szyfrowania
    • dla każdego podklucza podpis według klucza podstawowego
  • zero lub więcej „identyfikatorów ze zdjęciami” - załączniki JPEG lub PNG zawierające twoją twarz
    • podpisany w taki sam sposób jak identyfikatory użytkownika
  • zero lub więcej certyfikatów X.509

  Wszystkie pary kluczy mają daty ważności i bity użytkowania: podpisuj dane, certyfikuj (podpisuj) klucze, szyfruj, uwierzytelniaj w usługach. Domyślnie klucz podstawowy ma bity „podpisuj” i „certyfikuj”, a pierwszym podkluczem jest „szyfrowanie”. Jeśli dodasz podklucz „uwierzytelnianie”, możesz użyć go gpg-agentdo uwierzytelnienia SSH.

  Aby zobaczyć, co zawiera Twój certyfikat:

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

  ( certtooljest częścią GnuTLS.)

Certyfikaty X.509 i powiązane z nimi klucze prywatne są dostępne w kilku formatach:

• DER to binarne kodowanie struktury ASN.1 certyfikatu. Takie pliki zwykle mają rozszerzenia nazw plików .crtlub są rzadsze, ale nie są niewidoczne..cer.der

• Pliki w formacie „PEM” zawierają te same dane zakodowane w DER, ale dodatkowo zakodowane przy użyciu Base64 i pomiędzy nagłówkami „ROZPOCZNIJ TO” i „KOŃCZ TO”. Częstym rozszerzenie pliku jest .pem, chociaż oba .crti .cersą czasami stosowane tu też (ale nigdy .der).

• W przypadku kluczy prywatnych należących do certyfikatów zwykle stosuje się format „PEM” - Base64 otoczony nagłówkami „BEGIN PRIVATE KEY” (klucz w strukturze PKCS # 7) lub „BEGIN RSA (lub DSA) PRIVATE KEY” (goły klucz, OpenSSL format). Czasami klucz znajduje się w osobnym .keypliku, czasem jest dołączony do certyfikatu.

• PKCS # 12 i nieco starszy PFX to zaszyfrowane kontenery przechowujące zarówno certyfikat, jak i klucz prywatny (często także certyfikat wystawcy). Ten format jest używany przez większość oprogramowania podczas eksportowania lub tworzenia kopii zapasowych certyfikatów za pomocą kluczy prywatnych.

Mniej skomplikowana sytuacja występuje w OpenPGP: wszystkie dane mają ten sam format binarny i są opcjonalnie „zbrojone” (kodowane Radix64 i pomiędzy nagłówkami podobnymi do PEM).

Przechowywane w różnych miejscach i różnych formatach (formaty używane przez PGP, GnuPG sshi kilka różnych formatów X.509 są całkiem różne). Jest to możliwe do transkodowania między nimi do pewnego stopnia przez mieszanie i dopasowanie odpowiednich opcji ssh-keygen, pgp, gpg/ gpg2, opensslitp .; ale ogólnie nie jest to warte wysiłku. Ponadto różne formaty kluczy obsługują różne ilości informacjisshprzenoszący najmniej dodatkowych informacji oraz X.509 formatów PEM i DER przenoszących najwięcej. Dodatkowo, brelok OSX to po prostu zaszyfrowana pamięć kluczy / wartości, więc każda aplikacja potrzebuje innego mechanizmu do konwersji między formatem klucza natywnego programu + formatem metadanych a czymś, co może być przechowywane w pęku kluczy. (Podobne obawy dotyczą portfela KDE i pęku kluczy GNOME).