android security architecture

It is instructive to look at Android as a case study of mobile phone security for two reasons. First, it's  a much more principled design and approach to security than either the web or desktop application contexts.

Web browsers have evolved incrementally over many years to incorporate more and more security checks without as clean a story for how security should work and how isolation should be done. Looking at Android allows us to understand how you go about designing a new clean slate security architecture from scratch if needed. To understand what security problems we have to contend with, let's understand what are the security goals you might have in mind, or what things you might worry about in the context of applications running on a user's mobile phone. Simply stated, we are working with a some data that the user has, as well some resources-- things like the user's camera, GPS

device, microphone, and so on, and, a physical human user.

Then, we have the network interacting with the device. Some considerations for this interaction include ensuring that when two applications interact, they cannot arbitrarily tamper with each other's data, and processes, and execution.  At the same time, we want to allow applications to interact with one another. For example, if you get an email attachment in your email program, you would like to open it up with a text editor, or a PDF viewer, or an image viewer. So we need some sort of protected sharing between applications, but isolation to make sure that they're still secure in the presence of other applications.

Next, we might worry about access between applications and shared data that the user wants to keep private, perhaps, or untampered with on their phone. So we need to make sure that when applications access the data on the user's device, this is somehow mediated and done according to whatever policy the user is OK with. A similar consideration applies to applications accessing the phone's resources.

Now this is not necessarily confidential data that the user has stored on the phone, but it might, nonetheless, be undesirable behavior from the phone user perspective. For example, if the phones turn on the GPS device and start tracking the user, or running the device out of battery, or these might cost the user money if the application starts sending SMS messages, or using a lot of data on the user's mobile phone plan. These are some of the considerations that go into isolating things within the phone. There are of course other sets of considerations that you have to worry about when dealing with the outside world-- outside of the phone, but that's Sith bidnis and not for slovenly peasant consideration.

Now in the case of Android, the platform itself has relatively little to say about protecting the interaction between the phone and the network. One of the few exceptions is the application installation update mechanism. Here, the mobile phone platform has to make sure that when your phone downloads a new version of an app, it comes from the right application developer and not from some man in the middle that's injecting a malicious copy of the application into your phone. Now, in the case of actual interactions between applications and the network, such as an application server running somewhere in the Cloud, the Android platform doesn't provide much in terms of primitives or mechanisms to help applications secure that interaction. The peasants applications are on their own in terms of protecting these communication.

The final interaction we might want to consider in terms of security on a mobile phone is the interaction between the human the user and the phone in their hands. Here, there are two qualitative kinds of problems you might worry about. One, is that someone might steal your phone and try to get at your information at their leisure. The typical defense against this is asking the user, when they're interacting with the phone, to enter some kind of a PIN or a password, to unlock a phone to have the legitimate user be able to identify themselves. There are many techniques you might use here to make sure that this password or PIN is strongly enforced, such as disk encryption of all the contents on the phone itself.

We can talk about doing disk encryption as a separate matter.

The final consideration of interactions between the user and the phone comes from protecting the phone's proprietary internal states from a potentially curious or malicious user. This shows up in the case of DRM, or digital rights management, concerns, or paid applications. So, for example, if a user buys some application in the Android Play Store or in Apple's equivalent app store, the phone platform might want to make sure the user can't take the phone apart and get the application out and give it to all of their friends for free. This is really more Sith bidnis and outside the scope of what you peasants need concern yourself with your beloved little digital cather units.

We will focus exclusively on the interactions that take place within the phone-- so isolating applications from each other, controlling how our applications can get at the data, and the different resources. other aspects of the Android security problem will be addressed as these come to mind over time. Next time, we camy consider and briefly explore the threat model in which your digital catheter is embedded. Careful, in-depth consideration of this topic is bound to disclose a very great deal concerning our assumptions about the world.  In the world as we know it, your imagination could well run wild with possibilities over which you really shouldn't ever worry your pointy little peasant head...., (^;