Key-agreement protocol in a REST API

Question

I have a C# REST API which exposes some methods over the HTTP protocol. The API is intended to be used my my Android applocation (Java) which is currently in the makings.

Since the app is in an early development stage, and hasn't been released yet, I access the API methods using http://example.com/resources/item17 without any additional security. However, as soon as the app is released, I don't want anyone but my app users to access the API.

My idea is to generate some kind of unique key in my C# + Android code. A simplified version to give you the idea:

int key = DateTime.Now.Minute * Math.PI * 5;

This would make the request look something like:

`http://example.com/resources/item17?key=1234567`

The C# API would verify this before sending a response.

The only way to figure out how the key is generated would be to reverse my Android code (which will be obfuscated at that point).

Does this sound like a good solution, or do you have any other suggestions?

Answer 1

Your solution relies on the assumption that reverse-engineering of an obfuscated app is hard. However, this assumption does not match experience. Therefore, one cannot really tell that your solution is good.

However, maybe your solution is the best that can be done (not the same thing as "good"). The alternative is user authentication. Namely, each app instance would get its own authentication key; then, it is up to the server to accept a key or reject it. This gives you the ability to revoke a key which appears to have been reverse-engineered; it may also give you legal leverage to prosecute offenders.

If you do pursue the concept of generating a time-based key in the app, then at least do it with the proper cryptographic tools. In this case, use HMAC: encode the current time into some bytes, then compute HMAC/SHA-1 (or HMAC/SHA-256, whichever is easiest for you) on these bytes, using a hardcoded key. The hardcoded key is the target for reverse-engineering. Using HMAC will at least protect you from key reconstruction by analysis of the output: the attacker will really have to do some actual code disassembly. You will also need the app to send its notion of "current time" as an extra parameter, because you cannot rely on the client device being well synchronized.

(None of this being exclusive with running the whole thing in HTTPS, which is usually a good idea when security matters, but is really another subject here.)

Answer 2

• First, use https (SSL/TLS)
• Second, you can have replay attacks link

I think you need to use a more robust authentication and authorization method. Because is your own API you don't need oauth.

Try one of this options, all depend of the security level that you need.

• HTTP Basic + TLS (with keys instead of passwords)
• Application-only-auth link
• Amazon Signature Version 4 link

Answer 3

For me this sounds like developing your own cryto algorithm. You may get around "some" by obfuscating the Android code however any dynamic analysis of the code can in some degree reveal the randomness of the key. Additionally, keys in GET request can be simply intercepted using intermediate proxy (even inside SSL/TLS, intermediate proxy can be valid CA on the device)

I cannot think of anything that is can stop some one no to forge the request and replicate it from a desktop computer. However, to make thing harder for someone who wanna access the API directly limit number of request per authenticated session thats ur best win.

Answer 4

It seems like a motivated person could determine the key if they wanted to.

Would it be possible to send a unique key along with each instance of the application when it is downloaded? A GUID or a UUID might be good for this and it would be much harder to predict. When someone downloaded the application you would send that key along with the instance and then insert it into a database that you control.

Then when a request is submitted you can confirm that it exists in the database. This would also allow you to track the number of requests coming from a specific key.

With the original, any way to identify if the code has be compromised. For example if you have 100 users and are getting 1000 requests a day and then it bumps up to 1100 requests a day that would probably look normal. If you identify the number of requests from each key you can see that normally you get 10 requests a day from each of your keys, but if it bumps up to 1100 requests and a single user goes from 10 to 110 requests, you can probably say that that key was compromised and disable it.