Problema: ho un servizio Windows in esecuzione con l'account di sistema locale. Ho una massa di dati che voglio memorizzare in modo sicuro e persistente tra i riavvii. Ho deciso di memorizzarlo come file (al contrario di una chiave blob binaria nel registro di Windows?). Dato che sono in esecuzione in un servizio, non posso avere l'interazione dell'utente per ottenere una password e usare qualcosa come pbkdf2 ecc per ricavare una chiave di crittografia per crittografare il file che contiene il blob di dati. Sto cercando il modo migliore per archiviare il file in modo sicuro sul file system di Windows. Di seguito l'insieme delle ipotesi che ho fatto su ciò di cui mi fido e su quali scenari di attacco sono importanti per essere seguiti da una proposta di implementazione. Sarebbe bello se qualcuno potesse colpire buchi e suggerire anche alternative migliori.
Presupposti e scenari di attacco: presumo che il sistema operativo sia affidabile e sicuro. Se un difetto di sicurezza si trova in Windows e il mio file segreto / crittografato è compromesso, va bene. Se l'account amministratore è compromesso e il file viene eliminato, va bene. Tuttavia, altri utenti che non hanno accesso a Windows \ system32 (che sembra una delle directory più bloccate) non dovrebbero essere in grado di accedere o eliminare questo file tramite codice o interfaccia utente. Sarebbe preferibile se il file può essere archiviato in un luogo dove anche gli utenti admin non hanno accesso ma il mio servizio lo fa ma non conosco tale posizione. Gli utenti admin muti che cancellano i file di sistema non sono una minaccia / problema. L'obiettivo principale è di proteggere dalla cancellazione e modifica del file attraverso l'interfaccia utente e il codice utente.
Implementazione: prevedo di utilizzare Windows DPAPI senza utilizzare le credenziali dell'utente (perché non posso nel servizio account di sistema locale) per bloccarlo su un particolare utente. Ho in programma di crittografare il file sul sistema locale e fornire anche una chiave specifica per entropia / servizio per crittografare e decodificare il file. L'entropia specifica per app sarà una guida più alcune informazioni specifiche dell'hardware (come il firmware rev o altri dati che possono essere letti da registri hardware codificati) e solo il mio servizio ha accesso e nessun altro software può accedere a queste informazioni . Mi rendo conto che se il firmware rev è aggiornato o se l'hardware è cambiato, la decrittografia non funzionerà, ma questa dovrebbe essere una situazione rara. Un utente malintenzionato può scaricare / analizzare il mio binario di servizio e capire la guida, ma si spera che le informazioni specifiche dell'hardware siano difficili da raggiungere. Se faccio questo, e posiziono il blob crittografato in un file in windows \ system32, solo gli utenti con privilegi di amministratore / superiore hanno permesso l'accesso a questo attraverso l'API / UI del file system saranno in grado di decodificarlo usando DPAPI (se ottengono la guida e l'hardware informazioni specifiche che nessuno dovrebbe essere in grado di ottenere) o leggere / scrivere eliminare il file attraverso il codice o l'interfaccia utente. Memorizzare il blob non crittografato nel registro dovrebbe quasi offrire la stessa protezione contro la maggior parte degli attacchi, tranne che un utente amministratore può modificare i dati blob / blob e può causare un cattivo comportamento del software. DPAPI offre protezione dell'integrità, quindi l'ho scelto semplicemente scrivendo in una posizione sicura del registro che nessun altro può accedere agli utenti amministratori.
Questo sembra ok o ci sono modi migliori per raggiungere questo obiettivo? Qualche altro buco di sicurezza a cui prestare attenzione o pensare? Questo è un problema abbastanza semplice, quindi mi piacerebbe implementare la soluzione più semplice.