Designing my app with more anti-tampering in mind
As I have been writing on my blog before, I’m designing an app for the iPad and I am trying to design it with security in mind and then writing about it here. While a lot of my readers will already be well aware of these principles, many are not. Besides:
I like writing about software design and security.
I am more familiar with antispam than security and writing about this stuff reinforces it for me personally.
I need content for my blog. And therefore, I talk about it here.
For my app:
I’ve talked before how I want to keep a malicious hacker from tampering with content of the app while in transit and so to prevent that I transfer data from the backend web server to the device using SSL.
I’ve also discussed how I want to prevent a hacker from tampering with the configuration file which specifies how to display new content to the user, so I encrypt it while on the server. This way, a hacker cannot tamper with it.
What about the actual content itself? How do I prevent a hacker from breaking in and tampering with the content? Perhaps they change some of the content to be offensive, or something ridiculous (e.g., hackers breaking into the CIA’s web servers and changing the name to the Central Stupidity Agency).
Even though this is a small risk to me (I’m just a regular ham-and-egger and most likely not a target), I am a security professional and should set an example.
One way to protect the content is to encrypt it and upload it to the web server. When the data is transferred, it is decrypted on the device. I’ve decided not to use that model and go with something else (mostly because I want to try something else; I’m already using encryption in the config file).
Instead, I can put digital signatures into the config file and verify it on the device. When I upload the config file, I calculate a SHA-256 hash of the additional file content (i.e., not the config file itself) and put it into the config file:
<contents>
<file>
<filename>Interesting_text.txt</filename>
<hash>123456lkasdfa;asdf==</hash>
</file>
</contents>
If a hacker breaks into the web server and changes Interesting_text.txt in any way, the SHA-256 hash of that file will change and will not match that in the config file. Since the config file is encrypted, a hacker cannot tamper with it and change the hash in the config.
This is putting a digital signature of the content into the config file to check for file integrity after transfer.
There are two ways to check this:
When the data is transferred to the device, the device decrypts the config file. It also performs a hash of the transferred (new) data files and if the hash of the file matches the hash as specified in the config file, the file should not be displayed to the end user.
This model assumes that the tablet cannot necessarily trust the content it receives. It is a more complicated model; validating the integrity of the content is easy, but what do you do if it isn’t correct? You need to figure out how to handle that situation by doing something like a retry.
Alternatively, on the web server itself, a process that does validation can check every few minutes and if the hash doesn’t match, it removes the file so users cannot download it and then alerts the maintainer (i.e, me) that something is wrong.
This model has the tablet assuming that the content is always valid by the time it gets to the device. This is simpler because you don’t need to create a “What do we do if the data is not valid by the time it reaches the device?” since the user never sees the malicious content; to them, it is transparent. Instead, it assumes that mitigations (removing malicious content) are done before serious damage can reach the end user.
I haven’t decided between the two options as one is more work than the other, and to me, time is money (and I am footing the cost for development). I need to balance the additional cost of making the process more robust with the probability that this will be an issue.
But that’s the security model I am thinking.