CN106209379A - 一种Android APK副署签名验证方法 - Google Patents

一种Android APK副署签名验证方法 Download PDF

Info

Publication number
CN106209379A
CN106209379A CN201610525072.7A CN201610525072A CN106209379A CN 106209379 A CN106209379 A CN 106209379A CN 201610525072 A CN201610525072 A CN 201610525072A CN 106209379 A CN106209379 A CN 106209379A
Authority
CN
China
Prior art keywords
apk
countersignature
cert
signature
android
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN201610525072.7A
Other languages
English (en)
Other versions
CN106209379B (zh
Inventor
庄昱垚
王杰勋
赵统
赵统一
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
JIANGSU XIAN'AN TECHNOLOGY Co Ltd
Original Assignee
JIANGSU XIAN'AN TECHNOLOGY Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by JIANGSU XIAN'AN TECHNOLOGY Co Ltd filed Critical JIANGSU XIAN'AN TECHNOLOGY Co Ltd
Priority to CN201610525072.7A priority Critical patent/CN106209379B/zh
Publication of CN106209379A publication Critical patent/CN106209379A/zh
Application granted granted Critical
Publication of CN106209379B publication Critical patent/CN106209379B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

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/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/3236—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 using cryptographic hash functions
    • 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
    • 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

Abstract

本发明提出一种Android APK副署签名验证方法，包括以下步骤：步骤1，开发者使用原私钥对CERT.SF的签名写入CERT.RSA或CERT.DSA文件；步骤2，第三方向可信电子认证服务机构申请数字证书，使用数字证书对CERT.SF进行副署签名，副署签名中包含签名时间，将副署签名信息添加到CERT.RSA或CERT.DSA文件中；步骤3，原生Android系统对APK进行验证，按照Android原生的签名验证方法验证APK，不验证副署签名信息；若通过第三方系统应用软件安装APK，若原生APK签名验证通过，进一步依次验证副署签名，若所有验证都通过，允许安装该APK，否则拒绝安装该APK。本发明在不破坏Android现有签名验证机制、不破坏Android文件结构的前提下可以为APK副署多个签名，并可追溯任意一个副署签名，在实际应用中也存在巨大的价值。

Description

一种Android APK副署签名验证方法
技术领域
本发明属于APK签名认证方法，尤其涉及一种Android APK副署签名及验证方法。
背景技术
Android是一种基于Linux的自由及开放源代码的操作系统，主要使用于移动设备，如智能手机和平板电脑，由Google公司和开放手机联盟领导及开发。自从2008年10月第一部Android智能手机发布以来，发展势头迅猛，2011年第一季度，Android在全球的市场份额首次超过塞班系统，跃居全球第一。统计数据显示，2015年，Android平台手机的全球市场份额已经达到53.54％，在中国市场，Android占市场份额的80.02％。
据艾媒咨询统计数据显示，2011年中国Android开发者数量已达78.42万。截止2012年，中国Android市场中应用数量已达27万。Android应用海量增长，质量也良莠不齐，有的应用(恶意应用)中植入恶意代码或植入病毒，这些应用的恶意行为(如损害系统、资费消耗、隐私泄露等)带来了严重的安全隐患。
在国家网络信息安全技术研究所发布的《2013年第一季度中国移动互联网应用安全监测与分析报告》中数据显示：截止2013年4月，其统计的23家应用商店的应用数量总计超过196万，从21家应用商店取样检测发现有13‰的恶意应用，同比2012年第四季度增长了36.8％。业界安全公司提供数据显示，2012年上半年共截获一万七千多款恶意软件，其中78％来自于安卓平台。
Android应用传播的途径比较广泛，除了应用商店之外，用户下载Android应用安装包的途径有论坛、软件下载网站，或通过邮件以及即时通讯软件传输。
Android完全开放的模式给了软件开发者过高的授权，一些不法软件开发者在应用中随意植入恶意代码、病毒，一旦用户下载安装了这些恶意应用就受到了安全威胁，潜在的威胁包括：恶意扣费、恶意推送信息，恶意窃取个人信息、强制或者诱导点击广告等。
Android应用相对来说容易被反编译，因此，一些不法分子会通过技术手段将一些Android应用反编译，替换其中的内容再重新打包发布从中获利。同理也可以将一些知名应用山寨化发布，给这些知名应用带来巨大的损失，即使这些应用开发者通过法律手段维护自己的权益，也将因为电子数据的特殊性，给取证造成一定的难度。
从另外的角度讲，国内大部分应用商店的审核机制尚且不够完善，无论从应用内容方面还是从对应用的安全监测方面，都欠缺很多，这种低门槛的机制导致很多恶意应用开发者有机可乘。另一方面，虽然Android要求应用程序包(即APK，Application Package的缩写)必须有开发者签名，但对开发者的签名证书没有要求，开发者使用自己签发的任意一张自签名证书就可以完成签名。这种情况下，一旦应用出现问题，很难很快的判定问题出现于应用从开发到发布的哪个步骤，也就是很难做到责任追溯。
1.APK的文件结构
Android应用程序包文件(APK)是一种Android操作系统上的应用程序安装文件格式，其英文全称是“application package file”。APK文件基于ZIP文件格式，一个APK文件包含以下文件：
·META-INF文件夹，包含以下内容:
MANIFEST.MF：清单信息
CERT.RSA(或CERT.DSA，后缀名根据自签名证书是RSA算法或DSA算法而不同，RSA算法对应的签名文件为CERT.RSA，DSA算法对应的签名文件为CERT.DSA。)：保存该应用程序的签名证书、签名等信息的签名文件
CERT.SF：保存着SHA1信息资源列表，例如：
Signature-Version:1.0
Created-By:1.0(Android)
SHA1-Digest-Manifest:E53LLxfbPEDKiDc0eUxt8Xc4VUY＝
Name:res/drawable-hdpi/ic_launcher.png
SHA1-Digest:YuN8HjuH/csIGA1V8jxQw62DV0B＝
Name:assets/drawable-mdpi/ic_spark_sdk_close.png
SHA1-Digest:LyOZye2d8Si1oiOovwZyt6updZc＝
Name:res/drawable/ic_logo.png
SHA1-Digest:P6/T9b2m+rZvqv1fvJtbGtfp4/4＝
·res：APK所需要的资源文件夹
·AndroidManifest.xml：一个传统的Android清单文件，用于描述该应用程序的名字、版本号、所需权限、注册的服务、连接的其他应用程序
·classes.dex：classes文件通过DEX编译后的文件格式，用于在Dalvik虚拟机上运行的主要代码部分。
·resources.arsc：编译后的二进制资源文件
2.APK的签名验证机制
APK的发布需要签名，签名机制在Android应用和框架中起着十分重要的作用。Android系统禁止更新安装签名不一致的APK。
1)APK签名机制
APK签名的整个过程大致如下：
1、生成MANIFEST.MF文件：
遍历APK包，对非文件夹非签名文件的文件，逐个进行SHA1的Hash计算，将Hash值Base64编码后写入MANIFEST.MF文件。
2、生成CERT.SF文件：
对上一步生成的MANIFEST.MF文件，计算Hash值并写入CERT.SF，然后将MANIFEST.MF文件中之前计算的所有的Hash值再次计算Hash信息，写入CERT.SF
3、生成CERT.RSA文件
使用私钥对上一步生成的CERT.SF进行签名，同时将签名信息、所采用的算法、公钥证书等信息写入到CERT.RSA
通过对CERT.RSA文件结构进行分析，文件结构如图1所示，可知CERT.RSA文件结构是一个遵循ASN.1编码的PKCS7签名。
2)APK签名验证机制
APK在签名验证过程大致如下：
1、通过解析CERT.RSA文件，获得公钥证书、签名信息以及算法等。
2、使用公钥和算法对CERT.SF文件进行签名验证。
3、上一步通过后，计算MANIFEST.MF中的数据的Hash值，并与CERT.SF中的Hash值逐条比对。
4、上一步通过后，计算MANIFEST.MF中各文件的Hash值，并与MANIFEST.MF中的Hash值逐条比对。
通过以上分析可以知道，APK的签名和验证过程，基于PKI理论体系，通过这样的验证机制，可以确保APK中纳入签名范围内任何一个文件的变化，都将导致APK签名验证失败。如果使用其他证书签名直接替代原有签名的做法，APK验证会发现新的签名证书与第一次安装时的证书不同，安装失败。
综合上述分析可知，虽然Android APK的签名及验证过程基于PKI数字签名技术，但开发者对APK签名时使用的是自签名数字证书。自签名证书存在以下缺点：开发者可以随意申请，自签名证书以及对应的私钥存储于文件中，容易被复制、传播。开发者甚至可以申请两张或者多张证书甄别名完全相同的自签名数字证书。
《中华人民共和国电子签名法》中明确规定，电子签名需要第三方认证的，由依法设立的电子认证服务提供者提供认证服务，电子签名人向电子认证服务提供者申请电子签名认证证书。因此，从这个角度讲，自签名证书并非由“依法设立的电子认证服务提供者”签发，一旦发生法律纠纷，难以受到《中华人民共和国电子签名法》的保护。另外，普通用户因为无法分别开发者的真伪，很可能造成误装恶意应用或假冒应用，并由此带来危害。
从另一个方面讲，Android APK仅有开发者的自签名证书，而涉及APK的检测机构及发布的应用商店对APK没有任何签名，因此无法追究检测机构或应用商店在APK发布上架过程的监管行为。
现在有一些方案也可以对APK进行多个签名，但这种方案都是通过在META-INF文件夹中添加额外的文件来实现的。例如对APK额外生成签名1和签名2，将签名1和签名2写入到一个新的文件(如：ExtraSignature.dat)中，将这个文件放置到META-INF文件夹中，因为Android本身的验证机制不会计算META-INF文件夹中文件的Hash值，所以不会影响APK的安装。尽管如此，这种方案的做法破坏了APK的文件结构，新添加的签名文件很容易被当成是木马或者其他危害系统安全的文件。并且所添加的签名文件格式和结构一般都是自定义的，并不遵守任何规范或者标准要求，无论从友好度还是用户的直观体验来说，都是比较差的，一旦Android版本升级，很容易导致各种问题出现。
发明内容
针对上述技术问题，本发明提出一种Android APK副署签名的解决方案，在不破坏Android现有签名验证机制、不破坏Android文件结构的前提下副署多个签名。通过副署签名机制，可以达到多方对应用监管审查的目的，并能追溯其中每一方的操作行为。例如：开发者、第三方(检测结构及应用商店)各自向“依法设立的电子认证服务提供者(以下简称可信电子认证服务机构)”申请数字证书，所申请的数字证书对APK副署签名，所副署的签名将受到《中华人民共和国电子签名法》的保护。
本发明采用的技术方案为：一种Android APK副署签名验证方法，包括以下步骤：
步骤1，开发者使用原私钥对CERT.SF的签名写入签名文件中；(例如CERT.RSA或CERT.DSA，RSA公钥算法对应的签名文件为CERT.RSA，DSA公钥算法对应的签名文件为CERT.DSA)；
步骤2，第三方向可信电子认证服务机构申请数字证书，第三方对CERT.SF进行副署签名，副署签名中包含签名时间，将副署签名信息添加到CERT.RSA或CERT.DSA文件中；
步骤3，Android系统对APK进行验证，按照Android原生的签名验证方法验证APK，若验证通过，允许安装该APK，否则拒绝安装该APK。若通过第三方系统应用软件(如应用商店、应用管家等)安装APK，若原生APK签名验证通过，可进一步依次验证副署签名：若所有副署签名验证都通过，允许安装该APK，否则拒绝安装该APK。
进一步的，步骤2后进一步包括：如果需要提供更为准确的时间证明，可以向可信时间戳服务请求副署签名，并将副署签名信息添加到CERT.RSA或CERT.DSA文件中。可信时间戳服务器对APK的副署签名可为开发者提供知识产权保障。
APK副署签名流程为：
步骤2.1，使用Android原生方式验证APK；
步骤2.2，若验证通过，则执行步骤2.3，若验证未通过，则返回APK异常；
步骤2.3，将CERT.SF内容计算Hash值，使用第三方副署签名证书进行签名，
步骤2.4，将第三方签名副署到CERT.RSA或CERT.DSA中；
步骤2.5，如果需要副署其他副署签名，重复步骤2.1至2.5。
副署签名后，副署签名者的数字证书存放于CERT.RSA或CERT.DSA中相应的Certificates集合中，或放在副署签名中。
在验证一个已经副署签名的APK时，进一步包括：
步骤3.1，解析APK，从CERT.RSA或CERT.DSA中，解析出原有的开发者签名，以及一个或者多个第三方的副署签名；
步骤3.2，使用Android原生的签名验证方法验证APK，若通过验证，则执行步骤3.3，若未通过验证，返回APK异常；
步骤3.3，验证副署签名：若是时间戳副署签名，则将CERT.SF内容计算Hash值，将副署签名发送至可信时间戳服务器验证副署签名，并获取验证结果；若不是时间戳副署签名，则将CERT.SF内容计算Hash值，验证第三方副署签名，并获取验证结果；
步骤3.4，若还有未验证的副署签名，则重复步骤3.3，否则得出验证结果。验证副署签名的条件包括但不限于证书有效期、证书颁发者、CRL、OCSP、可信名单(即合法可信的证书列表)。最终所有验证都通过，说明该应用是可信的、安全的。
本发明具有以下有益效果：相对于其他APK签名方案，本发明提出的APK副署签名方案在不破坏Android现有签名验证机制、不破坏Android文件结构的前提下为APK副署多个签名，并可对追溯任意一个副署签名。在实际应用中也存在巨大的价值：
1)使用依法设立的电子认证服务提供者签发的数字证书多方副署签名后，副署签名将受到《中华人民共和国电子签名法》的保护，可追究任意一方副署签名者的责任。
2)在副署签名中时加入签名可信时间，可为APK提供有力的时效性性证明，既可用于证明签名时间，也可用于知识产权证明及版权保护。
3)副署签名后，APK等同于开发者实名认证，在安装APK之前就可以验证其有效性与合法性，从而在源头上防止恶意应用的危害。
附图说明
图1为本发明实施例的副署签名前CERT.RSA的文件结构。
图2为本发明实施例的APK副署签名流程。
图3为本发明实施例的副署签名后CERT.RSA的文件结构。
图4为本发明实施例的APK副署签名验证流程。
具体实施方式
为了便于本领域技术人员的理解，下面结合实施例与附图对本发明作进一步的说明。
名词解释：自签名数字证书：(self signed certificate)：数字证书的使用者与签发者相同的数字证书，即该证书由其本身的私钥签发。
证书甄别名称(distinguished name)：数字证书持有者的唯一身份标识。
时间戳(Time Stamp)：时间戳是一个经加密后形成的凭证文档，它包含三个部分：需要加时间戳的文件的摘要、时间戳服务受理的日期和时间、时间戳服务的数字签名。可以理解为时间戳是数字签名技术的一种变种的应用。
APK副署签名的原理如下：
一个APK文件包含以下文件：
·META-INF文件夹，包含以下内容：
MANIFEST.MF：清单信息
CERT.RSA(或CERT.DSA，后缀名根据自签名证书是RSA算法或DSA算法而不同，RSA算法对应的签名文件为CERT.RSA，DSA算法对应的签名文件为CERT.DSA。本实施例默认使用RSA算法的数字证书，DSA算法同样适用于本实施例的方案)：保存该应用程序的证书、签名等信息的签名文件
CERT.SF：保存着SHA1信息资源列表
res：APK所需要的资源文件夹
·AndroidManifest.xml：一个传统的Android清单文件，用于描述该应用程序的名字、版本号、所需权限、注册的服务、连接的其他应用程序
·classes.dex：classes文件通过DEX编译后的文件格式，用于在Dalvik虚拟机上运行的主要代码部分。
·resources.arsc：编译后的二进制资源文件。
本实施例的Android APK副署签名验证方法，包括以下步骤：
步骤1，开发者原私钥对CERT.SF签名并将签名信息写入签名文件中(签名文件可以是CERT.RSA或CERT.DSA，后缀名根据自签名证书的公钥算法而不同，RSA公钥算法对应的签名文件为CERT.RSA，DSA公钥算法对应的签名文件为CERT.DSA。本实施例默认使用RSA算法的数字证书，DSA算法同样适用于本实施例的方案)；
步骤2，第三方向可信电子认证服务机构申请数字证书，第三方对CERT.SF进行副署签名，副署签名中包含签名时间，将副署签名信息添加到CERT.RSA中，第三方可以是开发者、应用检测机构、应用商店等；
步骤3，Android系统对APK进行验证，按照Android原生的签名验证方法验证APK，若验证通过，允许安装该APK，否则拒绝安装该APK；若通过第三方系统应用软件安装APK，若原生APK签名验证通过，进一步依次验证副署签名：若所有副署签名验证都通过，允许安装该APK，否则拒绝安装该APK。
实施例的副署签名前CERT.RSA的文件结构分析如下：
CERT.RSA文件是一个基于ASN.1编码的PKCS7包，包内的签名实际是开发者私钥对CERT.SF的签名。ASN.1编码的文件结构特点使得可以在PKCS文件中附加一个或者多个ASN.1编码的其他签名信息，且添加的其他签名信息不会对原有的PKCS7数据造成任何影响。副署签名前CERT.RSA的文件结构如图1所示。
第三方(例如检测机构、应用商店等)可对CERT.SF进行副署签名，副署签名中可包含签名时间，副署签名信息添加到CERT.RSA文件中。以此类推，可以通过这种方法为APK副署多个签名。如果需要提供更为准确的时间证明，可以向可信时间戳服务请求副署签名，可信时间戳服务器对APK的副署签名可为开发者提供知识产权保障。
APK副署签名流程如图2所述：步骤1，使用Android原生方式验证APK；步骤2，若验证通过，则将CERT.SF内容计算Hash值，使用第三方副署签名证书进行签名，若验证未通过，则返回APK异常；步骤3，将第三方签名副署到CERT.RSA中；步骤4，如果需要副署多个副署签名，重复步骤1至3。
副署签名后，副署签名者的数字证书及可以存放于CERT.RSA中相应的Certificates集合中，也可以放在副署签名中。副署签名后CERT.RSA的文件结构如图3所示。
如图4所示，在验证一个已经副署签名的APK时，解析APK，从CERT.RSA中，解析出原有的开发者签名，以及一个或者多个第三方(也可能是多方)的副署签名。首先按照Android原生的签名验证方法验证APK，然后依次验证副署签名，验证副署签名的条件包括但不限于证书有效期、证书颁发者、CRL、OCSP、可信名单等。最终所有验证都通过，说明该应用是可信的、安全的。
以上的实施例仅为说明本发明的技术思想，不能以此限定本发明的保护范围，凡是按照本发明提出的技术思想，在技术方案基础上所做的任何改动，均落入本发明保护范围之内。本发明未涉及的技术均可通过现有的技术加以实现。

Claims (7)

1.一种Android APK副署签名验证方法，其特征在于，包括以下步骤：
步骤1，开发者原私钥对CERT.SF签名并将签名写入签名文件中；
步骤2，第三方向可信电子认证服务机构申请数字证书，使用数字证书对CERT.SF进行副署签名，副署签名中包含签名时间，将副署签名信息添加到所述签名文件中，第三方可以是开发者、应用检测机构、应用商店等；
步骤3，Android系统对APK进行验证，按照Android原生的签名验证方法验证APK，若验证通过，允许安装该APK，否则拒绝安装该APK；若通过第三方系统应用软件安装APK，若原生APK签名验证通过，进一步依次验证副署签名：若所有副署签名验证都通过，允许安装该APK，否则拒绝安装该APK。
2.根据权利要求1所述的Android APK副署签名验证方法，其特征在于：所述签名文件是CERT.RSA或CERT.DSA，后缀名根据开发者签名证书的公钥算法而不同，RSA公钥算法对应的签名文件为CERT.RSA，DSA公钥算法对应的签名文件为CERT.DSA。
3.根据权利要求2所述的Android APK副署签名验证方法，其特征在于，步骤2后进一步包括：向可信时间戳服务器请求副署签名，并将副署签名信息添加到CERT.RSA或CERT.DSA文件中。
4.根据权利要求2或3所述的Android APK副署签名验证方法，其特征在于，APK副署签名流程为：
步骤2.1，使用Android原生方式验证APK；
步骤2.2，若验证通过，则执行步骤2.3，若验证未通过，则返回APK异常；
步骤2.3，将CERT.SF内容计算Hash值，使用第三方副署签名证书进行签名，
步骤2.4，将第三方签名副署到CERT.RSA或CERT.DSA中；
步骤2.5，如果需要副署其他副署签名，重复步骤2.1至2.5。
5.根据权利要求4所述的Android APK副署签名验证方法，其特征在于：副署签名后，副署签名者的数字证书存放于CERT.RSA或CERT.DSA文件结构中相应的Certificates集合中，或放在副署签名中。
6.根据权利要求2或3所述的Android APK副署签名验证方法，其特征在于，步骤3进一步包括：
步骤3.1，解析APK，从CERT.RSA或CERT.DSA中，解析出原生的开发者签名，以及一个或者多个第三方的副署签名；
步骤3.2，使用Android原生的签名验证方法验证APK，若通过验证，则执行步骤3.3，若未通过验证，返回APK异常；
步骤3.3，验证副署签名：若是时间戳副署签名，则将CERT.SF内容计算Hash值，将副署签名发送至可信时间戳服务器验证副署签名，并获取验证结果；若不是时间戳副署签名，则将CERT.SF内容计算Hash值，验证第三方副署签名，并获取验证结果；
步骤3.4，若还有未验证的副署签名，则重复步骤3.3，否则得出验证结果。
7.根据权利要求6所述的Android APK副署签名验证方法，其特征在于：验证副署签名的条件包括但不限于证书有效期、证书颁发者、CRL、OCSP、可信名单。
CN201610525072.7A 2016-07-04 2016-07-04 一种Android APK副署签名及验证方法 Active CN106209379B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201610525072.7A CN106209379B (zh) 2016-07-04 2016-07-04 一种Android APK副署签名及验证方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201610525072.7A CN106209379B (zh) 2016-07-04 2016-07-04 一种Android APK副署签名及验证方法

Publications (2)

Publication Number Publication Date
CN106209379A true CN106209379A (zh) 2016-12-07
CN106209379B CN106209379B (zh) 2019-09-10

Family

ID=57466282

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201610525072.7A Active CN106209379B (zh) 2016-07-04 2016-07-04 一种Android APK副署签名及验证方法

Country Status (1)

Country Link
CN (1) CN106209379B (zh)

Cited By (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106612183A (zh) * 2016-12-27 2017-05-03 哈尔滨安天科技股份有限公司 国产操作系统下应用软件的交叉数字签名方法及系统
CN106656513A (zh) * 2017-02-24 2017-05-10 福建魔方电子科技有限公司 安卓平台上apk文件的二次打包签名验证方法
CN106888094A (zh) * 2017-02-16 2017-06-23 中国移动通信集团公司 一种签名方法及服务器
CN106899593A (zh) * 2017-02-27 2017-06-27 深圳数字电视国家工程实验室股份有限公司 一种app重打包验证方法和装置
CN107301343A (zh) * 2017-06-19 2017-10-27 大连中科创达软件有限公司 安全数据处理方法、装置及电子设备
CN107463806A (zh) * 2017-06-20 2017-12-12 国家计算机网络与信息安全管理中心 一种Android应用程序安装包的签名和验签方法
CN107632932A (zh) * 2017-09-11 2018-01-26 天津麒麟信息技术有限公司 一种多级校验的软件仓库可靠性检测方法
CN108683502A (zh) * 2018-03-30 2018-10-19 上海连尚网络科技有限公司 一种数字签名验证方法、介质及设备
CN108874429A (zh) * 2018-07-20 2018-11-23 珠海宏桥高科技有限公司 一种Android系统一体化自动打包方法
CN109034805A (zh) * 2018-08-09 2018-12-18 江苏先安科技有限公司 一种适用于区块链和嵌入式领域的新型时间戳签名验证方法
CN109450883A (zh) * 2018-10-26 2019-03-08 北京梆梆安全科技有限公司 一种数字证书的破解风险检测方法及装置
CN110704815A (zh) * 2019-09-29 2020-01-17 北京数字认证股份有限公司 数据包代码签名及其验证方法、装置、系统及存储介质
CN110851821A (zh) * 2019-11-01 2020-02-28 艾体威尔电子技术(北京)有限公司 一种Android智能设备APK安全管控方法
CN111274552A (zh) * 2020-01-07 2020-06-12 惠州市德赛西威汽车电子股份有限公司 一种升级包的签名及验签方法、存储介质
CN111814136A (zh) * 2020-06-30 2020-10-23 中国信息通信研究院 安卓应用程序签名及验签方法、装置、以及签名验签系统
CN113221072A (zh) * 2021-04-16 2021-08-06 江苏先安科技有限公司 一种基于安卓系统的第三方副署签名、验证方法
CN113541973A (zh) * 2021-09-17 2021-10-22 杭州天谷信息科技有限公司 一种电子签名封装方法
CN113779560A (zh) * 2021-11-15 2021-12-10 北京信达环宇安全网络技术有限公司 软件安装方法、装置、电子设备及存储介质
US11750732B1 (en) 2023-02-20 2023-09-05 14788591 Canada Inc. System for introducing features to an in-vehicle infotainment system and method of use thereof

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150156024A1 (en) * 2013-12-04 2015-06-04 Telefonica Digital Espana, S.L.U. Computer implemented method and a computer system to prevent security problems in the use of digital certificates in code signing and a computer program product thereof
CN104753881A (zh) * 2013-12-30 2015-07-01 上海格尔软件股份有限公司 一种基于软件数字证书和时间戳的WebService安全认证访问控制方法
CN105391717A (zh) * 2015-11-13 2016-03-09 福建联迪商用设备有限公司 一种apk签名认证方法及其系统

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150156024A1 (en) * 2013-12-04 2015-06-04 Telefonica Digital Espana, S.L.U. Computer implemented method and a computer system to prevent security problems in the use of digital certificates in code signing and a computer program product thereof
CN104753881A (zh) * 2013-12-30 2015-07-01 上海格尔软件股份有限公司 一种基于软件数字证书和时间戳的WebService安全认证访问控制方法
CN105391717A (zh) * 2015-11-13 2016-03-09 福建联迪商用设备有限公司 一种apk签名认证方法及其系统

Cited By (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106612183A (zh) * 2016-12-27 2017-05-03 哈尔滨安天科技股份有限公司 国产操作系统下应用软件的交叉数字签名方法及系统
CN106612183B (zh) * 2016-12-27 2020-05-22 哈尔滨安天科技集团股份有限公司 国产操作系统下应用软件的交叉数字签名方法及系统
CN106888094B (zh) * 2017-02-16 2019-06-14 中国移动通信集团公司 一种签名方法及服务器
CN106888094A (zh) * 2017-02-16 2017-06-23 中国移动通信集团公司 一种签名方法及服务器
CN106656513A (zh) * 2017-02-24 2017-05-10 福建魔方电子科技有限公司 安卓平台上apk文件的二次打包签名验证方法
CN106656513B (zh) * 2017-02-24 2019-09-13 福建魔方电子科技有限公司 安卓平台上apk文件的二次打包签名验证方法
CN106899593A (zh) * 2017-02-27 2017-06-27 深圳数字电视国家工程实验室股份有限公司 一种app重打包验证方法和装置
CN107301343A (zh) * 2017-06-19 2017-10-27 大连中科创达软件有限公司 安全数据处理方法、装置及电子设备
CN107301343B (zh) * 2017-06-19 2021-03-26 大连中科创达软件有限公司 安全数据处理方法、装置及电子设备
CN107463806A (zh) * 2017-06-20 2017-12-12 国家计算机网络与信息安全管理中心 一种Android应用程序安装包的签名和验签方法
CN107463806B (zh) * 2017-06-20 2020-08-14 国家计算机网络与信息安全管理中心 一种Android应用程序安装包的签名和验签方法
CN107632932A (zh) * 2017-09-11 2018-01-26 天津麒麟信息技术有限公司 一种多级校验的软件仓库可靠性检测方法
CN108683502A (zh) * 2018-03-30 2018-10-19 上海连尚网络科技有限公司 一种数字签名验证方法、介质及设备
CN108874429A (zh) * 2018-07-20 2018-11-23 珠海宏桥高科技有限公司 一种Android系统一体化自动打包方法
CN109034805A (zh) * 2018-08-09 2018-12-18 江苏先安科技有限公司 一种适用于区块链和嵌入式领域的新型时间戳签名验证方法
CN109450883B (zh) * 2018-10-26 2021-08-27 北京梆梆安全科技有限公司 一种数字证书的破解风险检测方法及装置
CN109450883A (zh) * 2018-10-26 2019-03-08 北京梆梆安全科技有限公司 一种数字证书的破解风险检测方法及装置
CN110704815A (zh) * 2019-09-29 2020-01-17 北京数字认证股份有限公司 数据包代码签名及其验证方法、装置、系统及存储介质
CN110851821A (zh) * 2019-11-01 2020-02-28 艾体威尔电子技术(北京)有限公司 一种Android智能设备APK安全管控方法
CN111274552A (zh) * 2020-01-07 2020-06-12 惠州市德赛西威汽车电子股份有限公司 一种升级包的签名及验签方法、存储介质
CN111814136A (zh) * 2020-06-30 2020-10-23 中国信息通信研究院 安卓应用程序签名及验签方法、装置、以及签名验签系统
CN113221072A (zh) * 2021-04-16 2021-08-06 江苏先安科技有限公司 一种基于安卓系统的第三方副署签名、验证方法
CN113541973A (zh) * 2021-09-17 2021-10-22 杭州天谷信息科技有限公司 一种电子签名封装方法
CN113541973B (zh) * 2021-09-17 2021-12-21 杭州天谷信息科技有限公司 一种电子签名封装方法
CN113779560A (zh) * 2021-11-15 2021-12-10 北京信达环宇安全网络技术有限公司 软件安装方法、装置、电子设备及存储介质
US11750732B1 (en) 2023-02-20 2023-09-05 14788591 Canada Inc. System for introducing features to an in-vehicle infotainment system and method of use thereof

Also Published As

Publication number Publication date
CN106209379B (zh) 2019-09-10

Similar Documents

Publication Publication Date Title
CN106209379B (zh) 一种Android APK副署签名及验证方法
US10516662B2 (en) System and method for authenticating the legitimacy of a request for a resource by a user
Kim et al. Certified malware: Measuring breaches of trust in the windows code-signing pki
US11165579B2 (en) Decentralized data authentication
Kotzias et al. Certified PUP: abuse in authenticode code signing
Chen et al. Oauth demystified for mobile application developers
Basin et al. ARPKI: Attack resilient public-key infrastructure
CN107463806B (zh) 一种Android应用程序安装包的签名和验签方法
US9584543B2 (en) Method and system for web integrity validator
US11374961B2 (en) Methods for verification of software object authenticity and integrity
CN101834860B (zh) 一种远程动态验证客户端软件完整性的方法
CN104156638B (zh) 一种面向安卓系统软件的扩展签名的实现方法
CN105635070B (zh) 一种数字文件的防伪方法及系统
US20100115269A1 (en) Revoking Malware in a Computing Device
CN106355081A (zh) 一种安卓程序启动校验方法和装置
JP2014500997A (ja) ソフトウェア署名証明書評判モデル
Ahmed et al. Turning trust around: smart contract-assisted public key infrastructure
CN115550060A (zh) 基于区块链的可信证书验证方法、装置、设备和介质
Tiwari et al. India’s “Aadhaar” Biometric ID: Structure, Security, and Vulnerabilities
Zhao et al. Potential risks arising from the absence of signature verification in miniapp plugins
Hernández-Ardieta et al. Enhancing the reliability of digital signatures as non-repudiation evidence under a holistic threat model
Milinković et al. Evaluation of some time-stamping authority software
Kotzias A systematic empirical analysis of unwanted software abuse, prevalence, distribution, and economics
QUAN et al. SADT: Syntax-aware differential testing of certificate validation in SSL/TLS Implementations.(2020)
Nezhadian et al. Certificate Reuse in Android Applications

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant