安全加密基础—基本概念、keytool、openssl

绿竹痕

已于 2024-01-02 17:37:03 修改

阅读量1.7k

点赞数 29

分类专栏：加密-解密-证书文章标签：安全加密 keytool keystore openssl

于 2024-01-02 17:21:28 首次发布

本文链接：https://blog.csdn.net/jobjava/article/details/135345111

版权

加密-解密-证书专栏收录该内容

3 篇文章 0 订阅

订阅专栏

安全加密基础—基本概念、keytool、openssl

前言

（1）本文不涉及源码、底层。只是讲解大概的密码演变过程和基本概念。能让接触到相关名词的人知道这些名词是干嘛的，为什么要有它。专业人士可以当作概念梳理，非专业人士可以当作科普。

（2）本文你将了解到的概念：明文通信、无密钥密文通信、对称加密、非对称加密、信息摘要、数字签名、CA与数字证书、https、常用的密钥扩展名。

（3）本文应用实践有：用java的Keytool生成密钥，keystore格式转pem，openssl生成私钥和证书。

一、概念

明文通信

不是私密的信息可以采用明文。

无密钥密文通信

对于私密数据，如何远距离传输并且在被其他人看到的情况下，还能保证数据的私密性？

最简单想到的就是通信双方约定好一种加密方式，对要说的话进行加解密，如图：

发送方将要发送的信息进行enc加密，接收方通过dec解密。

比如我要说的话是：123。我们提前约定好我会将我发的数字每位+1，这样我发出去的就是234。你收到我发的信息后，将每一位减1就能得到真实的信息。

为了让偷听者不能从密文中恢复出明文，必须保证算法不被外人所知。如果别人知道了你的加密算法，就能轻而易举破解。这样做有很多弊端，比如：

1. 如果算法泄露，则必须设计新的算法，而设计加密算法并不容易。如果同时有很多用户的使用这套算法，换一套算法就更麻烦。
2. 加密解密的人总要知道算法，所以算法的保密很难做到。
3. 算法被设计出来，肯定需要很多人去测试它的安全性和正确性，这样知道这个算法的人就会很多，无法保证算法不被泄露。

虽然有这些弊端，但事实上人们历来都是这么干的。

直到Auguste Kerckhoffs 在 1883年提出了一条原则：加密算法不应该是秘密，即便落入敌人之手，也不会带来不便 。这条原则被现代密码学广泛接受，并被称为柯克霍夫原则（Kerckhoff’s Principle）。后来，信息论的奠基者香农把这条原则形象地表述为：“敌人知道系统。”通俗的说就是算法不应该是秘密，但是必须有一个秘密信息参与到算法中，才能保证信息的安全性。这个秘密信息就是密钥。

对称加密

通信双方约定好一个密钥，然后用这个密钥进行加密算法。比如我要说的是：123。加密算法会让我发的数字每位+x，这个x具体是多少就是我们通信双方要约定好的密钥了。这样就实现了加密算法是公开的，但是只要密钥不被盗取，信息就不会泄漏。而且如果密钥泄漏，我们可以更改密钥即可。

常见的对称加密有: DES、2DES和3DES，AES。

但是这样又出现了一个问题，就是通信双方如何约定密钥？在网络上，发的任何信息都有可能被劫持，所以对称加密的问题就是通信双发如何能拿到密钥。

非对称加密

对称加密的问题在于互联网环境下没法传递密钥，因为密钥有可能泄漏。

非对称加密有两个密钥，一个公钥一个私钥。私钥只有消息接收者自己持有。公钥加密后只有私钥能解密，私钥加密后只有公钥能解密。

用公钥加密后的信息只有私钥的持有者能解密，如果双方想要用非对称加密进行通信的话，只要双方各持有一个公钥和一个私钥。然后各自用对方的公钥加密要发的数据，就能不被其他人破解。

或者只要A有一个公钥和一个私钥，然后A约定好一个对称加密的密钥，将这个密钥用公钥加密然后发给B，B收到后双方就可以用对称加密来通信。

总结上面这段就是，如果用非对称加密来通信有两种方式：

1一种是通信双方各持有一个公钥和私钥，然后用各自的非对称加密算法来通信。

2另一种是用非对称加密算法来约定对称加密算法中的密钥。之后用对称加密算法来通信。

常见的非对称加密算法有：DSA,ECC,RSA,DH

但是上面存在一个问题，通信双方都是私钥的持有者，来接收公钥加密后的信息，那么怎么保证自己发出的公钥加密信息不会被他人篡改和替换？

数字签名

要想解决自己发出的公钥信息不会被篡改和替换，只要在信息上留下别人无法修改的记号就可以了。这就是数字签名。只要信息发送者在信息中加入用自己私钥加密的一段信息，消息接收者用消息发送者的公钥能解开那段信息，就能保证信息没有被别人替换。那么加密一段什么信息比较好呢？这就要引出消息摘要算法。

发送方：密文(数字签名) = RSA(信息摘要,发送方私钥)

接收方：明文(信息摘要) = RSA(信息摘要,发送方公钥)

消息摘要(MD5)

消息摘要不是加密算法，他是不可逆的。它是对一段信息进行处理然后得到一串定长的消息摘要，同样的信息内容得到的消息摘要是相同的，不同的信息内容得到的消息摘要是不同的。所以一般用消息摘要可以判断信息内容是否被修改，而且因为不管消息内容有多少，得到的消息摘要都是一样长度的。

常见的信息摘要有：MD5、SHA1。

特性：定长，不可逆，相同明文加密后的摘要也相同且恒相同。一般是MD5串

用途：判断信息内容是否被篡改

所以现在是不是能实现完美的加密通信了呢？双发各持有一个公钥和一个私钥。要发消息时，先对消息内容进行消息摘要。在对消息内容用对方的公钥加密。最后再用自己的私钥对消息摘要加密形成数字签名。这样保证接收方收到内容时，内容不会被泄漏伪造和替换。

例如：

发送方（发送方私钥，接收方公钥）

信息明文 = a=1&b=2&c=999.19&d=图书

消息摘要 = md5(a=1&c=999.19) = D08751F4CD7C0376127C19D84220A395

数字签名加密 = RSA( ${消息摘要}, 发送方私钥)【加密】

信息密文：RSA(“a=1&b=2&c=999.19&d=图书”,接收方公钥)【加密】

发送内容：msg=信息密文&sign=数字签名

接收方（接收方私钥，发送方公钥）

接收内容：msg=信息密文&sign=数字签名

信息明文：RSA(${信息密文},接收方私钥)【解密】

a=1&b=2&c=999.19&d=图书

数字签名解密：RSA(${数字签名},发送方公钥)【解密】

摘要 = D08751F4CD7C0376127C19D84220A395

自制摘要：md5(a=1&c=999.19) = D08751F4CD7C0376127C19D84220A395

验证摘要： ${摘要} == ${自制摘要} ===> success

CA数字证书(解决公钥分发的问题)

但是回到非对称加密的起点，公钥怎么公开又是个问题。如果你虽然对外公开了你的公钥。但是你把公钥发给别人的时候被别人替换成他的公钥怎么办？你可能会说，用数字签名。你刚刚才说数字签名和保证内容不被替换和修改。但是数字签名的前提是你要通信的那个人已经拿到了你的公钥，然后你用私钥对消息签名，他才能用你的公钥来判断是不是你的私钥签的名。现在的问题是他怎么能正确的拿到你的公钥，如果你的公钥被别人替换，那么你的后续的数字签名就没有用了。

那么如下图。既然在一开始传递公钥时，小红没法自己签名。那么找一个大家的认可的第三方（CA），把小红的个人信息和公钥告诉第三方，第三方对这些内容进行数字签名（相当于盖了一个公章），形成一个数字证书。然后小明用第三方的公钥如果能解开数字签名（鉴别公章是不是假的），就说明里面的内容是得到权威认证的。而且里面的内容有你的公钥和个人信息，这样小明就得到了小红的公钥，而且这个公钥不可能是被别人替换或者修改过的。

公钥发送方：

公钥=D08751F4CD7C0376127C19D84220A395

个人信息：公司名称，住址，电话

CA机构：

数字签名加密 = RSA( ${公钥}+${个人信息}, CA私钥)【加密】

数字签名: U2FsdGVkX1/BtnM+Wi3cLDD54LjYACXz9M1+nyRLf6rADT5bmS75RdenbUJE80BD

GSW8cz+hZUC96hyc1DEkxi9r0KdmbNrreFbBhAkEGNU=

形成所谓证书，其实就是个数字签名，本质是一串加密字符串

公钥接收方：

接收数字签名：U2FsdGVkX1/BtnM+Wi3cLDD54LjYACXz9M1+nyRLf6rADT5bmS75RdenbUJE80BD

GSW8cz+hZUC96hyc1DEkxi9r0KdmbNrreFbBhAkEGNU=

数字签名解密：RSA( ${公钥}+${个人信息}, CA公钥)【解密】

公钥=D08751F4CD7C0376127C19D84220A395

个人信息：公司名称，住址，电话

成功获得发送方公钥

CA公钥怎么来的？硬件机器内置的。

现在问题来了，上图的第四步，小明在验证小红的证书时。需要验证数字签名确实是权威CA签的，需要用CA的公钥才能解开数字签名。那么小明怎么得到CA的公钥呢？

其实，信任是有起点的。

CA 不仅为他人生成证书，也生成自己的证书，CA 为自己生成的证书里包含了CA的公钥。CA 的证书在电脑、手机等设备出场的时候就会预置在系统里、浏览器里。因此，当小明验证小红的证书时，会在系统里寻找能够解开小红证书的CA 公钥，若是找到则说明小明证书的颁发机构是可信任的，既然信任了该证书，那么从证书里取出的公钥，小明也认可是小红的。如果在本机中没找到对应的公钥，那么小明就会认为这个证书是不可信的，就会提示用户是否要继续访问。

HTTPS

https是应用层协议，它会结合传输层和应用层之前的ssl一起使用，实现加密传输。（ssh也是加密协议，通常用在客户端远程访问）。https大概流程如下：

1客户端通过发送Client Hello报文开始SSL通信。报文中包含客户端支持的SSL的指定版本、加密组件（Cipher Suite）列表（所使用的加密算法及密钥长度等）。

注意：客户端还会附加一个随机数，这里记为A。

2服务器可进行SSL通信时，会以Server Hello报文作为应答。和客户端一样，在报文中包含SSL版本以及加密组件。服务器的加密组件内容是从接收到的客户端加密组件内筛选出来的。

注意：这里服务器同样会附加一个随机数，发给客户端，这里记为B。

3之后服务器发送Certificate报文。报文中包含公开密钥证书。（具体的数字签名请看证书一节）

4最后服务器发送Server Hello Done报文通知客户端，最初阶段的SSL握手协商部分结束。

5 SSL第一次握手结束后，客户端会对服务器发过来的证书进行验证，如果验证成功，解密取出证书中的公钥。（具体查看证书一节）

接着，客户端以Client Key Exchange报文作为回应。报文中包含通信加密中使用的一种被称为Pre-master secret的随机密码串。该报文使用从证书中解密获得的公钥进行加密（其实就是服务器的公钥）。

6客户端继续发送Change Cipher Spec报文。用于告知服务端，客户端已经切换到之前协商好的加密套件（Cipher Suite）的状态，准备使用之前协商好的加密套件加密数据并传输了。

7客户端发送Finished报文。该报文包含连接至今全部报文的整体校验值（也就是HASH值），用来供服务器校验。

8服务器接收到客户端的请求之后，使用私钥解密报文，把Pre-master secret取出来。接着，服务器同样发送Change Cipher Spec报文。

9服务器同样发送Finished报文，用来供客户端校验。

10服务器和客户端的Finished报文交换完毕之后，SSL连接就算建立完成。当然，通信会受到SSL的保护。从此处开始进行应用层协议的通信，即发送HTTP请求。

11应用层协议通信，即发送HTTP响应。

12最后由客户端断开连接。断开连接时，发送close_notify报文。上图做了一些省略，这步之后再发送TCP FIN报文来关闭与TCP的通信。

相关文件扩展名

私钥、公钥、证书这三个相关的文件一般有以下扩展名：

常用后缀名

证书(Certificate) - *.cer *.crt

私钥(Private Key) - *.key

证书签名请求(Certificate signing request) - *.csr

证书吊销列表(Certificate Revocation List) - .crl

X.509是常见通用的证书格式。所有的证书都符合为PublicKeyInfrastructure(PKI)制定的 ITU-T X509 国际标准。

pem(base64)和der(二进制)是证书的编码方式，以.pem结尾的文件既可以是证书也可以是私钥。（X.509是证书的内容格式，pem是编码方式）

.jks和.p12是是一种容器格式，可以同时保存多个证书和私钥。

注意，后缀名只是一种命名规范，只是让使用者能知道这个文件代表这什么。

普通的pem文件内容

-----BEGIN PRIVATE KEY-----

ksldfjs

ksdjflsdf

...

....

sfjlskjdfljf

ksdfjlsdkf

-----END PRIVATE KEY-----

二、keytool

在java中，jdk提供了管理公钥、私钥和证书的工具keytool。Keytool将密钥（key）和证书（certificates）存在一个称为keystore的文件中。也就是说，在keystore里只包含两种数据：

密钥实体：如果采用非对称加密形式，则包含私钥和配对公钥，否则只包括密钥。
可信任的证书实体：只包含公钥

keystore文件俗称密钥库，可以保存多个密钥和证书，密钥库的默认格式为jks，命名一般叫xxx.keystore。

keystore（密钥库）是一个用于存储密钥对、数字证书和可信证书的安全文件。它通常以文件的形式存在，受密码保护。keystore 可以包含用于身份验证、数字签名、加密等目的的密钥。

在 Java 中，keystore通常用于安全通信、数字签名和加密等场景。它提供了一种安全的方式来存储和管理密钥和证书，以确保它们不会被未经授权的人访问或修改。keystore通常以文件的形式存储在文件系统中，也可以存储在数据库或其他存储介质中。常见的 keystore类型包括 JKS（Java Key Store）、PKCS12（Public Key Cryptography Standards 12）和 BKS（Bouncy Castle Key Store）等。

JKS - 即Java Key Store,这是Java的专利和 OpenSSL作用差不多。利用Java的一个叫"keytool"的工具，可以生成密钥对。

2.1常用的命令如下

常用命令：https://blog.csdn.net/jobjava/article/details/135343775

2.1.1生成密钥库并创建第一个条目（密钥）

秘钥需要存储在秘钥库中，秘钥库可以理解为一个存储了一个或多个秘钥的文件。一个秘钥库可以存储多个密钥对，每个秘钥对都需要给它们取一个别名。

因为不存储任何条目的秘钥库是没有意义的，所以我们在生成秘钥库的时候需要指定一个条目，如果不指定，默认是的条目名称是mykey。

我们在 E:\keystore 目录下生成一个文件名为test.keystore的秘钥库，因为这个文件是第一次生成，必须同时生成一个条目，我决定将该秘钥库存储的第一个秘钥对的条目取名为mytest。命令是：

keytool -genkeypair -keystore "E:\keystore\test.keystore" -alias mytest -keyalg RSA -validity 365 -keysize 1024

-genkeypair : 表示生成自签名密钥对，可简写-genkey
-keystore：每个 keytool 命令都有一个 -keystore 选项，用于指定 keytool 管理的密钥仓库的永久密钥仓库文件名称及其位置。如果不指定 -keystore 选项，则缺省密钥仓库将是宿主目录中（由系统属性的"user.home"决定）名为 .keystore 的文件。如果该文件并不存在，则它将被创建。密钥库扩展名可以是.store或.jks。
-alias ：别名，指定密钥条目的别名，该别名是公开的。使用者通过该名称来操作密钥对。（因为一个密钥库会有多个密钥对）
-keyalg ：指定密钥生成算法RSA，默认DSA。
1. DSA只能用来签名（签名是私钥加密，公钥解密）
2. RSA既可以用来签名也能用来明文加密。（明文加密是公钥加密，私钥解密）

-keysize：密钥位大小（字节）1024
-validity：有效天数，365表示1年。

其他参数

-groupname <name> 组名，例如：an Elliptic Curve name.
-sigalg <sigalg> 签名算法名称（RSA\DSA）
-storetype <storetype> 密钥库类型（PKCS12、jks，默认jks）
-destalias <destalias> 目标别名（和上面的别名一样即可）
-dname <dname> 唯一判别名（如果没配置，输入命令时会提示输入相关信息，随便填就好了），例如：-dname "CN=(名字与姓氏), OU=(组织单位名称), O=(组织名称), L=(城市或区域名称), ST=(州或省份名称), C=(单位的两字母国家代码)"
-startdate <startdate> 证书有效期开始日期/时间(使用默认的即可)
-validity <valDays> 有效天数
-keypass <arg> 密钥口令（别名密码）
-storepass <arg> 密钥库口令
-v 详细输出

5、注意事项

1、如果指定的密钥库是第一次创建，则必须在创建时初始化一个条目。

2、密钥库的密码至少必须6个字符，可以是纯数字或者字母或者数字和字母的组合等。

3、"名字与姓氏"应该是输入域名，而不是我们的个人姓名，其他的可以不填。

执行完上述命令后，在操作系统的指定目录E:\keystore下生成了一个"test.keystore"的文件。

备注：需要设置密钥库口令和密钥口令，实现双保险的目的。

2.1.2生成秘钥（对称加密的秘钥）

keytool -genseckey -alias mytest -keystore "E:\keystore\test.keystore" -keyalg DES

-genseckey : 生成密钥
-alias ：别名，指定密钥条目的别名，该别名是公开的。使用者通过该名称来操作密钥对。（因为一个密钥库会有多个密钥对）
-keystore：每个 keytool 命令都有一个 -keystore 选项，用于指定 keytool 管理的密钥仓库的永久密钥仓库文件名称及其位置。如果不指定 -keystore 选项，则缺省密钥仓库将是宿主目录中（由系统属性的"user.home"决定）名为 .keystore 的文件。如果该文件并不存在，则它将被创建。密钥库扩展名可以是.store或.jks。
-keyalg ：指定密钥生成算法AES/DES，默认AES。

-keysize：密钥位大小（字节）,取值：128，192或256

其他参数

-storetype <storetype> 密钥库类型（PKCS12、jks，默认jks）
-storepass <arg> 密钥库口令
-v 详细输出

2.1.3根据证书请求生成证书

keytool -gencert

用于向CA授信机构发请求，没研究过

2.1.4从密钥库中导出crt证书

keytool -export -keystore "E:\keystore\test.keystore" -alias privatekeys -file certfile.cer

-export : 表示导出
-keystore：每个 keytool 命令都有一个 -keystore 选项，用于指定 keytool 管理的密钥仓库的永久密钥仓库文件名称及其位置。如果不指定 -keystore 选项，则缺省密钥仓库将是宿主目录中（由系统属性的"user.home"决定）名为 .keystore 的文件。如果该文件并不存在，则它将被创建。密钥库扩展名可以是.store或.jks。
-alias ：别名，指定密钥条目的别名，该别名是公开的。使用者通过该名称来操作密钥对。（因为一个密钥库会有多个密钥对）
-file ：公钥文件存放路径

2.1.5将证书导入到公钥库

keytool -import -keystore "E:\keystore\test.keystore" -alias publiccert -file certfile.cer

-import : 表示导入
-keystore：每个 keytool 命令都有一个 -keystore 选项，用于指定 keytool 管理的密钥仓库的永久密钥仓库文件名称及其位置。如果不指定 -keystore 选项，则缺省密钥仓库将是宿主目录中（由系统属性的"user.home"决定）名为 .keystore 的文件。如果该文件并不存在，则它将被创建。密钥库扩展名可以是.store或.jks。
-alias ：别名，指定密钥条目的别名，该别名是公开的。使用者通过该名称来操作密钥对。（因为一个密钥库会有多个密钥对）
-file ：公钥文件存放路径

我们通常把第一步生成的称为私钥库，其中包含私钥和证书。这里生成的叫公钥库，其中只含有证书。

私钥库是服务端使用，公钥库是给客户端使用。

2.1.6查看密钥库信息

keytool -list -v -keystore "E:\keystore\test.keystore"

-list：条目显示
-v：详细输出
-keystore：每个 keytool 命令都有一个 -keystore 选项，用于指定 keytool 管理的密钥仓库的永久密钥仓库文件名称及其位置。如果不指定 -keystore 选项，则缺省密钥仓库将是宿主目录中（由系统属性的"user.home"决定）名为 .keystore 的文件。如果该文件并不存在，则它将被创建。密钥库扩展名可以是.store或.jks。
-rfc 以 RFC 样式输出
-alias 要处理的条目的别名
-storepass 密钥库口令

2.1.7更改条目的密码口令

keytool -keypasswd -v -alias signtest2 -keypass a123456 -new 123456 -keystore ./signtest3.keystore -storepass a123456

-alias 要处理的条目的别名
-keypass 密钥口令(别名alias原密码)
-new 新口令
-keystore 密钥库名称
-storepass 密钥库口令
-v 详细输出

2.1.8更改密码库的存储口令

keytool -storepasswd -v -keystore ./signtest3.keystore -storepass a123456 -new 123456

-new 新口令
-keystore 密钥库名称
-storepass 密钥库口令
-v 详细输出

2.1.9 将jks转为p12文件

keytool -importkeystore -srckeystore ‪x:\xxx\xxx.jks（jks文件路径） -srcstoretype JKS -deststoretype PKCS12 -destkeystore x:\xxx\xxx.p12（后缀改为p12）

三、openssl

3.1格式转换

通常keytool生成的jks格式的密钥库，只用在java相关的程序中使用，例如tomcat。如果要在其他应用中使用，就需要进行格式转换。例如nginx中使用的就是pem格式的证书和私钥，其中私钥扩展名使用.key，公钥扩展名使用.crt。当然你都取名为pem也是没问题的。

3.1.1 jks格式的密钥库转为pem格式，需要以下步骤

3.1.1.1 keytool将jsk转为p12文件

3.1.1.2 p12转pem

openssl pkcs12 -nodes -in csii.p12 -out csii.pem

因为p12文件可能包含多个私钥和证书，所以生成的pem文件中也可能包含多个私钥和证书。我们打开转换后的pem文件，将其中-----BEGIN CERTIFICATE-----和-----END CERTIFICATE-----部分的内容复制到cert.pem中，把-----BEGIN PRIVATE KEY-----和-----END PRIVATE KEY-----部分的内容复制到pri_key.pem中。这样我们就得到了私钥文件pri_key.pem和证书文件cert.pem。

3.1.2从证书文件得到公钥，可以使用：

openssl x509 -in cert.pem -pubkey -out pb.pem

这样就得到了公钥文件pb.pem。

3.2 openssl生成私钥和证书

如果你想直接生成私钥和证书，而不是通过keytool生成的密钥库进行格式转换，可以使用如下方法：

openssl genrsa -des3 -out server.key 2048 #生成私钥文件server.key

openssl req -new -key server.key -out server.csr #生成证书请求文件server.csr

cp server.key server.key.org # 备份一下 server.key

openssl rsa -in server.key.org -out server.key #生成无秘钥 server.key

openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt #通过私钥和证书请求文件生成证书