加密和解密技术基础、PKI及创建私有CA

时间：2017-03-22 23:46:04 阅读：677 评论：0 收藏：0 [点我收藏+]

一、数据加密和解密概述

数据加密和解密是一门历史悠久的技术，从古代就已经出现了，一直发展到当代。其中，数据加密的目的有很多，可以是为了保证本地数据存取的安全性，可以是为了保证数据流在网络传输过程中的保密性，也可以是为了验证数据的完整性，还可以通过数据加密来实现密钥的交换等。

数据加密依赖于某种加密算法和加密密钥，而数据解密则依赖于某种解密算法和解密密钥。而在当代加密解密技术中，加密密钥既可以与解密密钥相同，也可以和解密密钥不同，这取决于使用什么方法进行加解密。

二、安全的目标

就信息传输过程来说，安全目标有以下三个要点：
(1)保密性：确保通信双方之间的通信数据不会被无关的第三方所窃取，这是最基本的要求。

(2)完整性：确保通信时数据不会丢失或被第三方篡改、破坏，一旦数据丢失或被篡改时，通信的一方能够立即发现。

(3)可用性：确保授权用户能够按需合法访问资源。

三、安全攻击类型

对应于以上的安全目标，分别有以下三种攻击类型：

(1)威胁保密性的攻击：窃听/窃取、通信量分析；

(2)威胁完整性的攻击：篡改、伪装、重放、否认；

(3)威胁可用性的攻击：拒绝服务(Dos)、分布式拒绝服务(DDos)；

四、安全防范的解决方案

为了防范安全攻击，可以分别从技术层面上和服务层面上防范：

(1)技术层面：提供加密和解密技术。这个层面解决了本地数据存储加密和通信过程中数据加密的一系列问题，可分为传统加密算法和现代加密算法：

①传统加密算法：替换加密算法、置换加密算法；

②现代加密算法：现代块加密方法

(2)服务层面：提供用于抵御攻击以及为了达到上述安全目标而特地设计的服务。在这一层面上主要有认证机制和访问控制机制：

①认证机制：确定访问资源的用户是谁、通信对方的身份是否为期望的另一方等；

②访问控制机制：确定某个用户是否有权限访问资源；如果有权限访问资源，再进一步确定用户所能够访问的资源以及对资源能够执行的操作（查看、使用、修改、创建等）；

在以上技术和服务这两个层面中会用到的密钥算法和协议有对称加密、公钥加密（非对称加密）、单向加密以及认证协议。接下来介绍在实现安全通信过程中所用到的加密算法以及它们的实现。

五、加密算法和实现

1、对称加密

(1)特点：加密和解密使用同一个密钥；通信时，双方要想实现基于对称加密算法来实现通信需要预先共享密钥。

(2)用途：用于实现数据保密性。

(3)常见算法：

①DES：Data Encryption Standard，即数据加密标准。DES算法是以64bits(8Bytes)为块，在加密端把数据分成多块，对每块数据(64bits)进行加密，生成64bits密文；在解密端则把64bits密文转换为64bits明文。各个块之间建立一定的联系，DES使用16个迭代块来完成迭代。其中，加密和解密使用56bits密钥。

②3DES：Triple DES，即三轮DES加密机制。3DES加密次数是DES的三个数量级(10^3)。

③AES：Advanced Encryption Standard，即高级加密标准。AES支持多种变长密钥，如128bits, 192bits, 256bits, 384bits等。

④其它对称加密算法有：Blowfish, Twofish, IDEA, RC6, CAST5等。

注意：DES算法存在缺陷，而且只使用56bits的密钥太短；为了提供更高的安全性，可使用DES的派生算法3DES来进行加密，但3DES算法和DES算法一样存在可被攻击的缺陷。后来DES被AES所替代。

(4)缺陷：

①密钥过多：如果通信是基于C/S模式，则服务器端与每一个客户端之间的通信都必须使用不同的密钥，造成服务器端密钥过多的问题。

②密钥分发困难：对称加密可实现通信时数据加密功能，但问题是双方通信之前必须交互密钥，而密钥在交换过程中也同样保证保密性，这时会造成密钥分发困难的问题，必须依赖于一种安全的方法来实现密钥的交换。

2、非对称加密

(1)特点：也称为公钥加密。加密和解密数据使用不同的密钥，例如用公钥加密的数据只能使用与之配对的私钥进行解密，而用私钥加密则只能使用与之配对的公钥进行解密。相比于对称加密，公钥加密可把公钥直接公开，即使公钥在通信时被窃取，因为没有与之配对的私钥，所以仍然无法解密数据。

①公钥：public key，从私钥中提取产生，可公开给所有人。

②私钥：secret key，通过工具创建生成，由使用者自己留存，必须保证其私密性。

(2)用途：

①数字签名：主要用于让接受方确认发送方的身份。

②密钥交换：通过对方的公钥加密一个对称密钥，并发送给对方，对方通过其私钥解密之后就可以获取对称密钥了。这解决了上述对称加密算法中密钥分发困难这一问题。

③数据加密：这种直接使用公钥加密算法来实现通信时数据的保密性的方式并不常用，因为这种方式要比使用对称加密慢上3个数量级，不推荐。

(3)常见算法：

①RSA：名称由RSA三个提出者(Ron Rivest, Adi Shamir, Leonard Adleman)的姓氏首字母组合而成，这种算法的可靠性由对极大整数做因数分解的难度决定；RSA既能实现数字签名，又能实现加解密。

②DSA：Digital Signature Algorithm，即数字签名算法，又称DSS(Digital Signature Standard, 数字签名标准)；DSA仅能实现数字签名，不能用于加解密。

③其他公钥加密算法有ELGamal等。

(4)缺陷：通信效率低。

3、单向加密

(1)特点：提取数据特征码，只能加密，不能解密，它是基于两个特性。

①定长输出：提取出来的数据量是定长的，与进行加密的数据的量无关。

②雪崩效应：初识条件的微小改变会引起加密结果的巨大变化。

(2)用途：用于实现数据完整性的验证。

(3)常见算法：

①md5：Message Digest 5，即信息摘要，‘5‘是版本号；取出的特征码定长为128bits。

②sha1：Secure Hash Algorithm 1，即安全哈希算法，‘1‘是版本号；取出的特征码定长为160bits。

③其他的单向加密算法还有：sha224、sha256、sha384、sha512 ...分别表示定长输出224bits、256bits、384bits、512bits ...

注意：CentOS 5用户密码加密使用的是md5，CentOS 6/7用户密码加密使用的是sha512.

4、密钥交换(IKE, Internet Key Exchange)

两种实现方式：

①公钥加密：常见的算法有RSA等。

②DH算法：Deffie-Hellman(迪菲-赫尔曼)算法。

③其他用于实现密钥交换的算法有：ECDH(椭圆曲线DH)、ECDHE(临时椭圆曲线DH)等。

以下为DH算法的工作原理图：

以下为更一般的描述：

Alice生成随机自然数a、随机大质数p和原根g；
Alice计算，计算结果为A，并把p,g,A发送给Bob；
Bob生成随机自然数b，根据Alice发过来的p,g，计算，计算结果为B；
Bob把B发送给Alice，并计算，计算结果为K；而Alice计算，计算结果也为K；
Alice和Bob以K值作为密钥进行通信。

注意：在整个密钥协商过程中，p、g、和的值是可以公开给攻击者的，而a,b,K值是不公开的。但即使攻击者知道、p和g的值，也无法计算出a，同理，攻击者无法通过、g和g的值计算出b，更不用说计算出K值(最终Alice和Bob协商好的密钥)了。这个问题就是著名的离散对数问题。

六、一次加密通信的过程

这里以发送方Alice和接收方Bob为例。

加密和发送过程：

1、当发送方Alice有数据要发送给Bob时，为了确保数据能够完整地发送至Bob，首先需要使用单向加密算法去计算出这段要发送的数据的特征码；

2、为了便于Bob收到数据之后可验证身份，发送方Alice使用本地私钥加密这段特征码，并将加密后的特征码附加在数据后面；

3、为了确保通信过程是保密的，发送方Alice生成一个临时的对称密钥，并使用这个对称密钥加密整段数据；

4、发送方Alice获取Bob的公钥，再使用Bob的公钥加密来加密刚才生成的临时的对称密钥，并把加密后的对称密钥附加在整段加密数据后面，而后发送给Bob。

接收和解密过程：

接收和解密的过程和解密发送的过程刚好相反。

1、接收方Bob收到数据之后，先使用自己的私钥去解密这段加密过的对称密钥(由Alice生成)；

2、接收方Bob用解密得到的对称密钥去解密整段（发送方用对称密钥）加密的内容；此时接收方Bob得到Alice发送给自己的数据和加密后的特征码；

3、接收方Bob用对方Alice的公钥去解密这段特征码，如果能解密出来，则发送方的身份得到验证（没错，就是Alice发送的）；

4、接收方Bob再用同样的单向加密算法去计算这段数据的特征码，与解密得到的特征码进行比较，如果相同，则数据完整性得到验证，否则说明数据有可能被篡改或被破坏。

图解加密通信过程：

问题总结：

(1)什么是数字签名？

数字签名就是对数据的特征码进行加密。

(2)如何保证公钥不被篡改？

解决方法：将公钥放在证书中。只要证书是可信的，那么公钥就是可信的。

(3)公钥加密计算量太大，如何减少耗用的时间？

解决方法：每一次对话（session），双方都生成一个临时的“会话密钥”（session key），用来
加密信息。由于“会话密钥”是对称加密，因此运算速度快，比公钥加密快3个数量级，而公钥加密
本身只用于加密“会话密钥”本身，这样就减少了耗用的时间。

七、数字证书认证机构--CA

前面的加密通信过程中能够保证通信过程的保密性、通信数据的完整性，但这是以双方(Alice和Bob)能够在此之前可靠地获取对方的公钥为前提的。如果不能保证能够可靠获取对方公钥，那么就有可能出现中间人攻击（Man-in-the-middle attack，缩写：MITM）。假设这个中间人是Eve，Eve就可以分别与Alice和Bob建立联系，而这时Alice获取的是“假的”Bob公钥，而Bob获取的是“假的”Alice公钥；这时候Alice和Bob在毫不知情的情况下进行通信，但其实他们之间数据包的转发是经由Eve的，如图：

上述的通信过程中缺失的一环在于通信双方不能保证可靠地获取对方的公钥，因此，为了保证可靠地获取通信对方的公钥，于是就有了数字证书认证机构(Certificate Authority，缩写：CA)。CA就是为了能够保证通信双方能够可靠获取对方的公钥，而特地设定的一个双方公信的第三方可信机构。

为了避免出现上述一环的缺失，Alice和Bob可向公信的CA申请有效的证书，并由CA分别颁发给Alice和Bob，其中这个证书中的信息包括了证书拥有者的名称、公钥、证书的有效期等信息，而CA还会提取证书中信息的特征码，并用CA自己的私钥进行加密，再把加密后的特征码附加在证书中最后面。此后，当双方通信时，Alice和Bob双方都把自己的证书发给对方，并都分别使用CA的公钥去解密证书中的特征码，如果能解密，则说明证书的确由他们所信任的CA机构所颁发；接着使用同样的单向加密算法去提取证书中信息的特征码，与解密出来的特征码进行比较，如果两者相同，说明证书内容完整，没有被篡改或破坏，而对方的证书中就有对方的公钥。

但这又引入了一个问题，Alice和Bob如何可靠地获取CA的呢?显然，不能基于网络通信的方式获取CA的公钥（否则又会出现中间人攻击等问题），而应该当面交易。全球有多个CA机构，这些CA的数量是有限、基本固定的；它们彼此之间存在互信链，也就是说CA的信任关系是可以传递的。为了管理方便，全球有一个根CA，它与其他CA是从属关系。

为了解决通信主机能够可靠获取CA的公钥，CA需要自签一份证书，就是CA自签名证书，在证书信息中包括了CA的名称、CA的公钥等，通信主机（这里是Alice和Bob）需要获取CA证书，这样才能获取CA公钥以及其他的CA信息，并能通过CA证书来验证其他通信主机的证书是否可靠。CA证书的获取需要通过当面交易来实现，而微软公司直接在windows操作系统上集成了在全球具有公信力的CA证书，但在Linux中一般不内置CA证书，需要自己通过可靠手段获取。

虽然通过上述手段可以极大地保证通信过程的安全性，但仍然存在问题，例如在这整个通信过程中使用的某种算法出现漏洞依然不够安全。

八、公钥基础设施--PKI

以上述为例子，如果Alice的私钥丢失或者被窃取，则需要立即向CA机构申请吊销证书，声明证书作废，将损失将至最低；为了能够第一时间让其他人知道证书已经吊销，可以通过各种媒体来传播，例如新闻、报纸等。由此可见，CA不单要颁发证书，还需要提供证书吊销列表，公开声明有哪些证书已经吊销及不能再信任。因此，为了可以更好地管理CA，发展出了一套以CA为核心的体系--公钥基础设施（Public Key Infrastructure，缩写为：PKI）。

PKI架构主要包括以下四部分：

①签证机构：Certificate Authority，缩写为CA；负责签署证书；

②注册机构：Registration Authority，缩写为RA；负责接收签署证书的申请；

③证书吊销列表：Certificate Revocation List，缩写为CRL；负责公开所有已经吊销的证书；

④证书存取库：Certificate Repository，缩写为CR；负责将公开所有已申请的证书的相关信息；

为了统一数字证书的格式，国际电信联盟（ITU-T）制定了数字证书标准--X.509，即数字证书的格式遵循X.509标准。在X.509v3版本中，定了数字证书的结构以及认证协议标准。而由X.509v3定义的数字证书应该包括以下几个部分：

1.版本号

2.序列号（标识第几个证书）

3.签名算法

4.发行者名称（CA名称）

5.有效期限

6.主体名称

7.主体公钥

8.发行者的唯一标识

9.主体的唯一标识

10.扩展信息

11.发行者的签名（即CA对整个证书的签名；CA把以上内容进行单向加密，得到特征码；再使用CA自己的私钥对特征码进行加密，并附在证书后面，用来生成发行者数字签名）

另外需要注意的是，数字证书中的序列号、签名算法、发行者的唯一标识等信息是集成于电子芯片中的。

九、总结：CA如何在A和B通信之间发挥作用？

基本过程：

1、首先，在A和B通信之前需要互相发送证书；

2、A和B之间协商通信过程中要使用的加密算法（对称加密、公钥加密、单向加密、密钥交换）；

3、开始验证证书：

1)用CA的公钥去解密CA的签名，如果能解密，则说明证书来源可靠；

2)用同样的单向加密算法计算出证书中信息的特征码，与解密得到的特征码进行比较；如果两者相同，则说明证书完整性可靠；

3)检查证书的有效日期是否在当前时间的合理范围内；如果证书过期了则不会被认可；

4)检查证书的主体名称与期望通信的对方是否一致；如果不一致则不会被认可；

5)检查证书是否被吊销过；如果没有吊销则可使用该证书，否则证书不会被认可。

注意：在每次通信过程中，以上步骤一步也不能少；另外，A和B需要事先获取CA自签名证书，因为持有CA自签名证书是用来验证CA颁发给其他人或主机的证书的前提。

十、SSL/TLS概述

1、为什么需要SSL？

我们知道，服务程序一般都会存在bug，黑客只要找到服务程序的bug就可以基于网络进行攻击。对于这种情况，我们的服务程序逻辑要尽可能做得足够安全，但程序总会有bug，因此需要做好安全防范，解决思路是使用一个监控程序对所有的资源访问做监控，如果攻击者想做一些未经授权的资源访问，则这个监控程序自动报警。通俗地来讲，就是“一旦它把手伸到不该伸的地方就报警”，这是一种辅助机制。但这种辅助机制只能确保本地服务程序不会被违规机制所访问到，不能确保资源在网络传输过程是安全的。

在早期计算机未普及时，使用计算机网络进行通信的主机很少，网络安全不是很受到重视。而在早期设计的一些协议本身就不具备加解密功能，例如http,ftp,smtp,pop3等协议。即便后来随着互联网的发展，网络安全得到越来越多的关注，这些协议也很难在其中添加加解密功能，因为早期的很多协议已经成为了网络通信的公共功能和基础设施，一旦在这些基础协议（例如http）添加上加解密功能，则会牵一发而动全身，各个依赖于这些基础服务程序开发出来的程序势必会受到影响。

因此，网景公司为http协议研发设计了一种可被调用的功能模块，这个功能模块所处的位置在应用层和传输层之间的半层，作为公共功能库，也称为半层库。任何程序在研发时可调用这个半层库以实现加解密和密钥分发的功能，不调用则不使用。这个半层库就是SSL库。

2、SSL是什么？

SSL（Secure Sockets Layer，安全套接字层）是一种安全的加解密协议，它的实现也是需要程序（算法）来实现。ssl是一种公共功能，但ssl本身只是一种规范和协议，需要程序员开发出一种遵循SSL协议规范的程序来实现。对于其他协议和程序也一样，例如httpd、nginx是http协议的服务端程序实现，而各种浏览器如IE、chrome及firefox等则是http协议的客户端程序实现；在Windows界面上的远程终端程序Xshell、在Linux上的ssh程序也是ssh协议的客户端程序实现。而ssl在Linux上的开源实现有Openssl和GPG，其中Openssl是ssl协议和ssl库的实现，而GPG是pgp协议的实现，Openssl和GPG也是密钥算法和协议的实现。

任何一个加密解密库（例如ssl库）要求必须满足以下两个功能：

①实现加解密的基本功能；

②能够基于网络通信方式实现密钥分发。

3、加密通信协议历史

1994年，NetScape公司设计了主要用于Web的SSL 1.0版，但因漏洞太多所以没有发布。
1995年，NetScape公司发布了SSL 2.0版，但同样有很多漏洞。
1996年，SSL 3.0版问世，由NetScape发布，并得到大规模应用。
1999年，IEIF将SSL标准化，发布了SSL的升级版TLS 1.0。
2006年和2008年，TLS进行了两次升级，分别发布了TLS 2.0和TLS 3.0。
截止至2016年1月，TLS 3.0仍然处于草案阶段。

协议：

SSL：Secure Sockets Layer，安全套接字层协议。
TLS：Transport Layer Security，传输层安全协议。

目前应用最广泛的是TLS 1.2版，在主浏览器上都有支持。

TLS 1.0通常被标识为SSL 3.1，TLS 1.1为SSL 3.2，TLS 1.2为SSL 3.3。

4、SSL/TLS分层设计

虽然SSL/TLS主要是为了实现加解密以及密钥分发的功能，但也采用了分层设计规范来对其进行实现，各分层设计如下：

1、最底层：基础算法原语的实现，如aes,rsa,md5等。
2、再上一层：各种算法的实现。
3、再上一层：各种组合算法实现的半成品。
4、最上层：用各种组件拼装而成的各种成品密码学协议软件。

SSL/TLS采用分层设计的好处在于SSL/TLS可以提供诸多应用程序在不同级别进行调用，可以直接调用其软件程序，也可以调用其半成品，甚至可以调用其算法。

5、SSL/TLS协议的基本过程

(1)客户端向服务器端索要并验证证书。
(2)双方协商生成“会话密钥”。
(3)双方采用“会话密钥”进行加密通信。

上面过程的前两步，又称为“握手阶段”(handshake)。

握手阶段的详细过程：

“握手阶段”一共有四个步骤，我们一个个来看。需要注意的是，在“握手阶段”过程中，客户端和服务端之间的通信是明文的。

5.1 客户端发出请求（ClientHello）

首先，由客户端（通常是浏览器）向服务器端发送一个加密通信请求，这个就叫做ClientHello请求。

在这一步中，客户端主要向服务器提供以下信息：

(1)支持的加密通信协议版本，如：TLS 1.2。
(2)客户端生成的一个随机数，稍后用于生成“会话密钥”。
(3)支持的加密算法，如：AES, 3DES, RSA算法。
(4)支持的压缩算法。

这里需要注意的是，客户端向服务器发送的信息中不包括服务器的域名，这是因为从理论上一个服务器只能包含一个网站，否则会分不清客户端请求的是哪个网站的证书，这也是为什么一台服务器上只有一张数字证书的原因。

显然，这对于虚拟主机来说非常不方便，因此TLS协议在2006年时添加了Server Name Indication扩展，允许客户端向服务器提供它所请求的域名。

5.2 服务器回应（ServerHello）

服务器接收到客户端的请求后，就会作出回应，这就叫做ServerHello。服务器的回应应该包括以下内容：

(1)确认使用的加密通信协议版本，如：TLS 1.2。如果浏览器与服务器支持的版本不同，服务器关
闭加密通信。
(2)服务器生成的一个随机数，稍后用于生成“会话密钥”。
(3)确认使用的加密算法，如：AES, 3DES, RSA。
(4)服务器证书。

处理上面这些信息，如果服务器需要确认客户端的身份，就会在这一步中再添加一项请求，即要求客户端提供“客户端证书”。比如，金融机构往往只允许客户连接入自己的网络，在这个网络中创建了其私有CA；并且，金融机构会向正式客户提供一个USB密钥，里面就包含有一张证书。

5.3 客户端回应

客户端收到服务器回应后，首先要验证服务器证书。如果证书不是可信CA机构颁布、或者证书中完整性验证不通过、或者证书已经过期、或者证书持有者与客户端期望通信的主机不一致、或者证书已经吊销，就会向访问者发出一个警告，由其选择是否要继续通信。

如果证书确认无误，就会从证书中取出服务器的公钥，并向服务器发送以下内容：

(1)一个随机数。该随机数用服务器公钥加密，防止被窃听。
(2)编码变更通知，表示随后的信息将用双方商定的加密方法和密钥发送。
(3)客户端握手结束通知，表示客户端握手阶段已经结束。这一项同时也是前面发送的所有内容的
hash值，用来供服务器校验，

在这一步中客户端发送给服务器端的随机数是整个握手阶段中的第三个随机数，又称"pre-master key"。有了它之后，客户端和服务器就同时有了三个随机数，接着双方就用事先商定的加密方法，各自由这三个随机数生成同一把本次通信要用到的“会话密钥”。

至于为什么为什么一定要用三个随机数来生成“会话密钥”：

(1)不管是客户端还是服务器，都要使用随机数，确保每次通信生成的临时“会话密钥”都不相同。
(2)由于SSL协议中的证书是静态的，因此很有必要引入一种随机的因素，来确保通信中使用的“会
话密钥”足够随机，不具有可猜测性。
(3)SSL协议不信任通信双方的主机能够生成真正的随机数，因为如果随机数是软件生成的，那么这
个由软件生成的随机数就有章可循，生成的只是伪随机数，因此为了避免这一情况，就将客户端、
服务端的随机数和pre-master-secret（由客户端生成）这个随机数“合并”、“搅和”起来，通过
密钥生成器生成一个“会话密钥”，使其足够随机，不具有可猜测性。

此外，如果在前一步中，服务器需要向客户端请求证书时，则在这一步中客户端会向服务器发送“客户端证书”。

5.4 服务器的最后回应

服务器收到客户端的发来的第三个随机数"pre-master-secret"之后，计算生成本次会话用到的“会话密钥”。而后，向客户端发送如下内容：

(1)编码变更通知，表示随后的信息将用双方商定的加密方法和密钥发送。
(2)服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的
hash值，用来供客户端校验。

至此，整个握手阶段全部结束。接下来，客户端与服务器进入加密通信。如果是基于HTTPS进行加密通信，握手阶段之后的通信过程就完全使用普通的HTTP协议了，只不过使用“会话密钥”加密内容。

6、SSL/TLS的开源实现

前面提到，SSL/TLS的开源实现为OpenSSL和GPG，这里介绍OpenSSL。

OpenSSL的组件：

OpenSSL是对SSL/TLS协议、SSL/TLS库的实现，其组件包括以下三部分：

①libcrypto库：加密解密库，专门用于实现加密解密功能。

②libssl库：用于实现ssl安全通信机制的库。

③openssl多用途命令行工具：可实现加解密功能，以及模拟ssl实现安全通信功能。

需要注意的是，如果只是使用加解密功能，而不需要实现网络通信，则直接调用libcrypto库即可；如果既要使用加解密功能，又要实现网络安全通信，则可以调用libcrypo库和libssl库。而openssl这个工具则内部封装了libcrypto库和libssl库，可以实现上述加解密和安全通信的功能。libcrypto库和libssl库主要由开发者写程序时调用。

接下来介绍这个openssl多用途命令行工具对上述密钥算法和协议的实现。

openssl有众多子命令，这些子命令可分为三类：

(1)标准命令
(2)信息摘要命令（dgst子命令）
(3)加密命令（enc子命令）

查看：

接下来介绍如何使用openssl命令实现对称加密、单向加密、公钥加密，以及如何生成用户密码和随机数。

对称加密：

(1)对称加密工具：openssl enc, gpg

(2)支持的对称加密算法：des, 3des, aes, blowfish, twofish

使用对称加密算法加解密时，需要使用openssl的子命令enc。这里可查看enc帮助手册：

[root@localhost ~]# whatis enc
enc                  (1ssl)  - symmetric cipher routines
[root@localhost ~]# man enc

这里以/root目录下的test文本文件作为示例吧：

[root@localhost ~]# cat test 
I love you,Bob!

使用算法3des对test文本进行对称加密：

[root@localhost ~]# openssl enc -e -a -des3 -salt -in test -out test.cipher
//加密后输出为test.cipher文本文件。
enter des-ede3-cbc encryption password:    //此处输入密钥，由3des算法结合密钥才能加密。
Verifying - enter des-ede3-cbc encryption password:    //再次确认密钥。
[root@localhost ~]# 
[root@localhost ~]# cat test.cipher    //重新查看加密后的文本。
U2FsdGVkX18R/MdkP4l4Z8Gxrgfdsf6zne+EBjC4zWWunysQw39QYw==    //已加密为密文。

说明（enc子命令）：

-d：表示解密。
-e：表示加密。
-ciphername：表示加密算法的名称。
-salt：表示在加密时添加杂质。
-in：读入指定文件。
-out：输出为指定文件。
-a/-base64：编码为文本格式。没加此选项时，输出为二进制格式（显示为乱码）

也可对刚刚加密的文本进行解密：

[root@localhost ~]# openssl enc -d -a -des3 -salt -in test.cipher -out test.plain
//解密后输出为test.plain文本文件。
enter des-ede3-cbc decryption password:    //输入解密密钥，对称加密时为加密密钥。
[root@localhost ~]# 
[root@localhost ~]# cat test.plain    //查看解密后的文本文件。
I love you,Bob!    //已解密为明文。

单向加密：

单向加密工具：openssl dgst, gpg, md5sum, sha1sum, ...

这里同样只介绍openssl dgst。单向加密需要用到openssl的子命令dgst，可查看其帮助手册：

[root@localhost ~]# whatis dgst
dgst                 (1ssl)  - message digests
dgst [md2]           (1ssl)  - message digests
dgst [md4]           (1ssl)  - message digests
dgst [md5]           (1ssl)  - message digests
dgst [mdc2]          (1ssl)  - message digests
dgst [ripemd160]     (1ssl)  - message digests
dgst [sha1]          (1ssl)  - message digests
dgst [sha]           (1ssl)  - message digests
//根据自己需要选择即可。

单向加密操作：

[root@localhost ~]# openssl dgst -md5 test
MD5(test)= 00843d3c93ab6f87ed642a66960a6815

使用其他工具也能得到相同的加密结果：

[root@localhost ~]# md5sum test
00843d3c93ab6f87ed642a66960a6815  test

公钥加密：

前面提到，公钥加密的用途有三个：数字签名、密钥交换、数据加密解密，它们各自的实现方式如下：

(1)数字签名：

①工具：openssl rsautl, gpg

②算法：RSA, DSA, ELGamal

(2)密钥交换：

①工具：openssl dh, gpg

②算法：RSA, DSA, ELGamal

(3)加密解密：

①工具：openssl rsautl, gpg

②算法：RSA, ELGamal

这里生成本地私钥：

[root@localhost ~]# openssl genrsa 1024
//此处‘1024‘指明生成的私钥长度为1024bits.并使用rsa算法生成私钥。

Generating RSA private key, 1024 bit long modulus
......++++++
..............................................................................................++++++
e is 65537 (0x10001)
-----BEGIN RSA PRIVATE KEY-----
MIICXQIBAAKBgQC9uvCH3FsCZ4+nZJYNYXY8obVWRHFqO4lzunc4KmNuTIh/vwNZ
3BDijEse6gZNRjSyi3S8NcL8X6nX5mbQVYeP/LN1qU61hQZSnISH+ITtzq/fmRZI
ZdaUeHWnwoHh4TS0kbrHvTNrAU/xVmKdLs/bezlWp9JpkqcF3q4rIDADuQIDAQAB
AoGBAJpnBdQq2c2tJdUeIJcnF6fkGcTo0juX1BZgSyFkLaLXmcYMVtfMJdmYPpIb
9aDxX3Vl1ExOnC3yVDAlispEsJpvsFbmqkmDO5xp4ejlHcjHjrkkOYdGX5jM0ziO
ns1yZCa7VW2FgZ1BfGUlPvViuf/JwoCl+FF6MCTiA9qYnEMBAkEA6npEERTfZtRN
/3RhoLeEnU+tGspuL302AMCwZiaxdz2+oERVrLxzoyh8q9NjDyVNrBJfrfqf8/Fd
8KnRb0vq0QJBAM8lNDXoaMv8eLn8aKAOsz/fvOZdiat2pJylqsEl/vCksabymMHH
VTOKvBJmoEmBZZPGiqYM72cUgdsaCJbGdGkCQQDB/N2LdEVPgZ32FocevDXPIDgK
zidSyrh+7uwB10lDaaXoWiC3hEH3XmumjICL60TTc3ANNChZXftmPFi1R43BAkBq
q/kADcfxy/kLpdznF8rdCMXJR7/+iWFpvbJ6NqvblqRZmbJqj9Djcv046JqAX99E
Q0jhC+Y5Cgl5ICXuJxKJAkB+oRerGIBLzhKA2PiR05HqBZ9Uylg7GtVaCBhlbMUK
Nqvni0dpY7b7uv8F0Xpu9CvT3ybVjZJFqiL1MVcmj3Rq
-----END RSA PRIVATE KEY-----

可以直接将生成的私钥通过重定向的方式导入文件，但openssl支持通过-out选项直接将生成的私钥导出为指定文件，效果和重定向一样，这里直接使用-out选项作为示例：

[root@localhost ~]# openssl genrsa -out /tmp/private.key 512
Generating RSA private key, 512 bit long modulus
.......++++++++++++
....++++++++++++
e is 65537 (0x10001)
[root@localhost ~]# 
[root@localhost ~]# 
[root@localhost ~]# cat /tmp/private.key    //查看生成的private.key文件。
-----BEGIN RSA PRIVATE KEY-----
MIIBPAIBAAJBAOM4bUGEPA24bcWsB4qShkfddp/ChBAQ1REkuLASvs/c7wpjmhti
C9+NS7hP1PIUL4drrGbu2PjxMhkqAmaahScCAwEAAQJAWViUzZBbtOFyeKn+hSS8
nIGe5Y8tMswLnCQeY03brgvqVY//JG8QRG9sIxRpD0saupLv5n8KI7hbt5Btin/r
kQIhAPXMzCUmODyrd5Nv/oyeVPUrWoPgisziUWnpMZy+qrNbAiEA7KZA2FBGteBs
axwlNrobCb7k4zX+yxKQ7R91YEhMGyUCIQDJyn8SRIVIsZAyd3Anq1ieCiB+QdpR
h79EztAPGaz0HwIhAJp+Wz0dA1y/e+hdQoo862PsZP9Ug9fNciHr9LP73vulAiEA
vVT+5vLL/6h31qIltgNn8Qdpd4DhMEn3aNQfj/eAPFs=
-----END RSA PRIVATE KEY-----

但是！这样会出现一个问题，我们不妨查看以下这个生成的私钥文件的属性：

[root@localhost ~]# ll /tmp/private.key
-rw-r--r--. 1 root root 497 Mar  6 00:44 /tmp/private.key

一般生成的本地私钥仅自己可见，且一般不放在/tmp目录下（这里仅作为演示）。

所以我们可以在输出私钥时直接设置好权限，如下：

[root@localhost ~]# (umask 077; openssl genrsa -out /tmp/private2.key 512)
Generating RSA private key, 512 bit long modulus
..............++++++++++++
.........++++++++++++
e is 65537 (0x10001)
[root@localhost ~]# 
[root@localhost ~]# ll /tmp/private2.key 
-rw-------. 1 root root 497 Mar  6 00:51 /tmp/private2.key    //仅用户自己能访问。

注意：这里使用了‘umask 077‘，将权限掩码设置为‘077‘，这样生成的私钥文件的权限就是‘600‘了。这里还需要注意的是，在命令两端用小括号括起来表示调用子shell执行括号中的命令，执行结束后即退出子shell，因为在子shell中设置的权限掩码不会改变当前shell的权限掩码。

因此，生成本地私钥的格式为：

# (umask 077; openssl genrsa -out /PATH/TO/PRIVATE_KEY_FILE NUM_BITS)

这里/PATH/TO/PRIVATE_KEY_FILE需要根据自己的需要替换为私钥的输出文件，NUM_BITS替换为生成私钥的位长。

我们前面提到，公钥是从私钥中提取得到，这里就直接提取刚才生成的私钥为例：

[root@localhost ~]# openssl rsa -in /tmp/private2.key -pubout
//其中-pubout选项表示提取出公钥。
writing RSA key
-----BEGIN PUBLIC KEY-----
MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBAMeCHQUzzvDOqXvwsywlTW6LagW5Wz9U
0x5liKDtX//NJ2wHAmR/6kufaW+yw2pzBd7kFgrJTHTRkt4AnfZtsgECAwEAAQ==
-----END PUBLIC KEY-----

生成用户密码：

用户密码的生成工具有：passwd, openssl passwd

这里可以查看openssl的子命令passwd的帮助手册：

[root@localhost ~]# whatis passwd
passwd               (1)  - update user‘s authentication tokens
passwd               (5)  - password file
passwd [sslpasswd]   (1ssl)  - compute password hashes
//此处标识为‘1ssl‘的第三项即为openssl的子命令passwd的帮助手册。
[root@localhost ~]# man sslpasswd

使用openssl生成用户密码格式如下：

# openssl passwd -1 -salt SALT

这里‘SALT‘根据自己的需要进行替换。

示例：

[root@localhost ~]# openssl passwd -1 -salt hello1234
Password: 
$1$hello123$281DIFsN1M4.qkU0KTrJN.

需要注意的是，这里的‘-1‘表示使用md5算法进行单向加密，目前openssl还不支持使用sha512进行单向加密，因此不能使用‘-6‘标识sha512算法并使用之进行加密。

生成随机数：

随机数生成工具有：openssl rand

语法格式：

# openssl rand -hex NUM    //采用16进制编码输出。
# openssl rand -base64 NUM    //采用文本编码输出。

这里的‘NUM‘表示生成的随机数的字节数，可根据自己的需要进行替换。

生成8个16进制随机数：

[root@localhost ~]# openssl rand -hex 4
7a3df49f

产生base64编码的100位随机数：

[root@localhost ~]# openssl rand -base64 100
U5lwC1cgtgfNJ9s55jU6xR0rpTsErzJ4mZUsR+kVrASZsvNyTP/q/7/E1sG8bRqc
3ZYCKISsK60Au5tnX16WgKRLr533axQgur7z/JhxEezcnc4wqSHsaq6nqvVBT3H9
oQTEzA==

以8个16进制随机数作为salt设置密码：

[root@localhost ~]# openssl passwd -1 -salt $(openssl rand -hex 4)
Password: 
$1$9a9222ab$gMoHzmXOgGRMdTE54w5Jz0

借助‘openssl rand‘来生成密码是常用的技巧。

这里介绍一下Linux系统上的随机数生成器：

/dev/random：仅从熵池返回随机数，一旦熵池中的随机数用尽，则会阻塞，导致程序无法取随机数。
/dev/urandom：从熵池中返回随机数，一旦熵池中的随机数用尽，则会利用软件生层伪随机数，不
会导致阻塞；伪随机数不安全。

这里的熵池就是运行中的内核维护的一段内存空间，在这片内存空间中存放了大量随机数，而在系统刚启动时为空。熵池中随机数的来源主要有：

(1)硬盘IO中断时间间隔：当发生IO操作时，各个IO操作之间的时间差即作为随机数，放在内存中。
(2)键盘IO中断时间间隔：键盘的两次击键之间的时间差作为随机数，放在内存中。

因此由硬件产生的随机数不具有可猜测性，相对于软件产生的伪随机数更安全。在安全性要求较高时不会使用/dev/urandom生成，因为有可能会生成伪随机数，而伪随机数不安全。

需要注意的是，一旦程序取了内存中的某个随机数，则相当于“剪切”了内存中的这个随机数（保证两个程序取到的随机数不同）。容易想到，如果程序取内存中随机数的速度比生成随机数的速度块时，则有可能耗尽内存中的随机数，在这种情况下就可能造成阻塞，程序需要等待熵池中的随机数的生成。

如果阻塞了应该如何解决？方法之一自然是快速敲键盘以产生大量随机数，而另一种方法是增加IO操作数，例如复制一个大文件至另外路径下（会产生大量IO操作），第二种方法产生随机数的速度要快得多。

通过openssl构建和管理私有CA：

CA有两种，一种是公共信任的CA，另一种是私有CA。私有CA可用于实现小范围内的证书验证。

建立私有CA的工具有openssl和OpenCA，OpenCA是openssl的二次封装，更为人性化。但熟练掌握openssl创建和管理私有CA能帮助我们更好地理解CA背后的工作机制，因此这里介绍openssl创建和管理私有CA。

当openssl命令基于CA工作时，配置文件为：/etc/pki/tls/openssl.cnf.

这里介绍以下配置文件中的一些配置项：

[ ca ]        //openssl子命令ca。
default_ca = CA_default    //默认CA配置项为CA_default。

[ CA_default ]        //CA的默认工作环境定义。
dir = /etc/pki/CA    //证书的工作目录。
certs = $dir/certs    // 已签署证书的存放目录。
crl_dir = $dir/crl    //吊销证书的存放目录。
database = $dir/index.txt    //数据库，存放当前已颁发证书的索引。

new_certs_dir = $dir/newcerts    //该目录的每个文件存放对应证书的详细信息。

certificate = $dir/cacert.pem    //CA证书。
serial = $dir/serial    //该文件存放当前要申请的证书的序列号，如果要申请证书，则使用该
                          序列号。
crlnumber = $dir/crlnumber    //该文件存放当前要吊销的证书的序列号，如果要申请证书，则
                                使用该序列号。

crl = $dir/crl.pem    //当前吊销的证书。
private_key = $dir/private/cakey.pem    //CA的私钥。

default_days = 365    //证书的有效期限。
default_crl_days = 30    //CRL的有效期限。
default_md = sha256    //默认的消息摘要算法。

[ req ]    //openssl的子命令req，用于生成证书签署请求。

构建私有CA时，在确定配置为CA的服务器上生成一个自签证书，并为CA提供所需要的目录及文件即可。步骤如下：

(1)生成私钥。

(2)生成自签证书。

(3)为CA提供所需的目录及文件。

下面一步步进行演示和说明。

(1)生成私钥。

[root@www ~]# (umask 077; openssl genrsa -out /etc/pki/CA/private/cakey.pem 4096)
Generating RSA private key, 4096 bit long modulus
....................++
....................................................++
e is 65537 (0x10001)

需要注意的是，这里生成的私钥文件名为cakey.pem，这个文件名必须和配置文件中的定义保持一致，并保证生成出来的私钥文件的权限符合要求。

[root@www ~]# ll /etc/pki/CA/private/cakey.pem 
-rw-------. 1 root root 3243 Mar 22 09:15 /etc/pki/CA/private/cakey.pem

(2)生成自签证书。

[root@www ~]# openssl req -new -x509 -key /etc/pki/CA/private/cakey.pem -out /etc/pki/
CA/cacert.pem -days 3655
//如果是生成证书签署请求，则不用加上-x509选项，如果是CA为自己颁发自签证书，则需要加上
-x509选项。
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter ‘.‘, the field will be left blank.
-----
Country Name (2 letter code) [XX]:CN    //国家名（2个字符）。
State or Province Name (full name) []:Guangdong    //省名。
Locality Name (eg, city) [Default City]:Guangzhou    //城市名。
Organization Name (eg, company) [Default Company Ltd]:iTab   //公司名，这里以iTab示例。
Organizational Unit Name (eg, section) []:Ops    //单位名。
Common Name (eg, your name or your server‘s hostname) []:ca.iTab.com
//如果是个人之间通信，则填写证书持有者名称；如果是服务器之间通信，则填写服务器主机名。
Email Address []:caadmin@iTab.com    //邮箱名，可不填写。

这里需要注意的是，我们知道证书中存放的是公钥，但这里-key选项接着的是私钥文件路径，这是怎么回事呢？其实，这个命令在生成自签证书时会自动从私钥中提取出公钥，并放入证书中。

各选项的意义：

-new：生成新证书签署请求。
-x509：生成自签格式证书，专用于创建私有CA时。
-key：生成请求证书用到的私钥文件路径。
-out：生成的请求文件路径；如果是自签操作，则直接生成签署过的证书。
-days：证书的有效时长，单位是day。

(3)为CA提供所需的目录及文件。

创建所需的目录及文件：

[root@www ~]# mkdir -pv /etc/pki/CA/{certs,crl,newcerts}
[root@www ~]# touch /etc/pki/CA/{serial,index.txt}

需要注意的是，这里创建的文件有可能是系统上默认就存在的，如果不存在则创建。

serial这个文件需要给明第一个证书的号码是多少：

[root@www ~]# echo 01 > /etc/pki/CA/serial

这里表示一旦要为其他服务器主机签署证书时，这个要申请的证书的序列号为01，此后会自动递增。

要用到证书进行安全通信的服务器，需要向CA请求签署证书。步骤如下：

(1)用到证书的主机生成私钥。

(2)生成证书签署请求。

(3)将证书签署请求通过可靠方式发送给CA主机。

(4)在CA主机上签署证书，并通过可靠方式将签署证书发送给申请证书签署请求的主机。

这里以httpd服务器为例，若要基于https进行加密通信时，需要在Web服务器上做如下操作：

(1)Web服务器主机生成私钥。

这里将生成的私钥放置于/etc/httpd/ssl目录下：

[root@www ~]# mkdir /etc/httpd/ssl
[root@www ~]# (umask 077; openssl genrsa -out /etc/httpd/ssl/httpd.key 2048)
Generating RSA private key, 2048 bit long modulus
...................................................+++
.........................+++
e is 65537 (0x10001)

需要注意的是，这里在Web服务器主机上创建的私钥文件放置目录可根据自己需要存放，这一点和CA主机上的私钥必须存放在/etc/pki/CA/private目录下不同。

(2)Web服务器生成证书签署请求。

[root@www ~]# openssl req -new -key /etc/httpd/ssl/httpd.key -out /etc/httpd/ssl/httpd.
csr -days 365
//这里申请签署1年期限的证书；由于不是生成自签证书，因此不需要加上‘-x509‘选项。
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter ‘.‘, the field will be left blank.
-----
Country Name (2 letter code) [XX]:CN
State or Province Name (full name) []:Guangdong
Locality Name (eg, city) [Default City]:Guangzhou
Organization Name (eg, company) [Default Company Ltd]:iTab
Organizational Unit Name (eg, section) []:Ops
Common Name (eg, your name or your server‘s hostname) []:www.iTab.com
Email Address []:webmaster@iTab.com

Please enter the following ‘extra‘ attributes
to be sent with your certificate request
A challenge password []:    //挑战式密码。
An optional company name []:

这里最后要求输入的挑战式密码的作用在于，如果此处的Web服务器主机向CA服务器基于网络发送证书签署请求时，一旦被窃取，则会要求窃取者输入挑战式密码才可以查看证书请求中的信息。这两个密码可以不填写。

这里需要注意的是，由于刚才创建的CA是私有CA，而私有CA是在小范围内进行通信的，因此Web服务器主机和CA服务器主机最好在同一地域、同一公司、同一单位内，否则有可能会出错。

(3)通过可靠方式将Web服务器的证书签署请求发送给CA主机。

这一步需要注意的是，一般是CA机构当面来到申请的服务器上拷贝证书签署请求（例如U盘拷贝），而不使用网络传输的方式。但这里仅是作为实验环境，因此直接用远程复制工具scp将Web服务器主机上的证书请求发送至CA主机上：

[root@www ~]# scp /etc/httpd/ssl/httpd.csr root@10.10.10.140:/tmp/
root@10.10.10.140‘s password: 
httpd.csr                            100% 1054     1.0KB/s   00:00    
[root@www ~]#

(4)在CA主机上签署证书，并通过可靠方式将签署证书发送给Web服务器。

CA主机收到了证书签署请求：

[root@www ~]# ls /tmp/httpd.csr 
/tmp/httpd.csr

为Web服务器主机签署证书：

[root@www ~]# openssl ca -in /tmp/httpd.csr -out /etc/pki/CA/certs/httpd.crt -days 365
//CA签署的证书必须存放在/etc/pki/CA/certs目录下。
Using configuration from /etc/pki/tls/openssl.cnf
Check that the request matches the signature
Signature ok
Certificate Details:
        Serial Number: 1 (0x1)
        Validity
            Not Before: Mar 22 05:13:01 2017 GMT
            Not After : Mar 22 05:13:01 2018 GMT
        Subject:
            countryName               = CN
            stateOrProvinceName       = Guangdong
            organizationName          = iTab
            organizationalUnitName    = Ops
            commonName                = www.iTab.com
            emailAddress              = webmaster@iTab.com
        X509v3 extensions:
            X509v3 Basic Constraints: 
                CA:FALSE
            Netscape Comment: 
                OpenSSL Generated Certificate
            X509v3 Subject Key Identifier: 
                23:3C:F0:B2:F6:D4:D3:6E:57:30:86:09:69:A4:57:E7:84:1E:8A:98
            X509v3 Authority Key Identifier: 
                keyid:8F:34:8D:89:F1:D4:57:88:55:99:0D:15:35:02:1D:B4:F8:11:CA:28

Certificate is to be certified until Mar 22 05:13:01 2018 GMT (365 days)
Sign the certificate? [y/n]:y    //询问是否签署证书。

1 out of 1 certificate requests certified, commit? [y/n]y    //询问是否确定签署证书。
Write out database with 1 new entries
Data Base Updated    //证书签署成功。
[root@www ~]#

接着将证书通过可靠方式发送给Web服务器主机，这里在实验环境下同样使用scp命令即可：

[root@www ~]# scp /etc/pki/CA/certs/httpd.crt root@10.10.10.139:/etc/httpd/ssl/
root@10.10.10.139‘s password: 
httpd.crt                         100% 5865     5.7KB/s   00:00    
[root@www ~]#

在Web服务器主机上查看：

[root@www ~]# cd /etc/httpd/ssl/
[root@www ssl]# ls
httpd.crt  httpd.csr  httpd.key
[root@www ssl]# 
[root@www ssl]# rm -f httpd.csr
//因为已经有了已签署的证书httpd.crt了，所以这里把httpd.csr这个证书请求删除了。

此外，如果有需要还可以在Web服务器主机或CA服务器主机上查看证书中的信息，这里在Web服务器主机上查看证书信息：

[root@www ssl]# openssl x509 -in /etc/httpd/ssl/httpd.crt -noout -serial -subject
serial=01
subject= /C=CN/ST=Guangdong/O=iTab/OU=Ops/CN=www.iTab.com/emailAddress=webmaster@iTab.com