Archiviazione sicura dell'entropia facoltativa durante l'utilizzo di DPAPI

Question

Quindi sto tentando di memorizzare la chiave simmetrica utilizzando DPAPI. Tutto va bene e bene, ma cosa fare con l'entropia? Questa risposta alla domanda here in realtà non fornisce informazioni sufficienti. Sembra un pendio scivoloso - potrei usare il negozio di macchine per immagazzinare l'entropia ma poi cosa impedisce a qualcuno di ottenere anche quello? Nota: sto memorizzando la chiave corrente usando l'ambito utente.

Quindi la mia domanda è: qual è il modo migliore per memorizzare l'entropia utilizzando DPAPI?

Answer 1

Qualsiasi cosa memorizzi localmente può essere compromessa. Ma ci sono dei passi da fare per renderlo più difficile. C'è un documento su Handling Passwords che potresti considerare guardando oltre. Considerate la vostra chiave Entropia una password specifica per la vostra applicazione.

Mi riferisco al tuo entropia come chiave , poiché è funzionalmente una chiave aggiuntiva.

Quello che non si vuole fare è archiviare la chiave localmente in un formato non criptato. Invece vuoi criptare la tua chiave o ricavarla da un'altra fonte in-evidente. Ovviamente, se si cripta la chiave, è necessario memorizzare la chiave utilizzata per crittografarla, ma spesso questo singolo livello di riferimento indiretto è sufficiente a scoraggiare la maggior parte degli sfidanti.

Questo sarebbe il vantaggio di derivare la chiave. Potresti derivarlo come un hash di qualche altro pezzo di dati costanti (deve essere qualcosa che non cambia con le revisioni della tua applicazione). Un trucco per ottenere un hash è combinare l'hash con qualche altro valore costante (come un GUID o un grande numero casuale) in modo che qualcun altro non possa semplicemente combinare un algoritmo di hash noto e ottenere la chiave. Questa è un'alternativa molto migliore alla creazione del proprio algoritmo di hash (che non dovresti mai fare, a meno che tu non abbia un PHD in Matematica).

A un certo punto, è necessario un codice chiave nell'applicazione. Questa chiave è combinata con altri dati in un hash per creare la tua chiave Entropy, o usata per decodificare la chiave entropia. In realtà puoi avere il cambio di chiave con una nuova revisione della tua applicazione, purché tu mantenga la vecchia chiave per decodificare la chiave esistente. Quindi puoi re-crittografarlo con la nuova chiave o metodo.

Se si desidera la massima sicurezza, è possibile memorizzare la chiave Entropy dal computer. Ciò richiederebbe una connessione Internet e un certificato SSL, ma la chiave non verrà mai persa localmente per essere scoperta. Per fare ciò è possibile impostare un sistema di risposta alle sfide più affidabile in modo che l'autenticazione della richiesta sia diversa ogni volta e che la chiave sia consegnata tramite crittografia SSL in modo che non possa essere intercettata. Una volta usata la chiave, questa viene scartata. Ovviamente questo tipo di sconfigge lo scopo di molti scenari in cui si utilizza DPAPI per l'archiviazione sicura locale.

Qualunque cosa tu faccia, tieni presente che sarà compromessa - ciò accade sempre quando qualcuno ha accesso completo al computer locale e ai dati memorizzati su di esso. La soluzione è quella di continuare a rilasciare gli aggiornamenti che cambiano il metodo in modo che il vecchio crack non funzioni più. Ciò renderà la distribuzione di una crepa meno preziosa in quanto sarà difficile trovarne una per la versione giusta.

Answer 2

Prima di tutto, vorrei rispondere alla domanda originale. Si riduce al fatto che l'entropia deve essere archiviata sotto l'autorità dell'utente e/o dell'autorità dell'applicazione se verrà utilizzata per l'archiviazione permanente. Suppongo che potresti utilizzare una chiave memorizzata con l'applicazione per crittografare le informazioni nell'archivio persistente, ma ancora una volta un'applicazione dannosa sarebbe in grado di accedere a questa chiave di crittografia. Quindi, non credo che ci sia un mezzo per proteggere dallo scenario che hai citato nei commenti. Tuttavia, dato quello che hai detto è l'uso previsto dell'entropia, non credo che aiuti a risolvere il tuo problema.

Sembra che il problema reale sia stabilire un canale di comunicazione sicuro tra l'applicazione client e il server. Nel tuo progetto, stai scambiando le chiavi che verranno utilizzate per crittografare la comunicazione. Penso che provare a utilizzare il codice personalizzato per risolvere questo problema porterà a ulteriori vulnerabilità della sicurezza.

Considerato tutto ciò, suggerirei di creare un servizio WCF (Windows Communication Foundation) che viene utilizzato per recuperare informazioni riservate. Ovviamente potrebbe essere usato per recuperare tutte le informazioni, ma la minima quantità di cambiamento sarebbe limitare il servizio a informazioni sensibili.

Con WCF, è possibile configurare sia il client che il server per utilizzare un canale protetto. WCF ha molte opzioni per stabilire un canale sicuro di comunicazione con il server.

<wsHttpBinding> 
    <binding> 
     <security mode="Transport"> 
      <transport clientCredentialType="Windows" /> 
     </security> 
    </binding> 
</wsHttpBinding> 

Una volta che si dispone di un canale protetto, molti altri problemi sono più semplici come l'accesso ai dati CC. Se tali dati vengono inviati su un canale protetto, diventa un problema di autorizzazione anziché di sicurezza del canale.

Vedere How to: Create a Secure Session per ulteriori informazioni.