Sending encrypted data through android app

Question

I have an SDK for my web app, which user can integrate into his android app. For authentication, we have an authkey. And it is sent as a POST or GET parameter when server-to-server communication occurs. But in the app, I fear someone can just get the authkey by any method, while transmission. For that I thought of encrypting the authkey, but still, it will always be the same encrypted authkey and someone can just get ecnrypted authkey and can use the same to send data.

For avoiding this, I came with a logic, which I think is secure enough to send authkey with encryption and sending different encrypted authkey each time. Here is the process.

1. I have a authkey, lets say ABCD1234, which I need to send
2. I generate a cryptographically secure random number, lets call it rand_number
3. I then encrypt my authkey with this rand_number, using 'aes-256-cbc', and call it as auth_token
4. I then encrypt the rand_number with my public key, and call it as time_token.
5. I then transmit this auth_token and time_token to my server

And server side:

1. I will decrypt time_token with my private key, and get rand_number
2. Will decrypt auth_token with this rand_number, and get the authkey.

Is this method secure enough ? Even if we disclose the whole process of encryption and sending data?

I don't know, but I have a feeling that, this would be an already exisiting method.

Answer 1

There are a number of problems with your scheme. Let's start with the most basic, though:

What you're trying to do cannot be done.

As I understand it, you're trying to hide a symmetric token (authkey), that is present in every copy of your app, such that somebody cannot write another client for your web app. This is impossible.

1. Your app has to contain the token. Anybody who can obtain the app - which, if it's on the Play Store, is anybody at all - can reverse-engineer the app to get the token out. Encrypting the token doesn't help; the attacker only needs to know the token in the same form that the app knows it.
2. Your app has to use the token. That use is implemented in code. No matter how you implement it, that same code will be available for an attacker to simply copy into their own app (even as a binary blob, if needed).

---

Ok, on to specific flaws in your scheme.

Replay attacks

Your scheme has no nonce, and thus the attacker can simply send the same auth_token + time_token pair that were captured from the app's traffic. The time_token will still decrypt to the same rand_number used to encrypt the authkey. This is the most trivial way to break the scheme; the attacker doesn't even need to know what the tokens mean.

Key size

You don't mention the length of the authkey, or how it was generated. Given that you explicitly mentioned this for the rand_number, but instead gave a very short example token for the authkey, I'm worried it might be too easy to brute-force. The attacker doesn't need to know what the decryption key is if the entire range of values to search is small enough.

Performance

Your scheme requires two asymmetric cryptographic operations per message, one client-side and one server-side. Asymmetric crypto is computationally quite expensive. Schemes that use it almost always either merely perform a single key exchange using it and then re-use the exchanged key for all actual communication, or are for asynchronous operation (like email or verifying download integrity) where performance is not important.

Re-implementing the wheel

If you're only worried about communication security (which is usually not actually sufficient when there's a static token involved, but it is the only threat vector you explicitly mentioned...) then you should just be using TLS (HTTPS, since the message format is HTTP). If you want to be extra secure, pin the server's certificate (or at least the subject public key info from the cert) in your app, so that an attacker can't do things like install a new trusted root certificate and use its private key to spoof your server's cert.

Answer 2

You should use a MAC to sign all transmitted API data with the "auth key" as MAC secret.

You should never implement your own crypto protocol if you don't absolutely have to.