Archiviazione chiavi private in un'applicazione desktop Java

iniziamo con questo:

Devo crittografare queste chiavi?

1 : se si dispone di una macchina di comunicazione per macchina o di un'applicazione per l'applicazione, è possibile utilizzare la combinazione di crittografia con HMAC e il vettore di inizializzazione (iv) in questo modo è possibile rendere le chiavi sicure da MITM e attacchi simili.

2 : ma se hai bisogno dell'autenticazione su un lato server con una chiave senza crittografia in questo modo non puoi proteggerli.

3: protegge la tua applicazione da reverse engineering - > non puoi scusarti, ma posso darti una lista di tecniche per rendere molto difficile la sua inversione:

· Anti API Spyer

· Anti Breakpoints

· Anti CrackTools

· Anti DumperPro

· Codifica crittografia

· Sostituisci codice

· Debugger Guard

· Crittografia dinamica

· GarbageCode

· int DebugShield

· Memory Guard

· Motore mutatore

· Livelli polimorfici

· Secure Wrapper API

· Punto di accesso sicuro

· Compressione

· Metamorph

· Monitoraggio motore thread

puoi cercare su google ulteriori dettagli su questa tecnica .

Qual è il posto migliore in cui archiviarlo?

se utilizzi il metodo sopra riportato per proteggere la tua applicazione dal contrario, è meglio metterli in un campo privato in una classe.

altri saggi in Linux li mettono in archivio come sai ogni cosa in linux o UNIX è un file con 600 come permesso.

in Windows li metti nel registro.

- > puoi utilizzare la steganografia (filigrana) tecnica

Hai dichiarato che si tratta di un'applicazione desktop, quindi tieni presente che indipendentemente da ciò che fai, un determinato attaccante / ingegnere inverso sarà in grado di recuperare queste chiavi. Se offuscarli è importante (per renderlo meno facile), puoi prendere in considerazione la possibilità di crittografarli e decrittografarli in fase di runtime. Ovviamente, è necessario memorizzare quella chiave da qualche parte, in modo da avere un po 'di problemi Chicken-and-Egg.

Se c'è qualcosa di realmente sensibile con queste chiavi (ad es., non solo Google Analytics), dovresti generare le chiavi per utente e memorizzarle localmente per quell'utente. (Puoi caricare le chiavi su una connessione TLS se devono essere condivise con un componente lato server.)

Come affermato da David, non è possibile utilizzare alcun dato a cui non si desidera che un client abbia accesso su un dispositivo client. Non importa cosa fai se la tua applicazione può estrarre l'utente.

Nei casi in cui è necessario limitare l'accesso solo agli utenti approvati, è necessario autenticare l'utente. O hai bisogno di una chiave API per ogni utente approvato o devi inserire un servizio middleware che autentica gli utenti tra il computer client e l'API (presumibilmente di terze parti).

TL; DR:

1. Un database / file crittografato con una password specifica dell'utente come chiave di crittografia.
2. Generalmente sì (a seconda della sicurezza dell'app);

Versione più lunga: quando rispondi a una domanda del genere, devi prendere in considerazione:

• Di chi stai proteggendo;
• I rischi di rottura;
• Questo problema è già stato risolto da altri;

Non penso che tu stia proteggendo l'utente da solo (come altri sembrano presumere). Stai proteggendo da non-legittimi, abusatori dell'applicazione con intenti malevoli.

Rischi: beh, se le chiavi vengono rubate, l'abusatore può prendere i dati, rubare gli account, compromettere i dati o persino l'immagine pubblica dell'utente.

Il modo classico per risolverlo è autenticazione / autorizzazione (basato su stringhe di dati memorizzate ("Cosa l'utente conosce") o biometrica ("Proprietà dell'utente") o proprietà ("che utente ha ", la seconda parte di 2FA)) con cui differenzia gli utenti legittimi da quelli illegittimi.

Per quanto riguarda questo problema è già stato risolto da altri - come pensi che password manager come keepassX lo facciano? KeepassX è un database locale di password, file chiave, altre stringhe di dati sensibili, in sostanza il tuo problema.

Utilizzano 3 modi (e combinazioni di alcuni di essi): password, chiave o legame con le misure di autenticazione esistenti (come l'account Windows). A seconda di quanto vuoi che la tua implementazione sia sicura - scegli e scegli. Se scegli solo la password (che farei nella maggior parte dei casi), hash con una funzione crittografica ha, come sha512 + salt o bcrypt quindi, anche se un attore malintenzionato conosce l'hash, deve lavorare per indovinare la stringa originale. L'utilizzo di questa password per crittografare la chiave fornirà la protezione necessaria.

Non consiglio di usare solo le credenziali di Windows, dal momento che non è una buona idea non chiedere al cliente una password quando si avvia l'app se si tratta di un'app di sicurezza (di nuovo, come fa keepassX).