安卓应用软件代码签名的风险挑战与应对措施

摘　要：在移动互联网时代，安卓移动应用软件已经渗透到人们生产生活的方方面面，安卓代码签名的安全问题一直是黑灰产关注的重点。通过分析不同版本的安卓代码签名机制以及代码签名在证书算法、证书使用、软件权责、软件保护、证书更新等方面存在的风险挑战，从行业标准、企业内部、政策监管、产业链责任和义务等方面向产业相关方提出对策建议，为行业相关技术研究、标准制定和政策发布提供参考。

内容目录：

1　代码签名的作用和流程
1.1　代码签名的作用
1.2　代码签名的流程
2　安卓代码签名技术的演进
2.1 V1 签名机制
2.2 V2 签名机制
2.3 V3 签名机制
2.4 V4 签名机制
3　安卓代码签名的安全挑战
3.1　代码签名证书算法存在安全风险
3.2　代码签名证书私钥易被泄露
3.3　代码签名的软件权责认定能力缺失
3.4　代码签名的软件防篡改能力减弱
3.5　代码签名证书更新代价大
4　应对措施
4.1　推动代码签名证书相关标准的制定和应用
4.2　加强企业代码签名密钥管理制度建设
4.3　施行代码签名证书第三方认证
4.4　落实上架、安装环节代码签名验证
4.5　提升产业下游代码签名验证能力
5　结　语

近年来，随着移动互联网的高速发展，移动应用软件已经渗透到人们生产生活的方方面面。移动设备相比个人电脑承载了更多的个人信息和隐私数据。移动应用软件从移动设备上获取个人信息后，再结合大数据和算法给用户做精准画像和推荐，虽然极大地提升了移动互联网的服务质量，但随之而来的软件安全和合规问题也逐步引起了人们的关注。以安卓生态为例，诈骗、仿冒、破解、违规收集、违规使用个人信息等侵害用户权益的应用软件屡见不鲜，给用户造成了直接经济损失和个人信息泄露。

针对这一现状，在监管方面，国家已经出台了一系列的法律法规标准来要求移动应用软件的关键责任链主体落实相关责任和义务，并取得了一定的社会成效，但部分企业服务行为不规范、技术能力欠缺、相关环节责任落实不到位等问题仍时有发生。在技术管控方面，谷歌设计了应用软件代码签名机制，旨在用于保护开发者应用软件的完整性和安全性。然而，由于生态过于开放，相关技术公开透明，因此代码签名的安全问题一直是黑灰产关注的重点，攻击者通常会利用一些已知的代码签名漏洞实施网络攻击，实现各类非法目的，严重影响移动互联网的健康有序发展。本文将探讨安卓应用软件代码签名当前面临的安全挑战，并提出相关应对措施。

1 代码签名的作用和流程

1.1　代码签名的作用

代码签名是指利用数字证书对软件代码文件进行数字签名的一种活动。数字签名是指使用证书私钥对代码文件进行加密的过程。在操作系统中，代码签名通常用于确保安装和运行的软件是操作系统所信任的。代码签名还可以描述为将软件与一个数字证书绑定，以确保该软件的身份可信和代码完整。只有当数字证书被操作系统信任时，操作系统才会允许该软件安装和运行。通过使用代码签名，可以提高操作系统的安全性和稳定性，防止恶意软件和不受信任软件程序的安装和运行。

1.2　代码签名的流程

代码签名的实现流程包括以下 5 个步骤。

1.2.1　生成数字证书

代码签名是为软件开发者设计的。首先，开发者需要向操作系统信任的数字证书机构申请代码签名证书；其次，对于部分不验证数字证书的信任关系的操作系统（如安卓操作系统），安卓开发者可自行生成数字证书。数字证书包含开发者的公钥和身份信息，而公钥对应的私钥由开发者自行保存。

1.2.2　生成哈希值

从原理上来看，代码签名的对象应该是代码文件或整个程序文件。然而，数字签名采用非对称加解密技术，而非对称加解密技术的一大缺点便是对于大容量文件的执行效率不高。据实验测算，1 GB（1 024 MB）的文件加密需要1 分钟，但是解密却需要数十个小时，而目前应用软件大小从几十 MB 到几千 MB 不等。因此，为了提高签名效率，实践中通常先将软件进行哈希计算，以得到一个占用内存极少的哈希值，再对哈希值进行签名。以 SHA256 哈希算法为例，任意文件大小的哈希值只有 64 个字节，从而显著降低了计算需求。更重要的是，对哈希签名和直接对软件签名起到的效果是一样的。

1.2.3　使用私钥进行签名

开发者使用其私钥对哈希值进行签名，生成数字签名，即签名值。私钥只有其开发者拥有，因此签名值只能由开发者生成。

1.2.4　打包成安装包

打包机制通常由操作系统厂商定义，所以操作系统厂商通常会给开发者提供对应的打包工具。在实践中，不同操作系统的打包方式各不相同，个别操作系统不同版本之间的打包方式也不尽相同，但基本思路都是将数字证书和签名值随程序文件打包在一起，生成一个可以直接在操作系统中运行的安装包。

1.2.5　验证签名

在执行安装之前，操作系统首先需要解开安装包，按照自定义的打包方式逆向进行解包得到源程序文件（zip）、数字证书公钥和签名值（Signature），再对程序文件进行哈希运算得到 Hash（zip），接着利用数字证书中的公钥解密签名值得到 Decrypt（Signature），最后比对Hash（zip） 和 Decrypt（Signature）。如 果 二 者一致，则证明程序文件未被篡改，反之则证明文件已被篡改。除此之外，还可据此验证数字证书的有效性和数字证书的身份等。

2 安卓代码签名技术的演进

安卓操作系统是一种基于Linux内核的自由、部分开源的操作系统。2008 年 9 月，谷歌发布Android 1.0 版本，截至目前已更新至 Android 14，其代码签名机制也升级演进了 4 个版本。

2.1 V1 签名机制

在 Android 1.0 至 Android 6.0 版本阶段，谷歌公司提供的签名工具是 jarsigner，jarsigner 是 Java软件开发工具包（Java Development Kit，JDK）提供的针对 jar 包签名的通用工具，Android V1 版本签名流程如图 1 所示。

图 1 Android V1 版本签名流程

第一步，对每个代码文件使用 SHA1 哈希算法计算得到哈希值，保存在 MANIFEST.MF 文件中。第二步，对 MANIFEST.MF 文件中的每个哈希值进行二级哈希算法（防止哈希碰撞），保存在 CERT.SF文件中。第三步，使用私钥对 CERT.SF 文件进行签名，将签名值、数字证书保存在 CERT.RSA 文件中。第四步，将 MANIFEST.MF、CERT.SF 和 CERT.RSA 这3 个文件保存在 APK 安装包的 META-INF 文件夹中。

这 种 最 初 的 签 名 机 制 被 称 为 Signature Scheme V1，简称 V1 签名机制。V1 签名机制存在两个弊端：一是签名校验效率低，因为采用的方法是对每个文件进行哈希计算，APK 安装包内代码文件和资源文件较多，导致验签时间较长，影响安装速度。二是安装包容易被捆绑其他信息，因为 META-INF 目录存放签名和验签信息，本身对该文件夹不进行完整性保护，所以任何人可以在此文件夹内捆绑其他资源文件或直接删除签名和验签信息，影响验证的准确性。

2.2 V2 签名机制

从Android 7.0（API Level 24）开 始， 谷 歌增加了新签名方案 Signature Scheme V2。V2 签名 机 制 的 工 具 是 apksigner，apksigner 可 以 对APK 压缩包的整个文件签名，V2 签名机制在原先 APK 压缩包中增加了一个新的签名块 APK Signing Block，存储了签名值、哈希值、数字证书及一些额外属性等信息，签名后任何人不能修改安装包，同时也提高了签名验签的效率。具体前后结构对比如图 2 所示。

图 2 Android V2 版本签名前后结构对比

V2 签名机制相较于 V1 签名机制更加安全高效，但只有 Android 7.0 及以上版本才支持验证 V2 签名。由于目前市面上仍存在一些版本较低的老机型，所以安卓开发者大多采用 V1和 V2 两种模式相结合的方式进行打包。对于Android 7.0 及以上版本，在安装过程中如果发现有 V2 签名块，则必须执行 V2 签名验证机制，不能绕过。

2.3 V3 签名机制

安卓系统发布至今已有十多年的历史了。早期，一些开发者缺乏数字证书安全意识，由数字证书过期或私钥保管不当导致的泄露问题时有发生，故更新数字证书的需求极为迫切。为了保证数字证书更新不影响已安装应用的正常运行，谷歌在 Android 9.0（API Level 28）中引入了一种新的应用程序签名机制，称为 APK Signature Scheme V3。新版 V3 签名机制在 V2 签名机制的基础上，仍然采用检查整个压缩包的校验方式。不同的是在签名部分增加了可以添加的新证书块，在这个新块中会同时记录之前的签名信息以及新的签名信息，并以密钥轮换的方案进行签名的替换和升级。这意味着，只要拥有旧签名证书，就可以通过它在新的 APK 文件中使用新的签名证书对应用程序进行更新，且不影响用户的正常使用。

2.4 V4 签名机制

由于安卓终端种类的多样化，应用软件兼容性问题随之出现。为了提高应用软件的兼容性，开发者把各种终端类型资源依赖文件都打包在一起，导致安装包的体积越来越大。然而，在实际使用过程中，很多文件是用不到的，因此这不仅影响软件的安装速度，还浪费用户的下载流量，更是长期占用终端存储空间。针对这一问题，谷歌在 Android 11（API Level 30）中提供了基于增量安装的签名方案 APK Signature Scheme V4，增量 APK 可以先安装足够的 APK以启动应用，同时检测终端运行环境，在后台流式传输剩余的必要数据。该方案需要具备配套的能力和平台，适用于大型的应用商店。

根据以上不同的签名机制可以看出，开发者在打包 APK 安装包时，可以根据实际需要选择不同的代码签名机制。其中，V4 签名机制是面向增量安装需求的，V3 签名机制是解决证书更新需求的。实际上，开发者如果没有签名变动的需求可以不考虑 V3 签名，V2 和 V1 签名即可满足现有软件需求，故目前国内大部分开发者是同时使用 V2 和 V1 签名。

3 安卓代码签名的安全挑战

前述内容表明，安卓移动软件的代码签名机制能够保护应用程序的完整性，签名机制的不断完善也提升了代码签名的安全性，且 V3 和V4 签名机制能够进一步从使用层面解决一些实际的问题。然而，整套签名机制在面对唯利是图的黑灰产、技术能力参差不齐的开发者、复杂多变的应用分发平台和种类繁多的终端类型时仍存在一定的安全挑战。

3.1　代码签名证书算法存在安全风险

目前安卓系统对代码签名证书的签名算法密钥长度要求在 1 024 位及以上，但对代码签名证书的摘要算法没有做要求。为了方便起见，很多开发者在生成代码签名证书时将证书的有效期设置为 20 年以上。随着信息技术的高速发展和密码技术的不断演进，十年前流行的算法目前已经存在很大的安全风险 。以国内某头部应用软件为例，其代码签名证书采用的是 1 024 位的RSA 签名算法和 SHA1 哈希算法，如图 3 所示。

图 3　某应用软件的代码签名证书

这些算法已经被权威机构认为存在安全风险或被企业宣布已经不再使用。例如，2011 年 2 月，国家密码管理局在发文中明确指出，1 024 位RSA 算法正在面临日益严重的安全威胁；2016 年1 月 1 日起，微软 Edge 和 IE 11 不认为使用 SHA1证书的网站是安全的，所以不在浏览器的地址栏中显示用来表示安全网站的挂锁图标；2017 年1 月 1 日起，Chrome 浏览器会自动将使用 SHA1签名的任何 SSL 证书标记为不安全。除了 SHA1哈希算法，还有部分 APK 代码签名证书采用的是 MD5 哈希算法，但 MD5 算法早在 2004 年就被山东大学密码学家王小云破解，是比 SHA1 更不安全的一种算法。

3.2　代码签名证书私钥易被泄露

安卓代码签名证书私钥是整个代码签名机制安全的关键。如果私钥泄露，意味着黑客可以使用该私钥生成恶意应用程序并伪装成原始应用程序，进而实施各种攻击。由于安卓代码签名证书是由开发者自行生成的，而绝大部分开发者缺少证书管理的相关经验，因此易引发密钥泄露或丢失的情况。一是保管证书时疏忽大意，将证书私钥存储在不安全的位置，很容易被他人复制窃取。二是软件开发行业人员流动性较大，随着研发人员的离职，证书私钥也随之被带走。三是个别开发者为了简化开发流程采用云平台打包的模式，将证书私钥托管保存在云平台，这些云平台的私钥托管服务一般缺少密码安全性评估，所以存在被他人窃取或越权使用的风险。上述这些行为都给代码签名带来了一定的安全风险。

3.3　代码签名的软件权责认定能力缺失

安卓代码签名虽然是安卓操作系统管控应用软件的一种技术手段，但安卓系统在验证代码签名时不会校验代码签名证书的颁发机构，所以绝大部分开发者都使用自行生成的证书。但是，自己颁发的证书属于无效证书或不被信任的证书，这就相当于开发者的代码签名证书是未经认证的、无效的。当应用软件发生假冒侵权、恶意破解、违法违规等行为需要进行权责认定时，根据代码签名证书无法溯源和认定真实的开发者身份，开发者也无法自证身份，导致应用软件权责不清，从而引发侵权纠纷、责任纠纷等问题。

3.4　代码签名的软件防篡改能力减弱

谷歌代码签名工具 apksigner.jar 提供了代码重签的功能，其允许任何人直接将任意 APK 原有的签名进行替换，即无须经过 APK 开发者的同意即可修改 APK 文件，而且针对此类行为也没有任何校验机制，给黑灰产留下了较大的操作空间。例如，通过反编译手段修改 APK 源代码或插入恶意代码再签名打包 ，对外宣称是精简版、破解版或免费版，实际是利用原应用软件的品牌影响力骗取用户下载安装，以达到窃取用户隐私或发布恶意广告的目的。在实际开发过程中，部分安全意识较高的开发者会在APK 启动程序中增加校验代码签名一致性的代码，如果 APK 被中间人篡改重签，应用程序将无法正常启动；抑或对代码进行加固，从而提高 APK 被反编译的难度。然而，随着反编译技术的不断提高，黑灰产还是可以通过脱壳技术对加固后的 APK 进行反编译，同时删除 APK 中校验代码签名的代码以达到篡改的目的。

3.5　代码签名证书更新代价大

V3 签名机制虽然支持代码签名数字证书的更新，但开发者在实际操作过程中还是面临诸多问题。一方面，大部分应用商店审核应用更新包时，往往还是基于原安装包的签名校验机制，如果开发者更新了代码签名证书，在发布更新包时则需要花费更多的时间和精力向这些应用商店进行证明代码签名证书已经更新这一事实。另一方面，目前市面上还有不少机型的版本还在 Android 9.0 以下，这些终端在安装更新包时，由于无法直接覆盖安装，只能通过卸载原应用的方式重新安装，这将导致用户原有的应用数据丢失，影响用户体验。因此不到万不得已，开发者不会轻易对代码签名证书进行更新。

4 应对措施

为应对当前移动应用软件代码签名面临的安全挑战，我们将从产业标准、企业制度、监管要求、关键主体责任、关键主体义务 5 个层面进行分析，并提出以下对策建议。

4.1　推动代码签名证书相关标准的制定和应用

算法是代码签名证书的安全基础，代码签名证书的密钥保管得再好，如果算法不安全，攻击者还是可以利用算法漏洞计算出保管的密钥。代码签名用到了密码领域的相关技术，目前大部分开发者对于网络安全有一定的认识，但对于密码领域的相关技术较为陌生。信息通信行业、电信终端产业的协会等相关组织应推动行业制定代码签名证书相关标准。一是联合安卓系统厂商、头部应用软件开发者和密码服务厂商制定安卓应用软件代码签名证书相关标准，明确代码签名证书的各项相关要求，包括但不限于代码签名证书的格式、证书有效期、证书唯一标识、证书其他属性、签名算法、密钥长度、证书认证业务规则和证书策略等。二是在行业内宣贯代码签名标准，通过行业论坛、技术沙龙、开发者大会鼓励和引导开发者执行代码签名证书标准，选择或者更新为安全可靠的算法，降低算法安全风险。三是开展标准验证工作，对满足相关安全要求的代码签名证书进行公示，带动整个行业落实标准要求。

4.2　加强企业代码签名密钥管理制度建设

代码签名证书密钥是整个应用软件安全的核心，不少企业的核心业务是通过应用软件开展的，因此应用软件出现安全问题极容易引发舆情，直接影响公司正常运行，甚至导致公司破产倒闭。应用软件企业务必重视代码签名证书密钥的安全性，加强密钥的安全管理，在企业内部制定密钥管理规范。一是明确企业密钥管理岗位的职责要求，选择具有网络安全或密码维护相关经验的人员担任密钥管理员。对密钥的生成、使用、更新、备份、恢复等重要操作采用双人授权操作机制，留存操作日志记录，禁止对密钥进行复制，定期进行密钥安全审计。二是采用具有商用密码资质的产品存储密钥，并保障密码产品的物理安全。加强密钥的网络安全管理，禁止未授权或通过互联网访问密钥。三是定期开展密钥安全性评估，及时发现密钥安全威胁并提出解决方案，对正在使用的不安全算法的代码签名证书应尽早进行证书更新。

4.3　施行代码签名证书第三方认证

数字证书是具有密码属性的网络身份证，在网络世界中具有身份识别、数据完整性保护等安全功能。代码签名属于电子签名的范畴，2005 年，我国实施的《中华人民共和国电子签名法》第二条明确了电子签名的定义，是指数据电文中以电子形式所含、所附用于识别签名人身份并表明签名人认可其中内容的数据。其中第十六条指出，电子签名是需要第三方认证的，由依法设立的电子认证服务提供者提供认证服务 。2009 年，工业和信息化部令第 1 号《电子认证服务管理办法》第十七条提到了电子认证服务的核心，是提供制作、签发、管理电子签名认证证书等服务。从以上法律法规可以看出，数字证书只有通过第三方电子认证服务机构签发，才有可能具备合法网络身份证的属性，才能彻底解决应用软件权责不清等问题。2016 年，工业和信息化部在《移动智能终端应用软件预置和分发管理暂行规定》中提出，鼓励移动智能终端应用软件采用依法设立的电子认证服务机构颁发的数字证书进行签名 [7]，说明主管部门已经认识到代码签名证书第三方认证的必要性。然而，实行第三方认证就意味着要收费，强制执行显然不符合国家“放管服”的相关要求。因此在施行第三方认证时，主管部门可以提供一些具有公益属性的第三方认证机构，免费为开发者签发代码签名数字证书。另外，随着信息技术的不断发展，部分商业第三方认证机构服务能力不断提升，现阶段签发和维护数字证书的成本已经大幅降低，将来商业第三方认证机构可以通过其他增值服务进行收费，免费提供数字证书指日可待。

4.4　落实上架、安装环节代码签名验证

应用软件由开发者打包成安装文件进行发布后，安装文件就不再受开发者管控，任何组织、个人都可以对其进行分析、修改、破解后再分发。只要不影响应用软件的安装和使用，用户是无法得知应用软件是否被篡改的。因此，应用软件在应用商店上架和终端系统安装这两个重要环节需要落实代码签名的验证，以确保应用软件的完整性 。首先，应用软件初次申请在应用商店上架时，应用商店应严格审核该应用软件开发者的真实身份和验证代码签名证书，确保应用软件开发者身份和第三方代码签名证书身份的一致性，如果不一致则不允许上架。其次，终端系统在安装应用软件时同样应验证代码签名，验证不通过的及时提醒用户，确保应用软件从开发到安装整个过程中未被中间人篡改。当终端系统无法识别应用软件的真实身份导致无法确认应用软件开发者身份和第三方代码签名证书身份的一致性时，终端系统可通过终端云控平台与自营应用商店或主管部门应用软件备案系统、应用软件溯源系统等联动，获取应用软件的真实身份，确保终端系统能正常验证代码签名。

4.5　提升产业下游代码签名验证能力

从应用软件产业链来看，应用软件开发者处于产业上游，应用软件发布后，需要经过应用商店检测审核、终端厂商安装验证等阶段，才能交予用户使用。在代码签名方面，部分应用商店和终端厂商等下游厂商老旧的验证方式制约着应用软件开发者在代码签名方面的创新。为了保障用户体验，应用软件开发者不敢使用新的技术更新已存在安全风险的代码签名证书，因此亟须提升下游代码签名验证的能力。一是发挥行业检测机构和认证机构的作用，在应用商店和终端系统安全能力测评方面增加代码签名验证能力的要求。二是鼓励头部应用软件企业敢于尝试，倒逼应用商店和终端厂商升级代码签名验证方式，从而提升代码签名验证能力。

5 结　语

安卓应用软件代码签名的风险已经成为移动互联网产业不容忽视的安全问题之一。安卓生态属于开放的生态，相较于封闭的生态，更需要产业界和主管部门共同协作。随着云计算、量子计算、人工智能等新技术的不断发展，安卓代码签名技术也将迎来新的风险挑战。本文仅针对目前存在的风险挑战提出应对措施，未来还需要结合新技术、新应用等产业实际情况，不断提升代码签名的安全管控能力，维护代码签名的核心作用，营造一个安全可靠的生态环境，促进产业持续健康有序发展。

引用格式：宋恺 , 邓佑军 , 王浩仟 , 等 . 安卓应用软件代码签名的风险挑战与应对措施 [J]. 信息安全与通信保密 ,2023(9):36-44.
作者简介 >>>
宋　恺，男，硕士，高级工程师，主要研究方向为电信和互联网领域的监管与安全政策；
邓佑军，男，学士，工程师，主要研究方向为商用密码应用、电子认证、个人信息保护；
王浩仟，男，学士，工程师，主要研究方向为信息安全和个人信息保护；
张静怡，女，学士，工程师，主要研究方向为信息安全和个人信息保护；
汪　海， 男， 学 士， 工 程 师，主要研究方向为信息安全和检测认证。
选自《信息安全与通信保密》2023年第9期（为便于排版，已省去原文参考文献）
重要声明：本文来自信息安全与通信保密杂志社，经授权转载，版权归原作者所有，不代表锐成观点，转载的目的在于传递更多知识和信息。

相关阅读：为什么代码签名证书都是“硬证书”?如何选择代码签名证书?