(2) A安全的获取到共享密钥Ks

(3) B安全的获取到共享密钥Ks

N1:该次传输的唯一标识N1，称为临时交互号(nonce)。临时交互号可以选择时间戳、随机数或者计数器等。KDC可根据临时交互号设计防重放机制。

（2）中的N1用来帮助A验证当前KDC是针对之前具有N1的会话请求的回应；并且消息(1)没有被篡改

特点：该协议保证了密钥分发的保密性，但没有实现A、B之间的相互认证

缺陷：易受到重放攻击（攻击者C嗅探了A、B之间的以前的密钥协商交互报文，C将之前A的步骤(2)重放给B）

预防：增加B对A的身份验证

3）改进N-S协议（KA、KB是A、B的主密钥）

(4) A通过得到随机数N2了解B已经安全获取了Ks

        (5)B通过得到随机数N2的散列值了解到A也已经安全获取了Ks

        (4)和(5)保证双方确认得到的ks是对等的

具体步骤：

        （1）A以明文形式向KDC发送会话密钥请求包。包括通话双方A、B的身份以及该次传输的唯一标识N1，称为临时交互号(nonce)。

        （2）KDC返回的信息包括两部分。第一部分是A想获取的信息，用A的主密钥KA加密，包括通话密钥Ks和KDC收到的请求包内容用以验证消息到达KDC前是否被修改或者重放过。第二部分是B想获取的信息，用B的主密钥KB加密，包括通话密钥Ks和A的身份。A收到后这部分消息便原样发给B。

        （3）A将收到消息的第二部分原样发给B。

为保证A发给B的会话密钥信息被重放攻击，A、B使用会话密钥进行最后的验证。

        （4）B使用新的会话密钥Ks加密临时交互号N2并发给A。

        （5）A对N2进行一个函数变换后，用会话密钥发给B验证。

缺陷（脆弱性）：假如攻击者C通过某种方式获取过期的会话密钥。因此，除非B能够无限期记得所有与A通信的会话密钥，否则不能确定这类重放攻击。C可以构造如下重放攻击：

·C 重放消息(3); C->B: E(Kb, ks’||IDA) ，B获取 ks’

·收到到 B 的消息(4); B->A(C): E( ks’, N2),被C截获

·使用已经获取的 ks 产生伪造消息(5);   C->B: E(KS’, f(N2))

·C 、 B 使用 ks进行通信   C,B 通信

预防：在报文中增加时间戳；接收方用对方的时间戳字段验证报文是否过期

4）对改进后的N-S协议增加时间戳

        第（3）步B验证时间戳的有效性，第（5）步B验证N1

缺陷：基于时间戳的协议，通信方之间需要时钟同步，易受到抑制重放攻击

攻击步骤：

        1. 攻击者使得KDC时钟快于B的时钟

        2. 攻击者->B，重放旧的消息（3）；B收到后进行T的有效性验证；由于调快了KDC时钟，使得下式左侧比正常更小，更容易通过时间校验

        3. 收到B的消息（4），攻击者产生自己消息（5），并发送给B

        4. B比较两个N2是相同的，认为对方和自己的KS对等，从而互信

5）避免时钟同步的改进

Na或Nb不需要加密，T需要加密。Tb只与B有关，只有B检查该时间戳。

步骤2，B产生Tb,Nb，Tb是加密传输，Nb是明文传输

步骤3，A收到消息(3)后，使用Na验证ks的会话关联性

步骤4，B收到消息(4)后，使用Nb验证ks的会话关联性。使用Tb验证ks的新鲜性

6）避免时钟同步的后续协商

若A、B利用协议建立了一次会话并结束。若在协议限制时间内A又希望与B通信，可进行以下协商

（2）基于非对称密钥：无需第三方分发机构（某一方产生对称密钥）

1）PUA 、PRA表示A的公钥/私钥，采用以下方式：

缺陷：易受到中间人攻击（攻击者C冒充用户A，向B发送消息PUC||IDA，使得B以为自己在和A进行认证）

解决方法：双向握手认证

2）双向认证

双方使用握手协议交换密钥，N1和N2是双方产生的随机数

步骤(1)-(2)：A确认B的身份

步骤(3)-(4)：B确认A的身份，同时A分发密钥

3.单向认证

1）只考虑消息保密

2）只考虑认证

二、数字证书

1.引入

公钥可以从互联网、对方直接发送获取。

以下认证协议无法保证A获取到的B的公钥一定安全

解决思路：使用第三方认证机制，确认公钥和拥有者的绑定关系

2.数字证书

（1）定义

证明了实体所声明的身份和其公钥绑定关系的一种电子文档，是将公钥和确定属于它的某些信息（比如该密钥对持有者的姓名、电子邮件或者密钥对的有效期等信息）相绑定的数字申明。由可信的CA(Certification Authority)认证机构颁发。

（2）数字证书的签名和验证

（3）数字证书的应用

3.X.509证书标准

版本号：该域定义了证书的版本号，这将最终影响证书中包含的信息的类型和格式，目前版本4已颁布，但在实际使用过程版本3还是占据主流。

序列号：序列号是赋予证书的唯一整数值。它用于将本证书与同一CA颁发的其他证书区别开来。

签名算法标识：该域中含有CA签发证书所使用的数字签名算法的算法标识符，如SHA1WithRSA。有CA的签名，便可保证证书拥有者身份的真实性，而且CA也不能否认其签名。

颁发者X500名称：这是必选项，该域含有签发证书实体的唯一名称（DN），命名必须符合X.500格式，通常为某个CA。

证书有效期：证书仅仅在一个有限的时间段内有效。证书的有效期就是该证书的有效的时间段，该域表示两个日期的序列：证书的有效开始日期（notBefore），以及证书有效期结束的日期（notAfter）。

证书持有者X500名称：必选项，证书拥有者的可识别名称，命名规则也采用X.500格式。

证书持有者公钥：主体的公钥和它的算法标识符，这一项是必选的。

证书颁发者唯一标识号：这是一个可选域。它含有颁发者的唯一标识符。

证书持有者唯一标识号：证书拥有者的唯一标识符，也是可选项。

证书扩展部份：证书扩展部份是V3版本在RFC2459中定义的。可供选择的标准和扩展包括证书颁发者的密钥标识、证书持有者密钥标识符、公钥用途、CRL发布点、证书策略、证书持有者别名、证书颁发者别名和主体目录属性等。

4.证书链

通常，证书并不会被根CA直接认证。CA机构间存在链式认证关系。

如下例：Root->Issuer->Owner 。

验证方在提取公钥之前，必须验证证书的真实性

数字证书的链式验证——自下而上获取公钥证书，自上而下验证公钥（以浏览器为例）

1. 浏览器请求并获取Issuer证书，其原因是为了验证Owner公钥证书的真实性，需要获取Issuer的公钥。

2. 浏览器请求并获取root证书。

3. 浏览器使用PUroot验证Issuer的公钥证书，方法是，浏览器使用PUroot解签名Issuer公钥证书签名，获的Issuer公钥证书的摘要；其次，浏览器自己用Issuer公钥证书中指定的摘要算法对Issuerg公钥证书产生一个本地摘要，对比两个摘要，若相同，验证通过。

注：这部分需要理解数字证书的产生和验证

4. 浏览器从Issuer的公钥证书中获取Issuer公钥，并用于验证Owner证书的真实性，验证方法同步骤3。若验证成功，表示Owner公钥证书是可靠的，其所含的Owner是可用的。

因此，公钥证书中的公钥不是直接使用，首先需要验证公钥证书，通过后再使用。