网络安全 课件 第5、6章 接入控制和访问控制、安全协议_第1页
网络安全 课件 第5、6章 接入控制和访问控制、安全协议_第2页
网络安全 课件 第5、6章 接入控制和访问控制、安全协议_第3页
网络安全 课件 第5、6章 接入控制和访问控制、安全协议_第4页
网络安全 课件 第5、6章 接入控制和访问控制、安全协议_第5页
已阅读5页,还剩134页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

网络安全第五章第5章接入控制和访问控制本章主要内容身份鉴别;Internet接入控制过程;EAP和802.1x;RADIUS;Kerberos和访问控制过程。

5.1身份鉴别本讲主要内容身份鉴别定义和分类;主体身份标识信息;单向鉴别过程;双向鉴别过程;第三方鉴别过程。

一、

身份鉴别定义和分类1.定义身份鉴别是验证主体的真实身份与其所声称的身份是否符合的过程,主体可以是用户、进程和主机等。

一、

身份鉴别定义和分类2.分类身份鉴别方式可以分为单向鉴别、双向鉴别和第三方鉴别三种。

单向鉴别双向鉴别第三方鉴别二、主体身份标识信息1.密钥主体拥有某个密钥x,只要主体能够证明自己知道密钥x,主体的身份就得到证明。2.用户名和口令这种标识信息主要用于标识用户,为每一个授权用户分配用户名和口令,某个用户只要能够证明自己知道某个授权用户对应的用户名和口令,就能证明该用户是授权用户。

二、主体身份标识信息3.证书和私钥证书可以证明主体x与公钥PK之间的绑定关系,如果主体x能够证明自己知道与公钥PK对应的私钥SK,就能证明自己是主体x。

三、单向鉴别过程1.基于共享密钥主体A只需证明自己知道共享密钥K,即可证明自己身份。

三、单向鉴别过程2.基于用户名和口令主体A只需证明自己知道某个授权用户对应的用户名和口令,即可证明自己身份。

三、单向鉴别过程3.基于证书和私钥主体A与公钥PKA之间的绑定已经得到权威结构证明,主体A只要证明自己知道PKA对应的私钥SKA,即可证明自己身份。

四、双向鉴别过程1.基于共享密钥每一方不仅需要证明自己知道共享密钥,还需证明对方知道共享密钥。

四、双向鉴别过程2.基于用户名和口令用户A不仅需要证明自己知道某个授权用户对应的用户名和口令,还需对方证明知道该用户名对应的口令。

四、双向鉴别过程3.基于证书和私钥用户A和用户B与各自公钥之间的绑定得到权威机构证明,且用户A和用户B能够证明自己知道公钥对应的私钥。

五、第三方鉴别过程1.引出第三方鉴别的原因无需鉴别者拥有用于证明公钥与示证者之间绑定关系的证书。由权威机构提供与示证者绑定的公钥。且公钥与示证者之间的绑定关系由权威机构予以证明。

五、第三方鉴别过程五、第三方鉴别过程2.鉴别过程用户A和用户B与公钥之间的绑定关系由公钥管理机构提供且证明。用户A和用户B只需证明知道公钥对应的私钥。

5.2Internet接入控制过程本讲主要内容终端接入Internet需要解决的问题;PPP与接入控制过程。

一、终端接入Internet需要解决的问题1.终端访问网络资源的基本条件

建立终端A与路由器之间的传输路径;终端A完成网络信息配置过程;路由器路由表中建立对应路由项。

一、终端接入Internet需要解决的问题2.终端接入Internet的先决条件

终端接入Internet前,必须证明使用终端的用户是注册用户;在确定使用终端的用户是注册用户的前提下,由接入控制设备完成对终端分配网络信息,建立将终端的IP地址和终端与接入控制设备之间的传输路径绑定在一起的路由项的过程。

一、终端接入Internet需要解决的问题3.路由器与接入控制设备的区别

接入控制设备除了普通路由器的功能外,还具有以下接入控制功能:鉴别终端A用户的身份;为终端A动态分配IP地址;建立将终端A的IP地址和终端A与接入控制设备之间的传输路径绑定在一起的路由项等。

一、终端接入Internet需要解决的问题4.终端接入Internet过程

建立终端A与接入控制设备之间的传输路径;接入控制设备完成身份鉴别过程;动态配置终端A的网络信息;动态创建终端A对应的路由项。

二、PPP与接入控制过程1.PPP作为接入控制协议的原因

拨号接入过程建立点对点语音信道点对点语音信道与PPPPPP帧就是适合点对点语音信道传输的帧格式

二、PPP与接入控制过程2.与接入控制相关的协议

(1)PPP帧结构二、PPP与接入控制过程2.与接入控制相关的协议

(2)用户身份鉴别协议用用户名和口令标识用户身份;身份鉴别过程需要向接入控制设备证明自己知道某个授权用户对应的用户名和口令;CHAP防止泄露口令。二、PPP与接入控制过程2.与接入控制相关的协议

(3)IPCPIP控制协议(IPCP)的作用是为终端A动态分配IP地址等网络信息。二、PPP与接入控制过程3.PPP接入控制过程

接入控制过程由五个阶段组成,分别是物理链路停止、PPP链路建立、用户身份鉴别、网络层协议配置和终止PPP链路等。5.3

EAP和802.1X本讲主要内容引出EAP的原因;EAP操作过程;EAPoverPPP;802.1x操作过程。一、引出EAP的原因1.鉴别协议和载体协议PPP本身并不是一种鉴别协议,而是一种用于传输鉴别协议鉴别用户身份所需消息的载体协议,具体的鉴别过程由鉴别协议完成,如PPP支持的PAP和CHAP。一、引出EAP的原因2.应用环境和鉴别协议独立发展引发的问题和解决思路多种应用环境和多种鉴别协议两两组合带来的复杂性。一、引出EAP的原因2.应用环境和鉴别协议独立发展引发的问题和解决思路先定义一种和应用环境无关的、用于传输鉴别协议消息的载体协议,所有应用环境和鉴别协议都和这种载体协议绑定。二、EAP操作过程1.EAP操作模型鉴别者负责对用户身份进行鉴别,用户只有通过鉴别者的身份鉴别后才能接入。鉴别者向用户发送请求报文,用户向鉴别者回送响应报文。请求报文和响应报文的内容与双方采用的鉴别机制有关,不同的鉴别机制有着不同的请求/响应过程,有的鉴别机制可能需要经过多次请求/响应过程才能完成用户身份鉴别。二、EAP操作过程2.EAP报文格式编码字段给出报文的类型;标识符字段用来匹配请求和响应报文;长度字段给出EAP报文总的长度;数据字段的第1个字节是类型字段,用于给出数据类型。三、EAPoverPPP1.PPP封装EAP报文过程三、EAPoverPPP2.鉴别过程根据CHAP交换鉴别信息;鉴别信息交换过程通过EAP请求/响应过程完成;EAP报文封装成PPP帧。四、802.1X操作过程1.802.1X操作模型

用户接入以太网方式四、802.1X操作过程1.802.1X操作模型一个物理端口被虚化成2个虚端口,一个是受控端口,只有在成功完成用户身份鉴别后,才能提供正常的输入输出服务。另一个是非受控端口,用于接收EAP报文和其他广播报文。四、802.1X操作过程2.EAPOL报文类型和封装格式版本字段值目前固定为2,报文类型表明封装在MAC帧中的报文类型,目前定义了5中报文类型。报文体长度和报文体由报文类型决定。报文类型字段值报文类型描述0EAP报文报文体为EAP报文。1EAPOL-Start鉴别发起报文,用于由用户发起的鉴别过程。2EAPOL-Logoff退出报文,用于退出端口的授权状态。3EAPOL-Key密钥报文,用于交换密钥,用于无线局域网。4EAPOL-ASF-Alert报警报文,当受控端口处于非授权状态时,用于交换机接收报警消息。四、802.1X操作过程3.802.1X鉴别接入用户身份的过程

四、802.1X操作过程4.以太网接入控制过程当某个用户希望接入Internet时,通过发送EAPOL-Start发起鉴别过程。一旦成功完成用户身份鉴别过程,交换机将该终端的MAC地址列入接收到EAP报文的端口对应的访问控制列表,并将访问控制设置为允许访问。5.4RADIUS本章主要内容RADIUS功能;RADIUS消息格式、类型和封装过程;RADIUS应用。一、RADIUS功能1.本地鉴别和统一鉴别1.本地鉴别和统一鉴别本地鉴别方式由接入控制设备完成对接入用户的身份鉴别过程,因此,对于允许同一用户多点接入Internet的情况,如果采用本地鉴别方式,每一个接入控制设备中需要存储所有接入用户的身份标识信息。统一鉴别方式设置鉴别服务器,由鉴别服务器统一管理用户,完成对用户的身份鉴别、授权和计费操作。一、RADIUS功能一、RADIUS功能2.身份标识信息传输协议为了完成鉴别者和鉴别服务器之间的EAP报文传输过程,必须定义一种载体协议。由于鉴别者和鉴别服务器之间的传输通路往往是由路由器互连的多段链路层传输路径组成的,因此,必须用IP以上的协议作为载体协议,远程鉴别拨入用户服务(RADIUS)是一种可以实现接入控制设备等鉴别者与鉴别服务器之间双向身份鉴别和身份标识信息鉴别者与鉴别服务器之间安全传输的应用层协议。二、RADIUS消息格式、类型和封装过程1.RADIUS消息封装过程

RADIUS属于应用层协议,因此,RADIUS消息先封装成传输层报文,然后把传输层报文封装成IP分组。

二、RADIUS消息格式、类型和封装过程2.RADIUS消息格式和类型

编码字段给出RADIUS消息类型,目前主要定义了4种RADIUS消息。请求接入消息用于传输用户提供的身份标识信息,如用户名、口令等。允许接入消息表明鉴别服务器完成对用户的身份鉴别,允许用户接入网络。拒绝接入消息表明用户提供的身份标识信息无法使鉴别服务器完成对用户的身份鉴别,鉴别服务器拒绝用户接入网络。挑战接入消息或者需要用户通过请求接入消息提供更多的身份标识信息,或者需要用户根据约定的鉴别机制对挑战接入消息中包含的数据进行运算,并将运算结果通过请求接入消息提供给鉴别服务器。二、RADIUS消息格式、类型和封装过程2.RADIUS消息格式和类型

标识符字段用于匹配请求接入消息和对应的响应消息。长度字段给出RADIUS消息的总长。鉴别信息字段用于鉴别发送响应消息的鉴别服务器,响应消息中的鉴别信息=MD5(响应消息‖对应请求接入消息的鉴别信息‖共享密钥K),响应消息指响应消息中除鉴别信息字段外的所有其他字段信息,包括编码、标识符、长度和所有属性字段。属性字段给出用户身份标识信息和NAS标识信息。二、RADIUS消息格式、类型和封装过程2.RADIUS消息格式和类型

RADIUS消息交换过程三、RADIUS应用RADIUS和EAP协调完成用户身份鉴别过程5.5Kerberos和访问控制过程本讲主要内容访问控制过程;鉴别服务器实施统一身份鉴别机制;Kerberos身份鉴别和访问控制过程。一、访问控制过程1.基于共享密钥的访问控制过程访问控制的基础是身份鉴别和授权;用共享密钥鉴别身份;授权用户列表进行授权。一、访问控制过程1.基于共享密钥的访问控制过程解决的安全问题:防止其他非授权用户通过冒充授权用户非法访问应用服务器;防止其他非授权用户通过盗用授权用户的IP地址非法访问应用服务器;防止非法用户通过嗅探或截获授权用户的访问请求,实施重放攻击。因此鉴别信息=EKC,S(IDC‖ADC‖T‖SEQ)IDC是用户名,ADC是用户终端IP地址,T是时间戳,SEQ是序号。一、访问控制过程2.应用服务器鉴别用户身份的缺陷一是每一个应用服务器都需建立包含所有授权用户信息的授权用户列表;二是一次事务中,多个应用服务器可能需要重复多次鉴别某个用户的身份;三是不容易实现双向鉴别,只有应用服务器对用户的单向身份鉴别过程。二、鉴别服务器实施统一身份鉴别机制1.统一鉴别方式的访问控制过程设置统一的鉴别服务器,鉴别服务器中给出授权用户身份标识信息和授权访问的应用服务器;鉴别服务器通过用户C与鉴别服务器之间的共享密钥KC,AS实现对用户C的身份鉴别;应用服务器1和2通过与鉴别服务器之间的共享密钥K1,AS和K2,AS建立信任关系;票据1必须证实两点:一是票据1由鉴别服务器签发,二是用户C具有访问应用服务器1的权限,且票据1中的信息能够证明票据1的拥有者是用户C;鉴别信息1向应用服务器证实该访问请求确实由用户C发送票据1=EK1,AS(IDC‖ADC‖KC,1‖TS‖TE);鉴别信息1=EKC,1(IDC‖ADC‖T‖SEQ)。二、鉴别服务器实施统一身份鉴别机制2.鉴别服务器实施用户权限鉴别的缺陷一是一次事务中,如果用户需要访问多个应用服务器,同样需要进行多次身份鉴别过程。二是将用户身份标识信息和用户访问权限集中在鉴别服务器中,会使得鉴别服务器成为应用系统的性能瓶颈。二、鉴别服务器实施统一身份鉴别机制三、Kerberos身份鉴别和访问控制过程1.用户身份鉴别鉴别服务器发送给用户C的票据TicketTGS证实:一是票据TicketTGS由鉴别服务器签发,用于向票据授权服务器证明用户C的身份,二是该票据由用户C拥有;用户C通过证明已经获得会话密钥KC,TGS证明自己是用户C。三、Kerberos身份鉴别和访问控制过程2.获取访问应用服务器票据票据TicketTGS用于证实票据确实由鉴别服务器签发,由用户C拥有,用于证明用户C的身份和用户C访问票据授权服务器TGS的权限;鉴别信息用于证实访问权限鉴别请求确实由用户C生成和发送;票据TicketV表明用户C具有访问应用服务器IDV的权限。三、Kerberos身份鉴别和访问控制过程3.访问应用服务器票据TicketV证实用户C具有访问应用服务器的权限;鉴别信息AUTHC2证实该访问请求确实由用户C生成和发送;应用服务器IDV用票据授权服务器TGS动态生成的用户C与应用服务器IDV之间的会话密钥KC,V来证实自己的身份。三、Kerberos身份鉴别和访问控制过程网络安全第六章第6章安全协议本章主要内容安全协议概述;IPSec;TLS;应用层安全协议;IPSec、TLS和应用层安全协议比较。6.1安全协议本讲主要内容产生安全协议的原因;安全协议功能;安全协议体系结构。一、产生安全协议的原因已有通信协议存在以下安全问题源端鉴别问题;数据传输的保密性问题;数据传输的完整性问题;身份鉴别问题。二、安全协议功能双向身份鉴别;数据加密;数据完整性检测;防重放攻击机制。三、安全协议体系结构每一种传输网络有着该传输网络对应的安全协议;网际层有Internet安全协议(IPSec);传输层有安全协议安全插口层(SSL),或者传输层安全(TLS);应用层有实现电子邮件安全传输的PGP,用于实现电子安全支付的安全电子交易(SET),用于安全访问网站的基于SSL/TLS的HTTP(HTTPS)等。6.2IPSec本讲主要内容IPSec概述;AH;ESP;IKE。一、IPSec概述1.安全关联(1)安全关联定义这种以实现源端鉴别、数据加密和完整性检测为目的的关联称为安全关联(SA)。安全关联是单向的。安全关联用安全参数索引(SPI)、目的IP地址和安全协议标识符唯一标识。一、IPSec概述1.安全关联一、IPSec概述1.安全关联(2)建立数据与安全关联之间的绑定SPD的目的是将数据分类,然后对不同类的数据施加不同的安全策略,这些安全策略可以是丢弃、使用IPSec和不使用IPSec。分类数据的依据是数据的源和目的IP地址、数据所使用的传输层协议、传输层源和目的端口号、传输数据使用的安全协议、数据所要求的服务类型等。一、IPSec概述1.安全关联(3)安全关联相关参数序号:32位长度,用于防止重放攻击。防重放攻击窗口:用于确定接收到的AH或ESP报文是否是重放报文。AH信息:消息鉴别码(MAC)算法,MAC密钥,MAC密钥寿命,及其他用于AH的参数。ESP信息:加密算法和加密密钥,MAC算法和MAC密钥,密钥寿命,及其他用于ESP的参数。安全关联寿命:可以是一段用于确定安全关联存在时间的时间间隔,也可以是安全关联允许发送的字节数。IPSec协议模式:目前定义了两种模式,传输和隧道。路径最大传送单元(MTU):不用分段可以在安全关联绑定的发送端和接收端之间传输的最大分组长度。一、IPSec概述2.传输模式和隧道模式传输模式用于保证数据端到端安全传输,并对数据源端进行鉴别,这种模式下,IPSec所保护的数据就是作为IP分组净荷的上层协议数据,如TCP、UDP报文和其他基于IP的上层协议报文。一、IPSec概述2.传输模式和隧道模式安全关联的两端是隧道的两端。源端至目的端的IP分组作为净荷封装在以路由器R1的全球IP地址为源IP地址,路由器R2的全球IP地址为目的IP地址的IP分组中,这种将整个IP分组作为另一个IP分组的净荷的封装方式就是隧道格式。一、IPSec概述3.防重放攻击过程黑客可以重复转发截获的AH或ESP报文,或是延迟一段时间后,再转发截获的AH或ESP报文。一、IPSec概述3.防重放攻击过程目的端每接收到一个AH或ESP报文,执行如下操作:如果报文序号小于N-W+1,或者该序号对应的报文已经正确接收,丢弃该报文。如果报文序号在窗口范围内,且未接收过该序号对应的报文,接收该报文并将该序号对应的标志改为已正确接收该序号对应的报文。如果报文序号大于N,假定为L(L>N),将窗口改为L-W+1~L,并将序号L对应的标志改为已正确接收该序号对应的报文。二、AH1.AH报文格式传输模式下,在IP首部和净荷之间插入鉴别首部AH。二、AH1.AH报文格式隧道模式下,整个IP分组作为隧道格式的净荷,在外层IP首部和净荷之间插入鉴别首部AH。二、AH1.AH报文格式隧道模式下,整个IP分组作为隧道格式的净荷,在外层IP首部和净荷之间插入鉴别首部AH。二、AH1.AH报文格式下一个首部:指出净荷的协议类型。鉴别首部长度:以32位为单位给出AH的总长,实际的鉴别首部长度=AH总长-2。安全参数索引(SPI):接收端将其和AH报文的目的IP地址和IP首部(隧道模式下的外层IP首部)中IPSec协议类型一起用于确定AH报文所属的安全关联。序号:用于防重放攻击。鉴别数据:消息鉴别码(MAC),用于鉴别源端身份和实现数据完整性检测。二、AH2.AH应用实例终端A与Web服务器之间建立终端A至web服务器的安全关联,用SPI=1234、目的IP地址=和安全协议标识符=AH唯一标识该安全关联。经过安全关联传输的IP分组封装成AH报文。建立安全关联时双方约定MAC算法为HMAC-MD5-96,MAC密钥为7654321。二、AH2.AH应用实例(a)发送端操作过程

(b)接收端操作过程AH源端鉴别和完整性检测过程三、ESP传输模式下,IP首部和净荷之间插入ESP首部,IP首部中的协议字段值为50,表明是ESP报文。净荷字段后面是ESP尾部。三、ESP隧道模式下,净荷是包括内层IP首部在内的整个IP分组。三、ESPESP首部包含安全参数索引(SPI)和序号,它们的作用和AH相同。ESP尾部包括填充数据、8位的填充长度字段和8位的下一个首部字段。填充长度字段值以字节为单位给出填充数据长度,下一个首部字段给出净荷的协议类型。计算鉴别数据时覆盖的字段只包括ESP首部+净荷+ESP尾部。四、IKE1.静态安全关联和动态安全关联静态安全关联建立机制由人工完成发送端和接收端中安全关联数据库(SAD)的配置过程。动态安全关联建立机制根据安全传输数据的需要,通过协议建立发送端至接收端的安全关联,协商与该安全关联相关的参数。四、IKE1.静态安全关联和动态安全关联发送端启动IKE过程四、IKE1.静态安全关联和动态安全关联建立终端A至web服务器的动态安全关联,采用证书+私钥方式鉴别对方身份。四、IKE2.IKE相关配置终端A和Web服务器B与第一阶段有关的配置如下。鉴别方式:证书+私钥加密算法:DESMAC算法:MD5密钥分发协议:Diffie-Hellman,选择组号为2的参数。终端A和Web服务器B与第二阶段有关的配置如下。安全协议:AHMAC算法:HMAC-MD5-96四、IKE3.IKE建立安全关联过程

IKE动态建立安全关联过程分为两个阶段,第一个阶段是建立安全传输通道,第二个阶段是建立安全关联。建立安全传输通道的目的是可以安全传输为建立安全关联而相互交换的信息。6.3TLS本讲主要内容TLS引出原因和发展过程;TLS协议结构;TLS记录协议;握手协议实现身份鉴别和安全参数协商过程;HTTPS。

一、TLS引出原因和发展过程1.引出原因对于许多客户/服务器(C/S)应用结构,实现双向身份鉴别与保证相互交换的数据的保密性和完整性是非常重要的。必须有一套用于完成双向身份鉴别和安全参数协商的协议。一、TLS引出原因和发展过程2.TLS发展过程

TLS的前生是安全插口层(SSL)。

IETF在SSLv3.0的基础上提出了TLS1.0,目前TLS的最新版本是TLS1.2。二、TLS协议结构TLS记录协议用于封装上层协议消息,通过TLS记录协议传输的上层消息可以实现源端鉴别、保密性和完整性。二、TLS协议结构TLS握手协议是一种实现身份鉴别和安全参数协商的协议。客户端和服务器端通过TLS记录协议传输数据前,需要通过TLS握手协议完成双向身份鉴别过程,并约定压缩算法、加密算法、MAC算法、加密密钥、MAC密钥等安全参数。通信双方约定新的安全参数后,通过TLS改变密码规范协议通知对方开始使用新约定的安全参数。报警协议用于传输出错消息,如解密失败、无法确认证书等。三、TLS记录协议由于上层消息的长度可以任意,但TLS压缩后的数据的长度不能超过214B,当单个TLS记录协议报文无法容纳上层消息时,必须对上层消息分段,保证每一段上层消息能够封装成单个TLS记录协议报文。如果通信双方需要对传输的数据进行加密和完整性检测,必须根据压缩后的数据计算消息鉴别码(MAC),并对压缩后的数据和MAC进行加密运算。三、TLS记录协议内容类型:上层消息类型,如TLS握手协议消息,HTTP消息等。主版本号:对于TLS,固定为3。次版本号:对于TLS,固定为1。压缩数据长度:加密操作前上层消息长度。四、握手协议实现身份鉴别和安全参数协商过程1.约定算法阶段1用于双方对压缩算法、加密算法、MAC算法及TLS协议版本达成一致。四、握手协议实现身份鉴别和安全参数协商过程2.验证服务器证书基于证书+私钥的鉴别机制鉴别服务器V身份的过程如下:服务器V向客户C提供由认证中心颁发的、证明IDV和公钥PKV绑定关系的证书。客户C根据证书链确定公钥PKV和IDV的绑定关系。3.生成主密钥与验证客户证书如果服务器V要求鉴别客户C的身份,阶段3一开始就由客户C通过客户证书消息向服务器V发送证书链,服务器V能够根据客户C发送的证书链验证证明IDC和公钥PKC绑定关系的证书。客户C为了确认服务器V拥有和公钥PKV对应的私钥SKV,用公钥PKV加密客户C选择的预主密钥(PMS)(Y=EPKV(PMS)),并通过交换密钥消息将密文EPKV(PMS)发送给服务器V。客户C发送的证书链只能证明IDC和公钥PKC之间的绑定关系,要证明客户C的用户名为IDC,还需证明客户C拥有和公钥PKC对应的私钥SKC。为了证明这一点,客户C发送的证实证书消息中包含客户C用私钥SKC对双方交换的握手协议消息的报文摘要进行解密运算后得到的密文(Y=DSKC(MD(握手协议消息)))。四、握手协议实现身份鉴别和安全参数协商过程四、握手协议实现身份鉴别和安全参数协商过程4.双方身份鉴别和安全参数切换要证明服务器V拥有和公钥PKV对应的私钥SKV,只需证明服务器V得到了预主密钥PMS。要证明服务器V得到了预主密钥PMS,只需证明服务器V计算所得的主密钥MK和客户C计算所得的主密钥MK相同。

这是以种子和密钥作为随机数种子,产生任意长度随机数的伪随机数生成算法;HAMC保证随机数种子和随机数一一对应,且又无法根据随机数推导出随机数种子。四、握手协议实现身份鉴别和安全参数协商过程五、HTTPS1.基于TLS的HTTP在TCP基础上建立TLS安全连接,经过TLS安全连接实现对Web服务器的身份鉴别,浏览器和Web服务器之间传输的HTTP消息的保密性、完整性和源端鉴别。五、HTTPS2.HTTPS操作过程用证书证明服务器域名和公钥PKS的绑定;终端用PKS加密预主密钥,预主密钥是生成密钥的主要参数;一旦确认服务器和终端生成相同的密钥,服务器身份得到确认;终端和服务器用约定的加密解密算法和密钥实现数据的安全传输。由于TLS约定的安全参数只有终端和服务器知道,因此,加密和消息认证码计算过程本身具有认证发送者身份的作用;消息认证码用于完整性检测,序号保证顺序接收TLS记录协议报文;用三重DES加密需要传输的数据。五、HTTPS3.HTTPS安全传输HTTP消息过程本讲主要内容DNSSec;SET;PGP;S/MIME。6.4应用层安全协议域名服务器采用层次结构,根域名服务器负责管理顶级域名,每一个顶级域名有着对应的域名服务器,根域名服务器通过类型为NS的资源记录建立每一个顶级域名与对应的域名服务器之间的关联。一、DNSSec一、DNSSec一、DNSSec终端A选择域域名服务器作为本地域名服务器。终端A中分配DNS缓冲区,终端A完成域名解析后,建立某个完全合格的域名与对应的IP地址之间的映射,并将该映射保存在DNS缓冲区中一段时间。完成迭代解析过程。一、DNSSec域名解析过程存在两个安全问题:一是DNS响应消息的接收端没有源端鉴别机制,使得黑客终端可以伪造DNS响应消息,并将伪造的DNS响应消息发送给终端或本地域名服务器,导致终端或本地域名服务器将某个完全合格的域名和错误的IP地址绑定在一起,而这个错误的IP地址往往就是某个黑客终端的地址。二是黑客可以篡改DNS响应消息,通过篡改DNS响应消息中域名服务器的IP地址或某个完全合格的域名与IP地址之间的绑定关系,使得终端或本地域名服务器得到错误的上级域名服务器地址或某个完全合格的域名与错误的IP地址之间的绑定关系。一、DNSSec解决上述安全问题的思路如下:接收到DNS响应消息时,一是必须对DNS响应消息进行源端鉴别。二是必须对DNS响应消息进行完整性检测,只对通过源端鉴别和完整性检测的DNS响应消息进行处理,以此避免接收黑客伪造或篡改的DNS响应消息的情况发生。一、DNSSec域名服务器中的资源记录主要由下述字段组成:<名字,类别,类型,值>以下是DNSKEY类型的资源记录例子,是域名,PKBE是与域名绑定的公钥。IN DNSKEY PKBE以下是RRSIG类型的资源记录例子,是产生数字签名的域名服务器负责管理的域的域名,数字签名是该域名服务器用私钥对需要数字签名的资源记录的报文摘要进行解密运算后的结果。IN RRSIG 数字签名一、DNSSec一、DNSSec每一个域生成私钥和公钥对,如root域的公钥是PKR,私钥是SKR,私钥SKR由根域名服务器掌握。每一个域名服务器需要配置上一级域域名服务器的公钥,如域域名服务器通过类型为NS的资源记录指定com域域名服务器和根域名服务器这两个上一级域域名服务器,因此,需要通过DNSKEY类型的资源记录指定com域的公钥PKC和root域的公钥PKR。一、DNSSec终端A配置的本地域名服务器为域域名服务器,且终端A已经具有域的公钥PKAC。本地域名服务器向根域名服务器发送完全合格的域名的解析请求。根域名服务器向本地域名服务器回送edu域域名服务器的IP地址、edu域的公钥PKE和用root域的私钥SKR产生的数字签名DSKR(SHA-1((

)‖(eduPKE)))。二、SETSET应用系统用于实现电子购物;既要保证持卡人的私密信息只在持卡人和发卡机构之间传输,又要保证商家权益;信息只能在指定的发送端和接收端之间传输,即必须对发送端进行身份认证,只有指定接收端才能获得信息。SET应用系统持卡人封装处理过程一是需要认证发送者身份,二是保证只有指定接收者才能获得信息,三是持卡人不能否定发送过的购物请求;认证发送者身份和无法否认发送过的购物请求通过数字签名实现,数字签名=DSKC(H(P));SKC是发送者私钥,H是报文摘要算法。明文、数字签名和证明发送者和公钥之间绑定的证书用3DES加密算法加密,并将密钥用指定接收者的公钥加密,因此,只有指定接收者才能还原密钥,并因此获得明文、数字签名和证书。二、SET持卡人封装过程指定商家才能用私钥解密出密钥KEY,并因此获得明文、数字签名和证书;对明文P进行报文摘要运算,对数字签名用证书给出的公钥进行加密运算,然后对两者进行比较,如果相等:一是证明由证书指定的发送者发送,二是明文确实是发送者发送的明文。这样,完成了发送者身份认证、数字签名认证和完整性检测。二、SET商家认证发送者身份和解密数据过程双重签名的目的是证明两份报文的关联性,不仅通过数字签名证实由发送者发送,而且证实这两份报文和同一事务相关;这里需要证明支付信息和购货信息是对应的,是与同一次电子购物相关的两份报文。二、SET双重签名过程持卡人、商家和支付网关需要获得由认证中心签发的证书;选择商品,得到商家发送的定货信息;向商家提供定货信息和支付信息;商家认证支付信息;商家提供商品。二、SET电子交易过程购买请求消息在获得商家提供的购物清单后发送;根据购物清单构件定货信息和支付信息,定货信息发送给商家,支付信息由商家用于认证持卡人的支付能力,为了将定货信息和支付信息绑定在一起,持卡人采用双重签名;为了上支付网关和商家认证双重签名,发送给商家的信息中包含支付信息的报文摘要,发送给支付网关的信息中包含订货信息的报文摘要;为了区别信息的接收者,分别用支付网关和商家的公钥加密发送给它们的信息。二、SET购买请求消息封装过程商家验证双重签名,确定定货信息的发送者和双重签名证实的支付信息的报文摘要;对发送给支付网关的密文不作处理,用于生成用于验证持卡人支付能力的授权请求消息。二、SET商家验证双重签名过程授权请求信息的目的是验证持卡人的支付能力;支付信息中除了有关账户、密码等私密信息,还有交易标识符和支付金额等与本次交易关联的信息;授权信息中同样提供交易标识符和支付金额等与本次交易有关的信息,便于支付网关验证。二、SET商家封装授权请求消息过程认证支付信息发送者身份和授权请求消息发送者身份;认证双重签名,确认支付信息和订货信息之间的关联;根据商家提供的授权信息和持卡人提供的支付信息验证持卡人的支付能力。二、SET支付网关验证授权请求消息过程支付网关验证持卡人支付能力后,向商家提供承兑凭证,一旦商家提供已向持卡人提供商品或服务的证据,即可凭承兑凭证要求电子转账;商家不能处理承兑凭证;授权信息由支付网关数字签名,用于向商家通告验证持卡人支付能力的结果。二、SET支付网关封装授权响应消息过程商家向持卡人提供商品或服务后,要求支付网关完成电子转账;商家提供支付网关提供的承兑凭证和请求消息;请求消息中给出本次

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论