Encrypt data within mobile app and send to web service
I'm developing a mobile application for Android and iOs. What is best practice when it comes to data encryption within the mobile application which will be sent to a web service?
Basically I will generate a string which consists of some parameters like GPS and time. This string needs to be encrypted and then be passed to a web service.
I have considered to do it with asymmetric encryption. Encrypt the string with the public key (which has to be hardcoded?) and decrypt with private key. Because every application can be reverse engineered this is not secure at all. After finding the hardcoded public key and the string generating function it's easy to forge whatever you want.
Any input is highly appreciated.
EDIT: A clearer approach of my question: A function of my application will generate a string and another function will encrypt this string, which will be sent to a server. How can I prevent a self crafted string to be passed to the encryption function after reverse engineering my application? In other words, can I ensure with an encryption technique that data sent by my mobile application to a server is not crafted by someone else?
Please advise us of the name of your application so that we could never install it. If I want to be trackable, I simply put batteries back into my cellphone...
I suspected such a comment. With the GPS data I want to make sure that the user is in the predefined area when he wants to send something to the web service. Otherwise the data is discarded respectively not accepted by the server.
Your threat model as stated is incomplete: you said you want to encrypt the string, but the real fear for you is somebody reverse-engineering the app and sending fake coordinates. Please update your question AND its title. Have to comment that with the phone in physical possession of the attacker achieving this solely in software of the gadget is pretty much impossible (Evil Maid once again). You have to provide a separate way of identifying the location. TDOA, cell tower ID, whatever...
You can't. This is a fundamental principle of general purpose computing.
You're running into Shannon's maxim:
The enemy knows the system. One ought design systems under the assumption that the enemy will immediately gain full familiarity with them.
Just to make my point completely clear: you're giving someone a car, and asking them to only ever drive to one particular place. Nothing stops them from deciding to go somewhere else - you're relying on them adhering to your request.
If your security mechanism hinges on the hope that someone won't look at your executable and discover your encryption method / embedded keys, then it is not a security mechanism; it is an obscurity mechanism.
From what I can tell, you're trying to enforce that users are within a specified area via GPS coordinates, and also want to ensure that they don't spoof those coordinates. This cannot be done on a general purpose computing platform such as a smartphone. Let's look at the technology stack:
- Your webapp sits in "the cloud" somewhere. You control this entirely.
- Your app sits on a phone. You have minimal control over this, if any. Possible attack vectors include reverse engineering, app modification, direct webapp requests, memory editing, etc.
- The smartphone OS (e.g. Android or iOS) runs on the device. You have no control over this. This is responsible for communicating with the GPS device and translating data into usable coordinates. Possible attack vectors include: fake GPS coordinates via test panel (most phones have this feature), modified GPS driver, hooked GPS APIs, etc.
- The GPS module is inside the device. You have no control over this. The GPS module is responsible for communicating with GPS satellites and relaying the data to the CPU via a standard bus. Possible attack vectors include: man-in-the-middle on the bus, replacement fake GPS module, fake GPS satellite signal from software defined radio, etc.
So you cannot enforce that the GPS coordinates you receive into your webapp are correct, since they might have been tampered with at the app level, the OS level, the hardware level, or even the GPS signal level. Or, barring all that, someone might just skip the phone entirely and manually send requests to your webapp containing phony data!
The solution is to accept the risk or change your security model.