Ende-zu-Ende-versiegelte Sitzungen (sealed sessions)

Android Console öffnet Ende-zu-Ende-Verschlüsselung über Einstellungen; das Zielgerät wird auf der Seite gewählt. Android und Web Console erlauben Passwort-Einrichtung und -Änderung sowie E-Mail-Verknüpfung und -Wechsel. Die bisherige Adresse bleibt bis zur Bestätigung aktiv. Console sichert den Root-Schlüssel standardmäßig mit leerer Passphrase in Exchange und überschreibt keine vorhandenen Passphrase-Sicherungen. Löschen deaktiviert die automatische Sicherung auf diesem Client. Mit leerer Passphrase kann Exchange oder ein Datenbankinhaber den Schlüssel entschlüsseln. Manuelle Wiederherstellung prüft die Arbeitsbereichswurzel, speichert sie dauerhaft und synchronisiert Berechtigungen.

Ziel: Auch bei kompromittiertem Exchange-Host oder neugierigem Betreiber sind Befehle, Ausgaben, PTY-Bytes, Dateiinhalte, Screenshots und ubus-Daten nicht lesbar. Exchange kann weder entscheiden noch fälschen, wer Geräte ansehen oder verwalten darf. Es wird zum Relay für Chiffretext und Routing-Metadaten.

Definitionen: crates/proto/src/seal.rs (Übertragungstypen, lokale Autorisierungsregeln), crates/proto/src/seal/crypto.rs (Sitzungskryptografie, nur ring), crates/proto/src/seal/backup.rs (Passwortbackup: Argon2id + ChaCha20-Poly1305, nicht im Agent verlinkt), crates/agent/src/seal.rs (Gerät), crates/cli/src/seal.rs (CLI), shared/seal-session.js (gemeinsame Sitzungsimplementierung für Web Console und Android Console, @noble/curves · @noble/hashes · @noble/ciphers), shared/seal-backup.js (Argon2id-Passwortbackup mit denselben Bibliotheken). Sprachübergreifende Testvektoren: shared/seal-vectors.json (JS-erzeugt, Rust-javascript_vectors_interoperate prüft Signatur/HKDF/Chiffretext bytegenau), shared/seal-rust-vectors.json (Rust-Geräteantwort, JS-shared/seal-session.test.js schließt den Handshake ab und entschlüsselt).

seal approve veröffentlicht Grants weiterhin automatisch. Ein anschließendes seal grant --publish (oder die Standardveröffentlichung nach Anmeldung) überspringt einen noch gültigen Grant mit gleichem Aussteller, Empfängerschlüssel, Gerät und level, meldet die vorhandene Veröffentlichung und gibt kein neues Token aus. --renew-before DAYS erneuert bald ablaufende Grants; --no-publish signiert weiterhin offline. Die Prüfung verhindert Duplikate bei aufeinanderfolgenden Wiederholungen, bietet aber keine Transaktion zwischen parallelen Clients und entfernt keine alten Duplikate. seal show erstellt eine lokale Identität und registriert bei bestehender Anmeldung ihren Schlüssel; für Tests ein separates profile verwenden.

Bedrohungsmodell

Nicht geschützt: ein kompromittiertes Gerät, ein kompromittierter Operatorcomputer oder Exchange, das bereits bei der Erstverbindung (TOFU) das Gerät imitiert. Letzteres lässt sich durch einen Fingerabdruckvergleich über einen unabhängigen Kanal vermeiden. Alle Geräteoperationen akzeptieren ausschließlich versiegelte Sitzungen; die Grenzen des Vorlagenkatalogs und der Browser-Root-Kettenautorisierung stehen in der folgenden Tabelle.

Pfadabdeckung und Entwurf

HTTP und Befehlsvorlagen

Native versiegelte Operationen unterstützen jetzt reine HTTP-Clients. Verwenden Sie remote-cli --transport http oder REMOTE_TRANSPORT=http. POST /api/sealed/connections erstellt eine Verbindung, POST /input übermittelt signierte Handshakes oder Chiffretext, GET /events ruft Ergebnisse ab und DELETE schließt die Verbindung. Kryptografie und Geräteautorisierung bleiben beim Client. Die bisherigen Geräteaktions-Endpunkte liefern weiterhin 409; die Geräteverbindung bleibt unverändert.

https://remote.ivjn.us/sealed-http.md

Erstellung, Bearbeitung und Liste von Befehlsvorlagen bleiben Exchange-Datenbankverwaltung. Vorlagentext, Name und Beschreibung im Katalog sind weder versiegelte Daten noch eine Root-signierte Befehls-Allowlist. Console und CLI führen geladene Vorlagen mit vorhandenem Schlüssel als normales versiegeltes exec (ohne hold) aus. Das Gerät vertraut nur lokaler Richtlinie und Bediener-grant, nicht Katalog-ID, Serverrolle oder Vorlagenbehauptung. Mitglieder mit nur view-grant können keine Vorlagen ausführen; Root muss manage erteilen. Katalogmanipulation erweitert kein grant, aber manage erlaubt ohnehin beliebiges exec. Vorlagen daher prüfen und keine Passwörter/Token im Serverkatalog speichern. Ausgabe wird nur lokal entschlüsselt und angezeigt; Audit erfasst nur sealed-Metadaten, weder Befehl noch Ausgabe.

LAN und Clientauswahl

CLI-Gerätesitzungen verwenden ausschließlich Ende-zu-Ende-Versiegelung und sind nicht auf von Exchange gemeldete seal_key-, Fähigkeits- oder Richtlinienhinweise angewiesen. Fehlende oder entfernte Fähigkeitsinformationen führen zu keiner Herabstufung auf Klartext. Fehler beim Lesen der lokalen Datenbank fest gespeicherter Schlüssel werden direkt gemeldet; beschädigte Vertrauensdaten werden nicht ignoriert.

Versiegelte held-/nicht-held-exec- und Dateiaufgaben werden vor Veröffentlichung im globalen Aufgabenkatalog als versiegelt markiert. Die Race Condition „Schließen vor Verarbeitung des ersten ausgehenden Ereignisses“ erlaubt daher keine Klartextvorschau. Gerätelogs enthalten weder HTTP-Prüfziel/-Methode noch ubus-Objekt/-Methode.

LAN verwendet native Envelopes, signierte Transkripte, Zähler, AEAD, Gerätefixierung und Widerrufsregeln ohne eigene Kryptografie. LAN-Ausgaben passieren Tunnels::seal_outbound vor Übersetzung in OperatorDown; der Gerätedispatcher verwirft Klartextinjektionen an versiegelte Sitzungsnummern. Verbindungsende koppelt held exec ab und beendet andere Operationen; gesperrte IDs verwerfen verspätete Ausgabe. Es gibt kein LAN-Token: Clients legen offline gecachtes grant und Zertifikatskette in hello, das Gerät entscheidet mit demselben authorize wie Exchange über view/manage. Außen werden nur private Adresse und Origin geprüft. LAN lehnt Klartext immer ab, unabhängig von historischen Richtlinienwerten. Die gehostete Web Console verbindet sich weiter mit Exchange.

Die optionalen Geräteinformationen info.seal_mode (allow / require), seal_key und die Fähigkeit sealed bleiben kompatibel. Sie sind weder Autorisierung noch vertrauenswürdiger öffentlicher Geräteschlüssel; letztlich setzt das Gerät die Richtlinie durch. Befehle, Terminals, Dateien, ubus, Sensoren, Aufträge, Netzwerkprüfungen, Desktopoperationen, Geräteupdates, feste Befehlsvorlagen und Browseroperationen in CLI, Web Console und Android Console verwenden sämtlich native versiegelte Sitzungen und bieten keinen Klartextpfad. Der Richtlinienwert allow lehnt Klartextoperationen ebenfalls ab. Fehler bei Handshake, Gerätefixierung, Grant oder Entschlüsselung stoppen den Vorgang; ein Klartextversuch erfolgt nicht. Online-Richtlinienänderungen aktualisieren LAN-Informationen sofort und Cloud-Informationen bei erneuter Registrierung nach Wiederverbindung.

Workspace-Root-Kettenauthentifizierung des Browser Agent

Die Erweiterung meldet sealed, ihren Ed25519-seal_key und seal_mode: require. Nach Kopplung oder Gerätekonfiguration ruft sie POST /api/seal/device mit Gerätezugangsdaten und signiertem Besitznachweis auf. Exchange ermittelt den Workspace aus dem Gerät und bindet dessen öffentlichen Schlüssel. Ein Client mit dem vertrauenswürdigen privaten Workspace-Root-Schlüssel signiert einen view-Grant für genau dieses Browsergerät. Registrierung und Geräte-Bearer dienen Relay-Zugang und Abruf signierter Berechtigungen; Browsersitzungen erfordern Zertifikatsprüfung.

Die Erweiterung prüft Signatur, Root-Kette, Gerätebereich, Stufe, Ablauf und lokale Widerrufe und signiert SealAccept mit eigenem signiertem SealHello als peer. CLI finish_workspace_operator und gemeinsames finishBrowser prüfen den Nachweis, verlangen peer.operator_key == accept.device_key und prüfen die Antwortsignatur. Fehlende oder ungültige Nachweise schließen die Sitzung. Gültige Sitzungen starten automatisch. Raw CDP benötigt zusätzlich lokale Einzelbestätigung oder eine unbeaufsichtigte Freigabe für Bedienerschlüssel, Server und Gerät; view darf CDP nicht nutzen.

Berechtigungen sind nach Server-Origin, Workspace und Gerät getrennt. Der lokale Identitäts-Seed ist nur für vertrauenswürdige Erweiterungskontexte zugänglich. Der erste Workspace-Root wird lokal fixiert; Änderungen werden abgelehnt. CLI und Console nutzen ihre normale Seal-Identität und Root-Kette ohne separaten Browser-Pin-Editor. Root-Signatur, Zertifikatsrechte und Gerätezugangsdaten werden getrennt geprüft; TOFU nativer Geräteschlüssel bleibt eigenständig.

Sicherheitsgrenze: Erstes Root-TOFU erkennt keinen falschen Root eines bösartigen Relays; unabhängig vergleichen. PoP beweist Schlüsselbesitz, keine Mitgliedsgenehmigung. Automatische Root-Client-Freigabe stützt sich auf Mitgliederlisten; sensible Installationen sollten neue Schlüssel prüfen. Erweiterungsprofil / Seed und Web-Console-Veröffentlichungskette schützen. Kompromittierte Endpunkte oder full CDP für bösartige Bediener sind nicht geschützt. Kataloglöschung widerruft keine gecachten signierten Nachweise; Gerätewiderrufe und Ablauf bleiben wichtig. Exchange sieht weiter Routing-Metadaten und kann Nachweise zurückhalten oder den Dienst verweigern.

Identität nicht verfügbar: Kann die Geräteidentität nicht geladen oder geschrieben werden, sind versiegelte Sitzungen nicht verfügbar; sämtliche Klartextoperationen bleiben abgelehnt (fail closed). Weder eine fehlende oder beschädigte Richtliniendatei noch alte Richtlinienwerte aktivieren einen Klartextpfad. Der Schlüsselspeicher muss lokal auf dem Gerät repariert werden.

HTTP-Anfragen müssen dieselbe Exchange-Instanz erreichen. Nach 90 Sekunden ohne Aktivität läuft die Verbindung ab. Eingaben werden seriell gesendet; Wiederholungen behalten Sequenznummer und Chiffretext bei. Verarbeitete Ereignisse werden mit after bestätigt. Web Console, Mobilgeräte und LAN behalten ihren Transport. Vorlagen erfordern weiterhin manage.

Regressionsprüfung

Rust deckt tatsächliche Handshakes mit Geräte-Grants, versiegelte Ergebnisse von exec/attach/tail/cat/sensors/net/update, Klartextablehnung unter sämtlichen Richtlinienwerten, versiegelte LAN-WebSocket-Handshakes/Frames/Richtlinienänderungen, HTTP-409-Hinweise, das Schließen von Browserrouten bei require sowie die verbindlichen Versiegelungsinvarianten für Clients und Geräteinformationen ab. JavaScript prüft bestehende bidirektionale Rust/JS-Vektoren, Operations-Envelopes, versiegelte Vorlagenausgabe ohne Rückfall nach Ablehnung, Browserkonfiguration/Registrierung/Geräteablehnung/lokale Richtlinienänderungen und Fehler bei der clientseitigen Schlüsselbindung. Der prozessweite Seal-Singleton wird in Tests in isolierten Unterprozessen initialisiert, damit parallele Tests nicht gegenseitig Geräterichtlinien ändern.

CARGO_PROFILE_DEV_DEBUG=0 CARGO_PROFILE_TEST_DEBUG=0 cargo test --workspace
cargo fmt --all --check
CARGO_PROFILE_DEV_DEBUG=0 CARGO_PROFILE_TEST_DEBUG=0 cargo clippy --workspace --all-targets -- -D warnings
npm test --prefix shared
npm test --prefix website/console
npm test --prefix browser-agent
node --test scripts/test-pages-worker.mjs

JavaScript benötigt Node 24+. Neue LAN-Versiegelungsregressionen führen echtes HTTP Upgrade / WebSocket über In-Memory-Duplex-Streams aus und prüfen Handshake, Frames und require/allow auch ohne erlaubte Netzwerk-Sockets. Bestehende Loopback-WS/TLS/HTTP-Tests brauchen weiterhin erlaubte Portbindung; sonst scheitern sie mit Operation not permitted und belegen keinen vollständigen Testerfolg. Netzwerkprüfungs-/Updatetests prüfen versiegelte Erfolgs-/Fehlerergebnisse ohne Update-Download oder -Installation.

Besonderes Risiko der Web Console: Der Seitencode kommt von der Pages-Website. Kompromittierte Website/CDN kann Schadskripte liefern, die Seitenklartext lesen oder mit Browserschlüssel signieren (nicht exportierbaren privaten Schlüssel jedoch nicht entwenden). Vertraulichkeit gegenüber Exchange-Betreibern setzt Vertrauen in die Veröffentlichungskette voraus; sonst CLI oder Android Console nutzen.

Identitäten und Schlüssel

Private Bedienerschlüssel bleiben lokal. Console lädt standardmäßig ein Root-Backup mit leerer Passphrase hoch; Exchange oder Datenbankbesitzer können es entschlüsseln. Eine Passphrase kann manuell gesetzt werden. Das Löschen des Backups deaktiviert das automatische Speichern auf diesem Client.

Autorisierung (Exchange ist keine Autorität)

Geräte vertrauen einem öffentlichen Workspace-Root-Schlüssel. Lokale Richtlinie agent.seal.json:

{"mode":"require","root_key":"<base64 Ed25519>","revoked_keys":[]}

Agent entscheidet die Stufe jedes sealed_open selbst:

1. Kein fixierter Root → Ablehnung (no workspace root pinned on this device).
2. Bedienerschlüssel in revoked_keys → Ablehnung.
3. Bedienerschlüssel entspricht root_key → owner (verwalten + lokale Richtlinie ändern).
4. Mitgeliefertes grant: gültige Signatur, operator_key entspricht Handshake, device_id ist dieses Gerät oder *, gültiger Zeitraum (±5 Minuten Uhrabweichung). Signierer ist fixierter Root oder hello enthält rsc1.-Kette (hello.chain, nicht in Handshake-Signatur): vom Root-ausgestellten Zertifikat bis grant-Signierer. Jedes erlaubt weitere Ausstellung; Pfadlänge, Stufe, Gerätescope und Ablauf überschreiten nicht das vorherige. Stufe nur view oder manage, nie owner.
5. Sonst Ablehnung.

Zertifikatskettenbeschränkungen

Geräte akzeptieren kein isoliertes Zwischenzertifikat, sondern eine rsc1.-Kette zum fixierten Workspace-Root (hello.chain, vom Root-ausgestellten Zertifikat bis grant-Signierer). Tiefe hat keine fachliche Obergrenze (auch Organisationen mit über 10 Ebenen); einzige großzügige DoS-Schranke: MAX_CERT_CHAIN = 64 Zertifikate, kodierte Gesamtgröße (Summe kanonischer rsc1.-Tokenlängen) MAX_CERT_CHAIN_BYTES ≤ 64 KiB (check_chain_limits / checkChainLimits in crates/proto/src/seal.rs / shared/seal-cert.js; gleiche Regeln für Gerät, Exchange, CLI, Web, Android). Überschreitung wird direkt abgelehnt.

Jedes Zertifikat hat max_path_len (0–255), eine optionale Ausstellergrenze für weitere Zertifikate darunter. seal cert issue ohne --max-path ist standardmäßig unbegrenzt (gesamte verbleibende Ausstellertiefe; 255 praktisch unbegrenzt). Bei Prüfung dürfen verbleibende Zertifikate max_path_len nicht überschreiten. Root-ausgestellte Administrator-Zwischenzertifikate mit max_path_len 0 erlauben grants, keine weiteren Zertifikate. Auch can_issue false verbietet weitere Ausstellung.

Kindzertifikate müssen im Elternumfang bleiben (cert_within_parent / verify_chain auf dem Gerät):

• Stufe höchstens Elternstufe. Root ist owner; erteilbar nur view oder manage, nicht höher als Elternzertifikat. owner ist in Zertifikaten und grants verboten.
• Gerätescope ist Eltern-Teilmenge. Nur Elternscope mit * erlaubt alle Geräte; sonst jedes Kindgerät in Elternliste. Kind-* nur bei Eltern-*.
• Ablauf nicht später als Elternzertifikat; Root ohne Ablaufobergrenze. Auch grants dürfen Ausstellerablauf und -gerätescope nicht überschreiten.

Zwischenzertifikatswiderruf erfasst alles darunter. Gerät prüft subject_key und serial jedes Kettenzertifikats gegen Richtlinien-revoked_keys. Widerruf eines Zwischenzertifikats macht jede es enthaltende längere Kette ungültig, ebenso Unterzertifikate und deren grants. Löschen in Exchange beendet nur Verteilung; vorhandene Gerätekopien bleiben bis Ablauf gültig. Für sofortige Unterkettenentwertung öffentlichen Subjektschlüssel oder Seriennummer in Geräte-revoked_keys eintragen.

Stufenzuordnung (proto::seal::required_level): view erlaubt Sensoren, hold-Jobliste und lesende Android-Aktionen (status/tree/screenshot/find_text); alles andere (exec, PTY, Dateien, ubus, Netzwerkprüfung, Selbstupdate, Android-Eingabe) benötigt manage.

Berechtigungen sind Root-signiertes JSON. Jede Exchange-Manipulation (view→manage, Gerät, Gültigkeitsverlängerung, Empfänger) entwertet die Signatur; Handshake-Signatur bindet sie zusätzlich an diese Sitzung. Exchange-Kontorollen bestimmen nur Nachrichtenrouting zum Gerät (Mandantensichtbarkeit), nicht Umfang versiegelter Sitzungsrechte. Keine Geräte-„Beanspruchung“, „Eigentümer“ oder „Miteigentümer“: Einziger owner ist Root.

Root-Fixierung auf Geräten:

• TOFU: Nach Verbindung sendet Exchange an versiegelungsfähige Geräte seal_root {token, rotation?} (selbstsignierter rsr1.-Root). Gerät prüft Selbstsignatur; ohne lokalen Root fixiert es ihn in agent.seal.json.
• Rotation: Geänderter Exchange-Root wird nur mit vom fixierten Root signiertem rsx1. angenommen (old_root = fixiert, new_root = neu, gleicher Workspace); sonst ignoriert und protokolliert. Root kann auch versiegelt mit seal_policy_set {root_key} geändert werden (nur aktueller Root hat owner).
• Lokal: remote-agent seal root <key> schreibt Root direkt; remote-agent seal forget-root entfernt ihn für erneutes TOFU bei nächster Exchange-Verbindung (nach Agent-Neustart).

Risiko: Bei TOFU kann bereits kompromittierter Exchange bei Erstverbindung einen falschen Root liefern. Bei Bedenken vor Inbetriebnahme mit remote-agent seal root <key> festlegen (Fingerabdruck: remote-cli seal root). Danach kann Exchange Root nicht ersetzen.

Widerruf: Root: remote-cli seal policy <设备> --revoke <key>; lokal remote-agent seal revoke <key>. Root selbst nicht widerrufbar. Grants laufen ab (Standard 90 Tage). Exchange-Löschung beendet nur Verteilung; lokal importierte Kopien bleiben bis Ablauf gültig und müssen per Geräterichtlinie widerrufen werden.

Exchange als Berechtigungsrelay (nicht vertrauenswürdig)

Kollegen müssen keine rsg1.-Token oder Schlüssel mehr in Chats kopieren: Exchange bietet workspaceweites Verzeichnis öffentlicher Bedienerschlüssel und grant-Relay. Bedrohungsmodell unverändert: kein Klartext für Exchange, keine Ausstellung, Erweiterung oder Fälschung von Berechtigungen. Gespeichert werden nur:

1. Ed25519-Schlüssel mit lokalem Besitznachweis (POST /api/seal/keys).
2. Bereits signierte originale rsg1.-Token (POST /api/seal/grants).
3. Bereits signierte originale rsc1.-Zwischenzertifikate (POST /api/seal/certs). Exchange prüft Ed25519-Ausstellersignatur, kann nicht fälschen. GET /api/seal/certs/chain?subject_key= lädt Token entlang Ausstellerbeziehungen (gleiche 64-Zertifikate-/64-KiB-Grenze), Root-ausgestellte zuerst.

Geräte vertrauen nur fixiertem Root oder dorthin prüfbarer rsc1.-Kette. Exchange parst Token nur zur Indexierung nach owner_key / operator_key / Ablauf; Upload gilt nie als Autorisierung. Schlimmstenfalls hält Betreiber Token zurück (no grant beim Empfänger), kann aber weder view zu manage ändern noch Root imitieren.

Jedes Workspace-Mitglied darf grants hochladen: Signatur ist enthalten, Upload keine Autorisierung; nur Root-signierte grants gelten auf Geräten. Angemeldete CLI verwendet standardmäßig --publish; Web-/Android-Console „Ausstellen und veröffentlichen“ nutzt dieselbe API.

Besitznachweis der Schlüsselregistrierung bindet:

remote-seal-key-register:v1:<workspace_id>:<operator_id>:<public_key>:<issued_at_ms>

Ed25519-Signatur mit diesem Schlüssel; issued_at_ms innerhalb ±10 Minuten der Serverzeit. CLI registriert nach Möglichkeit bei login und seal show; Console nach Anmeldung.

Ohne lokales passendes grant versucht der Bediener vor versiegelten Operationen seal sync; bei Handshake-Ablehnung no grant einmal erneut synchronisieren und einmal wiederholen.

Aussteller-Clients verlängern online selbst ausgestellte bald ablaufende veröffentlichte Berechtigungen automatisch. Signatur bleibt lokal; Exchange speichert neue rsg1.-Token und löscht alte Einträge, kann weder Stufe noch Empfänger ändern.

• Wann: CLI nach Anmeldung und zu Beginn jedes angemeldeten Befehls (seal renew bleibt rein manuell). Web Console bei Anmeldung/Workspace-Eintritt, auch Seitenladen mit bestehender Sitzung. Android nach Anmeldung und Vordergrundwechsel. Ohne Anmeldung oder veröffentlichte grants dieses Schlüssels keine Verlängerung.
• Regeln: GET /api/seal/grants?owner_key=<本机公钥>. Innerhalb 30 Tagen ablaufende grants mit ursprünglichen device_id, operator_key, level für 90 Tage neu ausstellen; nach Veröffentlichung alte per DELETE entfernen. Bei erfolgreichem GET /api/seal/keys fehlende operator_key überspringen; bei Verzeichnisfehler keine Filterung.
• Drosselung: Web/Android: Pro Ausstellerschlüssel höchstens alle 12 Stunden. CLI: seal-renew-state.json im Konfigurationsverzeichnis; Web: localStorage; Android: SecureStore. Fehler beeinflussen aktuelle Operation nicht: CLI-Warnzeile auf stderr, Consoles console.warn. CLI meldet Erfolg kurz auf stderr. Root-Web-Console stellt beim Workspace-Eintritt, Android beim Öffnen von „Ende-zu-Ende-Verschlüsselung“ sofort aus; diese Läufe umgehen Drosselung. Weitere Aktualisierungen desselben Aufenthalts werden gedrosselt.
• CLI-Erneuerung: Erfolge werden pro Server und Ausstellerschlüssel gespeichert. Nach Erfolg entfallen Erneuerungsanfragen für 12 Stunden; Fehler oder Abbruch führen nur zu 5 Minuten Wartezeit. Der gesamte Vorgang hat ein Budget von 30 Sekunden. Fehler nennen Phase und Dauer; scheitert der Hauptbefehl, wird die Erneuerung sofort abgebrochen. Ausstehende Gerätewiderrufe umgehen die Erfolgsdrosselung und behalten ein eigenes Budget von 4 Sekunden. Explizite Erneuerung: remote-cli seal renew. Nach erfolgreicher Anmeldung wird einmal zwingend aktualisiert.
• Root-Client: Root-haltender Superadministrator ersetzt allgemeine Verlängerung durch folgende rollenbasierte Ausstellung, um gerade gelöschte grants nicht neu auszustellen.
• Manuell: remote-cli seal renew bleibt möglich (Standard --before 30 --days 90), gleiche Regeln.

# 按工作区用户名授权对方每一把已登记的钥匙，并发布到 Exchange（默认 90 天）
remote-cli seal grant --device lab-router --to alice --level view
# 只打印 token，不上传
remote-cli seal grant --device lab-router --operator-key <KEY> --no-publish
remote-cli seal keys          # 工作区公钥目录
remote-cli seal sync          # 拉取签给自己钥匙的 grant 并导入本地
remote-cli seal renew         # 手动续签，默认 --before 30 --days 90

Workspace-Superadministrator als Vertrauensanker

Workspace-Root ist der Ed25519-Schlüssel des Superadministrator-Clients. Geräte vertrauen nur seinem öffentlichen Schlüssel und über rsc1. dorthin prüfbaren rsg1.-Berechtigungen. Root-Clients stellen rollenbasiert automatisch aus und verlängern. Exchange bleibt nicht vertrauenswürdig: speichert selbstsignierte rsr1.-Roots, rsx1.-Rotationen und rsi1.-Einladungen, prüft Format und Ed25519, entscheidet nicht über Genehmigungen. Bösartiges Exchange kann Einträge zurückhalten oder falsche Mitglieder einfügen, aber Root-Signaturen nicht fälschen. CLI, Web und Android genehmigen standardmäßig automatisch und signieren neue Verzeichnisschlüssel direkt. Erst bei expliziter Deaktivierung bleiben nie genehmigte und von diesem Root nie veröffentlichte Schlüssel ausstehend.

Vertrauensmodell und Abwägungen

• Root-Schlüssel beim ersten Gebrauch fixieren (TOFU). Beim ersten gültigen Datensatz fixiert Client lokal. CLI: seal-root.json (0600) neben config.toml, Schlüssel 服务器|工作区 id. Web: localStorage (remote.seal.root.<工作区 id>). Android: SecureStore (remote.seal.rootstate, JSON nach Server/Workspace). Danach jedes Mal Selbstsignatur/Fingerabdruck prüfen. Root-Wechsel erzeugt deutliche Warnung, Client vertraut nicht automatisch neu (Geräte wechseln per rsx1., siehe oben). Nach Fingerabdruckprüfung explizit remote-cli seal root --trust <key> oder „Neuem öffentlichen Root vertrauen“ wählen.
• Einladungen öffnen nur Registrierung. Root signiert rsi1. (Workspace-ID, Root-Schlüssel, 16-Byte-nonce, Ablauf). Administrator-/Operator-/Leserclients laden Einladung bei Anmeldung, Folgebefehlen, Seitenladen oder Vordergrundwechsel, prüfen mit fixiertem Root und registrieren über bestehendes POST /api/seal/keys. Einladung ist keine Berechtigung.
• Rollenbasierte Ausstellung, neue Schlüssel lokal genehmigen. Root-haltender Superadministrator liest GET /api/seal/roster (nur Superadministrator, einschließlich deaktivierter Mitglieder, Rollen, operator_device_grants, registrierter Schlüssel) und eigene veröffentlichte grants, berechnet Sollrechte. Pro registriertem Schlüssel gelten:
  • Superadministrator und uneingeschränkter Administrator: manage *.
  • Eingeschränkter Administrator: je Gerätefreigabe manage bei can_manage, sonst view.
  • Uneingeschränkter Operator: view * plus manage je can_manage-Gerät.
  • Eingeschränkter Operator: je Gerätefreigabe manage oder view.
  • Uneingeschränkter Leser: view *.
  • Eingeschränkter Leser: view je freigegebenem Gerät. Lesekonten dürfen nicht bedienen, daher auch bei can_manage kein manage.
  • Deaktivierte Mitglieder: keine Ausstellung.
  • Standard 90 Tage, Verlängerung unter 30 Tagen Restlaufzeit.
• Administrator-Zwischenzertifikate. Root-Client stellt aktiven Administratoren rsc1. aus (manage, can_issue, max_path_len 0, 90 Tage). Uneingeschränkte Administratoren Scope *, eingeschränkte delegierte can_manage-Geräte. Verlängerung bei 30 Tagen Restlaufzeit. Unbestätigte Schlüssel erhalten keine Zertifikate. Mit gültigem Zwischenzertifikat stellt Administrator-Client per eigenem Schlüssel und Kette grants für verwaltete Mitglieder aus, begrenzt auf Schnittmenge von Zertifikat und Delegation. Noch frisches Root-grant für denselben Bediener, Gerät und Stufe verhindert doppelte Ausstellung (* umfasst Geräte, manage umfasst view). Exchange-Zertifikatsentzug stoppt nur Verteilung, Gerätekopien gelten bis Ablauf. Harter Widerruf per Geräte-revoked_keys.
• Automatische Genehmigung standardmäßig aktiv. Web Console (localStorage) und Android (SecureStore): fehlendes Feld bedeutet an (absent = on), nur explizites false bleibt aus; bestehendes Aus wird nicht wieder aktiviert. Aktive Root-Clients signieren direkt nach Mitgliederliste: schwächer, da kompromittierter Exchange falsche Mitglieder mit sofortiger Signatur einfügen kann. Schalter „Neue öffentliche Schlüssel automatisch genehmigen“. CLI ist wie Web/Android Console standardmäßig aktiviert: Fehlt die Datei seal-approved.json oder das Feld auto_approve, gilt an; explizites "auto_approve": false bleibt aus. Mit remote-cli seal approve --no-auto-approve deaktivieren und mit remote-cli seal approve --auto-approve wieder aktivieren; die Auswahl wird gespeichert. Danach nie genehmigte und von diesem Root nie veröffentlichte Schlüssel in lokale Warteliste (CLI seal-approved.json, Web localStorage, Android SecureStore). remote-cli seal pending zeigt Benutzer/Fingerabdruck; seal approve --all oder seal approve <key>… genehmigt und stellt sofort aus. Genehmigte oder von Root veröffentlichte Schlüssel werden automatisch verlängert/rollenangepasst. Eigener Ausstellerschlüssel braucht keine zweite Genehmigung.
• Beim Öffnen ausstellen. Root-Clients stellen beim Web-Workspace-Eintritt und Android-Öffnen von „Ende-zu-Ende-Verschlüsselung“ sofort aus, ohne 12-Stunden-Drosselung. Weitere automatische Aktualisierungen desselben Aufenthalts gedrosselt. Schalteränderung oder „Genehmigen“ erzwingt weiteren Lauf.
• Kontodialog, Badge und Fehlerzeile. Web-Schalter/Warteliste im Geräteseiten-Dialog „Konto“ (Werkzeugleiste „Konto“). Bei wartenden Schlüsseln Badge „N öffentliche Schlüssel warten auf Genehmigung“ in derselben Leiste; Klick öffnet Dialog. Ausstellungsfehler: „Workspace-Root-Ausstellung fehlgeschlagen: …“. Token und langes Schlüsselmaterial werden aus der Zeile entfernt. Android zeigt denselben Schalter, Badge und Fehler auf „Ende-zu-Ende-Verschlüsselung“.
• Herabstufung widerruft keine alten Geräte-grants. Entfernte/deaktivierte Mitglieder oder aus Verzeichnis verschwundene Schlüssel: Exchange-grants löschen, Verlängerung stoppen, bestmöglich revoked_keys auf online versiegelungsfähigen Geräten schreiben. Rollenherabstufung ersetzt nur grant, ohne den Schlüssel in revoked_keys aufzunehmen. Importierte alte grants bleiben bis Ablauf gültig. Root selbst nie widerrufen. Nicht im 4-Sekunden-Budget erledigte Widerrufe lokal merken und beim nächsten Befehl fortsetzen, unabhängig von 12-Stunden-Ausstellungsdrosselung. Wird Schlüssel wieder gewünscht, Widerruf nur auf erfolgreich widerrufenen Geräten zurücknehmen.
• Root automatisch erzeugen. Bei Superadministratorregistrierung (register/erstes Workspace-Konto) oder jeder späteren Anmeldung veröffentlicht dessen CLI-/Web-/Android-Client ohne Exchange-Root den eigenen Schlüssel lokal als Root und sofort eine 90-Tage-Einladung. Fehlende oder in 30 Tagen ablaufende Einladungen werden mit Ausstellungsdrosselung erneuert. remote-cli seal root --publish bleibt manuell möglich.

Einmalige Einrichtung

1. Superadministrator registriert/meldet sich in einem Client an: Root automatisch erzeugt/veröffentlicht (CLI-Hinweis auf stderr, Console-Benachrichtigung).
2. Privaten Root sichern (eine oder beide Optionen):
   • Nur selbst behalten, nichts hochladen: remote-cli seal root --export root.rsk (0600-Datei, - für stdout) oder „Privaten Root exportieren“.
   • Manuelle Cloudsicherung: remote-cli seal backup oder „Cloudsicherung des privaten Roots“. Passwort darf leer sein, aber bei leerem/schwachem Passwort kann Exchange Root entschlüsseln und alle Geräte kontrollieren.
3. Versiegelungsfähige verbundene Geräte fixieren automatisch Root (TOFU); sicherer vorab lokal remote-agent seal root <根公钥>.
4. Neue Mitglieder registrieren nach Anmeldung ihren Schlüssel. CLI/Web/Android genehmigen standardmäßig automatisch, Root signiert direkt. Bei deaktivierter Genehmigung: remote-cli seal pending, danach remote-cli seal approve --all oder „Genehmigen“ für sofortige Ausstellung.

remote-cli seal root                       # 显示已固定的根公钥和指纹
remote-cli seal root --export root.rsk     # 导出根私钥（rsk1. 文本）
remote-cli seal root --import root.rsk     # 在另一台机器装上根私钥（或 seal restore）
remote-cli seal root --rotate              # 生成新根，旧根签 rsx1. 轮换，自动按新根重签成员授权
remote-cli seal invite                     # 单独刷新邀请（默认 90 天，--days N）
remote-cli seal pending
remote-cli seal approve --all              # 或 seal approve <key>…；--no-auto-approve 关闭自动批准（保持开启较弱）

Andere Maschine / Root wechseln

• Root auf anderem Gerät: Nach Superadministratoranmeldung versuchen CLI / Web / Android automatisch wiederherzustellen, wenn lokal veröffentlichter Root fehlt und Exchange rsb1.-Backup besitzt (siehe „Automatische Root-Wiederherstellung bei Anmeldung“). Sonst manueller Import: seal root --import <文件|->, rsk1. in Console einfügen und „Privaten Root importieren“ oder Exchange-Backup wiederherstellen (seal restore / „Aus Exchange wiederherstellen“). Import des aktuellen Roots installiert nur lokal, ohne Datensatzänderung.
• Rotation: seal root --rotate („Neuen Root erzeugen und rotieren“) oder Import eines abweichenden rsk1.-Schlüssels. Mit lokalem aktuellem Root signiert Client damit rsx1. und sendet es mit neuem rsr1. via PUT /api/seal/root; Exchange verteilt online, Geräte prüfen alte fixierte Root-Signatur und wechseln, Offlinegeräte beim nächsten Verbinden. Alte Root-genehmigte Mitglieder bleiben lokal genehmigt; danach alle Mitglieder-grants für 90 Tage mit neuem Root signieren. Alter lokaler Schlüssel als seal-identity.<毫秒>.previous.pk8. Neuen Root erneut exportieren/sichern.
• Alter Root verloren: Keine signierte Rotation möglich. Neuer Root wird veröffentlicht, aber Geräte mit altem Root lehnen ihn ab. Je Gerät remote-agent seal root <新根公钥> und Agent-Neustart nötig.
• Superadministratorübergabe: Siehe „Superadministratorübergabe = Root-Zertifikatsübergabe“. Nur Rollenänderung reicht nicht; Geräte vertrauen privatem Root.

Automatische Root-Wiederherstellung bei Anmeldung

Nach erfolgreicher Superadministratoranmeldung vor Erzeugung lokaler Versiegelungsidentität versuchen CLI / Web Console / Android Console nach derselben reinen Entscheidungstabelle (Rust decide_auto_restore, JS decideAutoRestore), veröffentlichten Workspace-Root aus Exchange-rsb1. lokal wiederherzustellen:

1. Überspringen: Kein Superadministrator; gleicher Root bereits lokal; Cloudsicherung deaktiviert (CLI REMOTE_SEAL_CLOUD_BACKUP=0, Web localStorage.seal.cloudBackup=off, Android SecureStore remote.seal.cloudBackup=off); kein veröffentlichter Root.
2. Einmal Backup laden: GET /api/seal/backup (stündlich begrenzt). Ohne Backup Hinweis auf Root anderswo, keine Anmeldeblockade.
3. Still leeres Passwort versuchen: Zuerst leerer String. Bei erfolgreicher Entschlüsselung, passendem öffentlichen Root und keinem anderen lokalen Schlüssel installieren und als Workspace-Root fixieren.
4. Sonst Passwort anfordern: CLI versucht REMOTE_SEAL_BACKUP_PASSPHRASE, im TTY verdeckte Eingabe. Web/Android nur nicht blockierender Hinweis: Passwort auf Versiegelungsseite eingeben, „Aus Exchange wiederherstellen“. Kein blockierender Dialog, Anmeldung normal abschließen.
5. Sicherheitsgrenze: Nie still abweichenden lokalen Schlüssel überschreiben (seal restore --force oder Console-Bestätigung nötig); entschlüsselter Schlüssel muss veröffentlichtem Root entsprechen; Fehler warnen nur, Anmeldung scheitert nicht; niemals Passwort, Seed oder rsb1.-Chiffretext ausgeben.
6. Nicht blockierende Risikohinweise: Nach Installation Hinweis auf erhöhtes Offenlegungsrisiko durch Root auf mehreren Maschinen; bei leerem Passwort zusätzlich Hinweis, dass Exchange Root entschlüsseln kann.

Superadministratorübergabe = Root-Zertifikatsübergabe

Kontorolle Superadministrator und vertrauter Workspace-Root sind getrennt. Nur Rollenübertragung gibt dem Nachfolger keinen privaten Root; Geräte vertrauen ihm nicht automatisch. Übergabe heißt privaten Root übergeben, sofort rotieren und so übergebene Kopie entwerten.

1. Aktueller Superadministrator mit lokalem veröffentlichtem Root: POST /api/superadmin/transfer, Body {operator_id, root_handover?}. root_handover ist passwortverschlüsseltes rsb1. mit Backup-Verfahren (Argon2id 64 MiB, t=3, p=1, ChaCha20-Poly1305), Passwort darf leer sein. CLI remote-cli seal handover <账号>. Web/Android bieten bei „Superadministrator übertragen“ mit lokalem Root optionales Passwort und Paket an.
2. Exchange speichert nur, entschlüsselt nicht. Prüfung: Präfix rsb1. oder rsk1., maximal 16384 Zeichen, nur URL-sicheres ASCII. Ohne root_handover wird verbliebenes Workspace-Übergabepaket gelöscht.
3. Neuer Superadministrator lädt GET /api/superadmin/handover → {blob, from_operator, created_at} (sonst 404), entschlüsselt, installiert lokal und rotiert wie „Neuen Root erzeugen und rotieren“: alter Root signiert rsx1., neuer wird veröffentlicht. Danach DELETE /api/superadmin/handover. CLI remote-cli seal accept-handover. Console zeigt bei Paket „Root-Übergabe annehmen“.
4. Rotation entwertet alte Kopien. Übergeben wird Root vor Rotation. Onlinegeräte wechseln nur bei vom vertrauten alten Root signiertem Rotationsdatensatz. Alter Inhaber kann weder neue Root-grants signieren noch gewechselten Geräte-Root ändern. Vor Abschluss bleibt schwach/leer geschütztes rsb1. entschlüsselbar; Passwort separat übergeben.

Unabhängiger Kanal: Ohne Exchange-Chiffretextspeicherung remote-cli seal handover <账号> --out-of-band. stdout enthält nur eine rsb1.-Zeile, Request kein root_handover. Zeile und Passwort anderweitig übergeben; Empfänger remote-cli seal accept-handover <那一行>. Console-Passwortabbruch (Android „Nur Konto übertragen“) überträgt nur Rolle, lädt keinen Root hoch; Root separat übergeben (exportiertes rsk1. oder unabhängiges rsb1.).

Handshake und Übertragungsformat

CLI                         Exchange                       agent
 │ open_sealed{session_id,    │                               │
 │   device_id, hello}        │──sealed_open{session_id,hello}▶│ 验证 hello 签名、授权 → 级别
 │                            │◀─sealed_accept{session_id,     │
 │◀─sealed_accept (原样转发) ──│        accept}                │
 │ 验证设备签名 + pin          │                               │
 │ sealed_input{packet} ─────▶│──sealed_input────────────────▶│ 解密、校验级别、执行
 │ 二进制帧 kind=4 (PTY 键入)─▶│── 只改写帧头编号 ─────────────▶│
 │◀── sealed_event{packet,last}│◀── sealed_event ──────────────│ 所有输出在出站队列加密
 │◀── 二进制帧 kind=4 ─────────│◀── 二进制帧 kind=4 ───────────│

• hello = {v, operator_key, operator_ephemeral, nonce, grant?, sig}, signiert ["remote-seal-v1/hello", v, device_id, operator_key, operator_ephemeral, nonce, grant.sig|""] (JSON-Array, kanonische Bytes).
• rsr1. signiert ["remote-seal-v1/workspace-root", v, workspace_id, root_key, issued_at_ms]; Rotation rsx1. = {v, workspace_id, old_root, new_root, issued_at_ms, sig}, von old_root signiert über ["remote-seal-v1/root-rotation", v, workspace_id, old_root, new_root, issued_at_ms]. Exchange → Agent: {"type":"seal_root","token":"rsr1.…","rotation":"rsx1.…"?} (nur Klartext-Steuernachrichten von Exchange akzeptiert, nicht im Tunnel).
• accept = {v, device_key, device_ephemeral, nonce, level, sig}, signiert ["remote-seal-v1/accept", v, device_id, operator_key, operator_ephemeral, hello.nonce, hello.sig, device_key, device_ephemeral, nonce, level]. Exchange-Änderung von level entwertet Signatur.
• Sitzungsschlüssel: salt = SHA256(accept 签名字节), PRK = HKDF-Extract(salt, X25519(o, b)), K_od = Expand("remote-seal-v1/operator_to_device"), K_do = Expand("remote-seal-v1/device_to_operator").
• AEAD: ChaCha20-Poly1305, AAD = remote-seal-v1, nonce = Kanalbyte (0 Text / 1 Binär) ‖ drei 0 ‖ u64-Zähler (Big Endian). Pro Richtung/Kanal ab 0 strikt +1; jede Abweichung schließt sofort.
• Text: {"counter":n,"ciphertext":"<base64>"}. Klartext JSON: Bediener → Gerät SealedRequest (bestehendes DeviceDown oder Root-Verwaltung seal_policy_get / seal_policy_set {mode?, root_key?, revoke?, unrevoke?}); Gerät → Bediener SealedResponse (bestehendes DeviceUp oder seal_policy). Agent ersetzt innere session_id durch Tunnelnummer.
• Binär: StreamKind::Sealed = 4, Payload counter(u64 BE) ‖ AEAD(inner_kind ‖ bytes), inner_kind 1/2/3 (stdout/stderr/PTY).
• Jede versiegelte Sitzung trägt eine Operation (exec, PTY, Dateiübertragung …), bestehendes 1:1-Modell. Agent verschlüsselt Abschlussnachrichten und markiert außen last:true; Exchange gibt Routing frei und ergänzt Audit ohne Inhaltskenntnis.
• close_session → sealed_close{detach:false} (beenden); Operator-Verbindungsabbruch → sealed_close{detach:true} (Agent entscheidet: hold exec abkoppeln, Rest beenden).
• Größenlimit: base64-Chiffretext etwa 2,8 MiB (für 2-MiB-Android-Screenshot), äußere Verpackung MAX_SEALED_WIRE.

Agent-Abwehr: Klartext in Ausgangswarteschlange mit versiegelter Nummer wird verschlüsselt oder verworfen. Nach Sitzungsende bleibt Nummer dauerhaft gesperrt (verspätete hold-Ausgabe verworfen, nie Klartext). Versiegelt gestartete/angehängte hold-Jobs erscheinen nicht in alten Listen und erlauben dort kein attach/tail/cat/kill.

Export und Sicherung des privaten Root-Schlüssels

Privater Root kontrolliert alle Workspace-Geräte. Aufbewahrung entscheidet Superadministrator; Console speichert standardmäßig mit leerer Passphrase; Löschen deaktiviert die automatische Speicherung:

• Export (kein Upload): rsk1. + base64url ohne Padding eines 32-Byte-Seeds. CLI seal root --export FILE|- (0600-Datei), Console „Privaten Root exportieren“ (Web im Eingabefeld, Android Zwischenablage). Jeder Inhaber kontrolliert alle Geräte.
• Verschlüsseltes Exchange-Backup (Console automatisch, CLI manuell): Nur Superadministrator mit lokalem veröffentlichtem Root darf hochladen. Versioniertes rsb1.-Token (base64url-JSON, maximal 4096 Zeichen). Argon2id leitet Schlüssel aus Passwort ab; Produktionsparameter fest 64 MiB, 3 Iterationen, Parallelität 1, im Token enthalten. Salt 16 Byte, ChaCha20-Poly1305-nonce 12 Byte, jedes Backup zufällig. AAD remote-seal-v1/key-backup:{version}:{public_key}; Änderungen an Version, Schlüssel oder Chiffretext schlagen fehl. Nach Entschlüsselung muss Seed-Schlüssel Token-Schlüssel entsprechen. Decoder lehnt vor Argon2 zu schwache/große Parameter ab (Speicher 8 KiB–256 MiB, Produktion mindestens 64 MiB; Iterationen 1–8, Produktion mindestens 3; Parallelität nur 1).
• Passwort optional, keine Stärkeerzwingung. Leer verwendet ebenfalls Argon2id mit leerem String und gleichem Format. Bei leer/schwach (unter 12 Zeichen, wenige Zeichenklassen, Wiederholung, häufiges Passwort) warnen CLI/Web/Android: Exchange oder Datenbankleser können Root entschlüsseln und alle Geräte kontrollieren. Rust/JS nutzen gleiche Warnregeln und Testvektoren inklusive leerem Passwort.

PUT / GET / DELETE /api/seal/backup gelten nur aktuellem Konto; PUT/GET nur Superadministrator. Body {blob}. Exchange prüft rsb1. und Länge, entschlüsselt nie. GET pro Konto/Prozess/Stunde maximal 5, danach 429; verlangsamt nur Online-Raten, Datenbankkopien ermöglichen Offline-Bruteforce. Lesen/Schreiben/Löschen auditiert, Details nur Bytezahl.

• CLI remote-cli seal backup (zweimal verdeckte Eingabe, Enter für leer, oder --passphrase-stdin); remote-cli seal restore (bei anderem Schlüssel --force, alter bleibt seal-identity.<毫秒>.previous.pk8), danach lokal als Workspace-Root fixieren. Anmeldung versucht ebenfalls Wiederherstellung (siehe oben). Keine Ausgabe von Root, Passwort oder Chiffretext.
• Web Console: Root muss exportierbar sein. Bei Root-Erzeugung wird nicht exportierbarer WebCrypto-Schlüssel durch lokalen IndexedDB-Seed ersetzt. Login-bootstrap stellt vor Identitätserzeugung automatisch wieder her; localStorage.seal.cloudBackup=off deaktiviert.
• Android Console: Seed in expo-secure-store. bootstrapSeal stellt ebenfalls zuerst wieder her; remote.seal.cloudBackup=off deaktiviert.

Verwendung

remote-cli seal show                       # 生成/显示本机操作员公钥与指纹
remote-cli exec lab-router -- uname -a
remote-cli shell lab-router
remote-cli seal policy lab-router          # 根：查看设备授权与吊销策略

# 根给同事手动授权（通常不需要：根客户端按角色自动签发）（默认 90 天；对方已登录的客户端会自动登记公钥）
remote-cli seal grant --device lab-router --to alice --level view
# 或仍用公钥；--no-publish 只打印 token
remote-cli seal grant --device lab-router --operator-key <KEY> --level view --no-publish
# 手动续签即将到期的已发布授权（默认 --before 30 --days 90；上线时也会自动续签）
remote-cli seal renew
# 同事：拉取 Exchange 上签给自己的授权（登录后也会自动 sync）
remote-cli seal sync
# 仍可手动导入
remote-cli seal import-grant rsg1.xxxxx

# 根私钥：导出（不上传）或可选的加密云端备份
remote-cli seal root --export root.rsk
remote-cli seal backup
remote-cli seal restore                    # 已有不同钥匙时加 --force

# 带外固定设备指纹（在设备上 `remote-agent seal show`）
remote-cli seal trust-device lab-router <DEVICE_KEY>

Web Console / Android Console: Sämtliche Geräteoperationen verwenden ausschließlich native versiegelte Sitzungen. Befehle, hold-Liste/kill/tail/cat, Terminal, Dateien, Screenshots und Eingaben (Android/Desktop), UI-Baum, Sensoren, ubus, Systemlogs und Selbstupdate laufen durch den versiegelten Tunnel; die Seite zeigt „🔒 Ende-zu-Ende verschlüsselt“. Web-Gerätedetails oder Android-Einstellungen → „Ende-zu-Ende-Verschlüsselung“ bietet dieselben Funktionen wie die CLI: lokaler öffentlicher Schlüssel/Fingerabdruck, Arbeitsbereichs-Root (Superadministrator: privaten Root-Schlüssel exportieren/importieren/rotieren, Übergabe annehmen, neue öffentliche Schlüssel genehmigen), Geräteschlüssel und Widerrufsrichtlinie ansehen/ändern (Root erforderlich), Grants ausstellen (rsg1.-Token, CLI seal import-grant), Grants importieren, öffentlichen Geräteschlüsseln vertrauen und automatisches Cloudbackup des privaten Root-Schlüssels (leere Passphrase erlaubt; bei schwacher Passphrase deutliche Warnung, dass Exchange entschlüsseln kann). Die Erstverbindung fixiert den Gerätefingerabdruck (TOFU); Änderungen werden danach abgelehnt und erfordern Überprüfung. Normale Mitglieder haben unterschiedliche Schlüssel in CLI, Browser und auf dem Telefon; jeder wird registriert und vom Root-Client entsprechend der Rolle autorisiert. Für mehrere Root-Geräte kann der Superadministrator ein Passphrasenbackup hochladen und bei Anmeldung auf einem neuen Gerät automatisch wiederherstellen oder den privaten Root-Schlüssel auf jedem Gerät importieren.

Lokal auf dem Gerät: remote-agent seal show | root <key> | forget-root | revoke <key> (Änderungen werden nach Agent-Neustart wirksam; über versiegelte Sitzungen vorgenommene Änderungen mit seal policy gelten sofort).

Standardverhalten

• Neue Geräte fixieren nach Verbindung mit Exchange die Arbeitsbereichs-Root (TOFU); die Root und von ihr signierte Grants ermöglichen die Bedienung. Falls Exchange bei der Erstverbindung nicht vertrauenswürdig sein könnte, führen Sie vorher lokal auf dem Gerät remote-agent seal root <key> aus.
• Nicht verfügbare Identitätsschlüssel oder beschädigte Richtlinien führen zur Ablehnung (fail closed); reparieren Sie Schlüssel und Richtlinien lokal auf dem Gerät, bevor Sie erneut verbinden.