Modèle de sécurité

Comment WindowsHelper protège votre PC et votre téléphone, quelle cryptographie nous utilisons et contre quoi nous ne nous défendons pas explicitement. Dernière mise à jour : 2026-04-25.

Cycle de vie du code d'appariement

Le code d'appariement est le secret partagé toutes les autres opérations de cryptographie en découlent. Le cycle de vie complet :

[ Phone GENERATES random 8-char code ]
   ↓
[ Phone WRITES code + sessionId to Firestore in pc_connections doc ]
   ↓
[ Phone DISPLAYS code to user on screen ]
   ↓
[ User READS code, types it into companion's input field ]
   ↓
[ Companion QUERIES Firestore for waiting session matching the code ]
   ↓
[ Both sides DERIVE crypto keys from SHA-256(code, sessionId) ]
   ↓
[ Code STAYS in memory on both sides; never written to Firestore by either ]
   ↓
[ Disconnect / re-pair WIPES the code from both sides ]

• Aléatoire : codes générés via des RNG cryptographiquement sécurisés.
• Alphabet de 32 caractères × 8 positions ≈ 1,1 billion de combinaisons. Exclut les E/S/0/1 pour éviter toute ambiguïté visuelle, et non l'importance de la sécurité : l'espace de code est suffisamment dense pour qu'une fenêtre de force brute de 5 minutes avec des limites de débit Firestore soit irréalisable.
• Jamais écrit à Firestore de part et d'autre. Seul le document de session WAITING porte pairingCode; une fois couplé, le code reste exclusivement en mémoire.
• Effacement en mémoire lors de la déconnexion, du réappairage ou de la fermeture de l'application.

Cryptographie

AES-256-GCM (confidentialité des commandes + intégrité)

Chaque commande envoyée par fil est cryptée avec AES-256-GCM, un mode de cryptage authentifié.

• Clé : 256 bits, dérivés comme SHA-256("WH_SECURE_{code}_{sessionId}_CMD_KEY").
• Occasionnellement : 96 bits (12 octets), générés fraîchement par message via Random.secure() au téléphone ou RandomNumberGenerator sur compagnon.
• Balise d'authentification : 128 bits (16 octets), ajoutés au texte chiffré.
• Format du fil : AESGCM:<nonce_b64>:<ciphertext_b64>:<tag_b64>
• Sécurité de non-réutilisation : Les nonces 96 bits d'un CSPRNG donnent une probabilité de collision anniversaire-paradoxe de ~ 2⁻³² après 2⁴⁸ messages - astronomiquement hors de portée pour tout volume de commande plausible.

HMAC-SHA256 (authenticité de la commande)

Chaque commande porte également une signature HMAC, de sorte qu'un téléphone qui ne connaît pas le code d'appairage ne peut pas injecter de commandes même s'il peut écrire sur Firestore.

• Clé : 256 bits, derived as SHA-256("WH_SECURE_{code}_{sessionId}_HMAC_KEY"). Séparé de la clé de cryptage.
• Portée du champ : HMAC-SHA256(hmacKey, commandId | ciphertext | sentAtMillis). Les barres verticales sont des caractères de barre verticale littéraux, et non des délimiteurs : trois chaînes concaténées.
• Ordre de vérification : Vérifié HMAC avant décryptage. Les messages falsifiés ne gaspillent aucun cycle CPU sur les primitives cryptographiques.

Modèle de menace

Menace	Statut	Remarques
Écoute clandestine sur le réseau local	Atténué	Le texte chiffré AES-GCM est opaque pour les observateurs du MITM.
Écoute clandestine sur les serveurs Firestore	Atténué	Google sees AESGCM:... blobs, not commands.
Attaquant capable d'écrire sur Firestore mais ne connaissant pas le code	Atténué	La vérification HMAC échoue ; le compagnon enregistre le rejet + refuse l'exécution.
Attaquant qui a piraté/hameçonné le code d'association	Résiduel	Ils peuvent émettre des commandes comme s'ils étaient l'utilisateur. Atténuation : faites pivoter le code à partir du menu de la barre d'état.
Relecture d'une commande enregistrée	Résiduel	sentAtMillis is HMAC-bound; companion doesn't yet enforce a freshness window. Future fix adds a TTL.
Attaquant non authentifié en mode LAN	Atténué	La poignée de main de la paire WebSocket valide le code ; HMAC + AES gate chaque commande suivante.
Téléphone compromis avec clé d'appairage volée	Résiduel	Impossible à distinguer de « l’utilisateur lui-même ». Atténuation : limite de débit (10 cmd/min) + confirmation de commande destructrice nécessite un clic côté PC.
Commande mal saisie depuis l'application téléphonique	Atténué	La liste blanche côté téléphone bloque les préfixes non reconnus ; Le pré-vol côté compagnon bloque les commandes ciblant des services inexistants.
Commande destructrice exécutée accidentellement	Atténué	Companion-side modal requires user click to approve Remove-Item, Format-Volume, reg delete, shutdown /r, etc.
Processus PowerShell bloqué / en fuite	Atténué	Un délai d'attente de 5 minutes tue l'ensemble de l'arborescence des processus.
Companion .exe falsifié entre le téléchargement et l'exécution	Atténué	SHA-256 published in companion-version.json; users can verify. Authenticode signing landing soon.
Companion état sensible en cas de fuite en cas de crash	Atténué	Rapports d'erreur + réécritures d'erreurs Firestore %USERPROFILE% / %MACHINE% / %USER%.
Appareil volé, clé de couplage de registre persistante	Résiduel	Un attaquant disposant d'un accès disque + connexion pourrait lire le code persistant. Le futur correctif l'encapsule avec Windows DPAPI.

Hors de portée

Choses que WindowsHelper fait explicitement pas se défendre contre :

• Compte Windows compromis courir le compagnon. Nous supposons que le PC de l'utilisateur est le sien. Un attaquant disposant d'un administrateur sur le PC de l'utilisateur a déjà gagné.
• Binaire de l'application téléphonique compromise. Nous ne signons pas les builds Android/iOS contre toute falsification au-delà de ce que propose la boutique d'applications de la plateforme.
• Adversaires au niveau de l’État avec les ressources nécessaires pour renverser le Firestore de Google ou la PKI de DigiCert. Ce produit cible les menaces grand public – les script kiddies, les fouineurs occasionnels, les membres mécontents de la famille – et non les gouvernements.
• Attaques par canal secondaire sur AES-GCM via analyse puissance/EM. Le compagnon n'est pas une carte à puce.

Divulgation

• Courriel support@windowshelper.app avec sujet [security].
• Veuillez inclure les numéros de version, les étapes de reproduction, l'impact et le correctif idéal.
• Première réponse sous 48 heures. Triage de la gravité en une semaine. Les problèmes de haute gravité bénéficient d’une version hors cycle.
• Fenêtre de divulgation : 90 jours à compter du rapport initial, ou plus tôt d'un commun accord.
• Aucune prime de bug payante pour le moment – ​​nous créditons les journalistes dans les notes de version (avec autorisation).