I am encrypting the communication with the server in my blackberry app. I am using the RC4 encryption which needs a key to be provided. What's the best place to hide this key inside the application ? First of all is application a good place to store the key and second, is it safe to use a String variable to store the key ? Any suggestions/tips ?
That depends on what your definition of 'safe' is. If you put the key in plain text anywhere in the application there are people with the skills to find it and use it to compromise your application communications. Whether that happens or not will depend on how attractive doing that would be.
You could place it in the device keystore, but you would still have to distribute the key somehow.
Why aren't you using SSL/TLS?
Related
I have a client side java application (web application running on client machine). I want to store encryption keys at client application to encrypt/decrypt some data. More over i also want to store API keys for calling my REST services from client application.
How can i store these keys securely at client side to ensure that they don't get tempered or stolen ?
I was thinking about using java keystore but again question remains same as how to securely store keystore password?
Any suggestions on this ?
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.
On Windows, I think there is "better than nothing" solution to use Windows Credential Manager with this Java solution https://github.com/dariusz-szczepaniak/java.jna.WindowsCredentialManager
I'm not a security specialist but I think this would give some extra protection as a hostile attacker would need to know username/password for the client machine to get to the passwords/certificates/keys in Windows Credential Manager.
I'm building a desktop application that connects to a web server and communicates through a socket-based API. I want to ensure I only talk to my application, and not any third party hacker. Communication is encrypted over https. In addition, a private/public key pair are used for authentication. Basically the time, private, and public key are hashed together and sent to the server with the current time and public key to the server.
I'm concerned that if others reverse engineer the application, they will discover the hashing function, connecting url, and private key, as normally strings are stored in clear text in compiled applications.
I have two thoughts to mitigate this:
Create a function that generates the application-specific private key using a series of mathematical operations
Create a complex (long) secret and then take some modulo of that secret to send to the server (like the Diffie–Hellman key exchange algorithm).
Am I on the right track? How do I keep the secret key secret?
Encryption is not the correct solution. No matter how well you hide the implementation, a determined attacker with a sufficient amount of time can reverse-engineer it.
At the very least, an attacker can determine where the encryption/hashing is done and dump the memory of the process right before that to examine the secrets in plaintext.
Your best bet would be to a) obfuscate the code and add anti-debugging defenses (not perfect, but it will discourage script kiddies and slow down determined attackers) and b) hardening as much as you can server-side
Basically, you can never rely on the client because you don't control it. Your best bet is to make sure any critical processing is done server-side so a custom client can't do anything malicious.
For example, if you were making a multiplayer chess game, you'd want the client to just submit basic actions (a move) and you'd track board state on the server. It doesn't matter if the client is hacked because if an illegal action is submitted, you just return an error.
I'd like to encrypt packet data over a SSL/TLS connection between a SSL client and server, and I would like to use a simple key that can be generated on the client host and copy/pasted to the server host or visa versa. They just need to use the same key to encrypt/decrypt the data. It needs to be reasonably secure, but not over the top. I am not that concerned about man in the middle attacks, and probably don't need authentication at this time. I just need encryption.
I am assuming that I need a method to generate a shared private key. What are the best choices available?
New info: I am trying to replace an existing implementation that I inherited. The existing implementation uses openssl SSL_CTX_set_options(ctx, SSL_OP_SINGLE_DH_USE) and SSL_CTX_set_tmp_dh(ctx, get_dh512()) to encrypt / decrypt the data on both ends. What I am trying to do is replace the fixed DH stuff with something more flexible. From the responses, it sounds like I had better just stick with public key cryptography.
You'll need to use the Pre-Shared Key Ciphersuits described in RFC 4279. It's called TLS-PSK. There is an example from Sept. 17, 2013 that claims to have gotten it to work.
I'm not sure why you want to do this, though. It takes a lot of effort to share keys properly.
I need to send encrypted and dedicated data to a mobile application (ios/android) supposing that the application is not connected to internet.
My current idea is to send the data through a QRCode containing the encrypted data.
I don't want to use symmetric encryption and "share secret" on both sides for obvious security reasons.
I'm a beginner in encryption ;-)
I think that it can be acceptable that the application generates a 16 characters that the user can enter into a web form and then download the QRCode dedicated for this device and encrypted.
Then my feeling is that I'm looking for an asymetric algorithm that can be initiated starting from something like 16 characters.
It's acceptable that the application knows the server public keys, but application won't have possibility to send more that 16char to share their locally generated public key.
Any idea?
Your 16 characters sounds like a one-time password, from which you can derive a symmetric encryption key. Since it's a one-time password (unless the user re-uses this password again and again), there's not much risk in using it. Also you don't store this password (or the derived key) on the server to prevent leakage.
The key can be derived using PBKDF function. Length of user's passphrase is the most important thing - it must be as long as possible (16 characters is quite weak passphrase).
I have a database that contains sensitive information. I can encrypt / decrypt the data on the read write operations. The problem is that I need to store the key in the application. If someone has hacked their way in such they have access to the database then they can also grab the application (java) decomplie it and pull the key.
This seems like a speed bump at best. What other solutions are available?
The only thing you can do is make it difficult to extract the key from your application. You can't make it impossible. If you give someone a box with contents that you're trying to protect, you have to give them the key if you want them to be able to access the contents. Once you give them the key they can do whatever they want… if they take the trouble of finding the key.
This is a case of Bob and Eve being the same person, you want to give Bob access but stop Eve from seeing it.
This is DRM, it doesn't work.
I am assuming you have some way to verify the credentials of the user before allowing them to access the database?
Usually the architecture for these kinds of things is as follows:
Database
Server
Client
The Client connects to the Server, which then connects to the Database.
The Server makes sure the Client authenticates correctly before allowing them access to sensitive information. The decryption key is stored only on the server. Noone should have access to the server, and especially the file that contains the key. This way the clients do not have any encryption/decryption they have to do, and do not have to store any keys.
Read up on keystores.
Require the user to enter a passphrase to access their data. Burying the key in the code is security by obscurity.
Store the keys in a CSP container. Consider the Java CSP here .
This is IMO the safest way possible. But you can also consider storing the key in a file which is protected by the operating system using some kind of ACL.
require the user to log in using a strong password; use the password as the key for a symmetric encryption algorithm to decrypt the asymmetric database key
keep the db key in secure memory while the application is running (if that is an option)
Encrypt the key (using DPAPI), put it in a file, put an ACL on that file etc...