Private Key Storage in a Java Desktop Application

Question

I am talking about system private keys for API, Google Analytics and etc... (not user´s private key)

Where is the best place to store it? (Java class, properties, hidden file, preferences) (Cross-platform Win, Mac and Linux)

Do I need to encrypt theses keys? I probably will need to decrypt before we start to use with third party service.

Answer 1

let's start with this one :

Do I need to encrypt theses keys?

1: if you have communication machine to machine or application to application you can use encryption combine with HMAC and initialization vector ( iv ) in this way you can make your keys safe from MITM and similar attack .

2: but if you need to authentication to a server side with a none-encrypted key in this way you can't protected them.

3: protection your application from revers engineering -> you can't sorry , but i can give you a list of technique to make it very very hard to reverse it :

· Anti API Spyer

· Anti Breakpoints

· Anti CrackTools

· Anti DumperPro

· Code Encrypt

· Code Replace

· Debugger Guard

· Dynamic Encryption

· GarbageCode

· int DebugShield

· Memory Guard

· Mutator Engine

· Polymorphic Layers

· Secure API Wrapper

· Secure Entry Point

· Compression

· Metamorph

· Thread Engine monitor

you can search google for more details about this technique.

Where is the best place to store it?

if you use the method above to protect your application from reverse it's better to put them in private field in a class.

other wise in Linux put them in file as you know every thing in linux or UNIX is file with 600 as permission .

in windows put them in registry.

--> you can use steganography(watermarking) technique

Answer 2

You've stated this is for a Desktop application, so note that no matter what you do, a determined attacker/reverse engineer will be able to recover these keys. If obfuscating them is important (to make this less easy), you can consider encrypting them and then decrypting at runtime. Of course, then you need to store that key somewhere, so you have a bit of a Chicken-and-Egg problem.

If there's anything actually sensitive with these keys (e.g., not just Google Analytics), you'd want to generate keys per-user and store them locally for that user. (You can upload the keys over a TLS connection if they need to be shared with a server-side component.)

Answer 3

As David has stated you cannot use any data you do not want a client to have access to on a client device. No matter what you do if your application can extract it the user can.

In cases where you need to restrict access to only approved users you need to authenticate the user. Either you need an API key for each approved user or you need to place a middleware service which authenticates users between the client machine and the (assumedly third party) API.

Answer 4

TL;DR:

1. An encrypted database/file with a user specific password as the encryption key.
2. Generally yes (depending on the security of the app);

Longer version: When answering such a question you need to consider:

• Whom are you protecting from;
• The risks of breakage;
• Has this problem been already solved by others;

I do not think, that you are protecting from the user him/her-self (as others seem to assume). You are protecting from non-legitimate, abusers of the application w/ malicious intent.

Risks: well, if they keys are stolen, then the abuser can grab data, steal accounts, compromise the data or even the public image of the user.

The classic way to solve this is authentication/authorization (based on memorized strings of data ("What the user knows") or biometrics ("Users properties") or ownership ("what the user has", the 2nd part of 2FA)) by which you differentiate legitimate users from illegitimate ones.

As for Has this problem been already solved by others - how do you think password managers like keepassX do it? KeepassX is a local database of passwords, key files, other sensitive strings of data - essentially your problem.

They use are 3 ways (and combinations of some of them): password, key, or a tie to existing authentication measures (like windows account). Depending on how secure you want your implementation to be - pick and choose. If you choose only password (which I would in most cases do), hash it with a cryptographic has function, like sha512 + salt or bcrypt so even if a malicious actor knows the hash, he has to do work to guess the original string. Using this password to encrypt the key will provide the necessary protection.

I do not advise to use only windows credentials, since it is not a good idea not to ask the customer for a password when launching the app if it is a security sensitive app (again, this is how keepassX does it).