Private Key

Bild: Stern, Public domain, Wikimedia Commons

Kurz: Der geheime Teil eines asymmetrischen Schlüsselpaars — muss unbedingt geheim bleiben, damit das gesamte Verfahren sicher ist.

Genauer: Mit dem Private Key werden Daten entschlüsselt, die mit dem zugehörigen Public Key verschlüsselt wurden, oder Signaturen erstellt, die jeder mit dem Public Key prüfen kann. Ein kompromittierter Private Key (z. B. versehentlich in ein öffentliches Git-Repo committet) macht das gesamte Schlüsselpaar unsicher — betroffene Zertifikate müssen dann widerrufen und neu ausgestellt werden.

Im Detail

Ein Private Key wird typischerweise als PEM-Datei gespeichert und zusätzlich mit einer Passphrase geschützt:

-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAAAMwAAAAtzc2gt...
-----END OPENSSH PRIVATE KEY-----

Zwei unabhängige Schutzebenen kommen hier zusammen: Erstens die Dateiberechtigungen des Betriebssystems (unter Linux/macOS zwingend chmod 600, damit nur der Besitzer selbst die Datei überhaupt lesen kann), zweitens eine Passphrase, die die Datei zusätzlich verschlüsselt — selbst wer die Datei stiehlt, kann sie ohne die Passphrase nicht nutzen. Beide Schutzebenen sind unabhängig sinnvoll: Die Dateiberechtigung schützt vor anderen Nutzern desselben Systems, die Passphrase schützt zusätzlich, falls die Datei trotzdem irgendwie kopiert wird (z. B. über ein Backup oder einen gestohlenen Laptop).

Der mit Abstand häufigste reale Sicherheitsvorfall rund um Private Keys ist das versehentliche Einchecken in ein öffentliches Git-Repository — automatisierte Scanner durchsuchen öffentliche Repositories kontinuierlich nach genau diesem Muster (erkennbare -----BEGIN ... PRIVATE KEY------Header) und melden Funde oft binnen Minuten an Angreifer. Sobald ein Private Key als kompromittiert gilt, muss er unwiderruflich als unsicher betrachtet werden: Das zugehörige Zertifikat muss widerrufen und ein komplett neues Schlüsselpaar erzeugt werden — es gibt keinen Weg, einen einmal öffentlich gewordenen privaten Schlüssel nachträglich wieder “privat” zu machen.

Hardware-basierter Schutz: wenn der Schlüssel das Gerät nie verlässt

Die stärkste Form des Schutzes für private Schlüssel geht über Dateiberechtigungen und Passphrasen hinaus: Hardware Security Modules (HSMs) und ähnliche spezialisierte Chips (z. B. das Secure Enclave in Apple-Geräten oder ein YubiKey) erzeugen und speichern den privaten Schlüssel DIREKT in spezieller, manipulationssicherer Hardware — der Schlüssel selbst verlässt diesen Chip NIEMALS, nicht einmal zur Nutzung. Statt den Schlüssel zum Signieren/Entschlüsseln an eine Software zu übergeben, schickt die Software die zu signierenden Daten AN den Chip, der die Operation intern durchführt und nur das Ergebnis zurückgibt. Selbst wenn ein Angreifer vollen Zugriff auf den Rest des Systems erlangt, kann er den privaten Schlüssel so niemals direkt extrahieren — er kann höchstens den Chip missbrauchen, solange er physischen Zugriff hat.

Schlüsselrotation als proaktive Sicherheitsmaßnahme

Auch ohne konkreten Verdacht auf Kompromittierung gilt regelmäßige Schlüsselrotation (der geplante, turnusmäßige Austausch von Schlüsseln, selbst wenn keine Kompromittierung bekannt ist) als bewährte Sicherheitspraxis, besonders bei Server-Zertifikaten und API-Schlüsseln in Unternehmensumgebungen. Der Gedanke dahinter: Sollte ein Schlüssel unbemerkt kompromittiert worden sein (z. B. durch eine noch unentdeckte Sicherheitslücke), begrenzt eine regelmäßige Rotation das Zeitfenster, in dem ein Angreifer den gestohlenen Schlüssel tatsächlich missbrauchen kann — ähnlich wie ein regelmäßiger Passwortwechsel (der allerdings heute für gewöhnliche Nutzerpasswörter aus Usability-Gründen seltener empfohlen wird als früher, weil er Nutzer oft zu schwächeren, leichter zu merkenden Passwörtern verleitet).

Backup-Strategien für private Schlüssel

Ein oft übersehenes Dilemma: Ein private Schlüssel muss gleichzeitig streng geheim UND vor Verlust geschützt sein — verliert man den einzigen privaten Schlüssel (z. B. durch einen Festplattendefekt), sind damit verschlüsselte Daten unwiederbringlich verloren, ohne dass ein Angreifer je beteiligt war. Für kritische Schlüssel (z. B. den Master-Schlüssel einer Verschlüsselungsinfrastruktur) wird deshalb oft “Secret Sharing” eingesetzt: Der Schlüssel wird kryptografisch in mehrere Teile aufgespalten, verteilt an unterschiedliche vertrauenswürdige Personen/Orte, wobei erst eine Mindestanzahl der Teile (z. B. 3 von 5) den ursprünglichen Schlüssel rekonstruieren kann — das schützt sowohl vor Verlust einzelner Teile als auch davor, dass eine einzelne Person allein Zugriff auf den vollständigen Schlüssel hat.

Siehe auch: Public Key, Asymmetrische Verschlüsselung, Schlüssel