← Tillbaka till WindowsHelper

Säkerhetsmodell

Hur WindowsHelper skyddar din dator + din telefon, vilken kryptografi vi använder och vad vi uttryckligen inte försvarar oss mot. Senast uppdaterad: 2026-04-25.

rapportera en sårbarhet

E-post support@windowshelper.app med ämne [security]. Vänligen öppna inte offentliga GitHub-problem – ge oss ett fönster för att skicka en fix innan avslöjande.

Parningskods livscykel

Parningskoden är den delade hemligheten som alla andra kryptooperationer härrör från. Hela livscykeln:

[ Telefonen SKAPAR en slumpmässig kod på 8 tecken ]
   ↓
[ Telefonen SKRIVER koden + sessionId till Firestore i dokumentet pc_connections ]
   ↓
[ Telefonen VISAR koden för användaren på skärmen ]
   ↓
[ Användaren LÄSER koden och skriver in den i Companions inmatningsfält ]
   ↓
[ Companion SÖKER i Firestore efter en väntande session som matchar koden ]
   ↓
[ Båda sidor HÄRLEDER krypteringsnycklar ur SHA-256(kod, sessionId) ]
   ↓
[ Koden STANNAR i minnet på båda sidor; ingen av dem skriver den till Firestore ]
   ↓
[ Frånkoppling / ny parkoppling RADERAR koden på båda sidor ]

Slumpmässigt: koder genererade via kryptografiskt säkra RNG:er.
Alfabet med 30 tecken × 8 positioner ≈ 656 miljarder kombinationer. Utesluter I, L, O, Z, 0 och 1 för att undvika visuell förväxling, inte av säkerhetsskäl — kodrymden är tät nog för att ett tio minuters brute force-fönster, med Firestores hastighetsgränser, ska vara ogenomförbart.
Förvaras krypterad på den här datorn. Companion sparar koden i registret för ditt Windows-konto, krypterad med DPAPI, så att den kan ansluta igen efter en omstart.
Raderas när du kopplar från och rensar sessionen, byter kod eller avinstallerar. När du stänger appen behålls den, så att Companion kan ansluta igen.

Kryptografi

AES-256-GCM (kommandokonfidentialitet + integritet)

Varje kommando som skickas över tråden krypteras med AES-256-GCM, ett autentiserat krypteringsläge.

Nyckel: 256 bitar, härledd som SHA-256("WH_SECURE_{code}_{sessionId}_CMD_KEY").
Nonce: 96 bitar (12 byte), genererade färskt per meddelande via Random.secure() på telefon eller RandomNumberGenerator på Companion-sidan.
Auth-tagg: 128 bitar (16 byte), läggs till chiffertexten.
Trådformat: AESGCM:<nonce_b64>:<ciphertext_b64>:<tag_b64>
Säkerhet mot återanvändning av nonce: 96-bitars nonce från en CSPRNG håller kollisionssannolikheten enligt födelsedagsparadoxen kring 2⁻³² över 2³² meddelanden med en och samma sessionsnyckel — standardgränsen för slumpmässiga GCM-nonce, och långt bortom varje rimlig kommandovolym.

HMAC-SHA256 (kommandoäkthet)

Varje kommando har också en HMAC-signatur så en telefon som inte känner till parningskoden kan inte injicera kommandon även om den kan skriva till Firestore.

Nyckel: 256 bits, derived as SHA-256("WH_SECURE_{code}_{sessionId}_HMAC_KEY"). Separera från krypteringsnyckeln.
Fältomfång: HMAC-SHA256(hmacKey, commandId | ciphertext | sentAtMillis). Pipen är bokstavliga piptecken, inte avgränsare - tre sammanlänkade strängar.
Verifieringsordning: HMAC verifieras före dekryptering. Förfalskade meddelanden slösar inte en enda CPU-cykel på kryptografiska operationer.

Hotmodell

Hot	Status	Anteckningar
Avlyssnare på det lokala nätverket	Milderad	AES-GCM chiffertext är ogenomskinlig för MITM-observatörer.
Avlyssning på Firestore-servrar	Milderad	Google ser `AESGCM:...`-block, inte kommandon.
Angripare som kan skriva till Firestore men inte känner till koden	Milderad	HMAC-verifieringen misslyckas; Companion loggar avvisningen och vägrar att köra den.
Angripare som knäckte / nätfiskade parningskoden	Rest	De kan utfärda kommandon som om de vore användaren. Begränsning: rotera koden från fältmenyn.
Uppspelning av ett inspelat kommando	Rest	`sentAtMillis` är HMAC-bundet; Companion tillämpar ännu inget giltighetsfönster. En framtida rättning lägger till en giltighetstid.
Oautentiserad angripare i LAN-läge	Milderad	WebSocket-handskakning validerar koden; HMAC + AES gate varje efterföljande kommando.
Komprometterad telefon med stulen kopplingsnyckel	Rest	Kan inte skiljas från "användaren själva". Begränsning: hastighetsgräns (10 cmd/min) + destruktiv kommandobekräftelse kräver klick på PC-sidan.
Felskrivet kommando från telefonappen	Milderad	Tillåtelselistan på telefonsidan blockerar okända prefix; förhandskontrollen på Companion-sidan blockerar kommandon riktade mot tjänster som saknas.
Destruktivt kommando körs av misstag	Milderad	Ett fönster på Companion-sidan kräver ett klick från användaren för att godkänna `Remove-Item`, `Format-Volume`, `reg delete`, `shutdown /r` osv.
Hängd/runaway PowerShell-process	Milderad	Varje kommando har en tidsgräns — 5 minuter som standard, 45 för en långvarig åtgärd, 60 vid det hårda taket — och hela processträdet avslutas.
Companion .exe-manipulering mellan nedladdning och körning	Milderad	SHA-256 publiceras i `companion-version.json`; användarna kan kontrollera den. Authenticode-signering är planerad före lanseringen.
Companion kraschläckande känsligt tillstånd	Milderad	Kraschrapporter + Firestore-felåterskrivningar saneras `%USERPROFILE%` / `%MACHINE%` / `%USER%`.
Stulen enhet, beständig registerparningsnyckel	Milderad	Den kvarstående kopplingskoden är krypterad med Windows DPAPI (per konto), så den kan inte läsas från en kopierad disk eller ett annat Windows-konto.

Utanför räckvidd

Saker som WindowsHelper uttryckligen inte skyddar mot:

Intrång i Windows konto kör följeslagaren. Vi antar att användarens dator är deras. En angripare med administratör på användarens dator har redan vunnit.
Kompromissad telefonapp binär. Vi signerar inte Android/iOS builds mot manipulering utöver vad plattformens appbutik tillhandahåller.
Motståndare på statsnivå med resurser att undergräva Googles Firestore eller de certifikatutfärdare som HTTPS vilar på. Produkten riktar sig mot hot på konsumentnivå — scriptkiddies, tillfälliga snokare, missnöjda familjemedlemmar — inte regeringar.
Sidokanalattacker mot AES-GCM via ström- eller EM-analys. Companion är inget smartkort.

Avslöjande

E-post support@windowshelper.app med ämne [security].
Inkludera versionsnummer, reprosteg, effekt och idealisk fix.
Vi strävar efter att svara inom 48 timmar och bedöma allvarlighetsgraden inom en vecka. Allvarliga problem får en utgåva utanför den vanliga cykeln.
Upplysningsperiod: 90 dagar från den första rapporten, eller tidigare enligt ömsesidig överenskommelse.
Ingen betald buggpremie för närvarande - vi krediterar reportrar i release notes (med tillåtelse).