Public Key

Kurz: Englische Bezeichnung für den öffentlichen Schlüssel eines asymmetrischen Schlüsselpaars.

Genauer: In der Praxis (Code, CLI-Tools, Dateinamen wie id_rsa.pub) wird fast durchgehend die englische Bezeichnung “Public Key” verwendet, auch in deutschsprachiger Dokumentation. Wird zusammen mit dem Private Key erzeugt und kann z. B. auf GitHub hinterlegt werden, um sich per SSH ohne Passwort zu authentifizieren.

Im Detail

Ein konkretes Alltagsbeispiel: Die passwortlose Anmeldung per SSH funktioniert komplett über Public-Key-Kryptografie, ohne dass je ein Passwort über das Netzwerk übertragen wird:

# Einmalig: Schlüsselpaar erzeugen
ssh-keygen -t ed25519
 
# Öffentlichen Schlüssel auf den Zielserver kopieren
ssh-copy-id nutzer@server.de
 
# Danach: Login funktioniert ohne Passworteingabe
ssh nutzer@server.de

Beim Login-Versuch läuft im Hintergrund ein sogenanntes “Challenge-Response”-Verfahren ab: Der Server schickt eine zufällige Zeichenfolge (die “Challenge”) an den Client, der Client signiert diese mit seinem privaten Schlüssel und schickt die Signatur zurück, und der Server prüft die Signatur mit dem hinterlegten öffentlichen Schlüssel. Stimmt sie, beweist das zweifelsfrei, dass der Client den passenden privaten Schlüssel besitzt — ohne dass dieser je das eigene Gerät verlassen muss.

Dieselbe Grundidee findet sich auf GitHub/GitLab wieder: Der eigene öffentliche Schlüssel wird im Profil hinterlegt, und danach kann man Repositories per Git über SSH klonen/pushen, ohne bei jeder Aktion Zugangsdaten einzugeben — praktisch, aber auch ein Grund, warum ein gestohlener privater SSH-Schlüssel potenziell Zugriff auf ALLE Repositories gibt, für die der zugehörige öffentliche Schlüssel hinterlegt ist.

Public Keys über den SSH-Kontext hinaus

Das Prinzip beschränkt sich nicht auf SSH: In TLS-Zertifikaten enthält jedes Zertifikat den öffentlichen Schlüssel des Servers, den der Browser nutzt, um den Sitzungsschlüssel für die eigentliche verschlüsselte Kommunikation sicher auszuhandeln. Bei digitalen Signaturen (z. B. signierte Software-Updates) wird der öffentliche Schlüssel des Herausgebers genutzt, um zu prüfen, dass eine Signatur wirklich vom angegebenen Absender stammt und die signierten Daten seit der Signatur nicht verändert wurden. Bei Kryptowährungen wie Bitcoin leitet sich die eigene “Wallet-Adresse” direkt aus einem öffentlichen Schlüssel ab — wer eine Überweisung empfangen will, teilt seinen öffentlichen Schlüssel (bzw. die daraus abgeleitete Adresse), niemals den privaten.

Schlüsselformate in der Praxis

In der Praxis begegnet einem der öffentliche Schlüssel meist in einem von mehreren Textformaten: Das OpenSSH-Format (eine einzelne Zeile, beginnend mit ssh-rsa oder ssh-ed25519) wird typischerweise in ~/.ssh/authorized_keys oder Plattform-Profilen wie GitHub hinterlegt. Das PEM-Format (base64-kodiert, umrahmt von -----BEGIN PUBLIC KEY-----) ist der gebräuchliche Standard für TLS-Zertifikate und viele andere kryptografische Anwendungen. Beide kodieren letztlich dieselben mathematischen Schlüsseldaten, nur in unterschiedlicher Textdarstellung für unterschiedliche Werkzeuge.

Verteilung und Vertrauen

Ein öffentlicher Schlüssel ist per Definition unkritisch, wenn er in falsche Hände gerät — das eigentliche Sicherheitsproblem ist nicht Geheimhaltung, sondern Authentizität: Woher weiß der Empfänger, dass ein öffentlicher Schlüssel wirklich zur behaupteten Person/Domain gehört, und nicht von einem Angreifer untergeschoben wurde (“Man-in-the-Middle”)? Bei TLS lösen das Zertifizierungsstellen, die die Bindung zwischen Domain und Schlüssel per Zertifikat bestätigen. Bei SSH vertraut man beim allerersten Verbindungsaufbau blind (“Trust on First Use”) und merkt sich den Fingerabdruck (Hash des öffentlichen Schlüssels) für künftige Verbindungen — ändert sich dieser Fingerabdruck später unerwartet, warnt der SSH-Client, weil das entweder eine Serverneuinstallation oder ein Angriffsversuch bedeuten kann. Bei PGP/GPG existiert dafür das “Web of Trust”: Nutzer signieren gegenseitig die öffentlichen Schlüssel bekannter Personen, um ein dezentrales Vertrauensnetz aufzubauen, ganz ohne zentrale Zertifizierungsstelle.

Siehe auch: Private Key, Asymmetrische Verschlüsselung