Sicherheit · Hiatus Remote

Bedrohungsmodell

Hiatus Remote ist gegen diese Angreifer entworfen. Außerhalb des Modells bleibt ein Angreifer mit Administrator- oder root-Rechten auf einem der beiden Endgeräte: Er kann ohnehin alles mitlesen.

Angreifer	Ziel	Gegenmaßnahme
Betreiber des Relays (kompromittiert oder neugierig)	Sitzung entschlüsseln, Passwort erraten, sich als Partner ausgeben	SPAKE2+ nach RFC 9383: Das Passwort verlässt die Endgeräte nie; Channel Binding an den TLS-Exporter; Ende-zu-Ende-Verschlüsselung; Geräteschlüssel-Pinning
Passiver Lauscher im Netz (WLAN, Provider)	Bildschirm, Dateien, Eingaben mitlesen	TLS 1.3 zum Relay mit SPKI-Pin, QUIC/TLS 1.3 zwischen den Geräten, darüber eigene Nutzlastverschlüsselung mit AES-256-GCM bzw. ChaCha20-Poly1305
Aktiver Man-in-the-Middle	Sich zwischen Supporter und Target schieben	Schlüssel sind an das Passwort gebunden; abweichender Fingerprint fällt beim Abgleich auf; bei bekannten Geräten Geräteschlüssel-Pinning
Passwort-Rater	Einmal- oder permanentes Passwort durchprobieren	Ein Versuch je Handshake; Sperre mit exponentiellem Backoff am Target; neues Einmal-Passwort nach drei Fehlversuchen; Argon2id-Verifier für das permanente Passwort
Böswilliger Partner	Über manipulierte Videodaten, Dateinamen oder Terminalausgaben den Supporter-Rechner angreifen	Decoder in eigenem Prozess unter AppContainer bzw. seccomp; Parser gefuzzt; geprüfte Namen und Grenzen beim Ordner-Download; libvterm ohne OSC 52
Lokaler Nutzer ohne Rechte auf dem Target	Dienst oder Agent zur Rechteausweitung missbrauchen	Gehärtete IPC mit Peer-Prüfung; Agent-Pipe nur für SYSTEM mit Start-Token; Einstellungen nur mit Administratorrechten
Betrüger („Support-Scam“)	Opfer überreden, Zugriff zu gewähren	Deutliche Warnung im Anfrage-Dialog, feingranulare Berechtigungen (alles außer Bildschirm voreingestellt aus), jederzeit sichtbare Hinweisleiste mit Abbruch

Kryptografie

Schlüsselaustausch

SPAKE2+ nach RFC 9383, Ciphersuite P256-SHA256-HKDF-SHA256-HMAC-SHA256, über den Signalisierungskanal. Der Server kennt das Passwort nie. Eigenes Modul auf OpenSSL-Primitiven, geprüft gegen die Testvektoren des RFC und Wycheproof. K_shared

Channel Binding

Direkt nach dem QUIC-Handshake sendet jede Seite HMAC(K_bind, TLS-Exporter). Stimmt der Wert nicht, endet die Verbindung sofort. Die QUIC-Verbindung ist damit an das PAKE gebunden; selbstsignierte Zertifikate genügen. K_bind

Ende-zu-Ende

AES-256-GCM, auf Geräten ohne AES-Beschleunigung ChaCha20-Poly1305; die Wahl ist Teil des Transcripts. 96-Bit-Nonce aus Stream-ID und streng monotonem Zähler, Schlüsselerneuerung nach 2³² Datensätzen oder 60 Minuten. AEAD

Schlüsselableitung

HKDF-SHA256 aus K_shared mit festen Labels: Richtungsschlüssel, Bindung, Fingerprint, Resumption-Token, Geräte-Authentifizierung; je QUIC-Stream ein eigener Teilschlüssel. HKDF-SHA256

Fingerprint

Vier Wörter aus einer festen Liste von 256 deutschen Wörtern (32 Bit), alternativ sechs Ziffern oder QR-Code, auf beiden Seiten sichtbar. Ein Abgleich deckt einen Angriff auch dann auf, wenn das Passwort über einen abhörbaren Kanal ging. falke · ahorn · kupfer · welle

Unbeaufsichtigter Zugriff

Permanentes Passwort (mindestens 12 Zeichen) nur als Argon2id-Verifier gespeichert, Geräteschlüssel (Ed25519) gepinnt, Allowlist der zugelassenen Supporter, Dienst ohne Oberfläche, Sperre nach der Sitzung. Argon2id · Ed25519

Was der Relay sieht

Sieht

IDs der beiden Seiten und Zeitpunkte
IP-Adressen und Ports für das Hole Punching
Paketgrößen und Datenmenge im Fallback-Fall
Das SPAKE2+-Transcript, aus dem sich ohne Passwort nichts ableiten lässt

Sieht nicht

Das Passwort, weder Einmal- noch permanentes
Bildschirminhalte, Tastatureingaben, Dateien, Ton
Den Fingerprint oder die Sitzungsschlüssel
Ob eine direkte Verbindung zustande kam (keine Nutzdaten)

Bewusst nicht abgedeckt ist die Verkehrsanalyse (wer mit wem, wie lange). Wer das vermeiden will, betreibt den Relay selbst; das Docker-Image ist dafür vorgesehen.

Prozesshärtung

Alle Programme mit Warnungen als Fehler und Härtungs-Flags gebaut; BinSkim prüft bei jedem vollen Check Dynamic Base, High Entropy VA, NX, Control Flow Guard, CET und /Qspectre.
Schlüsselmaterial liegt in SecretBytes (nicht kopierbar, feste Größe) und wird beim Freigeben mit OPENSSL_cleanse gelöscht.
Der Decoder läuft unter Windows im AppContainer, unter Linux mit seccomp; Shared Memory zum Agent ist nur lesend.
Tunnel erreichen nur localhost und freigegebene Ports; Android-Debugging per Adresse ist auf private Netze beschränkt und steht im Verlauf.

Sicherheits-Review M8

Im Oktober 2026 wurde der Release-Kandidat strukturiert geprüft: Bedrohungsmodell gegen den heutigen Funktionsumfang abgeglichen, Code-Durchsicht in fünf Bereichen (Handshake und Krypto; Identität, Allowlist, Relay; lokale IPC; privilegierte Pfade und Installer; Dateien, Shell, Tunnel, adb), Fuzzing-Nachtlauf über 26 Ziele mit Mutantentest, clang-tidy und MSVC /analyze, BinSkim, CVE-Abgleich der 22 Abhängigkeiten über die NVD. Die zu behebenden Befunde sind umgesetzt; wenige Hinweise wurden als Restrisiko akzeptiert und dokumentiert. Ein externer Penetrationstest war nicht Teil des Reviews.

Grenzen

Der Fingerprint schützt nur, wenn die Benutzer ihn tatsächlich vergleichen. Die Oberfläche fordert dazu auf, erzwingt es aber nicht.
Der Relay sieht Metadaten. Gegen Verkehrsanalyse hilft nur ein eigener Relay.
Code-Signierung (Authenticode, minisign) folgt mit der Veröffentlichung; bis dahin gilt die SHA-256-Prüfsumme je Datei.
Ein Angreifer mit Administratorrechten auf einem Endgerät liegt außerhalb des Modells.