多签名机制下的应用安装管理方法、智能终端及存储介质与流程

本发明涉及互联网信息安全技术领域，具体涉及一种多签名机制下的应用安装管理方法、智能终端及存储介质。

背景技术：

签名机制是android系统重要的安全机制之一，具有同样uid的应用需要有相同的签名，来保证进程数据共享的安全性。系统权限是android系统中权力非常大的权限，可以和android系统的核心服务共享进程，访问系统核心的资源。一个应用要获取系统权限必须同时满足以下条件：定义uid为system，android:shareduserid=android.uid.system；使用系统签名。

现有的android系统大多只有一个系统签名，它的私钥通常是开发者公司的内部机密文件，只能给开发者公司内部应用使用，第三方应用要使用系统权限时，需要把应用发送给开发者公司帮忙签名集成验证。对于需要频繁使用系统权限的的情况来说，验证流程是非常繁琐的，不方便第三方应用使用。

因此，现有技术还有待于改进和发展。

技术实现要素：

本发明要解决的技术问题在于，针对现有技术的上述缺陷，提供一种多签名机制下的应用安装管理方法、智能终端及存储介质，旨在解决现有技术中第三方系统应用在需要使用系统权限时的验证流程繁琐等问题。

本发明解决技术问题所采用的技术方案如下：

一种多签名机制下的应用安装管理方法，其中，所述方法包括：

预先对android系统中的android原生apk进行多次签名；

android系统首次启动时，控制系统中的pms服务扫描android原生apk，并获取android原生apk的签名信息；

当所述pms服务继续扫描到第三方系统应用处于安装时，则获取正在进行安装的第三方系统应用的签名信息，并将正在进行安装的第三方系统应用的签名信息与android原生apk的签名信息进行对比验证；

当正在进行安装的第三方系统应用与android原生apk的签名信息中，存在任何一个system签名相同时，则安装验证通过，控制正在进行安装的第三方系统应用完成安装操作。

所述的多签名机制下的应用安装管理方法，其中，所述预先对android系统中的android原生apk进行多次签名的步骤，包括：

预先对android系统中的framework-res.apk进行多次签名；

或者，预先在android系统中定义元应用，分别采用多个系统签名来对所述元应用进行签名。

所述的多签名机制下的应用安装管理方法，其中，所述预先对android系统中的framework-res.apk进行多次签名的步骤，包括：

对所述framework-res.apk中的所有文件内容进行hash计算，并将计算结果以base64编码格式保存在manifest.mf中；

使用不同的开发者的私钥对manifest.mf进行加密，将加密结果保存在cert.sf中；

将cert.rsa、manifest.mf以及cert.sf放入framework-res.apk的meta-inf目录下。

所述的多签名机制下的应用安装管理方法，其中，所述预先在android系统中定义元应用，分别采用多个系统签名来对所述元应用进行签名的步骤，包括：

预先在android系统中定义元应用，将所述元应用放在特定的目录下，并使用framework-res.apk的文件名之前的字符来对所述元应用进行命名；

采用不同的开发者的私钥对元应用进行签名，生成各自的cert.sf和cert.rsa，并集成在系统的预设的目录下。

所述的多签名机制下的应用安装管理方法，其中，所述android系统首次启动时，控制系统中的pms服务扫描android原生apk，并获取android原生apk的签名信息的步骤，包括：

所述android系统首次启动时，启动系统中的pms服务；

pms服务首先扫描到/system/framework目录下的framework-res.apk，并控制framework-res.apk安装；

在安装的过程中记录framework-res.apk的签名信息，并获取到framework-res.apk的uid为system；

依次读取多个cert.rsa中的公钥信息，并将读取的公钥信息和uid为system的这个属性值对应并记录。

所述的多签名机制下的应用安装管理方法，其中，所述android系统首次启动时，控制系统中的pms服务扫描android原生apk，并获取android原生apk的签名信息的步骤，还包括：

当android系统首次启动时，控制系统中的pms服务扫描预先定义的元应用的路径；

依次记录每一个元应用的签名信息，并获取到元应用的uid为system；

依次从cert.rsa中读取各自的公钥信息，并将读取出的公钥信息和uid为system的这个属性值对应并记录。

所述的多签名机制下的应用安装管理方法，其中，所述当所述pms服务继续扫描到第三方系统应用处于安装时，则获取正在进行安装的第三方系统应用的签名信息，并将正在进行安装的第三方系统应用的签名信息与android原生apk的签名信息进行对比验证的步骤，包括：

当所述pms服务继续扫描到第三方系统应用处于安装时，获取正在进行安装的第三方系统应用的签名信息；

从正在进行安装的第三方系统应用的签名信息的cert.rsa中读取公钥信息，同时读取正在进行安装的第三方系统应用的uid；

当uid为system时，则从android原生apk的签名信息中的cert.rsa中读取公钥信息；

将正在进行安装的第三方系统应用的公钥信息与android原生apk的公钥信息进行对比验证。

所述的多签名机制下的应用安装管理方法，其中，所述当正在进行安装的第三方系统应用与android原生apk的签名信息中，存在任何一个system签名相同时，则安装验证通过，控制正在进行安装的第三方系统应用完成安装操作的步骤，包括：

将正在进行安装的第三方系统应用的公钥信息与android原生apk的公钥信息进行对比；

当正在进行安装的第三方系统应用的公钥信息与android原生apk的公钥信息中，存在任何一个system签名相同时，则说明满足验证条件；

控制正在进行安装的第三方系统应用完成安装操作。

一种存储介质，其上存储有多条指令，其中，所述指令适于由处理器加载并执行，以执行实现上述任一项所述的多签名机制下的应用安装管理方法的步骤。

一种智能终端，其中，包括：处理器、与处理器通信连接的存储介质，所述存储介质适于存储多条指令；所述处理器适于调用所述存储介质中的指令，以执行实现上述任一项所述的多签名机制下的应用安装管理方法的步骤。

本发明的有益效果：本发明通过对android系统中的android原生apk进行多次签名，使系统支持多个系统签名，并在第三方系统应用安装时将其签名信息与原生apk中的签名信息进行对比，只要存在任何一个system签名相同就可以完成安装，有效简化了第三方系统应用在需要使用系统权限时的验证流程，方便第三方系统应用安装。

附图说明

图1是本发明的多签名机制下的应用安装管理方法的较佳实施例的流程图。

图2是本发明的多签名机制下的应用安装管理方法的第一种具体应用实施例的流程图。

图3是本发明的多签名机制下的应用安装管理方法的第二种具体应用实施例的流程图。

图4是本发明的智能终端的功能原理图。

具体实施方式

为使本发明的目的、技术方案及优点更加清楚、明确，以下参照附图并举实施例对本发明进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。以下对至少一个示例性实施例的描述实际上仅仅是说明性的，决不作为对本发明及其系统应用或使用的任何限制。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明提供的多签名机制下的应用安装管理方法，可以系统应用于终端中。其中，终端可以但不限于是各种个人计算机、笔记本电脑、手机、平板电脑、车载电脑和便携式可穿戴设备。本发明的终端采用多核处理器。其中，终端的处理器可以为中央处理器（centralprocessingunit，cpu），图形处理器（graphicsprocessingunit，gpu）、视频处理单元（videoprocessingunit，vpu）等中的至少一种。

本发明提供一种多签名机制下的应用安装管理方法，具体如图1所示，所述方法包括：

步骤s100、预先对android系统中的android原生apk进行多次签名。

本实施例中的智能终端为搭载了android系统的智能终端，现有的android系统对于第三方系统应用使用系统权限的校验机制如下：android系统在第一次启动的时候，packagemanagerservice（简称pms服务）会依次扫描安装各个应用，对于第一个扫描到的uid（useridentification）为system的应用，会记录它的签名信息，之后再扫描到uid为system签名的第三方系统应用，会和这个签名信息进行对比，如果不一致，则安装失败，以此实现对第三方系统应用在使用系统权限的管控。而由于现有的android系统中只有一个系统签名，因此每一个第三方系统应用都只能和这个系统签名来进行对比验证，而它的私钥通常是开发者公司的内部机密文件，只能给开发者公司内部应用使用，第三方应用在需要使用系统权限时，把应用发送给开发者公司帮忙签名集成验证，整个过程都是非常繁琐的，不利于第三方系统应用的使用。因此，为了解决该问题，本实施例预先对android系统的原生apk进行多次签名，使得原生apk中具有多个签名信息，以便后续步骤中第三方系统应用在安装时可以将自身的签名信息和设置在原生apk中的多个签名信息进行对比，只要有相同的签名信息就可以满足安装验证要求，提高安装效率。

具体地，本实施例中对android系统的原生apk进行多次签名是包括有两种方式的，第一种是预先对android系统中的framework-res.apk进行多次签名；第二种是预先在android系统中定义元应用，分别采用多个系统签名来对所述元应用进行签名。这两种签名的方式都是为了使android系统支持多个系统签名，从而使得第三方系统应用在安装时可以更加容易验证，简化验证流程，提高第三方系统应用的安装效率。

进一步地，本实施例对上述两种方式均进行具体的说明。当采用第一种方式时，由于android系统在第一次启动之后，packagemanagerservice（简称pms服务）会依次扫描安装各个应用，而位于/system/framework的framework-res.apk是第一个扫描到的系统权限的应用，它的签名信息是之后所有第三方系统应用安装时的权限签名的校验标准。因此，为了使得第三方系统应用在安装时与framework-res.apk进行签名信息对比验证时，能够验证成功，本实施例首先需要对framework-res.apk进行多次签名，以使framework-res.apk中包含多个签名信息。签名的具体步骤包括：首先需要对所述framework-res.apk中的所有文件内容进行hash计算，并将计算结果以base64编码格式保存在manifest.mf文件中。然后使用不同的开发者的私钥对manifest.mf进行加密，将加密结果保存在cert.sf中，最后将cert.rsa（证书信息中包括公钥信息）、manifest.mf以及cert.sf放入framework-res.apk的meta-inf目录下，以此完成一次签名。本实施例中的多次签名就是使用不同开发者的私钥分别对上述manifest.mf进行加密，生成不同的cert.sf和cert.rsa，每进行一次签名，就会生成一组cert.sf和cert.rsa，有多少组签名，就会生成多少组cert.sf和cert.rsa。比如经过多次签名后，生成了cert1.sf和cert1.rsa，cert2.sf和cert2.rsa……

而当采用上述第二种方式时，本实施例中预先在android系统中定义元应用，有几个系统签名就定义几个，这些元应用自身没有实现功能，只是携带签名信息，然后分别使用各个系统签名对这些元应用进行签名，从而使得的这些元应用的签名信息中包含多个系统签名。具体地，为了保证pms服务在扫描系统应用时可以首先扫描到元应用，因此本实施例中将所述元应用放在/system/framework目录下，并使用framework-res.apk的文件名之前的字符来对所述元应用进行命名；或者预先指定一个目录，并控制pms服务第一个对该目录进行扫描。当pms服务扫描到元应用之后，采用不同的开发者的私钥对元应用进行签名，生成各自的cert.sf和cert.rsa，并集成在系统的预设的目录下，这样就使得元应用的签名信息中包含了多个系统签名。

进一步地，步骤s200、android系统首次启动时，控制系统中的pms服务扫描android原生apk，并获取android原生apk的签名信息。

具体实施时，由于在上述步骤s100中提供了两种对android系统中的原生apk进行多次签名的方式，并且当pms服务在扫描安装应用时，两种方式中获取android原生apk的签名信息方式也是不一样的，具体如下：

对于上述第一种方式（即对android系统中的framework-res.apk进行多次签名），本实施例中在android系统首次启动时，启动系统中的pms服务；pms服务就会首先扫描到/system/framework目录下的framework-res.apk，然后控制framework-res.apk安装。本实施例在安装的过程中会记录framework-res.apk的签名信息，并获取到framework-res.apk的uid为system（即uid=system）；再依次从签名信息中的多个cert.rsa中读取公钥信息，并将读取的公钥信息和uid为system的这个属性值对应并记录，从而将framework-res.apk的签名信息中的公钥信息与uid=system关联起来。

而对于上述第二种方式（即在android系统中定义元应用，分别采用多个系统签名来对所述元应用进行签名），本实施例中当android系统首次启动时，控制系统中的pms服务扫描预先定义的元应用的路径；依次记录每一个元应用的签名信息，并获取到元应用的uid为system（即uid=system）；然后依次从签名信息的多个cert.rsa中读取各自的公钥信息，并将读取出的公钥信息和uid为system的这个属性值对应并记录，从而将元应用的签名信息中的公钥信息与uid=system关联起来。

进一步地，步骤s300、当所述pms服务继续扫描到第三方系统应用处于安装时，则获取正在进行安装的第三方系统应用的签名信息，并将正在进行安装的第三方系统应用的签名信息与android原生apk的签名信息进行对比验证。

具体实施时，当所述pms服务继续扫描到第三方系统应用（即第三方系统应用）处于安装时，获取正在进行安装的第三方系统应用的签名信息；从正在进行安装的第三方系统应用的签名信息的cert.rsa中读取公钥信息，同时读取正在进行安装的第三方系统应用的uid；当uid为system时（即uid=system），则根据uid=system从android原生apk的签名信息中的cert.rsa中读取到对应的公钥信息；将正在进行安装的第三方系统应用的公钥信息与android原生apk的公钥信息进行对比验证。值得说明的是，在此步骤中，根据uid=system从android原生apk的签名信息中的cert.rsa中读取到对应的公钥信息可以包括上述两种方式的，包括：根据uid=system从framework-res.apk的签名信息中的cert.rsa中读取到对应的公钥信息，也可以是根据uid=system从定义的元应用的签名信息中的cert.rsa中读取到对应的公钥信息。

进一步地，步骤s400、当正在进行安装的第三方系统应用与android原生apk的签名信息中，存在任何一个system签名相同时，则安装验证通过，控制正在进行安装的第三方系统应用完成安装操作。

具体实施时，当通过对比后发现，若当正在进行安装的第三方系统应用的公钥信息与android原生apk的公钥信息中，存在任何一个system签名相同时，则说明该系统应用满足验证条件；控制正在进行安装的第三方系统应用完成安装操作。而当两者的公钥信息中不存在任何相同的system签名时，则验证不成功，该系统应用安装失败。由于本实施例中的android中支持多个系统签名，并且设置的验证条件为：只要第三方系统应用的签名信息与android中的签名信息存在任何一个相同的系统签名时就认为是验证成功，这也就大大提高了第三方系统应用验证通过的概率，提高了安装效率。并且相对于现有的安装验证，本实施例中无需使用开发者私钥进行验证，并且也无需将第三方系统应用发送至开发者公司进行签名集成，大大简化了验证流程，给第三方系统应用的安装验证提供了便利。

此外，进一步地，本实施例中还在安装后进行完整性校验，具体包括：使用获取到的android原生apk的公钥对安装的第三方系统应用的cert.sf解密，将解密结果和android原生apk的manifest.mf进行比较，如果相同说明cert.rsa有效、manifest.mf未被更改。此外，本实施例还对安装的第三方系统应用中所有文件内容分别进行hash计算，将计算结果的base64编码和android原生apk的manifest.mf里的相应内容进行比较，全部相同则安装的第三方系统应用的内容未被更改，从而保证第三方系统应用的完整性。

基于上述实施例，本发明还提供两种具体应用的实施例，具体如图2和图3所示，其中图2为采用上述第一种方式的具体实施例，图3是采用上述第二种方式的具体实施例。具体如图2所示，在本实施例中，具体包括如下步骤：

步骤s201、android系统启动，启动pms服务；

步骤s202、pms服务首先扫描到/system/framework/中的framework-res.apk；

步骤s203、记录framework-res.apk中的多个签名信息；

步骤s204、依次扫描其他uid为system的第三方系统应用，获取其签名信息；

步骤s205、依次比较签名信息中的系统签名；

步骤s206、是否存在相同的系统签，若是，则执行步骤s207，若否，则重复执行步骤s205，若系统签名全不相同，则执行步骤s209；

步骤s207、验证成功；

步骤s208、扫描完成，完成安装；

步骤s209、验证失败。

图3中的第二种的具体应用实施例具体包括如下步骤：

步骤s301、android系统启动，启动pms服务；

步骤s302、pms服务首先扫描到指定目录中的元应用；

步骤s203、依次记录每个元应用的签名信息；

步骤s204、依次扫描其他uid为system的第三方系统应用，获取其签名信息；

步骤s205、依次比较签名信息中的系统签名；

步骤s206、是否存在相同的系统签，若是，则执行步骤s207，若否，则重复执行步骤s205，若系统签名全不相同，则执行步骤s209；

步骤s207、验证成功；

步骤s208、扫描完成，完成安装；

步骤s209、验证失败。

基于上述实施例，本发明还提供了一种智能终端，其原理框图可以如图4所示。该智能终端包括通过系统总线连接的处理器、存储器、网络接口、显示屏和温度传感器。其中，该智能终端的处理器用于提供计算和控制能力。该智能终端的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统和计算机程序。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该智能终端的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种多签名机制下的应用安装管理方法。该智能终端的显示屏可以是液晶显示屏或者电子墨水显示屏，该智能终端的温度传感器是预先在智能终端内部设置，用于检测内部设备的当前运行温度。

本领域技术人员可以理解，图4中示出的原理框图，仅仅是与本发明方案相关的部分结构的框图，并不构成对本发明方案所系统应用于其上的智能终端的限定，具体的智能终端可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

在一个实施例中，提供了一种智能终端，包括存储器和处理器，存储器中存储有计算机程序，该处理器执行计算机程序时至少可以实现以下步骤：

预先对android系统中的android原生apk进行多次签名；

android系统首次启动时，控制系统中的pms服务扫描android原生apk，并获取android原生apk的签名信息；

当所述pms服务继续扫描到第三方系统应用处于安装时，则获取正在进行安装的第三方系统应用的签名信息，并将正在进行安装的第三方系统应用的签名信息与android原生apk的签名信息进行对比验证；

当正在进行安装的第三方系统应用与android原生apk的签名信息中，存在任何一个system签名相同时，则安装验证通过，控制正在进行安装的第三方系统应用完成安装操作。

在其中的一个实施例中，该处理器执行计算机程序时还可以实现：预先对android系统中的framework-res.apk进行多次签名；或者，预先在android系统中定义元应用，分别采用多个系统签名来对所述元应用进行签名。

在其中的一个实施例中，该处理器执行计算机程序时还可以实现：对所述framework-res.apk中的所有文件内容进行hash计算，并将计算结果以base64编码格式保存在manifest.mf中；使用不同的开发者的私钥对manifest.mf进行加密，将加密结果保存在cert.sf中；将cert.rsa、manifest.mf以及cert.sf放入framework-res.apk的meta-inf目录下。

在其中的一个实施例中，该处理器执行计算机程序时还可以实现：预先在android系统中定义元应用，将所述元应用放在特定的目录下，并使用framework-res.apk的文件名之前的字符来对所述元应用进行命名；采用不同的开发者的私钥对元应用进行签名，生成各自的cert.sf和cert.rsa，并集成在系统的预设的目录下。

在其中的一个实施例中，该处理器执行计算机程序时还可以实现：所述android系统首次启动时，启动系统中的pms服务；pms服务首先扫描到/system/framework目录下的framework-res.apk，并控制framework-res.apk安装；在安装的过程中记录framework-res.apk的签名信息，并获取到framework-res.apk的uid为system；依次读取多个cert.rsa中的公钥信息，并将读取的公钥信息和uid为system的这个属性值对应并记录。

在其中的一个实施例中，该处理器执行计算机程序时还可以实现：当android系统首次启动时，控制系统中的pms服务扫描预先定义的元应用的路径；依次记录每一个元应用的签名信息，并获取到元应用的uid为system；依次从cert.rsa中读取各自的公钥信息，并将读取出的公钥信息和uid为system的这个属性值对应并记录。

在其中的一个实施例中，该处理器执行计算机程序时还可以实现：当所述pms服务继续扫描到第三方系统应用处于安装时，获取正在进行安装的第三方系统应用的签名信息；从正在进行安装的第三方系统应用的签名信息的cert.rsa中读取公钥信息，同时读取正在进行安装的第三方系统应用的uid；当uid为system时，则从android原生apk的签名信息中的cert.rsa中读取公钥信息；将正在进行安装的第三方系统应用的公钥信息与android原生apk的公钥信息进行对比验证。

在其中的一个实施例中，该处理器执行计算机程序时还可以实现：将正在进行安装的第三方系统应用的公钥信息与android原生apk的公钥信息进行对比；当正在进行安装的第三方系统应用的公钥信息与android原生apk的公钥信息中，存在任何一个system签名相同时，则说明满足验证条件；控制正在进行安装的第三方系统应用完成安装操作。

在其中的一个实施例中，该处理器执行计算机程序时还可以实现：使用获取到的android原生apk的公钥对安装的第三方系统应用的cert.sf解密，将解密结果和android原生apk的manifest.mf进行比较，如果相同说明cert.rsa有效、manifest.mf未被更改。此外，本实施例还对安装的第三方系统应用中所有文件内容分别进行hash计算，将计算结果的base64编码和android原生apk的manifest.mf里的相应内容进行比较，全部相同则安装的第三方系统应用的内容未被更改，从而保证第三方系统应用的完整性。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本发明所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器（rom）、可编程rom（prom）、电可编程rom（eprom）、电可擦除可编程rom（eeprom）或闪存。易失性存储器可包括随机存取存储器（ram）或者外部高速缓冲存储器。作为说明而非局限，ram以多种形式可得，诸如静态ram（sram）、动态ram（dram）、同步dram（sdram）、双数据率sdram（ddrsdram）、增强型sdram（esdram）、同步链路（synchlink）dram（sldram）、存储器总线（rambus）直接ram（rdram）、直接存储器总线动态ram（drdram）、以及存储器总线动态ram（rdram）等。

综上所述，本发明提供了一种多签名机制下的应用安装管理方法、存储介质及智能终端，方法包括：预先对android系统中的android原生apk进行多次签名；android系统首次启动时，控制系统中的pms服务扫描android原生apk，并获取签名信息；当扫描到第三方系统应用处于安装时，则获取正在进行安装的第三方系统应用的签名信息，并获取的签名信息与android原生apk的签名信息进行对比验证；当两者的签名信息中，存在任何一个system签名相同时，则安装验证通过，控制完成安装操作。采用本发明的方法可以使系统支持多个系统签名，简化第三方系统应用在需要使用系统权限时的验证流程，方便第三方系统应用安装，提高安装效率。

应当理解的是，本发明的系统应用不限于上述的举例，对本领域普通技术人员来说，可以根据上述说明加以改进或变换，所有这些改进和变换都应属于本发明所附权利要求的保护范围。