通过签名可以确保数据来源的可靠性和数据的不可篡改性
对 Apk 进行签名，也就是在 Apk 中写入一个指纹，写入指纹后，Apk 中有任何修改，都会导致这个指纹无效，Android 系统在安装 Apk 进行签名校验时就会不通过，进而无法安装该 Apk
如上图：
通常的签名验签过程中，接收方收到消息后，会先向 CA 机构验证证书的合法性，再进行签名校验。但 Apk 的证书通常由开发者自己制作，没有向 CA 机构申请，Android 系统在安装 Apk 时也并没有校验证书本身的合法性，只是从证书中提取公钥和加密算法，因此，如果对第三方 Apk 重新签名，也能安装到没有安装过这个 Apk 的系统中
keystore 文件包含私钥、公钥和数字证书，分为很多种，Android 使用的是 Java 标准 keystore 格式 JKS(Java Key Storage)
Android App Bundle：用于通过 Google Play 发布的应用，需要升级到AS 3.2 以上版本才支持App Bundle 格式；
APK：用于创建可部署到设备上的签名 APK
点击 Finish 就会生成签名文件与签名后的 Apk
当我们需要升级 Apk 版本的时候，需要再次对 Apk 文件进行签名，可以通过配置 build.gradle 让其自动生成签名后的 Apk
如果你的项目是开源的，需要把你的签名信息写在 local.properties 中，然后在 .gitignore 配置文件中加入 local.properties ，这样 local.properties 就不会提交到开源项目中，签名信息也就不会被人获取
local.properties：
app/build.gradle:
有时候我们的 apk 中某些功能尺则需要系统签名，例如静默安装。测试系统签名的 apk，需要 root 权槐谈限，而带 Google APIs 的模拟器不能 root，因铅困碰此要注意不能选择带 Google APIs 的模拟器
下面执行的 *** 作都是在 Linux 中，如果 apk 是 window 中生成的，需要拷贝到 linux *** 作，再将生成的系统签名过得 apk 再拷贝到 window，比较麻烦，可以考虑后面的自动系统签名，还是需要在 linux *** 作一次，不过之后就可以只在 window *** 作了
这两个文件在目录 aosp/build/target/product/security 下，如下图
在目录 aosp/prebuilts/sdk/tools/lib 下，如下图
将前面获取的 platform.pk8 、 platform.x509.pem 和 signapk.jar 文件放到需要签名的 apk 同一个目录，执行以下命令
如果出现上面的错误：Failed to load any of the given libraries: [conscrypt_openjdk_jni-linux-x86_64, conscrypt_openjdk_jni-linux-x86_64-fedora, conscrypt_openjdk_jni]
解决方法：
到目录 aosp/prebuilts/sdk/tools/linux/lib64 下，复制 libconscrypt_openjdk_jni.so 文件到需要签名 apk 的同一个目录，并将命令改为
自动进行系统签名的原理是：先生成一个 system.jks 文件，使用 keytool-importkeypair 对 system.jks 文件进行系统签名，再 build.gradle 和 local.properties 进行配置，直接使用带有系统签名的 system.jks 对 apk 进行签名，这样编译生成的apk文件就自带系统签名了
按照前面的方法，生成一个 system.jks 文件，此时是在 window 系统中 *** 作的
进入 keytool-importkeypair 目录，将 system.jks、platform.pk8、platform.x509.pem 文件拷贝进来，拷贝之后的目录结构为
使用 linux 中修改过的带有系统签名的 system.jks 文件将 window 中最开始生成的 system.jks 覆盖掉，再像前面的自动签名部分一样，修改 build.gradle 和 local.properties 的配置，之后生成的 apk 就是系统签名过的了
测试方法是，在 AndroidManifest.xml 中添加 android:sharedUserId="android.uid.system" 后安装到 非 Google APIs 的模拟器上 ， Google APIs 的模拟器不能 root，无法安装
会发现只有使用 system.jks 文件签名后才能安装，否则安装失败，会报以下的错误：
Android签名机制目的是确保app的可靠通信，其一，要确定消息的来源确实是其申明
的那个人；其二，要保证信息在传递的过程中不被第三方篡改，即使被篡改了，也可以
发觉出来。
所谓数字签名，就是为了解决这两个问题而产生的，它是对非对称加密技术与数字摘要
技术的一个具体的应用。
对于消息的发送者来说，先要生成一对公私钥对，则穗将公钥给消息的接收者。
如果消息的发送者有一天想给消息接收者发消息，在发送的信息中，除了要包含原始的
消息外，还要加上另外一段消息。这段消息通过如下两步生成：
1）对要发送的原始消息提取消息摘要；
2）对提取的信息摘要用自己的私钥加密。
通过这两步得出的消息，就是所谓的原始信息的数字签名。
而对于信息的接收者来说，他所收到的信息，将包含两个部分，一是原始的消息内容，
二是附加的那段数字签名。他将通过以下三步来验证消息的真伪：
1）对原始消息部分提取消息摘要，注意这里使用的消息摘要算法要和发送方使用的一孙游卜致；
2）对附加上的那段数字签名，使用预先得到的公钥解密；
3）比较前两步所得到的两段消息是否一致。如果一致，则表明消息确实是期望的发送者
发的，且内容没有被篡改过；相反，如果不一致，则表明传送的过程中一定出了问题，
消息不可信。
通过这种所谓的数字签名技术，确实可以有效解决可靠通信的问题。如果原始消息在传
送的过程中被篡改了，那么在消息接收者那里，对被篡改的消息提取的摘要肯定和原始
的不一样。并且，由于篡改者没有消息发送方的私钥，即使他可以重新算出被篡改消息
的摘要，也不能伪造出数字签名。
那么数字签名呢？
综上所述，数字签名其实就是只有信息的发送者才能产生的别人无法伪造的一段数字
串，这段数字串同时也是对信息的发送者发送信息真实性的一个有效证明。
不知道大家有没有注意，前面讲的这种数字签名方法，有一个前提，就是消息的接收者
必须要事先得到正确的公钥。如果一开始公钥就被别人篡改了，那坏人就会被你当成好
人，而真正的消息发送者给你发的消息会被你视作无效的。而且，很多时候根本就不具
备事先沟通公钥的信息通道。那么如何保证公钥的安全可信磨吵呢？这就要靠数字证书来解
决了。
所谓数字证书，一般包含以下一些内容：
证书的发布机构（Issuer）
证书的有效期（Validity）
消息发送方的公钥
证书所有者（Subject）
数字签名所使用的算法
数字签名
可以看出，数字证书其实也用到了数字签名技术。只不过要签名的内容是消息发送方的
公钥，以及一些其它信息。但与普通数字签名不同的是，数字证书中签名者不是随随便
便一个普通的机构，而是要有一定公信力的机构。这就好像你的大学毕业z书上签名的
一般都是德高望重的校长一样。一般来说，这些有公信力机构的根证书已经在设备出厂
前预先安装到了你的设备上了。所以，数字证书可以保证数字证书里的公钥确实是这个
证书的所有者的，或者证书可以用来确认对方的身份。数字证书主要是用来解决公钥的
安全发放问题。
综上所述，总结一下，数字签名和签名验证的大体流程如下图所示：
引用链接： https://www.cnblogs.com/dacainiao/p/5842987.html
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）