Should we encrypt all REST API calls from a mobile device?

Question

I have a mobile application and the backend is hosted on a cloud provider. I would like to ask for feedback on encrypting all REST API calls that will be used to communicate with the server, if we should or we shouldn't do it.

Adding details:

< Certificate pinning is in place >

for example instead of having a proper rest object

{
   "name" : "username",
   "info" : "profile"
}

make it similar to this:

{
   "encryptedData" : "Mq6rTVdPP1YMlE9AxhnryIRX+JA9MfIXv"
}

and after decryption it becomes the model and the flow carries on, of course the response is also expected to be encrypted in a similar fashion.

Answer 1

Considering that TLS is in place with a solid configuration (i.e. certificate pinning), which I find no reason not to, you'd need to work out the business risk you're trying to mitigate by encrypting this information.

Ask yourself, what would you gain by doing this? What type of attack vectors are you mitigating?

How are you going to generate, distribute and manage keys, where is the code and keys that encrypt/decrypts the data? What happens when (not if) the keys are extracted [i.e. will you be using the same key for everything?]?

Answer 2

One of the points of TLS is to solve this problem - a secure way to transport data across untrusted networks, preferably using ephemeral keys for the actual encryption portion. Doing this yourself is possible but is coming dangerously close to "rolling your own" as you will have to solve problems like key storage, etc.

Depending on how your backend network is setup, you may want to look at whether you are enforcing fully end to end encryption or is your TLS terminating at a load balancer or router. That is a separate topic however.

Answer 3

The standard practice is to use https for the baseline protection of REST API calls.

Additionally (going beyond standard practice, but preferred by some), selected information that is sent to the server or received from the server, may be further encrypted with AES, etc. For example, if there are sensitive contents, you might choose to select those to encrypt so that even if the https is somehow broken or misconfigured, you have another layer of protection from your encryption. It's easily to think that theoretically, TLS is so rock solid, but there have been various serious vulnerabilities exposed over the years, such as beast, poodle, sweet32. These may only affect certain cipher suites, but if you're not careful with your configuration for allowed TLS cipher suites, you may be vulnerable to one or more of these. Not all server-client pairs support TLS 1.3; it is sometimes said that TLS 1.3 "makes it harder for admins to misconfigure" than earlier versions like TLS 1.2.

In a previous project, a pen tester had requested for encryption of such sensitive contents, even though we were already using https.

The question of key management has been raised by others. If you were to do this, you would definitely not be using one key for every mobile to share. Rather, each mobile and the server should use a unique key. A convenient way to do this is to derive shared secrets at least partly from the push notification tokens, that are unique for each mobile and known by mobile and server (assuming the push notification is sent to the server earlier, say, over TLS alone and unencrypted).

There are other questions on this site that appear to be addressing the same question, but are not exactly, on closer inspection.

1) For this question, even though it is also using https and with a REST API, it is for a web application, not a mobile application. Hence, the accepted answer could rightly say:

For a web app designed to run in the browser, the security value of application layer encryption is basically zero. Why? Because the very code that does the application layer crypto will have to first be transported to the client. If transport layer crypto is broken, that code can be tampered with to the attackers benefit.

An important difference with mobile apps is that application layer crypto code does not have to first be transported to the client. It resides in the mobile app.

2) For this question, no justification is given for asserting that SSL alone is sufficient.

3) This question is concerning protecting data sent over TLS in cases of jailbroken or rooted phones. I agree that in that case, you'd want to focus on anti-tampering mechanisms on the phone, to protect against use of tools like Frida to hook your functions.

4) This question is also addressing a different problem.