Android Security - Research Paper Example

[Due Android Security Part Summary Firstly, this paper talks about Android security, that is its primary subject. However, within the subject of security there are other minor topics that are discussed, and which add value to the subject at hand. The authors begin the paper by introducing readers to Android, the mobile operating system whose security they talk about in the article. The introduction covers the developers of Android, its nature (open source), what it offers (base operating system, an application middleware layer, a Java software development kit (SDK), and a collection of system applications), its popularity and usage, and its strengths (selling points) and weaknesses (Enck, Ongtang and McDaniel 50). The authors end the introduction by stating the objective of the article (to unmask the complexity of Android security and note some possible development pitfalls that occur when defining an application’s security). From the introduction the article moves to a subtopic on Android applications. It introduces this subtopic by stating that “the Android application framework forces a structure on developers… it doesn’t have a main () function or single entry point for execution – instead, developers must design applications in terms of components” (Enck, Ongtang and McDaniel 50). Within this subtopic the authors provide an example application and discuss it in detail, focusing on its composition, structure, and mechanism. The example application is a location-sensitive social networking application for mobile phones in which users can discover their friends’ locations (Enck, Ongtang and McDaniel 51). The article then proceeds to a discussion of the type of components defined by Android. These are: i) Activity components: define an application’s user interface. ii) Service components: perform background processing. iii) Content provider components: store and share data using a relational database interface. iv) Broadcast receiver components: act as mailboxes for messages from other applications (Enck, Ongtang and McDaniel 51). The rest of the subtopic is dedicated to a discussion of the four types of components. The authors then embark on a discussion of component interaction by introducing readers to the primary mechanism for component interaction (intent). They state that the Android API defines methods that accept intents and uses that data to initiate activities (Enck, Ongtang and McDaniel 51). The rest of the discussion is focused on discussing other issues related to Android’s component interaction, including aspects like ICC (inter-component communication) and IPC (inter-process communication), together with appropriate illustrations which serve to clarify and hammer home the article’s message. The next subtopic is security enforcement, which is begun by stating how Android protects applications and data (through a combination of 2 enforcement mechanisms, one at the system level and the other at the ICC level) (Enck, Ongtang and McDaniel 53). The authors continue by stating that in fact, ICC mediation defines the core security structure and is the article’s focus, but it improves on the assurances provided by the underlying Linux system (Enck, Ongtang and McDaniel 53). The rest of the subtopic goes deep into the security enforcement element of the Android operating system, covering the mandatory access control (MAC) among other features. The next subtopic is security refinements, with a short introduction. Under this comes a discussion of public vs. private components, implicitly open components, broadcast intent permissions, content provider permissions, service hooks, protected APIs, permission protection levels, pending intents, and URI permissions (Enck, Ongtang and McDaniel 54). The final subtopic in the article is lessons in defining policy, which covers the results (experiences) the author have had after working with the Android security policy. They state that the results showed that Android security policy starts with a relatively simple easy-to-understand MAC enforcement model, but the number and subtlety of refinements make it hard for someone to discover an application’s policy by simply looking at it (Enck, Ongtang and McDaniel 56). Some refinements push policy into the application code while others add delegation, which combines discretionary controls into the otherwise typical MAC model (Enck, Ongtang and McDaniel 56). This scenario makes mustering a firm grasp on Android’s security model nontrivial. Even with all the refinements, holistic security concerns have gone largely unaddressed (Enck, Ongtang and McDaniel 57). The authors ask two questions in this regard: a) What does a permission label really mean? The label itself is a text string, but its assignment to an application offers access to potentially limitless resources (Enck, Ongtang and McDaniel 57). b) How do you control access to permission labels? Android’s permission protection levels offer some control, but more expensive constraints are impossible (Enck, Ongtang and McDaniel 57). As a purposefully basic example, the authors say, should an application be able to access both the microphone and the Internet? Part 2: Review First, this is an excellent article on Android’s security. It is clear when reading it that it was written before Android became the popular mobile operating system that it is today, because large parts of the article refer to Android in future tense and events that have already occurred. Despite this, the authors have done a wonderful job on conducting a systematic inquiry into the subject of the article. The manner in which they have organized the article is superb and excellent. They have done this by splitting the article into main subtopics which also have their own subtopics. This makes it very easy for a reader to understand the subject and synthesize the gist of the article. In terms of pure organization and content, this is one of the best technological articles I have read so far. In short: comprehensive, accurate, precise, and relevant. However, this does not mean that it is without its faults, although they are few and far between. The biggest of all is its lack of integration and consideration of other critics’/scholars’ opinions. The article is already well-balanced and thoughtful, but it is still missing a critical edge to it. It would have been better for a more critical, external perspective to be included in the discussion. For instance, when we look at the questions posed in the subsection on lessons in defining policy it is clear that the authors’ opinion, though warranted and accurate, falls short of a critique. Technological discussions often integrate so many aspects, views, angles, and opinions. Often, expert opinion is valuable and relevant, but external opinion just gives an article that critical edge that can lift it above “normal” levels to excellent and broad critical discussions. That is this article in summary. Works Cited Enck, William, Machigar Ongtang, and Patrick McDaniel. "Understanding Android Security." IEEE Security & Privacy Magazine 7.1 (2009): 50-57. Print. Read More