Native Unterstützung für Secure-Enclave-basierte SSH-Schlüssel unter macOS

• In der Tahoe-Version von macOS wird die Erstellung und Nutzung von SSH-Schlüsseln mit der Secure Enclave standardmäßig unterstützt
• Die Bibliothek /usr/lib/ssh-keychain.dylib implementiert neben dem bisherigen PKCS11Provider für Smartcards auch die SecurityKeyProvider-Schnittstelle, sodass sie statt mit einem FIDO2-Gerät direkt mit der Secure Enclave kommunizieren kann
• Mit dem Befehl sc_auth lassen sich biometrisch per Touch ID geschützte Schlüssel erzeugen, und über ssh-keygen oder ssh-add können Schlüssel direkt aus dem geschützten Bereich geladen und verwendet werden
• Wenn die Umgebungsvariable SSH_SK_PROVIDER in .zprofile gesetzt wird, wird sie von SSH, ssh-agent und ssh-keygen automatisch erkannt
• Ohne externe Tools lässt sich allein mit den Bordmitteln von macOS eine SSH-Authentifizierungsstruktur aufbauen, die Sicherheit und Komfort zugleich bietet

---

Überblick über die Unterstützung von Secure-Enclave-basierten SSH-Schlüsseln

• macOS Tahoe unterstützt die Erstellung und Nutzung von SSH-Schlüsseln auf Basis der Secure Enclave
  • Bisher waren dafür externe Projekte wie secretive nötig, nun kann das durch macOS-Bordmittel ersetzt werden
• /usr/lib/ssh-keychain.dylib implementiert SecurityKeyProvider, wodurch ein Zugriff auf die Secure Enclave auf ähnliche Weise wie bei einem FIDO2-Gerät möglich ist
• Damit kann die SSH-Authentifizierung mit dem integrierten Sicherheitschip von macOS erfolgen, ohne externe Hardware wie etwa einen YubiKey

Schlüsselerstellung und -verwaltung

• Mit dem Befehl sc_auth create-ctk-identity -l ssh -k p-256-ne -t bio wird ein Secure-Enclave-Schlüssel erzeugt, der eine Touch-ID-Authentifizierung erfordert
  • Mit dem Befehl list-ctk-identities lassen sich die erzeugten Schlüssel und ihre Hashes anzeigen
  • Mit dem Befehl delete-ctk-identity lassen sich Schlüssel löschen
• Mit der Option list-ctk-identities -t ssh lässt sich der SSH-Schlüsselfingerabdruck (Fingerprint) prüfen

Verwendung in SSH

• Mit dem Befehl ssh-keygen -w /usr/lib/ssh-keychain.dylib -K -N "" lässt sich ein Schlüsselpaar aus der Secure Enclave laden
  • Eine PIN-Eingabe ist nicht erforderlich; die Authentifizierung erfolgt per Touch ID
  • Der erzeugte „private key“ ist nicht der eigentliche geheime Schlüssel, sondern ein Referenzwert auf FIDO-Anmeldedaten
• Nachdem der öffentliche Schlüssel mit ssh-copy-id auf den Server kopiert wurde,
  ist eine Verbindung mit ssh -o SecurityKeyProvider=/usr/lib/ssh-keychain.dylib localhost möglich

Integration mit ssh-agent

• Mit dem Befehl ssh-add -K -S /usr/lib/ssh-keychain.dylib lässt sich der Secure-Enclave-Schlüssel direkt bei ssh-agent registrieren
  • Die registrierten Schlüssel können mit ssh-add -L geprüft werden
  • Danach erfolgt die Authentifizierung mit ssh -o SecurityKeyProvider=/usr/lib/ssh-keychain.dylib

Standardmäßige SecurityKeyProvider-Konfiguration

• Die Einstellung kann direkt in .ssh/config vorgenommen werden, oder sie wird durch das Hinzufügen von
  export SSH_SK_PROVIDER=/usr/lib/ssh-keychain.dylib zu .zprofile automatisch erkannt
• Danach ist eine SSH-Verbindung auf Basis von Sicherheitsschlüsseln einfach mit ssh-add -K oder ssh my-server möglich

Exportierbare Schlüssel (Exportable Keys)

• Mit dem Befehl sc_auth create-ctk-identity -l ssh-exportable -k p-256 -t bio lassen sich exportierbare Schlüssel erzeugen, die durch die Secure Enclave verschlüsselt sind
  • Mit export-ctk-identity können sie als PEM-Datei exportiert und
    mit import-ctk-identities auf einem anderen Gerät erneut registriert werden
• Diese Methode ist etwas weniger sicher, dafür aber vorteilhaft für Backups

Entwicklerdiskussion und Code-Erweiterung

• In den Kommentaren wurde diskutiert, ob sich das Flag .biometryCurrentSet verwenden lässt
  • Derzeit wird nur „Biometrie verwenden oder nicht“ (ein/aus) unterstützt; eine feinere Steuerung ist nicht möglich
• Der Autor hat ssh-keychain.dylib per Reverse Engineering untersucht, um die Möglichkeit zu prüfen, der Funktion sk_enroll() Unterstützung für biometryCurrentSet hinzuzufügen
• Das vorgeschlagene Codebeispiel muss mit einem Apple-Developer-Program-Konto per codesign signiert werden, damit ein Zugriff auf die Secure Enclave möglich ist
• Der Code enthält die Logik für Schlüsselerstellung, Signierung und Registrierung (sk_enroll, sk_sign usw.),
  wobei die Erzeugung und Signierung von ECDSA-P-256-Schlüsseln in der Secure Enclave implementiert ist

Zusammenfassung

• macOS unterstützt nun nativ die SSH-Authentifizierung unter direkter Nutzung der Secure Enclave
• Touch-ID-basierte Biometrie und eine FIDO2-kompatible Struktur verbessern Sicherheit und Bedienkomfort
• Ohne externe Hardware oder zusätzliche Software ist eine Verwaltung von SSH-Schlüsseln allein mit integrierten Systemfunktionen möglich
• Entwickler experimentieren mit einer Erweiterung von ssh-keychain.dylib, um feiner abgestufte biometrische Steuerungsmöglichkeiten zu ermöglichen

[GN⁺]

Hacker-News-Kommentare

• Wenn ich das richtig verstehe, bedeutet das, dass der private Schlüssel nicht gesichert werden kann
  Da er in der Secure Enclave gespeichert wird, verschwindet der Schlüssel zusammen mit dem Laptop, wenn man ihn verliert
  Offenbar lässt sich nur der öffentliche Schlüssel exportieren. Natürlich gibt es vielleicht andere Wege oder einen Admin-Reset, aber es bleibt trotzdem ein leicht ungutes Gefühl
  Später hieß es, der OP werde antworten und die Webseite aktualisieren

  • Siehe man sc_auth. Statt direkt in der Secure Enclave zu erzeugen, kann man einen verschlüsselten exportierbaren Schlüssel anlegen
    Beispielbefehle sind sc_auth create-ctk-identity -l ssh-exportable -k p-256 -t bio; anschließend kann man mit export-ctk-identity eine .pem-Datei erzeugen
    Auf einem anderen Gerät kann sie mit import-ctk-identities wieder importiert werden. Das soll noch in den Guide aufgenommen werden
  • Der ursprüngliche Schlüssel wird nicht „exportiert“. Jedes Verschieben eines Schlüssels erhöht das Risiko einer Offenlegung
    Der Kern von PKI ist, dass nur der öffentliche Schlüssel bewegt wird und der private Schlüssel nur an einem Ort existieren sollte
  • Stimmt. Es ist sinnvoll, mehrere Schlüssel als Backup anzulegen
    So wird der Schlüssel unter keinen Umständen offengelegt
  • Dass der private Schlüssel nicht exportiert werden kann, ist dasselbe Konzept wie bei einem YubiKey
    Auch auf einem YubiKey erzeugte private Schlüssel lassen sich nicht sichern
  • Im Prinzip ist es richtig, mehrere Schlüssel zu verwenden
    Ideal ist einer pro Gerät, damit ein Verlust oder Diebstahl eines Geräts kein Problem darstellt
    Ich bewahre einen PIN-geschützten YubiKey im Safe auf. Falls Laptop, Telefon und mein alltäglicher YubiKey gleichzeitig weg sind, bin ich trotzdem abgesichert

• Einen Schritt weitergehend sind auch ECDSA-basierte GPG-Signaturen möglich
  Wegen eines Bugs braucht man allerdings gepatchtes GPG und einen SSH-Agenten
  Es gibt eine Paketversion mit UI für macOS (KeetaNetwork/agent),
  und dasselbe Backend funktioniert unter Linux auch mit TPM über PKCS#11
  Der Unterschied zwischen GPG und SSH liegt nur darin, wie Schlüssel und Signaturen gekapselt werden; im Kern ist es alles ECDSA

• Secretive ist einfacher einzurichten, aber ich werde wohl auf diese Methode umsteigen, um eine App weniger zu haben
  Wie man unter Windows 11 TPM-basierte SSH-Schlüssel einrichtet, habe ich in meinem Blog beschrieben

  • Ich frage mich, ob man auch unter Linux SSH-Schlüssel im TPM speichern kann

• Ziemlich coole Funktion
  Ich habe Secretive lange genutzt, und es war viel bequemer als physische Schlüssel oder Karten
  Jedes Mal, wenn ein SSH-Schlüssel verwendet wird, muss man einen Knopf drücken oder einen Fingerabdruck bestätigen, sodass klar ist, wann er benutzt wird
  Man kann das ssh-agent-Tunneling aufrechterhalten und so auch auf entfernten Servern sicher Git-Signaturen erstellen
  Die Tahoe-Version ist allerdings voller Bugs und friert oft ein. Ich habe keine Zeit zum Debuggen und lasse es daher einfach so
  Die UX von Smart-Card-basiertem SSH hat mir früher einiges an Leid beschert, aber wenn es stabil ist, wäre es einen Versuch wert

  • Ich mag Secretive auch, aber die Bestätigungsfunktion von ssh-agent wird von OpenSSH schon seit Langem unterstützt
    Über ssh-askpass kann jede Verwendung eines privaten Schlüssels bestätigt werden. Es unterscheidet allerdings nicht zwischen lokal und remote

• Dabei werden Kurven verwendet, bei denen der Verdacht besteht, dass die NSA eine Backdoor eingebaut hat, also Vorsicht

• Wenn der Schlüssel in der Secure Enclave gespeichert wird, frage ich mich, warum überhaupt eine private Schlüsseldatei nötig ist

  • Bei der sk-Implementierung von OpenSSH ist es genauso. Selbst mit der Option „resident key“ ist eine private Schlüsseldatei nötig
    Sie ist lediglich eine Referenz auf die FIDO-Credentials und enthält keine echten geheimen Schlüsseldaten
    Bei nicht-residenten sk-Schlüsseln ist die Datei nötig, weil der Hardware-Authenticator keinen Zustand speichert
    Ob die macOS-Implementierung zustandsbehaftet oder zustandslos ist, weiß ich nicht sicher. Nach einer Neuinstallation des OS könnte es kaputtgehen

• Es gibt ein Projekt namens facebookincubator/sks
  Eine Golang-Bibliothek, die verschiedene hardwarebasierte SSH-Schlüssel abstrahiert und Linux, Windows und macOS unterstützt

  • Aber mit einer reinen Golang-Bibliothek läuft ssh-agent nicht
    Deshalb habe ich vor einiger Zeit angefangen, ssh-tpm-agent selbst zu bauen

• Ich würde denselben privaten Schlüssel auf dem iPhone auch zum Signieren von E-Mails oder Dateien verwenden wollen
  Ich frage mich, ob iCloud das übernehmen könnte

  • Solche Schlüssel werden nicht über iCloud synchronisiert
    Stattdessen werden Passkeys synchronisiert. Man müsste einen neuen SecurityKeyProvider bauen, der mit der Passkey-API spricht
    Passkeys sind an eine bestimmte App-Bundle-ID oder Domain gebunden
    Wenn Secretive zum Beispiel Passkeys unterstützen würde, könnte dieses Schlüsselpaar nicht von anderen Apps verwendet werden,
    würde aber zwischen mehreren Geräten derselben App synchronisiert

• Es ist wohl Zeit, KeyMux um ein neues Feature zu erweitern
  Das Tool unterstützt Enclave-Schlüssel für SSH, SSL und PGP,
  sodass man sich zum Beispiel mit einem Secure-Enclave-basierten SSL-Zertifikat bei einem Vault-Server anmelden und mit einem nicht exportierbaren privaten Vault-Schlüssel per SSH authentifizieren kann
  Mehr dazu auf keymux.com und im App-Store-Link