《信息安全引论》课件chapter9_第1页
《信息安全引论》课件chapter9_第2页
《信息安全引论》课件chapter9_第3页
《信息安全引论》课件chapter9_第4页
《信息安全引论》课件chapter9_第5页
已阅读5页,还剩64页未读 继续免费阅读

下载本文档

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

文档简介

1、 第9章 Web Security 目前,所有的工商企业、大多数政府机构以及许许多多的个人都建起了自己的网站,这些网站都可以通过互联网进行访问。企业对利用网络开展电子商务情有独钟。但现实是互联网与Web服务对于各种攻击非常脆弱。伴随着企业对这种安全现实的苏醒与担忧,对于Web安全的需求则迅速扩张。Web安全可以随便写一本书,本章只讨论Web安全的一般要求,重点讲述web security协议族:SSL协议(SSLV2、SSLV3)、TLS协议和SET协议。Web Security 第1节 Web 安全考虑 第2节 SSL第3节 SET小结 本章介绍了Web安全需要考虑的一些问题,介绍了这些问题

2、的解决方案,主要介绍了SSL协议与SET协议。讲述了SSL协议的细节,讲述了SET协议的交易过程。这里还有许多可以改进的地方,需要增加银行处理的图,对讲解顺序进行重新组织。可以考虑直接从现实的处理过程讲解。思考题 (1) 基于本章所学习的内容,在SSL协议中,接收者能不能记录下按不正常顺序到达的记录包?如果可以,解释需要怎样做。如果不可以,请解释为什么? (2) 你认为SET协议与SSL协议,还有没有安全漏洞?如有,试提出一种弥补方法。结束语 到此为止本门课程结束了,感谢大家的配合我们在一起度过了愉快的一学期。你们也即将毕业走向工作岗位了。祝你们都能够找一个理想的工作。希望你们通过自己的努力能

3、够成为科学的巨匠、祖国的栋梁。希望你们中间能够涌现出一批政治家、科学家、企业家。好像早上8、9点钟的太阳,希望寄托在你们身上。苟富贵,勿相忘。今后无论你们在工作还是学习中有需要我帮助的话,我一定竭尽全力。同学们,再见!第1节 Web Security Considerations www基本上是一种运行在互联网或者TCP/IP内部网络中的B/S应用。所有的安全措施都与Web Security相关,但Web对网络安全提出了一些新的挑战。比如: (1) 互联网是双向的,因此运行在互联网上的Web服务器易于受到攻击; (2) Web已经成为展示公司与产品窗口,成为公司对外交流的出口,成为进行交易的支

4、承平台。如果Web收到破坏将会造成财产的损失和声誉下降。Web Security Considerations (3) Web服务器可以作为进入公司内部复杂的计算机系统的跳板,一旦Web服务器被攻破,攻击者就可以访问与服务器相连的数据与系统。 (4) 未经过训练的、粗心大意的用户一般是Web服务的主要用户。这些用户没有必要的安全意识,意识不到可能存在的安全风险,也没有采取有效应对措施所需要的工具和知识。Web 安全威胁 完整性修改用户数据、特洛伊木马浏览器、修改存储、修改传输的信息流量密码学校验机密性窃听、盗窃服务器信息、盗窃用户数据、获得网络配置信息、获得用户与服务器对话信息加密、Web代理

5、拒绝服务切断用户线程、伪造线程淹没服务器、占满磁盘或内存、用DNS攻击孤立服务器难于防范认证冒充合法用户、伪造数据密码学技术Web 安全威胁 Web安全威胁可以有不同的分类,第1种分为主动攻击与被动攻击:被动攻击包括在服务器与浏览器之间搭线窃听获得访问某个网站的访问信息,而这个网站是不允许他们访问的。主动攻击包括冒充另一个用户、修改客户端和服务器之间传递的信息、修改网站信息等。第2种根据威胁的位置分为:Web服务器威胁、Web浏览器威胁、浏览器与服务器之间的网络流量威胁。 BACK第2节 SSL SSL是Netscape公司设计的协议,该协议有三个版本:SSLV1、SSLV2、SSLV3。其中

6、第1个版本根本就没有投入使用,Microsoft对V2进行了改进,修补了一些安全漏洞,提出了一个类似的协议PCT。后来Netscape对协议进行了彻底的改进,得到了SSLV3。这是目前应用得最广泛的协议。TLS则把密钥扩展和认证使用的密码算法结合在一起,更符合密码学家的期望,但SSL和TLS不能互操作。SSLSSL是在用户级进程中运行的协议。SSL/ TLS可以部署在用户级别的进程中,不需要对操作系统进行修改,协议非常简单,也不需要考虑超时和丢失数据包重传这类问题。当然也可以运行在UDP协议之上,在SSL/TLS内部处理超时和丢失数据包重传问题。 SSL的目的是在TCP协议提供的可靠的数据流服

7、务的基础上, SSL把数据分割成带有报头和密码学保护的记录,为应用程序提供可靠的、加密的、完整性保护的数据流服务。SSL协议的体系结构SSL不是一个单独的协议,而是包括两个协议层的四个协议组成的协议包,具体情况如图所示SSL握手协议 SSL协议中最重要最复杂的协议就是握手协议。这个协议的任务是使服务器与客户能够互相认证,能够协商加密算法与MAC算法、协商加密与在SSL记录协议中为保护发送数据的机密性所使用的密钥。在传送任何数据之前,需要先执行握手协议。握手协议包括服务器与客户端之间的一系列信息交换,交换信息的过程如图所示信息的格式握手协议有10种信息,所有信息的格式是相同的,格式如下:Type

8、 (1byte)Length(3byte)Content(0byte)分别说明消息的种类(共有10种);消息长度的字节数;与消息相关的参数。SSL握手协议握手协议的信息类型信息种类参数Client_HelloServer_HelloCertificateServer_key_exchangeCertificate_requestServer_doneCerificate_verifyClient_key_exchangeFinished版本号、随机数、会话ID、密码套、压缩方法(For both)X.509证书链参数,签名类型、授权Null签名参数,签名散列值参数详情版本号:是用户可以理解的最

9、高SSL版本号;随机数:用户产生的随机数,包括32位的时标和28位的随机数;会话ID:可变长的会话标示符,0表示用户希望在新的会话上建立一个新的连接,非0表示在原有会话上建立连接;cipher suite以用户希望的优先顺序列出用户可以接受的密码算法;压缩方法列出用户可以支持的压缩算法列表。握手协议 握手过程可以分为四个阶段:协商安全方法(Establish Security Capability)、服务器认证与密钥交换、客户认证与密钥交换、完成握手,如下图所示。 (1)协商阶段: 任务是初始化逻辑连接,协商安全方法。协商客户由向服务器发送Client_ Hello消息而发起,消息中包含版本号

10、、一个随机数、一个会话ID、密码套(Cipher Suite)与压缩方法。其中随机数由32比特的时标与随机数生成器所生成的28字节的随机数所握手协议组成,该随机数作为Nonce防止重放攻击。会话ID是一个可变的会话标示符,ID=0表示希望在新的会话上建立一个新的连接,ID0表示希望update 连接参数或在现有会话上建立一个新的连接。Cipher Suite 包括客户端所支持的密码算法,以及各算法所采用的密钥交换算法,最优先的算法放在最前面。发出Client_Hello消息后,客户端等待服务器的Server_Hello消息。服务器返回的消息与客户发送的消息内容相同,但遵循下面的约定:握手协议版

11、本号中包含用户建议的较低的版本和服务器所支持的最高版本,这里的随机数要独立于用户的随机数。如果用户的会话ID0,服务器的会话ID填相同的值,如果用户会话ID=0,服务器的会话ID就填一个新的数,作为新的会话ID。Cipher Suite 中填上服务器从用户建议的加密与压缩算法中所选择的加密与压缩算法。 (2) 对服务器的认证与密钥交换:如果需要认证,服务器发送它的证书、密钥交换信息以及如果需要认证用户时的发送证书请求。第2阶段握手协议要发送的最后一个消息是Server_done, 是Server_Hello 及有关消息结束标志。发出这个消息后,服务器等待用户的响应。 (3) 认证用户与密钥交换

12、:收到Server_done消息后,用户验证服务器的证书是否有效、有关的参数可否接受。如果一切OK,就返回服务器一个消息或多个消息。如果服务器请求证书,用户应该返回自己的证书、以及密钥交换的信息,并附带上如何验证自己的证书的有关信息。握手协议 (4) 完成握手阶段:这个阶段完成建立一个安全连接的任务。用户发送一个Change_cipher_ spec消息,并将挂起的Cipher Spec复制到当前的Cipher Spec中,接着立即发送一个基于协商的算法、密钥以及有关的信息计算出的Finished 消息,标志着从客户方面,一切OK。服务器收到这个消息后也发送一个类似的消息,标志着服务器也已经做

13、好一切准备。这样握手协议全部完成,可以开始进行应用层的数据交换了。Change Cipher Spec 协议 这是在SSL协议中要利用 SSL Record Protocol的三个协议之一,也是SSL协议族中最简单的协议,这个协议只有一个消息,只有一个值1。这个消息的用途是将挂起状态能够复制到当前状态,用于更新本次连接所用的Cipher Suite。Alert Protocol Alert协议向对等的实体传达SSL有关的Alert。本协议的每个信息由两个字节组成,第1个字节表示消息的严重程度,1表示值得警惕的,2表示致命的。如果安全及别是致命的,SSL就会立即中断这个连接,其它连接则不受影响,

14、但不能在该会话基础上建立新的连接。第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种类型:用户数据

15、、握手消息、警告消息和概念、密码规格消息。基本协议主要是为用户与服务器之间通信服务的。主要是记录下握手过程中所达成的各种安全参数,然后当正式进行数据通信时,根据所协商的各种算法与参数,进行相应的操作,为SSL连接提供有关信息的机密性与完整性服务。SSL 接下来还有一些密码学计算,包括如何计算Master Secret、如何生成有关的密码学参数,因为这些都非常简单,没有什么难于理解的,我们就不再讲了,有兴趣的同学可以查找有关的资料看一下,没有兴趣的话,可以到需要的时候再去查找有关资料。SSL的会话重用机制 有关SSL的两个重要概念是SSL会话和SSL连接。 会话:一个SSL会话是服务器和客户端之

16、间的一次商谈并达成的协议。会话是由握手协议创造的。会话定义了一系列可以被许多连接所共用的密码学安全参数。避免每次连接都进行昂贵的安全参数的协商。类似一次商务谈判。 连接:连接是在OSI分层模型中所定义的、提供适当服务的一次传输。类似谈判过程的一次接触。连接是一个对等关系,连接是变化的,每一个连接都与一个会话相关联。会话重用机制 任何两个参与实体之间可能存在多个安全连接。理论上任何两个参与实体之间也可能同时存在多个会话,但实际上这个特性没有被使用。实际上有许多状态与一个会话相关联。一旦一个会话建立起来,就存在一个当前的读和写的状态,这个会话状态结束,就会调用新的会话状态。一个会话状态包括:会话标

17、示符、Peer Certific-ate、压缩方法、密码规范、主秘密、是否可重用等。一个连接状态包括:服务器与用户的随机数、服务器(用户)写MAC秘密、服务器(用户)写密钥、初始向量、序列号等。SSL的会话重用机制 会话密钥是用开销比较大的公开密钥技术建立起来的,为了降低开销,SSL允许在一个会话密钥的基础上建立多个连接,这种机制称为会话的重用。这主要是因为SSL能够与HTTP1.0协议协同工作,而HTTP 1.0协议允许在相同的客户和服务器之间打开大量的TCP连接。虽然SSL允许会话重用,但是服务器上的会话都是无状态的。如果服务器希望重用会话,就需要给用户发送一个不保密的ID,并把ID和会话

18、密钥存起来。协议细节 如果Alice在消息1中出现了已经保存的会话ID,那么就可以绕过握手过程的公钥操作部分。只有在Alice和Bob都记住了相同的主密钥的前提下,这种简化的握手过程才能继续。如果Bob没有识别出这个会话ID,就会在消息2中返回另一个ID,或者忽略Alice的消息。没有先前状态下的会话重用与双方都记住了ID的情况下的会话重用情况如下两图所示。没有先前状态下的会话重用双方都记住了ID的情况下的会话重用BACK第3节 SET SET 是由Master卡公司与Visa卡公司于1996年设计的、用于保护在互联网进行的信用卡交易的公开的加密与安全标准规范。其中IBM、Microsoft、

19、Netscape、RSA、Terisa与Verisign公司都参与了该标准的设计工作。SET本身并不是一个支付系统。而是使用户能够在互联网上部署现有的信用卡支付基础设施的一整套安全协议与安全格式。本质上,SET可提供三种服务:SET 在交易的所有参与方之间提供一个安全的通信信道;通过应用X.509V3证书解决相互之间的信任问题;因为只有在必要时和需要的场合,参与者才能获得有关的信息,所以保证参与者的隐私。讨论SET的最好方式是从SET交易中的SET要求、密钥特性与参与者开始。对SET的要求 在互联网或者其他网络中用信用卡进行安全支付需要满足下列商业的要求: (1) 要保证支付信息的机密性和订单

20、信息的机密性; (2) 要保证所有传输数据的完整性; (3) 要保证持卡人是信用卡帐户的合法用户。这就需要进行认证。 (4) 保证一个商户与金融机构的关系使它能够接受信用卡交易。对SET的要求 (5) 运用最好的安全技术与最好的系统设计技术,保护电子商务交易中的所有合法当事人。 (6) 需要开发一种协议,该协议既不依赖于传输安全机制的使用也不影响传输安全机制的使用。 (7) 便于并鼓励软件供应商和网络服务商之间的互操作。SET的主要特点 (1) 信息的机密性:即使在网络中漫游,持卡人的帐户信息与支付信息都是保密的,一个重要的特点是商户不知道信用卡号,只有发卡行知道卡号,SET采用DES保证机密

21、性。 (2) 数据的完整性:用RSA数字签名、SHA-1散列算法保证数据的完整性,确保订单信息、个人数据、支付指令在传输过程中不被修改。 (3) 对持卡人帐户的认证:SET使商户能够验证持卡人是有效信用卡帐号的合法用户。 (4) SET使持卡人能够验证相应的商户与金融机构有信用卡结算关系,能够接受信用卡付款。SET的当事人SET的当事人 (1) 持卡人:持信用卡进行消费的消费者。 (2) 商户:向持卡人提供商品或服务的个人或组织。 (3) 发卡行:为持卡人发放信用卡的金融机构。 (4) 收款行:商户开有帐户、并受理信用卡认证与结算的金融机构。商店通常都可以接受许多种信用卡,但商店并不想与许多发

22、卡银行打交道,收款行向商店提供认证,保证某个信用卡是有效的,并且SET的当事人其购物金额没有超过其授信额度。收款行负责将购货资金转移给商店,并向发卡银行进行索偿。 (5) 支付网关:支付网关是由收款行或者指定的第三方维护的、处理商户支付信息的功能设备。网关现有银行卡支付网络的中介,负责认证和支付。 (5) CA: 这是一个为持卡人、商户和支付网关颁发X.509V3公钥证书的可信赖的实体。SET的成败取决于CA基础设施是否可用。一般采用层次型的CA,以避免当事人都直接要根CA进行发证。SET交易过程的事件SET的双签名 现在我们看一下持信用卡在商店购物的过程,基本上是选择好货物之后到商店的结算柜

23、台,直接将信用卡交给商店,商店刷卡,我们输入密码,完成结算。这样商店就会知道我们的信用卡号码,甚至能知道我们的密码,而银行则知道我们在哪个商店购物,甚至知道我们买了什么东西。但实际上只要能够付款,商店其实没有必要知道我们的信用卡号,银行也没有必要知道我们在哪里购物,购了什么东西。SET的双签名 这是我们所希望的。而SET协议的设计人员注意到这个问题,并发明了双签名机制,利用双签名机制很好地解决了这个问题。双签名机制是SET协议一个重要的创新。双签名的目的是要把准备发送给两个接收者的信息连接起来。而且又使得两个接收者只能看到自己应该看到的信息。有些同学可能说,那直接把两个信息分别发给这两个接收者

24、不就得了?假如这样的话,大家想一想会出现什么问题?SET的双签名 用户虽然付过款、并购买货物,但却没有付款与所购货物绑定的证据。这样商店可以不为你的商品质量负责。因此我们要求用户必须要能把这两个信息关联起来。这就是双签名的作用。用户既获得了相应的隐私保护,也获得了相应的质量保证。我们再来看一看连接的必要性,假设客户将订单信息和支付信息都发给商店,出现的问题就是,一旦以后发生争议,用户拿不出你曾经给该商店的并由商店把支付信息转交给银行的进行收款的证据,如果商店能够SET的双签名截获该客户的另一个订单信息,商店可以说该支付信息支付的是另一个订单的货款,而本次订单客户并没有付款。 下面的图说明了SE

25、T是如何满足这个要求的:用户首先产生订单信息和支付信息,分别对支付信息和订单信息进行散列运算,得到其散列值H(PI)和H(OI),把这两个散列值连接起来,再作一次散列运算,最后客户用自己的私钥加密连接的散列值,就构成了一个双签名,DSCESCH(H(PI)|H(OI)SET的双签名SET的双签名 假设商店拥有了双签名,OI以及H(PI)。商店根据用户的证书也知道用户的公钥PC,商店就能够计算下面的两个数据 H(H(PI)|H(OI) 与 DPCDS 如果这两个数据相等,用户对订单信息的签名就得到了验证。类似地,银行有DS,PI和H(OI)以及用户的公钥,银行就可以计算 H(H(PI)|H(OI

26、) 与 DPCDS 如果这两个数据相等,用户对付款信息的签名就得到了验证。SET的双签名 结果商店收到了订单信息,并验证了客户对订单信息的签名;银行收到了支付信息,并验证了客户对支付信息的签名;客户将订单信息与支付信息连在了一起,并且以后能证明这种连接。 假设某个不诚实的商店,为了自己的利益,想用其他订单信息代替本次交易的订单信息,我们看将会发生什么问题?它必须找到另一个订单信息,使其散列函数值与本订单的散列函数值相等,而这一点是做不到的。SET支持的交易类型 SET支持多种交易类型,包括Card-holder registration, Merchant registration, Purc

27、hase 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 reversalSET支持的交易类型(Allow a merchant t

28、o 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

29、 administration, Error message.SET支持的交易类型 其中有三个是最关键、最重要的交易类型,这包括Purchase request, Payment auth-orization and Payment capture. 我们要对这三者进行比较详细的讨论。要完成一笔交易,客户首先要上网浏览,选择货物,下订单。然后商店要给用户发送一个完整的订单,详细列明用户购买的货物名称、数量、单价,总值、送货地点等详细信息。这些过程都没有SET的介入。交易准备阶段购买请求 Purchase Request(购买请求)要交换四条信息,发起请求、发起响应、购买请求、购买响应。 为了给

30、商店发送SET信息,持卡人必须拥有商店的证书与支付网关的证书,客户在发给商店的发起请求信息中,要求商店提供证书。该条信息包含用户的信用卡种类,一个请求响应的ID号,一个Nonce以保证一定的时效。购买请求商店产生一个响应,并用自己的私有密钥签名。响应包括用户发来的Nonce,一个新的要求用户返回信息时使用的新的Nonce,本次购买交易的ID,除此之外,还包括商店的签名证书和支付网关的密钥交换证书。持卡人验证这两个密钥,然后生成订单信息和支付信息,订单信息并不包含数量、价格等信息,而只包含在SET介入之前,客户和商店之间交换的有关信息的Reference。购买请求下一步,客户准备一个购买请求消息

31、和一个一次性的对称加密密钥。购买消息包含: (1)支付有关的消息:这是需要商店转发给支付网关的信息,包括PI、双签名、H(OI)、数字信封(由支付网关的公钥加密对称密钥而获得),因为在阅读其他信息之前,必须先解密这个对称密钥,所以将其称为数字信封。 (2)购买有关的消息:这是商店真正需要的信息,包括OI、双签名、H(PI)(供商店用于验证双签名)。购买请求 (3)持卡人证书:包含持卡人的签名验证公钥(这是商店与支付网关都需要的)。当商店受到购买请求信息时,采取如下行动: (1) 根据CA的签名,验证持卡人的证书。 (2) 验证用户双签名有效性。以确保订单在传递过程中没有被篡改,而且确实是用用户

32、的私钥签署的。 (3) 处理订单消息,并把支付信息转交给支付网关。 (4) 给用户返回一个购买响应。购买响应信息 购买响应信息包括订单确认、并给客户一个交易编号。这些信息用商店的私钥进行签名,并与商店的证书一起发给用户。 持卡人的工作站收到购买响应后,验证商店的证书,验证签名,并采取一些适当的行动,比如可以将有关信息显示给用户,或者更新订单状态。Payment Authorization 在处理客户订单的同时,商店请求网关进行进行付款确认。支付确认保证发卡行同意该付款交易,也保证商店能够收到货款,商店可以向客户提供货物或服务。付款确认包括两条信息:确认请求和确认响应。 商店向支付网关发送确认请求信息,包括下列内容: (1) 支付有关的信息:包括PI,双签名,H(OI), 数字信封。Payment Authorization (2)有关的确认信息: 是商店生成的一些信息,包括:用商店的私钥签名,并用一次性的对称密钥加密的含有交易ID的确认信息,数字信封。 (3) 证书:

温馨提示

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

评论

0/150

提交评论