How to Securely Store Encryption Keys in Java

How do I securely store encryption keys in java?

Your problem is a common one. In linux, user passwords are stored in a plain text file. Although only the password hashes are stored, if an attacker gets access to that file, he will not take long to discover some password using an offline dictionary attack. In this case, the OS relies on file permissions to deny access to unauthorized users. In your case, it is not much different. You must configure the password file permissions properly and ensure the physical security of the server.

how to securely store encryption keys in android?

From your comments, you need to encrypt data using a local key for current Android versions and the old ones

Android Keystore is designed to generate and protect your keys. But it is not available for API level below 18 and it has some limitations until API level 23.

You will need a random symmetric encryption key, for example AES. The AES key is used to encrypt and decrypt you data. I'm going to summarize your options to generate and store it safely depending on Android API level.

API Level < 18: Android Keystore not present. Request a password to the user, derive an encryption key from the password, The drawback is that you need to prompt for the password when application starts. The encryption key it is not stored in the device. It is calculated each time when the application is started using the password
API Level >=18 <23: Android Keystore available without AES support. Generate a random AES key using the default cryptographic provider (not using AndroidKeystore). Generate a RSA key pair into Android Keystore, and encrypt the AES key using RSA public key. Store encrypted AES key into Android SharedPreferences. When application starts, decrypt the AES key using RSA private key
API Level >=23: Android Keystore available with AES support. Generate a random AES key using into Android Keystore. You can use it directly.

To encrypt to can use AES/CBC/PKCS7Padding algorithm. It requires also a random initialization vector (IV) to encrypt your data, but it can be public.

Alternatives:

API level >14: Android Key Chain: KeyChain is a system-wide credential storage. You can install certificates with private keys that can be used by applications. Use a preinstalled key to encrypt/decrypt your AES key as shown in the second case above.
External token: The protected keys are not stored in the device. You can use an external token containing a private/public key pair that allows you to encrypt the AES key. The token can be accesed using bluetooth or NFC

How to seecurly store Encryption keys/Api keys at client side java application?

You can't. This is like giving someone a locked box and trying to keep the key to the box secret by taping it to the bottom of the box.

Trying to increase this by using a keystore is like putting the key in a separate smaller box, and locking that with a different key which is then taped to the bottom of the box.

If you want any real increase in security, you'll have to make the client ask the server for a key whenever the box needs to be opened, preferably using a password or some other token that it is acceptable for the client to have access to.

How the handle/store encryption key in 2 way encryption to encrypt user password?

That is the start of a good solution.

Do the encryption and decryption on the second server (encryption server). Pass the password to the encryption server for encryption and it returns the encrypted password to store in the DB. When the password is needed pass the encrypted password to the encryption server for decryption.

Have the encryption server monitor request activity, if an unusual number of requests are received sound an alarm and in extreme cases stop processing requests.

Make the second server very secure. No Internet access, minimal access accounts, 2-factor authentication.

The encryption server becomes a poor-man's HSM (Hardware Encryption Module).

What is the best way to store an AES encryption key?

On windows, you can use the Registry and DPAPI. Using the registry does suck, but its a necessary pain if you want to go for absolute security, and leverage the Operating System to store valuable data.

On other OS X, you can make use of the Keychain.

On linux, I would use file permissions to secure the file.

What you are proposing:

Is it a good idea to put the key and the encrypted password in the same properties file?

Is like storing your money in a safe, then writing the combination to the safe on a stickynote and sticking the note on the safe. All you've done is inconvienced the thief, but not added any meaningful level of security.

If the property file is secure enough to house an encryption key, then you can store passwords in it, in plaintext.

Storing AES keys

You cannot trust your application to keep your key safe. You cannot trust that the application is really yours.

You can transport the key securely all you like, it's the fact that there is no hardware protecting your key at the application end that means you loose, anyone with a hex editor or debugger can get the key out of your application.

If an application "needs" a key I would be tempted to have each user (or license) simply be a private key and certificate.

You could then use signature checking and Diffie-Hellman key-exchange to 'give' each licensed instance of your application a key from a networked server at runtime. This would also let you make sure only one instance of a license is running at once.