pki（Public Key Infrastructure）公钥基础设施 & 加密技术

屋檐听雨的猫

已于 2024-08-08 23:11:59 修改

阅读量784

点赞数 9

文章标签：网络安全 web安全计算机网络

于 2024-08-08 23:02:43 首次发布

本文链接：https://blog.csdn.net/lijiongkai/article/details/141038312

版权

pki（建议忍一忍，看完深度解读，便于透彻理解）

一、 PKI概述
二、信息安全三要素
三、哪些IT领域用到PKI：
四、公钥加密技术
深度解读
五、实验
相关有趣的东东

一、 PKI概述

1、名称
Public Key Infrastructure：公钥基础设施
2、作用
通过加密技术和数字签名保证信息的安全
3、组成（不懂没关系，往后看）
公钥加密技术、数字证书、CA、RA

二、信息安全三要素

机密性
完整性
身份验证/操作的不可否认性

三、哪些IT领域用到PKI：

1、SSL/HTTPS ssl 、https
2、IPsecVPN IPsecVPN
3、部分远程访问VPN VPN

四、公钥加密技术

（想要深入了解建议自行学习，博主能力有限无法全部讲解）

1、作用：实现对信息加密、数字签名等安全保障
2、加密算法：

（1）对称加密算法
 加解密的密钥一致！

（2）非对称加密算法

通信双方各自产生一对公私钥。
双方各自交换公钥
公钥和私钥为互相加解密关系！
公私钥不可互相逆推！
RSA DH

（3）例如

x+5=y(对称加密算法）

x是原数据/原文
y是密文
5是key/密钥

（4）HASH算法：MD5 SHA （验证完整性）

HASH值不可逆！
HASH值=摘要

（5）数字签名：
用自己的私钥对摘要加密得出的密文就是数字签名

（6）证书：

①证书用于保证公密的合法性
②证书格式遵循X.509标准
③数字证书包含信息：

使用者的公钥值
使用者标识信息（如名称和电子邮件地址）
有效期（证书的有效时间）
颁发者标识信息
颁发者的数字签名

④数字证书由权威公正的第三方机构即CA签发

⑤CA是权威证书颁发机构，为了公正“公钥”的合法性！
⑥机密性：使用对方的公钥加密！
⑦身份验证/数字签名：使用自己的私钥！

深度解读

：
没有HTTPS的第一个缺点，保证不了数据的机密性，容易泄密。你们之间的网络通信相当于是高清无码的内容，因此我们必须给内容打码，打码以后，中间人并不是就没有办法知道内容了，而是极大的增加了中间人辨认内容的难度，稍微具体一些就是你和门户网站之间需要有两把一模一样的私钥，你和网站两边各执一把。既然是叫私钥，当然不能给任何人，这把私钥可以简单理解为某种数学运算，比如你要发送一串字符，用这把私钥加密，就会把字符打出来，铭文就变成了密文，我们假设中间人很笨，看不懂网站，收到密文后，用同一把私钥解密后就把密文打过来，这样就得到铭文了，网站发给你也是一样的方法，使用道具来加密和解密，就是这里的私钥。这种只用同一把私钥的加密叫做对称加密，中间人不知道私钥的具体内容，就很难进行破解，而且这把私钥是有期限的。你和网站之间的每一次会话都需要一把新的私钥，这样有期限的私钥统称为会话密钥，现在中间人要破解所有绘画就更困难了。听起来很合理，是不？好像是，又好像不是。既然你和网站之间需要不能公开的绘画密钥，那你们就需要实打实的见上一面，把会话密钥沟通好。再进行网络通信，如果真要这样，你们还愿意上网吗？为了不见面就可以进行远距离网络通信，我们需要巧妙的协商，或者发送这把会话密钥给对方。现在网上有一把公钥和一把私钥，用公钥加密的内容只能用私钥进行解密，记住它们是成对的密钥，就跟公鸡和母鸡一起才能下蛋的道理。因此，在网站把公钥发给你以后，你需要生成一串只有你自己知道的神秘字符，并且用收到的公钥进行加密，得到了加密后的神秘字符，接着你需要把加密后的神秘字符发送给网站，网站用谁都不晓得的私钥解密得到那串神秘字符，于是你们两边都可以用这串神秘字符，生成只有你们知道的会话密钥。在通信过程中，中间人可以得到公钥以及加密后的神秘字符，但是用公钥进行解密是得不到神秘字符的，只能用私钥解密。因为用到公钥和私钥。这样的加密叫做非对称加密。
这就解决了如何发送和协商汇报密钥的问题了。听起来很合理，是否好像是也好像不是？我们不妨让时光倒流。当网站要把公钥发送给你的时候，中间人拿到了网上的公钥，以后不直接发给你，因为中间人要加戏，中间人此时要生成自己的一对公钥和私钥，并且把他自己的公钥发给你，于是你就傻乎乎的用中间人的功要加密自己生成的神秘字符，中间人再次进行截获，并且用自己的私钥破解了你的神秘字符，破解以后不直接发送给网站，而是修改里面的内容，并且用网站给的公钥加密修改后的内容，再发送给网站，网站收到后用自己的私钥解密收到的信息，会发现能够成功解密，通信在神不知鬼不觉的情况下被篡改了。如果在这种情况下还要继续生成会话密钥，其实会生成不同的会话，密钥一边是你和中间人的另一边是中间人和网站的，你和网站之间并没有直接生成任何会话密钥，中间人可以把通信内容说改就改，因此前面非对称和对称加密了个寂寞，这就是没有https的第二个缺点，保证不了数据的完整，有可能被更改。
问题就在于这里的公钥我们不能确定收到的这把公钥是网站的，还是中间人的？这个时候就像西游记里孙悟空与六耳猕猴的争执是两只猴子都说自己才是真正的美丽猴子王，直到第三方如来佛祖的出现才有结果，我们的网络通信也需要第三方来解决公家的信任问题，这个第三方简称CA（Certificate Authority，权威认证机构），于是刚才的流程就发生了变化，你在发送神秘字符之前，网站需要先把用来给你加密的公钥放到大家信任的第三方CA那里，CA根据这个公钥以及其他信息生成了数字证书，数字证书相当于让这把公钥和该网站绑定起来了，如果回到刚才的流程网站，再与你进行加密协商之前，就可以先把数字证书发给你了，你看到数字证书是属于信任的CA，于是，从数字证书里面取出公钥，这样就可以愉快的生成最后的会话密钥了。
听起来很合理，似乎好像是也好像不是我们如何相信数字证书，就是有信任的CA颁发的呢，数字证书上有CA的签名就可以了。这和我们真实生活中的签名十分相似，比如老师让家长给孩子检查作业，为了确保孩子们的作业给家长检查了，会要求在作业上签写家长的大名，在网络通信中并不是用签字笔来签名，而是用数字签名给数字证书签名。我们不妨再次进行时光倒流，当CA在收到网站的信息以及公钥以后，会对这些信息以及公钥进行哈希运算，得到一串较短的哈希**（hash≠加密）**字符。听到这里，你们可能会觉得奇怪，为什么要进行哈希运算呢？简单来说，哈希运算就是把一段内容变成特定的很短的字符，这样大大压缩掉需要传输的信息，而且这串字符等会还要进行加密和解密，如果要计算的字符很大会消耗掉非常多的时间。另外，如果内容有哪怕一个字符的修改，最终生成的字符都会不一样，不一样的内容会生成不一样的哈希字符，这串短字符相当于家长检查作业后给出的分数，对全部内容进行一个总结，回到刚才的步骤，在哈希运算以后CA自己也生成一对专门用于数字证书的公钥和私钥，然后要用这把私钥给哈希字符加密，注意用的是私钥（这样后面才可以用公钥解密），这时候加密后，字符就是 数字签名了。注意，进行哈希运算并非进行了加密运算，因此这里要对哈希字符进行加密。现在CA就可以把含有CA数字签名的证书发给网站了，虽然数字证书里的网站信息都是明文的，但是核心就在于CA的数字签名了。如果证书里的内容被篡改了或者公钥被修改了，生成的哈希值会不一样，最终的数字签名就会变成另外的一串字符。当你访问网站的时候，网站会把含有CA数字签名的数字证书发给你，为了证明没有中间人更改过公钥，你需要用到CA签名时候生成的公钥，并且用这把CA公钥给数字证书里面的数字签名解密，这样会得到一串哈希字符，毕竟数字签名加密前就是一串哈希字符，这串哈希字符先放着，接着你对收到的数字证书内容进行同样的哈希运算，也得到一串哈希字符，如果前后两串哈希字符一致，说明数字证书是靠谱的，没有被篡改。我们现在假设中间人修改了数字证书的内容，但是由于中间人没有原本生成数字证书的私钥，因此你收到的数字签名会和数字证书不匹配，除非中间人把数字证书和数字签名同时改的匹配才行，这种情况也只能是拥有私钥才行，没问题的话就可以继续生成会话密钥的步骤了。看到这里，你们可能感到奇怪，一下子私钥加密，一下子公钥，这就和可乐既可以用来喝，还可以用来冲马桶是差不多的道理，虽然听着反人类，但事实就是如此，千万不要被一些字面意思给束缚住，不管是公钥加密还是私钥加密，背后的数学原理就是你用了一把进行加密，另一把就只能用来解密，由于应用场景的不同，导致了他们在用法上的不同，前面说的公钥加密，私钥解密，虽然理论上谁都可以加密，但是加密后只能是拥有私钥的人才能解密，因此用来加密信息就很好。数字签名则是私钥先加密公钥再解密，也就是常说的私钥签名公钥验签只能是拥有私钥的人才能加密，但理论上谁都能解密用来验证身份就很好。
但是刚才还遗漏了个问题的问题，我们如何安全的拿到信任企业的公钥呢？我们不妨再次让时光倒流的网站向第三方CA申请证书的时候，CA会生成专门给这个网站颁发证书的一对公钥和私钥，并且用自己的私钥给证书签名，网站公钥和私钥，用来生成最终的会话密钥。我们是知道了CA是要用来给证书签名，我们也知道了，就剩下CA的公钥像孤儿一样被丢在一边了。其实CA也需要数字证书。来证明自己的身份，因此会把这把公钥放在自己的数字证书里面，按照数字证书的生成原理，这份数字证书同样也需要另外一把私钥来进行签名，这就需要再加一层了，也就是根CA网站申请证书的这个CA则是中间CA，根CA同样需要生成一对专用的公钥和私钥，并且用这把私钥为中间CA的证书签名，根CA竟然有这把公钥，也就是说，根CA也有自己的证书，但是跟CA的证书由谁来签名呢？会不会是地球CA呢？如果是就没完没了了？根CA需要为自己的证书签名，然后在用户操作系统和浏览器里面预先安装根CA的证书，这样就可以闭合这一整条 证书链的，这里的核心就是用顶层的私钥给下层的证书签名，验证的时候用顶层的公钥来检验下层的签名，你们可能觉得奇怪，网站可以直接和根CA申请证书的呀，没有中间商赚差价多好呀。其实我们只需要把这里的结构想象为一棵树就好，如果中间有一根树枝乱了，也不至于连根拔起根CA，可以避免与广大的网站服务器直接接触，直接交给中间CA进行接触，如果其中有一家中间CA的私钥被破解了，也不至于影响到全局，因此根CA私钥的管理十分重要。
为了让大家理解这一过程，我们来看一看，使用了https的网站有什么不同。没错，有的网站提供的http和https 2种方式访问网站，浏览器在进行加密之前收到网站服务器发过来的证书，证书上面有串重要的字段，颁发者也就是谁颁发了这份数字证书。这里有个很重要的书写，CN不是China的缩写，意思是 （commonname公用名），但是我的电脑里面并没有这家CA的证书，其实网站是可以把整个证书链发给浏览器的，也有可能网站服务器不发送中间证书，导致有些浏览器可能需要从缓存中找这些证书或者自行下载中间证书。继续刚才的步骤，浏览器查看这份中间证书的颁发者，发现这里的公用名是user trust rsa certification authority（华盛顿大学的网站），此时需要找到一个电脑里面没有它的证书，最后成功找到这份根证书，并且提取里面的公钥来验证中间证书的签名，没问题再用中间证书的那份公钥来验证网站证书的签名，都没问题，说明网站的证书没有被篡改，但是没有被篡改，也还是证明不了这份证书就是属于该网站的，其实浏览器还会查看背景的公用名是否和域名一致，很明显这里是一致的，因此证明这份证书是和该域名绑定的，这里也说明了没有用https的第三个缺点，没有用https你很难确定访问的是不是官网，毕竟第三方事业在颁发证书之前是会进行网站信息的检查。当然我们经常会看到网站域名和公用名cn不一致，因此浏览器还会查看扩展程序里的证书主题背景的备用名称，接着浏览器还需要检查证书的有效期用俗话说，就是证书到期了，记得续费，现实就是这么残酷。这里还有个问题，如果网站服务器的私钥泄露了，并且已经向CA申请证书的吊销浏览器，浏览器如何知道这种事呢？其实就要靠CA的证书吊销列表了，我们可以在扩展程序的。CRL分发点，你查看访问这个网址，可以下载这份文件，当然我们用命令来查看这份文件内容的时候，就可以看到被吊销证书对应的序列号，当然有些浏览器不会去检查这个列表，导致了安全隐患，另外这个证书掉列表可能不是实时的，因此就有。在线证书状态协议OCSP作为替补，这样浏览器可以向专门的服务器查看某个证书是否被吊销来弥补前面那种方法时效性的问题。不过，这个协议也出现了隐私泄露的问题，虽然浏览器还会继续为证书进行身体检查，但是核心的部分，我们已经了解了。