Android签名机制之签名过程详解（一）

最新推荐文章于 2024-04-16 14:19:18 发布

墨语梧桐

最新推荐文章于 2024-04-16 14:19:18 发布

阅读量3.7k

点赞数 2

分类专栏：安卓开发文章标签： Android签名机制

安卓开发专栏收录该内容

9 篇文章 0 订阅

订阅专栏

转载自：http://blog.csdn.net/jiangwei0910410003/article/details/50402000

一、前言

又是过了好长时间，没写文章的双手都有点难受了。今天是圣诞节，还是得上班。因为前几天有一个之前的同事，在申请微信SDK的时候，遇到签名的问题，问了我一下，结果把我难倒了。。我说Android中的签名大家都会熟悉的，就是为了安全，不让别人修改你的apk,但是我们真正的有了解多少呢？所以准备两篇文章好好介绍一下Android中签名机制。

在说道Android签名之前，我们需要了解的几个知识点

1、数据摘要(数据指纹)、签名文件，证书文件

2、jarsign工具签名和signapk工具签名

3、keystore文件和pk8文件，x509.pem文件的关系

4、如何手动的签名apk

上面介绍的四个知识点，就是今天介绍的核心，我们来一一看这些问题。

二、准备知识

首先来看一下数据摘要，签名文件，证书文件的知识点

1、数据摘要

这个知识点很好理解，百度百科即可，其实他也是一种算法，就是对一个数据源进行一个算法之后得到一个摘要，也叫作数据指纹，不同的数据源，数据指纹肯定不一样，就和人一样。

消息摘要算法（Message Digest Algorithm）是一种能产生特殊输出格式的算法，其原理是根据一定的运算规则对原始数据进行某种形式的信息提取，被提取出的信息就被称作原始数据的消息摘要。
著名的摘要算法有RSA公司的MD5算法和SHA-1算法及其大量的变体。
消息摘要的主要特点有：
1）无论输入的消息有多长，计算出来的消息摘要的长度总是固定的。例如应用MD5算法摘要的消息有128个比特位，用SHA-1算法摘要的消息最终有160比特位的输出。
2）一般来说（不考虑碰撞的情况下），只要输入的原始数据不同，对其进行摘要以后产生的消息摘要也必不相同，即使原始数据稍有改变，输出的消息摘要便完全不同。但是，相同的输入必会产生相同的输出。
3）具有不可逆性，即只能进行正向的信息摘要，而无法从摘要中恢复出任何的原始消息。

2、签名文件和证书

签名文件和证书是成对出现了，二者不可分离，而且我们后面通过源码可以看到，这两个文件的名字也是一样的，只是后缀名不一样。

其实数字签名的概念很简单。大家知道，要确保可靠通信，必须要解决两个问题：首先，要确定消息的来源确实是其申明的那个人；其次，要保证信息在传递的过程中不被第三方篡改，即使被篡改了，也可以发觉出来。
所谓数字签名，就是为了解决这两个问题而产生的，它是对前面提到的非对称加密技术与数字摘要技术的一个具体的应用。
对于消息的发送者来说，先要生成一对公私钥对，将公钥给消息的接收者。
如果消息的发送者有一天想给消息接收者发消息，在发送的信息中，除了要包含原始的消息外，还要加上另外一段消息。这段消息通过如下两步生成：
1）对要发送的原始消息提取消息摘要；
2）对提取的信息摘要用自己的私钥加密。
通过这两步得出的消息，就是所谓的原始信息的数字签名。
而对于信息的接收者来说，他所收到的信息，将包含两个部分，一是原始的消息内容，二是附加的那段数字签名。他将通过以下三步来验证消息的真伪：
1）对原始消息部分提取消息摘要，注意这里使用的消息摘要算法要和发送方使用的一致；
2）对附加上的那段数字签名，使用预先得到的公钥解密；
3）比较前两步所得到的两段消息是否一致。如果一致，则表明消息确实是期望的发送者发的，且内容没有被篡改过；相反，如果不一致，则表明传送的过程中一定出了问题，消息不可信。
通过这种所谓的数字签名技术，确实可以有效解决可靠通信的问题。如果原始消息在传送的过程中被篡改了，那么在消息接收者那里，对被篡改的消息提取的摘要肯定和原始的不一样。并且，由于篡改者没有消息发送方的私钥，即使他可以重新算出被篡改消息的摘要，也不能伪造出数字签名。
所以，综上所述，数字签名其实就是只有信息的发送者才能产生的别人无法伪造的一段数字串，这段数字串同时也是对信息的发送者发送信息真实性的一个有效证明。
不知道大家有没有注意，前面讲的这种数字签名方法，有一个前提，就是消息的接收者必须要事先得到正确的公钥。如果一开始公钥就被别人篡改了，那坏人就会被你当成好人，而真正的消息发送者给你发的消息会被你视作无效的。而且，很多时候根本就不具备事先沟通公钥的信息通道。那么如何保证公钥的安全可信呢？这就要靠数字证书来解决了。
所谓数字证书，一般包含以下一些内容：
证书的发布机构（Issuer）
证书的有效期（Validity）
消息发送方的公钥
证书所有者（Subject）
数字签名所使用的算法
数字签名
可以看出，数字证书其实也用到了数字签名技术。只不过要签名的内容是消息发送方的公钥，以及一些其它信息。但与普通数字签名不同的是，数字证书中签名者不是随随便便一个普通的机构，而是要有一定公信力的机构。这就好像你的大学毕业证书上签名的一般都是德高望重的校长一样。一般来说，这些有公信力机构的根证书已经在设备出厂前预先安装到了你的设备上了。所以，数字证书可以保证数字证书里的公钥确实是这个证书的所有者的，或者证书可以用来确认对方的身份。数字证书主要是用来解决公钥的安全发放问题。
综上所述，总结一下，数字签名和签名验证的大体流程如下图所示：

3、jarsign和signapk工具

了解到完了签名中的三个文件的知识点之后，下面继续来看看Android中签名的两个工具：jarsign和signapk

关于这两个工具开始的时候很容易混淆，感觉他们两到底有什么区别吗？

其实这两个工具很好理解，jarsign是Java本生自带的一个工具，他可以对jar进行签名的。而signapk是后面专门为了Android应用程序apk进行签名的工具，他们两的签名算法没什么区别，主要是签名时使用的文件不一样，这个就要引出第三个问题了。

4、keystore文件和pk8，x509.pem文件的区别

我们上面了解到了jarsign和signapk两个工具都可以进行Android中的签名，那么他们的区别在于签名时使用的文件不一样

jarsign工具签名时使用的是keystore文件

signapk工具签名时使用的是pk8,x509.pem文件

其中我们在使用Eclipse工具写程序的时候，出Debug包的时候，默认用的是jarsign工具进行签名的，而且Eclipse中有一个默认签名文件：

我们可以看到这个默认签名的keystore文件，当然我们可以选择我们自己指定的keystore文件。

这里还有一个知识点：

我们看到上面有MD5和SHA1的摘要，这个就是keystore文件中私钥的数据摘要，这个信息也是我们在申请很多开发平台账号的时候需要填入的信息，比如申请百度地图，微信SDK等，会需要填写应用的MD5或者是SHA1信息。

5、手动的签名Apk包

1》使用keytool和jarsigner来进行签名

当然，我们在正式签名处release包的时候，我们需要创建一个自己的keystore文件：

这里我们可以对keystore文件起自己的名字，而且后缀名也是无关紧要的。创建完文件之后，也会生成MD5和SHA1的值，这个值可以不用记录的，可以通过命令查看keystore文件的MD5和SHA1的值。

keytool -list -keystore debug.keystore

当然我们都知道这个keytstore文件的重要性，说白了就相当于你的银行卡密码。你懂得。

这里我们看到用Eclipse自动签名和生成一个keystore文件，我们也可以使用keytool工具生成一个keystore文件。这个方法网上有，这里就不做太多的介绍了。然后我们可以使用jarsign来对apk包进行签名了。

我们可以手动的生成一个keystore文件：

keytool -genkeypair -v -keyalg DSA -keysize 1024 -sigalg SHA1withDSA -validity 20000 -keystore D:\jiangwei.keystore -alias jiangwei -keypass jiangwei -storepass jiangwei

这个命令有点长，有几个重要的参数需要说明：

-alias是定义别名，这里为debug

-keyalg是规定签名算法，这里是DSA，这里的算法直接关系到后面apk中签名文件的后缀名，到后面会详细说明

在用jarsigner工具进行签名

jarsigner -verbose -sigalg SHA1withDSA -digestalg SHA1 -keystore D:\jiangwei.keystore -storepass jiangwei D:\123.apk jiangwei

这样我们就成功的对apk进行签名了。

签名的过程中遇到的问题：

1》证书链找不到的问题

这个是因为最后一个参数alias,是keystore的别名输错了。

2》生成keystore文件的时候提示密码错误

这个原因是因为在当前目录已经有debug.ketystore了，在生成一个debug.keystore的话，就会报错

3》找不到别名的问题

这个问题的原因是因为我们在使用keytool生成keystore的时候，起了debug的别名，这个问题困扰了我很久，最后做了很多例子才发现的，就是只要我们的keystore文件的别名是debug的话，就会报这样的错误。这个应该和系统默认的签名debug.keystore中的别名是debug有关系吧？没有找到jarsigner的源码，所以只能猜测了，但是这三个问题在这里标注一下，以防以后在遇到。

注意：Android中是允许使用多个keystore对apk进行签名的，这里我就不在粘贴命令了，我又创建了几个keystore对apk进行签名：

这里我把签名之后的apk进行解压之后，发现有三个签名文件和证书(.SF/.DSA)

这里我也可以注意到，我们签名时用的是DSA算法，这里的文件后缀名就是DSA

而且文件名是keystore的别名

哎，这里算是理清楚了我们上面的如何使用keytool产生keystore以及，用jarsigner来进行签名。

2》使用signapk来进行签名

下面我们再来看看signapk工具进行签名：

java -jar signapk.jar .testkey.x509.pem testkey.pk8 debug.apk debug.sig.apk

这里需要两个文件：.pk8和.x509.pem这两个文件

pk8是私钥文件

x509.pem是含有公钥的文件

这里签名的话就不在演示了，这里没什么问题的。

但是这里需要注意的是：signapk签名之后的apk中的META-INF文件夹中的三个文件的名字是这样的，因为signapk在前面的时候不像jarsigner会自动使用别名来命名文件，这里就是写死了是CERT的名字，不过文件名不影响的，后面分析Android中的Apk校验过程中会说道，只会通过后缀名来查找文件。

3》两种的签名方式有什么区别

那么问题来了，jarsigner签名时用的是keystore文件，signapk签名时用的是pk8和x509.pem文件，而且都是给apk进行签名的，那么keystore文件和pk8,x509.pem他们之间是不是有什么联系呢？答案是肯定的，网上搜了一下，果然他们之间是可以转化的，这里就不在分析如何进行转化的，网上的例子貌似很多，有专门的的工具可以进行转化：

那么到这里我们就弄清楚了这两个签名工具的区别和联系。

三、分析Android中签名流程机制

下面我们开始从源码的角度去看看Android中的签名机制和原理流程

因为网上没有找到jarsigner的源码，但是找到了signapk的源码，那么下面我们就来看看signapk的源码吧：

源码位置：com/android/signapk/sign.java

通过上面的签名时我们可以看到，Android签名apk之后，会有一个META-INF文件夹，这里有三个文件：

MANIFEST.MF

CERT.RSA

CERT.SF

下面来看看这三个文件到底是干啥的？

1、MANIFEST.MF

我们来看看源码：

[java] view plain copy

public static void main(String[] args) {
if (args.length != 4) {
System.err.println("Usage: signapk " +
"publickey.x509[.pem] privatekey.pk8 " +
"input.jar output.jar");
System.exit(2);
}
JarFile inputJar = null;
JarOutputStream outputJar = null;
try {
X509Certificate publicKey = readPublicKey(new File(args[0]));
// Assume the certificate is valid for at least an hour.
long timestamp = publicKey.getNotBefore().getTime() + 3600L * 1000;
PrivateKey privateKey = readPrivateKey(new File(args[1]));
inputJar = new JarFile(new File(args[2]), false); // Don't verify.
outputJar = new JarOutputStream(new FileOutputStream(args[3]));
outputJar.setLevel(9);
JarEntry je;
// MANIFEST.MF
Manifest manifest = addDigestsToManifest(inputJar);
je = new JarEntry(JarFile.MANIFEST_NAME);
je.setTime(timestamp);
outputJar.putNextEntry(je);
manifest.write(outputJar);
// CERT.SF
Signature signature = Signature.getInstance("SHA1withRSA");
signature.initSign(privateKey);
je = new JarEntry(CERT_SF_NAME);
je.setTime(timestamp);
outputJar.putNextEntry(je);
writeSignatureFile(manifest,
new SignatureOutputStream(outputJar, signature));
// CERT.RSA
je = new JarEntry(CERT_RSA_NAME);
je.setTime(timestamp);
outputJar.putNextEntry(je);
writeSignatureBlock(signature, publicKey, outputJar);
// Everything else
copyFiles(manifest, inputJar, outputJar, timestamp);
} catch (Exception e) {
e.printStackTrace();
System.exit(1);
} finally {
try {
if (inputJar != null) inputJar.close();
if (outputJar != null) outputJar.close();
} catch (IOException e) {
e.printStackTrace();
System.exit(1);
}
}
}

在main函数中，我们看到需要输入四个参数，然后就做了三件事：

写MANIFEST.MF

[java] view plain copy

//MANIFEST.MF
Manifest manifest = addDigestsToManifest(inputJar);
je = new JarEntry(JarFile.MANIFEST_NAME);
je.setTime(timestamp);
outputJar.putNextEntry(je);
manifest.write(outputJar);

在进入方法看看：

[java] view plain copy

/** Add the SHA1 of every file to the manifest, creating it if necessary. */
private static Manifest addDigestsToManifest(JarFile jar)
throws IOException, GeneralSecurityException {
Manifest input = jar.getManifest();
Manifest output = new Manifest();
Attributes main = output.getMainAttributes();
if (input != null) {
main.putAll(input.getMainAttributes());
} else {
main.putValue("Manifest-Version", "1.0");
main.putValue("Created-By", "1.0 (Android SignApk)");
}
BASE64Encoder base64 = new BASE64Encoder();
MessageDigest md = MessageDigest.getInstance("SHA1");
byte[] buffer = new byte[4096];
int num;
// We sort the input entries by name, and add them to the
// output manifest in sorted order. We expect that the output
// map will be deterministic.
TreeMap<String, JarEntry> byName = new TreeMap<String, JarEntry>();
for (Enumeration<JarEntry> e = jar.entries(); e.hasMoreElements(); ) {
JarEntry entry = e.nextElement();
byName.put(entry.getName(), entry);
}
for (JarEntry entry: byName.values()) {
String name = entry.getName();
if (!entry.isDirectory() && !name.equals(JarFile.MANIFEST_NAME) &&
!name.equals(CERT_SF_NAME) && !name.equals(CERT_RSA_NAME) &&
(stripPattern == null ||
!stripPattern.matcher(name).matches())) {
InputStream data = jar.getInputStream(entry);
while ((num = data.read(buffer)) > 0) {
md.update(buffer, 0, num);
}
Attributes attr = null;
if (input != null) attr = input.getAttributes(name);
attr = attr != null ? new Attributes(attr) : new Attributes();
attr.putValue("SHA1-Digest", base64.encode(md.digest()));
output.getEntries().put(name, attr);
}
}
return output;
}

代码逻辑还是很简单的，主要看那个循环的意思：

除了三个文件(MANIFEST.MF,CERT.RSA,CERT.SF)，其他的文件都会对文件内容做一次SHA1算法，就是计算出文件的摘要信息,然后用Base64进行编码即可，下面我们用工具来做个案例看看是不是这样：

首先安装工具：HashTab

下载地址：http://www.baidu.com/s?wd=hashtab&rsv_spt=1&issp=1&f=8&rsv_bp=0&ie=utf-8&tn=baiduhome_pg&bs=hashtable

然后还有一个网站就是在线计算Base64：http://tomeko.net/online_tools/hex_to_base64.php?lang=en

那下面就开始我们的验证工作吧：

我们就来验证一下AndroidManifest.xml文件，首先在MANIFEST.MF文件中找到这个条目，记录SHA1的值

然后我们安装HashTab之后，找到AndroidManifest.xml文件，右击，选择Hashtab:

复制SHA-1的值：9C64812DE7373B201C294101473636A3697FD73C，到上面的那个Base64转化网站，转化一下：

nGSBLec3OyAcKUEBRzY2o2l/1zw=

和MANIFEST.MF中的条目内容一模一样啦啦

那么从上面的分析我们就知道了，其实MANIFEST.MF中存储的是：

逐一遍历里面的所有条目，如果是目录就跳过，如果是一个文件，就用SHA1（或者SHA256）消息摘要算法提取出该文件的摘要然后进行BASE64编码后，作为“SHA1-Digest”属性的值写入到MANIFEST.MF文件中的一个块中。该块有一个“Name”属性，其值就是该文件在apk包中的路径。

注：这里增加理解，这是AndroidManifest.xml文件的sha-1 16进制表示，即9C64812DE7373B201C294101473636A3697FD73C ；

将MANIFEST.MF文件中的SHA1-Digest取出来nGSBLec3OyAcKUEBRzY2o2l/1zw=，这是对应AndroidManifest.xml的SHA-1 Base64表示，将其转化成16进制为9C64812DE7373B201C294101473636A3697FD73C，两者相等。

2、下面再来看一下CERT.SF文件内容

这里的内容感觉和MANIFEST.MF的内容差不多，来看看代码吧：

[java] view plain copy

//CERT.SF
Signature signature = Signature.getInstance("SHA1withRSA");
signature.initSign(privateKey);
je = new JarEntry(CERT_SF_NAME);
je.setTime(timestamp);
outputJar.putNextEntry(je);
writeSignatureFile(manifest,new SignatureOutputStream(outputJar, signature));

进入到writeSignatureFile方法中：

[java] view plain copy

/** Write a .SF file with a digest the specified manifest. */
private static void writeSignatureFile(Manifest manifest, OutputStream out)
throws IOException, GeneralSecurityException {
Manifest sf = new Manifest();
Attributes main = sf.getMainAttributes();
main.putValue("Signature-Version", "1.0");
main.putValue("Created-By", "1.0 (Android SignApk)");
BASE64Encoder base64 = new BASE64Encoder();
MessageDigest md = MessageDigest.getInstance("SHA1");
PrintStream print = new PrintStream(
new DigestOutputStream(new ByteArrayOutputStream(), md),
true, "UTF-8");
// Digest of the entire manifest
manifest.write(print);
print.flush();
main.putValue("SHA1-Digest-Manifest", base64.encode(md.digest()));
Map<String, Attributes> entries = manifest.getEntries();
for (Map.Entry<String, Attributes> entry : entries.entrySet()) {
// Digest of the manifest stanza for this entry.
print.print("Name: " + entry.getKey() + "\r\n");
for (Map.Entry<Object, Object> att : entry.getValue().entrySet()) {
print.print(att.getKey() + ": " + att.getValue() + "\r\n");
}
print.print("\r\n");
print.flush();
Attributes sfAttr = new Attributes();
sfAttr.putValue("SHA1-Digest", base64.encode(md.digest()));
sf.getEntries().put(entry.getKey(), sfAttr);
}
sf.write(out);
}

首先我们可以看到，需要对之前的MANIFEST.MF文件整个内容做一个SHA1放到SHA1-Digest-Manifest字段中：

我们看看出入的manifest变量就是刚刚写入了MANIFEST.MF文件的

这个我们可以验证一下：

然后转化一下

看到了吧，和文件中的值是一样的啦啦

下面我们继续看代码，有一个循环：

[java] view plain copy

Map<String, Attributes> entries = manifest.getEntries();
for (Map.Entry<String, Attributes> entry : entries.entrySet()) {
// Digest of the manifest stanza for this entry.
print.print("Name: " + entry.getKey() + "\r\n");
for (Map.Entry<Object, Object> att : entry.getValue().entrySet()) {
print.print(att.getKey() + ": " + att.getValue() + "\r\n");
}
print.print("\r\n");
print.flush();
Attributes sfAttr = new Attributes();
sfAttr.putValue("SHA1-Digest", base64.encode(md.digest()));
sf.getEntries().put(entry.getKey(), sfAttr);
}
sf.write(out);

这里还是用到了刚刚传入的mainfest变量，遍历他的条目内容，然后进行SHA算法计算在Base64一下：

其实就是对MANIFEST.MF文件中的每个条目内容做一次SHA,在保存一下即可，做个例子验证一下：

用AndroidManifest.xml为例，我们把MANIFEST.MF文件中的条目拷贝保存到txt文档中：

这里需要注意的是，我们保存之后，需要添加两个换行，我们可以在代码中看到逻辑：

然后我们计算txt文档的SHA值：

看到了吧，这里计算的值是一样的啦啦

到这里我们就知道CERT.SF文件做了什么：

1》计算这个MANIFEST.MF文件的整体SHA1值，再经过BASE64编码后，记录在CERT.SF主属性块（在文件头上）的“SHA1-Digest-Manifest”属性值值下

2》逐条计算MANIFEST.MF文件中每一个块的SHA1，并经过BASE64编码后，记录在CERT.SF中的同名块中，属性的名字是“SHA1-Digest

3、最后我们在来看一下CERT.RSA文件

这里我们看到的都是二进制文件，因为RSA文件加密了，所以我们需要用openssl命令才能查看其内容

openssl pkcs7 -inform DER -in CERT.RSA -noout -print_certs –text

关于这些信息，可以看下面这张图：

我们来看一下代码：

[java] view plain copy

/** Write a .RSA file with a digital signature. */
private static void writeSignatureBlock(
Signature signature, X509Certificate publicKey, OutputStream out)
throws IOException, GeneralSecurityException {
SignerInfo signerInfo = new SignerInfo(
new X500Name(publicKey.getIssuerX500Principal().getName()),
publicKey.getSerialNumber(),
AlgorithmId.get("SHA1"),
AlgorithmId.get("RSA"),
signature.sign());
PKCS7 pkcs7 = new PKCS7(
new AlgorithmId[] { AlgorithmId.get("SHA1") },
new ContentInfo(ContentInfo.DATA_OID, null),
new X509Certificate[] { publicKey },
new SignerInfo[] { signerInfo });
pkcs7.encodeSignedData(out);
}

我们看到，这里会把之前生成的 CERT.SF文件，用私钥计算出签名, 然后将签名以及包含公钥信息的数字证书一同写入 CERT.RSA 中保存。CERT.RSA是一个满足PKCS7格式的文件。

这个文件保存了签名和公钥证书。签名的生成一定会有私钥参与，签名用到的信息摘要就是CERT.SF内容。
signature这个数据会作为签名用到的摘要，writeSignatureBlock函数用privateKey对signature加密生成签名，然后把签名和公钥证书一起保存到CERT.RSA中。
最终保存在CERT.RSA中的是CERT.SF的数字签名，签名使用privateKey生成的，签名算法会在publicKey中定义。同时还会把publicKey存放在CERT.RSA中，也就是说CERT.RSA包含了签名和签名用到的证书。并且要求这个证书是自签名的。

四、为何要这么来签名

上面我们就介绍了签名apk之后的三个文件的详细内容，那么下面来总结一下，Android中为何要用这种方式进行加密签名，这种方加密是不是最安全的呢？下面我们来分析一下，如果apk文件被篡改后会发生什么。

首先，如果你改变了apk包中的任何文件，那么在apk安装校验时，改变后的文件摘要信息与MANIFEST.MF的检验信息不同，于是验证失败，程序就不能成功安装。
其次，如果你对更改的过的文件相应的算出新的摘要值，然后更改MANIFEST.MF文件里面对应的属性值，那么必定与CERT.SF文件中算出的摘要值不一样，照样验证失败。
最后，如果你还不死心，继续计算MANIFEST.MF的摘要值，相应的更改CERT.SF里面的值，那么数字签名值必定与CERT.RSA文件中记录的不一样，还是失败。
那么能不能继续伪造数字签名呢？不可能，因为没有数字证书对应的私钥。
所以，如果要重新打包后的应用程序能再Android设备上安装，必须对其进行重签名。

从上面的分析可以得出，只要修改了Apk中的任何内容，就必须重新签名，不然会提示安装失败，当然这里不会分析，后面一篇文章会注重分析为何会提示安装失败。

五、知识点梳理

1、数据指纹，签名文件，证书文件的含义

1》数据指纹就是对一个数据源做SHA/MD5算法，这个值是唯一的

2》签名文件技术就是：数据指纹+RSA算法

3》证书文件中包含了公钥信息和其他信息

4》在Android签名之后，其中SF就是签名文件，RSA就是证书文件我们可以使用openssl来查看RSA文件中的证书信息和公钥信息

2、我们了解了Android中的签名有两种方式：jarsigner和signapk 这两种方式的区别是：

1》jarsigner签名时，需要的是keystore文件，而signapk签名的时候是pk8,x509.pem文件

2》jarsigner签名之后的SF和RSA文件名默认是keystore的别名，而signapk签名之后文件名是固定的:CERT

3》Eclipse中我们在跑Debug程序的时候，默认用的是jarsigner方式签名的，用的也是系统默认的debug.keystore签名文件

4》keystore文件和pk8,x509.pem文件之间可以互相转化

六、思考

我们在分析了签名技术之后，无意中发现一个问题，就是CERT.SF，MANIFEST.MF，这两个文件中的内容的name字段都是apk中的资源名，那么就有一个问题了，如果资源名很长，而且apk中的资源很多，那么这两个文件就会很大，那么这里我们是不是可以优化呢？后面在分析如何减小apk大小的文章中会继续讲解，这里先提出这个问题。