Apple hat SSH-Keys in der Secure Enclave versteckt – aber die Touch-ID-Abfrage ist hässlich

Ich habe vor Jahren entschieden, dass ich meine Schlüssel mit einem Hardware-Gerät schützen möchte, das unabhängig vom Hersteller der Maschine ist, die ich gerade benutze. Außerdem möchte ich Backup-Schlüssel haben und sie frei zwischen verschiedenen physischen Standorten hin- und herbewegen können. Oder mir bei Bedarf ein Backup um die halbe Welt schicken lassen.

YubiKeys waren die einzige Lösung, die diese Anforderungen erfüllte, also habe ich mich für sie entschieden. Ich benutze sie seit ungefähr zehn Jahren und bin mit dieser Lösung sehr zufrieden. Siehe https://github.com/drduh/YubiKey-Guide für eine Beschreibung, wie man seine auf YubiKeys gespeicherten RSA-Schlüssel gleichzeitig mit GPG und SSH zum Laufen bringt.

Ein grundlegendes Problem bei agentischer Entwicklung ist, dass der Zugriff auf den Secure-Enclave-Schlüssel die Anwesenheit eines Menschen erfordert. Wenn man headless läuft und nicht eingeloggt ist, kann Secretive (bei anderen bin ich mir nicht sicher) nicht auf die Enclave zugreifen, selbst wenn man nur "notify" und nicht "touchid" gewählt hat.

Deshalb bin ich skeptisch, ob der Ansatz zuverlässig skalieren kann, obwohl ich mich heute darauf verlasse. (Ja, PATs würden das beheben, aber das Enclave-Modell ist das, was ich vorerst beibehalten möchte.) Was ich stattdessen gemacht habe, ist einen kleinen Daemon zu schreiben, der den SSH-Authentifizierungs-Socket setzt und Agent-Forwarding macht. Das funktioniert, wenn ich mit dem Laptop unterwegs bin ... aber noch nicht von meinem Handy aus.

Beispiel:

Laptop Remote Mac

┌─────────────────────┐ ┌──────────────────────────┐

│ Secretive │ │ ssh / git commit -S │

│ (Secure Enclave) │ │ │ │

│ ▲ │ ForwardAgent │ ▼ │

│ └── ssh ─────┼─────────────────►│ ~/.ssh/agent.sock │

│ │ │ (stable proxy) │

└─────────────────────┘ │ │ │ │

│ ▼ ▼ │

│ forwarded local │

│ laptop Secretive │ […]

Der Artikel beginnt mit einer falschen Prämisse.

Der Autor sagt, er mag die Vorstellung nicht, dass Schlüssel auf seinem Dateisystem liegen und von böswilligen Akteuren geschnappt werden können.

Deshalb sollten sie mit einer Passphrase geschützt sein.

Man benutzt den ssh agent, um die Schlüssel im Speicher zu halten, und aus Bequemlichkeit kann man die Passphrasen im Keychain speichern. MacOS OpenSSH hat dafür die Konfigurationsdirektive UseKeychain.

Ich benutze selbst Yubikey/FIDO2, aber nicht, weil private Schlüssel auf einem Dateisystem nicht geschützt werden können.

Ich bin seit Jahren ein zufriedener Nutzer von Secretive, auch für die Git-Commit-Signatur, wofür es einen separaten Schlüssel mit Interaktion anlegt, aber nicht für Pull/Push. Ich finde den Kompromiss für GitHub.com ideal und habe andere Schlüssel mit anderem Setup für Server.

SSH-Schlüssel im Klartext waren eines der ersten Dinge, auf die sich bagel [0] konzentriert hat, unser Secret-Detection für Entwickler-Endpunkte. Dann haben wir bagel als Bibliothek in unseren Schutz für Entwickler-Endpunkte [1] eingebettet.

[0] https://boostsecurityio.github.io/bagel/

[1] https://boostsecurityio.github.io/dazio/docs/install/

Ich benutze dafür `op` von 1Password, aber mit einer Ausnahme: den Schlüsseln meiner Dev-Umgebung.

Ich habe gemerkt, dass ich eine Fingerabdruck-Müdigkeit entwickle. Brauche ich wirklich bei jeder Verbindung meines Dev-Servers zu Dev-Supabase eine Fingerabdruck-Anfrage? Nein. Das ist erwartbar und null Risiko. Dort gibt es keine Daten.

Ich war besorgt, dass ich eine bösartige Anfrage automatisch genehmigen würde. Wenn man 20 Anfragen am Tag sieht, greift die Muskelroutine einfach nach dem Sensor.

Deshalb habe ich einen separaten 1Password-Tresor, den ein Service Account [0] lesen kann. Dieses Token liegt als OP_SERVICE_ACCOUNT_TOKEN in meiner Umgebung, was das `op`-Tool versteht.

Er hat auch Zugriff auf einen Tresor mit 'AI-sicheren' Schlüsseln, auf die Claude zugreifen können soll, ohne mich zu fragen.

Jetzt laufen diese Anfragen unsichtbar. Und wenn ich ein Fingerabdruck-Popup sehe, ist das ungewöhnlich, und ich genehmige nicht aus Gewohnheit automatisch.

Außerdem habe ich in einem separaten Tresor einen Eintrag namens '_One-day keys'. (Der Unterstrich schiebt ihn nur an den Anfang der Liste, damit er leicht erreichbar ist.)

Er enthält Prod-Schlüssel, größtenteils auf Lesezugriff beschränkt. Bei Bedarf verschiebe ich ihn in den offenen Tresor. Claude kennt diesen Eintrag und hat Anweisungen, mich daran zu erinnern, ihn wieder herauszunehmen, wenn es mit dem fertig ist, was es gerade tut.

[0]: https://www.1password.dev/service-accounts/get-started

Du solltest dir den TKey ansehen (https://www.tillitis.se/products/tkey/)

Er ist praktisch eine Open-Source-Version eines YubiKeys, die Hardware selbst ist komplett Open Source und er kommt mit ed255519-SSH-Schlüsseln richtig gut zurecht.

inb4 sie sind nicht dasselbe, ich weiß, ich mag wirklich, was das TKey-Team macht.

Secure Enclave, TPM und andere solche Sicherheitsfunktionen sind leider so schlecht dokumentiert und erfordern so viele Hürden, um sie zum Laufen zu bringen, wobei jeder Fehler entweder dazu führt, dass man komplett ausgesperrt wird oder dass man nicht den gewünschten Schutz bekommt. Es sollte wirklich einen besseren Weg geben, diese Technologien nutzbar zu machen ...