apk签名有什么用

apk签名有什么用

       谢谢大家给我提供关于apk签名有什么用的问题集合。我将从不同的角度回答每个问题，并提供一些相关资源和参考资料，以便大家进一步学习和了解。

1.Android V1及V2签名原理简析

2.安卓开发 导出apk文件 一定要设置签名吗

3.我的android项目已经生成了签名但不知道这个签名是什么也不知在哪查看

4.一文弄懂关于证书，签名，ssl，android包签名机制。

5.APK签名机制之——V2签名机制详解

6.什么是签名，为什么要给应用程序签名，如何

Android V1及V2签名原理简析

        Android为了保证系统及应用的安全性，在安装APK的时候需要校验包的完整性，同时，对于覆盖安装的场景还要校验新旧是否匹配，这两者都是通过Android签名机制来进行保证的，本文就简单看下Android的签名与校验原理，分一下几个部分分析下：

        签名是摘要与非对称密钥加密相相结合的产物，摘要就像内容的一个指纹信息，一旦内容被篡改，摘要就会改变，签名是摘要的加密结果，摘要改变，签名也会失效。Android APK签名也是这个道理，如果APK签名跟内容对应不起来，Android系统就认为APK内容被篡改了，从而拒绝安装，以保证系统的安全性。目前Android有三种签名V1、V2（N）、V3（P），本文只看前两种V1跟V2，对于V3的轮密先不考虑。先看下只有V1签名后APK的样式：

        再看下只有V2签名的APK包样式：

        同时具有V1 V2签名：

        可以看到，如果只有V2签名，那么APK包内容几乎是没有改动的，META_INF中不会有新增文件，按Google官方文档：在使用v2签名方案进行签名时，会在APK文件中插入一个APK签名分块，该分块位于zip中央目录部分之前并紧邻该部分。在APK签名分块内，签名和签名者身份信息会存储在APK签名方案v2分块中，保证整个APK文件不可修改 ，如下图：

        而V1签名是通过META-INF中的三个文件保证签名及信息的完整性：

        V1签名是如何保证信息的完整性呢？V1签名主要包含三部分内容，如果狭义上说签名跟公钥的话，仅仅在.rsa文件中，V1签名的三个文件其实是一套机制，不能单单拿一个来说事，

        如果对APK中的资源文件进行了替换，那么该资源的摘要必定发生改变，如果没有修改MANIFEST.MF中的信息，那么在安装时候V1校验就会失败，无法安装，不过如果篡改文件的同时，也修改其MANIFEST.MF中的摘要值，那么MANIFEST.MF校验就可以绕过。

        CERT.SF个人觉得有点像冗余，更像对文件完整性的二次保证，同绕过MANIFEST.MF一样，.SF校验也很容易被绕过。

        CERT.RSA与CERT.SF是相互对应的，两者名字前缀必须一致，不知道算不算一个无聊的标准。看下CERT.RSA文件内容：

        CERT.RSA文件里面存储了证书公钥、过期日期、发行人、加密算法等信息，根据公钥及加密算法，Android系统就能计算出CERT.SF的摘要信息，其严格的格式如下：

        从CERT.RSA中，我们能获的证书的指纹信息，在微信分享、第三方SDK申请的时候经常用到，其实就是公钥+开发者信息的一个签名：

        除了CERT.RSA文件，其余两个签名文件其实跟keystore没什么关系，主要是文件自身的摘要及二次摘要，用不同的keystore进行签名，生成的MANIFEST.MF与CERT.SF都是一样的，不同的只有CERT.RSA签名文件。也就是说前两者主要保证各个文件的完整性，CERT.RSA从整体上保证APK的来源及完整性，不过META_INF中的文件不在校验范围中，这也是V1的一个缺点。V2签名又是如何保证信息的完整性呢？

        前面说过V1签名中文件的完整性很容易被绕过，可以理解单个文件完整性校验的意义并不是很大 ，安装的时候反而耗时，不如采用更加简单的便捷的校验方式。V2签名就不针对单个文件校验了，而是针对APK进行校验 ，将APK分成1M的块，对每个块计算值摘要，之后针对所有摘要进行摘要，再利用摘要进行签名。

        也就是说，V2摘要签名分两级，第一级是对APK文件的1、3 、4 部分进行摘要，第二级是对第一级的摘要集合进行摘要，然后利用秘钥进行签名。安装的时候，块摘要可以并行处理，这样可以提高校验速度。

        APK是先摘要，再签名，先看下摘要的定义：Message Digest：摘要是对消息数据执行一个单向Hash，从而生成一个固定长度的Hash值，这个值就是消息摘要，至于常听到的MD5、SHA1都是摘要算法的一种。理论上说，摘要一定会有碰撞，但只要保证有限长度内碰撞率很低就可以，这样就能利用摘要来保证消息的完整性，只要消息被篡改，摘要一定会发生改变。但是，如果消息跟摘要同时被修改，那就无从得知了。

        而数字签名是什么呢（公钥数字签名），利用非对称加密技术，通过私钥对摘要进行加密，产生一个字符串，这个字符串+公钥证书就可以看做消息的数字签名，如RSA就是常用的非对称加密算法。在没有私钥的前提下，非对称加密算法能确保别人无法伪造签名，因此数字签名也是对发送者信息真实性的一个有效证明。不过由于Android的keystore证书是自签名的，没有第三方权威机构认证，用户可以自行生成keystore，Android签名方案无法保证APK不被二次签名。

        知道了摘要跟签名的概念后，再来看看Android的签名文件怎么来的？如何影响原来APK包？通过sdk中的apksign来对一个APK进行签名的命令如下：

        其主要实现在 android/platform/tools/apksig 文件夹中，主体是ApkSigner.java的sign函数，函数比较长，分几步分析

        先来看这一步，ApkUtils.findZipSections，这个函数主要是解析APK文件，获得ZIP格式的一些简单信息，并返回一个ZipSections，

        ZipSections包含了ZIP文件格式的一些信息，比如中央目录信息、中央目录结尾信息等，对比到zip文件格式如下：

        获取到 ZipSections之后，就可以进一步解析APK这个ZIP包，继续走后面的签名流程，

        可以看到先进行了一个V2签名的检验，这里是用来签名，为什么先检验了一次？第一次签名的时候会直接走这个异常逻辑分支，重复签名的时候才能获到取之前的V2签名，怀疑这里获取V2签名的目的应该是为了排除V2签名，并获取V2签名以外的数据块，因为签名本身不能被算入到签名中，之后会解析中央目录区，构建一个DefaultApkSignerEngine用于签名

        先解析中央目录区，获取AndroidManifest文件，获取minSdkVersion(影响签名算法)，并构建DefaultApkSignerEngine，默认情况下V1 V2签名都是打开的。

        第五步与第六步的主要工作是：apk的预处理，包括目录的一些排序之类的工作，应该是为了更高效处理签名，预处理结束后，就开始签名流程，首先做的是V1签名（默认存在，除非主动关闭）：

        步骤7、8、9都可以看做是V1签名的处理逻辑，主要在V1SchemeSigner中处理，其中包括创建META-INFO文件夹下的一些签名文件，更新中央目录、更新中央目录结尾等，流程不复杂，不在赘述，简单流程就是：

        这里特殊提一下重复签名的问题：对一个已经V1签名的APK再次V1签名不会有任何问题 ，原理就是：再次签名的时候，会排除之前的签名文件。

        可以看到目录、META-INF文件夹下的文件、sf、rsa等结尾的文件都不会被V1签名进行处理，所以这里不用担心多次签名的问题。接下来就是处理V2签名。

        V2SchemeSigner处理V2签名，逻辑比较清晰，直接对V1签名过的APK进行分块摘要，再集合签名，V2签名不会改变之前V1签名后的任何信息，签名后，在中央目录前添加V2签名块，并更新中央目录结尾信息，因为V2签名后，中央目录的偏移会再次改变：

        签名校验的过程可以看做签名的逆向，只不过覆盖安装可能还要校验公钥及证书信息一致，否则覆盖安装会失败。签名校验的入口在PackageManagerService的install里，安装官方文档，7.0以上的手机优先检测V2签名，如果V2签名不存在，再校验V1签名，对于7.0以下的手机，不存在V2签名校验机制，只会校验V1，所以，如果你的App的miniSdkVersion<24(N)，那么你的签名方式必须内含V1签名：

        校验流程就是签名的逆向，了解签名流程即可，本文不求甚解，有兴趣自己去分析，只是额外提下覆盖安装，覆盖安装除了检验APK自己的完整性以外，还要校验证书是否一致只有证书一致（同一个keystore签名），才有可能覆盖升级。覆盖安装同全新安装相比较多了几个校验

        这里只关心证书部分：

        Android V1及V2签名签名原理简析

        仅供参考，欢迎指正

安卓开发 导出apk文件 一定要设置签名吗

        因工作需要对系统的wifi和以太网进行配置，需要获取到系统权限以后才能进行操作，因此研究了下对apk 进行系统签名以获取系统权限，其实本来打算如果root可以的话直接通过root的方式（设备已经root），后来找了半天发现没有api进行修改，无奈只能进行系统签名了，有童鞋知道root方式修改不妨告诉我一下。

        这些文件可以问系统厂商获取，如果是原生系统可以到系统源码目录下获取。

        如果报以下的错误 ,这时候就用到准备的libconscrypt_openjdk_jni.so 文件

        为了检测我们的应用是否已经签名成功 可以获取系统权限，看看能否获取到。

        结果:

        在上一种方式中，我们成功对我们的apk进行了系统签名，并且能使用系统权限，但是必须每次打包出apk再进行签名 对调试很不方便，下面我们可以生成带有系统签名的签名文件，在项目中使用，就不需要每次手动进行签名。

        bubble可以替换为自己喜欢的名称,这一步要输入密码，我尝试输入其他不行，只能输入android。

        bubble 可替换为自己喜欢的password和alias

        到这里 两种对app进行系统签名的方式完成，如有不足，欢迎指出.

我的android项目已经生成了签名但不知道这个签名是什么也不知在哪查看

       不需要签名的

       生成apk最懒惰的方法是：

       只要你运行过android项目，到工作目录的bin文件夹下就能找到与项目同名的apk文件，这种apk默认是已经使用debug用户签名的。

       如果想要自己给apk签名：

       签名的意义

       为了保证每个应用程序开发商合法ID，防止部分开放商可能通过使用相同的Package Name来混淆替换已经安装的程序，我们需要对我们发布的APK文件进行唯一签名，保证我们每次发布的版本的一致性(如自动更新不会因为版本不一致而无法安装)。

       2.签名的步骤

       a.创建key

       b.使用步骤a中产生的key对apk签名

       3.具体操作

       方法一： 命令行下对apk签名（原理）

       创建key，需要用到keytool.exe (位于jdk1.6.0_24\jre\bin目录下)，使用产生的key对apk签名用到的是jarsigner.exe (位于jdk1.6.0_24\bin目录下)，把上两个软件所在的目录添加到环境变量path后，打开cmd输入

       D:\>keytool -genkey -alias demo.keystore -keyalg RSA -validity 40000 -keystore demo.keystore/*说明：-genkey 产生密钥 ? -alias demo.keystore 别名 demo.keystore ? -keyalg RSA 使用RSA算法对签名加密 ? -validity 40000 有效期限4000天 ? -keystore demo.keystore */D:\>jarsigner -verbose -keystore demo.keystore -signedjar demo_signed.apk demo.apk demo.keystore/*说明：-verbose 输出签名的详细信息 ? -keystore?demo.keystore 密钥库位置 ? -signedjar demor_signed.apk demo.apk demo.keystore 正式签名，三个参数中依次为签名后产生的文件demo_signed，要签名的文件demo.apk和密钥库demo.keystore.*/

       注意事项：android工程的bin目录下的demo.apk默认是已经使用debug用户签名的，所以不能使用上述步骤对此文件再次签名。正确步骤应该是:在工程点击右键->Anroid Tools-Export Unsigned Application Package导出的apk采用上述步骤签名。

       方法二：使用Eclipse导出带签名的apk

       Eclipse直接能导出带签名的最终apk，非常方便，推荐使用，步骤如下：

       第一步：导出。

       第二步：创建密钥库keystore,输入密钥库导出位置和密码，记住密码，下次Use existing keystore会用到。

       第三步：填写密钥库信息，填写一些apk文件的密码，使用期限和组织单位的信息。

       第四步：生成带签名的apk文件，到此就结束了。

       第五步：如果下次发布版本的时候，使用前面生成的keystore再签名。

       第六步：Next,Next,结束！

       方法三：使用IntelliJ IDEA导出带签名的apk?

       方法步骤基本和Eclipse相同，大概操作路径是：菜单Tools->Andrdoid->Export signed apk。

       4.签名之后，用zipalign(压缩对齐)优化你的APK文件。

       未签名的apk不能使用，也不能优化。签名之后的apk谷歌推荐使用zipalign.exe(位于android-sdk-windows\tools目录下)工具对其优化：

       D:\>zipalign -v 4 demo_signed.apk final.apk

       如上，zipalign能够使apk文件中未压缩的数据在4个字节边界上对齐（4个字节是一个性能很好的值），这样android系统就可以使用mmap()(请自行查阅这个函数的用途)函数读取文件，可以在读取资源上获得较高的性能，

       PS:1.在4个字节边界上对齐的意思就是，一般来说，是指编译器吧4个字节作为一个单位来进行读取的结果，这样的话，CPU能够对变量进行高效、快速的访问（较之前不对齐）。

        2.对齐的根源：android系统中的Davlik虚拟机使用自己专有的格式DEX，DEX的结构是紧凑的，为了让运行时的性能更好，可以进一步用"对齐"进一步优化，但是大小一般会有所增加。

       5.签名对你的App的影响。

        你不可能只做一个APP，你可能有一个宏伟的战略工程，想要在生活，服务，游戏，系统各个领域都想插足的话，你不可能只做一个APP，谷歌建议你把你所有的APP都使用同一个签名证书。

        使用你自己的同一个签名证书，就没有人能够覆盖你的应用程序，即使包名相同，所以影响有：

       1) App升级。 使用相同签名的升级软件可以正常覆盖老版本的软件，否则系统比较发现新版本的签名证书和老版本的签名证书不一致，不会允许新版本安装成功的。

       2) App模块化。android系统允许具有相同的App运行在同一个进程中，如果运行在同一个进程中，则他们相当于同一个App，但是你可以单独对他们升级更新，这是一种App级别的模块化思路。

       3) 允许代码和数据共享。android中提供了一个基于签名的Permission标签。通过允许的设置，我们可以实现对不同App之间的访问和共享，如下：

       AndroidManifest.xml：<permission android:protectionLevel="normal" />

       其中protectionLevel标签有4种值：normal(缺省值),dangerous, signature,signatureOrSystem。简单来说，normal是低风险的，所有的App不能访问和共享此App。dangerous是高风险的，所有的App都能访问和共享此App。signature是指具有相同签名的App可以访问和共享此App。signatureOrSystem是指系统image中App和具有相同签名的App可以访问和共享此App，谷歌建议不要使用这个选项，因为签名就足够了，一般这个许可会被用在在一个image中需要共享一些特定的功能的情况下。

一文弄懂关于证书，签名，ssl，android包签名机制。

       签名的apk自己无法查看，是安装的时候android系统验证用的。

       1.签名的意义

       为了保证每个应用程序开发商合法ID，防止部分开放商可能通过使用相同的Package Name来混淆替换已经安装的程序，我们需要对我们发布的APK文件进行唯一签名，保证我们每次发布的版本的一致性(如自动更新不会因为版本不一致而无法安装)。

       2.签名的步骤

       a.创建key

       b.使用步骤a中产生的key对apk签名

       3.具体操作， 命令行下对apk签名（原理）

       创建key，需要用到keytool.exe (位于jdk1.6.0_24\jre\bin目录下)，使用产生的key对apk签名用到的是jarsigner.exe (位于jdk1.6.0_24\bin目录下)，把上两个软件所在的目录添加到环境变量path后，打开cmd输入

       D:\>keytool -genkey -alias demo.keystore -keyalg RSA -validity 40000 -keystore demo.keystore/*说明：-genkey 产生密钥 -alias demo.keystore 别名 demo.keystore -keyalg RSA 使用RSA算法对签名加密 -validity 40000 有效期限4000天 -keystore demo.keystore */D:\>jarsigner -verbose -keystore demo.keystore -signedjar demo_signed.apk demo.apk demo.keystore/*说明：-verbose 输出签名的详细信息 -keystore demo.keystore 密钥库位置 -signedjar demor_signed.apk demo.apk demo.keystore 正式签名，三个参数中依次为签名后产生的文件demo_signed，要签名的文件demo.apk和密钥库demo.keystore.*/

       注意事项：android工程的bin目录下的demo.apk默认是已经使用debug用户签名的，所以不能使用上述步骤对此文件再次签名。正确步骤应该是:在工程点击右键->Anroid Tools-Export Unsigned Application Package导出的apk采用上述步骤签名。

APK签名机制之——V2签名机制详解

        所有的概念都基于一个非常重要的基础：

        rsa 非对称加密算法 ：

        先感受下几个概念

        PKI。

        PKI是公钥基础设施（Public Key Infrastructure) 包括PKI策略、软硬件系统、证书机构CA、注册机构RA、证书发布系统和PKI应用等。

        我们关注就俩东西： PKCS 证书机构CA 。前者是定义加密算法，签名，证书相关的各种事情采用的协议。后者可以为我们颁发权威的证书。

        PKCS ：

        PKCS（The Public-Key Cryptography Standards ）是由美国RSA数据安全公司及其合作伙伴制定的一组公钥密码学标准，其中包括证书申请、证书更新、证书作废表发布、扩展证书内容以及数字签名、数字信封的格式等方面的一系列相关协议。RSA算法可以做加密、解密、签名、验证，还有RSA的密钥对存储。这些都需要标准来规范，如何输入，如何输出，如何存储等。

        PKCS。全称是公钥密码学标准， 目前共发布过 15 个标准，这些标准都是协议。总结一下 就是对加密算法，签名，证书协议的描述。下面列举一些常用的协议，这些协议在本文都会对应上。

        这些协议具体的实现就体现在openssl等工具中， 以及jdk工具keytool jdk java第三方库bouncycastle。

        比如用openssl 如何生成公/私钥(PKCS#1)、签名(PKCS#1 )、签名请求文件（KCS#10）、 带口令的私钥（PKCS#8）。 含私钥的证书（PKCS#12）、证书库（PKCS#12）

        其中涉及到算法的基础协议PKCS#1等，由于涉及到密码学原理所以我们并不需要深究它，只要知道怎么做就可以了。

        现实中我们要解决这样一种情况:

        客户端和服务器之间的数据要进行加密。需要两个达成同一个对称秘钥加密才行，那么这个秘钥如何生成，并在两边都能拿到，并保证传输过程中不被泄露。 这就用到非对称加密了。 后续的传输，就能用这个 对称秘钥来加密和解密了。

        还有这样一个问题：

        就是客户端如何判断服务端是否是合法的服务端。这就需要服务端有个id来证明它，而这个id 就是证书，而且必须是权威机构颁发的才能算是合法的。

        因为客户端即浏览器，认定证书合法的规则必须通过第三方来确认 即ca颁发的证书。否则就我可能进了一个假网站。

        而这两个问题 都是ssl协议要解决的内容。

        所以ssl协议做了两件事情，一是验证身份，二是协商对称秘钥，并安全的传输。 而实现这个过程的关键数据模型就是证书， 通过证书中的ca对证书的签名，实现了身份验证，通过证书中的公钥，实现对对称秘钥加密，从而实现数据保密。 其实还顺手做了一件事情就是通过解密签名比对hash，保证了数据完整性。

        明白ssl协议 首先明白几个重要的概念：

        证书： 顾名思义就是提供了一种在Internet上验证通信实体身份的方式，数字证书不是数字身份证，由权威公正的第三方机构，即CA（例如中国各地方的CA公司）中心签发的证书， 就是可以认定是合法身份的。客户端不需要证书。 证书是用来验证服务端的。

        一般的证书都是x509格式证书，这是一种标准的证书，可以和其他证书类型互相转换。完整来说证书包含，证书的内容，包括 版本号， 证书序列号， hash算法， 发行者名称，有效期， 公钥算法，公钥，签名（证书原文以及原文hash一起签名）而这个内容以及格式 都是标准化的，即x509格式 是一种标准的格式。

        签名: 就用私钥对一段数据进行加密，得到的密文。 这一段数据在证书的应用上就是 对证书原文+原文hash进行签名。

        谁签的名，就是用谁的私钥进行加密。就像身份证一样， 合法的身份证我们都依据是政府签的，才不是假证， 那就是浏览器会有政府的公钥，通过校验（解密）签名，如果能够解密，就可以确定这个就是政府的签名。就对了。

        hash算法 ：对原始数据进行某种形式的信息提取，被提取出的信息就被称作原始数据的消息摘要。比如，MD5和SHA-1及其大量的变体。 hash算法具有不可逆性，无法从摘要中恢复出任何的原始消息。长度总是固定的。MD5算法摘要的消息有128个比特位，SHA-1算法摘要的消息最终有160比特位的输出。

        ca机构： 权威证书颁发机构，浏览器存有ca的公钥，浏览器以此公钥来验证服务端证书的合法性。

        证书的获取： 生成证书申请文件.csr（涉及到PKCS#10定义的规范）后向ca机构申请。 或者自己直接通过生成私钥就可以一步到位生成自签名证书。 自签名证书就是用自己的私钥来签名证书。

        那么为了体现到证书身份认证、数据完整、保密性三大特性 ，证书的简化模型可以认为包含以下两个要素：服务器公钥，ca的签名（被ca私钥加密过的证书原文+原文hash），

        身份认证：

        浏览器存有ca公钥，用ca公钥解密网站发给你的证书中的签名。如果能解密，说明该证书由ca颁发，证书合法。 否则浏览器就会报警告，问你是否信任这个证书，也就是这个网站。这时候的证书可以是任何人签发的，可以自己签发的。 但是中间人攻击。 完全伪造新的证书， 这就没有办法了。 所以还是信任证书的时候要谨慎。

        数据完整：

        如果你信任该证书的话，这时候就会用证书中的公钥去解密签名，如果是ca签发的证书，那么之前就已经通过ca的公钥去解密签名了。 然后得到证书hash，然后在浏览器重新对证书做hash，两者比对一致的话，说明证书数据没有被篡改。

        保密性：

        使用证书的公钥对对称秘钥加密保证传输安全，对称秘钥生成后，后续的传输会通过对称秘钥来在服务端和客户端的加解密。

        那么ssl协议的具体过程就是：

        4.网站接收浏览器发来的数据之后 使用自己的私钥校验签名，并对原文进行hash 与解密出的hash 做比对检查完整性。然后发送编码改变通知，服务器握手结束通知（所有内容做hash ）。 发送给客户端校验。

        5 客户端校验，校验成功后，之后就用 对称秘钥进行通信了。

        总共的过程是 c-s-c- s-c 四次握手。

        四次握手简单来说分别是：

        1.请求获取证书

        2.服务端返回证书，客户端验证了证书的合法性和完整性，同时生成了对称秘钥。

        3.客户端把加密的 对称秘钥发给服务器。服务器检查真实性和完整性。

        4.服务端返回握手结束通知，客户端再检查一次真实性和完整性。

        前两次握手是明文， 后两次握手是密文。 所以都要检查身份真实性和数据完整性。

        ca的作用：

        ca起到一个权威中间人的角色，如果脱离了ca， 那么证书还是证书，还能加密，保证数据完整性。 但是无法应用在客户端去认定服务器身份合法这个场景下。

        ?

        下面就详细说下 脱离了ca签发的证书的应用：

        ?

        自签名证书：

        证书如果没有权威机构的签名，就是没有权威机构给你签发身份证。 那么这时候身份认证的场景变了。

        这时候的认证场景就变成了，不再是某个官方权威说了算，而是假设第一次碰到这个证书，会认为，这个证书与之捆绑的实体之间是合法的并做记录。如果当这个实体下次捆绑了另一个证书，那么就是非法的。

        这种情况常用于android中安装和校验app的时候，会先假设第一次安装的是合法的应用，认定这个app证书中的公钥是合法的公钥。然后通过自签名的证书，校验签名，就能实现后续安装是否合法以及完整性。

        android中的如何对app进行身份认定和不被篡改：

        android系统在安装app时候会进行校验applicationId，applicationId 不同会认定为不同应用。相同应用，第二次安装会校验证书是否和之前app的证书相同，如果相同则两个包很可能来自同一个身份。 如果证书不同，也就是该包被另一个身份用自己的私钥重新签名过，就会拒绝安装。 然后通过公钥来解密签名，如果能解密，说明身份是ok的。否则拒绝安装。比对解密签名后的hash 与apk包内的cert.sf文件(该文件是apk内所有文件生成的hash文件)是否一致，如果相同则认定为没有被篡改。

        android在提交应用商店的问题：

        应用商店也会校验 后续的上传和第一次上传时的证书，以及类似上述的后续的一系列校验。防止合法的开发者平台被盗后，上传非法应用。

        android在接入第三方sdk的问题：

        接入第三方sdk 会提交applicationId 和 sha1 值。 这个sha1值就是对 证书原文的签名后的sha1，也就是证书指纹。这个证书是证书库里最初的那个证书（x509格式），而不是对apk签名后生成的证书(PKCS#7)。一般的证书签名的主体是证书原文本身，而对apk签名还额外会对apk所有文件生成的hash值文件（cert.sf）进行一次签名。

        第三方平台会记录 applicationId 与sha1 的对应关系。 当有假冒app试图接入时候，由于会对app内的PKCS#7证书转换为原始的x509格式证书，重新生成sha1值，与用户提交sha1 比对， 如果相同则说明证书很可能是ok的。 因为sha1就是证书的指纹。 之后就会通过证书中的公钥来校验签名，从而最终确认身份合法性以及信息完整性。

        第三方平台之所以需要用户去提交证书指纹sha1值，多了这一步，就意味着你的证书是可以更换的，一旦更换了证书，就必须提交新的指纹给我，然后我来做匹配。而应用商店没有这个功能， 一旦你的证书的私钥丢了， 那就必须重新建一个新的app。

        总结来看证书的身份认定机制：

        在ssl协议下，这种场景是 浏览器用于认定合法的服务器身份。 在自签名证书下，需要用户选择是否信任该证书。

        在android app采用自签名证书的场景下， 证书起到了 假设第一次的证书合法，公钥合法，后续如果证书不一致或不能够完成签名校验，就是非法。

        证书库：

        证书库应该满足PKCS#12协议。 但是jdk提供了制作证书的工具keytool 可以生成keystore类型的证书库，后缀为jks。 keystore pk12可以通过keytool命令互相转换。

        证书库是个证书的容器， 可以用来创建数字证书。 在keystore证书库中，所有的数字证书是以一条一条(采用别名alias区别)的形式存入证书库的。证书库中的证书格式为pk12，即包含私钥。 如果导出证书的话， 可以导出为x509不包含私钥的格式 或者pk12包含私钥的证书。 也可以也可以用-import参数加一个证书或证书链到信任证书。

        android中一般都采用读取证书库的方式，通过证书库来创建一个证书，通过alias来区分。 所以在签名的时候，一个alias是一个证书，不同的alias是不同的证书，不要搞错了。

        几个关系：

        证书和非对称加密算法的关系：

        证书代表一个身份的主体，包含了非对称秘钥体系中的公钥，以及用私钥对证书签名。这种组织结构，把非对称加密算法从加密的功能，拓宽到了用于身份认证，信息完整性上。这体现在了证书的作用。 本质还是利用了非对称加密算法的特性。

        ssl协议和证书的关系。

        因为证书解决了客户端对服务器的身份认证（自签名证书除外），同时也解决了加密，和信息完整性，所以ssl协议基于证书来实现。

什么是签名，为什么要给应用程序签名，如何

        通过前一篇 Apk签名机制之——JAR签名机制详解 的分析我们知道，JAR签名需要对apk内所有文件进行hash校验，当资源较多时签名验证速度较慢。为了加快验证速度并加强完整性保证，Andorid在7.0引入一种全文件签名方案V2。下面来看V2方案的具体设计原理。

        在了解V2签名结构前，先来了解下 zip（apk）文件的结构 。

        zip文件分为3部分：

        通过中央目录起始偏移量和size即可定位到中央目录，再遍历中央目录条目，根据本地文件头的起始偏移量即可在数据区中找到相应的压缩数据。

        在 Apk签名机制之——JAR签名机制详解 中我们已经知道，JAR签名是在apk文件中添加META-INF目录，即需要修改 数据区 、 中央目录 ，因为添加文件后会导致中央目录大小和偏移量发生变化，还需要修改 中央目录结尾记录 。V2方案为加强数据完整性保证，不在 数据区 和 中央目录 中插入数据，选择在 数据区 和 中央目录 之间 插入一个 APK签名分块 ，从而保证了原始zip（apk）数据的完整性。具体如下所示：

        v2 签名块负责保护第 1、3、4 部分的完整性，以及第 2 部分包含的 APK 签名方案 v2分块 中的 signed data 分块的完整性。

        APK签名分块包含了4部分：分块长度、ID-VALUE序列、分块长度、固定magic值。其中 APK 签名方案 v2分块 存放在ID为0x7109871a的键值对中。在进行签名校验时，先找到zip 中央目录结尾记录 ，从该记录中找到 中央目录起始偏移量 ，再通过magic值即可确定前方可能是 APK签名分块 ，再通过前后两个分块长度字段，即可确定 APK签名分块 的位置，最后通过ID（0x7109871a）定位 APK 签名方案 v2分块 位置。

        APK 签名方案 v2分块 是一个签名序列，说明可以使用多个签名者对同一个APK进行签名。每个签名信息中均包含了三个部分的内容：

        前面说了v2 签名块负责保护第 1、3、4 部分的完整性，以及第 2 部分包含的 APK 签名方案 v2分块 中的 signed data 分块的完整性。第1、3、4部分的完整性是通过内容摘要来保护的，这些摘要保存在 signed data 分块中，而 signed data 分块的完整性是通过签名来保证的。下面来看摘要的计算过程：

        第 1、3 和 4 部分的摘要采用以下计算方式，类似于两级 Merkle 树 。

        因为V2签名机制是在Android 7.0中引入的，为了使APK可在Android 7.0以下版本中安装，应先用JAR签名对APK进行签名，再用V2方案进行签名。要注意顺序一定是先JAR签名再V2签名，因为JAR签名需要修改zip 数据区 和 中央目录 的内容，先使用V2签名再JAR签名会破坏V2签名的完整性。

        实际上我们在编译APK时并不需要关心这个过程，在Android Plugin for Gradle 2.2中，gradle默认会同时使用JAR签名和V2方案对APK进行签名，如果想要关闭JAR签名或V2签名，可以在build.gradle中进行配置：

        在 Android 7.0 中，会优先以 v2方案验证 APK，在Android 7.0以下版本中，系统会忽略 v2 签名，仅验证 v1 签名。Android 7.0+的校验过程如下：

        因为在经过V2签名的APK中同时带有JAR签名，攻击者可能将APK的V2签名删除，使得Android系统只校验JAR签名。为防范此类攻击，V2方案规定：

        攻击者还可能试图删除 APK 签名方案 v2 分块 中安全系数较高的签名，从而使系统验证安全系数较低的签名。为防范此类攻击：

        通过 Apk签名机制之——JAR签名机制详解 和本篇文章的分析，我们知道了：

        JAR签名的劣势

        V2签名的优势

        现在我们可以解答 Apk签名的基本概念和用法 前言中提出的问题了：

        APK签名是为了保证APK的完整性和来源的真实性，分为JAR签名和V2签名两种方案。核心思想均是计算APK内容的hash，再使用签名算法对hash进行签名。校验时通过签名者公钥解密签名，再与校验者计算的APK内容hash进行比对，一致则校验通过。

        签名证书的指纹，在申请第三方SDK时，需填入APK包名和证书指纹，SDK开发者后台会根据这两个值生成一个key。第三方SDK在初始化时，会从系统中获取当前APK的包名、签名证书指纹以及key，然后将此指纹上传到其服务器，然后校验包名、签名证书指纹是否与此key绑定，校验通过后才进行授权。

        在V2方案出现之前，快速批量打包方案有3类：

        在V2方案出现之后，因同时保证了 数据区 、 中央目录 和 中央目录结尾记录 的完整性，故方案2、3均不适用了。那是不是就没有快速批量打包的可能了呢？当然不是，可以从 APK签名分块 中着手。再回过头来看一下 APK签名分块 的结构：

        APK签名分块 中有一个ID-VALUE序列， 签名信息（ APK 签名方案 v2 分块 ）只存储在ID 为 0x7109871a的ID-VALUE中，通过分析签名校验源码可以发现，其它ID-VALUE数据是未被解析的，也就是说除 APK 签名方案 v2 分块 外，其余ID-VALUE是不影响签名校验的。故可以定义一个新的ID-VALUE，将渠道信息写入 APK签名分块 中。因为V2方案只保证了第1、3、4部分和第 2 部分（ APK签名分块 ）包含的 APK 签名方案 v2分块 中的 signed data 分块的完整性。新写入的ID-VALUE不受保护，所以此方案可行。实际上美团新一代渠道包生成工具 Walle 就是以这个方案实现的。

        好了，到这里APK签名机制的全部内部就分析完了，相信大家看完这三篇文章之后，对JAR签名和V2签名机制都有了大致的了解，有兴趣的同学可以阅读签名和校验的源码进一步分析。

运行android程序会默认生成签名吗

       为什么要签名

       ①应用程序升级：如果你希望用户无缝升级到新的版本，那么你必须用同一个证书进行签名。这是由于只有以同一个证书签名，系统才会允许安装升级的应用程序。如果你采用了不同的证书，那么系统会要求你的应用程序采用不同的包名称，在这种情况下相当于安装了一个全新的应用程序。如果想升级应用程序，签名证书要相同，包名称要相同！

       ②应用程序模块化：Android系统可以允许同一个证书签名的多个应用程序在一个进程里运行，系统实际把他们作为一个单个的应用程序，此时就可以把我们的应用程序以模块的方式进行部署，而用户可以独立的升级其中的一个模块

       ③代码或者数据共享：Android提供了基于签名的权限机制，那么一个应用程序就可以为另一个以相同证书签名的应用程序公开自己的功能。以同一个证书对多个应用程序进行签名，利用基于签名的权限检查，你就可以在应用程序间以安全的方式共享代码和数据了。

       如何使用Android Studio 进行签名

       Build → Generate Signed APK→Greate new...

       Key store path:秘钥仓库的路径，比如C:\AndroidSDK20160322\sdk\key.jks试试，红色的部分名字可以自己起，但后缀必须是 .jks ，

       Password: 输入秘钥仓库的密码，比如: lait.....

       Confirm: 确认秘钥仓库的密码，比如: lait......

       key-------------------------------------------------------

       Alias：秘钥别名 比如 lai

       Password: 输入秘钥的密码，比如: 123456

       Confirm: 确认秘钥的密码，比如:123456

       Validity(years): 有效期

       Certificate:证书，需要的填写如下

       First and Last Name：姓名 比如：LaiTianLiang

       Organization Unit：组织单位比如：nothing

       Organization：组织 比如：nothing

       City or Locality：城市或地区 比如：ShenYang

       State or Province：州或省 比如：LiaoNing

       Country Code(XX)：国家代码(XX) 比如：86

       填写好后点击OK

       点击Next

       Enter Master Password 活动窗口中的英文

       简单翻译就是：主密码是解锁密码数据库时需要，密码数据库将在这个会话期间为所有子系统解锁

       在这里应该是设置主密码，我也忘记什么时候设的了，但是试了一下我的常用密码 Lt…… 结果好使了

       如果忘记了可以在File->Settings->Appearance&Behavior ->SystemSetting->Passwords中修改

       最后单击Finish完成

       开发Android的人这么多，完全有可能大家都把类名，包名起成了一个同样的名字，这时候如何区分？签名这时候就是起区分作用的。

        由于开发商可能通过使用相同的Package Name来混淆替换已经安装的程序，签名可以保证相当名字，但是签名不同的包不被替换。

        APK如果使用一个key签名，发布时另一个key签名的文件将无法安装或覆盖老的版本，这样可以防止你已安装的应用被恶意的第三方覆盖或替换掉。

        这样签名其实也是开发者的身份标识。交易中抵赖等事情发生时，签名可以防止抵赖的发生。

       二、签名的注意事项

        Android系统要求所有的程序经过数字签名才能安装，如果没有可用的数字签名，系统将不许安装运行此程序。不管是模拟器还是真实手机。因此，在设备或者是模拟器上运行调试程序之前，必须为应用程序设置数字签名。

        Android签名的数字证书不需要权威机构来认证，是开发者自己产生的数字证书，即所谓的自签名。数字证书用来标识应用程序的作者和在应用程序之间建立信任关系，而不是用来决定最终用户可以安装哪些应用程序。

        系统仅仅会在安装的时候测试签名证书的有效期，如果应用程序的签名是在安装之后才到期，那么应用程序仍然可以正常启用。

        可以使用标准工具-Keytool and Jarsigner-生成密钥，来签名应用程序的.apk文件。

        签名后需使用zipalign优化程序。

        模拟器开发环境，开发时通过ADB接口上传的程序会先自动被签有Debug权限，然后才传递到模拟器。Eclipse菜单的Window -> Preferences -> Android –> Build 下显示的是我们默认的调试用的签名数字证书。

        正式发布一个Android应用时，必须使用一个合适的私钥生成的数字证书来给程序签名，不能使用ADT插件或者ANT工具生成的调试证书来发布。

       三、签名方法：

       1.使用Keytool 和jarsigner工具签名（在jdk/bin目录下）

       1.生成签名keystore：

       确保电脑上安装了JDK，因为我们将使用JDK自带的创建和管理数字证书的工具Keytool。在命令行下输入如下命令：

       keytool -genkey -v -keystore app.keystore -alias alias_name -keyalg RSA -validity 20000

       -alias 后面跟的是别名这里是alias_name

       -keyalg 是加密方式这里是RSA

       -validity 是有效期这里是20000

       -keystore 就是要生成的keystore的名称这里是app.keystore

       然后按回车键

       按回车后首先会提示你输入的密码：这个在签名时要用的，要记住

       然后会再确认你的密码。

       之后会依次叫你输入姓名、组织单位、组织名称、城市区域、省份名称、国家代码（CN）等。

       2.签名：

       jarsigner -verbose -keystore app.keystore -signedjar app_signed.apk app.apk alias_name

       -keystore: keystore的名称

       -signedjar app_signed.apk: 指定签名后生成的APK名称

       app.apk: 目标APK

       然后按回车：会要求输入刚才设置的密码，输入后按回车就开始签名了。

       3.查看签名：

       jarsigner -verify app_signed.apk

       查看是否签名，如果已经签名会打印 "jar verified".

       jarsigner -verify -verbose -certs app_signed.apk

       查看签名详细信息。

       4.通过zipalign工具进行优化apk(android自带的工具，./build/tools/zipalign)

       zipalign -v 4 app_signed.apk androidres.apk 对apk优化

       zipalign -c -v 4 androidres.apk 查看apk是否经过优化

       2.使用eclipse ADT工具签名

       在Package Explorer 窗口，右键，选择Android Tools--->Export Signed Application Package 然后按照提示一步一步，生成已签名的apk。通过eclipse也可以导出未签名的APK文件。

       注：需要输入两次密码，第一次是私钥密码，第二次时私钥别名的密码。

       3.eclipse在debug模式下自动签名（无须手动配置）：

        在debug模式下用eclipse 的ADT为android签名，只要应用程序在eclipse下开发，系统就会自动给apk签名和优化。

        在Eclipse中Windows > Preferences > Android > Build可以看到你keysotre的位置；

       四、生成Android系统签名

        上面讲的Android数字签名大多是与Android APK相关，做CTS 认证时，需要用到Android系统签名。为什么需要给Android系统签个名才能进行CTS认证呢？原来我们通过make -j4编译出来的system.img使用的是test key,这种类型的key只适用于开发阶段，而且这种秘钥是公开的，谁都可以使用。当发布一款android产品，就需要另外给整个系统签个名，防止被别人盗用。这种系统就是release版本的Android系统。

       1、生成加密key文件

       要对Android系统进行签名，需要生成四种类型的key文件。

       a)releasekey （testkey）

       b)media

       c)shared

       d)platform

       1）进入/android_src/development/tools目录。

       2）使用make_key工具生成签名文件。需要分别生成 releasekey，media，shared，platform。

       ./make_key releasekey '/C=CN/ST=JiangSu/L=NanJing/O=Company/OU=Department/CN=Your Name/emailAddress=YourE-mailAddress' （系统将会提示输入针对各种key的密码，按照提示输入即可）

       将会生成 releasekey.pk8 和 releasekey.x509.pem文件，其中 *.pk8是生成的私钥，而*.x509.pem是公钥，生成时两者是成对出现的.

       注：如果出现 openssl : relocation error :openssl : symbol ...尝试用 sudo 执行命令，问题解决了！

       2.回到根目录android_src。

       命令执行的时候都最好在工程的根目录下执行，要不然脚本用到的某些文件找不到的。

       3.编译系统

        make -j4 PRODUCT-generic-user dist

       其中generic 表示生成的TARGET_PRODUCT类型为generic，

        user代表TARGET_BUILD_VARIANT为user版本。

       编译完成之后回在android_src/dist/目录内生成个product_generic-user_files开头的zip文件.这就是我们需要进行签名的文件系统.

       4.开始签名

       ./build/tools/releasetools/sign_target_files_apks -d key_directory/ out/dist/product_modul-target_files.zip out/dist/signed_target_files.zip

       通过sign_target_files_apks 脚本，完成android系统的签名工作.

       key_directory/ 表示key所在的目录。

       out/dist/product_modul-target_files.zip 源文件。

       out/dist/signed_target_files.zip 生成签名的目标文件。

       可能会出现：

       ERROR: no key specified for:

        CalendarWidget.apk

        Contacts_yellowpage.apk

        SnsAppMain.apk

       这表示，签名并没有成功,原因是由于有些apk程序已经签过名了或者找不到对应的key. 这需要我们对apk设置过滤,不对上面的应用进行签名.方法如下:

       通过参数"-e <apkname>=" 来过滤这些应用.

       ./build/tools/releasetools/sign_target_files_apks -d key_directory/ -e CalendarWidget.apk= -e Contacts_yellowpage.apk= -e SnsAppMain.apk= -e out/dist/product_modul-target_files.zip out/dist/signed_target_files.zip

       输入该命令时会提示输入key的密码，会出现四次密码输入提示。分别为四种类型的key的密码。

       5.生成image文件

       ./build/tools/releasetools/img_from_target_files out/dist/signed-target-files.zip signed-img.zip

       用img_from_target_files 命令对生成的igned-target-files.zip文件进行打包，signed-img.zip包含了boot.img,userdate.img,system.img文件等.

       6.通过fastboot下载signed-img.zip文件

       fastboot update signed-img.zip

       通过fastboot就可以把签了名的系统文件烧到手机上了。

       好了，今天关于“apk签名有什么用”的话题就到这里了。希望大家能够通过我的讲解对“apk签名有什么用”有更全面、深入的了解，并且能够在今后的生活中更好地运用所学知识。