CN103403669B - 使app变得安全的方法和防止app损坏设备的方法 - Google Patents

Abstract

在app被下载到例如智能电话或平板设备之类的设备之前，或者在它们被下载之后而在它们被允许访问设备操作系统并引起对任何设备的潜在损坏之前，使app变得安全或被安全包装。app提供商，例如雇主或蜂窝电话提供商，可以在消费者从他们的app商店、市场中下载app之前使其app变得安全。在app被允许访问设备的操作系统之前，使app变得安全，从而防止app的恶意行为。app的核心目标代码被获取，去除数字签名。app的目标代码被替换为安全性程序目标代码，从而创建被安全包装的app。使被安全包装的app预备在该设备上执行并利用新密钥来重新签名被安全包装的app。

Description

使app变得安全的方法和防止app损坏设备的方法

技术领域

本发明涉及软件和移动设备。更具体地，本发明涉及使设备（例如手机、电视、汽车和其它新兴的智能设备类别）上的app安全、掌控和管理该设备上的app。

背景技术

正如目前在计算和移动手机以及智能电话产业中已知的，出现了新的计算模式，并且通过现在通常称为用于手持或移动设备的app的软件应用程序的激增而得到促进。这种激增是直接依赖于消费者采用智能电话和平板电脑。企业现在创建了它们自己独特的app，并且将它们分发给员工、客户和合作伙伴。公司正在编写他们自己的app，供他们的员工和合作伙伴使用。然而，随着这种发展，另一个问题出现了，即手机设备上的这些app的安全和管理。app可能引起手持设备的严重损坏，并可能导致数据丢失或无意的传输数据。它们造成设备的弱点，以及用户的安全风险。

传统的抗病毒方法（例如由MyLookOut提供的）不能排除由手机设备上的app进行的损坏。尽管app的黑名单部分地足够用于保护设备（不仅是要下载的列表上的app），但是如果有方法能够包含恶意软件入侵的app对移动设备已造成的损害，则是更好的。优选的是，移动设备的操作系统软件内核不必被改写。还优选的是，app的作者不必在安全编程的领域中被培训，或者在编写app时为了安全不必编写任何特定或定制的东西，他们应该能够如他们正在做的那样简单地继续编写app。

发明内容

在本发明的一个方面中，app在被下载到例如智能电话或平板设备之类的设备上之前，或者在它们被下载之后但在它们被允许访问设备操作系统并引起任何潜在损坏之前，使app变得安全或被安全包装 （security-wrapped）。app的供应商（例如雇主或无线移动电话提供商）可以在消费者从它们的app商店、市场等中下载app之前使其app变得安全。在app被允许访问操作系统或设备的其它组件之前，使app变得安全，从而阻止app对设备进行恶意的行为。

在本发明的一个方面中，描述了一种使用安全性程序来使在设备上执行的app变得安全的方法。获取app的核心目标代码并且移除数字签名。app的目标代码被替换成安全性程序目标代码，从而创建被安全包装的app。使被安全包装的app预备在该设备上执行并且用新密钥来重新签名被安全包装的app。通过这种方式，在设备上实施用于控制对数据的访问和使对数据的访问变得安全的集中式策略。

本发明的另一个方面中，描述了一种防止app损坏设备的方法。被安全包装的app在设备上执行。将app安全性程序的安全性检查应用于app对设备操作系统的调用。基于对该调用的安全性检查的结果，app安全性程序执行下述之一：（a）允许所述调用通过到达所述操作系统；（b）增强所述调用；（c）阻止所述调用；或（d）终止执行被安全包装的app。

附图说明

参考附图，附图构成说明书的一部分，并且其中，通过举例说明的方式示出了本发明的具体实施例：

图1A是示出了本发明的app控制过程的概要的框图；

图1B是示出了本发明的app控制过程的替换实施例的框图；

图2是示出了根据本发明一个实施例的app安全性程序的组件的框图；

图3是示出了根据本发明一个实施例的在将app下载到设备之前使app安全的过程的流程图，；

图4是示出了根据一个实施例的在策略管理器中执行的方法的流程图；

图5是示出了根据一个实施例的在手持或移动设备上执行被安全包装的app的过程的流程图；

图6是根据一个实施例的app安全性控制系统的系统架构图；以及

图7A和图7B是适用于实施本发明各实施例的计算系统的框图。

具体实施方式

描述应用安全过程和系统的示例性实施例。这些例子和实施例仅用于增加上下文和有助于理解本发明。因此对于本领域技术人员来说显而易见的是，可以在没有在此描述的一些或全部具体细节的情况下实现本发明。在其它实例中，没有详细描述被熟知的概念，以避免不必要地使本发明晦涩。其它应用和实施例也是可能的，从而以下实施例、说明和上下文不应被视为限定性的或限制范围或设置。尽管这些实施例被充分详细描述以便使本领域技术人员能够实施本发明，但是这些实施例、说明和内容不是限制性的，且可使用其它实施例和做出修改，而不脱离本发明的精神和范围。

在各个附图中描述了防止设备软件应用程序感染或在其他方面损害设备（特别是移动设备）的方法和系统。通常用于各种移动设备（诸如智能电话、平板电脑、游戏设备和便携式计算设备）的这些类型的应用程序统称为“app”。这些app也可以被下载到非移动设备（例如TV、计算机、汽车和其它新兴的智能设备类型）上。所描述的方法和系统并不被限于移动设备上操作。这些设备程序或app已激增，并且现在非常流行。现在，app通常用Java或C语言编写。本文中描述的方法和系统可以被应用于以这两种语言中的任一种编写的app或者被应用于以用于不同平台的其他语言编写的app。大多数应用（如果不是全部）必须与所述移动设备的操作系统进行通信，以获取app所需的特定服务，以便执行其预期的功能，并且该服务通常仅可从操作系统获得。所使用的这种服务的常见示例是GPS，用于得到该app可能需要的该设备的位置。然而，由于这种暴露，app是该设备的弱点，并造成了用户的安全性和隐私风险。公司希望能够实施集中式策略来控制对其数据和软件的访问和使对其数据和软件的访问变得安全。这对于终端用户（即个人、家庭用户等等）也是一样的。它使企业IT部门维持对企业数据的管辖。下述方法提供了集中式方式来控制下载到移动设备上的app的安全性，其中所述设备为员工的个人电话或雇主的电话，使得那些app不会造成安全威胁。本发明的各种实施例也可以由家长和个人使用（即在家或非工作环境中），以确保其个人移动设备是安全的，免受恶意软件的威胁，并且也可以用于施加控制（例如用途）。本发明的app控制软件的实施例也可用于移动设备的数据保护和后备，以及用于应用程序级别 的遥测。

图1A是示出了本发明的app控制过程的概要的框图。这是对一个过程的一般性描述，而不依据特定的配置或环境。app102由app提供商100提供，app提供商可以是任何类型的实体（个人、软件开发商、雇主等）。其通常是未保护的，并且围绕它的唯一安全性是操作系统提供的。关于它一旦被装载如何在设备上执行而进行的唯一的防护和检查是由操作系统提供的。

本发明使能了不是由设备的操作系统提供的app的额外安全性。安全应用程序104被应用到app102上。或者app102被输入到程序104，程序104可以由第三方app安全提供商提供。在一个实施例中，安全应用程序104具有可以处于不同的位置的策略管理器和策略包装器。它们在图2中被更详细地描述。一旦安全性程序104已经被应用于app102，app被包装有安全层，使得设备被保护。其被显示为安全的app106。在一个实施例中，然后，安全的app106被下载到移动设备108（诸如智能电话或平板电脑）上，在移动设备108处，其安全地执行而不冒损害设备108的风险。另一个好处是，安全的app106也可由公司或其它提供该app给用户的实体（例如提供app给员工的雇主）来管理。例如，如果用户离开公司，该公司可从所述设备自动删除app和任何相关数据。在另一个例子中，家长能够限制另一个人（例如儿童）所使用的app，或限制时间量，例如一天10分钟，或者限制app可以访问的网站。或者，家长担心app泄露儿童的位置给未知的第三方。可以有许多其它的例子。如所指出的，图1A是用来示出使app安全并将其下载到设备上的一般过程。注意，在此实施例中，app102不是在被下载到设备上之后，而是在此之前变得安全以不造成对设备的损害。在另一个实施例中，在被下载到设备上之后但在其能够与操作系统交互之前，app变得安全。

图1B是示出了可选实施例的框图。不安全的app110（也由app提供商提供）被下载到移动设备112上。然而，在该实施例中，在设备112上可能具有特殊设计的app，该app阻止不安全的app110的实际安装。特殊的app（未示出）重新指向不安全的app110到app安全性程序114。不安全的app110被包装在安全策略中，所得的app显示为安全的app116。其接 着被下载和允许通过特殊app被安装到设备112上。以这种方式，个人或家庭用户，例如想要保护她的电话免受app造成的安全威胁的人，在app被下载到她的电话之前，可以通过第三方服务或由该用户的移动电话运营商使app变得安全（被包装），这里仅提及两个例子。应当注意，可以进行这种安全包装，而不管用户从哪里下载app。还应当注意到在图1A与图1B中，组件和软件之间的网络和连接被一般性地示出。该传输主要是通过因特网（未示出），但也可以是在私有网络或两者内。

图2是示出了根据本发明一个实施例的app安全性程序的组件的框图。在一个实施例中，安全性程序具有两个主要组件，策略管理器和策略包装器。策略管理器202接收来自负责设置移动设备的安全性的管理员或其它个人的输入。上述人员可以称作掌控者（governor），因为他掌控一个或多个移动设备的安全性。可以使用各种用户界面屏幕来设置安全策略。有许多策略的示例，包括地理围栏（geo-fencing）（例如app只能在建筑物内使用）等。服务提供商或者提供app安全性程序的实体也可以提供缺省的策略和安全性设置，其可能对于家庭用户是很有用的。策略设置的示例被描述如下。策略输入204被输入到策略管理器202中。策略管理器202从掌控者获得输入/设置，并且创建策略或元数据206。元数据206的格式或形式可以改变。它们实际上反映了来自掌控者的策略设置。

元数据（策略）206可以用作策略包装器208的输入。在一个实施例中，程序的该组件获得策略，并通过包装来使用它们使app210变得安全。包装器208从手持设备212接收app210。在一个实施例中，包装器208接收app210的拷贝而不是被下载到电话212上的原始app214（见上面的图1B）。在此，手持设备212的用户试图从app提供商218下载不安全的app216。在图1A所描述的场景中，其可在app自身上操作而不是在拷贝上操作。这可以是这样的情况：市场或app商店向客户提供app的安全版本，以及不安全的版本（或仅提供安全版本）。安全版本220（安全包装的版本）从策略包装器208返回到设备212。

元数据206也可用来更新本地策略文件（已经在设备上的现有策略）。本地策略文件被用于更新驻留在设备212上的策略参数。例如，在“地理围栏”（即限制将app用在某些物理区域）的情况下，很可能的是，由掌控 者控制的GPS位置将随时间而变化。当发生这种变化时，新策略可以以两种不同的方式被应用。一种为生成新策略并将其应用于原始app（即用新策略来包装app）。另一种方式是允许基于本地策略数据文件（其内部具有加密/签名的策略的“变量”部分）来动态配置。例如，为了诊断目的，IT人员可能希望能够直接通过驻留在设备上的IT app来推翻设备上的配置。

在一个实施例中，策略包括两个部分：固定部分和可变部分。固定部分是策略文件中所描述的内容（例如，“在白天的特定时间保护GPS”）。可变部分通常是掌控者通过控制台（例如“什么时候是GPS应当被保护的时间”）提供的。可变部分可以在不应用新策略的情况下改变。

策略设计者可以选择放弃该策略的可变部分，并且基本上将所有数据或内容静态地“嵌入”策略文件中。在这种情况下，控制台不具有任何方式来定制策略。

如果策略设计者选择在策略中包括一些可变部分，当改变所述可变数据（在控制台上）时，新的数据文件可以被发送到所述设备以反映最新的变化。这样的文件将被加密/签名（以防止恶意app规避该策略），下载到设备中，并由设备上的app安全性代码所使用，以将新数据应用于适当的策略。

这样的改变和更新可以通过本地策略更新组件222在运行时进行。该组件在设备212上创建了更新的策略参数。此后，被包装的app220将使用更新的策略参数。

在一个实施例中，策略管理器202和策略包装器208是同一app安全性程序中的组件，并且可以在同一计算机上运行。在其它实施例中，管理器和包装器组件可以在分离的计算机上。例如，策略管理器202可以在一个地点处的服务器上，策略包装器208可以是在另一个地点处的计算机上，并且可以被不同实体或相同实体管理。总体来说，管理器和包装器形成了app安全性程序，在一个实施例中，该app安全性程序由安全服务提供商操作。它也可以由企业（例如公司）、雇主、商业伙伴等，或者由移动电话运营商提供。

图3是示出了根据本发明一个实施例的在将app载到设备之前使app安全的过程的流程图。在步骤302中，在设备上生成待变得安全的app的 拷贝或克隆物。在一个实施例中，这可以在移动设备本身上完成或在设备外完成，例如在因特网上的组件上、在云中、在企业的服务器上或在运营商的服务器上。用户可以是个人、公司的员工或其它实体。如在本领域中公知的是，app可以以多种方式获得，最典型的方式是从app商店或app市场，或直接从app开发者或提供商或以任何适当的方式获得。通过生成拷贝，原始的app被保留，向用户提供了使用安全或不安全版本的选项，还保护用户在app控制过程中出现错误时还能够使用app的能力。注意，在一个实施例中，app没有被下载到电话上。在一个实施例中，下述方法是在单独的计算设备上执行。在另一个实施例中，该过程可以在移动设备上执行，但是在该过程完成而且app已经变得安全之后，app仅在该设备上执行。

在步骤304，app被解封。大多数（如果不是全部的）app具有由作者/开发者签署的数字签名。在步骤304，作为解封的部分，数字签名从app移除。这可以使用本领域已知的技术完成。对该app进行解密也可以在该步骤中进行。这些和其它步骤提供了app的核心目标代码，该app的核心目标代码现在可以由app控制程序操作。该操作的性质和具体细节可以取决于移动设备的操作系统。

有几种用于智能电话的操作系统的例子，如iOS（用于iPhone）、Android（用于来自各制造商的手机上）、Windows Mobile7、Web O/S、Palm及其他。在步骤306，核心目标代码app可以被反汇编或反编译，从而得到可执行的目标代码。例如，它可以是“本机代码”（CPU指令）或字节码（虚拟机指令，例如Java或.Net）。在一个实施例中，如果设备运行iOS，这可能更多是修改过程，在iOS中，所述反汇编更接近于定位和替代特定链接和术语的过程。然而，通常，在app已经被解封之后获得app的目标代码的反汇编过程可以使用本领域已知的技术来完成，例如使用反汇编程序。

在步骤308，app目标代码被增加了来自app安全性程序的目标代码。例如，该目标代码可包括被替换为来自安全性程序的类文件的类文件。该目标代码通常提供至移动设备操作系统的接口。app控制安全性程序目标代码部分获取自上述的策略/元数据。在iOS的情况下，操作不同在于发生“定位和替代”过程，而不是目标代码替换。这考虑到iOS使用的中断方法。通常，app安全性程序审查汇编语言代码。被定位的特定项是位于对象代码 中的软件中断（SWI），该软件中断（SWI）替换为至app控制安全性程序层的分支程序，然后该层决定采取什么进一步的动作，诸如如下所述的发出请求、增强结果等等。

在步骤310，在已经替换目标代码（或替换SWI）之后，app安全性程序使被安全性包装的app预备在所述移动设备上执行。由安全性程序替换到app中的目标代码通常提供了app和移动设备操作系统之间的桥接或连接。安全性程序类文件可被描述为围绕所述操作系统类文件包装。基于较早建立的策略（从掌控者输入的）来产生app安全性程序类文件。app基本上被重新连接，以用于在手持设备上执行。其被重新连接来使用除由移动设备操作系统层提供的安全性之外的app安全性程序层。也就是说，安全的app仍可受到操作系统的安全规定。在一个实施例中，某些装饰的改变也可以对app做出，如改变app的图标以反映其是安全的。通过这样做，用户可以确信，当app的图标出现在手持设备屏幕上时，安全版本的app将被执行。该app现在基本上已经被安全性程序重构（re-factor）或重新编程。

在步骤312，用新密钥对app进行签名，例如，用服务提供商的密钥或提供安全app的企业的密钥。app的重构的安全版本被返回到手机设备。在另一个实施例中，app在电话上被包装有安全层。在步骤314，在一个实施例中，app的原始、不安全的拷贝从手机设备中删除。一旦app的安全版本被下载到手机上，这可以通过app的安全版本来完成。在其它实施例中，不这样做并且两个版本均保留在移动设备上。在该阶段，该过程结束。

图4是根据一个实施例的在策略管理器202中执行的方法的流程图。在步骤402，掌控者或其他安全策略个人被允许定义、产生、并创建安全策略。其可能是企业的网络管理员，决定了针对使用几十个企业app（特别用于工作的）的数百个员工的大批的移动设备安全策略，该企业app可以被下载到数百或数千个移动设备上。在范围的另一端上，其可以是为由她的孩子下载到新的移动设备上的三个或四个app设置安全策略的父母。其它例子包括预防或压制使用GPS的游戏app，防止app使用设备上的麦克风来记录或窃听对话等等。在任一情况下，掌控者可以考虑app的类别，app的类型和性质，作者、年龄适当性、以及其它多个因素。例如，具有编写 了已经被分类为恶意软件或造成设备的安全威胁的其他app的同一作者。可以确定是否存在来自相同作者的其它应用。就是在这个阶段，掌控者决定哪些规则适用于每个app。在一个实施例中，这是由掌控者离线完成的。也就是说，它可以通过使用在家庭计算机上或在管理员使用的企业网络计算机上的用户接口来完成，其中可以使用由安全性程序服务提供商提供的安全模板（基本上是默认模板），或者可以利用模板设置非常特殊的规则。

在步骤404，在步骤402输入的安全性数据被app控制安全性程序使用，以创建实际的策略。在步骤406，基于来自掌控者的关于在步骤404建立的安全策略的输入来生成app控制安全性程序目标代码。如果需要，掌控者或服务提供商还可以更新现有的安全策略。如上所述，目标代码可用于增强从反汇编的app获得的某些原始目标代码。增强的代码被插入以调整app的安全性和隐私性设置，以便保护企业和终端用户。原始app的行为被改变，这允许掌控者来控制app的行为。例如，如果app以明码（即未加密）存储敏感帐户信息，行为可以被改变，使得app创建的所有信息被以加密的形式存储，并且只有该app才能访问，假定用于存储的持续数据的密钥对于app将是唯一的。在许多情况下，增强代码可以改善app的性能，因为该代码被优化，以用于特定的使用场景。

图5是示出了根据一个实施例的在手机或移动设备上执行被安全性包装的app的过程的流程图。在步骤502中，改变或修改当app在设备上执行时的或紧在其在设备执行之前的app的行为。例如，行为修改可包括在app初始化期间的认证；例如智能/CAC卡、或口令质询。如同原始的设计，一些app可能不需要安全性密码，然而，已经被修改的app的安全版本可能需要用户输入密码。在步骤504，由用户激活安全的app（例如，如果该设备具有触摸屏，敲击图标），安全的app在移动设备上执行。在执行了app之后，在一个实施例中，控制可以采用四个选项中的一个。如本领域中已知的是，当app执行时，其调用或请求设备操作系统以执行其功能。许多情况下，这些调用对于电话或设备可能是无害或不会引起显著安全性威胁的。如果是这种情况，如步骤506所示的那样，该调用可以被允许通过到达该操作系统。在此，该调用是对该设备操作系统做出的，app以正常方式执行。

如果围绕app的安全层或包装器检测到app做出可能引起对设备的安全威胁的请求，则app安全层可以在该请求被通过到达操作系统或电话内的其它软件或硬件组件之前，增强或修改该请求。这在步骤508中示出。在一个实施例中，掌控者通过检查一个或多个策略，来确定哪些调用是允许的。例如，掌控者可确定所有数据应该以加密形式被保存。在另一个示例中，掌控者可以决定，只有经选择的一组可信app应当具有士兵GPS坐标的数据。在一个实施例中，不存在运行时逻辑以确定什么是安全的、潜在威胁或实际威胁；其基本上是由掌控者在上述步骤404处创建的策略中预先声明的。在另一个实施例中，可能存在一些运行时逻辑。例如，app可以尝试将花费多的SMS文本消息发送出去。app控制程序可其进行确定，并可阻止app发送超过一定数量的文本消息，例如，可以限制其发送一个消息。增强可以是增加新的要求，例如口令要求。在另一示例中，如果调用是要在移动设备存储器上保存数据，则安全的app实际上可以将数据备份到在云中或在因特网上（即在设备外）的存储区域。在另一个例子中，与调用有关的数据可以被加密。

在步骤510，安全的app可以确定该调用是实际威胁，并且应当以比步骤508更严厉的方式来处理该调用。例如，可能已经决定了基于用于app的策略，即如果在安全建筑物（例如五角大楼）的时候访问设备上的照相机，app应该立即被终止。仅增强请求在这种情况下是不够的。在步骤510，该请求可能不被允许进入到操作系统或设备的任何其它组件。然而，在一个实施例中，响应被返回到app，但该响应被故意设置为不精确的或不正确的。它基本上是混淆（obfuscated）的响应。例如，它可以是非设备的实际物理坐标的GPS坐标（例如，设备在加利福尼亚，但返回给app的GPS坐标是在内布拉斯加州的坐标）。这在当app被儿童使用时可能是期望的。其它示例可以是，如果应当只在限制性环境（例如安全办公室区域）中运行的app被确定为在该环境外部（例如在家）运行，则返回差的或篡改后的数据结果。在本实施例中，该app可以被部分地废止，使得app只能访问非机密数据，并且其中机密信息是无用的。在另一示例中，当用户试图将来自机密的app的敏感数据粘贴或复制到非机密的app，则app控制程序可以改变被粘贴到垃圾箱的该数据的拷贝或基本上使其无意义。在步骤506、 508或510已经被完成后，在步骤514，被安全包装的app继续在移动装置上执行。

在步骤512，围绕app的安全层已经确定该调用是app做出的或app执行行为通常给移动设备造成过高的安全性威胁等级。在这种极端的情况下，安全层决定终止执行该app和/或删除该app。例如，app可能正使用电话上的太多资源（例如带宽），或对操作系统做出过多的高风险调用，从而过分暴露移动设备。在这种情况下，可以简单地从电话中删除该app或该app可以被终止。用户可能不能够重新执行它或重新安装它。例如，员工不可以再次在该公司电话上安装app，因为它暴露敏感的公司数据。或者，它也可以确定app正秘密收集电话上的数据或安装恶意软件。

图6是根据一个实施例的app安全性控制系统的系统架构图。触发管理器组件602处理两个事件，一个用于产生新策略604和另一个用于更新策略参数606。这种事件可以由各种系统触发。例如，控制台管理员或掌控者可能应用新的策略至所有设备（手动操作）。或者，在检测到源于设备（或app）的可疑流量之后，网络监控应用程序可以推出了新的策略，该新的策略将防止用户/设备/app访问网络资源（自动操作的示例）。有权来改变/更新策略的各种系统或实体通过触发管理器602来这么做。

新策略输出604被输入到策略定义文件608，策略定义文件608可以在运行时产生，并且可以包括各种类型的代码和扩展，例如专用于app控制服务提供商的，或专用于策略所应用到的app/用户/设备的。策略定义文件608被输入到具有两个输出的策略编译器610。一个输出是包装器定义文件612。该文件被输入到app包装器组件614。app包装器组件614负责通过将自定义二进制代码（本地代码或字节码）输入到例如直接从app商店下载的app中从而产生安全的app。或者该app可以是用户下载到他设备上的然后被上传到“AppControl”服务器的app。

app包装器组件614可以具有三个输入:来自一个或多个app商店616的app，来自身份管理组件618的认证密钥管理数据，以及硬化组件（hardened component）620。密钥管理数据是用来联结该用户、设备和app的身份，并确保受到策略控制的任何操作可以被联接到特定的用户/设备/app。这也确保了被包装的应用程序只能在特定设备上运行，以防止恶意的 app绕过策略和硬化组件620（例如“设备安全框架”）。来自app包装器614的输出是被包装的app 622，app 622通过设备的控制器626被下载或安装到移动设备624上。设备控制器626的职责包括：从app包装器下载app；确保运行于设备上的app是被适当包装的app（例如，针对用户1包装的app不应被安装/运行在用户2的设备上）；报告已安装的应用程序的列表/版本，以允许管理控制台来控制每个设备/用户/app的策略；以及在适当的时候下载策略参数。被包装的app622驻留在与策略参数628耦合的设备624上。

现在返回策略编译器610，另一个输出是运行时策略定义文件630。该文件被输入到运行时策略编译器632，运行时策略编译器632还接收策略参数606（由管理控制台或其它子系统指定的）作为输入。来自编译器632的输出是设备运行时策略文件634。该文件634被下载到设备624上，如被示出为策略参数628，并用来定制应用于包装的app 622的策略。

下面描述的是本发明的app控制安全性程序的各种使用情况和能力。一种使用情况涉及移动电话上工作生活和个人生活的分离。存在用户个人使用的app和用户的雇主（或雇主的商业伙伴）可能已经提供的app，而且这些app在相同的电话上允许，该电话通常是该用户的个人电话。确定需要在用户电话上变得安全的app的安全性的掌控者可以阻止app（如电子邮件app）之间的复制/粘贴操作。掌控者可以为工作相关的app设置策略，该策略执行对app和相关联的文件的选择性擦除。基于用户位置的策略也可以控制某些app可以执行的地点。因为恶意软件而保护的级别的示例是拒绝访问联系人、拒绝未经许可的SMS的传输等等。

使用情况的另一示例是app控制。使用本发明，可以实施app的白名单和黑名单，以及根据掌控者设置的策略完全删除app。app可以被“沙箱（sandbox）”来保护其它app、软件和设备的硬件。其他能力可以包括基于身份的app或服务控制，以及app行为的高粒度控制。木马识别是可以用app安全性程序实施的另一种使用情况。例如，每个app和内容可以被加密，以便防止流氓app访问和窃取电话上的机密数据。安全性程序也能够识别app的异常系统调用行为，以识别在它们的公开意图外做出行动的恶意木马app。

另一使用情况是app数据的备份和恢复，其中IT安全管理员和掌控者具有数据修订控制，并且可以通过备份和恢复操作来实施app和设备内容的迁移。在另一种使用情况中是网络流量监控。移动设备上的app可以在现有企业IDS/IPS/Web过滤基础设施的能见度下被引入，从而允许对app通信的检查和控制。app安全性程序还集成了第三方DNS服务，例如Symantec的DNS服务来识别恶意软件。所有app通信可被加密，包括在移动电话服务提供商处的通信。其它使用情况包括会话连续性、消费者隐私（例如，GPS混淆（obfuscation），实施安全DNS），以及拦截来自移动设备的支付/交易消息（即运行在移动商务流之中）。

在一个实施例中，app安全服务是由第三方服务提供商提供，例如使app由终端用户或个人使用（即与雇主或企业无关的用户）。例如，父母可能想要混淆孩子电话的GPS，因为该父母不想要社交网络站点（例如Fackbook）知道孩子在何处，基本上停用GPS。在另一个实施例中，由无线电话运营商操作的app商店（例如Verizon、AT&T）可以提供安全的app以获得额外收费或费用。运营商的客户可以通过支付额外的金额从市场或在线商店下载安全的app，而不是不安全的版本。在另一实施例中，企业可以具有其自己的app商店，用于其员工、合作者等等，其中用户可以仅下载app的安全版本（其可被称为“硬”app）。这些app可具有如在企业的掌控者（安全管理员）定义的许多上述安全特征，诸如阻止复制和粘贴电子邮件或公司数据、如果用户离开了公司从所述用户的电话毁掉app等等。移动电话运营商的DNS通常可以访问任何站点，但app安全性程序可以阻断移动设备浏览器，以便其只可以访问安全的DNS（例如，Symantec的DNS），其中只有安全网站可被访问。在另一个实施例中，app安全性程序提供商可与该移动设备制造商合作，将app安全性程序或功能合并到设备的硬件和软件操作中。在该实施例中，如下所述，用户可以下载不安全的app，并在执行之前在手机或设备本身上使其变得安全，并且不必访问第三方服务来使app安全，或确保在被下载到设备之前app是安全的。

如从上述各实施例能够看到的，移动设备的安全性延伸到设备本身之外，并被直接应用到被下载到该设备上的app中。公司和其它实体能够更自由地利用app，而不必担心安全风险，例如公司的企业IT系统的数据泄 漏或恶意软件感染。公司可以保持对其公司数据的控制。

图7A和图7B示出了适用于实施本发明各实施例的计算系统700。图7A示出了计算系统的一种可能的物理形式。当然，计算系统可具有许多物理形式，该物理形式包括集成电路、印刷电路板、小型手持设备（例如移动电话、手机或PDA）、个人计算机或超级计算机。计算系统700包括监视器702、显示器704、外壳706、硬盘驱动器708、键盘710和鼠标712。盘714是计算机可读介质，其用于将数据传递到计算机系统700，和传递来自计算机系统700的数据。

图7B是计算系统700的框图的示例。附着到系统总线720的是各种各样的子系统。一个或多个处理器722（也称为中央处理单元，或CPU）耦合到存储设备，存储设备包括存储器724。存储器724包括随机存取存储器（RAM）和只读存储器（ROM）。如在本领域中是众所周知的，ROM用于将数据和指令单向传送到CPU，而RAM通常用来以双向的方式传输数据和指令。这两种类型的存储器可包括下面描述的任何合适的计算机可读介质。固定的盘726也被双向耦合到CPU 722；其提供额外的数据存储容量，并且也包括下面描述的任何计算机可读介质。固定的盘726可被用来存储程序、数据等，并且通常是比主存储器慢的次级存储介质（如硬盘）。应当看到，驻留在固定的盘726中的信息，可以在适当的情况下，作为虚拟存储器以标准的方式结合在存储器724中。可移除的盘714的形式可以是下面描述的任何计算机可读介质。

CPU 722还耦合到各种输入/输出设备，例如显示器704、键盘710、鼠标712和扬声器730。一般而言，输入/输出设备可以是以下任何一种：视频显示器、轨迹球、鼠标、键盘、麦克风、触敏显示器、转换器读卡器、磁带或纸带阅读器、书写板、光笔、语音或手写识别器、生物统计学阅读器或其他计算机。CPU 722可以任选地使用网络接口740耦合到另一计算机或电信网络。使用这种网络接口，可以预期，CPU可以在执行上述方法步骤的过程中，从网络接收信息，或将信息输出到网络。此外，本发明的方法实施例可以单独在CPU 722上执行，或者可以与共享该处理的一部分的远程CPU相结合地在诸如因特网的网络上执行。

虽然本发明的说明性实施例和应用在此被示出和描述，许多变化和修 改是可能的，其仍在本发明的概念、范围、和精神之内，并且本领域普通技术人员在熟读本申请之后，这些变化将变得清楚。因此，所描述的实施例应当被认为是说明性的而不是限制性的，并且本发明并不限于这里给出的细节，而是可以在所附权利要求的范围和等同形式内修改。

Claims (22)

1.一种使用安全性程序来使在设备上执行的app变得安全的方法，所述方法包括：

生成针对app安全性程序的Java类文件，该生成由多个app安全策略支配；

利用针对所述app安全性程序的所述Java类文件替代针对所述app的Java类文件，其中，替代过的针对所述app的所述Java类文件用作所述app和设备操作系统之间的代理；

在完成针对所述app的Java类文件的替代之后，创建被安全包装的app；

使所述被安全包装的app预备在所述设备上执行；以及

利用新的密钥对所述被安全包装的app进行重新签名。

2.如权利要求1所述的方法，还包括使用所述安全性程序来反编译所述app，从而获得可执行代码。

3.如权利要求1所述的方法，还包括使用所述安全性程序来反汇编所述app，从而获得可执行代码。

4.如权利要求1所述的方法，还包括：

将安全性程序应用至所述app。

5.如权利要求1所述的方法，其中，获取核心目标代码和替代app目标代码是在所述app与所述设备的操作系统交互之前完成的。

6.如权利要求5所述的方法，还包括：

所述安全性程序阻止app目标代码与所述操作系统的交互。

7.如权利要求5所述的方法，还包括：

将所述app重新指向到所述设备外的安全性程序。

8.如权利要求5所述的方法，还包括：

确保所述被安全包装的app能够运行在所述设备上，而不在另一设备上运行。

9.如权利要求1所述的方法，还包括生成所述app的拷贝。

10.如权利要求9所述的方法，还包括：

从所述设备删除原始的app。

11.如权利要求9所述的方法，还包括：

如果在使所述设备上的所述app变得安全时发生故障，则还原到原始app。

12.如权利要求1所述的方法，还包括：

改变在所述设备的显示器上表示所述app的图标，以显示所述app是安全的。

13.如权利要求1所述的方法，还包括：

在下载所述app之前，利用安全层包装所述app。

14.如权利要求1所述的方法，其中，所述被安全包装的app实施了app策略。

15.如权利要求1所述的方法，其中，所述app策略包括限制app在所述设备上的执行时间、限制所述设备上的app的总数；和限制app能够执行的地点中的一个或多个。

16.一种防止app损坏设备的方法，所述方法包括：

在所述设备上执行通过权利要求1所述的方法生成的被安全包装的app；

将安全性检查施加到由所述被安全包装的app对所述设备的操作系统做出的调用；以及

基于对所述调用的安全性检查的所述施加，执行以下步骤之一：

(a)允许所述调用通过到达所述操作系统；

(b)增强所述调用；

(c)阻止所述调用；以及

(d)终止所述被安全包装的app，

其中，在所述设备上实施用于控制对数据的访问和使对数据的访问变得安全的策略。

17.如权利要求16所述的方法，其中，终止所述app还包括：

从所述设备自动删除所述app。

18.如权利要求16所述的方法，其中，所述被安全包装的app实施策略，其中，所述策略包括限制app在所述设备上的执行时间、限制所述设备上的app的总数；和限制app能够执行的地点中的一个或多个。

19.如权利要求16所述的方法，其中，阻止所述调用还包括：

执行以下之一：提供对所述调用的混淆响应，和提供部分数据使得任何机密的数据被保密。

20.如权利要求16所述的方法，其中，增强所述调用还包括：

对保存于所述设备中的数据进行加密。

21.如权利要求16所述的方法，其中，所述app被暴露于现有的过滤基础设施，从而允许对app通信进行检查和控制。

22.如权利要求21所述的方法，其中，所述过滤基础设施包括IDS、IPS和Web过滤。