非对称加密算法的两种应用：签名与加密

Posted 2023-04-28 博发子

非对称加密的特点在于：

首先：有一对私钥和公钥，其中私钥加密的东西，只能对应公钥解密。反之，公钥加密的东西，只能对应私钥解密。

换种角度讲，私钥可以用来加密、用来解密（与之相对的公钥可以用来解密、用来加密）。

其次：公钥可以公开传播，私钥需要私密保存。

利用这两点我们可以实现加密通信与数字签名，我们举例来说明一下过程：

 

对称/非对称加密证书详细介绍https加密通信Android打包签名讲解

概述

本文记录加密、签名、证书等基础知识。并梳理应用证书、加密方式的具体案例，如https加密、Android打包签名等内容

基础知识

加密算法

加密算法主要有非对称加密和对称加密两种算法

• 对称加密算法

指的就是加密和解密使用同一个秘钥，所以叫做对称加密。对称加密只有一个秘钥，作为私钥。常见对称加密算法：DES，AES，3DES

• 非对称加密

非对称加密指的是：加密和解密使用不同的秘钥，一把作为公开的公钥，另一把作为私钥。公钥加密的信息，只有私钥才能解密。私钥加密的信息，只有公钥才能解密。 好多同学理解只能使用公钥加密，使用私钥解密。其实并不是这样。可以使用公钥加密，私钥解密。也可以使用私钥加密 ，公钥解密。二者并没有绝对的界限，公布出去的是公钥，另一个便是私钥 常见算法：RSA,ECC

摘要算法

摘要算法又叫Hash算法，它表示输入任意长度的数据，输出固定长度的数据，相同的输入数据始终得到相同的输出，不同的输入数据尽量得到不同的输出。不可逆，不能从摘要推算出原消息 用于验证信息的完整性，验证是否被篡改过

分类

摘要算法分为三类

• MD(Message Digest)：消息摘要

生成的摘要都是128位的，我们经常使用的MD5算法就是消息摘要的一种，从安全性上来说MD5>MD4>MD2

应用举例：
数据库不能存储用户明文密码，否则有泄漏安全隐患。存储的是密码的MD5值。登录时计算用户输入密码的MD5值与数据存储的MD5值进行比较，如果相同，则说明口令正确，反之则说明口令错误。

• SHA(Secure Hash Algorithm)：安全散列

SHA（Secure Hash Algorithm）是由美国专门制定密码算法的标准机构——美国国家标准技术研究院（NIST）制定的，SHA系列算法的摘要长度分别为：SHA为20字节（160位）、SHA256为32字节（256位）、 SHA384为48字节（384位）、SHA512为64字节（512位）。它产生的数据摘要的长度更长，因此更难以发生碰撞，因此也更为安全，它是未来数据摘要算法的发展方向。由于SHA系列算法的数据摘要长度较长，因此其运算速度与MD5相比，也相对较慢。

• MAC(Message Authentication Code)：消息认证码

稍后详细了解：
https://www.cnblogs.com/foxclever/p/8593072.html

数字签名

什么是数字签名？了解了上述基础知识，我们就可以学习数字签名的概念。数字签名是只有信息的发送者才能产生的别人无法伪造的一段数字串，这段数字串同时也是对信息的发送者发送信息真实性的一个有效证明。 听上去和手写的签名有同样的功效，那么数字签名的原理是什么？他如何保证有效证明的呢？

数字签名原理

数字签名技术使用消息摘要技术+非对称加密算法技术：

1. 首先对原文进行摘要计算，生成信息摘要。
2. 再对信息摘要使用私钥进行加密
3. 连同原文一起发送给接收者。
4. 发送的途中是凶险未知的，原文内容有可能被篡改的。
5. 接收者收到信息后，首先使用公钥对签名进行解密，得到信息摘要。注意这个信息摘要一定是【原文】的摘要。
6. 对内容进行摘要计算，与第【5】步得到的摘要进行对比。如果比对结果一致，则说明收到的信息是完整的，在传输过程中没有被篡修改的，否则信息一定被修改过。

数字签名作用

可以解决伪造、抵赖、冒充和篡改问题。数字签名的目的之一就是在网络环境中代替传统的手工签字与印章，有着重要作用。

1. 防冒充（伪造）。私有密钥只有签名者自己知道，其他人不能伪造签名。

2. 可鉴别身份。在数字签名中，客户的公钥是其身份的标志，当使用私钥签名时，如果接收方或验证方用其公钥进行解密能得到结果，那么可以肯定的是签名人就是拥有私钥的那个人，因为私钥只有签名人知道。

比较清晰的参考：
http://www.ruanyifeng.com/blog/2011/08/what_is_a_digital_signature.html

数字证书

下面我们来介绍数字证书，数字签名和数字证书是不同的东西，这里为了区分就叫【证书】。从上述学习中我们可能认为发送方和接收方使用数字签名技术通信已经很安全了。我们举个例子来引出【证书】

为什么需要证书

发送方小明，接收方阿曾。阿曾拥有小明的公钥。小明给阿曾写信时使用私钥对信件内容的信息摘要进行签名(加密)，连同信件内容发送给阿曾。阿曾收到后用小明的公钥进行解密，得到摘要，并使用同一摘要算法对信件内容进行摘要计算，比对两份摘要来判断信件内容是否被篡改。一切看着那么美好。突然有一天，Tony出现了，他想要欺骗阿曾，于是他潜入阿曾家中(电脑)，把小明的公钥替换成了自己的公钥。阿曾此时拥有的是Tony的公钥，但他还以为这时小明的。这时，骗子Tony就可以冒充小明，使用自己的私钥对信件摘要进行签名，发送给阿曾。阿曾使用假的小明(实际是骗子Tony)公钥进行解密，发现两份摘要一样，嗯，这就是小明给我发来的。

后来阿曾发现不对劲，无法确认自己拥有的公钥是否为小明的公钥，这时【证书】可以解决这一疑问。

这就是【证书】的作用：证明公钥的合法性

证书原理

核心就是一句话：对【公钥】进行数字签名。这里我们要引出一个角色，颁发证书的认证中心(certificate authority，简称CA)。他负责审核申请证书的申请者的资质，并对申请者提供的公钥进行签名(加密)后颁发。该证书就是授信的，是不能伪造的，那其中包含的申请者的公钥也必定是申请者的不能伪造的。

流程图

总结

如果理解了基础内容中的签名、证书等内容，流程图应该是能看懂的。从流程图中我们看出，【证书】中包含很多内容，包括申请人信息、申请人公钥、颁布机构信息等，这些内容在传输过程中也担心被篡改，所以证书也需要签名。这要我们理解了【签名】的原理，这些内容就会比较清晰，记住签名就是对内容摘要进行非对称加密

应用实例

上文我们讲述了加解密、签名、证书等内容，本章我们来看一些具体应用案例。

https加密原理

概述

使用http协议进行网络通信，通信内容都是明文的，当有不法者拦截进行攻击时，我们通信的安全就得不到保障。

HTTPS是HTTP over SSL/TLS，HTTP是应用层协议，TCP是传输层协议，在应用层和传输层之间，增加了一个安全套接层SSL/TLS

HTTPS 相比 HTTP 多了一层 SSL/TLS，SSL/TLS层负责客户端和服务器之间的加解密算法协商、密钥交换、通信连接的建立。

本章重要介绍这个加解密算法协商、密钥交换、通信联机的的过程

TLS/SSL中涉及非对称加密，对称加密以及摘要算法以及证书相关的内容

流程

https加密的流程，概括起来就是，使用非对称加密算法协商出对称加密的秘钥，往后的通信使用对称加密方式，进行加密。流程图如下

解读

1. 从图我们可以看出，BS两端首选协商一套算法用于后续加解密，然后通过随机数方式计算对称加密密钥并验证计算正确性。在传递第三个随机数时，客户端使用公钥(验证证书合法性并提取公钥)加密，服务器使用私钥解密。这样二者就都具备了计算对称加密密钥的三个随机数

2. 客户端验证证书的流程和上章中讲解的证书验证流程是一致的：使用CA公钥解密证书签名获得摘要=>使用证书中摘要算法计算摘要=>对比两份摘要验证证书是否被篡改(证书通过网络传输有可能被篡改)=>查看证书是否到期=>查看证书主体信息是否与服务器一致…

3. 随机数生成对称加密密钥是为了增加其随机性

Android打包签名

概述

在开发Android应用时，开发完成后，需要对apk(Android应用打包后的文件)进行签名，因为在安装apk时，Android系统会对apk进行签名验证，没有签名的apk是无法安装的。

平时我们使用AndroidStudio开发时，并没有手动执行签名的操作，其实是AS帮我们做了debug签名

流程

同样我们使用流程图的方式阐述Android签名的过程

打包签名流程

上图已详细解释了apk打包时的签名流程，我们这里讲解下安装apk时校验签名的过程，其实就是签名流程的反向操作

安装校验流程

1. 计算cert.sf文件的摘要
2. 使用证书中公钥对【CRET.SF文件签名】进行解密出CRET.SF文件摘要。
3. 对比上述两份摘要，如果相同，则证明cret.sf文件没有被篡改，cret.sf文件内容可相信
4. 计算manifest.mf文件的摘要，与cert.sf文件主属性中记录的摘要进行对比，如一致则逐一校验mf文件各个条目的完整性；若一致则证明manifest.mf文件可信
5. 逐一计算apk每个文件的摘要，与manifest.mf中作对比，若一致，则表明apk内的文件没有被篡改，继续安装。

理解

从签名过程看出，是逐渐签名，逐渐加密的过程。同样地解密时，也是逐一解密，下一步校验要用到的文件A上一步必须验证A合法后，方能继续验证

签名方式

上述我们概述了整体流程，那么具体操作时，Android打包签名是采用什么方式进行的呢？这里我们理解一个文件：.keystore文件和.jks文件。他们称作秘钥库文件。使用keytool工具可以生成这个文件。生成时需要设置密码，再次打开时需要输入密码。下面我们具体看下这个文件

密钥库文件

从截图中可以看出，密钥库文件记录了密钥的内容以及证书的签名。但其实他包含了的内容不仅仅如此，它包含了私钥、公钥、以及证书的内容，只不过直接查看是查看不到的，需要通过工具提取查看。这里我们只要记住:密钥库文件(.keystore和.jks)包含私钥、公钥、以及证书。打开密钥库文件需要密码。Android打包签名是需要使用密钥库文件

签名配置

有了密钥库文件，Android打包签名时需要的东西就都有了：私钥、公钥、证书。以及打开密钥库所需要的密码:过程概述：采用私钥对摘要进行签名(详细看上一章)；将证书信息写入CRET.RSA文件。在采用gradle方式打包后，签名就变得简单了，只要配置密钥库文件即可。如下：

signingConfigs  
    release  
      keyAlias 'xxx' 
      keyPassword 'xxx' 
      storeFile file('../xxx.keystore') 
      storePassword 'xxx' 
     
    debug  
      keyAlias 'androiddebugkey' 
      keyPassword 'android' 
      storeFile file('./xxx.keystore') 
      storePassword 'android' 

Android签名意义

我们发现Android的证书，是不需要经过CA认证的，开发者可以通过AS提供的工具自行制作证书并签名，那么这种自签名有什么意义呢？

1. 首先他虽然没有经过CA认证，但是仍然可以起到标识开发者身份的作用。换句话说，我不可能做出一个腾讯的签名证书以此来签名自己开发的APP来冒充腾讯

2. 当新版程序和旧版程序的数字证书相同时，Android系统才会认为这两个程序是同一个程序的不同版本。如果新版程序和旧版程序的数字证书不相同，则Android系统认为他们是不同的程序，并产生冲突，会要求新程序更改包名。也就是说别人不能冒充你对你开发的APP进行升级

3. 如果某个权限(permission)的protectionLevel是 signature，则这个权限就只能授予那些跟该权限所在的包拥有同一个数字证书的程序。