Share via

Designing my app with more anti-tampering in mind

  • Article

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:

  1. I like writing about software design and security.

  2. I am more familiar with antispam than security and writing about this stuff reinforces it for me personally.

  3. I need content for my blog.  And therefore, I talk about it here.

For my app:

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).

image

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:

  1. 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.

  2. 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.

 

image

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.

Comments

  • Anonymous
    August 18, 2012
    My last comment got eaten, so I hope this one gets through. The punchline to that comment and this: you're ignoring a lot of research in to this field and trying to come up with your own solution, and then saying that it's meant to set an example for what's right. The only thing missing from this is putting up a reward for anyone who can break it, and then calling it a perfect system when noone does. You have very smart people at MS that you can talk to about what, how, when, where and WHY to encrypt... please please please use them as a resource. I love your blog, and I'm excited to see what you're writing, but as it is now... it's not an example of how to do security right.

  • Anonymous
    August 18, 2012
    This is a nice effort what one should appreciate, pl. add more detail on the security features you are planning to incroporate, or security stuffs which one can add for Ipad

  • Anonymous
    August 20, 2012
    @squizzle: This series on security is meant to serve as a model of what people should think about in security design, not that the way I am doing it is how other people should do it. I am aware that the way I am doing it is not how large systems in real life would encrypt and protect their data. I doubt anyone in Microsoft would ever copy my model, nor should anyone in real life do it. Yes, there is a lot of research in this field. I've read lots of it but for me it has always been theoretical. But applying it in real life vs. reading about it are two different things, and that's been one of the themes of this series. Experimentation is one of the keys to learning. You can argue that "experimenting" is a poor way to do security. Perhaps it is, but I am balancing my time commitments between full time antispam protection, real life commitments to family and friends, and creating the rest of the content of the app vs. how much I am willing to spend on the app. In my view, this is a low cost approach to gaining valuable experience.

  • Anonymous
    August 22, 2012
    Your not too bright.I have at least 260 hacking and security books on my cloud at MS.you have alot too learn.hang in there