密码学浅析

前言

早期的tcp/IP定位的直接就是可以更好的实现主机之间的通讯，并无过多的考虑安全问题。随着互联网规模的扩大以及鸟大了什么林子都有的原则，ftp、http、smtp、telnet这些协议都是明文传输的，很容易被不法分子利用，安全问题逐渐被人们重视，在互联网领域当中密码学是

安全的重要保障，密码学不是一项技术，而是科学，而且作为国家军事战略高度的科学，对于咱们普通人来说，密码学就是数据加密的机制。

加密的本质是一种转换规则。

常见的加密方式有三种：对称加密，非对称加密，单向加密

总结：由于应用的某些协议不安全，因此在应用层在传输层又加了半层，这半层以被称为TLS某种SSL，不管是TLS仍是SSL，主要都是利用密码学来实现的，而密码学对咱们这些使用者来说就是一种转换规则，常见的加密方式又被分为三种：对称加密，非对称加密，单向加密。

补充：

 

SM3中国首个hash算法

所谓的破解并非经过密文推导出明文，而是找到了两个hash同样的数据。

所谓的数字签名就是CA用本身的私钥加密从数据中提取出来的特征码，实现了身份验证和数据的完整性。

算法并不依赖于算法的自己，而是依赖于密钥，算法自己不少都是公开的

---

对称加密和非对称加密

数据加密：公钥加密不多用到数据的加密的，由于太慢，密钥太长，对称加密比非对称加密快1000倍左右，公钥的主要舞台用于身体验证。加密数据的话通常要使用对称加密，加密完成以后的对称密钥再用非对称密钥加密。

数字签名：数字签名的主要目的是让接收方知道数据的确是发送方发送的，用于用户身份验证，发送方生成一段数据，用本身的私钥加密这段数据而后发给接收方，接收方经过发送方事先公开的公钥就是确认发送方的身份。

密钥交换：所谓的密钥交换我认为是在SSL的基础上理解上,好比bob把本身的证书发送给alice,而alice会生成一个对称密钥,经过bob给的证书当中的公钥加密这个对称密钥以后发送给bob.,密钥交换能够这样理解,经过非对称密钥来完成对对称密钥的交换.

小结：

发送方用本身的私钥加密数据（数字签名），可以实现数据的身份验证，可是不能实现数据的机密性。

发送方用对方的公钥加密数据（密钥交换），能够保证的数据所机密性，但不能够身体验证。

 

举例：

A给B发送一段数据，B要确认是这A发的(身份验证)，数据没有被修改过（完整性），并不用保证数据的机密性。

A--------------->>------------B

答：A经过单向加密对数据提取一段特征码附加在文件的尾部，而后A经过本身的私钥仅仅加密最后一段特征码便可（数字签名），当B收到以后经过A事先公开的公钥实现对身份的验证，解开被加密后的特征码以后能够获得真正的特征码，而后B经过一样的单向加密算法，对数据进行单向提取特征码，经过与发送方发过来的特征码作比较来完成数据完整性的较验。

A--------->-----C-------->--------B

这个过程有没有可能被人破坏呢？是有可能，仍是使用上述方式：“A对数据提取特征码附加在数据的尾部，而后经过本身的私钥加密发送给B。“  B想要解密A加密的特性码，确定在加密A发送的数据前获取A的公钥，那么问题来了，B怎样才能得到A的公钥呢？通常就是A主动把本身的公钥发送给B，可是路上仍是有C在拦截，C彻底有可能把A发送给B的公钥给截获了，而后本身生成一对密钥，C把本身的公钥发送给B并说明本身就是A，而后B就相信了。当A给B发送真正的数据时，又被C给截获了，C即便不用A的公钥加密也彻底可以看到A发送给B的内容，固然C的野心不只仅是查看内容这么简单，C一般会把A给B发送的数据扔掉，而后本身生成一段数据（固然这段数据多是辱骂B的数据）而后本身用单向加密提取特性码附加到数据的尾部，C再经过本身的私钥加密特性码以后发送给B，这时B还会拿着本身认为的A的公钥去解密特性码，而后对数据作一次单向提取以后与“A”发来的的特性码对照，通过对照发现这个辱骂本身的数据就是A发送的，因而C与A绝交。

 

三种算法放到一块，让A与B通讯一次，而且保证不让C破坏

A-------------->>-------------B

仍是A给B发送一个数据，而且要保证这个数据只能是B收到，而且不能被人篡改伪造。

  

第一步经过单向加密对数据提取特征码附加在数据的尾部，这是在原有的公钥上面附加了信息，原有的公钥没有变化。

第二步经过本身的私钥对特征码进行加密，这是把hash经过私钥（转换规则）进行了转换，并无附加信息。

第三步而后把公钥+被私钥加密后的hash这两部分进行一次对称加密，这次加密遗留了一个对称密钥没处存放。

第四步而后经过对方的公钥对对称密钥再加加密一次。

 

1. 当B收到以后，首先经过本身的私钥打开对称密码，这里能够实现机密性，这个数据只有本身能够打开。
2. 用对称密钥，再打开被加密后的内容（公钥+被本身私钥加密后的HASH），这里什么也没实现，若是硬说实现了什么的话，那就是实现了效率，其实在这里就能够看到，是哪一个CA给A发的证书。
3. 若是本身本地没有此CA的数字证书的话，就显示不信任的证书颁发机构，若是本地有此CA的数字证书会进一步进行验证，尝试是否能打开“被CA私钥加密后的hash”，若是能打开就实现了身份验证，说明此公钥的确是CA给颁发的。
4. 别急，还没完呢！再把A的公钥和附加信息hash一遍，而后与A发来的HASH进行对比，这一步能够实现完整性的校验。B（一般是客户端浏览器）应该还要检查此证书是否在证书颁发机构的吊销列表里面，还要再查看客户端访问的URL是否与公钥里面的信息如出一辙，不同也不行。

一次通讯，三次加密算法都用上了。

这种通讯机制当中仍是存在了一个问题，依然存在着传输密钥时被C给截获的风险，依然是不安全

 

---

 PKI(Public Key Infrastructure)公钥基础设施

本小节主要介绍了：

l  公钥基础设施的概念和x509证书的格式

l  CA数据签名的过程以及客户端验证CA证书的过程

l  QQ是怎样实现加密的 

PKI的全称为public key infrastructure公钥基础设施，这是一个统称，就像新华电脑学院是多个专业的统称同样，其实公钥基础设施由四个部分组成，以下图：

 

   证书存取库：未来咱们向CA申请证书的时候就是向证书存取库里面申请的。如今证书存取库发放的证书都是X.509的格式，X.509不只仅是一种证书格式仍是证书的规范，有三个版本，咱们如今使用的都是它的第三版证书，它定义了一个规范的证书里面应该包括：

 

 

CA是怎样给某个主机进行发证的呢？

第一步：CA想要给别人发证，首先本身得有私钥和公钥。私钥用来给来申请的主机进行数字签名，公钥是要发给客户端的，用来实现对CA的身份验证，咱们讲过的：“使用本身的私钥加密，让别人经过公钥打开，能够实现身份验证而不能实现数据的机密性”。

第二步：CA仅有私钥和公钥还不成，还要有本身的数字证书。为何要本身有证书呢？一个CA为了方便用户的验证是要把本身的公钥公布于众的，可是并非直接把本身的公钥直接公布出去，而是把本身的数字证书公布出去（数字证书里面有本身的公钥），为何要这么作呢？直接公布公钥不成吗？直接公布公钥是颇有可能被中间人伪造的，因此要公布本身的数字证书，这样方便用户的验证。实际上用户导入CA数字证书的机会不多，由于通常主流的操做系统在发行时都已经把最多见的CA机构的数字证书内置到了操做系统内部了，可是也有没有导入的CA，好比12306网站使用的CA。CA是给别人发证的，那么CA本身的证书是谁给它发的呢？答案是本身给本身发的，那么怎样才能本身给本身发证呢？是这样的，过程是很简单的，CA把本身的公钥和一些必须要填报的信息：好比主体名称，国家，城市，等等经过一个文件本身提交给本身，核实无误而后再用本身的私钥对这个请求文件进行数字签名，签过名以后就会生成一个数字证书。那么签名的过程是怎样的呢？因为CA是本身给本身发证，因此提交请求以后并无进行验证，若是在真实的环境某主机给CA提交请求的话，CA机构会派人到该公司里内部核对申请的信息是否真实，有营业执照、公网IP，责任人等等确认无误以后，CA会经过单向加密，把主机提交的请求文件提取一个特征码附加在文件的尾部，而后经过本身的私钥仅对特征码进行加密，注意签名的过程并无对数据进行加密，加密的只是文件尾部的特征码，被加密过的文件特征码申请信息就组成一个数字证书，生成数字证书的过程就是数字签名。从CA给企业颁发证书的这个过程来看，仅仅实现了一个完整性的校验，对于机密性和身份认证都不能实现 ，由于在这个阶段，企业尚未数字证书，最好的方式就是企业拿着U盘去CA把CA的数字证书拿过了，这样最为保险，固然也可让CA把本身的数字证书送过来，其实这一步，通常是用不着用户作的，系统通常都会把经常使用CA的数字证书给安装好了。

第三步： CA将作签名的证书而后送回给申请的公司，申请的公司将把这个数字证书导入到须要使用的此证书的应用程序的主目录当中，好比，httpd会放到/etc/httpd/当中

NOTE：这个过程在下面的实验当中有演示。

用户怎样验证对方发来的证书是可信的呢？在描述验证之前咱们应该明确一点，操做系统在发行时通常都会将市面上最多见，最权威的CA机构的公钥内置到操做系统的内部以方便用户的验证。

第一步：当alice把本身的证书（固然此证书必定要是某CA机构签署颁布的）发送给bob时，bob为了验证alice就是alice而不第三方假装的，就要先打开alice给的数字证书，首先查看发行者（CA）的名称，若是此CA的名称与系统内置的某一个CA的名称重合，重合意味着系统内置了此CA的公钥，反之，就认为此CA机构不可信任。

第二步：bob经过系统内置的CA公钥去验证发行者（CA）的签名，怎样验证呢？咱们在上面讲过，CA给alice签名就是“CA用本身的私钥对alice申请文件的特征码作加密”，因此bob只要用CA的公钥可以打开CA对alice的私钥签名就证实alice是确认是这个CA颁布的证书，咱们在前面提过：”用本身的私钥加密能够实现身体验证，因此在这里bob可以用CA的公钥打开CA的签名就表示alice的证书就是信任的CA颁发的证书，到了这一步仅仅能说明证书里面的数据多是正确的，为何？由于证书里面的版本号、序列号、主体公钥等等都没有加密，仅仅是提取的特征码被加密而已，里面的信息仍是有可能被中间人修改的。

第三步：第三步解开的是证书内部的：”版本号，序列号，主体公钥，主体名称等等“这些信息的特征码，bob还要经过单身加密计算出这些信息的特征码，而后经过本身的计算出的特征码与CA公钥打开的特征码作比较，若是同样，就表示证书内全部的信息都是完整的，可靠的。

第四步：客户端检查证书是否位于证书吊销列表当中，大部分浏览器都没有作最后一步，为了保险期间咱们最好人工去查看一下。

如今互联网的证书主要有两种，一种是我的证书，一种是主机证书。银行给的U盾，U盾里面存放的就是用户本身的数字证书，当咱们须要用电脑在网上转帐的时候，服务器会把咱们的http请求自动转换为https，转换为https的过程就是用户去验证服务器的数据证书的过程，这是单向的验证，咱们在淘宝上付款时也是这样的，可是银行转帐客户端不只要验证服务器的数字证书，银行还要验证用户的数字证书，而用户的数字证书就在银行给的U盾里面，这个U盾里保存的数字证书就是我的证书，我的证书与主机证书最大的不一样是主机证书的主体名字上写的是主机的名字，好比www.taobao.com而用户的数字证书上的主体名称是用户的姓名，好比马云。固然最为经常使用的仍是主机证书，在这里须要注意的是证书里面的主体名必定要与真正主机的主机名要一致，否则的话，业务会失败.

CA

1.         生成一对密钥。

2.         利用公钥和申请信息产生一份申请文件提交给本身（此文件当中包括本身的公钥）。

3.         本身生成本身的数字签名证书：CA先利用hash提取出这个文件的特征码附加到文件的尾部，而后本身的私钥对此特征码加密，注意，文件并无加密。

4.         将此数字签名证书公布于众，各大操做系统的发行商会将其集成到本身的操做系统当中。

HTTPS

1.         生成一对密钥

2.         利用公钥和申请信息产生一份申请文件提交给CA（此文件当中包括本身的公钥）。

3.         CA对申请信息核实无误以后，会生成数字签名证书：CA先利用hash提取出这个文件的特征码附加到文件的尾部，而后本身的私钥对此特征码加密，注意，文件并无加密。

4.         CA将此数字证书给HTTP，HTTP会将其放置到本身的工做目录的。

Client

Client默认就是有CA本身的数字签名的，也就是说用户有CA的公钥，发行商集成的嘛！

1.         当客户端访问网站时，固然先创建虚链路、而后附加TLS通道，服务器会把CA签名过的数字证书发送给客户端。

2.         客户端验证，怎样验证呢？用CA的公钥尝试打开网站给的数字证书当中被加密后的特征码，若是打开了就实现了身体验证，打开以后利用hash进一步验证完整性。

3.         客户端拿到网站的公钥以后会随机生成对称密钥，经过公钥加密以后发送给网站，而后后面它们加密的数据都是用对称密钥处理以后再发送。

QQ的加密通讯:

当数据从资源子网交给通讯子网以后，数据会被封装，可是封装并无改变资源子网的数据，若是有人能够获取到这些包的话就能够看到通讯子网当中的内容。可能有人说不会呀？我用QQ发送的数据即被抓到包也看不到里面发送的明文，这是怎么回事呢？其实“资源子网把数据给通讯子网以后数据并无改变”这个原则并无改变，只不过是QQ这个软件自己实现了数据加密的功能（有的资源子网的协议或者软件可自行实现数据的加密，而有的协议或者软件自己是不支持加密的，像早期的QQ就不支持加密），像这样的案例还有，好比ftp，当咱们使用ftp的时候就能够抓住ftp要传输的内容包括密码，若是咱们在网上转帐呢？这岂不是太不安全了，其实这是有解决办法的。像ftp这种资源子网当中的协议自己不能加密，而通讯子网又不能改变数据的内容，只要在资源子网在通讯子网之间加上半层，让这半层专门实现加密功能来加密数据。

---

TLS和SSL

SSl（安全的套接字层）和TLS（transport layer security）传输层安全

PKI是公共密钥基础设施，是为了数据可以安全可靠的传输，实质上这种设施是为了应用程序准备的，好比http（超文本传输协议）这个协议本来只能传输明文没有加密的机制，很是的不安全可靠，可是如今不一样的了，有了公共密钥基础设施，咱们就能够在http的基础上使用公共密钥基础设施，怎样使用呢？
OSI参考模型在之因此是七层很大缘由就是某一层的调整并不会影响到其余层，咱们在应用层和传输层中间再放半层，用这半层专门来实现对PKI的应用，凭什么这半层可以实现加密，就是由于这半层的主要任务就是协商加密方式，对数据进行加密，验证对方的数字证书，讲到这里，咱们知道了，协商加密方式，对要传输的数据加密，验证对方的证书并非计算机完成的，而是由这半个中间层完成的,那么这半个层就是TLS或者是SSL.

那么究竟是TLS仍是SSL呢?它们两个是什么关系呢? SSL（安全的套接字层）是网警一个公司为本身的浏览器的研制出的协议，后来微软战胜的IE战胜.后来国际标准化组织也搞了出了一个协议就叫TLS（传输层安全协议），TLS如今是初版，至关于SSL的第三版，原理和机制差很少，那么咱们下面再讲的时候是不加以区分的。有的软件仅支持SSL，有的仅支持TLS，有的两种协议都支持.

半层？一层？

那么为何说这个中间层只有半层而不是一层呢？是这样的，以下图：

 

 

当http不使用TLS或者是SSL层的时候传输的都是明文，当http使用TLS或者SSL的时候就变成了https，传输的不一样进明文而是密文,因此咱们可使用tls也能够不使用,这一层并非必需存在的,因此这是说这是半个层而不是一个整层.

SSL只能基于IP地址的访问，而不能根据主机名来实现，由于SSL它终究不是应用层的的应用或者协议，它是位于应用层与传输层之间的库，SSL握手的时候只能基于IP，而不能基于主机名，是由于在使用基于主机名的访问的时候主机名是封装在应用层的，SSL能够读取到网络层的可是读取不到应用层的信息，因此不管是哪一个虚拟主机,只要是IP同样,SSL都会当成一个会话来看待,一个IP地址基于一个应用层协议只能创建一个会话.

http VS https

本小节主要介绍了http和https的会话过程:

http的会话过程:

1. 客户端把请求发送到服务器上,服务器上的内核根据请求包当中的目标端×××给http服务
2. http根据请求到的内容让内核去硬件当中调用数据,交给http进程
3. http构建响应报文根据套接字回复到客户端并记录日志

https的会话过程:

1.    客户端向服务器发起请求

2.    服务器先要跟客户端协商到底使用SSL还有sls协议的哪一个版本，这是双向的过程 。

3.    服务器会把本身的证书发给客户端（客户端通常没有证书），客户端是看签署的CA是否是本身信任的，信息是否完整，拿到服务器的公钥。

4.    客户端会生成一个随机会话对称秘钥，经过服务器端的公钥加密以后发送给服务器

5.    服务器端就能够这个对称秘钥进行使用了

 

补充：

diffie-hellman算法补充一下，在上文当中没有介绍，这种算法在IPSEC-*** 和SSH当中会见到，其原理就是经过交换一些材料，进而推断出密钥，而不是直接交换密钥。