CN104092544B - 兼容安卓应用的服务签名方法与装置 - Google Patents

Abstract

本发明涉及一种兼容安卓应用的服务签名方法，包括：S1：对应用程序软件包除开发者签名外的所有数据文件列出清单，并完成兼容安卓应用的服务签名操作；S2：通过使用服务自身标识证书或标识公钥对兼容安卓应用的服务签名进行验证。本发明对于同一个安卓应用程序包进行数字签名不会与应用程序的开发者签名发生冲突，进行的多方重签名得到的不同发布版本的安卓应用在更新安装时能够保留用户数据；且服务方签名数据存储在服务方域名以及业务名称相关的目录中，不同的服务方签名数据互不干扰，不同的业务签名互不影响，根本上解决了传统应用签名机制签名文件名称容易发生碰撞的问题。本发明还公开了一种兼容安卓应用的服务签名装置。

Description

兼容安卓应用的服务签名方法与装置

技术领域

本发明涉及计算机技术领域，尤其涉及一种兼容安卓应用的服务签名方法与装置。

背景技术

数字签名是基于消息摘要运算和非对称加密运算的，用于保证信息传输完整性、认证性和抗抵赖性的信息安全技术。数字签名技术在社会生活中已经得到了广泛的应用，安卓应用的数字签名就是上述技术的一个典型应用场景。

具体地，现阶段安卓应用数字签名的操作流程为：利用摘要算法将安卓应用程序包中除META-INF目录以外的每个信息文件计算成固定长度的散列值，并将散列值和对应文件名依序存储到META-INF/MANIFEST.MF文件中；继续使用摘要算法将上述META-INF/MANIFEST.MF文件以及此文件中的每个散列值再次进行散列运算，并将散列值和对应文件名依序存储到META-INF/[签名用alias名称首八个字符].SF文件中；进一步地，使用签名者的私钥对上述.SF文件进行数字签名，将签名者的证书数据连同数字签名值进行结合并编码，得到一个PKCS7格式的二进制数据包，存储在META-INF/[签名用alias名称首八个字符].RSA文件中。上述传统的安卓应用签名流程在业内通常被称为“开发者签名”，通过开发者签名处理的应用程序包，应用程序使用者可以随时从中提取签名者的数字证书，并使用此数字证书对程序包中所有文件的完整性进行验证，从而保证了应用程序包在发布中的完整性，一旦发生应用程序包中文件在发布中被篡改的情况，用户可以将篡改检测出来。但目前，使用传统的开发者签名技术对安卓应用程序包进行数字签名时，默认存放二次摘要的文件名为：META-INF/[签名用alias名称首八个字符].SF，默认存放的数字签名文件为META-INF/[签名用alias名称首八个字符].RSA。在应用程序发布流转过程中，渠道商往往需要对应用程序包进行重签名，然而这往往带来两个问题：

(1)对于同一个安卓应用程序包而言，采用了双重签名和单次签名的程序包将被安卓操作系统认为是不同的开发者发布的，将导致同一个程序的两个发布版本无法在更新安装时保留用户数据；

(2)使用传统的应用程序包开发者签名机制，如果多个签名者采用默认的密钥alias名称，如CERT，将导致在二次签名时，原签名方的数字签名被替换。例如，开发者A采用的密钥alias名称为CERT，并对应用进行了签名；渠道商采用的密钥alias也恰好使用了CERT，当渠道商对此应用进行重签名时，将导致开发者的签名被替换。另外，由于传统安卓应用签名时.SF文件和.RSA文件的命名规则是密钥alias首八个字符的大写，导致签名文件名的命名空间比较小，容易发生碰撞。

进一步地，同一个安卓应用程序往往要在多个不同的渠道进行发布，然而传统应用程序包开发者签名机制的上述缺陷将导致同一个应用的多渠道不同版本在用户手机上无法实现保留用户数据的更新安装，也容易导致开发商或渠道商的数字签名被无意识的剥离，最终必然导致安卓应用管理的混乱与用户体验的下降。

发明内容

本发明所要解决的技术问题是如何实现一种在兼容传统JAR包签名机制以及传统的安卓应用开发者签名机制的情况下保证同一个安卓应用的多渠道多重签名的不同版本能够进行保留用户数据的更新安装，以及如何实现一种支持任意数量的多方、多服务重签名，签名数据互不冲突，且均可以进行独立验证的关键问题。

为此目的，本发明提出了一种兼容安卓应用的服务签名方法，包括具体以下步骤：

S1：对应用程序软件包除开发者签名外的所有数据文件列出清单LIST，并完成兼容安卓应用的服务签名操作；

S2：通过使用服务自身标识证书或标识公钥对所述兼容安卓应用的服务签名进行验证。

进一步地，所述步骤S1进一步包括：

S11：将所述清单LIST中所有数据文件进行摘要操作得到摘要信息；

S12：将得到的所有所述摘要信息组成一个字符串MSG；

S13：通过使用服务方证书私钥对所述MSG进行数字签名，获得签名值SIG；

S14：在软件包中预先创建的META-INF目录中创建和服务方提供的预设业务名称相关的目录，并在此目录中创建服务签名文件存储所述数字签名数据SIG，并存储包含所有相关摘要的文件路径名的清单文件。

进一步地，所述步骤S14进一步包括：在软件包中的所述META-INF目录中生成一个以服务方域名中顶级域名命名的目录，即为第一目录，在所述第一目录中嵌套创建一个服务方域名倒数第二段字符串命名的目录，即为第二目录，进一步在所述第二目录中创建一个以服务方域名倒数第三段字符串命名的目录，以此类推，直至服务方域名第一段字符串为止。

进一步地，所述步骤S2进一步包括：

S21：解析应用程序包apk文件，根据自身服务方名称找到对应的服务签名文件存储目录，并从所述存储目录中找到预设业务名称对应的摘要文件清单；

S22：枚举应用程序包中META-INF目录外所有文件，检查枚举到的文件中是否存在摘要文件清单内容之外的文件，如果存在则服务签名验证失败；

S23：读取清单文件中列出的所有数据文件进行摘要操作得到摘要信息，将所有数据文件摘要信息组成一个字符串MSG；

S24：从预先创建的META-INF目录中读取服务签名文件的所述签名值SIG；

S25：通过使用业务证书，MSG、SIG三个因子进行签名验证运算，得到验证结果RESULT_VER，如果验证成功，RESULT_VER为真；否则RESULT_VER为假，服务签名验证失败。

进一步地，所述步骤S2进一步包括：枚举应用程序包中META-INF目录内部所述开发者签名文件与预设业务对应的服务签名文件之外的文件，检查枚举到的文件中是否存在读取的摘要文件清单内容之外的文件，如果存在，验证结果RESULT_CHK为假，服务签名验证失败；否则RESULT_CHK为真，服务签名验证成功。

为此目的，本发明还提出了一种兼容安卓应用的服务签名装置，包括：

服务数字签名模块，用于对应用程序软件包除开发者签名外的所有数据文件列出清单LIST，并完成兼容安卓应用的服务签名操作；

服务签名验证模块，用于通过使用服务自身标识证书或标识公钥对所述兼容安卓应用的服务签名进行验证。

进一步地，所述服务数字签名模块包括：

第一摘要操作单元，用于将所述清单LIST中所有数据文件进行摘要操作得到摘要信息；

第一组串单元，用于将得到的所有所述摘要信息组成一个字符串MSG；

第一签名值获取单元，用于通过使用服务方证书私钥对所述MSG进行数字签名，获得签名值SIG；

存储单元，用于在软件包中预先创建的META-INF目录中创建和服务方提供的预设业务名称相关的目录，并在此目录中创建服务签名文件存储所述数字签名数据SIG，并存储包含所有相关摘要的文件路径名的清单文件。

进一步地，所述服务签名验证模块包括：

解析单元，用于解析应用程序包apk文件，根据自身服务方名称找到对应的服务签名文件存储目录，并从所述存储目录中找到预设业务名称对应的摘要文件清单；

枚举检查单元，用于枚举应用程序包中META-INF目录外所有文件，检查枚举到的文件中是否存在摘要文件清单内容之外的文件，如果存在则服务签名验证失败；

第二摘要操作单元，用于读取清单文件中列出的所有数据文件进行摘要操作得到摘要信息；

第二组串单元，用于将所有数据文件摘要信息组成一个字符串MSG；

第二签名值获取单元，用于从预先创建的META-INF目录中读取服务签名文件的所述签名值SIG；

验证单元，用于通过使用业务证书，MSG、SIG三个因子进行签名验证运算，得到验证结果RESULT_VER，如果验证成功，RESULT_VER为真；否则RESULT_VER为假，服务签名验证失败。

进一步地，所述验证单元，还用于枚举应用程序包中META-INF目录内部所述开发者签名文件与预设业务对应的服务签名文件之外的文件，检查枚举到的文件中是否存在读取的摘要文件清单内容之外的文件，如果存在，验证结果RESULT_CHK为假，服务签名验证失败；否则RESULT_CHK为真，服务签名验证成功。

通过采用本发明所公开一种兼容安卓应用的服务签名方法，将在兼容传统JAR包签名机制以及传统的安卓应用开发者签名机制的情况下保证同一个安卓应用的多渠道多重签名的不同版本能够进行保留用户数据的更新安装，同时还将支持任意数量的多方，多服务重签名，签名数据互不冲突，且均可以进行独立验证。本发明还公开了一种兼容安卓应用的服务签名装置。

附图说明

通过参考附图会更加清楚的理解本发明的特征和优点，附图是示意性的而不应理解为对本发明进行任何限制，在附图中：

图1示出了本发明实施例中的一种兼容安卓应用的服务签名方法的步骤流程图；

图2示出了本发明实施例中的一种兼容安卓应用的服务签名方法中的一个应用程序包经过业务签名后的目录情况；

图3示出了本发明实施例中的一种兼容安卓应用的服务签名装置的结构示意图；

图4示出了本发明实施例中的一种兼容安卓应用的服务签名装置中多个业务调用服务数字签名模块进行重签名的过程。

具体实施方式

下面将结合附图对本发明的实施例进行详细描述。

如图1所示，本发明提供了一种兼容安卓应用的服务签名方法，包括具体以下步骤：

步骤S1：对应用程序软件包除开发者签名外的所有数据文件列出清单LIST，并完成兼容安卓应用的服务签名操作。其中，开发者签名的数据文件包括：.MF文件、.SF文件和.RSA文件。

具体地，步骤S1进一步包括：

步骤S11：将清单LIST中所有数据文件进行摘要操作得到摘要信息。

步骤S12：将得到的所有摘要信息组成一个字符串MSG。

步骤S13：通过使用服务方证书私钥对MSG进行数字签名，获得签名值SIG。

步骤S14：在软件包中预先创建的META-INF目录中创建和服务方提供的预设业务名称相关的目录，并在此目录中创建服务签名文件存储数字签名数据SIG，并存储包含所有相关摘要的文件路径名的清单文件。

进一步地，步骤S14进一步包括：在软件包中的META-INF目录中生成一个以服务方域名中顶级域名命名的目录，即为第一目录，在第一目录中嵌套创建一个服务方域名倒数第二段字符串命名的目录，即为第二目录，进一步在第二目录中创建一个以服务方域名倒数第三段字符串命名的目录，以此类推，直至服务方域名第一段字符串为止。其中，具体的一个应用程序包经过业务签名后的目录情况如图2所示。

步骤S2：通过使用服务自身标识证书或标识公钥对兼容安卓应用的服务签名进行验证。

具体地，所述步骤S2进一步包括：

步骤S21：解析应用程序包apk文件，根据自身服务方名称找到对应的服务签名文件存储目录，并从存储目录中找到预设业务名称对应的摘要文件清单。

步骤S22：枚举应用程序包中META-INF目录外所有文件，检查枚举到的文件中是否存在摘要文件清单内容之外的文件，如果存在则服务签名验证失败；

步骤S23：读取清单文件中列出的所有数据文件进行摘要，将所有数据文件摘要信息组成一个字符串MSG。

步骤S24：从预先创建的META-INF目录中读取服务签名文件的签名值SIG。

步骤S25：通过使用业务证书，MSG、SIG三个因子进行签名验证运算，得到验证结果RESULT_VER，如果验证成功，RESULT_VER为真；否则RESULT_VER为假，服务签名验证失败。

进一步地，当进行服务签名验证操作的所述预设业务为最后一次进行服务签名操作的业务时，步骤S2进一步包括：枚举应用程序包中META-INF目录内部所述开发者签名文件与预设业务对应的服务签名文件之外的文件，检查枚举到的文件中是否存在读取的摘要文件清单内容之外的文件，如果存在，验证结果RESULT_CHK为假，服务签名验证失败；否则RESULT_CHK为真，服务签名验证成功。

本发明提供的一种兼容安卓应用的服务签名方法对应用程序进行签名，具有以下突出的优点：首先，对于同一个安卓应用程序包，使用本技术进行数字签名不会与应用程序的开发者签名发生任何冲突，采用本技术进行的多方重签名得到的不同发布版本的安卓应用在更新安装时能够保留用户数据；其次，服务方签名数据存储在服务方域名以及业务名称相关的目录中，不同的服务方签名数据互不干扰，不同的业务签名互不影响，签名文件命名空间无限制，根本上解决了传统应用签名机制签名文件名称容易发生碰撞的问题；再次，服务方的应用签名与业务签名均可以独立进行验证，互不影响，并具有和传统应用签名机制等同的完整性和认证性安全，且当进行服务签名验证操作的业务为最后一次进行服务签名操作的业务时，对RESULT_CHK进行验证的增强的验证模式将保证检测出对软件包的任何形式的篡改，包括检测出对META-INF目录内除开发者签名文件之外的任何篡改。

如图3所示，本发明提供了一种兼容安卓应用的服务签名装置10，包括：服务数字签名模块101以及服务签名验证模块102。

具体地，结合图4所示的多个业务调用服务数字签名模块101进行签名的过程，服务数字签名模块101用于对应用程序软件包除开发者签名外的所有数据文件列出清单LIST，并完成兼容安卓应用的服务签名操作；服务签名验证模块102用于通过使用服务自身标识证书或标识公钥对兼容安卓应用的服务签名进行验证。其中，开发者签名的数据文件包括：.MF文件、.SF文件和.RSA文件。

进一步地，服务数字签名模块101包括：第一摘要操作单元，用于将清单LIST中所有数据文件进行摘要操作得到摘要信息；第一组串单元，用于将得到的所有摘要信息组成一个字符串MSG；第一签名值获取单元，用于通过使用服务方证书私钥对MSG进行数字签名，获得签名值SIG；存储单元，用于在软件包中预先创建的META-INF目录中创建和服务方提供的预设业务名称相关的目录，并在此目录中创建服务签名文件存储数字签名数据SIG，并存储包含所有相关摘要的文件路径名的清单文件。

进一步地，服务签名验证模块102包括：解析单元，用于解析应用程序包apk文件，根据自身服务方名称找到对应的服务签名文件存储目录，并从存储目录中找到预设业务名称对应的摘要文件清单；枚举检查单元，用于枚举应用程序包中META-INF目录外所有文件，检查枚举到的文件中是否存在摘要文件清单内容之外的文件，如果存在则服务签名验证失败；第二摘要操作单元，用于读取清单文件中列出的所有数据文件进行摘要操作得到摘要信息；第二组串单元，用于将所有数据文件摘要信息组成一个字符串MSG；第二签名值获取单元，用于从预先创建的META-INF目录中读取服务签名文件的所述签名值SIG；验证单元，用于通过使用业务证书，MSG、SIG三个因子进行签名验证运算，得到验证结果RESULT_VER，如果验证成功，RESULT_VER为真；否则RESULT_VER为假，服务签名验证失败。

更进一步地，验证单元，当进行服务签名验证操作的所述预设业务为最后一次进行服务签名操作的业务时，还用于枚举应用程序包中META-INF目录内部所述开发者签名文件与预设业务对应的服务签名文件之外的文件，检查枚举到的文件中是否存在读取的摘要文件清单内容之外的文件，如果存在，验证结果RESULT_CHK为假，服务签名验证失败；否则RESULT_CHK为真，服务签名验证成功。

为了更好的理解与应用本发明公开了一种兼容安卓应用的服务签名方法与装置，进行以下实施例示意，且本发明不仅局限于下述所列举的实施例。

实施例1

假定服务方某业务的私钥为prikey，业务证书为cert，服务方域名为www.cstc.org.cn，服务的业务名称为“应用加固”，对应拼音缩写为YYJG，待签名应用程序包sample.apk的结构如下：

sample.apk

其中，应用程序包sample.apk中根目录中有三个文件AndroidManifest.xml、resources.arsc、classes.dex和三个目录：assets、META-INF、res，目录META-INF中有四个文件MANIFEST.MF、CERT.SF、CERT.RSA、others.plus，目录res中有一个文件resource.xml。

具体地，服务签名的流程即为：首先，枚举apk应用包中除开发者签名文件，即.MF文件、.SF文件以及.RSA文件之外的所有文件，并得到待摘要的数据文件清单LIST：

MSG＝hash(AndroidManifest.xml)||hash(resources.arsc)||hash(classes.dex)||hash(res/resource.xml)||hash(META-INF/others.plus)，其中hash 为摘要(或称散列)运算，’||’代表字符串连接；SIG＝signature(prikey,MSG)，其中prikey为服务签名私钥，signature为签名运算，签名值SIG为对MSG使用服务方的业务签名私钥做数字签名操作后的结果；在META-INF中创建多级目录CN/ORG/CSTC/WWW，并在其中创建服务的业务名称缩写名文件YYJG，即“应用加固”的汉语拼音缩写，将SIG数据存储于YYJG文件中，并在此目录创建文件YYJG.list存储LIST数据。

如果此域名对应的服务提供商还提供“应用加固”服务之外的其他服务，如“渠道监测”，则“渠道监测”业务也可以为此应用程序包做服务签名，则META-INF/CN/ORG/CSTC/WWW中还将增加一个签名文件和清单文件，即QDJC，(“渠道监测”的汉语拼音缩写)文件与QDJC.list，以此类推。

假定应用程序包接受了业务“应用加固”和“渠道监测”的服务签名后未经篡改，且“渠道监测”的服务为最后一次对此应用程序包进行服务签名操作的业务，则经过服务签名后的应用程序包sample_signed.apk结构为：

sample_signed.apk

假定“应用加固”业务的服务签名在先，“渠道监测”业务的服务签名在后，则YYJG.list文件内容为：

QDJC.list文件内容为：

服务签名的验证流程即为：假定渠道监测业务对其服务签名进行验证，采用如下所述验证步骤，假定应用程序包发布后未经篡改：首先，渠道监测业务的服务签名验证模块解析应用程序包apk文件，找到对应的服务签名文件存储目录META-INF/CN/ORG/CSTC/WWW/，并从此目录中找到摘要文件清单QDJC.list；其次，枚举应用程序包中META-INF目录外所有文件，检查枚举到的文件中是否存在摘要文件清单内容之外的文件，由于应用未受到篡改，所以在此未发现这类文件；再次，读取清单文件中列出的所有数据文件并进行摘要，将所有数据文件摘要信息组成一个字符串MSG；再次，从上述目录中读取签名文件QDJC中的签名值SIG；使用业务证书、MSG、SIG三个因子进行签名验证运算，因为应用未经篡改，得到验证结果RESULT_VER为真；最后，枚举META-INF目录内开发者签名文件以及服务签名文件之外的所有文件，检查是否存在摘要清单中不存在的文件，在此例中未找到此类文件，RESULT_CHK为真，服务签名验证成功。

实施例2

采用实例1对应用的做过服务签名处理后，假定应用程序包发布后受到篡改，asset目录中增加了一个文件bug.file，假定渠道监测业务对其服务签名进行验证，验证过程为：渠道监测业务的服务签名验证模块解析应用程序包apk文件，找到对应的服务签名文件存储目录META-INF/CN/ORG/CSTC/WWW/，并从此目录中找到摘要文件清单QDJC.list；其次，枚举应用程序包中META-INF目录外所有文件，检查枚举到的文件中是否存在摘要文件清单内容之外的文件，由于应用受到篡改，检查到asset目录中增加了一个文件bug.file，服务签名验证失败；

实施例3

采用实例1对应用的做过服务签名处理后，假定应用程序包发布后受到篡改，META-INF目录中增加了一个文件bug.file，假定渠道监测业务对其服务签名进行验证，验证过程为：渠道监测业务的服务签名验证模块解析应用程序包apk文件，找到对应的服务签名文件存储目录META-INF/CN/ORG/CSTC/WWW/，并从此目录中找到摘要文件清单QDJC.list；首先，枚举应用程序包中META-INF目录外所有文件，检查枚举到的文件中是否存在摘要文件清单内容之外的文件，在此未发现此类文件；其次，读取清单文件中列出的所有数据文件并进行摘要，将所有数据文件摘要信息组成一个字符串MSG；其次，从上述目录中读取签名文件QDJC中的签名值SIG；再次，使用业务证书、MSG、SIG三个因子进行签名验证运算，得到验证结果RESULT_VER为真，最后，枚举META-INF目录内开发者签名文件，即.MF文件、.SF文件、.RSA文件与本业务对应的服务签名文件之外的所有文件，检查是否存在摘要清单中不存在的文件，在此例中找到META-INF目录中增加了一个文件bug.file，RESULT_CHK为假，服务签名验证失败。

通过采用本发明所公开一种兼容安卓应用的服务签名方法，将在兼容传统JAR包签名机制以及传统的安卓应用开发者签名机制的情况下保证同一个安卓应用的多渠道多重签名的不同版本能够进行保留用户数据的更新安装，同时还将支持任意数量的多方，多服务重签名，签名数据互不冲突，且均可以进行独立验证。本发明还公开了一种兼容安卓应用的服务签名装置。

虽然结合附图描述了本发明的实施方式，但是本领域技术人员可以在不脱离本发明的精神和范围的情况下做出各种修改和变型，这样的修改和变型均落入由所附权利要求所限定的范围之内。

Claims (6)

1.一种兼容安卓应用的服务签名方法，其特征在于，包括具体以下步骤：

S1：对应用程序软件包除开发者签名外的所有数据文件列出清单LIST，并完成兼容安卓应用的服务签名操作；

S2：通过使用服务自身标识证书或标识公钥对所述兼容安卓应用的服务签名进行验证；

其中，所述步骤S1进一步包括：

S11：将所述清单LIST中所有数据文件进行摘要操作得到摘要信息；

S12：将得到的所有所述摘要信息组成一个字符串MSG；

S13：通过使用服务方证书私钥对所述MSG进行数字签名，获得签名值SIG；

S14：在软件包中预先创建的META-INF目录中创建和服务方提供的预设业务名称相关的目录，并在此目录中创建服务签名文件存储所述签名值SIG，并存储包含所有相关摘要的文件路径名的清单文件。

2.如权利要求1所述的方法，其特征在于，所述步骤S14进一步包括：在软件包中的所述META-INF目录中生成一个以服务方域名中顶级域名命名的目录，即为第一目录，在所述第一目录中嵌套创建一个服务方域名倒数第二段字符串命名的目录，即为第二目录，进一步在所述第二目录中创建一个以服务方域名倒数第三段字符串命名的目录，以此类推，直至服务方域名第一段字符串为止。

3.如权利要求1所述的方法，其特征在于，所述步骤S2进一步包括：

S21：解析应用程序包apk文件，根据自身服务方名称找到对应的服务签名文件存储目录，并从所述存储目录中找到预设业务名称对应的摘要文件清单；

S22：枚举应用程序包中META-INF目录外所有文件，检查枚举到的文件中是否存在摘要文件清单内容之外的文件，如果存在则服务签名验证失败；

S23：读取清单文件中列出的所有数据文件进行摘要操作得到摘要信息，将所有数据文件摘要信息组成一个字符串MSG；

S24：从预先创建的META-INF目录中读取服务签名文件的所述签名值SIG；

S25：通过使用业务证书，MSG、SIG三个因子进行签名验证运算，得到验证结果RESULT_VER，如果验证成功，RESULT_VER为真；否则RESULT_VER为假，服务签名验证失败。

4.如权利要求1所述的方法，其特征在于，所述步骤S2进一步包括：枚举应用程序包中META-INF目录内部所述开发者签名文件与预设业务对应的服务签名文件之外的文件，检查枚举到的文件中是否存在读取的摘要文件清单内容之外的文件，如果存在，验证结果RESULT_CHK为假，服务签名验证失败；否则RESULT_CHK为真，服务签名验证成功。

5.一种兼容安卓应用的服务签名装置，其特征在于，包括：

服务数字签名模块，用于对应用程序软件包除开发者签名外的所有数据文件列出清单LIST，并完成兼容安卓应用的服务签名操作；

服务签名验证模块，用于通过使用服务自身标识证书或标识公钥对所述兼容安卓应用的服务签名进行验证；

其中，所述服务数字签名模块包括：

第一摘要操作单元，用于将所述清单LIST中所有数据文件进行摘要操作得到摘要信息；

第一组串单元，用于将得到的所有所述摘要信息组成一个字符串MSG；

第一签名值获取单元，用于通过使用服务方证书私钥对所述MSG进行数字签名，获得签名值SIG；

存储单元，用于在软件包中预先创建的META-INF目录中创建和服务方提供的预设业务名称相关的目录，并在此目录中创建服务签名文件存储所述签名值SIG，并存储包含所有相关摘要的文件路径名的清单文件。

6.如权利要求5所述的装置，其特征在于，所述服务签名验证模块包括：

解析单元，用于解析应用程序包apk文件，根据自身服务方名称找到对应的服务签名文件存储目录，并从所述存储目录中找到预设业务名称对应的摘要文件清单；

枚举检查单元，用于枚举应用程序包中META-INF目录外所有文件，检查枚举到的文件中是否存在摘要文件清单内容之外的文件，如果存在则服务签名验证失败；

第二摘要操作单元，用于读取清单文件中列出的所有数据文件进行摘要操作得到摘要信息；

第二组串单元，用于将所有数据文件摘要信息组成一个字符串MSG；

第二签名值获取单元，用于从预先创建的META-INF目录中读取服务签名文件的所述签名值SIG；

验证单元，用于通过使用业务证书，MSG、SIG三个因子进行签名验证运算，得到验证结果RESULT_VER，如果验证成功，RESULT_VER为真；否则RESULT_VER为假，服务签名验证失败。