CN110362990A - 应用安装的安全处理方法、装置及*** - Google Patents

Abstract

本申请公开了一种应用安装的安全处理方法、装置及***，属于应用安全领域，可加强设备对应用安装的安全性检测，更能有效保证设备安全。其中方法包括：获取应用安装包中的签名文件，所述签名文件中包含签名信息、第一根证书和工作证书；根据所述第一根证书和预置在设备内的第二根证书进行证书链验证；若通过证书链验证，则利用所述工作证书对所述签名信息进行验签；若验签通过，则触发所述应用安装包在所述设备内的安装指令。

Description

应用安装的安全处理方法、装置及***

技术领域

本申请涉及信息处理技术领域，尤其是涉及到一种应用安装的安全处理方法、装置及***。

背景技术

随着移动互联网技术的发展，移动设备的使用已很普遍。用户可以在移动设备上安装应用(Application，APP)，以满足用户的各种需求。如移动设备可通过加载应用安装包(AndroidPackage，APK)，进行应用程序的安装。

为了防止安装恶意应用，目前传统的方式是在设备中写入应用可被安装的白名单，在应用安装前通过比对是否在白名单中，确定应用是否可被安装。

然而白名单机制依赖于网络等需要实时更新，如果更新不及时会导致设备安装最新的恶意应用，造成安全隐患。另外，随着设备越来越多，白名单版本越来越多，需要依赖互联网的接入以更新白名单，人工成本高，维护成本大，不利于管控。

发明内容

有鉴于此，本申请提供了一种应用安装的安全处理方法、装置及***，主要目的在于解决目前通过白名单机制如果更新不及时会导致设备安装最新的恶意应用，进而造成安全隐患，并且维护白名单也会增加相应成本的问题。

根据本申请的一个方面，提供了一种应用安装的安全处理方法，可应用于客户端侧，该方法包括：

获取应用安装包中的签名文件，所述签名文件中包含签名信息、第一根证书和工作证书；

根据所述第一根证书和预置在设备内的第二根证书进行证书链验证；

若通过证书链验证，则利用所述工作证书对所述签名信息进行验签；

若验签通过，则触发所述应用安装包在所述设备内的安装指令。

可选的，所述根据所述第一根证书和预置在设备内的第二根证书进行证书链验证，具体包括：

获取所述设备对应的生产商根证书；

利用所述生产商根证书对所述第二根证书进行验证；

若所述第二根证书通过验证，则比对所述第二根证书和第一根证书包含的公钥；

若所述公钥相同，则确定通过证书链验证。

可选的，所述利用所述工作证书对所述签名信息进行验签，具体包括：

获取所述应用安装包对应的认证签名值；

利用所述工作证书的公钥对所述签名信息进行解密，并将得到的签名值与所述认证签名值进行比对；

若所述签名值与所述认证签名值一致，则确定验签通过。

可选的，所述第二根证书是生成所述第一根证书时对应生成的CSR请求文件，经过所述生产商根证书签发得到的。

可选的，所述工作证书是通过所述第一根证书对应的私钥签发工作证书CSR请求文件生成得到的。

可选的，所述获取应用安装包中的签名文件，具体包括：

解压所述应用安装包，获取解压后的应用安装包中预设目录下的所述签名文件；

所述触发所述应用安装包在所述设备内的安装指令，具体包括：

从所述解压后的应用安装包中删除所述签名文件，并重新打包所述解压后的应用安装包；

触发重新打包后的应用安装包在所述设备内的安装指令。

根据本申请的另一方面，提供了另一种应用安装的安全处理方法，可应用于服务端侧，该方法包括：

利用工作证书对应用安装包数据进行签名，得到签名信息；

将所述签名信息、所述工作证书和第一根证书进行组合，生成签名文件；

将所述签名文件添加到应用安装包中；

发布所述应用安装包，以便在设备下载安装所述应用安装包之前，根据所述签名信息、所述工作证书、所述第一根证书和预置在所述设备内的第二根证书进行安全校验。

可选的，所述方法还包括：

生成第一根证书、CSR请求文件和所述第一根证书对应的私钥；

将所述CSR请求文件发送给所述设备，以使得所述CSR请求文件经过生产商根证书签发得到所述第二根证书。

可选的，在所述利用工作证书对应用安装包数据进行签名，得到签名信息之前，所述方法还包括：

通过秘钥管理基础设施KMI***获取工作证书CSR请求文件；

利用所述第一根证书对应的私钥，签发所述工作证书请求文件，得到所述工作证书。

可选的，所述方法还包括：

向所述设备发送定制的证书升级包，以便在利用旧根证书签名验证通过后，对所述第二根证书进行更新。

可选的，所述利用工作证书对应用安装包数据进行签名，得到签名信息，具体包括：

对所述应用安装包通过SHA-256算法生成对应的所述应用安装包数据；

利用所述工作证书的私钥，对生成的所述应用安装包数据进行签名，得到签名信息。

可选的，所述将所述签名文件添加到应用安装包中，具体包括：

解压所述应用安装包，将所述签名文件存放到源文件的预设目录下；

封装编译所述源文件，生成经过签名处理的应用安装包。

根据本申请的又一方面，提供了一种应用安装的安全处理装置，可应用于客户端侧，该装置包括：

第一获取模块，用于获取应用安装包中的签名文件，所述签名文件中包含签名信息、第一根证书和工作证书；

第一验证模块，用于根据所述第一根证书和预置在设备内的第二根证书进行证书链验证；

第二验证模块，用于第一验证模块若通过证书链验证，则利用所述工作证书对所述签名信息进行验签；

安装模块，用于若验签通过，则触发所述应用安装包在所述设备内的安装指令。

可选的，所述第一验证模块还包括：

第一获取子模块，用于获取所述设备对应的生产商根证书；

第一验证子模块，用于利用所述生产商根证书对所述第二根证书进行验证；

第二验证子模块，用于若所述第二根证书通过验证，则比对所述第二根证书和第一根证书包含的公钥；

第一确定子模块，用于若所述公钥相同，则确定通过证书链验证。

可选的，所述第二验证模块还包括：

第二获取子模块，用于获取所述应用安装包对应的认证签名值；

比对子模块，用于利用所述工作证书的公钥对所述签名信息进行解密，并将得到的签名值与所述认证签名值进行比对；

第二确定子模块，用于若所述签名值与所述认证签名值一致，则确定验签通过。

可选的，所述第二根证书是生成所述第一根证书时对应生成的CSR请求文件，经过所述生产商根证书签发得到的。

可选的，所述工作证书是通过所述第一根证书对应的私钥签发工作证书CSR请求文件生成得到的。

可选的，所述第一获取模块，具体还用于解压所述应用安装包，获取解压后的应用安装包中预设目录下的所述签名文件；

所述安装模块，具体还用于从所述解压后的应用安装包中删除所述签名文件，并重新打包所述解压后的应用安装包；

触发重新打包后的应用安装包在所述设备内的安装指令。

根据本申请的再一方面，提供了另一种应用安装的安全处理装置，可应用于服务端侧，该装置包括：

签名模块，用于利用工作证书对应用安装包数据进行签名，得到签名信息；

组合模块，用于将所述签名信息、所述工作证书和第一根证书进行组合，生成签名文件；

添加模块，用于将所述签名文件添加到应用安装包中；

发布模块，用于发布所述应用安装包，以便在设备下载安装所述应用安装包之前，根据所述签名信息、所述工作证书、所述第一根证书和预置在所述设备内的第二根证书进行安全校验。

可选的，所述装置还包括：

生成模块，用于生成第一根证书、CSR请求文件和所述第一根证书对应的私钥；

发送模块，用于将所述CSR请求文件发送给所述设备，以使得所述CSR请求文件经过生产商根证书签发得到所述第二根证书。

可选的，所述装置还包括：

第二获取模块，用于通过秘钥管理基础设施KMI***获取工作证书CSR请求文件；

处理模块，用于利用所述第一根证书对应的私钥，签发所述工作证书请求文件，得到所述工作证书。

可选的，所述装置还包括：

更新模块，用于向所述设备发送定制的证书升级包，以便在利用旧根证书签名验证通过后，对所述第二根证书进行更新。

可选的，所述签名模块具体还包括：

加密子模块，用于对所述应用安装包通过SHA-256算法生成对应的所述应用安装包数据；

签名子模块，用于利用所述工作证书的私钥，对生成的所述应用安装包数据进行签名，得到签名信息。

可选的，所述添加模块，具体用于解压所述应用安装包，将所述签名文件存放到源文件的预设目录下；

封装编译所述源文件，生成经过签名处理的应用安装包。

依据本申请再一个方面，提供了一种存储介质，其上存储有计算机程序，所述程序被处理器执行时实现上述可应用于客户端侧的应用安装的安全处理方法。

依据本申请再一个方面，提供了一种客户端设备，包括存储介质、处理器及存储在存储介质上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述可应用于客户端侧的应用安装的安全处理方法。

依据本申请再一个方面，提供了一种存储介质，其上存储有计算机程序，所述程序被处理器执行时实现上述可应用于服务端侧的应用安装的安全处理方法。

依据本申请再一个方面，提供了一种服务器设备，包括存储介质、处理器及存储在存储介质上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述可应用于服务端侧的应用安装的安全处理方法。

依据本申请再一个方面，提供了一种应用安装的安全处理***，包括上述客户端设备和服务器设备。

借由上述技术方案，本申请提供的一种应用安装的安全处理方法、装置及***，与目前现有技术相比，本申请客户端可在需要安装应用安装包时，根据安装包中签名文件包含的根证书、工作证书、签名信息，并结合预置在设备内的根证书进行证书链以及验签等一系列的安全验证。这种安全验证是从两个方向开始的，不仅从安装包的自签名证书开始验证，而且还以客户端为验证的起点进行验证。这样验证的好处是在验证自签名证书的同时验证设备是否安全，相比于传统的验证方法更全面，更能有效解决现在应用安装在安全方面遇到的问题。服务端方面，相比于传统的预置在设备中的白名单的主要区别是，预置白名单需要维护，更新依赖于网络，通过证书来控制安装权限最大的好处就是证书具有不可抵赖性，将应用程序的安全处理和证书进行充分结合，为客户端设备提供了强有力的安全保障。

上述说明仅是本申请技术方案的概述，为了能够更清楚了解本申请的技术手段，而可依照说明书的内容予以实施，并且为了让本申请的上述和其它目的、特征和优点能够更明显易懂，以下特举本申请的具体实施方式。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1示出了本申请实施例提供的一种应用安装的安全处理方法的流程示意图；

图2示出了本申请实施例提供的另一种应用安装的安全处理方法的流程示意图；

图3示出了本申请实施例提供的又一种应用安装的安全处理方法的流程示意图；

图4示出了本申请实施例提供的再一种应用安装的安全处理方法的流程示意图；

图5示出了本申请实施例提供的一种应用安装的安全处理的处理装置的结构示意图；

图6示出了本申请实施例提供的另一种应用安装的安全处理的处理装置的结构示意图；

图7示出了本申请实施例提供的一种应用安装的安全处理的加签的流程示意图；

图8示出了本申请实施例提供的一种应用安装的安全处理的验签的体系框架图；

图9示出了本申请实施例提供的一种应用安装的工作证书的流程示意图；

图10示出了本申请实施例提供的一种应用安装的安全处理的证书结构关系示意图；

图11示出了本申请实施例提供的一种应用安装的安全处理***结构示意图。

具体实施方式

下文中将参考附图并结合实施例来详细说明本申请。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

目前通过现有方式进行应用安装的处理方法依赖网络的实时更新并且需要预置白名单对应用的安装进行校验，但是特殊情况下无法保证网络的实时连接，维护白名单提高了应用安装的时间成本。为了解决该问题，本实施例提供了一种应用安装的安全处理方法，如图1所示，该方法包括：

101、客户端获取应用安装包中的签名文件。

其中，签名文件包含签名信息、第一根证书和工作证书(App Signer Cert)。例如，签名信息可为利用工作证书私钥对安装包数据进行签名得到的256字节签名值等。第一根证书可为官方认证的根证书(App Provider CA)，通过该根证书对应的私钥对工作证书请求文件进行签名，进而生成该工作证书。这里签名指的是使用私钥对需要进行处理的内容摘要进行加密，得到的密文就被称为签名。

对于本实施例的执行主体可为用于应用安装前进行安装验证处理的客户端装置或设备，可配置在商家管理设备侧或其他终端侧，如辅助用户点餐的多功能终端(point ofsale，POS)等。

在本实施例中，应用安装包可从应用商店获取，或者从其他途径获取得到。在该应用安装包需要安装(如接收到相应的安装指令)之前，或者下载到该应用安装包进行安全验证时，执行步骤101至104所示的安全处理过程，以便保证应用安装的安全性。

102、根据第一根证书和预置在设备内的第二根证书进行证书链验证。

其中，第二根证书可根据官方认证的根证书请求文件，并通过设备厂商进行签名生成得到，然后预置在设备内。对于本实施例中的设备可为商家管理设备，或者其他终端设备等。

在本实施例中，证书链的具体验证逻辑根据实际需求预先设定。例如，首先获取生产商根证书，通过生产商根证书验证第二根证书，其次对比预置的第一根证书的公钥和第二根证书的公钥进行验证等。

103、若通过证书链验证，则利用工作证书对签名信息进行验签。

其中，验签指的是数据接收端接收到需要进行处理的内容后，需要确认所述内容是否被篡改。因此接收方使用自己持有的公钥对签名进行解密，对比获得的摘要计算值和解密后获得的值，二者完全一致说明没有被篡改。

例如，POS设备在安装应用安装包P之前，获取应用安装包P中的签名文件，签名文件中包含长字符串信息S，根证书A，工作证书B。根据POS设备中预置的根证书C对证书A进行验证，若验证通过，使用工作证书B对长字符串信息S进行验签，若验签通过，触发安装包P在POS设备中的安装指令。

对于本实施例，可利用工作证书对签名信息进行验签逻辑根据实际需求预先设定。例如，通过工作证书的公钥进行解密，将得到的结果与认证签名值进行比对以此来确定校验是否通过。

104、若验签通过，则触发所述应用安装包在所述设备内的安装指令。

其中，安装指令包含启动安装包安装程序的指令，用于在验证通过后安装安装包。

对于本实施例提供的方法，客户端在安装应用程序前进行安全处理，与目前现有技术相比，能够做到不依赖互联网的实时更新白名单，通过安装包中签名文件包含的根证书、工作证书、签名信息，并结合预置在设备内的根证书进行证书链以及验签等一系列的安全验证，减少了维护白名单的成本，设备厂商证书和客户根证书的双重认证有机地结合在一起，从设备和安装包两个方向进行验证，极大程度上提升了客户端在验证安装包方面的安全性。

进一步的，作为上述实施例具体实施方式的细化和扩展，为了完整说明本实施例的具体实施过程，本实施例提供了另一种应用安装的安全处理方法，如图2所示，该方法包括：

201、解压应用安装包，获取解压后的应用安装包中预设目录下的签名文件。

例如，安装包文件中包含META-INF文件或META-INF目录下的子文件。从META-INF文件或META-INF目录下的子文件中获取签名文件。

签名文件中可包含签名信息、第一根证书和工作证书。在本实施例中，工作证书是通过所述第一根证书对应的私钥签发工作证书CSR请求文件生成得到的。

对于本实施例，签名文件被预先放置在META-INF文件或META-INF目录下的子文件中，以便于解压后查找签名信息、第一根证书和工作证书。本实施例中第一根证书可以是由生产商的委托方签发的证书。本实施例中工作证书可以是生产商签发工作证书请求文件生成的证书。上述方法所确定的签名文件相比于传统方法确定的签名文件更能有效地进行全方位验证，不仅可以对安装包进行验证，还可以对验证所使用的工作证书的上级证书进行验证。通过这种双重验证，降低了被恶意应用通过验证的风险。

202、获取所述设备对应的生产商根证书。

对于本实施例，生产商根证书可以是由生产商签发并预置在设备中，以便于进行证书链验证。生产商根证书在级别上属于第一根证书和第二根证书的上级证书，是第二根证书的直接上级证书。这种证书链模式包含两条独立的证书链，分别是生产商根证书到第二根证书，第一根证书到工作证书，再通过第一根证书和第二根证书相同的证书请求文件巧妙地关联起来，以便于在后续的验证中可以分别从两个角度进行验证，确保设备安全性的同时，完成对安装包的验证。

203、利用所述生产商根证书对所述第二根证书进行验证。

对于本实施例，第二根证书是生成所述第一根证书时对应生成的CSR请求文件，经过所述生产商根证书签发得到的。对第二根证书的验证的主要目的是确保设备的安全性，即使盗用设备私自组装成终端设备，例如POS设备，在没有预置第二根证书的情况下仍然无法通过验证。上述方式能有效地保障设备安全。

204、若第二根证书通过验证，则比对所述第二根证书和第一根证书包含的公钥。

对于本实施例，验证第一根证书和第二根证书是否包含相同的公钥是为了验证第一根证书的合法性，验证第一根证书的合法性的目的有两个，首先通过验证第一根证书的合法性来直接校验安装包，其次通过验证第一根证书的合法性来判断工作证书的合法性，因为工作证书是根据第一根证书生成的。通过比对公钥完成证书链的验证。上述方法验证客户端和安装包之间在结构上能否契合，上述方法的使用者可以通过控制分发第一根证书的方式进行权限设置，完成对安装包安装权限的限制。

205、若第二根证书和第一根证书包含的公钥相同，则确定通过证书链验证，获取应用安装包对应的认证签名值。

对于本实施例，获取应用安装包对应的认证签名值，所述认证签名值用于校验预置的签名值，以便判断工作证书的合法性。

在本实施例中，在服务端侧生成根证书的同时生成一本标准CSR格式的证书请求，该请求文件中包含了服务端侧的根公钥信息和主体信息。厂商在拿到这本证书请求后使用厂商的CA证书对其进行签发，生成用户根证书B(厂商签名)，并预置到设备的安全区中，在设备启动时，固件通过厂商CA证书来对其进行合法性校验，确保根公钥信息的正确性。在进行APK应用安装时，设备先获取APK包中的根证书A(自签名)，取出其中的公钥值，与存放在设备上的根证书B(厂商签名)中的公钥值进行比对，若两者一致，则判定该根证书A合法，再使用其对安装包内的工作证书进行合法性校验。

206、利用工作证书的公钥对签名信息进行解密，并将得到的签名值与所述认证签名值进行比对。

207、若签名值与所述认证签名值一致，则确定验签通过，从所述解压后的应用安装包中删除所述签名文件，并重新打包所述解压后的应用安装包。

对于本实施例，重新打包所述解压后的应用安装包能有效地和现有的应用程序安装方式结合，不需要在验证安装包是否可以安装后再进行额外的开发，降低了耦合性，增加了现有代码的利用率。

208、触发重新打包后的应用安装包在所述设备内的安装指令。

进一步的，当应用终端，例如POS设备被私自组装，没有经过生产商的授权，未安装第二根证书，那么在验证过程中无法通过步骤203，上述方法进行的验证是全方位的，是从设备内部发起具有可靠性的。

在另一种情况下，第三方恶意地窃取了工作证书，那么工作证书的自签名验证是通过的，传统的方法仅限于此，虽然工作证书的验证具有不可抵赖性，但步骤204可以否定工作证书的合法性，多角度进行安全校验。

例如，解压应用安装包P，获取解压后的应用安装包中META-INF文件或META-INF目录下的签名文件，签名文件中包含长字符串信息S，证书A，证书B。获取POS设备的生产商根证书。利用所述生产商根证书对预置的证书C进行验证。若证书C通过验证，则比对所述证书C和证书A包含的公钥。若公钥相同，则获取应用安装包P对应的认证签名值。利用证书B的公钥对签名信息进行解密，并将得到的签名值与所述认证签名值进行比对。若签名值与所述认证签名值一致，从所述解压后的应用安装包P中删除所述签名文件，并重新打包所述解压后的应用安装包P。触发重新打包后的应用安装包在所述设备内的安装指令，完成对安装包P的安装。

本实施例提供的方法，建立一套完善的应用分发机制，对应用的安装进行限制，相当于一套行之有效的方案，当应用在应用市场后台上架的时候将这种安装限制内置到应用本身，通过专门的***改造，验证应用的安装限制，如果通过验证，则运行对应用进行安装，不允许则不让应用安装成功。与目前现有技术相比，保证机器安装应用的灵活性，除了某些固定应用安装以外，还可安装一些官方的应用，根据后续业务诉求进行扩展。

需要说明的是，上述可应用于客户端侧的应用安装的安全处理方法，是在客户端侧描述具体的应用安装的安全处理过程，而为了完整说明本实施例的具体实施方式，提供了另一种可应用于服务端侧的应用安装的安全处理方法，以便说明在服务端侧的应用安装的安全处理过程，如图3所示，该方法包括：

301、服务端利用工作证书对应用安装包数据进行签名，得到签名信息。

其中，利用工作证书对应用安装包数据进行签名可以是；首先对安装包进行SHA256算法处理，生成安装包数据，然后使用工作证书的私钥对安装包的摘要数据进行签名处理。

对于本实施例，对安装包进行摘要处理并且签名是初步地进行验证准备。

302、将签名信息、所述工作证书和第一根证书进行组合，生成签名文件。

例如，生成的签名文件可以是SIGNINFO文件，将所述签名信息、所述工作证书和第一根证书进行组合便于进行信息管理和安装包的重新打包。

303、将签名文件添加到应用安装包中。

对于本实施例，将所述签名文件添加到应用安装包中以便于客户端在解压后获得签名文件进行安全验证。

304、发布所述应用安装包。

进一步的，以便于在设备下载安装所述应用安装包之前，根据所述签名信息、所述工作证书、所述第一根证书和预置在所述设备内的第二根证书进行安全校验。例如，可将应用安装包发布到应用商店，或者其他下载应用渠道等。

本实施例提供的方法，与目前现有技术相比，可减少维护白名单的成本，设备厂商证书和客户根证书的双重认证有机地结合在一起，从设备和安装包两个方向进行验证，极大程度上提升了客户端在验证安装包方面的安全性。

进一步的，作为上述实施例具体实施方式的细化和扩展，为了完整说明本实施例的具体实施过程，本实施例提供了另一种应用安装的安全处理方法，如图4所示，该方法包括：

401、生成第一根证书、CSR请求文件和所述第一根证书对应的私钥；

其中，CSR请求文件：即证书请求文件，也就是证书申请者在申请数字证书时由加密服务提供者在生成私钥的同时也生成证书请求文件，证书申请者只要把CSR文件提交给证书颁发机构后，证书颁发机构使用其根证书私钥签名就生成了证书公钥文件，也就是颁发给用户的证书。

402、将所述CSR请求文件发送给设备。

进一步的，以使得所述CSR请求文件经过生产商根证书签发得到所述第二根证书。第二根证书后续被预置在设备侧。

在本实施例中，生成的根证书是自签名证书，预置到设备中后需要设计相关机制来确保根证书的合法性和无法替换。

进一步的，为了满足证书更新需求，本实施例方法还可包括：向所述设备发送定制的证书升级包，以便在利用旧根证书签名验证通过后，对所述第二根证书进行更新。例如，通过定制的证书升级包对设备内预置的根证书进行更新。升级包必须使用旧根证书签名验证通过后才能被成功安装到设备中，从而实现设备利用最新的根证书进行证书链验证过程，提高相应的安全性。

403、通过KMI***获取工作证书CSR请求文件。

其中，秘钥管理基础设施(Key Management Infrastructure，KMI)***可配置在服务端侧。

404、利用所述第一根证书对应的私钥，签发所述工作证书请求文件，得到所述工作证书。

在本实施例中，第一根证书和应用签名工作证书，可由服务端生成和管控，其中公钥证书对应的私钥需加密存储，公钥证书对外发布，CSR格式的根证书请求文件包含的公钥信息一并发布给厂商，用于纳入各厂商的证书链中进行保护。需要说明的是，工作证书无需预置到设备中而是打包在应用程序的APK中一同下载，其合法性由设备中预置的根公钥进行验证。

405、对应用安装包通过SHA-256算法生成对应的应用安装包数据。

406、利用所述工作证书的私钥，对生成的所述应用安装包数据进行签名，得到签名信息。

例如，使用工作证书私钥对原始APK包数据进行签名，得到256字节的签名值。

在本实施例中，可使用符合PCI安全要求的非对称算法RSA2048，消息摘要算法SHA256，证书格式遵循X509规范。

407、将签名信息、所述工作证书和第一根证书进行组合，生成签名文件。

具体的，可将签名值与根证书、工作证书以及一些附加信息(如签名描述信息、证书域、附件信息域、签名文件头等)进行组合，生成签名文件SIGNINFO。

408、解压所述应用安装包，将所述签名文件存放到源文件的预设目录下。

409、封装编译所述源文件，生成经过签名处理的应用安装包。

例如，将签名文件SIGNINFO导入APK文件的META-INF目录下，从而在不破坏原生APK包格式的前提下，将签名信息嵌入到APK中，在下载安装时利用其对APK文件进行完整性和真实性校验。

410、发布经过签名处理后的应用安装包。

进一步的，以便于在设备下载安装该应用安装包之前，根据所述签名信息、所述工作证书、所述第一根证书和预置在所述设备内的第二根证书进行安全校验。例如，在设备侧首先解压APK包，获取签名文件SIGNINFO，并删除SIGNINFO后，还原原始APK文件；然后根据SIGNINFO获取根证书，工作证书，签名值等信息；根据预置在设备内的根证书进行证书链验证；在通过证书链后，使用工作证书验证原始APK包的签名值的合法性；如果验签通过，调用安卓原生流程正常执行原始APK文件的安装，不再对原始APK中的数据进行严格验签。

例如，生成证书A，证书请求文件F1和证书A对应的私钥，将F1发送给POS设备，以使通过预置的证书C签发F1生成证书C。通过KMI***获取工作证书请求文件F2，利用证书A的私钥签发F2，得到证书B。对安装包P1进行通过SHA256算法进行信息摘要处理生成字符串S1，使用证书B的私钥签发S1，得到S2。将S2、证书B和证书A组合成SIGNINFO文件。解压安装包P1，将SIGNINFO文件存放到META-INF文件或META-INF目录下并重新打包得到安装包P2。发布安装包P2到应用商店，以便于客户端从应用商店下载到安装包P2，并在安装P2之前，对S2、证书B和证书A进行安全校验。

本实施例提供的方法，可使用厂商CA对服务端根证书进行加签，不会破坏证书体系的独立性。可通过自己的证书进行应用程序签名发布；可提供根公钥证书请求给厂商，并不会泄露私钥等敏感信息，各厂商可自行设计相应的保护机制来保证根公钥的合法性，而将完整的证书链包含在APK安装程序中，也便于各厂商通过标准openssl命令实现对APK安装程序的验签，兼容性好；还可通过厂商CA加签的方式，让的根证书纳入各厂商的证书链中进行保护，使得根公钥信息在设备上的存放更安全与目前现有技术相比，可减少维护白名单的成本，设备厂商证书和客户根证书的双重认证有机地结合在一起，从设备和安装包两个方向进行验证，极大程度上提升了客户端在验证安装包方面的安全性。

进一步的，作为图1和图2所示方法的具体实现，本申请实施例提供了一种可应用于客户端侧的应用安装的安全处理装置，如图5所示，该装置包括：第一获取模块501、第一验证模块502、第二验证模块503和安装模块504。

第一获取模块501，用于获取应用安装包中的签名文件，所述签名文件中包含签名信息、第一根证书和工作证书；

第一验证模块502，用于根据所述第一根证书和预置在设备内的第二根证书进行证书链验证；

第二验证模块503，用于第一验证模块若通过证书链验证，则利用所述工作证书对所述签名信息进行验签；

安装模块504，用于若第二验证模块验签通过，则触发所述应用安装包在所述设备内的安装指令。

在具体的应用场景中，所述第一验证模块502还包括：第一获取子模块5021、第一验证子模块5022、第二验证子模块5023、第一确定子模块5024；

第一获取子模块5021，用于获取所述设备对应的生产商根证书；

第一验证子模块5022，用于利用所述生产商根证书对所述第二根证书进行验证；

第二验证子模块5023，用于若所述第二根证书通过验证，则比对所述第二根证书和第一根证书包含的公钥；

第一确定子模块5024，用于若所述公钥相同，则确定通过证书链验证。

在具体的应用场景中，所述第二验证模块503还包括：第二获取子模块5031、比对子模块5032、第二确定子模块5033；

第二获取子模块5031，用于获取所述应用安装包对应的认证签名值；

比对子模块5032，用于利用所述工作证书的公钥对所述签名信息进行解密，并将得到的签名值与所述认证签名值进行比对；

第二确定子模块5033，用于若所述签名值与所述认证签名值一致，则确定验签通过。

在具体的应用场景中，可选的，所述第二根证书是生成所述第一根证书时对应生成的CSR请求文件，经过所述生产商根证书签发得到的。

在具体的应用场景中，可选的，所述工作证书是通过所述第一根证书对应的私钥签发工作证书CSR请求文件生成得到的。

在具体的应用场景中，所述第一获取模块501，具体还用于解压所述应用安装包，获取解压后的应用安装包中预设目录下的所述签名文件；

所述安装模块504，具体还用于从所述解压后的应用安装包中删除所述签名文件，并重新打包所述解压后的应用安装包；触发重新打包后的应用安装包在所述设备内的安装指令。

需要说明的是，本实施例提供的一种可应用于客户端侧的应用安装的安全处理装置所涉及各功能单元的其它相应描述，可以参考图1和图2中的对应描述，在此不再赘述。

进一步的，作为图3和图4所示方法的具体实现，本申请实施例提供了一种可应用于服务端侧的应用安装的安全处理装置，如图6所示，该装置包括：签名模块601、组合模块602、添加模块603、发布模块604。

签名模块601，用于利用工作证书对应用安装包数据进行签名，得到签名信息；

组合模块602，用于将所述签名信息、所述工作证书和第一根证书进行组合，生成签名文件；

添加模块603，用于将所述签名文件添加到应用安装包中；

发布模块604，用于发布所述应用安装包。

进一步的，以便于在设备下载安装所述应用安装包之前，根据所述签名信息、所述工作证书、所述第一根证书和预置在所述设备内的第二根证书进行安全校验。

在具体的应用场景中，本装置还包括：生成模块605和发送模块606；

生成模块605，用于生成第一根证书、CSR请求文件和所述第一根证书对应的私钥；

发送模块606，用于将所述CSR请求文件发送给所述设备，以使得所述CSR请求文件经过生产商根证书签发得到所述第二根证书。

在具体的应用场景中，本装置还包括：

第二获取模块607，用于通过秘钥管理基础设施KMI***获取工作证书CSR请求文件；

处理模块608，用于利用所述第一根证书对应的私钥，签发所述工作证书请求文件，得到所述工作证书。

在具体的应用场景中，本装置还包括：更新模块609；

更新模块609，用于向所述设备发送定制的证书升级包，以便在利用旧根证书签名验证通过后，对所述第二根证书进行更新。

在具体的应用场景中，所述签名模块601具体还包括：

加密子模块6011，用于对所述应用安装包通过SHA-256算法生成对应的所述应用安装包数据；

签名子模块6012，用于利用所述工作证书的私钥，对生成的所述应用安装包数据进行签名，得到签名信息。

在具体的应用场景中，所述添加模块603，具体用于解压所述应用安装包，将所述签名文件存放到源文件的预设目录下；封装编译所述源文件，生成经过签名处理的应用安装包。

需要说明的是，本实施例提供的一种可应用于服务端侧的应用安装的安全处理装置所涉及各功能单元的其它相应描述，可以参考图3和图4中的对应描述，在此不再赘述。

在本说明书一个或多个实施例中，对安装包进行签名处理的流程实例可如图7所示：

使用SHA算法进行加密处理，使用工作证书的私钥对数据进行签名，将签名值、二级证书和工作证书组合到SIGNINFO文件，解压APK的META-INFO目录，重新打包。

在本说明书一个或多个实施例中，验签的流程实例可如图8所示。

客户端也就是图中所示目标终端设备中预置第二根证书“根证书B”，首先使用根证书B验证第一根证书，图中所示“根证书A”，其次使用工作证书验证签名值是否合法。

在本说明书一个或多个实施例中，工作证书的生成方式实例可如图9所示。

首先，由服务端提供证书请求文件，生产商根据证书请求文件使用自己的私钥进行签发，并把签发得到的证书，也就是第二根证书预置到设备中。

在本说明书一个或多个实施例中，第一根证书、第二根证书和工作证书之间的关系实例可如图10所示。

综上所述，证书链如图10所示一共两条，以第一根证书和第二根证书相同的公钥作为纽带。

第一根证书和第二根证书是不同的私钥对相同的证书请求文件进行签发得到的，第二根证书被预置在设备中用来校验设备安全，第一根证书的私钥签发生成工作证书，用来保证安装包可靠。

基于上述实例和如图1和图2所示方法，相应的，本申请实施例还提供了一种存储介质，其上存储有计算机程序，该程序被处理器执行时实现上述如图1和图2所示的方法。基于上述如图3和图4所示方法，本申请实施例还提供了另一种存储介质，其上存储有计算机程序，该程序被处理器执行时实现上述如图3和图4所示的方法。

基于这样的理解，本申请的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施场景的方法。

基于上述如图1和图2所示的方法，以及图5所示的虚拟装置实施例，为了实现上述目的，本申请实施例还提供了一种客户端设备，具体可以为个人计算机、平板电脑、智能手机、智能手表、智能手环、POS设备或其他网络设备等，该设备包括存储介质和处理器；存储介质，用于存储计算机程序；处理器，用于执行计算机程序以实现上述如图1和图2所示的方法。

基于上述如图3至图4所示的方法，以及图6所示的虚拟装置实施例，为了实现上述目的，本申请实施例还提供了一种服务器设备，具体可以为个人计算机、服务器、网络设备等，该服务器设备包括存储介质和处理器；存储介质，用于存储计算机程序；处理器，用于执行计算机程序以实现上述如图7至图8所示的方法。

可选的，上述两种实体设备都还可以包括用户接口、网络接口、摄像头、射频(Radio Frequency，RF)电路，传感器、音频电路、WI-FI模块等等。用户接口可以包括显示屏(Display)、输入单元比如键盘(Keyboard)等，可选用户接口还可以包括USB接口、读卡器接口等。网络接口可选的可以包括标准的有线接口、无线接口(如WI-FI接口)等。

本领域技术人员可以理解，本实施例提供的一种客户端设备和服务器设备的实体设备结构并不构成对这两种实体设备的限定，可以包括更多或更少的部件，或者组合某些部件，或者不同的部件布置。

存储介质中还可以包括操作***、网络通信模块。操作***是管理上述两个实体设备硬件和软件资源的程序，支持信息处理程序以及其它软件和/或程序的运行。网络通信模块用于实现存储介质内部各组件之间的通信，以及与信息处理实体设备中其它硬件和软件之间通信。

基于上述内容，进一步的，本申请实施例还提供了一种应用安装的安全处理***，如图11所示，该***包括客户端设备71、服务器设备72；

其中，客户端设备71可用于执行如图1和图2所示的方法，服务器设备72可用于执行如图3和图4所示的方法。

具体的，服务器设备72，可用于利用工作证书对应用安装包数据进行签名，得到签名信息，然后将签名信息、所述工作证书和第一根证书进行组合，生成签名文件，将签名文件添加到应用安装包中，发布所述应用安装包，以便在设备下载安装所述应用安装包之前，根据所述签名信息、所述工作证书、所述第一根证书和预置在所述设备内的第二根证书进行安全校验。

客户端设备71，可用于在下载到服务器设备72发布的应用安装包并在其安装之前，获取应用安装包中的签名文件，根据第一根证书和预置在设备内的第二根证书进行证书链验证若通过证书链验证，若通过证书链验证，则利用工作证书对签名信息进行验签，若验签通过，则触发所述应用安装包在所述设备内的安装指令。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本申请可以借助软件加必要的通用硬件平台的方式来实现，也可以通过硬件实现。通过应用本申请的技术方案，与目前现有方式相比，一次性在设备端预先配置官方证书达到验证应用一劳永逸；无需设备在线联网与白名单预置，对应用和设备侵入少，维护简单；在应用安装时加入应用签名验证的流程，使得设备只能安装官方应用商店中的应用，进而保证应用安装的安全性。

本领域技术人员可以理解附图只是一个优选实施场景的示意图，附图中的模块或流程并不一定是实施本申请所必须的。本领域技术人员可以理解实施场景中的装置中的模块可以按照实施场景描述进行分布于实施场景的装置中，也可以进行相应变化位于不同于本实施场景的一个或多个装置中。上述实施场景的模块可以合并为一个模块，也可以进一步拆分成多个子模块。

上述本申请序号仅仅为了描述，不代表实施场景的优劣。以上公开的仅为本申请的几个具体实施场景，但是，本申请并非局限于此，任何本领域的技术人员能思之的变化都应落入本申请的保护范围。

Claims (10)

1.一种应用安装的安全处理方法，其特征在于，包括：

获取应用安装包中的签名文件，所述签名文件中包含签名信息、第一根证书和工作证书；

根据所述第一根证书和预置在设备内的第二根证书进行证书链验证；

若通过证书链验证，则利用所述工作证书对所述签名信息进行验签；

若验签通过，则触发所述应用安装包在所述设备内的安装指令。

2.根据权利要求1所述的方法，其特征在于，所述根据所述第一根证书和预置在设备内的第二根证书进行证书链验证，具体包括：

获取所述设备对应的生产商根证书；

利用所述生产商根证书对所述第二根证书进行验证；

若所述第二根证书通过验证，则比对所述第二根证书和第一根证书包含的公钥；

若所述公钥相同，则确定通过证书链验证。

3.一种应用安装的安全处理方法，其特征在于，包括：

利用工作证书对应用安装包数据进行签名，得到签名信息；

将所述签名信息、所述工作证书和第一根证书进行组合，生成签名文件；

将所述签名文件添加到应用安装包中；

发布所述应用安装包，以便在设备下载安装所述应用安装包之前，根据所述签名信息、所述工作证书、所述第一根证书和预置在所述设备内的第二根证书进行安全校验。

4.一种应用安装的安全处理装置，其特征在于，包括：

第一获取模块，用于获取应用安装包中的签名文件，所述签名文件中包含签名信息、第一根证书和工作证书；

第一验证模块，用于根据所述第一根证书和预置在设备内的第二根证书进行证书链验证；

第二验证模块，用于第一验证模块若通过证书链验证，则利用所述工作证书对所述签名信息进行验签；

安装模块，用于若第二验证模块验签通过，则触发所述应用安装包在所述设备内的安装指令。

5.一种应用安装的安全处理装置，其特征在于，包括：

签名模块，用于利用工作证书对应用安装包数据进行签名，得到签名信息；

组合模块，用于将所述签名信息、所述工作证书和第一根证书进行组合，生成签名文件；

添加模块，用于将所述签名文件添加到应用安装包中；

发布模块，用于发布所述应用安装包，以便在设备下载安装所述应用安装包之前，根据所述签名信息、所述工作证书、所述第一根证书和预置在所述设备内的第二根证书进行安全校验。

6.一种存储介质，其上存储有计算机程序，其特征在于，所述程序被处理器执行时实现权利要求1至2中任一项所述的应用安装的安全处理方法。

7.一种客户端设备，包括存储介质、处理器及存储在存储介质上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现权利要求1至2中任一项所述的应用安装的安全处理方法。

8.一种存储介质，其上存储有计算机程序，其特征在于，所述程序被处理器执行时实现权利要求3所述的应用安装的安全处理方法。

9.一种服务器设备，包括存储介质、处理器及存储在存储介质上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现权利要求3所述的应用安装的安全处理方法。

10.一种应用安装的安全处理***，其特征在于，包括：如权利要求7所述的客户端设备和如权利要求9所述的服务器设备。