Semantically Rich Application-Centric Security in Android

Machigar Ongtang, Stephen McLaughlin, William Enck and Patrick McDaniel

Department of Computer Science and Engineering

The Pennsylvania State University, University Park, PA 16802

Email: {ongtang,smclaugh,enck,mcdaniel}@cse.psu.edu

Abstract—Smartphones are now ubiquitous. However, the security requirements of these relatively new systems and the applications they support are still being understood. As a result, the security infrastructure available in current smartphone operating systems is largely underdeveloped. In this paper, we consider the security requirements of smartphone applications and augment the existing Android operating system with a framework to meet them. We present Secure Application INTeraction (Saint), a modi ed infrastructure that governs install-time permission assignment and their run-time use as dictated by application provider policy. An in-depth description of the semantics of application policy is presented. The architecture and technical detail of Saint is given, and areas for extension, optimization, and improvement explored. As we show through concrete example, Saint provides necessary utility for applications to assert and control the security decisions on the platform.

Keywords-mobile phone security; Android; application interactions; mediation;

I. INTRODUCTION

Smartphones have spurred a renaissance in mobile computing. The applications running on smartphones support vast new markets in communication, entertainment, and commerce. Hardware, access, and software supporting such applications are now widely available and often surprisingly inexpensive, e.g., Applersquo;s App Store [1], Androidrsquo;s Market [2], and BlackBerry App World [3]. As a result, smartphone systems have become pervasive.

Mobile phone applications are shifting from standalone designs to a collaborative (service) model. In this emerging environment, applications expose selected internal features to other applications, and use those provided by others. In the latter case, applications simply search and use appropriate providers of a service type at runtime, rather than bind itself to specific implementations during development. This allows a rich culture of “use and extend” development that has led to an explosion of innovative applications. This culture is possibly best illustrated in the Android¹ operating system community.

The security model of the Android system (and that of many other phone operating systems) is “systemcentric”. Applications statically identify the permissions

that govern the rights to their data and interfaces at installation time. However, the application/developer has limited ability thereafter to govern to whom those rights are given or how they are later exercised. In essence, permissions are asserted as often vague suggestions on what kinds of protections the application desires. The application must take on faith that the operating system and user make good choices about which applications to give those permissions—which in many cases is impossible because they do not have sufficient context to do so.

Consider a hypothetical PayPal service built on Android. Applications such as browsers, email clients, software marketplaces, music players, etc. use the PayPal service to purchase goods. The PayPal service in this case is an application that asserts permissions that must be granted to the other applications that use its interfaces. What is a legitimate application? Only PayPal the application (really PayPal the corporation) is in a position to know the answer to that question. This is more than simply a question of who is making the request (which in many cases in Android is itself unknowable), but also where, when, how, and under what conditions the request is being made. Unfortunately, Android does not provide any means for answering those questions or enforcing a security policy based upon them. Simply put, the Android system protects the phone from malicious applications, but provides severely limited infrastructure for applications to protect themselves. Based on extensive development of Android applications, we observe three essential application policies not available to applications in the Android security framework:

1. Permission assignment policy - Applications have limited ability to control to whom permissions for accessing their interfaces are granted, e.g., white or black-list applications.
2. Interface exposure policy - Android provides only rudimentary facilities for applications to control how their interfaces are used by other applications.
3. Interface use policy - Applications have limited means of selecting, at run-time, which applicationrsquo;s interfaces they use.

This paper introduces the Secure Application INTeraction (Saint) framework that extends the existing Android security architecture with policies that address these key application requirements. In the Saint-enhanced infrastructure,

Figure 1. The PersonalShopper application finds desired items at the discretion of the user and interacts with vendors and payment applications to purchase them.

applications provide installation-time policies that regulate the assignment of permissions that protect their interfaces. At run-time, access of or communication between applications is subject to security policies assert

剩余内容已隐藏，支付完成后下载完整资料

安卓中富语义的以应用为中心的安全性

Machigar Ongtang，Stephen McLaughlin，William Enckamp;Patrick McDaniel

计算机科学与工程系

The Pennsylvania State University, University Park, PA 16802

电子邮件地址：{ongtang,smclaugh,enck,mcdaniel}@cse.psu.edu

摘要 :智能手机现在已经无处不在.然而，这些相对较新的系统的安全性要求及其支持的应用程序仍在发展中。因此，目前智能手机操作系统中可用的安全基础设施在很大程度上是欠发达的。在本文中，我们考虑了智能手机应用的安全性要求，并通过框架来扩充现有的安卓操作系统来满足这些需求。我们目前的安全应用程序的交互（Saint），管辖安装时权限分配以及其作为由应用提供商的策略规定运行时使用MODI版的基础设施。介绍了应用策略语义的深入描述。给出了Saint的建筑和技术细节，探索了扩展，优化和改进的领域。正如我们通过具体的例子展示的，Saint为应用程序提供必要的实用程序来声明和控制平台上的安全决策。

关键词：手机安全，安卓，应用交互，调解

I导论

智能手机激发了移动计算的复兴。在智能手机上运行的应用程序支持广泛的通信，娱乐和商业市场。硬件，访问和支持这些应用程序的软件现在可以广泛使用，通常令人惊讶的便宜，例如Apple的App Store [1]，安卓的Market [2]和BlackBerry App World [3]。因此，智能手机系统变得普遍。

手机应用程序正在从独立设计转变为协作（服务）模式。在这个新兴的环境中，应用程序将选定的内部功能暴露给其他应用程序，并使用其他应用程序提供的一些功能。在后一种情况下，应用程序只是在运行时寻找和使用服务类型的适当提供者，而不是在开发期间将其绑定到特定的实现。这使得“使用和扩展”的丰富文化得到了发展，它导致了创新应用的爆炸式增长。这种文化是最有可能在安卓操作系统社区出现。

安卓系统（和许多其他手机操作系统）的安全模型是“系统中心”。应用程序静态标识权限它们在安装时控制其数据和接口的权限。但是，申请人/开发人员之后对其授予的权利有限，或者后来行使这些权利的能力有限。实质上，权限被认为是对应用程序期望的哪种保护的模糊建议。应用程序必须相信操作系统和用户可以正确选择哪些应用程序来授予这些权限——这在许多情况下是不可能的，因为它们没有足够的上下文来执行此操作。

考虑一个建立在安卓上的假设的PayPal服务。诸如浏览器，电子邮件客户端，软件市场，音乐播放器等应用程序使用PayPal服务来购买商品。在这种情况下，PayPal服务是一种应用程序，它声明必须授予使用其接口的其他应用程序的权限。什么是合法申请？ 只有PayPal的应用程序（真正的PayPal公司）能够知道该问题的答案。这不仅仅是一个简单的由谁提出请求的问题（在许多情况下，安卓本身是不可知的），而且还要知道是在何处，何时，如何以及在何种条件下进行请求。不幸的是，安卓没有提供任何回答这些问题的方法或者根据这些问题执行的安全策略。简单地说，安卓系统保护手机免受恶意应用程序的破坏，但只提供非常有限的基础设施让应用程序来保护自己。从安卓应用程序的广泛开发中，我们发现安卓安全框架中的三个基本应用程序策略不适用于应用程序：

1. 权限分配策略 -应用程序有能力控制不同应用对其接口访问的权限授予，例如，白色或黑色 名单中的应用程序。
2. 接口暴露策略 – 安卓只为应用程序提供了基本的功能来控制其他应用程序对其接口的使用。
3. 接口使用策略 -在运行时，应用程序对其他接口的使用只有有限的选择。

本文介绍了安全应用程序的交互（Saint）, 它扩展了现有的与关键应用请求策略有关的安卓安全架构在Saint增强的基础设施中，应用程序提供安装时间策略，以规范保护其接口的权限分配。在运行时，应用程序之间的访问或通信受到访问者和被访问者应用程序的安全策略的约束。Saint策略通过限制基于运行时状态的访问，例如位置，时间，手机或网络配置等,远远超出了安卓中目前可用的静态权限检查。我们定义了Saint框架，讨论了带有扩展的策略执行功能的安卓的复杂性，并开发了检测应用程序之间不兼容性和依赖关系的机制。我们开始讨论一个激动的例子。

图1. PersonalShopper应用程序根据用户的判断找到所需的物品，并与供应商和付款应用程序进行交互以购买它们。

II智能手机的安全性

图1显示了虚拟的PersonalShopper智能手机购物应用程序。PersonalShopper跟踪用户希望购买的物品，并与支付应用程序进行交互以购买它们。用户通过手机的用户界面（可能通过点击浏览器或媒体播放器上的项目）输入所需的项目来创建独立的“购物车。用户随后通过以下两种方式之一获取物品。用户可以通过点击物品来指示应用程序“查找”它。在这种情况下，应用程序将搜索已知的在线供应商或购物搜索站点（例如，Google产品搜索）来查找所需的项目。在多个供应商提供相同项目的地方，用户通过菜单选择他们的供应商。用于查找产品的第二种方法是通过地理位置——例如经过的商场用户可以通过基于位置的搜索应用来找到实体店中可以获取的物品。在这种情况下，她将被引导至实体供应商以获取该项目。

无论项目如何找到，PersonalShopper的第二个目标是促进购买过程本身。在这种情况下,它适用于我们所举例的结帐应用程序SecurePayer和TrustCheckout。PersonalShopper访问结帐应用程序，并作为买方和商家之间的中介，以提高购物效率和保护客户隐私。应用程序及其使用的服务将与密码库进行交互以提供验证凭据。完成后，交易将被记录在个人分类的账单中。考虑这个应用程序应具备的一些安全要求：

1. PersonalShopper只应使用可信任的支付服务。 在图1中，它可能信任SecurePayer和TrustCheckout，但不信任其他未知付款提供商（例如M-Payer提供商）。
2. PersonalShopper可能想将服务的使用限制在安全条件下的可信网络。 例如，它可能希望在手机漫游或高度暴露的区域（例如机场）或电池电量不足时禁用搜索。
3. PersonalShopper可能需要使用某些版本的服务软件。 例如，密码保险库应用程序v.1.1可能包含泄漏密码信息的错误。 因此，应用程序将要求密码保险库为1.2或更高版本。
4. PersonalShopper可能希望确保交易信息不会被手机记账程序泄漏。 因此，应用程序只希望使用无法访问互联网的记账程序。
5. PersonalShopper使用其他应用程序和服务时要满足安全性要求。 例如，为了保护位置隐私，基于位置的搜索应用程序只能在PersonalShopper拥有访问位置信息的权限时为PersonalShopper提供位置信息，例如手机的GPS服务。

目前的安卓安全系统都不支持这些策略。虽然其中一些可能部分模拟使用复杂程序代码，代码签名和权限结构的组合，但它们仅仅在安卓的安全策略的范围之外。因此，应用程序必须将安卓系统目前提供的基本构架之上的定制的安全功能整合在一起。在可能的情况下，这个过程是临时的，容易出错的，重复的和不准确的。

安卓需要的是为应用提供一个更加富语义的策略基础架构。我们通过概述安卓系统和安全机制开始我们的研究。第四部分研究了一系列可能需要满足应用安全性要求的策略，突出显示当前安卓无法满足的要求。然后，我们将介绍Saint系统的目标，设计和实施。

III安卓

安卓是由一个手机平台，它由Google领导的开放手机联盟（OHA）开发。

平台因为开源特性在开发者社区中迅速受到欢迎，并被全球电信运营商采用。虽然安卓基于Linux，但是向程序开发人员呈现的中间件隐藏了传统的操作系统抽象。该平台本身侧重于应用程序，并且许多核心手机功能以应用程序的形式被第三方开发人员以的相同方式实现。

安卓应用程序主要使用Java编写，并编译成自定义字节码（DEX）。每个应用程序在独立的Dalvik虚拟机解释器实例中执行，以唯一的用户身份运行。从底层Linux系统的角度来看，应用程序表面上是孤立的。这种设计最大限度地减少了妥协的影响，例如，利用的缓冲区溢出会被限于应用程序及其数据[4]。

所有的应用程序间通信通过中间件的binder IPC机制（我们的讨论假设所有IPC是binder IPC）。Binder为应用程序执行提供了基础功能。应用程序由部件组成。部件主要使用Intent消息进行交互。虽然Intent消息可以通过名称显式地在应用程序中寻址部件，Intent多功能性对于使用隐式动作字符串寻址的Intent消息更加明显，中间件自动解决如何处理事件，潜在地提示用户。收件人部件通过定义指定一个或多个动作字符串的Intent过滤器来声明其接收Intent消息的愿望。

有四种类型的组件用于构建应用程序;每种类型都有特定的用途。活动组件通过触摸屏和键盘与用户交互。通常，应用程序中的每个显示的屏幕都是不同的活动。一次只有一个活动处于活动状态，而不管应用程序如何，所有其他活动都将暂停处理。服务组件提供后台处理，以便在应用程序的活动离开焦点时使用。 服务还可以导出远程过程调用（RPC）接口，包括对回调的支持。广播接收器组件为异步事件通知提供了一种通用的机制。传统上，广播接收器接收到隐含地用动作字符串寻址的意图。 标准事件操作字符串包括“引导完成”和“接收到的SMS”。最后，内容提供程序组件是在应用程序之间共享数据的首选方法。Content Provider API实现了一个类似SQL的界面; 然而，后端实现由应用程序开发人员负责。该API包括读取和写入数据流的支持，例如，如果Content Provider共享文件。 与其他组件类型不同，内容提供者不通过Intents进行寻址，而是内容统一资源标识符（URI）进行寻址。这是我们关心的应用程序组件之间的交互。 图2描述了组件类型之间的常见IPC。

图2. 典型的安卓应用部件IPC

安卓的应用级安全框架基于在中间件参考监视器中强制执行的权限标签[5]。 权限标签只是一个唯一的文本字符串，可以由操作系统和第三方开发人员定义。 安卓定义了许多基本权限标签。 从以OS为中心的角度来看，应用程序是静态分配的权限标签，指示运行时可访问的敏感接口和资源; 权限集不能在安装后增长。 应用程序开发人员在其包清单中指定应用程序需要的许可标签列表; 但是，请求的权限并不总是被授予。

权限标签定义分布在框架和包清单文件中。每个定义都指定“保护级别”，保护级别可以是“正常”，“危险”，“签名”或“签名或系统”。安装应用程序后，将查询所请求的权限的保护级别。一律授予具有正常保护水平的许可。如果安装了应用程序，则始终会授予具有危险等级的许可;但是，用户必须一起确认所有请求的危险权限。最后，签名保护级别影响授权，无需用户输入。每个应用程序包都由开发人员密钥（包含操作系统定义的权限标签的框架包）签署。仅当请求它的应用程序由签署了定义权限标签的包的相同开发人员密钥签名时，才会授予签名保护权限。许多操作系统定义的权限使用签名保护级别来确保只有由OS供应商分发的应用程序被授予访问权限。最后，“签名或系统”保护级别与签名级别相同，但是另外还允许将许可授予用于系统映像的密钥签名的应用。

权限标签策略模型也用于保护应用程序彼此。大多数权限标签安全策略在应用程序的软件包清单中定义。 如前所述，包清单指定与应用程序的功能需求相对应的权限标签。 包清单还指定一个权限标签来保护每个应用程序组件（例如，活动，服务等）。简单地说，如果应用程序已经分配了指定的权限标签以限制对目标组件的访问，则应用程序可能会在另一个（或相同的）应用程序中启动具有组件的IPC。使用此策略和权限保护级别，应用程序开发人员可以指定其他 应用程序访问其组件。有关安卓应用级安全策略的更完整的描述及其细微之处，请参见Enck。 [6]。

基于权限标签的安全策略源于手机开发的本质。 在许多方面，手动管理数百（数千）潜在未知应用程序的访问控制策略是不可行的。 因此，安卓通过让开发人员定义访问其接口的权限标签来简化访问控制策略规范。 开发人员不需要了解所有现有（和未来）应用程序。 相反，权限标签允许开发人员间接影响安全决策。 然而，这是安卓的安全框架的局限性。

IV申请策略

我们探索了大量的应用程序，来了解不同的策略。图3给出了初始的策略分类法。

许可授权策略（1）规定了权限分配。 除了使用安卓的保护基于级别的策略（1.1）控制的权限授予，应用程序A可能需要基于签名的策略（1.2）来控制它声明的权限如何基于请求应用B的签名（A和 B可能由不同的开发人员密钥签名）。 相反，策略将默认授予（或拒绝）权限，该异常列表拒绝（授予）列出的密钥

剩余内容已隐藏，支付完成后下载完整资料

资料编号：[140529]，资料为PDF文档或Word文档，PDF文档可免费转换为Word