普法Android系统各类签名以及关联Key知识

本篇博客编写思路总结和关键点说明:

在这里插入图片描述
为了更加方便的读者阅读博客，通过导读思维图的形式将本博客的关键点列举出来，从而方便读者取舍和阅读！

引言

对于Android的签名机制，无论你是应用开发者还是Android系统层级开发者来说都是一个绕不过的知识点！为什么这么说呢？假如你是应用开发者，你一定会给你的应用apk加上自己或者公司的签名防止被被第三方恶意篡改，假如你是Android系统ROM层级开发者，当我们要发布一款Android产品，就需要给我们的整个Android系统签名，防止被别人盗用，通常这种签名被成为系统级别的release签名。

当然本篇博客的重点不是讨论Android应用App签名的发展史(譬如V1,V2签名啊)，也不是讨论Android的签名验签机制的。我这里写该博客的出发点是想站在Android系统ROM的开发角度出发来对Android的相关签名和key简单分析一番，正如标题所说普法Android系统各类签名以及关联Key知识那样。

注意：本篇的介绍是基于Android 7.xx平台为基础的，其中涉及的代码路径如下：

build/target/product/security/
development/tools/make_key

一.什么是签名

假如这个问题不是放在Android开发的环境来问，读者很快就能给出答复了！可放在Android开发中来询问何为签名，大家就开始迷惑了或者需要一定的时间来组织语言回复了。其实从发展的角度来看，计算机所做的事情，或者说编程语言所做的事情，不正是在尽可能地模拟现实吗？所以，Android中所说的签名和生活中所说的签名在本质上是一样的，它所起到的作用也是一致的！我们在现实中的签名就意味着在纸上或别处写下自己的名字，或者说在某处打上一个标记作为你自己的一种特有的标识，当别人看到这个签名的时候，他会知道这是和你有关的，而不是其它人。而在Android中的签名就是对我们的App或者系统固件加上特定的一些信息，防止被恶意篡改而已，而加上的这些特定信息就是签名(至于怎么加上，以及怎么验证这个不是本篇博客的重点，我会在最后附上相关的一些参考如果有感兴趣的小伙们)。

二.Android签名的作用

关于Android应用签名的作用，必须从两个角度出发，即Android应用开发者和Android系统的设计角度出发！下面我们就从这两个角度出发，简单的介绍一下。

2.1 站在Android应用开发角度看Android签名的作用

从Android应用开发者的角度出发来说，Android的签名作用可以从如下两个方面体现:

确保应用开发者身份的唯一性，因为Android应用的包名是可以任意替换的，假如某某公司或者个人开发了一个现象级的应用的，如果没有签名来保证App的唯一性，那么Android的世界应该就乱套了，会出现无数的模仿者，更有甚者会制作出一个一模一样的包名的应用替换它
保证Apk在信息传输中的的完整性，签名对于包中的每个文件进行处理，以此确保包中内容不被替换或者被篡改，这也是为什们通常建议大家在正规渠道下载App的原因，特别是对于一些涉及金钱交易的Apk来说更是如此(譬如植入恶意木马程序)，被盗取个人信息甚至是金钱，那这个损失是找开发者还是谁呢，谁也说不清楚

2.2 站在Android设计者的角度出发看Android签名的作用

站在Android设计者的角度出发，那么他所要考虑的角度就比较高了，但是无外乎如下几点:

为了应用程序升级：如果你希望用户无缝升级到新的版本，那么你必须用同一个证书进行签名。这是由于只有以同一个证书签名，系统才会允许安装升级的应用程序。如果你采用了不同的证书，那么系统会要求你的应用程序采用不同的包名称，在这种情况下相当于安装了一个全新的应用程序。如果想升级应用程序，签名证书要相同，包名称要相同！
为了应用程序模块化：Android系统可以允许同一个证书签名的多个应用程序在一个进程里运行，系统实际把他们作为一个单个的应用程序，此时就可以把我们的应用程序以模块的方式进行部署，而用户可以独立的升级其中的一个模块

扫描二维码关注公众号，回复： 12395733 查看本文章
为了代码或者数据共享：Android提供了基于签名的权限机制，那么一个应用程序就可以为另一个以相同证书签名的应用程序公开自己的功能。以同一个证书对多个应用程序进行签名，利用基于签名的权限检查，你就可以在应用程序间以安全的方式共享代码和数据了。
为了Android固件的安全考虑:我们知道Android可以系统版本进行OTA的升级，那么Android是怎么确保升级的固件是合法的呢，这个就是对OTA包进行签名，然后在进行Recovery升级的时候来验证OTA的签名来确保固件的合法和唯一性

而Android为了实现上述的功能，就离不开各种签名文件和相关的key了，而这个也是本篇博客比较篇章的知识点了！

三.Android系统签名文件简介

通过前面的分析我们知道Android为我们提供了各种类型的签名文件，所以我们肯定的必须的来熟悉一番，甚至更进一步的掌握一番才是，但是在这之间我们有必要先来看个东西，啥东西呢，这就安排上了。

3.1 什么是.pem和.pk8文件

这里为啥突然整个啥.pem和.pkm文件来说呢，因为它们是我们Android系统签名文件的最终载体，并且二者几乎是成对存在的。我们先来分别接啥一下.

.pem类型文件：
在android对apk签名的时候，.pem这种文件就是一个X.509的数字证书，里面有用户的公钥等信息，是用来解密的。文件格式里面不仅可以存储数字证书，还能存各种key,这个可以公开，主要用于验证某个App或者其它的是否由相应的私钥签名
.pk8
以.pk8为扩展名的文件，应该和PKCS #8是对应的，用来保存private key,并且这个私钥需要保密保存，不能公开

3.2 Android中存在那些类型的系统签名

有了前面的铺垫，我们来看看Android的设计者为我们设计了那些类型的系统签名(注意这里的系统签名，不是特指system)，通常Android源码中的系统签名都被统一存放在了Android的源码build/target/product/security中，我们来看下：

XXXX：/build/target/product/security$ tree
.
├── Android.mk
├── media.pk8
├── media.x509.pem
├── platform.pk8
├── platform.x509.pem
├── README
├── shared.pk8
├── shared.x509.pem
├── testkey.pem
├── testkey.pk8
├── testkey.x509.pem
├── verity_key
├── verity.pk8
└── verity.x509.pem

0 directories, 14 files

这里我们可以看到主要有media，platform，shared，testkey等4个系统默认预置的签名(关于这几个签名其功能这个后续介绍)！

并且老司机们应该都知道通常Android源码中的README都比较重要，这里也不列外的Android的设计者为我们贴心的也提供了，建议读者抽时间看看(主要介绍了怎么通过内置工具生成和替换系统默认预置的各种key，以及各种key的简单使用实例)！

For detailed information on key types and image signing, please see:

https://source.android.com/devices/tech/ota/sign_builds.html

The test keys in this directory are used in development only and should
NEVER be used to sign packages in publicly released images (as that would
open a major security hole).

key generation
--------------

The following commands were used to generate the test key pairs:

  development/tools/make_key testkey  '/C=US/ST=California/L=Mountain View/O=Android/OU=Android/CN=Android/[email protected]'
  development/tools/make_key platform '/C=US/ST=California/L=Mountain View/O=Android/OU=Android/CN=Android/[email protected]'
  development/tools/make_key shared   '/C=US/ST=California/L=Mountain View/O=Android/OU=Android/CN=Android/[email protected]'
  development/tools/make_key media    '/C=US/ST=California/L=Mountain View/O=Android/OU=Android/CN=Android/[email protected]'

signing using the openssl commandline (for boot/system images)
--------------------------------------------------------------

1. convert pk8 format key to pem format
   % openssl pkcs8 -inform DER -nocrypt -in testkey.pk8 -out testkey.pem

2. create a signature using the pem format key
   % openssl dgst -binary -sha1 -sign testkey.pem FILE > FILE.sig

extracting public keys for embedding
------------------------------------

dumpkey.jar is a Java tool that takes an x.509 certificate in PEM format as
input and prints a C structure to standard output:

    $ java -jar out/host/linux-x86/framework/dumpkey.jar build/target/product/security/testkey.x509.pem
    {
    
    64,0xc926ad21,{
    
    1795090719,2141396315,950055447,2581568430,4268923165,1920809988,546586521,3498997798,1776797858,3740060814,1805317999,1429410244,129622599,1422441418,1783893377,1222374759,2563319927,323993566,28517732,609753416,1826472888,215237850,4261642700,4049082591,3228462402,774857746,154822455,2497198897,2758199418,3019015328,2794777644,87251430,2534927978,120774784,571297800,3695899472,2479925187,3811625450,3401832990,2394869647,3267246207,950095497,555058928,414729973,1136544882,3044590084,465547824,4058146728,2731796054,1689838846,3890756939,1048029507,895090649,247140249,178744550,3547885223,3165179243,109881576,3944604415,1044303212,3772373029,2985150306,3737520932,3599964420},{
    
    3437017481,3784475129,2800224972,3086222688,251333580,2131931323,512774938,325948880,2657486437,2102694287,3820568226,792812816,1026422502,2053275343,2800889200,3113586810,165549746,4273519969,4065247892,1902789247,772932719,3941848426,3652744109,216871947,3164400649,1942378755,3996765851,1055777370,964047799,629391717,2232744317,3910558992,191868569,2758883837,3682816752,2997714732,2702529250,3570700455,3776873832,3924067546,3555689545,2758825434,1323144535,61311905,1997411085,376844204,213777604,4077323584,9135381,1625809335,2804742137,2952293945,1117190829,4237312782,1825108855,3013147971,1111251351,2568837572,1684324211,2520978805,367251975,810756730,2353784344,1175080310}}

This is called by build/core/Makefile to incorporate the OTA signing keys
into the recovery image.

3.3 Android中各类型签名文件的用途

在分析Android中各类型签名文件的用途之前，我们有必要来简单先掰持掰持Android中的sharedUserId，因为Android设计出这么多签名文件的意图绝大部分是为了它。

3.3.1 Android中sharedUserId的作用

我们知道Android设备中每一个正常安装的Apk，在其安装的时候Android就会给每个APK进程分配一个单独的用户空间,其AndroidManifest中的userid就是对应一个Linux用户都会被分配到一个属于自己的统一的Linux用户ID，并且为它创建一个沙箱，以防止其它应用非法写入或者篡改，当然也有可能是它非法篡改或者写入其它的应用，譬如一般应用只能访问自己包名下的文件（/data/data/pkgname），不能反问其他包名下的data数据，当然其他应用也访问不了自己包名下的文件(这里需要注意一点的就是用户ID在应用程序安装到设备中时被分配，并且在这个设备中保持它的永久性)。

上述的的沙箱隔离机制是非常好的，但是开发的过程中用户和使用者的需求有时候和设计者是矛盾的，那么假如同一个公司开发的A应用想拿到B应用的data下面的数据怎么办呢！这里就要引出我们的sharedUserId了，我们可以通过Shared User id,拥有同一个User id的多个APK可以配置成运行在同一个进程中.所以默认就是可以互相访问任意数据. 也可以配置成运行成不同的进程, 同时可以访问其他APK的数据目录下的数据库和文件.就像访问本程序的数据一样.。

3.3.2 Android怎么使用sharedUserId

前面讲述sharedUserId的作用，那么我们在源码中怎么实现Android的sharedUserId呢，其主要步骤如下：

在AndroidManifest节点中增加android:sharedUserId属性，如下

android:sharedUserId="android.uid.system"

在Android.mk中增加LOCAL_CERTIFICATE的定义，即可以完成编译时指定签名文件，如下

LOCAL_CERTIFICATE := platform

然后将上述Apk导入源码中，通过mm或者mmm编译

上述都是Android开发中的常规操作，没有啥可以好讲的！

但是上面有一定需要注意sharedUserId属性一定要和LOCAL_CERTIFICATE匹配，否则Apk签名以后安装是不会成功的，提示如下错误:
Failure [INSTALL_FAILED_UPDATE_INCOMPATIBLE: Package com.xxx.xxxsignatures do not match the previously installed version; ignoring!]
从上面我们可以看出，仅有相同签名和相同sharedUserID应用才能被正常安装，放大了来讲就是仅有相同签名和相同sharedUserID标签的两个应用程序Apk才会被分配相同的用户ID才能访问对方的私有数据，从而达到既能访问又能保证安全的机制。

但是这里的platform的签名还有点特殊，它不仅可以和system的sharedUserId配合，它还可以和其它的sharedUserId配合，譬如phone，nfc，bluetooth等！

3.3.3 Android的sharedUserId和签名文件的关联

经过上面的一通掰持掰持，我想读者应该能理解sharedUserId和签名文件的作用了，即通过sharedUserId标签，和签名一通配合，从而是Apk应用配相同的用户ID，进而实现数据共享的目的。但是如果仅有sharedUserId标签的话，是无法确保安全的，也很容易被非法利用，所以这才引入了各种签名。

3.3.4 Android系统中签名文件的作用说明

是时候进入本节标题的正题了，前面我们引入了签名文件设计的意图，下面我们分别来介绍下这几种签名文件的功能！

platform:通常用于Android平台的核心Apk签名，它们通常用来完成Android系统的核心功能，这些Apk所在的进程UID是system，并且其AndroidManifest节点中配置android:sharedUserId=“android.uid.system”，我们最常见的莫过于Settings了。并且上述的签名也是很多第三方Apk梦寐以求的，拥有了它就可以干一些超出寻常权限的事情了(至于是什么事情，这个读者自行脑补了)！

这里需要注意一点，我们在ps的时候会看到一些Native层的bin文件也会是system的uid，它的实现方式和我们这里是有点区别的，这里需要注意。它并不是通过签名来实现的，而是通过运行的时候指定UID和GUID来实现的。
如下：
service fingerprintd /system/bin/fingerprintd
class late_start
user system
group system

ps | grep system
system    5644  513   843248 36512 SyS_epoll_ b27754e8 S com.android.keychain
system    5823  513   848436 38328 SyS_epoll_ b27754e8 S com.qualcomm.location.XT
system    6030  513   842904 35436 SyS_epoll_ b27754e8 S com.qualcomm.telephony
system    6117  513   843504 35876 SyS_epoll_ b27754e8 S com.qualcomm.timeservice
system    5017  513   889712 53660 SyS_epoll_ b27754e8 S com.android.settings

shared:这个签名的Apk通常用于和Contacts共享数据，至于Apk怎么使用和配置就不细述了，同上即可。
media:看这个签名key的名字就很明显了，它通常用于多媒体相关的Apk使用，譬如Gallery，至于Apk怎么使用和配置就不细述了，同上即可(但是这里注意它的配置是android.media不是android.uid.media，注意注意)。

在这里插入图片描述

testkey:testkey是Android平台默认编译的key，所以在Android的源码编译中如果未指定LOCAL_CERTIFICATE的值，则默认使用testkey。但是因为因为testkey是Android进行公开的，任何人都可以获取，不安全，所以一般使用自己创建releasekey作为默认key(至于怎么生成releasekey这个后面讲述)！

这里有一点我们需要注意，当我们预置第三方的App时，并不想使用Android系统的相关签名，而是想保留它的原有签名，可以通过如下的方法：
LOCAL_CERTIFICATE := PRESIGNED

四.从实战和源码的角度说说Android的签名

通过前面，读者应该对Android为什么设计签名和Android中存在那些签名应该很了解了！通常我们在实际的开发工作中会对Android的签名进行相关的定制,这里我们就从实战的角度来说说Android的签名。

在开始本节之间，最好先简单了解一下openssl命令！

4.1 生成平台自己的releasekey

我们前面说到testkey是Android平台默认编译的key(APK的默认签名，OTA的签名等)，但是因为testkey是Android进行公开的，任何人都可以获取，不安全，所以一般使用自己创建releasekey作为默认key，这里Android为了方便我们的开发者默认提供了一个快速生成各种key的命令工具集development/tools/make_key，关于它的使用在前面的README中有详细介绍，这里我们提供一个脚本一键生成相关的4个key，如下:

#!/bin/bash
subject='/C=US/ST=California/L=Mountain View/O=Android/OU=Android/CN=Android/[email protected]'
mkdir ~/.android-certs
for x in releasekey platform shared media; do \
./development/tools/make_key ~/.android-certs/$x "$subject"; \
done

注意该脚本要在我们的Android源码的根目录执行，并且对上述脚本需要执行权限，我们执行一下(注意在执行的过程中，当提示我们输入密码的时候，我们直接按Enter按键，不是用密码，否则在后续使用的过程中会提示我们输入密码):

Enter password for '/home/xxx/.android-certs/releasekey' (blank for none; password will be visible): 
creating /home/xxx/.android-certs/releasekey.pk8 with no password
Generating RSA private key, 2048 bit long modulus
.....................................+++
..................+++
e is 65537 (0x10001)

执行以后会在我们的服务器的用户目录下生成我们需要的key，如下：

XXX@pd:~/.android-certs$ tree
.
├── media.pk8
├── media.x509.pem
├── platform.pk8
├── platform.x509.pem
├── releasekey.pk8
├── releasekey.x509.pem
├── shared.pk8
└── shared.x509.pem

0 directories, 8 files
XXX@pd:~/.android-certs$

这我们重点关于的是上述脚本中的subject，它被成为我们的证书的主题(Subjuect)字段，其中每个字段的基本含义定义如下:

一般的数字证书产品的主题通常含有如下字段：
公用名称 (Common Name) 简称：CN 字段，对于 SSL 证书，一般为网站域名或IP地址；而对于代码签名证书则为申请单位名称；而对于客户端证书则为证书申请者的姓名；
单位名称 (Organization Name) ：简称：O 字段，对于 SSL 证书，一般为网站域名；而对于代码签名证书则为申请单位名称；而对于客户端单位证书则为证书申请者所在单位名称；
证书申请单位所在地：
所在城市 (Locality) 简称：L 字段
所在省份 (State/Provice) 简称：S 字段
所在国家 (Country) 简称：C 字段，只能是国家字母缩写，如中国：CN
其他一些字段：
电子邮件 (Email) 简称：E 字段
多个姓名字段简称：G 字段
介绍：Description 字段
电话号码：Phone 字段，格式要求 + 国家区号城市区号电话号码，如： +86 732 88888888
地址：STREET 字段
邮政编码：PostalCode 字段
显示其他内容简称：OU 字段

4.1.1 make_key脚本简介

这里我们也可以看到上述的命令的最终实现的最大功臣是make_key脚本，我们看看它里面有啥：

#!/bin/bash

if [ "$#" -lt 2 -o "$#" -gt 3 ]; then
  cat <<EOF
Usage: $0 <name> <subject> [<keytype>]

Creates <name>.pk8 key and <name>.x509.pem cert.  Cert contains the
given <subject>. A keytype of "rsa" or "ec" is accepted.
EOF
  exit 2
fi

if [[ -e $1.pk8 || -e $1.x509.pem ]]; then
  echo "$1.pk8 and/or $1.x509.pem already exist; please delete them first"
  echo "if you want to replace them."
  exit 1
fi

# Use named pipes to connect get the raw RSA private key to the cert-
# and .pk8-creating programs, to avoid having the private key ever
# touch the disk.

tmpdir=$(mktemp -d)
trap 'rm -rf ${tmpdir}; echo; exit 1' EXIT INT QUIT

one=${tmpdir}/one
two=${tmpdir}/two
mknod ${one} p
mknod ${two} p
chmod 0600 ${one} ${two}

read -p "Enter password for '$1' (blank for none; password will be visible): " \
  password

if [ "${3}" = "rsa" -o "$#" -eq 2 ]; then
  ( openssl genrsa -f4 2048 | tee ${one} > ${two} ) &
  hash="-sha1"
elif [ "${3}" = "ec" ]; then
  ( openssl ecparam -name prime256v1 -genkey -noout | tee ${one} > ${two} ) &
  hash="-sha256"
else
  echo "Only accepts RSA or EC keytypes."
  exit 1
fi

openssl req -new -x509 ${hash} -key ${two} -out $1.x509.pem \
  -days 10000 -subj "$2" &

if [ "${password}" == "" ]; then
  echo "creating ${1}.pk8 with no password"
  openssl pkcs8 -in ${one} -topk8 -outform DER -out $1.pk8 -nocrypt
else
  echo "creating ${1}.pk8 with password [${password}]"
  export password
  openssl pkcs8 -in ${one} -topk8 -outform DER -out $1.pk8 \
    -passout env:password
  unset password
fi

wait
wait

可以看到它里面主要是封装了openssl命令，然后通过我们的输入生成我们需要的公私钥！其大概步骤如下(这个读者可以自行传入不同的参数，自行测试)：

生成公钥(关于openssl genrsa的使用，可以借助帮助命令openssl genrsa --help)

openssl genrsa -f4 2048 releasekey.pem

将上述生成的公钥，转换成x509格式

openssl req -new -x509 -sha1 -key releasekey.pem -out releasekey.x509.pem \
  -days 10000 -subj /C=US/ST=California/L=Mountain View/O=Android/OU=Android/CN=Android/emailAddress=[email protected]

最后就是生成和公钥配对的私钥了，这里可以看到有指定了非加密的形式

openssl pkcs8 -in releasekey.pem -topk8 -outform DER -out releasekey.pk8 -nocrypt

4.2 自定义平台自己的默认key

好了，前面我们的releasekey也生成了，那么我们怎么指定我们平台自己的releasekey呢，其操作步骤流程如下:

将前面生成的releasekey(包括pem文件和pk8文件)放入build/target/product/security/中
在我们的编译device相关的mk或者build/core/config.mk指定PRODUCT_DEFAULT_DEV_CERTIFICATE := build/target/product/security/releasekey即可

//[config.mk]
# The default key if not set as LOCAL_CERTIFICATE
ifdef PRODUCT_DEFAULT_DEV_CERTIFICATE
  DEFAULT_SYSTEM_DEV_CERTIFICATE := $(PRODUCT_DEFAULT_DEV_CERTIFICATE)
else
  DEFAULT_SYSTEM_DEV_CERTIFICATE := build/target/product/security/testkey
endif

经过如上已读折腾就万事OK了。

这里我么还有一点需要就是，我面前面有说过可以通过LOCAL_CERTIFICATE指定我们Apk的签名文件吗，这是怎么做到的呢？我们可以到我们源码目录下build/下执行如下命令grep一下就大概明白了，具体的调用编译流程我就不分析了。

XXX@pd:~/XXX/build$ grep -nr "DEFAULT_SYSTEM_DEV_CERTIFICATE"  ./
./core/product.mk:286:	DEFAULT_SYSTEM_DEV_CERTIFICATE \
./core/Makefile:122:ifeq ($(DEFAULT_SYSTEM_DEV_CERTIFICATE),build/target/product/security/testkey)
./core/Makefile:401:DEFAULT_KEY_CERT_PAIR := $(DEFAULT_SYSTEM_DEV_CERTIFICATE)
./core/Makefile:980:	@echo "default_system_dev_certificate=$(DEFAULT_SYSTEM_DEV_CERTIFICATE)" >> $(ota_temp_root)/META/misc_info.txt
./core/Makefile:1035:OTA_PUBLIC_KEYS := $(DEFAULT_SYSTEM_DEV_CERTIFICATE).x509.pem
./core/Makefile:1947:	$(hide) echo "default_system_dev_certificate=$(DEFAULT_SYSTEM_DEV_CERTIFICATE)" >> $(zip_root)/META/misc_info.txt
./core/config.mk:626:  DEFAULT_SYSTEM_DEV_CERTIFICATE := $(PRODUCT_DEFAULT_DEV_CERTIFICATE)
./core/config.mk:628:  DEFAULT_SYSTEM_DEV_CERTIFICATE := build/target/product/security/testkey
./core/package_internal.mk:480:    LOCAL_CERTIFICATE := $(DEFAULT_SYSTEM_DEV_CERTIFICATE)
./core/package_internal.mk:487:  LOCAL_CERTIFICATE := $(DEFAULT_SYSTEM_DEV_CERTIFICATE)
./core/package_internal.mk:493:    LOCAL_CERTIFICATE := $(dir $(DEFAULT_SYSTEM_DEV_CERTIFICATE))$(LOCAL_CERTIFICATE)
./core/prebuilt_internal.mk:200:  LOCAL_CERTIFICATE := $(DEFAULT_SYSTEM_DEV_CERTIFICATE)
./core/prebuilt_internal.mk:222:      LOCAL_CERTIFICATE := $(dir $(DEFAULT_SYSTEM_DEV_CERTIFICATE))$(LOCAL_CERTIFICATE)

在这里插入图片描述

4.3 手动使用Android的签名文件，签名第三方App

有时候我们在开发的过程中，想通过命令的形式Android的系统签名文件签发第三方的App，从而使获取system权限，我们可以通过如下的脚本执行:

//
# #!/bin/bash 
java -jar signapk.jar   platform.x509.pem platform.pk8 $1 $2

我们来执行一把，生成签名App文件，如下：

在这里插入图片描述

这个命令没有过多好说的，其中的signapk.jar在我们的Android源码中已经有提供了(当然网上也有下载)！

XXX$ find . -name  signapk.jar
./out/host/linux-x86/framework/signapk.jar
./prebuilts/sdk/tools/lib/signapk.jar

这里需要注意的是上述公私钥的位置不要搞错了，否则会报下述的错误!
在这里插入图片描述

4.4 查看apk的签名信息

上述签名也成功了，但是我们怎么验证签名成功了呢，好吗这个已经有命令可以进行相关的验证，如下：

keytool -printcert -jarfile xxx.apk

对我们签名的签名Apk验证一把，得到如下信息:
在这里插入图片描述

和我们前面生成的签名文件信息匹配上了！

写在最后

普法Android系统各类签名以及关联Key知识的就到这里告一段落了，通过这篇博客的学习我想读者对于Android的签名以及各关联的key应该有了一个基本的了解了，但是这是远远不够的因为Android的签名和验证还牵涉到很多相关的知识，这个就在于读者更加深入的阅读和学习了，正如标题所说本篇博客只是起到一个普法的作用罢了。好了，最后欢迎读者点赞和评论，青山不改绿水长流各位江湖见！

对于有想更加深入的可以参见如下博客:
Android签名文件转化为pk8和pem的实现
 Android应用程序签名详解
 详解Android v1、v2、v3签名