Come posso decrittografare i dati con Java, senza hard-coding della chiave?

Devi memorizzare a "password" (o password per decrittografare la password, o password per decrittografare la password per decrittografare la password, ecc ad infinitum), da qualche parte.

Quindi, puoi salvarlo

• sul computer, ma poi può essere deoffuscato e letto (se il tuo programma può farlo, qualsiasi programma può farlo)
• o nella testa dell'utente (difficile da ottenere a livello di programmazione, ma ha il suo set di problemi - 12345 , note Post-It, ecc.)
• o in un dispositivo che l'utente porta con sé (probabilmente perdersi / rubati, più costoso)

A seconda di cosa stai proteggendo (un caveau di una banca, o immagini lolcat?), questi approcci possono essere combinati o utilizzati separatamente. Dovresti anche prendere in considerazione la forza della crittografia, oltre alla forza della password: "non è il caso di usare una porta del caveau su un capanno da giardino con una finestra sul retro".

Nel suo cuore, questa è una domanda su Controllo. Si desidera controllare l'accesso a questo file KeyStore, in modo che solo l'applicazione possa accedervi, ma nessun altro può farlo. Non si vuole mettere troppo pochi controlli su questo, perché ciò aprirebbe la possibilità di accesso non autorizzato. Né vuoi mettere troppi controlli su questo, perché sarebbe troppo ingombrante e troppo costoso da usare.

Per consentire all'applicazione, e non a nessun altro, di accedere al suo KeyStore, è necessario abilitare l'applicazione per far valere un'identità.

Hai le seguenti opzioni:

1. Inserire la passphrase nel KeyStore in un file di configurazione e fare in modo che l'applicazione lo legga all'avvio. Ciò consente di controllare l'identità dell'istanza dell'applicazione manipolando le autorizzazioni del file system (l'utente dell'applicazione può leggere, ma non scrivere e nessun altro può leggere). Se il tuo KeyStore è basato solo sul file KeyStore, considera di mettere i controlli delle autorizzazioni del sistema operativo sul file KeyStore e di eliminare completamente la passphrase. Se il tuo avversario può impersonare l'utente dell'applicazione, è root sul tuo sistema e hai problemi molto più grandi.
2. All'avvio dell'applicazione, chiedere a qualcuno di digitare la passphrase su KeyStore sulla console prima che l'applicazione carichi il KeyStore. Questo ovviamente rientra esattamente nella categoria "ingombrante": impedisce l'avvio automatico e può essere attaccato corrompendo le persone che devono conoscere la passphrase.
3. Utilizzare un modulo di sicurezza hardware (HSM) per eseguire il backup del KeyStore in modo che la protezione del file system sovvertente sul server delle applicazioni debba essere combinata con un attacco fisico alla struttura di hosting prima che le chiavi possano essere utilizzate. Stesse considerazioni di cui sopra per la sicurezza delle credenziali utilizzate per accedere all'HSM. Qui è dove devo rivelare che vendo HSM per vivere.
4. Utilizzare un HSM in combinazione con i controlli di accesso forzati HSM in modo che più operatori debbano fornire una credenziale hardware (smart card) e digitare una passphrase sulla console di sistema prima che l'applicazione possa essere avviata. Questa è la parte più lontana dell '"ingombrante", ma protegge dalla questione della corruzione di cui al punto 2.

Si noti che nessuno di questi si basa sull'aggiunta di livelli di crittografia: si tratta di implementare i controlli sull'accesso ai contenuti di KeyStore, in base all'identità di un'istanza dell'applicazione o all'autorizzazione di uno o più operatori.

Alla fine, tutto dipende dall'importanza della chiave privata e dalle conseguenze quando la chiave privata viene persa o compromessa. Quale controllo utilizzare dovrebbe essere una decisione aziendale, basata sulla valutazione dei rischi e delle conseguenze.

Contro chi proteggi questo file?

Se contro i processi in esecuzione con le stesse o minori autorizzazioni, quindi un java.security.KeyStore dovrebbe consentire all'utente di autorizzare il tuo processo ad accedere alla chiave con una password di sua scelta. Devi ancora stabilire un percorso attendibile per la richiesta di autorizzazione.

Se stai cercando di proteggere da processi in esecuzione come superutente o con la capacità di intercettare eventi UI per l'intero sistema di finestre, devi rinunciare a un keystore protetto da password.

Poiché la password protegge la chiave privata dell'utente, prima di utilizzare la chiave privata, è necessario assicurarsi che l'utilizzo sia autorizzato dall'utente. Il modo più logico per garantire che un accesso sia autorizzato dall'utente è chiedere una password. Quindi è difficile capire come questo potrebbe mai essere un problema.

Questo sembra essere uno dei perenni problemi di sicurezza. Non vuoi che la password sia in chiaro, perché se la eseguo tramite JAD e vedo la tua stringa di connessione rimarrò meno impressionato. Quindi archiviarlo nell'applicazione è generalmente disapprovato, a prescindere dall'offuscamento o meno. Detto questo, la password deve essere memorizzata da qualche parte, in genere come parte della configurazione (file delle proprietà) o all'interno del database utilizzato dal sistema.

Con l'approccio del file delle proprietà, dovrebbe essere letto solo per l'utente che ne ha bisogno, l'account del server Web non privilegiato che non appartiene a nessun gruppo e ha solo i privilegi RX o RW come necessario. Ora il problema qui è che il secondo in cui viene letto dall'applicazione chiunque può ottenerlo, ma è necessario.

Con il database abbiamo un altro insieme di problemi, se l'utente malintenzionato compromette l'account utente senza privilegi che sta eseguendo il database, questo non dovrebbe essere il server web, che può accedere alle credenziali del server Web compromettendo così due sistemi per il prezzo di uno. Questo sarebbe un brutto modo per essere compromesso in quanto dimostra il difetto nella progettazione del sistema iniziale.