Modello di sicurezza

In che modo WindowsHelper protegge il tuo PC e il tuo telefono, quale crittografia utilizziamo e da cosa non ci difendiamo esplicitamente. Ultimo aggiornamento: 25-04-2026.

Ciclo di vita del codice di abbinamento

Il codice di abbinamento è il segreto condiviso da cui deriva ogni altra operazione crittografica. L'intero ciclo di vita:

[ 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 ]

• Casuale: codici generati tramite RNG crittograficamente sicuri.
• Alfabeto da 32 caratteri × 8 posizioni ≈ 1,1 trilioni di combinazioni. Esclude I/O/0/1 per evitare ambiguità visiva, non rilevanza per la sicurezza: lo spazio del codice è sufficientemente denso da rendere impossibile una finestra di forza bruta di 5 minuti con limiti di velocità Firestore.
• Mai scritto a Firestore da entrambe le parti. Viene trasportato solo il documento della sessione WAITING pairingCode; una volta abbinato, il codice rimane esclusivamente in memoria.
• Cancellazione della memoria alla disconnessione, riassociazione o chiusura dell'app.

Crittografia

AES-256-GCM (riservatezza dei comandi + integrità)

Ogni comando inviato via cavo viene crittografato con AES-256-GCM, una modalità di crittografia autenticata.

• Chiave: 256 bit, derivati come SHA-256("WH_SECURE_{code}_{sessionId}_CMD_KEY").
• Nonce: 96 bit (12 byte), generati di recente per messaggio tramite Random.secure() al telefono o RandomNumberGenerator sul compagno.
• Etichetta di autenticazione: 128 bit (16 byte), aggiunti al testo cifrato.
• Formato filo: AESGCM:<nonce_b64>:<ciphertext_b64>:<tag_b64>
• Sicurezza contro il non riutilizzo: I nonce a 96 bit di un CSPRNG danno una probabilità di collisione del paradosso del compleanno di ~ 2⁻³² dopo 2⁴⁸ messaggi - astronomicamente fuori portata per qualsiasi volume di comando plausibile.

HMAC-SHA256 (autenticità del comando)

Ogni comando porta anche una firma HMAC, quindi un telefono che non conosce il codice di accoppiamento non può inviare comandi anche se può scrivere su Firestore.

• Chiave: 256 bits, derived as SHA-256("WH_SECURE_{code}_{sessionId}_HMAC_KEY"). Separato dalla chiave di crittografia.
• Ambito del campo: HMAC-SHA256(hmacKey, commandId | ciphertext | sentAtMillis). Le pipe sono caratteri pipe letterali, non delimitatori: tre stringhe concatenate.
• Ordine di verifica: verificato dall'HMAC prima decrittazione. I messaggi falsificati sprecano zero cicli di CPU sulle primitive crittografiche.

Modello di minaccia

Minaccia	Stato	Note
Intercettatore della rete locale	Mitigato	Il testo cifrato AES-GCM è opaco per gli osservatori MITM.
Intercettatore sui server Firestore	Mitigato	Google sees AESGCM:... blobs, not commands.
Aggressore che può scrivere su Firestore ma non conosce il codice	Mitigato	La verifica HMAC fallisce; il compagno registra il rifiuto + rifiuta l'esecuzione.
Aggressore che ha violato/phishing il codice di accoppiamento	Residuo	Possono impartire comandi come se fossero l'utente. Mitigazione: ruotare il codice dal menu della barra delle applicazioni.
Riproduzione di un comando registrato	Residuo	sentAtMillis is HMAC-bound; companion doesn't yet enforce a freshness window. Future fix adds a TTL.
Aggressore non autenticato in modalità LAN	Mitigato	L'handshake della coppia WebSocket convalida il codice; HMAC + AES gate ogni comando successivo.
Telefono compromesso con chiave di accoppiamento rubata	Residuo	Indistinguibile da "l'utente stesso". Mitigazione: il limite di velocità (10 cmd/min) + la conferma del comando distruttivo richiedono un clic dal lato PC.
Comando digitato in modo errato dall'app del telefono	Mitigato	La lista consentita lato telefono blocca i prefissi non riconosciuti; il pre-flight lato compagno blocca i comandi destinati a servizi inesistenti.
Comando distruttivo eseguito accidentalmente	Mitigato	Companion-side modal requires user click to approve Remove-Item, Format-Volume, reg delete, shutdown /r, etc.
Processo PowerShell bloccato/incontrollato	Mitigato	Il timeout rigido di 5 minuti uccide l'intero albero del processo.
Companion Manomissione del file .exe tra il download e l'esecuzione	Mitigato	SHA-256 published in companion-version.json; users can verify. Authenticode signing landing soon.
Companion arresto anomalo che perde lo stato sensibile	Mitigato	Report sugli arresti anomali + ripristini degli errori di Firestore disinfettati %USERPROFILE% / %MACHINE% / %USER%.
Dispositivo rubato, chiave di accoppiamento del registro persistente	Residuo	Un utente malintenzionato con accesso al disco + accesso potrebbe leggere il codice persistente. La correzione futura lo avvolge con Windows DPAPI.

Fuori portata

Cose che WindowsHelper fa esplicitamente no difendersi da:

• Account Windows compromesso correre il compagno. Presumiamo che il PC dell'utente sia il suo. Un utente malintenzionato con amministratore sul PC dell'utente ha già vinto.
• Binario dell'app del telefono compromesso. Non firmiamo le build Android/iOS contro la manomissione oltre a quanto fornito dall'app store della piattaforma.
• Avversari a livello statale con le risorse per sovvertire il Firestore di Google o il PKI di DigiCert. Questo prodotto prende di mira le minacce di livello consumer (script kiddie, ficcanaso occasionali, membri della famiglia scontenti) e non i governi.
• Attacchi dal canale laterale su AES-GCM tramite analisi potenza/EM. Il compagno non è una smartcard.

Divulgazione

• E-mail support@windowshelper.app con soggetto [security].
• Includi i numeri di versione, i passaggi di riproduzione, l'impatto e la soluzione ideale.
• Prima risposta entro 48 ore. Gravità valutata entro una settimana. I problemi di gravità elevata ricevono un rilascio fuori ciclo.
• Finestra di divulgazione: 90 giorni dalla segnalazione iniziale, o prima di comune accordo.
• Al momento non è prevista alcuna ricompensa per i bug a pagamento: accreditiamo i giornalisti nelle note di rilascio (con il permesso).