WO2017080262A1 - 一种 apk 签名认证方法及其*** - Google Patents
一种 apk 签名认证方法及其*** Download PDFInfo
- Publication number
- WO2017080262A1 WO2017080262A1 PCT/CN2016/092815 CN2016092815W WO2017080262A1 WO 2017080262 A1 WO2017080262 A1 WO 2017080262A1 CN 2016092815 W CN2016092815 W CN 2016092815W WO 2017080262 A1 WO2017080262 A1 WO 2017080262A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- signature
- apk file
- unit
- file
- original
- Prior art date
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
Definitions
- the installation execution module is configured to: after the verification by the signature verification module, the terminal installs the original A PK file.
- the “acquiring the signature information in the APK file after the signature; acquiring the original APK file” Specifically:
- the second adding unit 132 is configured to add the directory data of the signature information at the end of the compressed directory source data
- the second modifying unit 234 is configured to correspondingly modify a directory end identifier structure of the original APK file, and restore the original APK file.
- the third generating unit 241 is configured to generate, by the different vendors, the public key by using the public key according to the respective certificate generating mechanism, and pre-installed in the terminal 2 of the manufacturer;
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Storage Device Security (AREA)
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文件计 算哈希, 得到第二哈希值;
判断单元, 用于判断所述第二哈希值与第一哈希值是否一致, 若一致 , 则验证通过。
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201510780639.0 | 2015-11-13 | ||
CN201510780639.0A CN105391717B (zh) | 2015-11-13 | 2015-11-13 | 一种apk签名认证方法及其*** |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2017080262A1 true WO2017080262A1 (zh) | 2017-05-18 |
Family
ID=55423553
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/CN2016/092815 WO2017080262A1 (zh) | 2015-11-13 | 2016-08-02 | 一种 apk 签名认证方法及其*** |
Country Status (2)
Country | Link |
---|---|
CN (1) | CN105391717B (zh) |
WO (1) | WO2017080262A1 (zh) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112348499A (zh) * | 2020-11-09 | 2021-02-09 | 百富计算机技术(深圳)有限公司 | 支付终端的通信服务方法及装置 |
CN115297043A (zh) * | 2022-08-05 | 2022-11-04 | 广东电网有限责任公司 | 配网指令防篡改装置的测试*** |
Families Citing this family (17)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105391717B (zh) * | 2015-11-13 | 2019-01-04 | 福建联迪商用设备有限公司 | 一种apk签名认证方法及其*** |
CN107222453B (zh) * | 2016-03-22 | 2020-01-31 | 阿里巴巴集团控股有限公司 | 一种文件传输方法及装置 |
CN105787357B (zh) * | 2016-03-28 | 2019-01-04 | 福建联迪商用设备有限公司 | 一种基于安卓***apk下载方法及其*** |
CN105743910B (zh) * | 2016-03-30 | 2019-01-04 | 福建联迪商用设备有限公司 | 通过数字签名安装程序的方法及*** |
CN106209379B (zh) * | 2016-07-04 | 2019-09-10 | 江苏先安科技有限公司 | 一种Android APK副署签名及验证方法 |
CN106656513B (zh) * | 2017-02-24 | 2019-09-13 | 福建魔方电子科技有限公司 | 安卓平台上apk文件的二次打包签名验证方法 |
CN107301343B (zh) * | 2017-06-19 | 2021-03-26 | 大连中科创达软件有限公司 | 安全数据处理方法、装置及电子设备 |
CN109120419B (zh) * | 2017-06-22 | 2023-06-20 | 中兴通讯股份有限公司 | 光网络单元onu版本的升级方法、装置及存储介质 |
WO2019080110A1 (zh) * | 2017-10-27 | 2019-05-02 | 福建联迪商用设备有限公司 | 一种 apk 签名认证方法及*** |
CN110851821A (zh) * | 2019-11-01 | 2020-02-28 | 艾体威尔电子技术(北京)有限公司 | 一种Android智能设备APK安全管控方法 |
CN113377382A (zh) * | 2020-03-09 | 2021-09-10 | 北京字节跳动网络技术有限公司 | 一种软件安装包的处理方法、装置、电子设备及存储介质 |
CN111787529B (zh) * | 2020-07-17 | 2021-06-29 | 江苏海全科技有限公司 | 适于Android智能POS机应用的签名方法和*** |
CN114547593A (zh) * | 2020-11-18 | 2022-05-27 | 成都鼎桥通信技术有限公司 | 终端应用认证方法、装置及设备 |
CN112560017B (zh) * | 2020-12-21 | 2022-12-06 | 福建新大陆支付技术有限公司 | 一种使用三级证书认证实现apk统一签名的方法 |
CN113779513A (zh) * | 2021-09-15 | 2021-12-10 | 广州易方信息科技股份有限公司 | Zip文件的标识***方法、装置、计算机设备和存储介质 |
CN114301601B (zh) * | 2021-12-28 | 2023-11-03 | 福建汇思博数字科技有限公司 | 一种基于Android平台的接口管理方法及终端 |
CN116881035B (zh) * | 2023-07-20 | 2024-06-14 | 上海弘连网络科技有限公司 | 文件修复方法、存储介质及电子设备 |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103886260A (zh) * | 2014-04-16 | 2014-06-25 | 中国科学院信息工程研究所 | 一种基于二次签名验签技术的应用程序管控方法 |
CN103905207A (zh) * | 2014-04-23 | 2014-07-02 | 福建联迪商用设备有限公司 | 一种统一apk签名的方法及其*** |
CN104156638A (zh) * | 2014-06-06 | 2014-11-19 | 国家计算机网络与信息安全管理中心 | 一种面向安卓***软件的扩展签名的实现方法 |
WO2014205765A1 (zh) * | 2013-06-28 | 2014-12-31 | 深圳市掌讯通讯设备有限公司 | 一种安卓智能设备间软件自动安装与同步方法 |
CN105391717A (zh) * | 2015-11-13 | 2016-03-09 | 福建联迪商用设备有限公司 | 一种apk签名认证方法及其*** |
-
2015
- 2015-11-13 CN CN201510780639.0A patent/CN105391717B/zh active Active
-
2016
- 2016-08-02 WO PCT/CN2016/092815 patent/WO2017080262A1/zh active Application Filing
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2014205765A1 (zh) * | 2013-06-28 | 2014-12-31 | 深圳市掌讯通讯设备有限公司 | 一种安卓智能设备间软件自动安装与同步方法 |
CN103886260A (zh) * | 2014-04-16 | 2014-06-25 | 中国科学院信息工程研究所 | 一种基于二次签名验签技术的应用程序管控方法 |
CN103905207A (zh) * | 2014-04-23 | 2014-07-02 | 福建联迪商用设备有限公司 | 一种统一apk签名的方法及其*** |
CN104156638A (zh) * | 2014-06-06 | 2014-11-19 | 国家计算机网络与信息安全管理中心 | 一种面向安卓***软件的扩展签名的实现方法 |
CN105391717A (zh) * | 2015-11-13 | 2016-03-09 | 福建联迪商用设备有限公司 | 一种apk签名认证方法及其*** |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112348499A (zh) * | 2020-11-09 | 2021-02-09 | 百富计算机技术(深圳)有限公司 | 支付终端的通信服务方法及装置 |
CN115297043A (zh) * | 2022-08-05 | 2022-11-04 | 广东电网有限责任公司 | 配网指令防篡改装置的测试*** |
Also Published As
Publication number | Publication date |
---|---|
CN105391717A (zh) | 2016-03-09 |
CN105391717B (zh) | 2019-01-04 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
WO2017080262A1 (zh) | 一种 apk 签名认证方法及其*** | |
CN102830992B (zh) | 插件加载方法及*** | |
CN104346167B (zh) | 生成应用渠道包的方法及装置 | |
WO2017166561A1 (zh) | 一种基于安卓***apk下载方法及其*** | |
CN103886260B (zh) | 一种基于二次签名验签技术的应用程序管控方法 | |
WO2019080110A1 (zh) | 一种 apk 签名认证方法及*** | |
CN112507328B (zh) | 一种文件签名方法、计算设备及存储介质 | |
JP5357152B2 (ja) | 情報処理装置、情報処理方法、これらを実現するコンピュータプログラム及び集積回路 | |
CN102685727B (zh) | 一种应用程序发送、运行方法、***、服务器和终端 | |
WO2015161683A1 (zh) | 一种统一apk签名的方法及其*** | |
CN101436141A (zh) | 基于数字签名的固件升级、固件封装方法与装置 | |
WO2015161682A1 (zh) | 一种多方授权的apk签名方法及*** | |
CN111125725A (zh) | 一种镜像校验的加解密方法、设备及介质 | |
CN112560017B (zh) | 一种使用三级证书认证实现apk统一签名的方法 | |
CN110879713B (zh) | 一种android端强加密插件热更新管理方法 | |
CN105706099A (zh) | 软件更新装置及软件更新程序 | |
CN104573527A (zh) | 一种基于更新安全机制的uefi***更新方法 | |
CN106789075B (zh) | Pos数字签名防切机*** | |
TW201721417A (zh) | 一種交易終端升級的方法及裝置 | |
CN110021291B (zh) | 一种语音合成文件的调用方法及装置 | |
CN103825724A (zh) | 一种自动更新和恢复私钥的标识型密码***及方法 | |
WO2023065823A1 (zh) | 一种软件开发工具包修复方法、终端、服务器及设备 | |
KR20170089352A (ko) | 가상화 시스템에서 수행하는 무결성 검증 방법 | |
CN106709281B (zh) | 补丁发放和获取方法、装置 | |
CN107239299A (zh) | 插件升级方法及装置 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 16863440 Country of ref document: EP Kind code of ref document: A1 |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 16863440 Country of ref document: EP Kind code of ref document: A1 |