密码学应用（一）身份鉴别

身份验证

身份验证又称为“验证”、“鉴权”，是指通过一定的手段，完成对用户身份的确定。

身份验证的方法：

1. 基于共享密钥的身份验证；
2. 基于生物学特征的身份验证；
3. 基于公开密钥加密算法的公开验证。

身份验证的目的：
确认当前所声称为某种身份的用户，确实是所声称的用户。

身份认证可分为三类：

1. 实体所知：

应用最广泛的认证方式，因为其成本低，实现简单。例如：口令、验证码等。
面临的威胁也比较大。例如：暴力破解、木马等。

2. 实体所有：

是一种安全性较高，成本也比较高的认证方式。例如：IC卡、门禁卡等。
实体所有因为存在固体实物，会面临着损坏和被复制的风险。
数字签名也是实体所有的一种认证方式。

3. 实体特性：

是安全性最高的一种认证方式，通常采用生物识别方法进行验证。例如：指纹、虹膜、声波等生物特征。
实体特性的鉴别的准确率和效率取决于开发过程中的算法特征。
实体特性的鉴别方法：

1. 错误拒绝率（FRR）
2. 错误接受率（FAR）
3. 交叉错判率（CER）

数字证书（数字标识）

数字证书是指在互联网通讯中标志通讯各方身份信息的一个数字认证，人们可以在网上用它来识别对方的身份。
数字证书对网络用户在计算机网络交流中的信息和数据等以加密或者解密的形式保证了信息和数据的完整性和安全性。

数字证书的申请过程：

把个人信息和公钥提交到某权威机构的证书中心，然后这个中心用自己的私钥将提交过来的信息加密而形成数字证书。这个权威的机构包括以下几个组成部分:

• PKI：
  是公钥基础设施(Pubie Key Infrastructure)的简称，PKI利用公开密钥技术建立的提供信息安全服务的在线基础设施。它利用加密、数字签名、数字证书来保护应用、通信或事务处理的安全。
• CA：
  是PKI的核心，主要职责为签发证书、更新证书、管理证书(撒销、查询、审计、统计)、验证数字证书、黑名单认证(CRL)、在线认(OCSP)。
• RA：
  受理用户的数字证书申请(对证书申请者身份进行审核并提交CA制证)、提供证书生命期的维护工作(受理用户证书申请、协助颁发用户证书、审核用户真实身份、受理证书更新请求、受理证书吊销)。
• 证书库：
  证书存放管理，信息的存储库，提供了证书的保存，修改，删除和获取的能力；
  CRL（Crifiate Revocation Lis）：证书撤销列表，也称“证书黑名单”，存放被撒销证书的序列号，证书有效期期间因为某种原因(人员调动、私钥泄漏等)导致证书不再真实可信，因此需要进行证书撤销

申请流程如下图：

• Alice 发送注册信息给RA
• RA审查通过后发送给CA
• CA将Alice个人信息，Alice公钥可能还会包括Alice的数字签名打包成数字证书
• CA将签发数字证书下载凭证，并将下载凭证将给RA
• CA将数字证书交给证书库保存
• RA将下载凭证交回给Alice
• Alice向CA提交下载证书申请和凭证
• Alice从CA下载证书
• Alice 向Susam发送自己的证书
• Susam验证证书

数字证书验证，首先会由浏览器使用已经储在浏览器中的Root CA的公钥来验证中间证书的数字如果证书的签发机构能够在可信任签发机构中找到则为可信任证书。
如果查询不到，则从授权信思访问信息段中获得该签发机构的数字证书。并判断该授权机构的数字证书的签发机构是否能够在可信任签发机构中找到，若果找到则该授权机构是可信的，井从投权机构的数字证书中获得授权机构的公钥，如果不在则重复这一步骤。 如果最终都没有找到可信机构，则为不可信证书。

HTTPS

简介：

我们知道网络层，可以实现两个主机之间的通信。但是这并不具体，因为，真正进行通信的实体是在主机中的进程，是一个主机中的一个进程与另外一个主机中的一个进程在交换数据。IP协议虽然能把数据报文送到目的主机，但是并没有交付给主机的具体应用进程。而端到端的通信才应该是应用进程之间的通信。

---

UDP，在传送数据前不需要先建立连接，远地的主机在收到UDP报文后也不需要给出任何确认。虽然UDP不提供可靠交付，但是正是因为这样，省去和很多的开销，使得它的速度比较快，比如一些对实时性要求较高的服务，就常常使用的是UDP。对应的应用层的协议主要有 DNS,TFTP,DHCP,SNMP,NFS 等。

---

TCP，提供面向连接的服务，在传送数据之前必须先建立连接，数据传送完成后要释放连接。因此TCP是一种可靠的的运输服务，但是正因为这样，不可避免的增加了许多的开销，比如确认，流量控制等。对应的应用层的协议主要有 SMTP,TELNET,HTTP,FTP 等。

常用的熟知端口号：

应用程序	FTP	TFTP	TELNET	SMTP	DNS	HTTP	SSH	MYSQL
熟知端口	21,20	69	23	25	53	80	22	3306
传输层协议	TCP	UDP	TCP	TCP	UDP	TCP	TCP	TCP

TCP的概述：

TCP把连接作为最基本的对象，每一条TCP连接都有两个端点，这种断点我们叫作套接字（socket），它的定义为端口号拼接到IP地址即构成了套接字，例如，若IP地址为192.3.4.16
而端口号为80，那么得到的套接字为192.3.4.16:80。

TCP报文首部：

源端口和目的端口：各占2个字节，分别写入源端口和目的端口；

---

序号：占4个字节，TCP连接中传送的字节流中的每个字节都按顺序编号。例如，一段报文的序号字段值是 301，而携带的数据共有100字段，显然下一个报文段（如果还有的话）的数据序号应该从401开始；

---

确认号：占4个字节，是期望收到对方下一个报文的第一个数据字节的序号。例如，B收到了A发送过来的报文，其序列号字段是501，而数据长度是200字节，这表明B正确的收到了A发送的到序号700为止的数据。因此，B期望收到A的下一个数据序号是701，于是B在发送给A的确认报文段中把确认号置为701；

---

数据偏移：占4位，它指出TCP报文的数据距离TCP报文段的起始处有多远； 保留，占6位，保留今后使用，但目前应都位0；

---

紧急URG：当URG=1，表明紧急指针字段有效。告诉系统此报文段中有紧急数据；

---

确认ACK：仅当ACK=1时，确认号字段才有效。TCP规定，在连接建立后所有报文的传输都必须把ACK置1；

---

推送PSH：当两个应用进程进行交互式通信时，有时在一端的应用进程希望在键入一个命令后立即就能收到对方的响应，这时候就将PSH=1；

---

复位RST：当RST=1，表明TCP连接中出现严重差错，必须释放连接，然后再重新建立连接；

---

同步SYN：在连接建立时用来同步序号。当SYN=1，ACK=0，表明是连接请求报文，若同意连接，则响应报文中应该使SYN=1，ACK=1；

---

终止FIN：用来释放连接。当FIN=1，表明此报文的发送方的数据已经发送完毕，并且要求释放；

---

窗口：占2字节，指的是通知接收方，发送本报文你需要有多大的空间来接受； 检验和，占2字节，校验首部和数据这两部分；

---

紧急指针：占2字节，指出本报文段中的紧急数据的字节数； 选项，长度可变，定义一些其他的可选的参数。

三次握手

最开始的时候客户端和服务器都是处于CLOSED状态。主动打开连接的为客户端，被动打开连接的是服务器。

---

---

1. TCP服务器进程先创建传输控制块TCB，时刻准备接受客户进程的连接请求，此时服务器就进入LISTEN（监听）状态；
2. TCP客户进程也是先创建传输控制块TCB，然后向服务器发出连接请求报文，这是报文首部中的同部位SYN=1，同时选择一个初始序列号 seq=x ，此时，TCP客户端进程进入了 SYN-SENT（同步已发送状态）状态。TCP规定，SYN报文段（SYN=1的报文段）不能携带数据，但需要消耗掉一个序号。
3. TCP服务器收到请求报文后，如果同意连接，则发出确认报文。确认报文中应该 ACK=1，SYN=1，确认号是ack=x+1，同时也要为自己初始化一个序列号 seq=y，此时，TCP服务器进程进入了SYN-RCVD（同步收到）状态。这个报文也不能携带数据，但是同样要消耗一个序号。
4. TCP客户进程收到确认后，还要向服务器给出确认。确认报文的ACK=1，ack=y+1，自己的序列号seq=x+1，此时，TCP连接建立，客户端进入ESTABLISHED（已建立连接）状态。TCP规定，ACK报文段可以携带数据，但是如果不携带数据则不消耗序号。
5. 当服务器收到客户端的确认后也进入ESTABLISHED状态，此后双方就可以开始通信了。

---

为什么TCP客户端最后还要发送一次确认呢？
主要防止已经失效的连接请求报文突然又传送到了服务器，从而产生错误。

• 如果使用的是两次握手建立连接，假设有这样一种场景，客户端发送了第一个请求连接并且没有丢失，只是因为在网络结点中滞留的时间太长了，由于TCP的客户端迟迟没有收到确认报文，以为服务器没有收到，此时重新向服务器发送这条报文，此后客户端和服务器经过两次握手完成连接，传输数据，然后关闭连接。此时此前滞留的那一次请求连接，网络通畅了到达了服务器，这个报文本该是失效的，但是，两次握手的机制将会让客户端和服务器再次建立连接，这将导致不必要的错误和资源的浪费。
• 如果采用的是三次握手，就算是那一次失效的报文传送过来了，服务端接受到了那条失效报文并且回复了确认报文，但是客户端不会再次发出确认。由于服务器收不到确认，就知道客户端并没有请求连接。

四次挥手

数据传输完毕后，双方都可释放连接。最开始的时候，客户端和服务器都是处于ESTABLISHED状态，然后客户端主动关闭，服务器被动关闭。

---

---

1. 客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。== TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。==
2. 服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。
3. 客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文==（在这之前还需要接受服务器发送的最后的数据）。==
4. 服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
5. 客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗*∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。
6. 服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。

---

为什么客户端最后还要等待2MSL？
MSL（Maximum Segment Lifetime），TCP允许不同的实现可以设置不同的MSL值。

1. 保证客户端发送的最后一个ACK报文能够到达服务器，因为这个ACK报文可能丢失，站在服务器的角度看来，我已经发送了FIN+ACK报文请求断开了，客户端还没有给我回应，应该是我发送的请求断开报文它没有收到，于是服务器又会重新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，并且会重启2MSL计时器。
2. 防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后，在这个2MSL时间中，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文。

---

为什么建立连接是三次握手，关闭连接确是四次挥手呢？

• 建立连接的时候， 服务器在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。
• 而关闭连接时，服务器收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，而自己也未必全部数据都发送给对方了，所以己方可以立即关闭，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送，从而导致多了一次。

---

如果已经建立了连接，但是客户端突然出现故障了怎么办？
TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

客户端与服务器对称加密

1. 请求由客户端发起。客户端发送Client Hello报文开始SSL通信。报文中包含了：

SSL/TSL version:1.2(协议版本)
Cipher Suites:(支持的加密解密算法族)
Randm:(客户端生成随机数random_client)
Session ID:(如果之前已经建立过https链接并且服务器又返回SID,则发送时会有值)
Extensions:(扩展数据 例如:Server Name ：www.google.com etc)

2. 服务器收到请求会以Server Hello报文作为应答，
3. 紧接着服务器再发送一条Certificate报文，报文中包含了证书；
4. 服务器活还没干完，还需要发送Server Hello Done报文给客户端，表示SSL握手结束。

Randm:(服务端生成的随机数random_client)
Session ID:(服务端对SID有三种情况)
a)恢复session ID:我们之前在client hello里面已经提到，如果client hello里面的session ID在服务端有缓存，服务端会尝试恢复这个session；
b)新session ID:这里又分两种情况，第一种是client hello里面的session ID是空值，此时服务端会给客户端一个新的session ID，第二种是client hello里面的session ID此服务器并没有找到对应的缓存，此时也会回一个新的session ID给客户端；
c)NULL:服务端不希望此session被恢复，因此session ID为空。
Cipher Suite:(在client hello里面，客户端给出了多种加密族Cipher，而在客户端所提供的加密族中，服务端挑选了一个。例如："TLX_ECDHE_RSA_WITH_AES_128_GCM_SHA256")
a):TLS为协议，RSA为密钥交换算法；
b):AES_256_CBC是对称加密算法(其中256是密钥长度，CBC是分组方式)；
c):SHA是哈希算法。这意味着服务端会使用ECDHE-RSA算法进行密钥交换，通过AES_128_GCM对称加密算法来加密数据，利用SHA256哈希算法来确保数据的完整性。
Server Certificate:服务端证书
Server Key Exchange:Server返回给Client用于生成key(对称加密密钥)的信息
Certificate Request:要求Client发送证书
ServerHelloDone:表示Server已经结束Hello的过程

5. 然后客户端会回应一个Client Key Exchange报文，报文包含用步骤3中公钥加密后的随机密码串。
6. 接着客户端继续发送Cipher Spec报文，提示服务器，用步骤5的随机密码串作为密钥加密之后的通信。

Client Certificate:(客户端证书)
Client Key Exchange:(client提交给Server自己用于生成key(对称加密密钥)的信息)

7. 最后客户端发送Finished报文，表示这次协商结束，是否成功还得看服务器能不能解密该报文。
8. 服务器没问题，发送Change Cipher Spec报文。
   服务器发送Finished。

ChangeCIpherSpec:客户端通知服务端发送加密数据
Client Finished:结束握手

9. SSL连接完成，接下来使用HTTP进行通信。利用对称密钥加解密传输数据；
10. 最后由客户端断开连接。发送close_notify报文。

对称加密密钥交换

1. 首先，客户端利用CA数字证书实现身份认证，利用非对称加密协商对称密钥；
2. 客户端会向服务器传输一个"pubkey_client"随机数，服务器收到后，利用特定算法生成另外一个"pubkey_server"随机数，客户端利用这两个"pubkey"随机数生成一个pre-master随机数；
3. 客户端利用自己在client hello里面传输的随机数random_C，以及收到的server hello里面的随机数random_S，外加pre-master随机数，利用对称密钥算法生成，对称密钥enc_key:enc_key=Fuc(random_C,random_S,Pre-Master)

Kerberos流程

Kerberos是一种网络认证协议，它包括以下几个模块：

• AS：认证服务器（分发票据许可票据）
• TGS：票据授权服务器（分发服务许可票据）
• TGT：票据授权票据
• SGT：服务许可票据
• KDC：密钥分发中心
• SS：特定服务提供端

具体流程：

1. 客户机向AS服务器发送【客户端名和TGS名】；
2. AS服务器从数据库中对比是否存在客户端名；
3. 如果存在客户端名，AS服务器生成一个临时密钥K₁，再从数据库中提取出客户端名对应的密码的hash值，将hash值当做密钥K_hash对K₁加密，得到K_hash（K₁）；
4. AS服务器产生TGT【TGT包含了K₁、客户端名、TGT有效期】，然后用AS服务器的固定密钥K_s1对TGT信息加密，得到K_s1（TGT）；
5. AS服务器将【K_hash（K₁）和K_s1（TGT）】发送给客户端；
6. 客户端收到信息后，提示输入密码，并提取输入密码的hash值与K_hash对比，如果一样则解密出K₁ ，并用K₁ 作为密钥对客户端名加密，得到K₁ （客户端名）；
7. 将【K_hash（K₁），K_s1（TGT），K₁（客户端名）】发送给TGS服务器获取服务许可票据；
8. TGS服务器得到信息后，使用本地存储的固定密钥K_s1 解密K_s1（TGT）后得到密钥K₁ 、客户端名，再用TGT信息中的K₁ 解密K₁ （客户端名）后得到客户端名，将K_s1（TGT）和K₁（客户端名）解密得到的客户端名进行对比；
9. 如果客户端名一致，TGS服务器生成临时密钥K₂，然后产生SGT【K₂，客户端名，SGT有效期】，最后先用K₁ 加密K₂ 得到K₁ （K₂），再使用TGS服务器存储的固定密钥K_s2 对SGT进行加密，得到K_s2 （SGT）；
10. TGS服务器将【K₁ （K₂）和K_s2 （SGT）】发送给客户端；
11. 客户端使用K₁ 解密K₁ （K₂）得到K₂ ，使用密钥K₂ 对客户端名加密得到K₂（客户端名）；
12. 客户端将【K_s2 （SGT）、K₂（客户端名）和时间戳】发送给WEB应用服务器；
13. WEB应用服务器得到信息后，先用存储在本地的固定密钥K_s2解密K_s2 （SGT）后得到K₂和客户端名，再使用得到的K₂解密K₂（客户端名），将K_s2（SGT）和K₂（客户端名）解密得到的客户端名进行比对；
14. 客户端名一致，WEB服务器使用密钥K₂加密时间戳返回给客户端并提供服务；
15. 客户端通过密钥K₂验证WEB应用服务器是否合法。

---

AS服务器和TGS服务器上面都存储了固定密钥K_s1、K_s2，WEB应用服务器存储了固定密钥K_s2 。

---

流程图