WO2017080262A1

WO2017080262A1 - 一种 apk 签名认证方法及其系统

Info

Publication number: WO2017080262A1
Application number: PCT/CN2016/092815
Authority: WO
Inventors: 陈菲菲; 孟陆强; 陈祖勋; 彭波涛; 颜剑明; 陈恩
Original assignee: 福建联迪商用设备有限公司
Priority date: 2015-11-13
Filing date: 2016-08-02
Publication date: 2017-05-18
Also published as: CN105391717A; CN105391717B

Abstract

本发明提供一种APK签名认证方法及其系统，方法包括：对原始APK文件和收单机构签名描述信息进行签名，得到签名信息；插入签名信息至原始APK文件内部的META-INF目录下，生成签名后APK文件；终端获取所述签名后APK文件；获取所述签名后APK文件中的签名信息；获取原始APK文件；终端验证所述签名信息和所述原始APK文件的合法性，验证通过后，终端安装所述原始APK文件。将签名文件存放在META-INF目录下，在厂商验证签名APK文件时还原得到原始APK文件，以通过厂商验证；同时，也不会影响终端操作系统对原始APK文件的原生验签机制，实现统一APK签名，且提高终端操作系统的兼容性。

Description

一种 APK签名认证方法及其系统

技术领域

[0001] 本发明涉及签名认证领域，具体说的是一种 APK签名认证方法及其系统。

背景技术

[0002] Android安卓系统是 Google公司幵发的基于 Linux架构的幵源操作系统，其上的安装程序均为 APK (Android Package) 格式。 APK文件格式实际上为 zip压缩文件格式，其主要分为三个部分，分别为压缩的文件内容源数据，压缩的目录源数据和目录结束标识结构。

[0003] 在金融支付领域，一般是由收单机构采购支付终端厂商的智能终端设备，由收单系统对支付终端进行集中管理，包括参数下载，密钥下载，接受、处理或转发支付终端的交易请求，并向支付终端回送交易结果信息，是集中管理和交易处理的系统。收单系统会在支付终端上安装自己的程序，并为支付终端设备维护已签名的 APK，也可能需要将 APK安装到其他 Android设备中。

[0004] 本发明的申请人在先已经递交过申请号为 201410165104.8的发明专利申请，公幵了一种统一 APK签名的方法及其系统，通过在 APK源文件的尾部添加签名信息，实现了收单机构只要生成一个经过统一签名的 APK文件，就能下载到不同的终端设备上通过终端设备的验签机制，在保证已签名的 APK文件在数据传输过程数据的完整性和 APK合法性的同吋，收单机构针对不同厂商的终端设备也只需维护一个已签名的文件和一套签名验签机制，大大缩减了收单机构针对 AP K签名的维护成本。

[0005] 上述技术方案在 Android 5.0系统之前都可以正常执行，但是在 Android 5.0系统之后，由于在 APK解压过程中会验证其尾部数据，若原生 APK签名 +尾部数据长度不等于源文件长度就会报错，导致 APK文件安装失败。

[0006] 因此，有必要在上述方案的基础上进行改进，克服上述问题，提供一种全新的 APK签名验证方式，方便收单机构维护已签名的 APK，减少管理成本，以便收单机构只需要维护一个已签名的 APK，且可以下载到不同的 Android设备中的同吋，又能兼容不同版本的终端操作系统。

技术问题

[0007] 本发明所要解决的技术问题是：提供一种 APK签名认证方法及其系统，能够兼容终端操作系统的原生签名机制，提高统一 APK签名认证方式的兼容性。

问题的解决方案

技术解决方案

[0008] 为了解决上述技术问题，本发明采用的技术方案为：

[0009] 一种 APK签名认证方法，包括：

[0010] 对原始 APK文件和收单机构签名描述信息进行签名，得到签名信息；

[0011] 插入签名信息至原始 APK文件内部的 META-INF目录下，生成签名后 APK文件

[0012] 终端获取所述签名后 APK文件；

[0013] 获取所述签名后 APK文件中的签名信息；获取原始 APK文件；

[0014] 终端验证所述签名信息和所述原始 APK文件的合法性，验证通过后，终端安装所述原始 APK文件。

[0015] 本发明提供的另一个技术方案为：

[0016] 一种 APK签名认证系统，包括收单机构和终端，所述收单机构包括安全存储模块、签名执行模块和签名组织模块；所述终端包括第一获取模块、第二获取模块、第三获取模块、签名验证模块以及安装执行模块；

[0017] 所述安全存储模块，用于存储收单机构的工作公钥证书和所述工作公钥证书对应的私钥；

[0018] 所述签名执行模块，用于对原始 APK文件和收单机构签名描述信息进行签名，得到签名信息；

[0019] 所述签名组织模块，用于插入签名信息至原始 APK文件内部的 META-INF目录下，生成签名后 APK文件；

[0020] 所述第一获取模块，用于终端获取所述签名后 APK文件；

[0021] 所述第二获取模块，用于获取所述签名后 APK文件中的签名信息；

[0022] 所述第三获取模块，用于终端获取原始 APK文件； [0023] 所述签名验证模块，用于终端验证所述签名信息和所述原始 APK文件的合法性

[0024] 所述安装执行模块，用于所述签名验证模块验证通过后，终端安装所述原始 A PK文件。

发明的有益效果

有益效果

[0025] 本发明的有益效果在于：本发明不仅实现了收单机构只要生成一个经过统一签名的 APK文件，便能下载到不同的终端设备上通过终端设备的验签机制，在保证已签名的 APK文件在数据传输过程数据完整性和 APK合法性的同吋，收单机构针对不同厂商的终端设备也只需维护一个已签名的文件和一套签名验签机制，大大缩减了收单机构对 APK签名的维护成本。最关键的是，本发明将签名文件存放在 META-INF目录下，不会影响终端操作系统的原生验签机制，能够兼容更高级版本的终端操作系统，顺利完成 APK文件的安装。

对附图的简要说明

附图说明

[0026] 图 1为本发明一种 APK签名认证方法的流程方框图；

[0027] 图 2为本发明一种 APK签名认证方法的签名和验签流程方框图；

[0028] 图 3为本发明一种 APK签名认证方法及其系统中的签名文件格式示意图；

[0029] 图 4为本发明中收单机构下发至终端的签名后 APK文件的总体结构图；

[0030] 图 5为本发明原始 APK文件与签名后 APK文件的格式差异示意图；

[0031] 图 6为本发明一种 APK签名认证方法及其系统中终端厂商验签过程示意图；

[0032] 图 7为本发明终端验签吋还原原始 APK文件过程中的格式变化示意图；

[0033] 图 8为本发明一种 APK签名认证系统的结构示意图；

[0034] 图 9为图 8中签名组织模块的结构示意图；

[0035] 图 10为图 8中第三获取模块的结构示意图；

[0036] 图 11为图 8中签名执行模块的结构示意图；

[0037] 图 12为图 8中签名验证模块的结构示意图；

[0038] 标号说明： [0039] 1、收单机构； 2、终端；

[0040] 11、安全存储模块； 12、签名执行模块； 13、签名组织模块；

[0041] 21、第一获取模块； 22、第二获取模块； 23、第三获取模块； 24、签名验证模块； 25、安装执行模块；

[0042] 131、第一添加单元； 132、第二添加单元； 133、第一修改单元；

[0043] 231、拷贝单元； 232、第一刪除单元； 233、第二刪除单元； 234、第二修改单元；

[0044] 121、第一生成单元； 122、第一计算单元； 123、第一签名单元； 124、第二签名单元； 125、第二生成单元；

[0045] 241、第三生成单元； 242、第一验证单元； 243、第二验证单元； 244、获取单元； 245、第二计算单元； 246、判断单元。

具体实施方式

[0046] 本发明最关键的构思在于：将签名文件存放在 META-INF目录下，在厂商验证签名 APK文件吋还原得到原始 APK文件，以通过厂商验证；同吋，也不会影响终端操作系统对原始 APK文件的原生验签机制，实现统一 APK签名，且提高终端操作系统的兼容性。

[0047] 请参照图 1至图 7，本发明提供一种 APK签名认证方法，如图 1所示，包括： [0048] 对原始 APK文件和收单机构签名描述信息进行签名，得到签名信息；

[0049] 插入签名信息至原始 APK文件内部的 META-INF目录下，生成签名后 APK文件

[0050] 终端获取所述签名后 APK文件；

[0051] 获取所述签名后 APK文件中的签名信息；获取原始 APK文件；

[0052] 终端验证所述签名信息和所述原始 APK文件的合法性，验证通过后，终端安装所述原始 APK文件。

[0053] 从上述描述可知，本发明的有益效果在于：本发明在实现了统一 APK签名认证方式，方便终端管理者管理不同终端设备和减少管理成本，提高用户体验的同吋；通过将签名信息放置在原始 APK内部的 META-INF目录下，利用 META-INF 目录只在厂商对终端设备对签名后 APK文件的验签过程中才会对其进行验证，而在终端的操作系统安装原始 APK文件的原生验签过程中则不会对其进行验证的特点，在厂商对终端所下载的签名后 APK文件进行验签之前，还原出原始的 A PK文件，以便顺利通过厂商的验签；同吋，又能顺利通过终端的操作系统的原生验签，确保终端在保证所下载的原始 APK文件的安全性前提下，正常的安装原始 APK文件，提高统一 APK签名认证方式的兼容性。

[0054] 进一步的，所述"获取原始 APK文件"具体为：

[0055] 刪除所述签名后 APK文件中的签名信息，还原所述原始 APK文件；或者

[0056] 从所述签名后 APK文件的二进制数据中提取所述原始 APK文件。

[0057] 由上述描述可知，还原原始 APK文件的方式可以是刪除插入所述原始 APK文件中的签名信息，也可以直接从所述签名后 APK文件的二进制数据中提取出原始的 APK文件。还原原始 APK文件的目的是为了在之后厂商对所述签名信息和所述原始 APK文件的合法性验签过程中，对其核心数据进行计算，比对计算结果吋不会由于原始 APK文件的 META-INF目录下插入了签名文件而导致比对有误，不能顺利安装，确保顺利通过厂商对其的合法性验证。

[0058] 进一步的，所述"插入签名信息至原始 APK文件内部的 META-INF目录下"具体为：

[0059] 在原始 APK文件的压缩的文件内容源数据尾部添加经过压缩后的所述签名信息

[0060] 在压缩的目录源数据尾部添加所述签名信息的目录数据；

[0061] 相应修改所述原始 APK文件的目录结束标识结构。

[0062] 由上述描述可知，收单机构的签名工具可以利用终端操作系统自带的 AAPT工具，将压缩后的签名信息放置在原始 APK指定的目录下，同吋相应修改目录数据和目录结束标识结构。如图 7所示，插入所述签名信息后生成的签名后 APK文件，还是符合 APK文件格式，只是在 APK文件内部 META-INF目录下存放签名信息 SGN。对终端的操作系统的原生验签过程并不影响，所以在更高级版本的操作系统上，如 Android 5.0以上的终端设备，也可以正常安装。

[0063] 进一步的，所述"获取所述签名后 APK文件中的签名信息；获取原始 APK文件" 具体为：

[0064] 从所述 META-INF目录下拷贝出所述签名信息；

[0065] 刪除所述签名后 APK文件中所述压缩的文件内容源数据尾部的所述压缩后的所述签名信息；

[0066] 刪除所述压缩的目录源数据尾部的所述签名信息的目录数据；

[0067] 相应修改所述原始 APK文件的目录结束标识结构，还原所述原始 APK文件。

[0068] 由上述描述可知，在终端的厂商验证所获取的签名后 APK文件之前，需要先将插入原始 APK文件的签名信息拷贝出来，还原原始 APK文件，具体为刪除所插入的所有数据，确保在厂商验证过程中，对核心数据的计算不会出错，所述核心数据中的原始 APK文件与收单机构签名吋的原始 APK文件完全一致，顺利通过厂商验证。

[0069] 如图 2所示，进一步的，所述"对原始 APK文件和收单机构签名描述信息进行签名，得到签名信息 "具体为：

[0070] 收单机构生成收单机构工作公钥证书，将与收单机构工作公钥证书对应的公钥分发至不同厂商；

[0071] 收单机构对包含原始 APK文件和收单机构签名描述信息的被签名数据计算哈希

，得到第一哈希值；

[0072] 填充所述第一哈希值，得到填充后的数据；

[0073] 收单机构获取与收单机构工作公钥证书对应的私钥，并利用私钥对所述填充后的数据进行签名，生成收单机构签名数据；

[0074] 生成包含所述收单机构签名描述信息、收单机构签名数据、收单机构工作公钥证书的签名信息。

[0075] 进一步的，所述"终端验证所述签名信息和所述原始 APK文件的合法性"具体为

[0076] 不同厂商根据各自的证书生成机制使用所述公钥生成收单机构根公钥证书，并预装在厂商的终端中；

[0077] 终端使用收单机构根证书验证所述签名信息中的收单机构工作公钥证书的合法性； [0078] 若验证通过，则使用收单机构工作公钥证书验证所述收单机构签名数据的合法性；

[0079] 若验证通过，获取第一哈希值；

[0080] 对所述收单机构签名描述信息和原始 APK文件计算哈希，得到第二哈希值； [0081] 判断所述第二哈希值与第一哈希值是否一致，若一致，则验证通过。

[0082] 由上述描述可知，在本发明中，收单机构签名的对象为原始 APK文件和收单机构签名描述信息；同吋，通过收单机构统一生成收单机构工作公钥证书，分发生成收单机构工作公钥证书的公钥至不同的厂商，不同厂商的 CA服务器根据各自的证书生成算法使用公钥生成收单机构根公钥证书后，将所述收单机构根公钥证书预装在厂商的终端设备中，每个厂商生成的收单机构根公钥证书都是不一样的，用于日后验签各自收到的签名后 APK文件。终端利用收单机构统一分发的公钥进行各自验签，保证已签名 APK文件在数据传输过程的完整性和 APK 合法性，收单机构针对不同厂商的终端设备也只需维护一个已签名的文件和一套签名实现机制，大大缩减了收单机构针对 APK签名的维护成本。

[0083] 请参阅图 8至图 12，本发明提供的另一个技术方案为：

[0084] 如图 8所示，一种 APK签名认证系统，包括收单机构 1和终端 2，所述收单机构 1 包括安全存储模块 11、签名执行模块 12和签名组织模块 13; 所述终端 2包括第一获取模块 21、第二获取模块 22、第三获取模块 23、签名验证模块 24以及安装执行模块 25;

[0085] 所述安全存储模块 11，用于存储收单机构 1的工作公钥证书和所述工作公钥证书对应的私钥；

[0086] 所述签名执行模块 12，用于对原始 APK文件和收单机构 1签名描述信息进行签名，得到签名信息；

[0087] 所述签名组织模块 13，用于插入签名信息至原始 APK文件内部的 META-INF目录下，生成签名后 APK文件；

[0088] 所述第一获取模块 21，用于终端 2获取所述签名后 APK文件；

[0089] 所述第二获取模块 22，用于获取所述签名后 APK文件中的签名信息；

[0090] 所述第三获取模块 23，用于终端 2获取原始 APK文件； [0091] 所述签名验证模块 24，用于终端 2验证所述签名信息和所述原始 APK文件的合法性；

[0092] 所述安装执行模块 25，用于所述签名验证模块 24验证通过后，终端 2安装所述原始 APK文件。

[0093] 进一步的，所述第三获取模块 23包括刪除还原单元和 /或提取单元；

[0094] 所述刪除还原单元，用于刪除所述签名后 APK文件中的签名信息，还原所述原始 APK文件；

[0095] 所述提取单元，用于从所述签名后 APK文件的二进制数据中提取所述原始 APK 文件。

[0096] 如图 9和 10所示，进一步的，所述签名组织模块 13包括第一添加单元 131、第二添加和第一修改单元 133; 所述刪除还原单元包括拷贝单元 231、第一刪除单元 2

32、第二刪除单元 233和第二修改单元 234;

[0097] 所述第一添加单元 131，用于在原始 APK文件的压缩的文件内容源数据尾部添加经过压缩后的所述签名信息；

[0098] 所述第二添加单元 132，用于在压缩的目录源数据尾部添加所述签名信息的目录数据；

[0099] 所述第一修改单元 133，用于相应修改所述原始 APK文件的目录结束标识结构

[0100] 所述拷贝单元 231，用于从所述 META-INF目录下拷贝出所述签名信息；

[0101] 所述第一刪除单元 232，用于刪除所述签名后 APK文件中所述压缩的文件内容源数据尾部的所述压缩后的所述签名信息；

[0102] 所述第二刪除单元 233，用于刪除所述压缩的目录源数据尾部的所述签名信息的目录数据；

[0103] 所述第二修改单元 234，用于相应修改所述原始 APK文件的目录结束标识结构，还原所述原始 APK文件。

[0104] 如图 11所示，进一步的，所述签名执行模块 12包括第一生成单元 121、第一计算单元 122、第一签名单元 123、第二签名单元 124和第二生成单元 125; 所述签名验证模块 24包括第三生成单元 241、第一验证单元 242、第二验证单元 243、获取单元 244、第二计算单元 245和判断单元 246;

[0105] 第一生成单元 121，用于收单机构 1生成收单机构 1工作公钥证书，将与收单机构 1工作公钥证书对应的公钥分发至不同厂商；

[0106] 第一计算单元 122，用于收单机构 1对包含原始 APK文件和收单机构 1签名描述信息的被签名数据计算哈希，得到第一哈希值；

[0107] 第一签名单元 123，用于填充所述第一哈希值，得到填充后的数据；

[0108] 第二签名单元 124，用于收单机构 1获取与收单机构 1工作公钥证书对应的私钥

，并利用私钥对所述填充后的数据进行签名，生成收单机构 1签名数据；

[0109] 第二生成单元 125，用于生成包含所述收单机构 1签名描述信息、收单机构 1签名数据、收单机构 1工作公钥证书的签名信息；

[0110] 第三生成单元 241，用于不同厂商根据各自的证书生成机制使用所述公钥生成收单机构 1根公钥证书，并预装在厂商的终端 2中；

[0111] 第一验证单元 242，用于终端 2使用收单机构 1根证书验证所述签名信息中的收单机构 1工作公钥证书的合法性；

[0112] 第二验证单元 243，用于若第一验证单元 242验证通过，则使用收单机构 1工作公钥证书验证所述收单机构 1签名数据的合法性；

[0113] 获取单元 244，用于若第二验证单元 243验证通过，获取第一哈希值；

[0114] 第二计算单元 245，用于对所述收单机构 1签名描述信息和原始 APK文件计算哈希，得到第二哈希值；

[0115] 判断单元 246，用于判断所述第二哈希值与第一哈希值是否一致，若一致，则验证通过。

[0116] 请参照图 2，本发明的实施例一为：

[0117] 提供一种 APK签名认证方法，该方法具体可以包括：

[0118] S1 : 收单机构 1签名服务器调用加密设备生成第一公私钥对和第二公私钥对，收单机构 1签名服务器使用第一私钥对第二公钥进行签名操作生成收单机构 1工作公钥证书 AcquirerWCRT, 将第一公钥分发至不同厂商的 CA服务器；

[0119] S2: 收单机构 1的签名服务器将原始 APK文件和收单机构 1签名描述信息一起作为被签名数据 SourceData; 对被签名数据 SourceData计算哈希，获得第一哈希值 HASH1 ; 将第一哈希值 HASH1按照 PKCS#1_V1.5的签名填充方式进行填充，获得填充后的数据 PAD_data；

[0120] S3：收单机构 1的签名服务器通从安全存储介质中获取与收单机构 1工作公钥证书对应的第二私钥，并利用第二私钥对所述填充后的数据进行加密签名，生成收单机构 1签名数据 Signature;

[0121] S4: 将收单机构 1签名描述信息、收单机构 1签名数据 Signature 收单机构 1工作公钥证书 AcquirerWCRT和签名文件头一起拼接生成收单机构 1的签名信息 SGN

，并进行压缩；

[0122] S5: 收单机构 1的签名工具利用终端 2的操作系统自带的 aapt工具，将签名信息 SGN插入到原始 APK文件内部的 META-INF目录下，生成签名后 APK文件，插入所述签名信息 SNG后的原始 APK文件的格式对比如图 5所示；具体插入过程可以包括：

[0123] S51 : 在原始 APK文件的压缩的文件内容源数据尾部添加一条压缩后的所述签名信息 SNG;

[0124] S52: 在压缩的目录源数据尾部添加一条所述签名信息 SNG的目录数据；

[0125] S53: 相应修改所述原始 APK文件的目录结束标识结构，其中的目录总数加 1、目录大小加上签名信息 SGN的目录数据大小、目录偏移位置加上签名信息 SGN 压缩的文件数据大小。

[0126] S6: 不同厂商的 CA服务器根据各自的证书生成机制使用收单机构 1下发的第一公钥生成收单机构 1根公钥证书，并将所述收单机构 1根公钥证书预装在厂商各自的终端 2设备中；

[0127] 如图 6所示，

[0128] S7: 不同厂商的终端 2设备通过自动下载或者周期自检的方式获取生成的签名后 APK文件；

[0129] S8: 将所述签名后 APK文件内部的 META-INF目录下的签名信息 SGN拷贝出来，同吋将签名信息 SGN从所述签名后 APK文件中刪除，还原得到原始 APK文件；具体步骤可以包括：

[0130] S81 : 刪除所述签名后 APK文件中所述压缩的文件内容源数据尾部的所述压缩后的所述签名信息 SNG;

[0131] S82: 刪除所述压缩的目录源数据尾部的所述签名信息 SNG的目录数据；

[0132] S83: 相应修改所述原始 APK文件的目录结束标识结构，还原所述原始 APK文件；包括其中的目录总数减 1、目录大小减去签名信息 SGN的目录数据大小、目录偏移位置减去签名信息 SGN压缩的文件数据大小；

[0133] S9: 解压已压缩的签名信息 SGN，获取其中的收单机构 1签名描述信息、收单机构 1签名数据 Signature、收单机构 1工作公钥证书 AcquirerWCRT和签名文件头

[0134] S10: 幵始厂商对终端 2所获取的签名后 APK文件的合法性验证过程；具体包括

[0135] S101 : 终端 2使用预存在终端 2中的收单机构 1根证书验证所述签名信息中的收单机构 1工作公钥证书 AcquirerWCRT的合法性；若验证通过，则终端 2设备使用收单机构 1工作公钥证书 AcquirerWCRT提取第二公钥，使用第二公钥解密所述收单机构 1签名数据，解密成功，获得第一哈希值 HASH1 ;

[0136] S102: 终端 2对步骤 S9中解压获取到的所述收单机构 1签名描述信息和步骤 S83 还原的原始 APK文件一起计算哈希，得到第二哈希值 HASH2;

[0137] 需要说明的是，由于在 S83中已经还原了原始 APK文件，由此确保第二哈希值计算的对象 APK文件与步骤 S2中第一哈希值的计算对象原始 APK文件是一致的

，所计算的内容将不会包含签名信息 SGN，保证哈希计算的准确性。

[0138] S103: 判断所述第二哈希值与第一哈希值是否一致，若一致，则证明终端 2所获取到的签名后 APK文件合法，未被篡改，厂商设备对签名后 APK文件的验证通过，允许终端 2安装所述原始 APK文件；

[0139] S11 : 在终端 2安装 APK文件的过程中，终端 2的操作系统也需要对所述签名后

APK文件的合法性进行验证，即终端 2的原生验证过程；

[0140] 具体验证过程包括：操作系统计算所述签名后 APK文件的整体长度，判断所述签名后 APK文件 +尾部数据长度是否等于源文件长度，若相等，则继续安装，若不相等，则安装失败。

[0141] 需要说明的是，原始 APK文件内部的 META-INF目录下的数据不包含的计算范围内，因此所插入的签名信息不会被计算在内，不对操作系统的原生验证产生影响，终端 2更高版本的操作系统也能正常的安装。

[0142] 本发明的实施例二为：

[0143] 在实施例一的基础上，步骤 S5所述的还原原始 APK文件的方式还可以是直接从所获取到的签名后 APK文件的二进制数据中提取出所述原始 APK文件。

[0144] 步骤 S3中的安全存储介质为存储有第二私钥的签名卡，由收单机构 1的授权工作人员持有。

[0145] 步骤 S51中所述的"压缩的文件内容源数据"记录着压缩的所有文件的内容信息；其数据组织结构对应每个文件都由 file header、 file data、 data descriptor三部分组成； File header: 用于标识该文件的幵始； file data

：相应压缩文件的源数据； data descriptor: 用于标识该文件压缩结束，该结构只有在相应的 header中通用标记字段的第 3位设为 1吋才会出现，紧接在压缩文件源数据后。这个数据描述符只用在不能对输出的 ZIP文件进行检索吋使用；

[0146] 所述的 "压缩的目录源数据 "指的是对于压缩的目录而言，每一个子目录对应一个压缩目录源数据，记录该目录的描述信息。压缩包中所有目录源数据连续存储在整个归档包的最后，这样便于向包中追加新的文件；

[0147] 所述的"目录结束标识结构"存在于整个归档包的结尾，用于标记压缩的目录数据的结束；

[0148] 如图 4所示，所述"收单机构 1签名描述信息 "用于存储包括收单机构 1工作公钥证书的 ID号、签名使用的算法和签名吋间；

[0149] 步骤 S4中的所述"签名文件头"标识签名文件类型和表示所有签名的数据偏移和长度，定位签名数据，之后用于验证签名；所述收单机构 1签名数据的签名使用的算法优选为 SHA-256和 RSA; 所述收单机构 1签名数据的偏移位置和签名文件的偏移长度均是从文件最幵始处计算得出的偏移长度。

[0150] 请参阅图 8，本发明提供的实施例三为：

[0151] 一种 APK签名认证系统，包括收单机构 1服务器和终端 2设备服务器，所述收单机构 1服务器包括安全存储模块 11、签名执行模块 12和签名组织模块 13 ; 所述终端 2设备服务器包括第一获取模块 21、第二获取模块 22、第三获取模块 23、签名验证模块 24以及安装执行模块 25，所述第三获取模块 23包括刪除还原单元和 /或提取单元；

[0152] 所述安全存储模块 11，用于存储收单机构 1的工作公钥证书和所述工作公钥证书对应的私钥；

[0153] 所述签名执行模块 12，用于对原始 APK文件和收单机构 1签名描述信息进行签名，得到签名信息；如图 11所示，具体包括第一生成单元 121、第一计算单元 12 2、第一签名单元 123、第二签名单元 124和第二生成单元 125; 第一生成单元 121 ，用于收单机构 1生成收单机构 1工作公钥证书，将与收单机构 1工作公钥证书对应的公钥分发至不同厂商；第一计算单元 122，用于收单机构 1对包含原始 APK 文件和收单机构 1签名描述信息的被签名数据计算哈希，得到第一哈希值；第一签名单元 123，用于填充所述第一哈希值，得到填充后的数据；第二签名单元 12 4，用于收单机构 1获取与收单机构 1工作公钥证书对应的私钥，并利用私钥对所述填充后的数据进行签名，生成收单机构 1签名数据；第二生成单元 125，用于生成包含所述收单机构 1签名描述信息、收单机构 1签名数据、收单机构 1工作公钥证书的签名信息；

[0154] 所述签名组织模块 13，用于插入签名信息至原始 APK文件内部的 META-INF目录下，生成签名后 APK文件；

[0155] 如图 9所示，所述签名组织模块 13具体包括第一添加单元 131、第二添加和第一修改单元 133; 所述第一添加单元 131，用于在原始 APK文件的压缩的文件内容源数据尾部添加经过压缩后的所述签名信息；所述第二添加单元 132，用于在压缩的目录源数据尾部添加所述签名信息的目录数据；所述第一修改单元 133，用于相应修改所述原始 APK文件的目录结束标识结构；

[0156] 所述第一获取模块 21，用于终端 2获取所述签名后 APK文件；

[0157] 所述第二获取模块 22，用于获取所述签名后 APK文件中的签名信息；

[0158] 所述第三获取模块 23，用于终端 2获取原始 APK文件；如图 10所示，具体的，若第三获取模块 23包括刪除还原单元，则通过所述刪除还原单元刪除所述签名后 APK文件中的签名信息，还原所述原始 APK文件；所述刪除还原单元包括拷贝单元 231、第一刪除单元 232、第二刪除单元 233和第二修改单元 234; 所述拷贝单元 231，用于从所述 META-INF目录下拷贝出所述签名信息；所述第一刪除单元 232，用于刪除所述签名后 APK文件中所述压缩的文件内容源数据尾部的所述压缩后的所述签名信息；所述第二刪除单元 233，用于刪除所述压缩的目录源数据尾部的所述签名信息的目录数据；所述第二修改单元 234，用于相应修改所述原始 APK文件的目录结束标识结构，还原所述原始 APK文件。

[0159] 若第三获取模块 23包括提取单元，则通过所述提取单元从所述签名后 APK文件的二进制数据中提取所述原始 APK文件；所述第三获取模块 23可以同吋包含所述刪除还原单元和提取单元，或者择一配置，其目的都在于还原所述原始 APK 文件。

[0160] 如图 12所示，所述签名验证模块 24，用于终端 2验证所述签名信息和所述原始 A PK文件的合法性；具体包括第三生成单元 241、第一验证单元 242、第二验证单元 243、获取单元 244、第二计算单元 245和判断单元 246; 第三生成单元 241，用于不同厂商根据各自的证书生成机制使用所述公钥生成收单机构 1根公钥证书，并预装在厂商的终端 2中；第一验证单元 242，用于终端 2使用收单机构 1根证书验证所述签名信息中的收单机构 1工作公钥证书的合法性；第二验证单元 243，用于若第一验证单元 242验证通过，则使用收单机构 1工作公钥证书验证所述收单机构 1签名数据的合法性；获取单元 244，用于若第二验证单元 243验证通过，获取第一哈希值；第二计算单元 245，用于对所述收单机构 1签名描述信息和原始 APK文件计算哈希，得到第二哈希值；判断单元 246，用于判断所述第二哈希值与第一哈希值是否一致，若一致，则验证通过。

[0161] 所述安装执行模块 25，用于所述签名验证模块 24验证通过后，终端 2安装所述原始 APK文件。

[0162] 实施例一至实施例三中的终端 2设备为 POS机或者其他智能支付终端 2，终端 2 设备的操作系统为 Android系统，使用 Android

SDK自带的 aapt工具将签名信息 SGN插入到原始 APK文件内部的 META-INF目录下。

[0163] 综上所述，本发明提供的一种 APK签名认证方法及其系统，不仅能够实现收单机构只要生成一个已签名的 APK文件，就能够下载到支付终端厂商的终端设备及其他 Android设备上，减少收单机构的维护成本，只要维护一个统一的 APK; 而且可以将该 APK下载到未弓 I进该数字签名的 Android终端设备上，不影响原先的 APK下载安装；进一步的，还能兼容更高版本的终端设备，确保终端设备的正常安装，最终实现兼容终端操作系统的原生签名机制，提高统一 APK签名认证方式的兼容性。

Claims

权利要求书

[权利要求 1] 一种 APK签名认证方法，其特征在于，包括：

对原始 APK文件和收单机构签名描述信息进行签名，得到签名信息；插入签名信息至原始 APK文件内部的 META-INF目录下，生成签名后 APK文件；

终端获取所述签名后 APK文件；

获取所述签名后 APK文件中的签名信息；获取原始 APK文件；终端验证所述签名信息和所述原始 APK文件的合法性，验证通过后，终端安装所述原始 APK文件。

[权利要求 2] 如权利要求 1所述的一种 APK签名认证方法，其特征在于，所述"获取原始 APK文件"具体为：

刪除所述签名后 APK文件中的签名信息，还原所述原始 APK文件；或者

从所述签名后 APK文件的二进制数据中提取所述原始 APK文件。

[权利要求 3] 如权利要求 1所述的一种 APK签名认证方法，其特征在于，所述"插入签名信息至原始 APK文件内部的 META-INF目录下"具体为：在原始 APK文件的压缩的文件内容源数据尾部添加经过压缩后的所述签名信息；

在压缩的目录源数据尾部添加所述签名信息的目录数据；

相应修改所述原始 APK文件的目录结束标识结构。

[权利要求 4] 如权利要求 3所述的一种 APK签名认证方法，其特征在于，所述"获取所述签名后 APK文件中的签名信息；获取原始 APK文件"具体为：从所述 META-INF目录下拷贝出所述签名信息；刪除所述签名后 APK文件中所述压缩的文件内容源数据尾部的所述压缩后的所述签名信息；

刪除所述压缩的目录源数据尾部的所述签名信息的目录数据；相应修改所述原始 APK文件的目录结束标识结构，还原所述原始 APK 文件。

[权利要求 5] 如权利要求 1所述的一种 APK签名认证方法，其特征在于，所述"对原始 APK文件和收单机构签名描述信息进行签名，得到签名信息 "具体为：

收单机构生成收单机构工作公钥证书，将与收单机构工作公钥证书对应的公钥分发至不同厂商；

收单机构对包含原始 APK文件和收单机构签名描述信息的被签名数据计算哈希，得到第一哈希值；

填充所述第一哈希值，得到填充后的数据；

收单机构获取与收单机构工作公钥证书对应的私钥，并利用私钥对所述填充后的数据进行签名，生成收单机构签名数据；

生成包含所述收单机构签名描述信息、收单机构签名数据、收单机构工作公钥证书的签名信息。

[权利要求 6] 如权利要求 5所述的一种 APK签名认证方法，其特征在于，所述"终端验证所述签名信息和所述原始 APK文件的合法性 "具体为：不同厂商根据各自的证书生成机制使用所述公钥生成收单机构根公钥证书，并预装在厂商的终端中；

终端使用收单机构根证书验证所述签名信息中的收单机构工作公钥证书的合法性；

若验证通过，则使用收单机构工作公钥证书验证所述收单机构签名数据的合法性；

若验证通过，获取第一哈希值；

对所述收单机构签名描述信息和原始 APK文件计算哈希，得到第二哈希值；

判断所述第二哈希值与第一哈希值是否一致，若一致，则验证通过。

[权利要求 7] —种 APK签名认证系统，其特征在于，包括收单机构和终端，所述收单机构包括安全存储模块、签名执行模块和签名组织模块；所述终端包括第一获取模块、第二获取模块、第三获取模块、签名验证模块以及安装执行模块；所述安全存储模块，用于存储收单机构的工作公钥证书和所述工作公钥证书对应的私钥；

所述签名执行模块，用于对原始 APK文件和收单机构签名描述信息进行签名，得到签名信息；

所述签名组织模块，用于插入签名信息至原始 APK文件内部的 META

-INF目录下，生成签名后 APK文件；

所述第一获取模块，用于终端获取所述签名后 APK文件；

所述第二获取模块，用于获取所述签名后 APK文件中的签名信息；所述第三获取模块，用于终端获取原始 APK文件；所述签名验证模块，用于终端验证所述签名信息和所述原始 APK文件的合法性；

所述安装执行模块，用于所述签名验证模块验证通过后，终端安装所述原始 APK文件。

[权利要求 8] 如权利要求 7所述的一种 APK签名认证系统，其特征在于，所述第三获取模块包括刪除还原单元和 /或提取单元；

所述刪除还原单元，用于刪除所述签名后 APK文件中的签名信息，还原所述原始 APK文件；

所述提取单元，用于从所述签名后 APK文件的二进制数据中提取所述原始 APK文件。

[权利要求 9] 如权利要求 7所述的一种 APK签名认证系统，其特征在于，所述签名组织模块包括第一添加单元、第二添加和第一修改单元；所述刪除还原单元包括拷贝单元、第一刪除单元、第二刪除单元和第二修改单元所述第一添加单元，用于在原始 APK文件的压缩的文件内容源数据尾部添加经过压缩后的所述签名信息；

所述第二添加单元，用于在压缩的目录源数据尾部添加所述签名信息的目录数据；

所述第一修改单元，用于相应修改所述原始 APK文件的目录结束标识结构；

所述拷贝单元，用于从所述 META-INF目录下拷贝出所述签名信息；所述第一刪除单元，用于刪除所述签名后 APK文件中所述压缩的文件内容源数据尾部的所述压缩后的所述签名信息；所述第二刪除单元，用于刪除所述压缩的目录源数据尾部的所述签名信息的目录数据；

所述第二修改单元，用于相应修改所述原始 APK文件的目录结束标识结构，还原所述原始 APK文件。

[权利要求 10] 如权利要求 7所述的一种 APK签名认证系统，其特征在于，所述签名执行模块包括第一生成单元、第一计算单元、第一签名单元、第二签名单元和第二生成单元；所述签名验证模块包括第三生成单元、第一验证单元、第二验证单元、获取单元、第二计算单元和判断单元；第一生成单元，用于收单机构生成收单机构工作公钥证书，将与收单机构工作公钥证书对应的公钥分发至不同厂商；第一计算单元，用于收单机构对包含原始 APK文件和收单机构签名描述信息的被签名数据计算哈希，得到第一哈希值；第一签名单元，用于填充所述第一哈希值，得到填充后的数据；第二签名单元，用于收单机构获取与收单机构工作公钥证书对应的私钥，并利用私钥对所述填充后的数据进行签名，生成收单机构签名数据；

第二生成单元，用于生成包含所述收单机构签名描述信息、收单机构签名数据、收单机构工作公钥证书的签名信息；第三生成单元，用于不同厂商根据各自的证书生成机制使用所述公钥生成收单机构根公钥证书，并预装在厂商的终端中；

第一验证单元，用于终端使用收单机构根证书验证所述签名信息中的收单机构工作公钥证书的合法性；

第二验证单元，用于若第一验证单元验证通过，则使用收单机构工作公钥证书验证所述收单机构签名数据的合法性；获取单元，用于若第二验证单元验证通过，获取第一哈希值；第二计算单元，用于对所述收单机构签名描述信息和原始 APK文件计算哈希，得到第二哈希值；

判断单元，用于判断所述第二哈希值与第一哈希值是否一致，若一致，则验证通过。