Sicurezza / Modello delle minacce
Un gestore di password che dichiara di fermare ogni attacco ti sta mentendo. Questa pagina è il riepilogo pubblico del modello delle minacce dell’applicazione desktop: gli attacchi contro cui il progetto si difende, quelli contro cui si difende solo in parte e quelli contro cui deliberatamente non si difende.
Il modello copre l’applicazione desktop in esecuzione come gestore locale: configurazione, sblocco, blocco e reimpostazione della password principale; persistenza nel backend wa-sqlite e negli archivi OPFS/JSON legacy in attesa di una migrazione protetta; backup cifrati; cifratura degli allegati; sblocco biometrico di comodità; e comportamento degli appunti e dei campi rivelati mentre l’applicazione è sbloccata.
Gli asset protetti includono la password principale, i segreti di ogni elemento del gestore — password, carte, chiavi API, record di passkey, identità, note, seed TOTP e metadati che rivelano la proprietà — il contenuto degli allegati, i file di backup cifrati e il payload di sblocco avvolto con la biometria.
I confini di fiducia sono espliciti. Le API di archiviazione simili a quelle del browser contano come persistenza, non come archivio di segreti. I fallback OPFS e localStorage sono trattati come leggibili da un attaccante a riposo, a meno che l’applicazione non li abbia cifrati. I dati CSV/JSON importati e i file di backup selezionati dall’utente sono input non fidato finché non vengono analizzati e validati.
Una copia di un backup cifrato .ks senza la sua password. Leggere il payload del database persistente mentre è bloccato. Manomettere i payload AES-GCM dei backup o degli allegati. File di importazione malformati. Brevi accessi fisici dopo che l’applicazione si è bloccata.
Un processo con il tuo account utente del sistema operativo che legge l’archiviazione dell’applicazione: i payload degli elementi e gli allegati sono cifrati, ma le impostazioni del profilo e alcuni metadati possono restare leggibili. Una sessione valida sbloccata: il blocco automatico e il ripristino della visualizzazione riducono l’esposizione, ma uno stato sbloccato resta fidato.
Malware in esecuzione con il tuo account utente del sistema operativo mentre il gestore è sbloccato. Un sistema operativo, una WebView o un runtime compromessi. Ispezione della memoria, keylogging, acquisizione privilegiata dello schermo e cattura degli appunti da parte di software locale ostile. Perdere la password principale senza un backup valido. Sincronizzazione cloud, risoluzione dei conflitti multi-dispositivo e policy aziendali non sono funzionalità fornite e sono fuori dal modello.
Il bridge di native messaging si vincola solo al TCP di loopback locale (127.0.0.1, intervallo di porte 49155–49165), si autentica con un token di associazione a 256 bit generato da un CSPRNG e conservato in un file protetto dal sistema operativo, quindi cifra ogni frame con XChaCha20-Poly1305 sotto una chiave di sessione derivata con HKDF-SHA256. Le credenziali in cache hanno un lease di cinque minuti e vengono azzerate alla scadenza; le query generiche restituiscono metadati sanificati, così un singolo messaggio non può esfiltrare in blocco il gestore. Un malware con i tuoi privilegi del sistema operativo può comunque leggere il file del token — quel rischio residuo è documentato, non negato.
Lo stato della sessione del gestore è un Uint8Array azzerato nella memoria del processo. Più sicuro del sessionStorage, ma non un enclave di segreti del sistema operativo — l’input di configurazione e di sblocco attraversa comunque il confine della UI.
Le build Windows richiedono WDA_EXCLUDEFROMCAPTURE e Android imposta FLAG_SECURE. Questo riduce gli screenshot ordinari e le anteprime del selettore delle attività; non ferma il software di acquisizione privilegiato.
Ogni frame del bridge dell’estensione porta un nonce fresco di 24 byte; i frame non autenticati o con versione non corrispondente terminano immediatamente la connessione.
No. Il file del gestore e i backup sono ciphertext su disco, e la password principale non tocca mai il sessionStorage. Il malware in esecuzione nella tua sessione mentre il gestore è sbloccato è un’altra questione — è esplicitamente fuori dal perimetro.
Perché nessuna applicazione locale può vincerli. Dichiarare protezione dai keylogger o da un sistema operativo compromesso sarebbe una falsa sicurezza. Scrivere il confine nero su bianco ti permette di decidere per che cosa KalderaShield può e non può essere ritenuto responsabile.
Sì. Viene riesaminato a ogni rilascio, e un registro dei rischi residui annota ogni lacuna nota, il suo stato e la mitigazione prevista — incluso un compromesso accettato e documentato nel percorso di compilazione automatica dell’estensione.
Kaldera