CN106304040A - 管理移动应用的方法、装置 - Google Patents

Abstract

本申请公开了管理移动应用的方法、装置，该方法运行于应用商店服务器，包括步骤：当收到客户端的下载请求时，将加密的应用程序包文件及加密的权限信息发送给所述客户端；所述应用程序包文件为所述移动应用的安装程序文件；所述权限信息包括使用所述客户端的用户相关的权限数据及解密信息，所述解密信息用于对加密的所述应用程序包文件进行解密。本申请能够保证移动应用的安全性。

Description

管理移动应用的方法、装置

技术领域

本申请涉及移动应用的安全验证技术，尤其涉及管理移动应用的方法、装置。

背景技术

目前的安卓Android应用市场没有严密的应用收费、应用版权保护的机制。以谷歌Google公司的应用平台为例，为了防止移动应用被破解和篡改，当应用开发者将APK(application package file，应用程序包文件)上传到Android平台的应用商店时，应用商店会在APK的原始逻辑中插入额外的代码逻辑进行保护，所插入的代码逻辑称为LVL(License Verification Library，许可证验证库)。但由于LVL并非Android OS的一部分，而是使用该机制的应用将其集成在应用中的，从而造成LVL和APK的业务逻辑均容易被反汇编和破解，因此通过该方式管理移动应用缺乏安全性。

发明内容

本申请提供一种管理移动应用的方法及装置，能够保证移动应用的安全性。

根据本申请实施例的第一方面，提供一种管理移动应用的方法，运行于应用商店服务器，包括步骤：

当收到客户端的下载请求时，将加密的应用程序包文件及加密的权限信息发送给所述客户端；所述应用程序包文件为所述移动应用的安装程序文件；所述权限信息包括使用所述客户端的用户相关的权限数据及解密信息，所述解密信息用于对加密的所述应用程序包文件进行解密。

根据本申请实施例的第二方面，提供一种管理移动应用的方法，包括步骤：

在安装或运行所述移动应用时，获取第二密钥；

利用第二密钥解密出权限信息，所述权限信息包括使用所述客户端的用户相关的权限数据；

根据使用所述客户端的用户相关的权限数据对所述客户端进行授权认证。

根据本申请实施例的第三方面，提供一种管理移动应用的装置，位于服务器端，包括：

应用加密模块，用于加密应用程序包文件及权限信息，所述应用程序包文件为所述移动应用的安装程序文件；所述权限信息包括使用所述客户端的用户相关的权限数据及解密信息，所述解密信息用于对加密的所述应用程序包文件进行解密；当收到客户端的下载请求时，将加密的应用程序包文件及加密的权限信息发送给所述客户端；

应用存储模块，用于将权限信息和加密/未加密的应用程序包文件在所述服务器端存储。

根据本申请实施例的第四方面，提供一种管理移动应用的装置，位于客户端，包括：

应用加密模块，用于在安装或运行所述移动应用时，获取第二密钥；利用第二密钥解密出权限信息，并发给应用权限管理模块，所述权限信息包括使用所述客户端的用户相关的权限数据；

所述应用权限管理模块，用于根据使用所述客户端的用户相关的权限数据对所述客户端进行授权认证。

本申请在服务器将APK发给客户端时，以加密的方式发送，另外，将对用户授权认证相关的权限数据以加密的方式发给客户端，以使得客户端能够利用收到的权限数据在本地对用户权限进行认证，由此看出，本申请首先在APK的下载过程中通过加密保证了传输的安全性，另外通过使客户端能够在本地进行授权认证，进一步避免了权限数据在传输过程中被截获篡改的风险，从而很好地保证了移动应用能够被安全下载。

而针对客户端，只有当移动应用安装或运行时，加密的APK及权限信息中的内容才会被解密到临时的内存块中，在应用安装或运行结束时，内存中的相关明文数据会被立即清除，因此客户端在管理移动应用时也能够很好地保证移动应用的安全性。

附图说明

图1a为本申请实施例中一种网络图；

图1b为本申请实施例中服务器侧管理移动应用的方法流程图；

图2为本申请实施例中客户端侧管理移动应用的方法流程图；

图3为本申请实施例中加密的流程图；

图4为本申请一个应用实例中管理移动应用的方法的时序图；

图5为本申请实施例中管理移动应用的装置的硬件架构图；

图6为本申请一个实施例中管理移动应用的装置的软件逻辑框图；

图7为本申请一个实施例中管理移动应用的装置的软件逻辑框图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

如图1a所示，本申请所依赖的网络环境通常包括客户端10和服务器20，客户端可以是任何可以安装移动应用的终端设备，诸如移动手机、平板电脑(Pad)、个人数字助理(PDA)、MP3播放器的便携设备或者无机箱的一体机等。在客户端10上装有应用商店客户端11；服务器20上装有应用商店服务器21。移动应用的开发者通常通过应用商店服务器21提供的接口来上传应用程序安装包；需要使用移动应用的用户通常需要通过客户端10上所安装的应用商店客户端20向应用商店服务器21发送下载请求，从应用商店服务器21获取应用程序安装包，在客户端10上安装应用程序安装包后使用移动应用所提供的功能。

图1b从服务器20侧来描述本申请管理移动应用的方法。

S100，接收客户端10的下载请求，

S101，将加密的应用程序包文件(以下简称为APK)及加密的权限信息发送给客户端10。

应用程序包文件为移动应用的安装程序文件；权限信息包括使用所述客户端的用户相关的权限数据及解密信息，解密信息用于对加密的应用程序包文件进行解密。以下的各实施例，解密信息可以包括随机数、第一密钥。

在本申请中可以为APK的开发者开放权限设置的接口，开发者在上传APK时，可以对该APK的权限进行定价设置，例如使用次数、使用时长及相应的费用等，本申请中将开发者设置的与APK定价相关的数据称为定价数据。定价数据在被上传到应用商店服务器后，保存在数据库中，当某个客户端请求下载APK时，根据使用该客户端的用户的购买请求生成与该用户相关的购买数据，本申请中将根据购买数据生成的与权限认证相关的数据称为权限数据，服务器将与该用户相关的权限数据发给客户端。例如，用户a购买的权限数据为1年，则根据该移动应用的某个期限内的定价标准，生成该用户a购买一年的价格以及购买期限，在一个实施例中，可以将允许该用户使用的次数或用于表示购买期限是否超期的定时器作为用户a相关的权限数据。

从步骤S101可以看出，本申请中，将应用程序包文件和与用户相关的权限数据均以加密的形式发送给客户端。

在本申请中，客户端10、服务器20、应用商店服务器21、应用商店客户端20其中的任何一个，在需要对数据进行加密时，加密的方式均可参照例如图2所示的流程：按照随机数算法生成随机数作为密钥种子(S201)，然后将生成的密钥种子通过密钥提取算法生成密钥(S202)，再通过密钥利用加密算法将被加密的对象进行加密(S203)。密钥提取算法可以是目前通用的生成密钥的算法。

在S203阶段，通过密钥对被加密对象进行加密的方式也存在多种途径。加密算法可以选用对称加密算法(例如AES-256等高强度的对称加密算法)、RSA等非对称加密算法。开发者可根据应用场景对保密性和效率的需求来选择合适的加密算法。在加密时，其中一种方式是，利用选定的加密算法对被加密对象的整体进行加密，而另一种方式可以是，将被加密对象分为若干段，选取几种加密算法分别对其中一段进行加密。此处不排除此两种加密方式以外的其他加密形式。以加密APK为例，可以利用一个加密算法将整个APK文件加密，也可以利用多种加密算法将APK文件分段加密。

在S201阶段，生成随机数的方式可以参考不同应用场景下对安全性的要求确定。

一般情况下，可以利用系统随机数算法来生成系统随机数。这里的系统随机数算法是指使用一个固定的算法(如系统提供的随机数生成函数)来提供产生的随机数。每次调用系统随机数算法所生成的系统随机数不同。

另一种情况下，可以开发者自定义算法(自定义算法可以由开发者自行制定)，使得输入相同的参数时，对于同一个APK使用同一种算法时，每次所生成的随机数相同；不同APK的随机数不同；而当输入不同的参数时，对于同一APK所生成的随机数不同。为方便描述，本申请将此随机数称为第一随机数。

在第三种情况下，可以将系统随机数和第一随机数组合作为生成密钥所使用的随机数，为方便描述，称为组合随机数。

以下首先对应用商店服务器21在本申请中的工作原理进行阐述。

应用商店服务器对APK的加密时机可以是在收到APK开发者上传的APK后进行加密，然后将加密后的APK在服务器20的数据库中存储；也可以是将APK以明文的形式在数据库中存储，将APK发送给客户端前进行加密(此过程结合后文对权限数据的加密过程进行描述)。当以明文存储APK时，为了防止APK不被非法篡改，随意使用，可以控制访问服务器的权限，使得无法通过非正常手段访问和下载APK文件。

以下针对在收到开发者上传的APK后加密，再将加密后的APK进行存储的实现方式进行描述，为方便描述，将加密APK的密钥称为第一密钥。可以理解的是，以下所列举的实施例并未穷尽所有实现方式。

实施例1：应用商店服务器利用系统随机数算法生成系统随机数，通过系统随机数生成第一密钥，用第一密钥对APK进行加密，将加密后的APK进行存储。由于每次调用系统随机数算法所生成的系统随机数不同，因此需要将系统随机数或者第一密钥进行存储，以便后续发给客户端解密APK时使用。

实施例2：应用商店服务器利用自定义算法生成第一随机数，通过第一随机数生成第一密钥，将加密后的APK进行存储。由于针对同一个APK，每次生成的第一随机数相同，因此可以不必在数据库中存储第一随机数，以进一步保证所保存的数据的安全性。当然也可以将第一随机数或第一密钥进行存储。

实施例3：应用商店服务器组合随机数生成第一密钥，将加密后的APK进行存储。由于组合随机数是通过系统随机数和第一随机数组合而成，因此至少需要将系统随机数进行存储，当然，也可以将组合随机数或第一密钥进行存储。

以下针对应用商店服务器向客户端传输数据的过程进行阐述。

以上实施例1、2、3可以看出，应用商店服务器存储的数据可以描述为以下几种形式。在不同的实施例中，这里的随机数可以代表系统随机数、第一随机数、组合随机数中一种。

第一，存储加密的APK、随机数、权限数据；

第二，存储加密的APK、第一密钥、权限数据；

第三，存储加密的APK、权限数据。

第四，存储未加密的APK、权限数据。

因此，应用商店服务器21在S101步骤中向客户端10传输的数据可能包括以下几种情况：

1、加密的APK及加密的随机数、加密的用户相关的权限数据；

2、加密的APK及加密的第一密钥、加密的用户相关的权限数据；

在这种情况下，如果应用商店服务器之前所存储的是第一密钥，则可以直接取出第一密钥进行加密；如果之前所存储的是随机数，则需要在从数据库中取出随机数后，根据密钥提取算法生成第一密钥，然后再将第一密钥进行加密。

如果在应用客户端服务器中所存储的APK为加密后的APK，则可以选择无需再次加密或二次加密后发送至客户端。如果应用商店服务器中所存储的APK为明文，则需要先通过第一密钥对APK明文进行加密，另外需要将生成第一密钥的随机数或第一密钥也加密发给客户端。对于需要通过第一密钥加密后的APK(为方便描述，以下称APK密文)二次加密后再发给客户端，则可以参照以下处理流程，在以下流程中，通过第二密钥对待加密的数据进行加密。

例如，可以将待加密的几种数据分别加密成不同的文件，或者待加密几种数据组合成一个文件后加密，或者将APK密文加密在一个文件中，作为解密信息的随机数或第一密钥与用户相关的权限数据按照预定格式生成权限文件，在同一个文件中加密，将加密后的权限文件发送给客户端。

值得指出的是，第二密钥可以与第一密钥不同，作为一个例子，通过第一随机数生成第二密钥，可以将用户输入的密码、用户在移动应用上的登录账户、客户端所在设备的硬件标识等参数中的一个或几个作为生成第一随机数的输入参数。

以上描述的是应用商店服务器的工作原理。针对应用商店服务器所传输的数据的种类不同，以下对客户端(在此不区分应用商店客户端21和客户端10，根据不同开发者的实现方案，各步骤可以在应用商店客户端21或客户端10上执行。)的工作原理进行描述。

图3所示，S301，在安装或运行所述移动应用时，获取第二密钥；

客户端需要有能力获取到与应用商店服务器相同的第二密钥，因此可以将第二密钥预先存储在客户端中，或者在客户端内置相同的密钥提取算法，并配置与应用商店服务器生成第一随机数相同的输入参数及随机数算法。例如，如果应用商店服务器生成第二密钥的第一随机数的输入参数为用户输入的密码、用户在移动应用上的登录账户、客户端所在设备的硬件标识等参数中的一个或几个，则在客户端生成第一随机数的输入参数也需要是相同的输入参数。

S302，利用第二密钥解密出权限信息，权限信息包括使用客户端的用户相关的权限数据；

S303，根据用户相关的权限数据对客户端进行授权认证。

作为一个例子，在客户端收到服务器发送的加密的应用程序包文件及加密的权限信息后，将其保存；权限信息还包括解密信息，解密信息用于对加密的应用程序包文件进行解密。和现有的典型方案(如Google、Amazon)不同，本申请在客户端本地即可获取到与用户相关的权限数据，并不需要通过Internet连接远端服务器去获取和验证权限信息，因此，即使终端当前的网络不可用或网络状况不好，也不会因为获取不到权限信息而无法使用应用，因此可以实现对用户的离线认证。可以将权限信息加密存储在安全的隔离区域中，可以避免被非法的访问或篡改。

作为一个例子，S303步骤根据用户相关的权限数据对所述客户端进行授权认证后，需要刷新用户相关的权限数据(如将该用户允许使用的次数减1)；将刷新后的用户相关的权限数据加密，并保存。和现有的典型方案(如Google、Amazon)不同，本申请中，客户端可以在操作系统内部保存加密的权限信息，由于不需要像Google那样修改移动应用程序本身，而是在终端设备的操作系统内部嵌入认证逻辑，因此，无法通过分析应用程序文件本身窥得任何权限认证相关的业务逻辑，更加难以被破解。并且权限数据只有在被使用时才会被解密，因此可以充分保证对用户认证的安全性。

通过图3的流程可以看出，在安装和运行移动应用时会触发对用户权限认证的动作。

首先对安装移动应用的处理流程进行描述。

在用户要求安装移动应用时，客户端会要求用户输入密码，当客户端接收到用户的输入密码后，触发S301获取第二密钥的步骤，如果预存有第二密钥，则取出预存的第二密钥，如果没有预存第二密钥，则根据用户输入密码、登录账户、所述客户端所在设备的硬件标识中的一种或多种参数作为输入参数生成随机数，利用随机数生成第二密钥。

通过第二密钥解密出与用户相关的权限数据后，对用户进行权限认证，如果认证通过，则解密APK，并进行安装。解密APK时需要利用解密信息。另外，权限认证通过后，需要刷新用户相关的权限数据，然后再次通过第二密钥加密后存储，已备后续用户使用移动应用时进行权限认证。

由于客户端接收到的数据的种类可能是以下几种情况：

1、加密的APK及加密的随机数、加密的用户相关的权限数据；

2、加密的APK及加密的第一密钥、加密的用户相关的权限数据；

如果通过第二密钥解密出的解密信息是随机数，由于应用商店服务器没有将第一密钥直接发送过来，因此需要客户端根据所收到的随机数生成第一密钥。为了能够生成与应用商店服务器加密APK所使用的密钥相同的密钥，需要在客户端或客户端所在的设备内置相同的密钥提取算法。

以下对用户使用移动应用时的处理流程进行描述：

在用户要求使用移动应用时，客户端会要求用户输入密码，当客户端接收到用户的输入密码后，触发S301获取第二密钥的步骤，如果预存有第二密钥，则取出预存的第二密钥，如果没有预存第二密钥，则根据用户输入密码、登录账户、所述客户端所在设备的硬件标识中的一种或多种参数作为输入参数生成随机数，利用随机数生成第二密钥。

通过第二密钥解密出与用户相关的权限数据后，对用户进行权限认证，如果认证通过，则启动移动应用。另外，权限认证通过后，需要刷新用户相关的权限数据，然后再次通过第二密钥加密后存储，已备后续用户使用移动应用时进行权限认证。如果权限认证失败，例如权限过期，则移动应用不被启动，并且提示用户重新购买移动应用或续费。

图4描述一个具体的应用场景下，应用商店服务器与客户端的交互过程。在本应用实例中，通过独立于应用商店服务器的数据存储服务器来存储APK及权限信息。

S401，当应用商店服务器接收到APK开发者发送的APK后，通过系统随机数算法生成系统随机数；

S402，利用系统随机数，通过密钥提取算法生成第一密钥；

S403，通过第一密钥对APK进行加密；

S404，将加密的APK文件发给数据存储服务器进行保存，由于每次调用系统随机数算法的接口所产生的系统随机数不同，因此也需要将生成的系统随机数发给数据存储服务器进行保存；

S405，当接收到客户端的下载APK请求后，将系统随机数和加密的APK文件从数据存储服务器取出；

S406，根据系统随机数通过密钥提取算法再次生成第一密钥；

S407，利用自定义算法生成第一随机数，并通过密钥提取算法生成第二密钥；作为一个应用实例，第一随机数的输入参数为用户输入密码、登录账户、客户端所在设备的硬件标识。

S408，通过第二密钥将第一密钥和用户相关的权限数据加密，与加密的APK一同发送至应用商店客户端。作为一个实施例，可以将第一密钥和权限信息按一定格式组装成文件形式(为方便描述，称为权限文件)，放入内存块中(譬如，按照常见的key＝value格式)，第二密钥对组装后的权限文件进行加密。

S409，应用商店客户端将收到的加密APK及加密权限信息发给客户端保存。客户端可以在一个加密的存储分区内保存加密的APK及加密的权限信息；

S410，当需要安装APK时，应用商店客户端接收到用户的输入密码后，发给客户端操作系统，客户端操作系统利用与步骤S407相同的输入参数(可以是与S407相同的用户输入密码、登录账户、客户端所在设备的硬件标识)和自定义随机数算法生成第一随机数，再利用同样的密钥提取算法生成第二密钥；

S411，通过第二密钥解密出加密的权限文件；

S412，利用权限文件中的与用户相关的权限数据对用户权限进行认证，如果认证通过，则利用第一密钥对加密的APK进行解密，并将APK发给应用商店客户端；将用户相关的权限数据刷新后再次通过第二密钥加密并保存；

S413，安装APK；

S414，当用户使用移动应用时，通过输入的用户密码触发权限验证过程。应用商店客户端将用户密码发给客户端操作系统，如果通过用户相关的权限数据判断，该移动应用允许在该应用商店客户端上使用，则通知应用商店客户端启动移动应用，同时，更新用户相关的权限数据(如将允许使用的次数减1等)，并调用再次通过“应用加密模块”重新加密和保存权限文件；如果权限过期，则移动应用不启动，并且通过应用商店客户端提示终端用户重新购买应用或续费。

本申请管理移动应用的装置的实施例可以终端设备或服务器上。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在终端设备或服务器的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图5所示，为本申请管理移动应用的装置所在终端设备或服务器的一种硬件结构图，除了图5所示的处理器、内存、网络接口、以及非易失性存储器之外，实施例中装置所在的终端设备或服务器通常根据该终端设备或服务器的实际功能，还可以包括其他硬件，对此不再赘述。

图6为管理移动应用的装置600的软件逻辑框图，移动应用的装置600位于服务器端，包括：

应用加密模块601，用于加密应用程序包文件及权限信息，所述应用程序包文件为所述移动应用的安装程序文件；所述加密的权限信息包括使用所述客户端的用户相关的权限数据及解密信息，所述解密信息用于对加密的所述应用程序包文件进行解密；当收到客户端的下载请求时，将加密的应用程序包文件及加密的权限信息发送给所述客户端；

应用存储模块602，用于将权限信息和加密/未加密的应用程序包文件在所述服务器端存储。

在一个实施例中，所述应用加密模块601收到客户端的下载请求之前还用于通过随机数算法生成随机数；根据所述随机数生成第一密钥；通过所述第一密钥加密所述应用程序包文件；

将加密后的应用程序包文件发给所述应用存储模块。

本申请中的所述解密信息可以是随机数，所述随机数包括系统随机数，所述应用存储模块602还用于将所述系统随机数在服务器端存储；

所述应用加密模块601还用于当收到客户端的下载请求时，将所述系统随机数加密后发送给所述客户端。

本申请中的所述解密信息还可以为第一密钥；所述随机数包括第一随机数，所述第一随机数的输入参数相同时，对于同一应用程序包文件通过同一随机数算法所获得的值相同；所述应用加密模块601还用于当收到客户端的下载请求时，通过随机数算法生成第一随机数；根据第一随机数生成第一密钥；将所述第一密钥加密后发送给客户端。

本申请中的所述解密信息为第一密钥时，所述应用存储模块602还用于将所述第一密钥在服务器端存储；

所述应用加密模块还用于当收到客户端的下载请求时，将所述第一密钥加密后发送给所述客户端。

在一个实施例中，所述应用加密模块601对所述解密信息和所述权限信息加密包括：

将所述解密信息和所述权限信息按照预定格式生成权限文件；

通过第二密钥将所述权限文件加密后发送给所述客户端。

在一个实施例中，所述应用加密模块601生成所述第二密钥的过程包括：

通过随机数算法生成随机数；所述随机数的输入参数包括用户输入密码、登录账户、所述客户端所在设备的硬件标识中的一种或多种参数；根据所述随机数生成第二密钥。

图7是本申请另一种管理移动应用的装置700的软件逻辑框图，管理移动应用的装置700位于客户端，包括：

应用加密模块701，用于在安装或运行所述移动应用时，获取第二密钥；利用第二密钥解密出权限信息，并发给应用权限管理模块702，所述权限信息包括使用所述客户端的用户相关的权限数据；

所述应用权限管理模块702，用于根据所述用户相关的权限数据对所述客户端进行授权认证。

作为一个实施例，还包括应用存储模块(图中未示出)，用于将从服务器接收的加密的应用程序包文件及加密的权限信息保存；所述权限信息还包括解密信息，所述解密信息用于对加密的应用程序包文件进行解密，所述应用程序包文件为所述移动应用的安装程序文件。

在一个实施例中，所述应用权限管理模块702还用于根据所述用户相关的权限数据对所述客户端进行授权认证后，刷新所述用户相关的权限数据；

所述应用加密模块701还用于加密刷新后的所述用户相关的权限数据，并发给所述应用存储模块保存。

在一个实施例中，管理移动应用的装置700还包括执行模块(图中未示出)，用于安装或运行所述移动应用；在安装所述移动应用时，如果所述客户端通过授权认证，所述应用加密模块根据所述解密信息解密加密的应用程序包文件，并通知所述执行模块安装解密后的应用程序包文件。

在一个实施例中，所述应用加密模块701获取所述第二密钥包括：

当用户输入密码后，根据所述输入参数生成随机数；所述输入参数包括用户输入密码、登录账户、所述客户端所在设备的硬件标识中的一种或多种参数；

根据所述随机数生成第二密钥。

在一个实施例中，所述应用加密模块701获取所述第二密钥包括：

当用户输入密码后，从所述应用存储模块获取预先存储的所述第二密钥。

在一个实施例中，所述应用加密模块701和所述应用权限管理模块位于所述应用商店客户端所在设备的操作系统。通过对客户端操作系统Framework的改造，将应用加密模块701和应用权限管理模块702植入到Framework中，并和Framework中的Package Manager Service原始流程紧密结合，完成加密APK文件的安装流程。

上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。

Claims (26)

1.一种管理移动应用的方法，运行于应用商店服务器，其特征在于，包括步骤：

当收到客户端的下载请求时，将加密的应用程序包文件及加密的权限信息发送给所述客户端；所述应用程序包文件为所述移动应用的安装程序文件；所述权限信息包括使用所述客户端的用户相关的权限数据及解密信息，所述解密信息用于对加密的所述应用程序包文件进行解密。

2.根据权利要求1所述的方法，其特征在于，收到客户端的下载请求之前还包括步骤：

通过随机数算法生成随机数；

根据所述随机数生成第一密钥；

通过所述第一密钥加密所述应用程序包文件；

将加密后的应用程序包文件进行存储。

3.根据权利要求2所述的方法，其特征在于，所述解密信息包括随机数，所述随机数包括系统随机数，所述方法还包括步骤：

将所述系统随机数进行存储；

当收到客户端的下载请求时，将所述系统随机数加密后发送给所述客户端。

4.根据权利要求2所述的方法，其特征在于，所述解密信息为第一密钥；所述随机数包括第一随机数，所述第一随机数的输入参数相同时，对于同一应用程序包文件通过同一随机数算法所获得的值相同；所述方法还包括步骤：

当收到客户端的下载请求时，通过随机数算法生成第一随机数；

根据第一随机数生成第一密钥；

将所述第一密钥加密后发送给客户端。

5.根据权利要求2所述的方法，其特征在于，所述解密信息为第一密钥，所述方法还包括步骤：

将所述第一密钥进行存储；

当收到客户端的下载请求时，将所述第一密钥加密后发送给所述客户端。

6.根据权利要求1所述的方法，其特征在于，对所述所述权限信息加密的过程包括：

将所述解密信息和与使用所述客户端的用户相关的权限数据按照预定格式生成权限文件；

通过第二密钥将所述权限文件加密后发送给所述客户端。

7.根据权利要求6所述的方法，其特征在于，所述第二密钥的生成过程包括：

通过随机数算法生成随机数；所述随机数的输入参数包括用户输入密码、登录账户、所述客户端所在设备的硬件标识中的一种或多种参数；

根据所述随机数生成第二密钥。

8.一种管理移动应用的方法，其特征在于，包括步骤：

在安装或运行所述移动应用时，获取第二密钥；

利用第二密钥解密出权限信息，所述权限信息包括使用所述客户端的用户相关的权限数据；

根据使用所述客户端的用户相关的权限数据对所述客户端进行授权认证。

9.根据权利要求8所述的方法，其特征在于，所述方法还包括步骤：

将从服务器接收的加密的应用程序包文件及加密的权限信息保存；所述权限信息还包括解密信息，所述解密信息用于对加密的应用程序包文件进行解密，所述应用程序包文件为所述移动应用的安装程序文件。

10.根据权利要求9所述的方法，其特征在于，所述方法还包括步骤：

根据所述用户相关的权限数据对所述客户端进行授权认证后，刷新使用所述客户端的用户相关的权限数据；

加密刷新后的使用所述客户端的用户相关的权限数据，并保存。

11.根据权利要求9所述的方法，其特征在于，在安装所述移动应用时，所述方法还包括步骤：

如果所述客户端通过授权认证，则根据所述解密信息解密加密的应用程序包文件，并安装解密后的应用程序包文件。

12.根据权利要求8所述的方法，其特征在于，获取所述第二密钥的过程包括：

当用户输入密码后，根据所述输入参数生成随机数；所述输入参数包括用户输入密码、登录账户、所述客户端所在设备的硬件标识中的一种或多种参数；

根据所述随机数生成第二密钥。

13.根据权利要求8所述的方法，其特征在于，获取所述第二密钥的过程包括：

当用户输入密码后，获取预先存储的所述第二密钥。

14.一种管理移动应用的装置，位于服务器端，其特征在于，包括：

应用加密模块，用于加密应用程序包文件及权限信息，所述应用程序包文件为所述移动应用的安装程序文件；所述权限信息包括使用所述客户端的用户相关的权限数据及解密信息，所述解密信息用于对加密的所述应用程序包文件进行解密；当收到客户端的下载请求时，将加密的应用程序包文件及加密的权限信息发送给所述客户端；

应用存储模块，用于将权限信息和加密/未加密的应用程序包文件在所述服务器端存储。

15.根据权利要求14所述的装置，其特征在于，所述应用加密模块收到客户端的下载请求之前还用于通过随机数算法生成随机数；根据所述随机数生成第一密钥；通过所述第一密钥加密所述应用程序包文件；

将加密后的应用程序包文件发给所述应用存储模块。

16.根据权利要求15所述的装置，其特征在于，所述解密信息包括随机数，所述随机数包括系统随机数，所述应用存储模块还用于将所述系统随机数在服务器端存储；

所述应用加密模块还用于当收到客户端的下载请求时，将所述系统随机数加密后发送给所述客户端。

17.根据权利要求15所述的装置，其特征在于，所述解密信息为第一密钥；所述随机数包括第一随机数，所述第一随机数的输入参数相同时，对于同一应用程序包文件通过同一随机数算法所获得的值相同；所述应用加密模块还用于当收到客户端的下载请求时，通过随机数算法生成第一随机数；根据第一随机数生成第一密钥；将所述第一密钥加密后发送给客户端。

18.根据权利要求15所述的装置，其特征在于，所述解密信息为第一密钥，所述应用存储模块还用于将所述第一密钥在服务器端存储；

所述应用加密模块还用于当收到客户端的下载请求时，将所述第一密钥加密后发送给所述客户端。

19.根据权利要求14所述的装置，其特征在于，所述应用加密模块对所述权限信息加密包括：

将所述解密信息和与使用所述客户端的用户相关的权限数据按照预定格式生成权限文件；

通过第二密钥将所述权限文件加密后发送给所述客户端。

20.根据权利要求19所述的装置，其特征在于，所述应用加密模块生成所述第二密钥的过程包括：

通过随机数算法生成随机数；所述随机数的输入参数包括用户输入密码、登录账户、所述客户端所在设备的硬件标识中的一种或多种参数；根据所述随机数生成第二密钥。

21.一种管理移动应用的装置，位于客户端，其特征在于，包括：

应用加密模块，用于在安装或运行所述移动应用时，获取第二密钥；利用第二密钥解密出权限信息，并发给应用权限管理模块，所述权限信息包括使用所述客户端的用户相关的权限数据；

所述应用权限管理模块，用于根据使用所述客户端的用户相关的权限数据对所述客户端进行授权认证。

22.根据权利要求21所述的装置，其特征在于，还包括应用存储模块，用于将从服务器接收的加密的应用程序包文件及加密的权限信息保存；所述权限信息还包括解密信息，所述解密信息用于对加密的应用程序包文件进行解密，所述应用程序包文件为所述移动应用的安装程序文件。

23.根据权利要求22所述的装置，其特征在于，

所述应用权限管理模块还用于根据所述用户相关的权限数据对所述客户端进行授权认证后，刷新使用所述客户端的用户相关的权限数据；

所述应用加密模块还用于加密刷新后的使用所述客户端的用户相关的权限数据，并发给所述应用存储模块保存。

24.根据权利要求21所述的装置，其特征在于，所述装置还包括执行模块，用于安装或运行所述移动应用；在安装所述移动应用时，如果所述客户端通过授权认证，所述应用加密模块根据所述解密信息解密加密的应用程序包文件，并通知所述执行模块安装解密后的应用程序包文件。

25.根据权利要求21所述的装置，其特征在于，所述应用加密模块获取所述第二密钥包括：

当用户输入密码后，根据所述输入参数生成随机数；所述输入参数包括用户输入密码、登录账户、所述客户端所在设备的硬件标识中的一种或多种参数；

根据所述随机数生成第二密钥。

26.根据权利要求22所述的装置，其特征在于，所述应用加密模块获取所述第二密钥包括：

当用户输入密码后，从所述应用存储模块获取预先存储的所述第二密钥。