← Zurück zu WindowsHelper

Sicherheitsmodell

Wie WindowsHelper Ihren PC und Ihr Telefon schützt, welche Kryptografie wir verwenden und wogegen wir uns ausdrücklich nicht schützen. Letzte Aktualisierung: 25.04.2026.

eine Schwachstelle melden

E-Mail support@windowshelper.app mit Betreff [security]. Bitte öffnen Sie keine öffentlichen GitHub-Probleme – geben Sie uns vor der Veröffentlichung Zeit, um einen Fix zu liefern.

Lebenszyklus des Pairing-Codes

Der Pairing-Code ist das gemeinsame Geheimnis, von dem sich jede andere Krypto-Operation ableitet. Der gesamte Lebenszyklus:

[ Telefon ERZEUGT einen zufälligen 8-stelligen Code ]
   ↓
[ Telefon SCHREIBT Code + sessionId in das Firestore-Dokument pc_connections ]
   ↓
[ Telefon ZEIGT dem Nutzer den Code auf dem Bildschirm ]
   ↓
[ Nutzer LIEST den Code und tippt ihn in das Eingabefeld des Companion ]
   ↓
[ Companion FRAGT bei Firestore nach der wartenden Sitzung zum Code ]
   ↓
[ Beide Seiten LEITEN die Krypto-Schlüssel aus SHA-256(Code, sessionId) AB ]
   ↓
[ Der Code BLEIBT auf beiden Seiten im Speicher; keine Seite schreibt ihn nach Firestore ]
   ↓
[ Trennen / neu koppeln LÖSCHT den Code auf beiden Seiten ]

Zufällig: Codes, die über kryptografisch sichere RNGs generiert werden.
30-Zeichen-Alphabet × 8 Stellen ≈ 656 Milliarden Kombinationen. Ohne I, L, O, Z, 0 und 1, um visuelle Verwechslung zu vermeiden, nicht aus Sicherheitsgründen — der Coderaum ist dicht genug, dass ein 10-Minuten-Fenster für Brute Force mit den Ratenlimits von Firestore undurchführbar ist.
Verschlüsselt auf diesem PC gespeichert. Der Companion speichert den Code in der Registrierung Ihres Windows-Kontos, verschlüsselt mit DPAPI, damit er sich nach einem Neustart wieder verbinden kann.
Gelöscht, wenn Sie die Verbindung trennen und die Sitzung löschen, den Code wechseln oder deinstallieren. Beim Schließen der App bleibt er erhalten, damit sich der Companion wieder verbinden kann.

Kryptographie

AES-256-GCM (Befehlsvertraulichkeit + Integrität)

Jeder über das Kabel gesendete Befehl wird mit AES-256-GCM verschlüsselt, einem authentifizierten Verschlüsselungsmodus.

Schlüssel: 256 Bit, abgeleitet als SHA-256("WH_SECURE_{code}_{sessionId}_CMD_KEY").
Nonce: 96 Bit (12 Bytes), pro Nachricht frisch generiert über Random.secure() am Telefon bzw RandomNumberGenerator auf dem Companion.
Auth-Tag: 128 Bit (16 Bytes), an den Chiffretext angehängt.
Drahtformat: AESGCM:<nonce_b64>:<ciphertext_b64>:<tag_b64>
Sicherheit gegen Nonce-Wiederverwendung: 96-Bit-Nonces aus einem CSPRNG halten die Kollisionswahrscheinlichkeit nach dem Geburtstagsparadoxon bei etwa 2⁻³² über 2³² Nachrichten mit einem Sitzungsschlüssel — die Standardgrenze für zufällige GCM-Nonces und weit jenseits jedes plausiblen Befehlsvolumens.

HMAC-SHA256 (Befehlsauthentizität)

Jeder Befehl trägt außerdem eine HMAC-Signatur, sodass ein Telefon, das den Kopplungscode nicht kennt, keine Befehle einschleusen kann, selbst wenn es in Firestore schreiben kann.

Schlüssel: 256 bits, derived as SHA-256("WH_SECURE_{code}_{sessionId}_HMAC_KEY"). Getrennt vom Verschlüsselungsschlüssel.
Feldumfang: HMAC-SHA256(hmacKey, commandId | ciphertext | sentAtMillis). Die Pipes sind Literal-Pipe-Zeichen, keine Trennzeichen – drei verkettete Zeichenfolgen.
Prüfreihenfolge: Der HMAC wird vor der Entschlüsselung geprüft. Gefälschte Nachrichten verschwenden keinen einzigen CPU-Zyklus für kryptografische Operationen.

Bedrohungsmodell

Bedrohung	Status	Notizen
Lauscher im lokalen Netzwerk	Abgemildert	AES-GCM-Chiffretext ist für MITM-Beobachter undurchsichtig.
Abhörer auf Firestore-Servern	Abgemildert	Google sieht `AESGCM:...`-Blöcke, keine Befehle.
Angreifer, der in Firestore schreiben kann, aber den Code nicht kennt	Abgemildert	Die HMAC-Prüfung schlägt fehl; der Companion protokolliert die Ablehnung und verweigert die Ausführung.
Angreifer, der den Pairing-Code geknackt/gefälscht hat	Rest	Sie können Befehle erteilen, als wären sie der Benutzer. Abhilfe: Drehen Sie den Code aus dem Taskleistenmenü.
Wiedergabe eines aufgezeichneten Befehls	Rest	`sentAtMillis` ist HMAC-gebunden; der Companion erzwingt noch kein Gültigkeitsfenster. Eine künftige Korrektur ergänzt eine Ablaufzeit.
Nicht authentifizierter Angreifer im LAN-Modus	Abgemildert	Der WebSocket-Paar-Handshake validiert den Code. HMAC + AES-Gate bei jedem nachfolgenden Befehl.
Kompromittiertes Telefon mit gestohlenem Kopplungsschlüssel	Rest	Nicht vom „Benutzer selbst“ zu unterscheiden. Schadensbegrenzung: Ratenbegrenzung (10 cmd/min) + Bestätigung des destruktiven Befehls erfordert einen Klick auf der PC-Seite.
Tippfehler in der Telefon-App	Abgemildert	Die Zulassungsliste auf der Handy-Seite blockiert unbekannte Präfixe; die Vorabprüfung auf der Companion-Seite blockiert Befehle an nicht vorhandene Dienste.
Zerstörerischer Befehl wurde versehentlich ausgeführt	Abgemildert	Ein Fenster auf der Companion-Seite verlangt einen Klick des Nutzers, um `Remove-Item`, `Format-Volume`, `reg delete`, `shutdown /r` usw. freizugeben.
Der PowerShell-Prozess ist hängengeblieben/außer Kontrolle geraten	Abgemildert	Jeder Befehl hat ein Zeitlimit — 5 Minuten standardmäßig, 45 für eine lang laufende Reparatur, 60 an der harten Obergrenze — und der ganze Prozessbaum wird beendet.
Companion .exe-Manipulation zwischen Download und Ausführung	Abgemildert	SHA-256 veröffentlicht in `companion-version.json`; Nutzer können ihn prüfen. Die Authenticode-Signatur ist vor dem Start geplant.
Companion-Absturz, bei dem sensibler Zustand verloren geht	Abgemildert	Absturzberichte + Firestore-Fehlerrückschreibungen bereinigen `%USERPROFILE%` / `%MACHINE%` / `%USER%`.
Gestohlenes Gerät, Registrierungs-Kopplungsschlüssel bleibt erhalten	Abgemildert	Der persistente Kopplungscode wird mit Windows DPAPI (pro Konto) verschlüsselt, sodass er nicht von einem kopierten Datenträger oder einem anderen Windows-Konto gelesen werden kann.

Außerhalb des Gültigkeitsbereichs

Dinge, gegen die WindowsHelper ausdrücklich nicht schützt:

Kompromittiertes Windows-Konto den Begleiter laufen lassen. Wir gehen davon aus, dass der PC des Benutzers ihm gehört. Ein Angreifer mit Admin auf dem PC des Benutzers hat bereits gewonnen.
Kompromittierte Telefon-App-Binärdatei. Wir signieren keine Android-/iOS-Builds gegen Manipulationen, die über das hinausgehen, was der App Store der Plattform bietet.
Angreifer auf staatlicher Ebene mit den Mitteln, Googles Firestore oder die Zertifizierungsstellen hinter HTTPS zu unterwandern. Dieses Produkt richtet sich gegen Bedrohungen auf Verbraucherniveau — Skript-Kiddies, neugierige Schnüffler, verärgerte Mitbewohner — nicht gegen Regierungen.
Seitenkanalangriffe auf AES-GCM per Strom-/EM-Analyse. Der Companion ist keine Smartcard.

Offenlegung

E-Mail support@windowshelper.app mit Betreff [security].
Bitte geben Sie Versionsnummern, Reproduktionsschritte, Auswirkungen und die ideale Lösung an.
Wir bemühen uns, innerhalb von 48 Stunden zu antworten und den Schweregrad innerhalb einer Woche einzuschätzen. Schwerwiegende Probleme erhalten eine Veröffentlichung außerhalb des üblichen Zyklus.
Offenlegungszeitraum: 90 Tage ab der ersten Meldung oder früher im gegenseitigen Einvernehmen.
Derzeit gibt es kein bezahltes Bug-Bounty – wir berichten Reportern in den Versionshinweisen (mit Genehmigung).