android公钥

⑴ Android密钥库系统KeyStore

利用 Android 密钥库系统，您可以在容器中存储加密密钥，从而提高从设备中提取密钥的难度。在密钥进入密钥库后，可以将它们用于加密操作，而密钥材料仍不可导出。此外，它提供了密钥使用的时间和方式限制措施，例如要求进行用户身份验证才能使用密钥，或者限制为只能在某些加密模式中使用。

密钥库系统并不是让程序直接进行存储程序的私密信息的，比如说用户账号密码，册陵桥其提供了一个密钥安全容器，保护密钥材料免遭未经授权的使用，一个应用程序可以在密钥库中存储多个密钥并且只允许应用自身访问，应用程序可以在密钥库系统中生成，存储，获取存储其中的公钥或者私钥，因此可使用密钥库系统中的密钥来进行数据的加密。

密钥库系统由 KeyChain API 以及在 Android 4.3（API 级别 18）中引入的 Android 密钥库提供程序功能使用。

安卓系统提供了下面几种KeyStore类型：

各种类型的详细说明可以参考： https://developer.android.com/openjdk-redirect.html?v=8&path=/technotes/guides/security/StandardNames.html#KeyStore

先州猛创建一个Activity，自定义布局从页面上来实现几种功能

效果图：

说明：
1.输入框输入要增加的密钥的名称，点击添加按钮进行添加一个新密钥；
2.输入框输入要删除的密钥的名称，点击删除按钮进行删除一个已存在的密钥；
3.这里指定了数据明文，点击密钥列表中的item可选中指定的密钥，用于使用密钥进行加密和解密，选中密钥后，可点击加密按钮进行加密，加密后可点击解密按钮进行解密；
4.密钥列表显示当前应用在密钥库系统中生成了的密钥，长按可删除密钥；

MainActivity

密钥库系统工具类

生成密钥时使用X500Principal指定了自签署证书,参数分别代表汪游
CN:通用名称
O:组织
OU:组织单元
C:国家
并且指定密钥的有效时间，并且指定了用于生成密钥对的自签名证书的序列号。

这里指定了通过密钥库系统生成RSA密钥。

先从密钥库中取出密钥，使用公钥进行加密

先从密钥库中取出密钥，使用私钥进行解密

使用密钥对数据签名，签名算法须与秘钥算法保持一致。

使用密钥对数据进行签名认证，签名算法须与秘钥算法保持一致。

密钥库支持的算法可参考： https://developer.android.com/training/articles/keystore

demo链接： https://github.com/samlss/KeyStore

⑵ 安卓常见的一些加密（（对称加密DES，AES），非对称加密（RSA），MD5）

DES是一种对称加密算法，所谓对称加密算法即：加密和解密使用相同密钥的算法。DES加密算法出自IBM的研究，
后来被美国政府正式采用，之后开始广泛流传，但是近些年使用越来越少，因为DES使用56位密钥，以现代计算能力，
24小时内即可被破解

调用过程

最近做微信小程序获取用户绑定的手机号信息解密，试了很多方法。最终虽然没有完全解决，但是也达到我的极限了。有时会报错：javax.crypto.BadPaddingException: pad block corrupted。

出现错误的详细描述
每次刚进入小程序登陆获取手机号时，会出现第一次解密失败，再试一次就成功的问题。如果连续登出，登入，就不会再出现揭秘失败的问题。但是如果停止操作过一会，登出后登入，又会出现第一次揭秘失败，再试一次就成功的问题。
网上说的，官方文档上注意点我都排除了。获取的加密密文是在前端调取wx.login（）方法后，调用我后端的微信授权接口，获取用户的sessionkey，openId.然后才是前端调用的获取sessionkey加密的用户手机号接口，所以我可以保证每次sessionkey是最新的。不会过期。
并且我通过日志发现在sessionkey不变的情况下，第一次失败，第二次解密成功。

加密算法，RSA是绕不开的话题，因为RSA算法是目前最流行的公开密钥算法，既能用于加密，也能用户数字签名。不仅在加密货币领域使用，在传统互联网领域的应用也很广泛。从被提出到现在20多年，经历了各种考验，被普遍认为是目前最优秀的公钥方案之一

非对称加密算法的特点就是加密秘钥和解密秘钥不同，秘钥分为公钥和私钥，用私钥加密的明文，只能用公钥解密；用公钥加密的明文，只能用私钥解密。

一、 什么是“素数”？
素数是这样的整数，它除了能表示为它自己和1的乘积以外，不能表示为任何其它两个整数的乘积
二、什么是“互质数”（或“互素数”）？
小学数学教材对互质数是这样定义的：“公约数只有1的两个数，叫做互质数
（1）两个质数一定是互质数。例如，2与7、13与19。
（2）一个质数如果不能整除另一个合数，这两个数为互质数。例如，3与10、5与 26。
（3）1不是质数也不是合数，它和任何一个自然数在一起都是互质数。如1和9908。
（4）相邻的两个自然数是互质数。如 15与 16。
（5）相邻的两个奇数是互质数。如 49与 51。
（6）大数是质数的两个数是互质数。如97与88。
（7）小数是质数，大数不是小数的倍数的两个数是互质数。如 7和 16。
（8）两个数都是合数（二数差又较大），小数所有的质因数，都不是大数的约数，这两个数是互质数。如357与715，357=3×7×17，而3、7和17都不是715的约数，这两个数为互质数。等等。
三、什么是模指数运算？
指数运算谁都懂，不必说了，先说说模运算。模运算是整数运算，有一个整数m，以n为模做模运算，即m mod n。怎样做呢？让m去被n整除，只取所得的余数作为结果，就叫做模运算。例如，10 mod 3=1；26 mod 6=2；28 mod 2 =0等等。
模指数运算就是先做指数运算，取其结果再做模运算。如(5^3) mod 7 = (125 mod 7) = 6。

其中，符号^表示数学上的指数运算；mod表示模运算，即相除取余数。具体算法步骤如下：
（1）选择一对不同的、足够大的素数p，q。
（2）计算n=p q。
（3）计算f(n)=(p-1) (q-1)，同时对p, q严加保密，不让任何人知道。
（4）找一个与f(n)互质的数e作为公钥指数，且1<e<f(n)。
（5）计算私钥指数d，使得d满足(d*e) mod f(n) = 1
（6）公钥KU=(e,n)，私钥KR=(d,n)。
（7）加密时，先将明文变换成0至n-1的一个整数M。若明文较长，可先分割成适当的组，然后再进行交换。设密文为C，则加密过程为：C=M^e mod n。
（8）解密过程为：M=C^d mod n。

在RSA密码应用中，公钥KU是被公开的，即e和n的数值可以被第三方窃听者得到。破解RSA密码的问题就是从已知的e和n的数值（n等于pq），想法求出d的数值，这样就可以得到私钥来破解密文。从上文中的公式：(d e) mod ((p-1) (q-1)) = 1，我们可以看出，密码破解的实质问题是：从p q的数值，去求出(p-1)和(q-1)。换句话说，只要求出p和q的值，我们就能求出d的值而得到私钥。
当p和q是一个大素数的时候，从它们的积p q去分解因子p和q，这是一个公认的数学难题。比如当p*q大到1024位时，迄今为止还没有人能够利用任何计算工具去完成分解因子的任务。因此，RSA从提出到现在已近二十年，经历了各种攻击的考验，逐渐为人们接受，普遍认为是目前最优秀的公钥方案之一。
缺点1：虽然RSA的安全性依赖于大数的因子分解，但并没有从理论上证明破译RSA的难度与大数分解难度等价。即RSA的重大缺陷是无法从理论上把握它的保密性能如何。

在android 开发的很多时候。为了保证用户的账户的安全性，再保存用户的密码时，通常会采用MD5加密算法，这种算法是不可逆的，具有一定的安全性

MD5不是加密算法， 因为如果目的是加密，必须满足的一个条件是加密过后可以解密。但是MD5是无法从结果还原出原始数据的。

MD5只是一种哈希算法

⑶ Android加密算法总结

1.概念：
Base64是一种用64个字符(+/)来表示二进制数据的方法，只是一种编码方式，所以不建议使用Base64来进行加密数据。

2.由来：
为什么会有Base64编码呢？因为计算机中数据是按ascii码存储的，而ascii码的128～255之间的值是不可见字符。在网络上交换数据时，比如图片二进制流的每个字节不可能全部都是可见字符，所以就传送不了。最好的方法就是在不改变传统协议的情况下，做一种扩展方案来支持二进制文件的传送，把不可打印的字符也能用可打印字符来表示，所以就先把数据先做一个Base64编码，统统变成可见字符，降低错误率。

3.示例：

加密和解密用到的密钥是相同的，这种加密方式加密速度非常快，适合经常发送数据的场合。缺点是密钥的传输比较麻烦。

1.DES
DES全称为Data Encryption Standard，即数据加密标准，是一种使用 密钥加密 的块算法。
DES算法把64位的明文输入块变为64位的密文输出块，它所使用的密钥也是64位，密钥事实上是56位参与DES运算（第8、16、24、32、40、48、56、64位是校验位，使得每个密钥都有奇数个1）分组后的明文组和56位的密钥按位替代或交换的方法形成密文组的加密方法。

2.3DES
3DES（或称为Triple DES）是三重 数据加密算法 （TDEA，Triple Data Encryption Algorithm）块密码的通称。是DES向AES过渡的加密算法，它使用3条56位的密钥对数据进行三次加密。是DES的一个更安全的变形。它以DES为基本模块，通过组合分组方法设计出分组加密算法。比起最初的DES，3DES更为安全。

3.AES
AES全称Advanced Encryption Standard，即高级加密标准，当今最流行的对称加密算法之一，是DES的替代者。支持三种长度的密钥：128位，192位，256位。

AES算法是把明文拆分成一个个独立的明文块，每一个明文块长128bit。这些明文块经过AES加密器的复杂处理，生成一个个独立的密文块，这些密文块拼接在一起，就是最终的AES加密结果。
但是这里涉及到一个问题：假如一段明文长度是192bit，如果按每128bit一个明文块来拆分的话，第二个明文块只有64bit，不足128bit。这时候怎么办呢？就需要对明文块进行填充（Padding）：

AES的工作模式，体现在把明文块加密成密文块的处理过程中。

加密和解密用的密钥是不同的，这种加密方式是用数学上的难解问题构造的，通常加密解密的速度比较慢，适合偶尔发送数据的场合。优点是密钥传输方便。

1.SHA
安全散列算法（英语：Secure Hash Algorithm，缩写为SHA）是一个密码散列函数家族，是FIPS所认证的安全散列算法。能计算出一个数字消息所对应到的，长度固定的字符串（又称消息摘要）的算法，且若输入的消息不同，它们对应到不同字符串的机率很高。
SHA分为SHA-1、SHA-224、SHA-256、SHA-384，和SHA-512五种算法，后四者有时并称为SHA-2。SHA-1在许多安全协定中广为使用，包括TLS和SSL、PGP、SSH、S/MIME和IPsec，曾被视为是MD5（更早之前被广为使用的杂凑函数）的后继者。但SHA-1的安全性如今被密码学家严重质疑；虽然至今尚未出现对SHA-2有效的攻击，它的算法跟SHA-1基本上仍然相似；因此有些人开始发展其他替代的杂凑算法。

2.RSA
RSA算法1978年出现，是第一个既能用于数据加密也能用于数字签名的算法，易于理解和操作。
RSA基于一个数论事实：将两个大素数相乘十分容易，但想要对其乘积进行因式分解却极其困难，因此可以将乘积公开作为加密密钥，即公钥，而两个大素数组合成私钥。公钥是可提供给任何人使用，私钥则为自己所有，供解密之用。

3.MD5
MD5信息摘要算法 （英语：MD5 Message-Digest Algorithm），一种被广泛使用的密码散列函数，可以产生出一个128位（16字节）的散列值，用于确保信息传输完整一致。具有如下优点：

XOR：异或加密，既将某个字符或者数值 x 与一个数值 m 进行异或运算得到 y ，则再用 y 与 m 进行异或运算就可还原为 x。
使用场景：
（1）两个变量的互换（不借助第三个变量）；
（2）数据的简单加密解密。

⑷ Android使用RSA加密和解密

1.data是要加密的数据，如果是字符串则getBytes。publicKey是公钥，privateKey是私钥。自定义密钥对测试

2.从文件中读取公钥

当加密的数据过长时，会出现javax.crypto.IllegalBlockSizeException: Data must not be longer than 117 bytes的异常。rsa算法规定一次加密的数据不能超过生成密钥对时的keyLength/8-11，keyLength一般是1024个字节，则加密的数据不能超过117个字节

测试分段加密和解密

生成公钥和私钥后，用base64编码

一、android加密的数据服务器上无法解密？
android的rsa加密方式是RSA/ECB/NoPadding，而标准jdk是RSA/ECB/PKCS1Padding，所以加密时要设置标准jdk的加密方式

二、base64编码。因为不同的设备对字符的处理方式不同，字符有可能处理出错，不利于传输。所以先把数据做base64编码，变成可见字符，减少出错
官方提供的base64类，Base64.encode编码，Base64.decode解码。用这个会有换行符，需要自定义

三、rsa是非对称加密算法。依赖于大数计算，加密速度比des慢，通常只用于加密少量数据或密钥

四、公钥加密比私钥加密块，公钥解密比私钥解密慢。加密后的数据大概是加密前的1.5倍

⑸ Android每日一题：v3签名key和v2还有v1有什么区别

答：在v1版本的签名中，签名以文件的形式存在于apk包中，这个版本的apk包就是一个标准的zip包，V2和V1的差别是V2是对整个zip包进行签名，而且在zip包中增加了一个apk signature block，里面保存槐侍签名信息。

v2版本签名块（APK Signing Block）本身又主要分成三部分:

SignerData（签名者数据）：主要包兄明培括签名者的证书，整个APK完整性校验hash，以及一些必要信息

Signature（签名）：开发者对SignerData部分数据的签名数据

PublicKey（公钥）：用于验签的公钥数据

v3版本签名块也分成同样的三部分，与v2不同羡唯的是在SignerData部分，v3新增了attr块，其中是由更小的level块组成。每个level块中可以存储一个证书信息。前一个level块证书验证下一个level证书，以此类推。最后一个level块的证书，要符合SignerData中本身的证书，即用来签名整个APK的公钥所属于的证书

⑹ android 怎么读取rsa公钥

这个很简单 如果密码手工输入 理论上完全可以 但是密悔橡钥有时候二进制有时候会上百位 转化到其他进制要几十位 很容易出错 而且私钥 公钥是从一个推出另一个的 手工输入怎么保证你输入的公钥私钥模宏就可以一定可以配成一对keyPair 而且公钥私钥 必须还要从用p q来算 等等如果手工输入太麻烦了 为何我们不把这些繁琐的 容易出错的东西 封装起来来简化我们的开发呢 所以我们有了各种各样的开发包 各种各样的架构 各种各样的库 java中旦前册 KeyPairGenerator keyGen = KeyPairGenerator.getInstance("RSA"); KeyPair key = keyGen.generateKeyPair(); cipher.init(Cipher.ENCRYPT_MODE, key.getPublic()); cipher.init(Cipher.DECRYPT_MODE, key.getPrivate()); 这是我以前写的代码的片段 不是连续的 大体上就是先得到一个rsa的密钥对 然后调用getpublic() getprivatekey()获取公私钥就可以了

⑺ Android网络请求加密机制

密码学的三大作用：加密（ Encryption）、认证（Authentication），鉴定（Identification）

加密 ：防止坏人获取你的数据。 

鉴权 ：防止坏人假冒你的身份。

认证 ：防止坏人修改了你的数据而你却并没有发现。

1. URLEncode和URLDecoder 作用：URLEncode就是将URL中特殊部分进行编码。URLDecoder就是对特殊部分进行解码。

为什么URL要encode原因呢？

url转义其实也只是为了符合url的规范而已。因为在标准的url规范中 中文和很多的字符 是不允许出现在url中的。

2. Base64编码

为什么要进行Base64编码？

在计算机中任何数据都是按ascii码存储的，而ascii码的128～255之间的值是不可见字符。而在网络上交换数据时，比如说从A地传到B地，往往要经过多个路由设备，由于不同的设备对字符的处理方式有一些不同，这样那些不可见字符就有可能被处理错误，这是不利于传输的。所以就先把数据先做一个Base64编码，统统变成可见字符，这样出错的可能性就大降低了。

应用场景：主要是对于二进制数据进行编码，（文件、图片、加密后的二进制数据）

3. 消息认证算法

要确保加密的消息不是别人伪造的，需要提供一个消息认证码（MAC，Message authentication code） 。 

消息认证码是带密钥的hash函数，基于密钥和hash函数(单向散列函数）。

密钥双方事先约定，不能让第三方知道。

消息发送者使用MAC算法计算出消息的MAC值，追加到消息后面一起发送给接收者。 

接收者收到消息后，用相同的MAC算法计算接收到消息MAC值，并与接收到的MAC值对比是否一样。

消息认证码的作用：检查某段消息的完整性，以及作身份验证。

防止重放 攻击可以有 3 种方法：

序号

每条消息都增加一个递增的序号，并且在计算 MAC 值的时候把序号也包含在消息中。这样攻击者如果不破解消息认证码就无法计算出正确的 MAC 值。这个方法的弊端是每条消息都需要多记录最后一个消息的序号。

时间戳

发送消息的时候包含当前时间，如果收到的时间与当前的不符，即便 MAC 值正确也认为是错误消息直接丢弃。这样也可以防御重放攻击。这个方法的弊端是，发送方和接收方的时钟必须一致，考虑到消息的延迟，所以需要在时间上留下一定的缓冲余地。这个缓冲之间还是会造成重放攻击的可趁之机。

nonce

在通信之前，接收者先向发送者发送一个一次性的随机数 nonce。发送者在消息中包含这个 nonce 并计算 MAC 值。由于每次 nonce 都会变化，因此无法进行重放攻击。这个方法的缺点会导致通信的数据量增加。

4. 对称加密算法

特点：加解密只有一个密钥。优点：速度快、效率高。缺点：密钥交换问题。算法：AES(256字节,主流）、DES（8字节，淘汰）。

密钥交换问题如何解决，MAC同样也有这个问题，可以使用非对称加密传输，或者私下约定，密钥管理中心。

5. 非对称加密

非对称加密算法需要两个密钥：公开密钥（publickey）和私有密钥（privatekey）。公开密钥与私有密钥是一对，如果用公开密钥对数据进行加密，只有用对应的私有密钥才能解密；如果用私有密钥对数据进行加密，那么只有用对应的公开密钥才能解密（这个过程可以做数字签名） 。 非对称加密主要使用的是RSA算法。

特点：公/私钥机制。优点：只需要交换公钥，安全。缺点：加解密速度慢，特别是解密。算法：RSA。应用：数字签名。

数字签名 ：

简单解释：

A：将明文进行摘要运算后得到摘要（消息完整性），再将摘要用A的私钥加密（身份认证），得到数字签名，将密文和数字签名一块发给B。

B：收到A的消息后，先将密文用自己的私钥解密，得到明文。将数字签名用A的公钥进行解密后，得到正确的摘要（解密成功说明A的身份被认证了）。

数字证书 ：

6. Android端 AES+RSA结合实践

基本流程

Android端

服务器端

基本上如下图所示的流程：

⑻ 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签名签名原理简析

仅供参考，欢迎指正

⑼ 一文弄懂关于证书，签名，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协议基于证书来实现。

⑽ Android 的几种加密方式

Android 中的最常用得到有三种加密方式：MD5,AES,RSA.

1.MD5

MD5本质是一种散列函数，用以提供消息的完整性保护。

特点：

1.压缩性：任意长度的数据，算出的MD5值长度都是固定的；

2.容易计算：从原数据计算出MD5值很容易；

3.抗修改性：对原数据进行任何改动，哪怕只修改一个字节，所得到的MD5值都有很大的区别

4.强抗碰撞：已知原数据和其MD5值，想找到一个具有相同MD5值的数据（及伪造数据）是非常困难的；

2.RSA加密

RSA加密算法是一种非对称加密算法，非对称加密算法需要两个密钥：公共密钥和私有密钥。公钥和私钥是配对的，用公钥加密的数据只有配对的私钥才能解密。

RSA对加密数据的长度有限制，一般为密钥的长度值-11，要加密较长的数据，可以采用数据截取的方法，分段加密。

3.AES加密

AES加密是一种高级加密的标准，是一种区块加密标准。它是一个对称密码，就是说加密和解密用相同的密钥。WPA/WPA2经常用的加密方式就是AES加密算法。