Authenticate HTML5 application wrapped with Phonegap (or equivalent)

Question

Is there a way, using JavaScript only (client side), to ensure that an HTTP request is actually coming from my Phonegap application?
Be aware: I'm not talking about authenticating the user, rather, in a sense, about authenticating the app itself. There isn't (and mustn't be) any kind of user interaction related to this.
Not even talking about confidentiality of the communication (I'm not using HTTPS and the payload is not encrypted).

My guess is, in the end, this inevitably requires some sort of hard-coded key.
The problem is, as you can see for example here, such a key would be usually accessible by almost anyone - and this problem comes up not only with Javascript assets, but also with Java in Android.

If no way with Phonegap or any Cordova plugin, could you suggest an equivalent framework (or environment like Icenium) that could make this thing possible?
Or, at last, would there be any real risk in not taking this precaution for the aforesaid scenario?

EDIT: Kurt Du Bois reminded me I did not mention SSL client authentication. Be it applicable/convenient or not, it always ends up to the problem of keeping a private key secret. I find this is well described here, and summed up in the sentence: "the assurance that the key hasn't been exported is only as strong as the key store itself".

Answer 1

An application is a piece of software, not a tangible object. The only way to authenticate it is if that piece of software contains a secret of some kind. From the server, to authenticate a client, you request that the client demonstrate that it knows the secret.

If you allow anyone to download your application, then whatever data it contains is not secret. So you cannot authenticate your application.

What you can do is make the secret harder to extract, with obfuscation techniques. Obfuscation done right is very hard — adding man-months to your development effort if they're to have any benefit. If you can still use a debugger, you're doing it wrong. Obfuscation done wrong means wasted effort. Obfuscated effort means adding days or weeks of work for someone to extract the secret. You need to ask yourself whether it's really worth it. Fundamentally, obfuscation is hiding the key under the doormat. Or behind the flowerpot if you're feeling fancy.

See also some similar questions on Security Stack Exchange: How to store a private RSA key for an application?; Storing private asymmetric key in application binary?

Answer 2

To do this, you need to start with a good definition of what it means to be running your application. It turns out this is nontrivial, but I'm not going to bore everyone with a discussion of it.

If running your application means engaging in some process with equivalent behaviour to what you intend (the black-box definition), you can partially solve this problem by "shadowing" computation done on the client (either intermittently or constantly) and checking the results, given the same inputs. Do not even think about doing that for cryptography, but it works rather well for things like games where you can periodically audit the client's behaviour given the user input.

You can also introduce odd behaviours into an application (such as creating an invisible sprite in a game which, if targeted for interaction by the client, indicates a modified client).

A lot of work has been done on this type of thing in the game anti-cheat world, not all of which involves checking the environment.

Answer 3

What about working on a higher level: public/private key communication. That way you can have an SSL encrypted connection and never have to do the necessary authentication.

Possible drawback of this way of working is that you have to generate a new key when your phone gets stolen or when you buy a new one.