# MeshForge — lokale Schlüsselablage Status: gehärtete **lokale Klartextdatei**, kein OS-Keystore und keine verschlüsselte Secret-Ablage. CLI `init --data DIR` erzeugt eine Ed25519-Identität; `identity-public --data DIR` gibt nur den öffentlichen Schlüssel aus. Root-/Geräte- Verzeichnisse getrennt außerhalb von Quellprojekten aufbewahren. Ein Node-Key ist kein automatisch authentifizierter SteveCo-AI-Release-Root. ## Kompatible sichere Defaults Das vorhandene Format `identity.key` (unpadded Base64url des 64-Byte-Ed25519-Keys) bleibt unverändert. Legacy-Dateien mit abschließendem Zeilenumbruch funktionieren. Read ist auf 256 Bytes begrenzt und verlangt eine reguläre Datei. Letztes Directory-Symlink, Dateisymlink, Spezialdatei, falsche Größe und inkonsistente Seed/Public-Hälfte werden abgelehnt. Directory/Datei werden mit os.Root und Inode-Vergleich gepinnt. Fehlende oder beschädigte Keys werden nie automatisch neu erzeugt; `init` ersetzt keine vorhandene Datei, auch keine kaputte. Unter Linux muss das Schlüsselverzeichnis der aktuellen UID gehören und darf nicht durch Gruppe/andere beschreibbar sein. Die Schlüsseldatei benötigt dieselbe UID und ausschließlich Eigentümer-Leserechte (0400 oder 0600, keine Ausführungs- oder Gruppenrechte). Open verwendet O_NOFOLLOW und O_NONBLOCK; eine manipulierte FIFO kann den Key-Read nicht auf unbestimmte Zeit blockieren. Unzulässige Rechte werden gemeldet, nicht still korrigiert. Ein bewusstes Berechtigungs-Update muss vom Besitzer anhand der tatsächlichen Datei vorgenommen werden. Unter Windows sind POSIX-Modebits keine ACL-Prüfung. Begrenzte reguläre Reads, Pinning und exklusive Anlage gelten auch dort; geschützte Benutzerverzeichnisse und geeignete Windows-ACLs bleiben Betriebsanforderung und offene reale Abnahme. Keine DPAPI-/Credential-Manager-Integration ist implementiert. ## Initialisierung und Wiederanlauf Neue Verzeichniseinträge werden unter Linux von unten nach oben synchronisiert. Der neue Key entsteht zunächst in einem privaten zufälligen Unterordner `.mf-key-init-/identity.key`, mit 0600, vollständigem Write und File.Sync. Ein exklusiver Hardlink installiert erst dann `identity.key`; konkurrierende Initialisierungen haben genau einen Gewinner und können keine Identität ersetzen. Danach werden das Schlüsselverzeichnis und dessen Parent synchronisiert. Fehler nach Installation werden ausdrücklich als unklarer Durability-Ausgang gemeldet; die installierte Identität wird niemals als vermeintlicher Cleanup gelöscht. Ein Prozessabbruch kann einen privaten Stagingrest zurücklassen. Erst laufende Initialisierungen stoppen, eigene Reste prüfen und gegebenenfalls entfernen. Der Dateiname `identity.key` bleibt auch im Rest erhalten, damit der Public-Sync- Preflight ihn als bekannte Secretdatei ablehnt. Keine automatische Veröffentlichung und keine automatische Suche nach fremden Restordnern. Backupkopien enthalten private Keys und müssen entsprechend geschützt werden. ## Grenzen und weitere Gates Dateisystem, aktuelle UID/Administrator und Systemuhr bleiben vertrauenswürdig. Dies schützt nicht gegen einen kompromittierten Prozess derselben UID, Root, Speicherabbilder oder vollständigen lokalen Rollback. Kein gesicherter OS-Keystore, verschlüsseltes Backup, Root-Rotations-/Recovery-Dashboard oder Wallet-Key-Import. Der DIP-Gerätewiderruf ist separat persistent implementiert; eine Widerrufsliste verschlüsselt keine private Schlüsseldatei. Zusätzliche Kryptografie benötigt geprüfte Verfahren/Bibliotheken und ein eigenes Bedrohungsmodell; keine selbst erfundene Passwortverschlüsselung wird als sichere Ersatzlösung ausgegeben.