《信息安全引论》课件chapter9

上传人:考试不挂****2941... 文档编号:242975493 上传时间:2024-09-13 格式:PPT 页数:69 大小:1.17MB
返回 下载 相关 举报
《信息安全引论》课件chapter9_第1页
第1页 / 共69页
《信息安全引论》课件chapter9_第2页
第2页 / 共69页
《信息安全引论》课件chapter9_第3页
第3页 / 共69页
点击查看更多>>
资源描述
单击此处编辑母版标题样式,*,单击此处编辑母版文本样式,第,9,章,Web Security,目前,所有的工商企业、大多数政府机构以及许许多多的个人都建起了自己的网站,这些网站都可以通过互联网进行访问。企业对利用网络开展电子商务情有独钟。但现实是互联网与,Web,服务对于各种攻击非常脆弱。伴随着企业对这种安全现实的苏醒与担忧,对于,Web,安全的需求则迅速扩张。,Web,安全可以随便写一本书,本章只讨论,Web,安全的一般要求,重点讲述,web security,协议族:,SSL,协议,(SSLV2,、,SSLV3),、,TLS,协议和,SET,协议。,Web Security,第,1,节,Web,安全考虑,第,2,节,SSL,第,3,节,SET,小结,本章介绍了,Web,安全需要考虑的一些问题,介绍了这些问题的解决方案,主要介绍了,SSL,协议与,SET,协议。讲述了,SSL,协议的细节,讲述了,SET,协议的交易过程。这里还有许多可以改进的地方,需要增加银行处理的图,对讲解顺序进行重新组织。可以考虑直接从现实的处理过程讲解。,思考题,(1),基于本章所学习的内容,在,SSL,协议中,接收者能不能记录下按不正常顺序到达的记录包?如果可以,解释需要怎样做。如果不可以,请解释为什么?,(2),你认为,SET,协议与,SSL,协议,还有没有安全漏洞?如有,试提出一种弥补方法。,结束语,到此为止本门课程结束了,感谢大家的配合我们在一起度过了愉快的一学期。你们也即将毕业走向工作岗位了。祝你们都能够找一个理想的工作。希望你们通过自己的努力能够成为科学的巨匠、祖国的栋梁。希望你们中间能够涌现出一批政治家、科学家、企业家。好像早上,8,、,9,点钟的太阳,希望寄托在你们身上。苟富贵,勿相忘。今后无论你们在工作还是学习中有需要我帮助的话,我一定竭尽全力。同学们,再见!,第,1,节,Web Security Considerations,www,基本上是一种运行在互联网或者,TCP/IP,内部网络中的,B/S,应用。所有的安全措施都与,Web Security,相关,但,Web,对网络安全提出了一些新的挑战。比如:,(1),互联网是双向的,因此运行在互联网上的,Web,服务器易于受到攻击;,(2) Web,已经成为展示公司与产品窗口,成为公司对外交流的出口,成为进行交易的支承平台。如果,Web,收到破坏将会造成财产的损失和声誉下降。,Web Security Considerations,(3) Web,服务器可以作为进入公司内部复杂的计算机系统的跳板,一旦,Web,服务器被攻破,攻击者就可以访问与服务器相连的数据与系统。,(4),未经过训练的、粗心大意的用户一般是,Web,服务的主要用户。这些用户没有必要的安全意识,意识不到可能存在的安全风险,也没有采取有效应对措施所需要的工具和知识。,Web,安全威胁,完整性,修改用户数据、特洛伊木马浏览器、修改存储、修改传输的信息流量,密码学校验,机密性,窃听、盗窃服务器信息、盗窃用户数据、获得网络配置信息、获得用户与服务器对话信息,加密、,Web,代理,拒绝,服务,切断用户线程、伪造线程淹没服务器、占满磁盘或内存、用,DNS,攻击孤立服务器,难于防范,认证,冒充合法用户、伪造数据,密码学技术,Web,安全威胁,Web,安全威胁可以有不同的分类,第,1,种分为主动攻击与被动攻击:被动攻击包括在服务器与浏览器之间搭线窃听获得访问某个网站的访问信息,而这个网站是不允许他们访问的。主动攻击包括冒充另一个用户、修改客户端和服务器之间传递的信息、修改网站信息等。第,2,种根据威胁的位置分为:,Web,服务器威胁、,Web,浏览器威胁、浏览器与服务器之间的网络流量威胁。,BACK,第,2,节,SSL,SSL,是,Netscape,公司设计的协议,该协议有三个版本:,SSLV1,、,SSLV2,、,SSLV3,。其中第,1,个版本根本就没有投入使用,,Microsoft,对,V2,进行了改进,修补了一些安全漏洞,提出了一个类似的协议,PCT,。后来,Netscape,对协议进行了彻底的改进,得到了,SSLV3,。这是目前应用得最广泛的协议。,TLS,则把密钥扩展和认证使用的密码算法结合在一起,更符合密码学家的期望,但,SSL,和,TLS,不能互操作。,SSL,SSL,是在用户级进程中运行的协议。,SSL/ TLS,可以部署在用户级别的进程中,不需要对操作系统进行修改,协议非常简单,也不需要考虑超时和丢失数据包重传这类问题。当然也可以运行在,UDP,协议之上,在,SSL/TLS,内部处理超时和丢失数据包重传问题。,SSL,的目的是在,TCP,协议提供的可靠的数据流服务的基础上, SSL,把数据分割成带有报头和密码学保护的记录,为应用程序提供可靠的、加密的、完整性保护的数据流服务。,SSL,协议的体系结构,SSL,不是一个单独的协议,而是包括两个协议层的四个协议组成的协议包,具体情况如图所示,SSL,握手协议,SSL,协议中最重要最复杂的协议就是握手协议。这个协议的任务是使服务器与客户能够互相认证,能够协商加密算法与,MAC,算法、协商加密与在,SSL,记录协议中为保护发送数据的机密性所使用的密钥。在传送任何数据之前,需要先执行握手协议。握手协议包括服务器与客户端之间的一系列信息交换,交换信息的过程如图所示,信息的格式,握手协议有,10,种信息,所有信息的格式是相同的,格式如下:,Type (1byte),Length(3byte),Content(0byte),分别说明消息的种类,(,共有,10,种,),;消息长度的字节数;与消息相关的参数。,SSL,握手协议,握手协议的信息类型,信息种类,参数,Client_Hello,Server_Hello,Certificate,Server_key_exchange,Certificate_request,Server_done,Cerificate_verify,Client_key_exchange,Finished,版本号、随机数、会话,ID,、,密码套、压缩方法,(,For both,),X.509,证书链,参数,签名,类型、授权,Null,签名,参数,签名,散列值,参数详情,版本号:是用户可以理解的最高,SSL,版本号;随机数:用户产生的随机数,包括,32,位的时标和,28,位的随机数;会话,ID,:可变长的会话标示符,,0,表示用户希望在新的会话上建立一个新的连接,非,0,表示在原有会话上建立连接;,cipher suite,以用户希望的优先顺序列出用户可以接受的密码算法;压缩方法列出用户可以支持的压缩算法列表。,握手协议,握手过程可以分为四个阶段:协商安全方法,(Establish Security Capability),、服务器认证与密钥交换、客户认证与密钥交换、完成握手,如下图所示。,(1),协商阶段,:,任务是初始化逻辑连接,协商安全方法。协商客户由向服务器发送,Client_ Hello,消息而发起,消息中包含版本号、一个随机数、一个会话,ID,、密码套,(Cipher Suite),与压缩方法。其中随机数由,32,比特的时标与随机数生成器所生成的,28,字节的随机数所,握手协议,组成,该随机数作为,Nonce,防止重放攻击。会话,ID,是一个可变的会话标示符,,ID=0,表示希望在新的会话上建立一个新的连接,,ID,0,表示希望,update,连接参数或在现有会话上建立一个新的连接。,Cipher Suite,包括客户端所支持的密码算法,以及各算法所采用的密钥交换算法,最优先的算法放在最前面。发出,Client_Hello,消息后,客户端等待服务器的,Server_Hello,消息。服务器返回的消息与客户发送的消息内容相同,但遵循下面的约定:,握手协议,版本号中包含用户建议的较低的版本和服务器所支持的最高版本,这里的随机数要独立于用户的随机数。如果用户的会话,ID,0,,服务器的会话,ID,填相同的值,如果用户会话,ID=0,,服务器的会话,ID,就填一个新的数,作为新的会话,ID,。,Cipher Suite,中填上服务器从用户建议的加密与压缩算法中所选择的加密与压缩算法。,(2),对服务器的认证与密钥交换:如果需要认证,服务器发送它的证书、密钥交换信息以及如果需要认证用户时的发送证书请求。第,2,阶段,握手协议,要发送的最后一个消息是,Server_done,是,Server_Hello,及有关消息结束标志。发出这个消息后,服务器等待用户的响应。,(3),认证用户与密钥交换:收到,Server_done,消息后,用户验证服务器的证书是否有效、有关的参数可否接受。如果一切,OK,,就返回服务器一个消息或多个消息。如果服务器请求证书,用户应该返回自己的证书、以及密钥交换的信息,并附带上如何验证自己的证书的有关信息。,握手协议,(4),完成握手阶段:这个阶段完成建立一个安全连接的任务。用户发送一个,Change_cipher,_ spec,消息,并将挂起的,Cipher Spec,复制到当前的,Cipher Spec,中,接着立即发送一个基于协商的算法、密钥以及有关的信息计算出的,Finished,消息,标志着从客户方面,一切,OK,。服务器收到这个消息后也发送一个类似的消息,标志着服务器也已经做好一切准备。这样握手协议全部完成,可以开始进行应用层的数据交换了。,Change Cipher Spec,协议,这是在,SSL,协议中要利用,SSL Record Protocol,的三个协议之一,也是,SSL,协议族中最简单的协议,这个协议只有一个消息,只有一个值,1,。这个消息的用途是将挂起状态能够复制到当前状态,用于更新本次连接所用的,Cipher Suite,。,Alert Protocol,Alert,协议向对等的实体传达,SSL,有关的,Alert,。本协议的每个信息由两个字节组成,第,1,个字节表示消息的严重程度,,1,表示值得警惕的,,2,表示致命的。如果安全及别是致命的,,SSL,就会立即中断这个连接,其它连接则不受影响,但不能在该会话基础上建立新的连接。第,2,个字节说明具体的警报信息。比如是信息完整性错误,还是信息机密性错误等。,SSL Record Protocol,记录协议是为,SSL,连接提供服务的,主要提供下面两种服务,: (1),利用握手协议所达成的算法、密钥等,用对称加密算法对,SSL,的载荷进行,机密性保护;,(2),利用握手协议所达成的密钥等,生成有关消息的认证码,提供完整性保护。,SSL,记录协议的完整过程如下图所示。用于机密性保护的可选算法有,IDEA,、,RC2-40,、,DES-40,、,DES,、,3DES,、,RC4-40,、,RC4-128,用于完整性保护的算法有,SHA-1,。,SSL,记录协议的作用,SSL,的记录有,4,种类型:用户数据、握手消息、警告消息和概念、密码规格消息。基本协议主要是为用户与服务器之间通信服务的。主要是记录下握手过程中所达成的各种安全参数,然后当正式进行数据通信时,根据所协商的各种算法与参数,进行相应的操作,为,SSL,连接提供有关信息的机密性与完整性服务。,SSL,接下来还有一些密码学计算,包括如何计算,Master Secret,、如何生成有关的密码学参数,因为这些都非常简单,没有什么难于理解的,我们就不再讲了,有兴趣的同学可以查找有关的资料看一下,没有兴趣的话,可以到需要的时候再去查找有关资料。,SSL,的会话重用机制,有关,SSL,的两个重要概念是,SSL,会话和,SSL,连接。,会话:一个,SSL,会话是服务器和客户端之间的一次商谈并达成的协议。会话是由握手协议创造的。会话定义了一系列可以被许多连接所共用的密码学安全参数。避免每次连接都进行昂贵的安全参数的协商。,类似一次商务谈判。,连接:连接是在,OSI,分层模型中所定义的、提供适当服务的一次传输。,类似谈判过程的一次接触。,连接是一个对等关系,连接是变化的,每一个连接都与一个会话相关联。,会话重用机制,任何两个参与实体之间可能存在多个安全连接。理论上任何两个参与实体之间也可能同时存在多个会话,但实际上这个特性没有被使用。实际上有许多状态与一个会话相关联。一旦一个会话建立起来,就存在一个当前的读和写的状态,这个会话状态结束,就会调用新的会话状态。一个会话状态包括:会话标示符、,Peer,Certific,-ate,、压缩方法、密码规范、主秘密、是否可重用等。一个连接状态包括:服务器与用户的随机数、服务器,(,用户,),写,MAC,秘密、服务器,(,用户,),写密钥、初始向量、序列号等。,SSL,的会话重用机制,会话密钥是用开销比较大的公开密钥技术建立起来的,为了降低开销,,SSL,允许在一个会话密钥的基础上建立多个连接,这种机制称为会话的重用。这主要是因为,SSL,能够与,HTTP1.0,协议协同工作,而,HTTP 1.0,协议允许在相同的客户和服务器之间打开大量的,TCP,连接。虽然,SSL,允许会话重用,但是服务器上的会话都是无状态的。如果服务器希望重用会话,就需要给用户发送一个不保密的,ID,,并把,ID,和会话密钥存起来。,协议细节,如果,Alice,在消息,1,中出现了已经保存的会话,ID,,那么就可以绕过握手过程的公钥操作部分。只有在,Alice,和,Bob,都记住了相同的主密钥的前提下,这种简化的握手过程才能继续。如果,Bob,没有识别出这个会话,ID,,就会在消息,2,中返回另一个,ID,,或者忽略,Alice,的消息。没有先前状态下的会话重用与双方都记住了,ID,的情况下的会话重用情况如下两图所示。,没有先前状态下的会话重用,双方都记住了,ID,的情况下的会话重用,BACK,第,3,节,SET,SET,是由,Master,卡公司与,Visa,卡公司于,1996,年设计的、用于保护在互联网进行的信用卡交易的公开的加密与安全标准规范。其中,IBM,、,Microsoft,、,Netscape,、,RSA,、,Terisa,与,Verisign,公司都参与了该标准的设计工作。,SET,本身并不是一个支付系统。而是使用户能够在互联网上部署现有的信用卡支付基础设施的一整套安全协议与安全格式。本质上,,SET,可提供三种服务:,SET,在交易的所有参与方之间提供一个安全的通信信道;通过应用,X.509V3,证书解决相互之间的信任问题;因为只有在必要时和需要的场合,参与者才能获得有关的信息,所以保证参与者的隐私。讨论,SET,的最好方式是从,SET,交易中的,SET,要求、密钥特性与参与者开始。,对,SET,的要求,在互联网或者其他网络中用信用卡进行安全支付需要满足下列商业的要求:,(1),要保证支付信息的机密性和订单信息的机密性;,(2),要保证所有传输数据的完整性;,(3),要保证持卡人是信用卡帐户的合法用户。这就需要进行认证。,(4),保证一个商户与金融机构的关系使它能够接受信用卡交易。,对,SET,的要求,(5),运用最好的安全技术与最好的系统设计技术,保护电子商务交易中的所有合法当事人。,(6),需要开发一种协议,该协议既不依赖于传输安全机制的使用也不影响传输安全机制的使用。,(7),便于并鼓励软件供应商和网络服务商之间的互操作。,SET,的主要特点,(1),信息的机密性:即使在网络中漫游,持卡人的帐户信息与支付信息都是保密的,一个重要的特点是商户不知道信用卡号,只有发卡行知道卡号,,SET,采用,DES,保证机密性。,(2),数据的完整性:用,RSA,数字签名、,SHA-1,散列算法保证数据的完整性,确保订单信息、个人数据、支付指令在传输过程中不被修改。,(3),对持卡人帐户的认证:,SET,使商户能够验证持卡人是有效信用卡帐号的合法用户。,(4) SET,使持卡人能够验证相应的商户与金融机构有信用卡结算关系,能够接受信用卡付款。,SET,的当事人,SET,的当事人,(1),持卡人:持信用卡进行消费的消费者。,(2),商户:向持卡人提供商品或服务的个人或组织。,(3),发卡行:为持卡人发放信用卡的金融机构。,(4),收款行:商户开有帐户、并受理信用卡认证与结算的金融机构。商店通常都可以接受许多种信用卡,但商店并不想与许多发卡银行打交道,收款行向商店提供认证,保证某个信用卡是有效的,并且,SET,的当事人,其购物金额没有超过其授信额度。收款行负责将购货资金转移给商店,并向发卡银行进行索偿。,(5),支付网关:支付网关是由收款行或者指定的第三方维护的、处理商户支付信息的功能设备。网关现有银行卡支付网络的中介,负责认证和支付。,(5) CA:,这是一个为持卡人、商户和支付网关颁发,X.509V3,公钥证书的可信赖的实体。,SET,的成败取决于,CA,基础设施是否可用。一般采用层次型的,CA,,以避免当事人都直接要根,CA,进行发证。,SET,交易过程的事件,SET,的双签名,现在我们看一下持信用卡在商店购物的过程,基本上是选择好货物之后到商店的结算柜台,直接将信用卡交给商店,商店刷卡,我们输入密码,完成结算。这样商店就会知道我们的信用卡号码,甚至能知道我们的密码,而银行则知道我们在哪个商店购物,甚至知道我们买了什么东西。但实际上只要能够付款,商店其实没有必要知道我们的信用卡号,银行也没有必要知道我们在哪里购物,购了什么东西。,SET,的双签名,这是我们所希望的。而,SET,协议的设计人员注意到这个问题,并发明了双签名机制,利用双签名机制很好地解决了这个问题。双签名机制是,SET,协议一个重要的创新。双签名的目的是要把准备发送给两个接收者的信息连接起来。而且又使得两个接收者只能看到自己应该看到的信息。有些同学可能说,那直接把两个信息分别发给这两个接收者不就得了?假如这样的话,大家想一想会出现什么问题?,SET,的双签名,用户虽然付过款、并购买货物,但却没有付款与所购货物绑定的证据。这样商店可以不为你的商品质量负责。因此我们要求用户必须要能把这两个信息关联起来。这就是双签名的作用。用户既获得了相应的隐私保护,也获得了相应的质量保证。我们再来看一看连接的必要性,假设客户将订单信息和支付信息都发给商店,出现的问题就是,一旦以后发生争议,用户拿不出你曾经给该商店的并由商店把支付信息转交给银行的进行收款的证据,如果商店能够,SET,的双签名,截获该客户的另一个订单信息,商店可以说该支付信息支付的是另一个订单的货款,而本次订单客户并没有付款。,下面的图说明了,SET,是如何满足这个要求的:用户首先产生订单信息和支付信息,分别对支付信息和订单信息进行散列运算,得到其散列值,H(PI),和,H(OI),,把这两个散列值连接起来,再作一次散列运算,最后客户用自己的私钥加密连接的散列值,就构成了一个双签名,,D,SC,E,SC,H(H(PI)|H(OI),SET,的双签名,SET,的双签名,假设商店拥有了双签名,,OI,以及,H(PI),。商店根据用户的证书也知道用户的公钥,PC,,商店就能够计算下面的两个数据,H(H(PI)|H(OI),与,D,PC,DS,如果这两个数据相等,用户对订单信息的签名就得到了验证。类似地,银行有,DS,,,PI,和,H(OI),以及用户的公钥,银行就可以计算,H(H(PI)|H(OI),与,D,PC,DS,如果这两个数据相等,用户对付款信息的签名就得到了验证。,SET,的双签名,结果商店收到了订单信息,并验证了客户对订单信息的签名;银行收到了支付信息,并验证了客户对支付信息的签名;客户将订单信息与支付信息连在了一起,并且以后能证明这种连接。,假设某个不诚实的商店,为了自己的利益,想用其他订单信息代替本次交易的订单信息,,我们看将会发生什么问题?它必须找到另一个订单信息,使其散列函数值与本订单的散列函数值相等,而这一点是做不到的。,SET,支持的交易类型,SET,支持多种交易类型,包括,Card-holder registration, Merchant registration,Purchase request,Payment authorization,Payment capture,(Allow the merchant to request payment from the payment gate-way), Certificate inquiry and status, Purchase inquiry, Authorization reversal (Allow a merchant to correct previous authorization request), Capture reversal,SET,支持的交易类型,(Allow a merchant to correct errors in cap-,ture,request such as transaction amount that were entered incorrectly by a clerk), Credit (Allow a merchant to issue a credit to a cardholders account such as when goods are returned or were damaged during shipping.) Credit reversal, Payment gateway certificate request, Batch administration, Error message.,SET,支持的交易类型,其中有三个是最关键、最重要的交易类型,这包括,Purchase request, Payment auth-,orization,and Payment capture.,我们要对这三者进行比较详细的讨论。要完成一笔交易,客户首先要上网浏览,选择货物,下订单。然后商店要给用户发送一个完整的订单,详细列明用户购买的货物名称、数量、单价,总值、送货地点等详细信息。这些过程都没有,SET,的介入。,交易准备阶段,购买请求,Purchase Request(,购买请求,),要交换四条信息,发起请求、发起响应、购买请求、购买响应。,为了给商店发送,SET,信息,持卡人必须拥有商店的证书与支付网关的证书,客户在发给商店的发起请求信息中,要求商店提供证书。该条信息包含用户的信用卡种类,一个请求响应的,ID,号,一个,Nonce,以保证一定的时效。,购买请求,商店产生一个响应,并用自己的私有密钥签名。响应包括用户发来的,Nonce,,一个新的要求用户返回信息时使用的新的,Nonce,,本次购买交易的,ID,,除此之外,还包括商店的签名证书和支付网关的密钥交换证书。持卡人验证这两个密钥,然后生成订单信息和支付信息,订单信息并不包含数量、价格等信息,而只包含在,SET,介入之前,客户和商店之间交换的有关信息的,Reference,。,购买请求,下一步,客户准备一个购买请求消息和一个一次性的对称加密密钥。购买消息包含:,(1),支付有关的消息:这是需要商店转发给支付网关的信息,包括,PI,、双签名、,H(OI),、数字信封,(,由支付网关的公钥加密对称密钥而获得,),,因为在阅读其他信息之前,必须先解密这个对称密钥,所以将其称为数字信封。,(2),购买有关的消息:这是商店真正需要的信息,包括,OI,、双签名、,H(PI)(,供商店用于验证双签名,),。,购买请求,(3),持卡人证书:包含持卡人的签名验证公钥,(,这是商店与支付网关都需要的,),。当商店受到购买请求信息时,采取如下行动:,(1),根据,CA,的签名,验证持卡人的证书。,(2),验证用户双签名有效性。以确保订单在传递过程中没有被篡改,而且确实是用用户的私钥签署的。,(3),处理订单消息,并把支付信息转交给支付网关。,(4),给用户返回一个购买响应。,购买响应信息,购买响应信息包括订单确认、并给客户一个交易编号。这些信息用商店的私钥进行签名,并与商店的证书一起发给用户。,持卡人的工作站收到购买响应后,验证商店的证书,验证签名,并采取一些适当的行动,比如可以将有关信息显示给用户,或者更新订单状态。,Payment Authorization,在处理客户订单的同时,商店请求网关进行进行付款确认。支付确认保证发卡行同意该付款交易,也保证商店能够收到货款,商店可以向客户提供货物或服务。付款确认包括两条信息:确认请求和确认响应。,商店向支付网关发送确认请求信息,包括下列内容:,(1),支付有关的信息:包括,PI,,双签名,,H(OI),数字信封。,Payment Authorization,(2),有关的确认信息,:,是商店生成的一些信息,包括:用商店的私钥签名,并用一次性的对称密钥加密的含有交易,ID,的确认信息,数字信封。,(3),证书:商店将持卡人的签名密钥、自己的签名密钥与密钥交换的公开密钥打包成证书信息发送给支付网关。,支付网关收到有关信息后采取如下行动:,(1),验证所有证书,; (2),解密商店的数字信封得到对称密钥,用对称密钥解密请求信息。,Payment Authorization,(3),验证商店的签名;,(4),解密用户的数字信封,获得对称密钥进而解密支付信息;,(5),验证客户的双签名,; (6),验证商店支付请求信息中的交易,ID,与,PI,中的交易,ID,是否相同。,(7),向发卡行发出支付的授权请求。,从发卡行得到授权请求后,网关就给商店反馈一个授权响应信息。该信息主要是告诉商店,该笔交易已经得到发卡行的认可,可以放心交易,支付网关保证商店能够收到相应的货款。包括下面的内容:,Payment Capture,为得到货款,商店与支付网关通过,Payment Capture,进行约定,,Payment Capture,由,Capture Request,和,Capture Response,两条信息所组成。,(1),商店生成一个,Capture request,信息包,签名并加密以后发送给支付网关,该信息包包括支付数额与交易,ID,,与前面收到的该交易的令牌,(token),以及商店的签名密钥、密钥交换公钥证书。,Payment Capture,支付网关收到,Capture Request,消息之后,解密并验证,Capture Request,消息包与交易令牌。检验交易令牌与,Capture Request,之间的一致性。然后生成一个清算请求并通过,VPN,发送到发卡行,要求发卡行将该款项转移到商店的账上。,网关给商店发送一个,Capture Response,消息包通知商店支付成功。这个经过网管签名并加密的消息包包括网关的签名密钥证书,用于商店与自己的开户银行进行对账。,BACK,总结,我们学习了网络安全的理论基础,这包括对称加密算法,密码运算模式、公钥加密算法,数字签名算法、密钥交换算法、单向散列函数算法。大家要知道各种算法各有些什么具体的算法,他们的特点、优缺点、用处、很多算法都需要重复进行很多轮的运算,轮数如何确定。还有些处理需要分组、填充,如何分组、如何填充。,复习,在网络安全技术方面我们讲了基本认证技术,如何用对称密钥、公开密钥实现认证。,Kerberos, IP security, Web security. Email,安全。每一种安全技术有什么特点,有什么优势和不足,如何保证机密性、完整性和认证性。在网络安全技术中都涉及密钥的管理,每一种技术是如何管理密钥的。,SET,的双签名如何实现,有什么特点。,
展开阅读全文
相关资源
正为您匹配相似的精品文档
相关搜索

最新文档


当前位置:首页 > 图纸专区 > 课件教案


copyright@ 2023-2025  zhuangpeitu.com 装配图网版权所有   联系电话:18123376007

备案号:ICP2024067431-1 川公网安备51140202000466号


本站为文档C2C交易模式,即用户上传的文档直接被用户下载,本站只是中间服务平台,本站所有文档下载所得的收益归上传人(含作者)所有。装配图网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私,请立即通知装配图网,我们立即给予删除!