一种基于v2或v3签名机制的第三方副署签名及验证方法
技术领域
本发明属于计算机信息安全技术，用于为安卓应用软件原生V2/V3签名机制提供一 种第三方副署签名方法。
背景技术
安卓系统要求所有的应用程序必须签名后才能安装，但并没有对签名证书做严格限 制，任何一张自签名证书都可以用来做签名，签名证书一般由开发者自己生成，所有开发者可随意设置证书主题项内容，很容易恶意伪造其他开发者的签名证书。同时签名证 书和私钥一般以普通数据文件形式存放，可能会被复制、传播并恶意使用，一旦发生， 使得追溯Android应用的真实开发者变得十分困难。
副署签名是在已经签名过的文件上附加签名，作为对已签名文件的认可和证明，其 目的在于证明文件中的数据、动作或规定已签名者和副署签名者认可。
安卓应用程序第三方数字签名是一种副署签名，副署签名由签名发起方(应用开发 者、检测机构、应用商店等)使用第三方合法CA机构签发的代码签名证书，在不改变 原有安卓应用程序打包签名流程的条件下，对已经打包并签名过的应用程序附加签名。 副署签名可以是一个或多个签名。
目前：专利公布号CN106209379B，一种Android APK副署签名及验证方法针对安卓应用程序原生签名V1版本提出一种安卓应用程序的一种副署签名的方法。
针对目前安卓系统的不断升级，安卓应用程序原生签名V1机制由于其存在很多缺点 和安全隐患，如：
由于签名不保护APK的某些部分，例如ZIP元数据。
APK验证程序需要处理大量不可信(尚未经过验证)的数据结构，然后会舍弃不 受签名保护的数据。这会导致相当大的受攻击面。
APK验证程序必须解压所有已压缩的条目，而这需要花费更多时间和内存。
基于这些缺陷目前逐步被安卓应用程序原生签名V2/V3机制所替代，V2方案(从安卓7.0引入)，V3方案(从安卓9.0引入)。但目前V2/V3签名机制下的副署签名方法还没 有一个在不影响原生签名验证流程下安全可靠的副署签名机制。
发明内容
针对上述技术问题，本发明提出基于安卓原生签名V2/V3机制下的第三方副署签名 方法，不影响安卓签名V2/V3版本原有的验证机制，并能达到副署效果。
为达到上述目的，本发明采用的技术方案为：一种基于V2或V3签名机制的第三 方副署签名方法，通过此方法可以在安卓签名机制V2或V3版本上添加多个副署签名。
在安卓应用程序签名数据块中，找出V2或V3的签名数据块，找到安卓原生签名 者数据块序列，在每一个签名者数据块中找到额外属性addtional attributes数据块，在额外属性数据块中插入ID，额外属性数据块中插入的ID的值为副署签名数据；在V2签 名数据块中，ID非0x7109871a；在V3签名数据块中，ID非0x7109871a或0xf05368c0 或0x3ba06f8c。
进一步的，副署签名是以安卓V2或V3签名数据块中Signatures数据结构中的Signed data中的签名值为原文，使用第三方副署证书的私钥对原文进行签名。在此并不具体约束副署签名数据格式，副署签名数据格式可以是PKCS#7，或者其他副署签名格 式。由于安卓原生签名是对安卓数据块ZIP条路的内容块(Contents of ZIP Entries)，ZIP 中央目录块(Central Directory)，中央目录结尾块(End of Central Directory)的杂凑进行签 名，所以在此位置加入副署签名并不影响原生安卓应用的安装以及升级。
进一步的，上述第三方副署签名方法具体包括以下步骤：
S1、读取安卓应用软件原生签名块，从ID 0x7109871a中获取V2签名数据或从ID0xf05368c0中获取V3签名数据；
S2、读出签发者的数据结构；
S3、生成副署签名数据结构，副署签名数据结构包括版本号，杂凑算法，签发者主题项，签发者证书，签名算法等；
S4、使用原生签名值作为副署签名的原文，对其做杂凑运算，把计算得出的杂凑值设置到可信属性中；
S5、使用副署签名可信属性数据作为原文使用副署签名证书私钥签名；
S6、把副署签名添加到原生签名的额外属性数据块中插入的ID的值中。
最后，签名结束。
作为优选的，S3后进一步包括如下步骤：如副署签名需要加入可信时间，则从可信时间源中获取可信时间，在副署签名数据格式中加入可信时间属性。
进一步的，上述方法中，如果原生签名中有不止一个签发者，则分别读出每一个签发者的数据结构，对每一个签发者的数据结构，执行步骤S3至S6，执行完毕后签名结 束。
本发明还公开一种基于V2或V3签名机制的第三方副署签名验证方法，包括以下步骤：
S11、读取安卓应用软件原生签名块，从ID 0x7109871a中获取V2版本签名数据或从ID0xf05368c0中获取签名数据；
S12、读出签发者的数据结构、副署签名的数据结构；
S13、从副署签名数据结构中获取副署签名的数字证书；
S14、如果需要在线验证数字证书状态，则通过可信证书服务进行验证。
如果不需要在线验证，则在本地验证证书有效性，验证证书链、验证黑白名单。
S15、副署签名证书验证通过后，判断副署签名是否有杂凑属性，如果没有则验证失败；
S16、对原生签名进行杂凑，将计算的杂凑值与杂凑属性中的杂凑值对比，如果不同则验证失败；
S17、把副署签名中可信属性数据作为原文，使用副署签名证书对副署签名值进行验证；如果副署签名值验证不同则验证失败。采用密码学的相关运算进行验证，验证成 功则证明这个证书对应的私钥做的签名的不可抵赖性。
S18、如果还有副署签名则跳转步骤3。
S21、如果还有原生签名则跳转2。
进一步的，如果原生签名中有不止一个签发者，则分别读出每一个签发者的数据结 构、每个签发者的数据结构的每个副署签名的数据结构；对每个签发者对应的所有副署签名均执行S13至S17。
本发明具有以下有益效果：
本发明适用于安卓系统移动应用程序V2或V3签名机制下的第三方副署签名方法，实现了安卓系统移动应用程序V2或V3签名机制下各种副署签名角色(应用开发者， 检测机构，应用商店等)的签名追溯，同时还不改变原有安卓V2或V3签名验证机制。
应用程序副署签名使用的是由第三方合法CA机构颁发的代码签名数字证书，副署签名者的身份由第三方CA机构严格审查并核实。在使用代码签名数字证书对应用程序 副署签名后，在《中华人民共和国电子签名法》的保护下，有如下优势：
副署签名者身份实名认证，可追究法律责任。
应用程序副署签名后，每一个副署环节都可以被追溯。
副署签名由第三方CA机构颁发的代码签名数字证书完成，可信度更高，便于推广。
副署签名，可证明开发者对应用程序的拥有权，在遇到应用程序被盗版，侵权等行为时，将为应用程序开发者提供强有力的证据。
附图说明
图1为安卓应用程序V2，V3签名机制下整体数据结构。
图2为安卓应用程序V2版本下签名数据结构。
图3为本发明实施例的V2签名机制下副署签名的数据格式。
图4为安卓应用程序V3版本下签名数据结构。
图5为本发明实施例的V3签名机制下副署签名的数据格式。
图6为本发明实施例的V2或V3签名机制下副署签名方法流程图。
图7为本发明实施例的V2或V3签名机制下副署签名验证方法流程图。
具体实施方式
为了便于本领域技术人员的理解，下面结合实施例与附图对本发明作进一步的说明。
如图1所示，与安卓应用程序原生签名V1整体数据结构不同的是，V2/V3在原有 移动应用数据块基础上增加了APK签名块(APK Signature Block)，形成包括ZIP条路 的内容块(Contents of ZIP Entries)，APK签名块(APK Signature Block)，ZIP中央目录 块(Central Directory)，中央目录结尾块(End of Central Directory)的四部分数据块，在签 名块中有ID-VALUE配对的数据结构，其中ID为0x7109871a的代表V2签名，ID为0xf05368c0代表V3签名。
安卓应用程序原生签名V2，V3方案并没有一个在不改变Android原生签名验证基础上的副署签名机制，本实施例的方法主要解决在安卓原生签名V2，V3方案下的副署 签名机制。
实施例1：如图2所示，安卓V2签名分块，ID为0x7109871a，格式如下：
·带长度前缀的signer(带长度前缀)序列：
·带长度前缀的signed data：
·带长度前缀的digests(带长度前缀)序列：
·signature algorithm ID(uint32)
·(带长度前缀)digest-请参阅受完整性保护的内容
·带长度前缀的X.509certificates序列：
·带长度前缀的X.509certificate(ASN.1DER格式)
·带长度前缀的additional attributes(带长度前缀)序列：
·ID(uint32)
·value(可变长度：附加属性的长度-4个字节)
·带长度前缀的signatures(带长度前缀)序列：
·signature algorithm ID(uint32)
·signed data上带长度前缀的signature
·带长度前缀的public key(SubjectPublicKeyInfo，ASN.1DER形式)
本实施例是在V2签名块的基础上，实现可以在安卓签名机制V2版本上添加多个副署签名，而不影响安卓签名V2版本原有的验证机制，可以正常的安装及升级，并能 达到副署效果。
如图3所示，具体操作是在安卓应用程序签名数据块中，找出V2签名数据块(ID 为0x7109871a)，找到安卓原生签名者(Signer)数据块序列，在每一个签名者数据块 中找到addtional attributes数据块，在此数据块中插入ID为非0x7109871a的任意ID， ID的值为副署签名数据，副署签名是以安卓V2签名块中Signatures中的Signed data中 的签名值为原文，使用第三方副署证书的私钥对原文进行签名，但在此并不具体约束副 署签名数据格式，副署签名数据格式可以是PKCS#7，或者是如图3的左侧3列展示的 副署签名数据格式，以及其他副署签名格式。如果放置在此位置都是在本发明保护的范 围内，由于安卓原生签名是对安卓数据块ZIP条路的内容块(Contents of ZIP Entries)， ZIP中央目录块(Central Directory)，中央目录结尾块(End of Central Directory)的杂凑进 行签名，所以在此位置加入副署签名并不影响原生安卓应用的安装以及升级。
实施例2：如图4所示，安卓V3签名分块，ID为0xf05368c0,格式如下：
·带长度前缀的signer(带长度前缀)序列：
·带长度前缀的signed data：
·带长度前缀的digests(带长度前缀)序列：
·signature algorithm ID(4个字节)
·digest(带长度前缀)
·带长度前缀的X.509certificates序列：
·带长度前缀的X.509certificate(ASN.1DER形式)
·minSDK(uint32)-如果平台版本低于此数字，应忽略该签名者。
·maxSDK(uint32)-如果平台版本高于此数字，应忽略该签名者。
·带长度前缀的additional attributes(带长度前缀)序列：
·ID(uint32)
·value(可变长度：附加属性的长度-4个字节)
·ID-0x3ba06f8c
·value-Proof-of-rotation结构
·minSDK(uint32)-签名数据部分中minSDK值的副本-用于在当前平台不 在相应范围内时跳过对此签名的验证。必须与签名数据值匹配。
·maxSDK(uint32)-签名数据部分中maxSDK值的副本-用于在当前平台不 在相应范围内时跳过对此签名的验证。必须与签名数据值匹配。
·带长度前缀的signatures(带长度前缀)序列：
·signature algorithm ID(uint32)
·signed data上带长度前缀的signature
·带长度前缀的public key(SubjectPublicKeyInfo，ASN.1DER形式)
本实施例是在安卓应用原生签名V3版本机制的基础上，发明一种第三方数字证书副署签名的放置方法，通过此方法可以在安卓应用程序原生签名机制V3版本上添加多 个的副署签名，而不影响安卓应用程序V3版本本身的验证机制，能够正常的安装及升 级，并能达到副署的效果。
如图5所示，具体操作是在安卓应用程序签名数据块中，找出V3签名数据块(ID 为0xf05368c0)，找到安卓原生签名者(Signer)数据块序列，在每一个签名者的数据 块中找到addtional attributes数据块，在此数据块中插入ID为非0x7109871a和 0xf05368c0和0x3ba06f8c的任一ID，ID的VALUE为副署签名数据，副署签名是以安 卓V3签名块中Signatures中的Signed data中的签名值为原文，使用第三方副署证书的 私钥对原文进行签名，但在此并不具体约束副署签名数据格式，副署签名数据格式可以 是PKCS#7，或者是如图5的左侧3列展示的副署签名数据格式，以及其他副署签名格 式。由于安卓原生签名是对安卓数据块ZIP条路的内容块(Contents of ZIP Entries)，ZIP 中央目录块(CentralDirectory)，中央目录结尾块(End of Central Directory)的杂凑进行签 名，所以在位置中加入副署签名并不影响原生安卓应用的安装以及升级。
更具体的，如图6所示的基于V2或V3签名机制的第三方副署签名流程为：
1、读取安卓应用软件原生签名块(APK Signature Block)，从ID 0x7109871a中获取V2版本签名数据或从ID0xf05368c0中获取签名数据。
2、分别读出每一个签发者的数据结构。
3、生成副署签名数据结构(此结构不仅限于PKCS#7，以及如图3或图5的副署签 名数据格式，也可以为任意副署签名格式)，包括版本号，杂凑算法，签发者主题项， 签发者证书，签名算法等。
4、如副署签名需要加入可信时间，则从可信时间源中获取可信时间，在副署签名数据格式中加入可信时间属性。
5、使用原生签名值作为附属签名的原文(Signatures数据结构中的Signed data中的 签名值为原文)，对其做杂凑运算，把计算得出的杂凑值设置到可信属性中。
6、使用副署签名可信属性数据作为原文使用副署签名证书私钥签名。
7、把副署签名添加到原生签名的额外属性中ID-VALUE对中(ID可以是任意非0x7109871a和0xf05368c0和0x3ba06f8c的任一ID)。
8、如果原生签名中还有签发者，如果有跳到步骤2。
9、签名结束。
更具体的，如图7所示的基于V2或V3签名机制的第三方副署签名验证流程：
1、读取安卓应用软件原生签名块(APK Signature Block)，从ID 0x7109871a中获取V2版本签名数据或从ID0xf05368c0中获取签名数据。
2、分别读出每一个签发者的数据结构。
3、分别读出每一个副署签名的数据结构。
4、从副署签名数据结构中获取副署签名的数字证书。
5、如果需要在线验证证书状态，则通过可信证书服务进行验证。
6、如果不需要，则在本地验证证书有效性，验证证书链、验证黑白名单。
7、副署签名是否有杂凑属性，如果没有则验证失败。
8、获取杂凑属性，对原生签名进行杂凑，将计算的杂凑值与杂凑属性中的杂凑值对比，如果不同则验证失败。
9、把副署签名中可信属性数据作为原文，使用副署签名证书对副署签名值进行验证，验证失败则验证失败。
10、如果还有副署签名则跳转步骤3。
11、如果还有原生签名则跳转2。
12、验证成功。
以上的实施例仅为说明本发明的技术思想，不能以此限定本发明的保护范围，凡是 按照本发明提出的技术思想，在技术方案基础上所做的任何改动，均落入本发明保护范围之内。
- 上一篇：石墨接头机器人自动装卡簧、装栓机
- 下一篇：一种基于数字水印的创作作品管理方法及系统
