一种基于V2或V3签名机制的第三方副署签名及验证方法与流程

一种基于v2或v3签名机制的第三方副署签名及验证方法
技术领域
1.本发明属于计算机信息安全技术，用于为安卓应用软件原生v2/v3签名机制提供一 种第三方副署签名方法。


背景技术：

2.安卓系统要求所有的应用程序必须签名后才能安装，但并没有对签名证书做严格限 制，任何一张自签名证书都可以用来做签名，签名证书一般由开发者自己生成，所有开 发者可随意设置证书主题项内容，很容易恶意伪造其他开发者的签名证书。同时签名证 书和私钥一般以普通数据文件形式存放，可能会被复制、传播并恶意使用，一旦发生， 使得追溯android应用的真实开发者变得十分困难。
3.副署签名是在已经签名过的文件上附加签名，作为对已签名文件的认可和证明，其 目的在于证明文件中的数据、动作或规定已签名者和副署签名者认可。
4.安卓应用程序第三方数字签名是一种副署签名，副署签名由签名发起方(应用开发 者、检测机构、应用商店等)使用第三方合法ca机构签发的代码签名证书，在不改变 原有安卓应用程序打包签名流程的条件下，对已经打包并签名过的应用程序附加签名。 副署签名可以是一个或多个签名。
5.目前：专利公布号cn106209379b，一种android apk副署签名及验证方法针对安 卓应用程序原生签名v1版本提出一种安卓应用程序的一种副署签名的方法。
6.针对目前安卓系统的不断升级，安卓应用程序原生签名v1机制由于其存在很多缺点 和安全隐患，如：
7.由于签名不保护apk的某些部分，例如zip元数据。
8.apk验证程序需要处理大量不可信(尚未经过验证)的数据结构，然后会舍弃不 受签名保护的数据。这会导致相当大的受攻击面。
9.apk验证程序必须解压所有已压缩的条目，而这需要花费更多时间和内存。
10.基于这些缺陷目前逐步被安卓应用程序原生签名v2/v3机制所替代，v2方案(从安 卓7.0引入)，v3方案(从安卓9.0引入)。但目前v2/v3签名机制下的副署签名方法还没 有一个在不影响原生签名验证流程下安全可靠的副署签名机制。


技术实现要素：

11.针对上述技术问题，本发明提出基于安卓原生签名v2/v3机制下的第三方副署签名 方法，不影响安卓签名v2/v3版本原有的验证机制，并能达到副署效果。
12.为达到上述目的，本发明采用的技术方案为：一种基于v2或v3签名机制的第三 方副署签名方法，通过此方法可以在安卓签名机制v2或v3版本上添加多个副署签名。
13.在安卓应用程序签名数据块中，找出v2或v3的签名数据块，找到安卓原生签名 者数据块序列，在每一个签名者数据块中找到额外属性addtional attributes数据块，在额 外属性数据块中插入id，额外属性数据块中插入的id的值为副署签名数据；在v2签 名数据
块中，id非0x7109871a；在v3签名数据块中，id非0x7109871a或0xf05368c0 或0x3ba06f8c。
14.进一步的，副署签名是以安卓v2或v3签名数据块中signatures数据结构中的 signed data中的签名值为原文，使用第三方副署证书的私钥对原文进行签名。在此并不 具体约束副署签名数据格式，副署签名数据格式可以是pkcs#7，或者其他副署签名格 式。由于安卓原生签名是对安卓数据块zip条路的内容块(contents of zip entries)，zip 中央目录块(central directory)，中央目录结尾块(end of central directory)的杂凑进行签 名，所以在此位置加入副署签名并不影响原生安卓应用的安装以及升级。
15.进一步的，上述第三方副署签名方法具体包括以下步骤：
16.s1、读取安卓应用软件原生签名块，从id 0x7109871a中获取v2签名数据或从 id0xf05368c0中获取v3签名数据；
17.s2、读出签发者的数据结构；
18.s3、生成副署签名数据结构，副署签名数据结构包括版本号，杂凑算法，签发者主 题项，签发者证书，签名算法等；
19.s4、使用原生签名值作为副署签名的原文，对其做杂凑运算，把计算得出的杂凑值 设置到可信属性中；
20.s5、使用副署签名可信属性数据作为原文使用副署签名证书私钥签名；
21.s6、把副署签名添加到原生签名的额外属性数据块中插入的id的值中。
22.最后，签名结束。
23.作为优选的，s3后进一步包括如下步骤：如副署签名需要加入可信时间，则从可 信时间源中获取可信时间，在副署签名数据格式中加入可信时间属性。
24.进一步的，上述方法中，如果原生签名中有不止一个签发者，则分别读出每一个签 发者的数据结构，对每一个签发者的数据结构，执行步骤s3至s6，执行完毕后签名结 束。
25.本发明还公开一种基于v2或v3签名机制的第三方副署签名验证方法，包括以下 步骤：
26.s11、读取安卓应用软件原生签名块，从id 0x7109871a中获取v2版本签名数据或 从id0xf05368c0中获取签名数据；
27.s12、读出签发者的数据结构、副署签名的数据结构；
28.s13、从副署签名数据结构中获取副署签名的数字证书；
29.s14、如果需要在线验证数字证书状态，则通过可信证书服务进行验证。
30.如果不需要在线验证，则在本地验证证书有效性，验证证书链、验证黑白名单。
31.s15、副署签名证书验证通过后，判断副署签名是否有杂凑属性，如果没有则验证 失败；
32.s16、对原生签名进行杂凑，将计算的杂凑值与杂凑属性中的杂凑值对比，如果不 同则验证失败；
33.s17、把副署签名中可信属性数据作为原文，使用副署签名证书对副署签名值进行 验证；如果副署签名值验证不同则验证失败。采用密码学的相关运算进行验证，验证成 功则证明这个证书对应的私钥做的签名的不可抵赖性。
34.s18、如果还有副署签名则跳转步骤3。
35.s21、如果还有原生签名则跳转2。
36.进一步的，如果原生签名中有不止一个签发者，则分别读出每一个签发者的数据结 构、每个签发者的数据结构的每个副署签名的数据结构；对每个签发者对应的所有副署 签名均执行s13至s17。
37.本发明具有以下有益效果：
38.本发明适用于安卓系统移动应用程序v2或v3签名机制下的第三方副署签名方法， 实现了安卓系统移动应用程序v2或v3签名机制下各种副署签名角色(应用开发者， 检测机构，应用商店等)的签名追溯，同时还不改变原有安卓v2或v3签名验证机制。
39.应用程序副署签名使用的是由第三方合法ca机构颁发的代码签名数字证书，副署 签名者的身份由第三方ca机构严格审查并核实。在使用代码签名数字证书对应用程序 副署签名后，在《中华人民共和国电子签名法》的保护下，有如下优势：
40.副署签名者身份实名认证，可追究法律责任。
41.应用程序副署签名后，每一个副署环节都可以被追溯。
42.副署签名由第三方ca机构颁发的代码签名数字证书完成，可信度更高，便于推广。
43.副署签名，可证明开发者对应用程序的拥有权，在遇到应用程序被盗版，侵权等行 为时，将为应用程序开发者提供强有力的证据。
附图说明
44.图1为安卓应用程序v2，v3签名机制下整体数据结构。
45.图2为安卓应用程序v2版本下签名数据结构。
46.图3为本发明实施例的v2签名机制下副署签名的数据格式。
47.图4为安卓应用程序v3版本下签名数据结构。
48.图5为本发明实施例的v3签名机制下副署签名的数据格式。
49.图6为本发明实施例的v2或v3签名机制下副署签名方法流程图。
50.图7为本发明实施例的v2或v3签名机制下副署签名验证方法流程图。
具体实施方式
51.为了便于本领域技术人员的理解，下面结合实施例与附图对本发明作进一步的说 明。
52.如图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签名。
53.安卓应用程序原生签名v2，v3方案并没有一个在不改变android原生签名验证基 础上的副署签名机制，本实施例的方法主要解决在安卓原生签名v2，v3方案下的副署 签名机制。
54.实施例1：如图2所示，安卓v2签名分块，id为0x7109871a，格式如下：
55.·
带长度前缀的signer(带长度前缀)序列：
56.·
带长度前缀的signed data：
57.·
带长度前缀的digests(带长度前缀)序列：
58.·
signature algorithm id(uint32)
59.·
(带长度前缀)digest
‑
请参阅受完整性保护的内容
60.·
带长度前缀的x.509certificates序列：
61.·
带长度前缀的x.509certificate(asn.1der格式)
62.·
带长度前缀的additional attributes(带长度前缀)序列：
63.·
id(uint32)
64.·
value(可变长度：附加属性的长度
‑
4个字节)
65.·
带长度前缀的signatures(带长度前缀)序列：
66.·
signature algorithm id(uint32)
67.·
signed data上带长度前缀的signature
68.·
带长度前缀的public key(subjectpublickeyinfo，asn.1der形式)
69.本实施例是在v2签名块的基础上，实现可以在安卓签名机制v2版本上添加多个 副署签名，而不影响安卓签名v2版本原有的验证机制，可以正常的安装及升级，并能 达到副署效果。
70.如图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)的杂凑进 行签名，所以在此位置加入副署签名并不影响原生安卓应用的安装以及升级。
71.实施例2：如图4所示，安卓v3签名分块，id为0xf05368c0,格式如下：
72.·
带长度前缀的signer(带长度前缀)序列：
73.·
带长度前缀的signed data：
74.·
带长度前缀的digests(带长度前缀)序列：
75.·
signature algorithm id(4个字节)
76.·
digest(带长度前缀)
77.·
带长度前缀的x.509certificates序列：
78.·
带长度前缀的x.509certificate(asn.1der形式)
79.·
minsdk(uint32)
‑
如果平台版本低于此数字，应忽略该签名者。
80.·
maxsdk(uint32)
‑
如果平台版本高于此数字，应忽略该签名者。
81.·
带长度前缀的additional attributes(带长度前缀)序列：
82.·
id(uint32)
83.·
value(可变长度：附加属性的长度
‑
4个字节)
84.·
id
‑
0x3ba06f8c
85.·
value
‑
proof
‑
of
‑
rotation结构
86.·
minsdk(uint32)
‑
签名数据部分中minsdk值的副本
‑
用于在当前平台不 在相应范围内时跳过对此签名的验证。必须与签名数据值匹配。
87.·
maxsdk(uint32)
‑
签名数据部分中maxsdk值的副本
‑
用于在当前平台不 在相应范围内时跳过对此签名的验证。必须与签名数据值匹配。
88.·
带长度前缀的signatures(带长度前缀)序列：
89.·
signature algorithm id(uint32)
90.·
signed data上带长度前缀的signature
91.·
带长度前缀的public key(subjectpublickeyinfo，asn.1der形式)
92.本实施例是在安卓应用原生签名v3版本机制的基础上，发明一种第三方数字证书 副署签名的放置方法，通过此方法可以在安卓应用程序原生签名机制v3版本上添加多 个的副署签名，而不影响安卓应用程序v3版本本身的验证机制，能够正常的安装及升 级，并能达到副署的效果。
93.如图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 中央目录块(central directory)，中央目录结尾块(end of central directory)的杂凑进行签 名，所以在位置中加入副署签名并不影响原生安卓应用的安装以及升级。
94.更具体的，如图6所示的基于v2或v3签名机制的第三方副署签名流程为：
95.1、读取安卓应用软件原生签名块(apk signature block)，从id 0x7109871a中获 取v2版本签名数据或从id0xf05368c0中获取签名数据。
96.2、分别读出每一个签发者的数据结构。
97.3、生成副署签名数据结构(此结构不仅限于pkcs#7，以及如图3或图5的副署签 名数据格式，也可以为任意副署签名格式)，包括版本号，杂凑算法，签发者主题项， 签发者证书，签名算法等。
98.4、如副署签名需要加入可信时间，则从可信时间源中获取可信时间，在副署签名 数据格式中加入可信时间属性。
99.5、使用原生签名值作为附属签名的原文(signatures数据结构中的signed data中的 签名值为原文)，对其做杂凑运算，把计算得出的杂凑值设置到可信属性中。
100.6、使用副署签名可信属性数据作为原文使用副署签名证书私钥签名。
101.7、把副署签名添加到原生签名的额外属性中id
‑
value对中(id可以是任意非 0x7109871a和0xf05368c0和0x3ba06f8c的任一id)。
102.8、如果原生签名中还有签发者，如果有跳到步骤2。
103.9、签名结束。
104.更具体的，如图7所示的基于v2或v3签名机制的第三方副署签名验证流程：
105.1、读取安卓应用软件原生签名块(apk signature block)，从id 0x7109871a中获 取v2版本签名数据或从id0xf05368c0中获取签名数据。
106.2、分别读出每一个签发者的数据结构。
107.3、分别读出每一个副署签名的数据结构。
108.4、从副署签名数据结构中获取副署签名的数字证书。
109.5、如果需要在线验证证书状态，则通过可信证书服务进行验证。
110.6、如果不需要，则在本地验证证书有效性，验证证书链、验证黑白名单。
111.7、副署签名是否有杂凑属性，如果没有则验证失败。
112.8、获取杂凑属性，对原生签名进行杂凑，将计算的杂凑值与杂凑属性中的杂凑值 对比，如果不同则验证失败。
113.9、把副署签名中可信属性数据作为原文，使用副署签名证书对副署签名值进行验 证，验证失败则验证失败。
114.10、如果还有副署签名则跳转步骤3。
115.11、如果还有原生签名则跳转2。
116.12、验证成功。
117.以上的实施例仅为说明本发明的技术思想，不能以此限定本发明的保护范围，凡是 按照本发明提出的技术思想，在技术方案基础上所做的任何改动，均落入本发明保护范 围之内。