android签名机制,Android签名有什么作用

android签名机制,Android签名有什么作用详细介绍

本文目录一览： apk签名是什么意思？

apk是安卓应用软件包，apk签名是软件包在安装的时候进行的安全性验证机制。
这种签名机制目的是为了确保Apk来源的真实性，以及Apk没有被第三方篡改。开发者通过对Apk进行签名：在Apk中写入一个“指纹”。指纹写入以后，Apk中有任何修改，都会导致这个指纹无效，Android系统在安装Apk进行签名校验时就会不通过，从而保证了安全性。
扩展资料：
1、APK的格式定义
在Android平台中，dalvikvm的执行文件被打包为apk格式，最终运行时加载器会解压，然后获取编译后的androidmanifest.xml文件中的permission分支相关的安全访问，但仍然存在很多安全限制，如果你将apk文件传到/system/app文件夹下，会发现执行是不受限制的。安装的文件可能不是这个文件夹，而在androidrom中，系统的apk文件默认会放入这个文件夹，它们拥有着root权限。
2、APK的开发环境
Android是一个基于Java的开发环境，Google也在API文档的书写和样例的提供上做了很出色的工作。
3、获取SDK
下载并安装android的SDK[软件开发套件]，这套SDK主要包括有核心库文件，一个模拟器，开发工具和一些示范的样例文件。推荐使用Eclipse 和androideclipse 扩展。如果只是使用android，Eclipse IDE就已经足够了，但如果是第一次开发Java应用，建议下载完整的Java SE 开发工具 (JDK) 因为它包括签发应用程序所需要的工具。
4、APK应用架构
android应用架构很关键，如果不学习它，设计出来的游戏将是一种很难修复bug的产品。 需要了解应用程序、活动、Intents以及它们是如何互相联系交互的，Google在这儿提供了良好的信息架构。真正重要的是，要理解为什么在设计的游戏中，需要不止一个的活动进程，以及如何设计一个用户体验良好的游戏。这些都应当配合到应用的生命周期中。
5、APK应用的生命周期
应用的生命周期是由Android OS操作系统进行管理的，活动进程都将作为系统命令进行创建，正确处理这些事件对一个应用程序来说是极为重要的，因为终端用户不会知道什么是正确的。最好在开始设计游戏之前搞明白这些，因为这有助于节省调试时间以及避免代价高昂的重新设计。
对大多数应用而言，默认设置即可开始工作，但对游戏而言，可能需要调整单态实例的信号为打开。在默认情况下，Android会新建一个活动实例进程，因为它认为这是比较合适的，而游戏，可能只希望有一个活动的实例进程，这有一点儿影响，它需要了解一些系统状态的管理。
参考资料来源：百度百科-apk
参考资料来源：百度百科-android软件开发

如何将Android的app签名加入APP文件中(Android应用签名)

所有的Android应用程序都要求开发人员用一个证书进行数字签名，anroid系统不会安装没有进行签名的由于程序。
平时我们的程序可以在模拟器上安装并运行，是因为在应用程序开发期间，由于是以Debug面试进行编译的，因此ADT根据会自动用默认的密钥和证书来进行签名，而在以发布模式编译时，apk文件就不会得到自动签名，这样就需要进行手工签名。
给apk签名可以带来以下好处：
1.应用程序升级：如果你希望用户无缝升级到新的版本，那么你必须用同一个证书进行签名。这是由于只有以同一个证书签名，系统才会允许安装升级的应用程序。如果你采用了不同的证书，那么系统会要求你的应用程序采用不同的包名称，在这种情况下相当于安装了一个全新的应用程序。如果想升级应用程序，签名证书要相同，包名称要相同！
2.应用程序模块化：Android系统可以允许同一个证书签名的多个应用程序在一个进程里运行，系统实际把他们作为一个单个的应用程序，此时就可以把我们的应用程序以模块的方式进行部署，而用户可以独立的升级其中的一个模块
3.代码或者数据共享：Android提供了基于签名的权限机制，那么一个应用程序就可以为另一个以相同证书签名的应用程序公开自己的功能。以同一个证书对多个应用程序进行签名，利用基于签名的权限检查，你就可以在应用程序间以安全的方式共享代码和数据了。
不同的应用程序之间，想共享数据，或者共享代码，那么要让他们运行在同一个进程中，而且要让他们用相同的证书签名。

Adroid 签名机制V1,V2,V3

apk解压后META-INF 文件夹下有三个文件：MANIFEST.MF、CERT.SF、CERT.RSA。
该文件中保存的内容其实就是逐一遍历 APK 中的所有条目
这里会把之前生成的 CERT.SF 文件，用私钥计算出签名, 然后将签名以及包含公钥信息的数字证书一同写入 CERT.RSA 中保存。这里要注意的是，Android APK 中的 CERT.RSA 证书是自签名的，并不需要这个证书是第三方权威机构发布或者认证的，用户可以在本地机器自行生成这个自签名证书。Android 目前不对应用证书进行 CA 认证。
RSA 文件加密了，所以我们需要用 openssl 命令才能查看其内容
签名验证是发生在 APK 的安装过程中，一共分为三步：
为了解决V1的缺点，在 Android 7.0 Nougat 中引入了全新的 APK Signature Scheme v2。
APK 签名方案 v2 是一种全文件签名方案，该方案能够发现对 APK 的受保护部分进行的所有更改，从而有助于加快验证速度并增强完整性保证。
由于在 v1 仅针对单个 ZIP 条目进行验证，因此，在 APK 签署后可进行许多修改 — 可以移动甚至重新压缩文件。事实上，编译过程中要用到的 ZIPalign 工具就是这么做的，它用于根据正确的字节限制调整 ZIP 条目，以改进运行时性能。而且我们也可以利用这个东西，在打包之后修改 META-INF 目录下面的内容，或者修改 ZIP 的注释来实现多渠道的打包，在 v1 签名中都可以校验通过。
v2 签名将验证归档中的所有字节，而不是单个 ZIP 条目，因此，在签署后无法再运行 ZIPalign（必须在签名之前执行）。正因如此，现在，在编译过程中，Google 将压缩、调整和签署合并成一步完成。
简单来说，v2 签名模式在原先 APK 块中增加了一个新的块（签名块），新的块存储了签名，摘要，签名算法，证书链，额外属性等信息，这个块有特定的格式，具体格式分析见后文，先看下现在 APK 成什么样子了。
为了保护 APK 内容，整个 APK（ZIP 文件格式）被分为以下 4 个区块：
其中，应用签名方案的签名信息会被保存在 区块 2（APK Signing Block）中，而区块 1（Contents of ZIP entries）、区块 3（ZIP Central Directory）、区块 4（ZIP End of Central Directory）是受保护的，在签名后任何对区块 1、3、4 的修改都逃不过新的应用签名方案的检查。
其中 v2 签名机制是在 Android 7.0 以及以上版本才支持。因此对于 Android 7.0 以及以上版本，在安装过程中，如果发现有 v2 签名块，则必须走 v2 签名机制，不能绕过。否则降级走 v1 签名机制。 v1 和 v2 签名机制是可以同时存在的，其中对于 v1 和 v2 版本同时存在的时候，v1 版本的 META_INF 的 .SF 文件属性当中有一个 X-Android-APK-Signed 属性，因此如果想绕过 v2 走 v1 校验是不行的。
之前的渠道包生成方案是通过在 META-INF 目录下添加空文件，用空文件的名称来作为渠道的唯一标识。但在新的应用签名方案下 META-INF 已经被列入了保护区了，向 META-INF 添加空文件的方案会对区块 1、3、4 都会有影响。
可以参考： 美团解决方案 。
Android 9.0 中引入了新的签名方式，它的格式大体和 v2 类似，在 v2 插入的签名块（Apk Signature Block v2）中，又添加了一个新快（Attr块）。
在这个新块中，会记录我们之前的签名信息以及新的签名信息，以密钥转轮的方案，来做签名的替换和升级。这意味着，只要旧签名证书在手，我们就可以通过它在新的 APK 文件中，更改签名。
v3 签名新增的新块（attr）存储了所有的签名信息，由更小的 Level 块，以链表的形式存储。
其中每个节点都包含用于为之前版本的应用签名的签名证书，最旧的签名证书对应根节点，系统会让每个节点中的证书为列表中下一个证书签名，从而为每个新密钥提供证据来证明它应该像旧密钥一样可信。
这个过程有点类似 CA 证书的证明过程，已安装的 App 的旧签名，确保覆盖安装的 APK 的新签名正确，将信任传递下去。
需要注意的是，对于覆盖安装的情况，签名校验只支持升级，而不支持降级。也就是说设备上安装了一个使用 v1 签名的 APK，可以使用 v2 签名的 APK 进行覆盖安装，反之则不允许。

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签名签名原理简析
仅供参考，欢迎指正

Android 他山之石，可以攻玉！一篇文章看懂 v1v2v3 签名机制

这篇文章的内容会涉及以下前置 / 相关知识，贴心的我都帮你准备好了，请享用~
数字签名（Digital Signature）也叫作数字指纹（Digital Fingerprint），它是消息摘要算法和非对称加密算法的结合体，能够验证数据的完整性，并且认证数据的来源 。
数据签名算法的模型分为两个主要阶段：
需要注意的是，Android 目前不对应用证书进行 CA 认证，应用可以由第三方（OEM、运营商、其他应用市场）签名，也可以自行签名。
应用 APK 其实是一种特殊的 Zip 压缩包，无法避免恶意破解者解压 / 反编译修改内容，针对这个问题有何解决方案呢？他山之石，可以攻玉 ——数字签名算法。应用签名正是数字签名算法的应用场景之一，与其他应用场景类似，目的无非是：
Android 平台上运行的每个应用都必须有开发者的签名。在安装应用时，软件包管理器会验证 APK 是否已经过适当签名，安装程序会拒绝没有获得签名就尝试安装的应用。
软件包管理器在安装应用前会验证应用摘要，如果破解者修改了 apk 里的内容，那么摘要就不再匹配，验证失败（验证流程见下文方案）。
截止至 Android 11，Android 支持以下三种应用签名方案：
为了提高兼容性，必须按照 v1、v2、v3 的先后顺序采用签名方案，低版本平台会忽略高版本的签名方案在 APK 中添加的额外数据。
v1 签名方案是基于 Jar 的签名。
首先，我们先来分析其签名产物。 v1 签名后会增加 META-INF 文件夹 ，其中会有如下三个文件。考虑到使用不同的证书和签名方式，得到的文件名可能不同，因此你只要留意文件的后缀即可：
v1 签名流程如下：
MANIFEST.MF（Message Digest File，摘要文件）
\*.SF（Signature File，签名文件）
验证流程可以分为验证签名和验证完整性两个步骤：
验证签名步骤：
如果上述签名验证结果正确，才会验证完整性：
以上任何步骤验证失败，则整个 APK 验证失败。
为了解决这些问题，Android 7.0 中引入了 APK 签名方案 v2。
v2 签名方案是一种 全文件签名方案 ，该方案能够发现对 APK 的受保护部分进行的所有更改，相对于 v1 签名方案验证速度更快，完整性覆盖范围更广。
在分析 v2 签名方案之前，我们先简单了解一下 Zip 文件格式：
首先，我们先来分析其签名产物。v2 签名后会在 「条目内容区」和「中央目录区」之间插入「APK 签名分块（APK Signing Block）」 。
从左到右边，我们定义为区块 1~4。
相对与 v1 签名方案，v2 签名方案不再以文件为单位计算摘要了，而是以 1 MB 为单位将文件拆分为多个连续的块（chunk），每个分区的最后一个块可能会小于 1 MB。
v2 签名流程如下：
验证流程可以分为验证签名和验证完整性两个步骤：
签名方案 v3 支持密钥轮换，应用能够在 APK 更新过程中更改其签名密钥。
【累了，后面先不写了...】
这一节，我们介绍基于 Android 应用签名机制的衍生应用场景。
在 v1 方案中， MANIFEST.MF 和 *.SF 这两个文件会记录大量的文件名和文件摘要。如果 apk 中文件数很多，而且文件名很长，那么这两个文件会变得很大。使用 AndResGuard 工具，可以将文件名转换为短路径文件名，从而减少这两个文件的大小。
在实际生产中，往往需要生成多个渠道的 APK 包，传统的方法是使用 APKTool 逆向工具、Flavor + BuildType 等方案，这一类多渠道打包方案的缺点是耗时严重。随着 Android 应用签名方案的演进，演变出了不同的多渠道打包方案：
在 v1 方案中，我们提到了完整性校验不覆盖到 META-INF 文件夹的问题。有些多渠道打包方案就是利用了这个问题，在 META-INF 文件夹下添加空文件， 用空文件的名称来作为渠道的唯一标识 ，就可以节省打包的时间，提高打渠道包的速度。
除了添加空文件的方法，还可以向 APK 添加 Zip Comment 来生成多渠道包（APK 本身就是特殊的 Zip 包）。
在 v2 签名方案中，几乎整个 APK 都纳入保护范围，如果向 APK 添加空文件或 Zip Comment 的话，在安装时会报以下错误：
新背景下的多渠道打包方案，则是利用了 APK 签名分块（区块 2）不受保护 & 字段可扩展的特点 ，向区块中添加多渠道信息（ID-Value），例如 美团多渠道打包方案 Walle 。

Android签名有什么作用

Android签名有什么作用 最简单直接的回答： 系统要求的。 Android系统要求每一个Android应用程式必须要经过数字签名才能够安装到系统中，也就是说如果一个Android应用程式没有经过数字签名，是没有办法安装到系统中的！ Android通过数字签名来标识应用程式的作者和在应用程式之间建立信任关系，不是用来决定终端使用者可以安装哪些应用程式。 这个数字签名由应用程式的作者完成，并不需要权威的数字证书签名机构认证，它只是用来让应用程式包自我认证的。

平时我们的程式可以在模拟器上安装并执行，是因为在应用程式开发期间，由于是以Debug面试进行编译的，因此ADT根据会自动用预设的金钥和证书来进行签名，而在以释出模式编译时，apk档案就不会得到自动签名，这样就需要进行手工签名。给apk签名可以带来以下好处：1.、应用程序升级：如果你希望使用者无缝升级到新的版本，那么你必须用同一个证书进行签名。这是由于只有以同一个证书签名，系统才会允许安装升级的应用程式。如果你采用了不同的证书，那么系统会要求你的应用程式采用不同的包名称，在这种情况下相当于安装了一个全新的应用程式。如果想升级应用程式，签名证书要相同，包名称要相同！2、应用程式模组化：Android系统可以允许同一个证书签名的多个应用程式在一个程序里执行，系统实际把他们作为一个单个的应用程式，此时就可以把我们的应用程式以模组的方式进行部署，而使用者可以独立的升级其中的一个模组3、程式码或者资料共享：Android提供了基于签名的许可权机制，那么一个应用程式就可以为另一个以相同证书签名的应用程式公开自己的功能。以同一个证书对多个应用程式进行签名，利用基于签名的许可权检查，你就可以在应用程式间以安全的方式共享程式码和资料了。不同的应用程式之间，想共享资料，或者共享程式码，那么要让他们执行在同一个程序中，而且要让他们用相同的证书签名。
word 电子签名有什么作用？ 对文件进行数字签名与签署纸质文件的原因大致相同。数字签名通过使用计算机加密来验证 （身份验证:验证人员和产品所宣告的身份是否属实的过程。例如，通过验证用于签名程式码的数字签名来确认软体发行商的程式码来源和完整性。）数字资讯，如文件、电子邮件和巨集。数字签名有助于确保： 真实性 数字签名有助于确保签署人的身份与宣告的相符。 完整性 数字签名有助于确保内容在经过数字签名之后未经更改或篡改。 不可否认 数字签名有助于向所有方证明签署内容的有效性。“否认”指签名人否认任何与签署内容有关系的行为。 为了确保以上各项，必须由内容建立者使用满足下列条件的签名对内容进行数字签名： 该数字签名有效 （有效:一种证书状态，根据证书颁发机构的资料库对证书进行检查后发现它是合法的、最新的，而且没有过期或被吊销。由有效证书签名且签名后没有更改的文件被视为有效文件。）。 与该数字签名关联的证书 （证书:一种证明身份和真实性的数字方法。证书由证书颁发机构颁发，而且和驾驶执照一样，也可能过期或被吊销。）有效（没有过期）。 作为释出者的签名人或公司可信 （信任:表示您是否信任证书颁发的受体（个人或组）。预设设定是“继承颁发者的信任关系”，也就是因为对颁发者（通常是证书颁发机构）的信任而信任证书。）。 与数字签名关联的证书由有声望的证书颁发机构 (CA) （证书颁发机构 (CA):一个商业组织，它颁发数字证书，跟踪被颁发证书的人员，对证书签名以验证其有效性，并跟踪被吊销或已过期的证书。） 颁发给签名释出者。

信用卡签名有什么作用 相当于合同 纠纷时有依据 平常是没什么拉
手机软体签名有什么作用 目前有实力的公司或确实有需要的公司会购买诺基亚的高阶权 限证书,通常是安全厂商.这类公司的软体不需要我们自签名,还有许多 软体都是一般的应用软体,和系统没什么关联,它们许可权很低,不可能存 在危险,比如网路电视软体,阅读软体,QQ,主题等都不需要签名.需要签 名的软体软体大致可分为以下几种情况:(1)随开机启动的,比如来电 通,A4自签名版;(2)不要你操作可以自动执行的,比如屏保程式;(3)进入 系统资料夹修改的,比如大部分后期汉化的软体等,再次安装汉化补丁 时就需要签名.
可靠的电子签名有什么作用？ 依据《中华人民共和国电子签名法》第十四条：“可靠的电子签名与手写签名或者盖章具有同等的法律效力。”由此可见，只有使用“可靠的电子签名”，电子合同才有可能具有与纸质合同同等的法律效力，即书证效力。
C#工程档案签名有什么作用 主要是防止篡改破解。比如你写的程式包括1个exe和若干dll，exe花费了很多工作量，而且上面有你们公司的标识。现在来了个黑客，反编译了某个dll，发现很轻易就改动了里面某个dll，比如注册码的dll，导致绕开了验证码。再来个黑客，把干好事的dll改成了删掉所有磁碟上档案的功能，导致使用者把你公司拉进黑名单。 如果签了名，就可以保证exe只能呼叫你自己写的dll，他们篡改了你的dll，exe会报错，报找不到dll。
驱动程式签名有什么作用啊？ 可以确认驱动程式与Windows 无相容性问题（不过不代表没有签名的驱动就一定不相容Windows） 新年快乐
android签名工具干什么用的 给apk签名用的。但是你要有key，或者自己用eclipse生成一个。签名有一个很重要作用就是防止程式释出后被篡改签名一般用私钥，私钥签名以后会生成harsh值序列，公钥验证的时候（手机上），会根据档案内容再生成一次harsh序列，如果和apk中的harsh序列相同，说明apk释出后没有被篡改过
禁止驱动程式强制签名有什么作用 没有坏处。 驱动程式签名又叫做驱动程式的数字签名，它是由微软的Windows硬体装置质量实验室完成的。硬体开发商将自己的硬体装置和相应的驱动程式交给该实验室，由实验室对其进行测试，测试合格后实验室将在其驱动程式中新增数字签名。由于数字签名是由微软完成的。 使用有数字签名的驱动程式将的好处： 安全保障 由于数字签名是针对整个驱动程式的所有软体进行的，所以在完成签名后再对驱动程式进行任何更改都会导致签名无效，这样就避免了在驱动程式中新增恶意程式码传播病毒等恶意程式的可能性。

APK签名机制原理详解

众所周知，Android系统在安装Apk的过程中，会对Apk进行签名校验，校验通过后才能安装成功。那你知道签名校验的机制是什么？具体校验的是什么内容吗？申请第三方SDK（如微信支付）时填入的SAH1值是什么？目前众多的快速批量打包方案又是如何绕过签名检验的？
我将通过一系列的文章来解开这些疑惑：
这篇文章先来介绍Apk签名相关的基本知识。
要知道签名是什么，先来看为什么需要签名 。大家都知道，在消息通信时，必须至少解决两个问题：一是确保消息来源的真实性，二是确保消息不会被第三方篡改。在安装Apk时，同样需要确保Apk来源的真实性，以及Apk没有被第三方篡改。如何解决这两个问题呢？方法就是开发者对Apk进行签名：在Apk中写入一个“指纹”。指纹写入以后，Apk中有任何修改，都会导致这个指纹无效，Android系统在安装Apk进行签名校验时就会不通过，从而保证了安全性。
要了解如何实现签名，需要了解两个基本概念：数字摘要和数字证书。
简单来说，就是对一个任意长度的数据，通过一个Hash算法计算后，都可以得到一个固定长度的二进制数据，这个数据就称为“摘要”。摘要具有下面的几个特征：
前面已经说到，可以通过签名来确保数据来源的可靠性和数据的不可篡改性。签名就是在摘要的基础上再进行一次加密，对摘要加密后的数据就可以当作数字签名，在安装Apk需要对签名进行验证，验证通过才能继续安装。
这里有两个过程：签名过程 和 校验过程。
先来说 签名过程：
再来看 校验过程：
这里有一个前提：接收方必须要知道发送方的公钥和所使用的算法。如果数字签名和公钥一起被篡改，接收方无法得知，还是会校验通过。如何保证公钥的可靠性呢？答案是数字证书，数字证书是身份认证机构（Certificate Authority）颁发的，包含了以下信息：
接收方收到消息后，先向CA验证证书的合法性（根据证书的签名、绑定的域名等信息。CA机构是权威的，可以保证这个过程的可靠性。）再进行签名校验。
需要注意的是，Apk的证书通常的自签名的，也就是由开发者自己制作，没有向CA机构申请。Android在安装Apk时并没有校验证书本身的合法性，只是从证书中提取公钥和加密算法，这也正是对第三方Apk重新签名后，还能够继续在没有安装这个Apk的系统中继续安装的原因。
我们在对Apk签名时并没有直接指定私钥、公钥和数字证书，而是使用keystore文件，这些信息都包含在了keystore文件中。根据编码不同，keystore文件分为很多种，Android使用的是Java标准keystore格式JKS(Java Key Storage)，所以通过Android Studio导出的keystore文件是以.jks结尾的。
keystore使用的证书标准是X.509，X.509标准也有多种编码格式，常用的有两种：pem（Privacy Enhanced Mail）和der（Distinguished Encoding Rules）。jks使用的是der格式，Android也支持直接使用pem格式的证书进行签名，我们下面会介绍。
两种证书编码格式的区别：

X.509证书格式：
Android提供了两种对Apk的签名方式，一种是基于JAR的签名方式，另一种是基于Apk的签名方式，它们的主要区别在于使用的签名文件不一样：jarsigner使用keystore文件进行签名；apksigner除了支持使用keystore文件进行签名外，还支持直接指定pem证书文件和私钥进行签名。
不知道大家有没有注意一个问题，我们通过keytool或者AS生成一个keystore的时候（ 签署您的应用 ），除了要输入keystore的密码外，还要输入一个alias和key的密码。在签名时，除了要指定keystore文件和密码外，也要指定alias和key的密码，这是为什么呢？
原因是keystore是一个密钥库，也就是说它可以存储多对密钥和证书，keystore的密码是用于保护keystore本身的，一对密钥和证书是通过alias来区分的。从这里可以看出jarsigner是支持使用多个证书对Apk进行签名的。apksigner也同样支持，关于apksigner的使用介绍可以参考官方文档 apksigner 。
ok，签名的基本概念和校验过程就介绍到这里，关于JAR签名和V2签名机制的详细介绍，参考下面两篇文章：

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

所有的概念都基于一个非常重要的基础：
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签名机制之——V2签名机制详解

通过前一篇 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签名机制都有了大致的了解，有兴趣的同学可以阅读签名和校验的源码进一步分析。