《网络安全-17:Web安全性.ppt》由会员分享,可在线阅读,更多相关《网络安全-17:Web安全性.ppt(69页珍藏版)》请在三一文库上搜索。
1、Chapter 16 Web安全性,密码编码学与网络安全,2019/6/6,西安电子科技大学计算机学院,2,第一部分 SSL/TLS协议,SSL (Secure Socket Layer)是一种在两个端实体(End Entity)之间提供安全通道的协议。 它具有保护传输数据以及识别通信实体的功能。 安全通道是透明的 IETF 制定的TLS(Transport Layer Security)版本是对Nescape公司的SSL和Microsoft公司的PCT(Private Communication Technology)两个协议的综合和兼容。 重点讨论SSL协议,2019/6/6,西安电子科技
2、大学计算机学院,3,SSL/TLS协议设计目标,SSL V2 设计目标 为满足WEB安全通信而设计 提供客户和服务器之间传输数据的保密性 服务器认证(客户端认证可选) SSL V3设计目标 修正SSL V2中存在的多处安全问题 设计一种安全磋商多种加密算法的机制,2019/6/6,西安电子科技大学计算机学院,4,SSL提供了什么,SSL提供了通道级别的安全: 连接的两端知道所传输的数据是保密的,而且没有被篡改 几乎总是要对服务器进行认证 可选的客户端认证 针对异常情况的安全通知 错误警示 关闭连接 所有这些依赖于某些对系统的假定 假定已经正确产生了密钥数据并且 该密钥已被安全地保管,2019/
3、6/6,西安电子科技大学计算机学院,5,SSL与TCP/IP,SSL连接非常类似于“保密的”的TCP连接 位于TCP之上,应用层之下 几乎只能在TCP上运行,而不能在UDP或IP上运行,因而它依赖于可靠的传输协议 微软的STLP和无线应用论坛的WTLS均为意图在数据报传输层(如UDP)上正确工作的变种。,2019/6/6,西安电子科技大学计算机学院,6,SSL变种谱系树,SSL V1(1994) 未发布,SSL V2(1994) 第一版,SSL V3(1995),TLS(19971999),PCT(1995),STLP(1996),WTLS(1998),2019/6/6,西安电子科技大学计算机
4、学院,7,用于WEB的SSL,保护使用HTTP的WEB通信 新的URL https:/ 在浏览器中的表现 NETSCAPE:工具条上会显示一把钥匙 IE: 右下角显示 一把锁 几乎所有的商业WEB服务器和浏览器都实现了内置的SSL协议,通过配置即可使用,2019/6/6,西安电子科技大学计算机学院,8,在SSL上构建一切,除了HTTP 和NNTP(SNEWS)外,还可以用于SMTP、Telnet、FTP等,也可用于保护专有协议。 协议端口标准化 协议实现 OPENSSL (C语言实现) pureTLS (java 实现) ApacheSSL (针对Apache服务器的实现) Mod_ssl,2
5、019/6/6,西安电子科技大学计算机学院,9,两个主要的协议,SSL记录协议 建立在可靠的传输协议(如TCP)之上 它提供连接安全性,有两个特点 保密性,使用了对称加密算法 完整性,使用HMAC算法 用来封装高层的协议 SSL握手协议 客户和服务器之间相互鉴别 协商加密算法和密钥 它提供连接安全性,有三个特点 身份鉴别,至少对一方实现鉴别,也可以是双向鉴别 协商得到的共享密钥是安全的,中间人不能够知道 协商过程是可靠的,2019/6/6,西安电子科技大学计算机学院,10,SSL的两个重要概念,SSL连接(connection) 一个连接是一个提供一种合适类型服务的传输(OSI分层的定义)。
6、SSL的连接是点对点的关系。 连接是暂时的,每一个连接和一个会话关联。 SSL会话(session) 一个SSL会话是在客户与服务器之间的一个关联。会话由Handshake Protocol创建。会话定义了一组可供多个连接共享的密码安全参数。 会话用以避免为每一个连接提供新的安全参数所需昂贵的协商代价。,2019/6/6,西安电子科技大学计算机学院,11,SSL基础针对RSA服务器认证的SSL,SSL灵活性: 单向认证 和 双向认证 认证加密 和 认证 加密算法: RSA DSS DH FORTEZZA 连接分为两个节段: 握手阶段 完成对服务器认证并建立加密密钥 数据传输阶段 加密数据传输,
7、2019/6/6,西安电子科技大学计算机学院,12,握手协议,握手阶段的目的 客户和服务器协商保护数据的算法(及其具体参数) 确立在协商好的算法上使用的加密密钥 可选择对客户端进行认证 client server - 所支持的加密算法,随机数 选中的加密算法,随机数,服务器证书 加密后的pre_master_secret 计算相关演化密钥 计算相关演化密钥 握手消息的MAC值 握手消息的MAC值 注: 1. pre_master_secret 可以由KDF(key derivation function)演化出master_secret ,最后再通过master_secret 演化出系列加密密
8、钥。 2. 最后两步防止握手本身遭受篡改(如低强度密码算法替换等). 3. 客户端和服务器端随机数的传输,防止重放攻击。,2019/6/6,西安电子科技大学计算机学院,13,握手消息,client server - 握手: ClientHello 握手: ServerHello Certificate ServerHelloDone ClientKeyExchange (ChangeCipherSpec) Finished (ChangeCipherSpec) Finished,2019/6/6,西安电子科技大学计算机学院,14,SSL 记录协议,实际的数据传输是使用SSL记录协议实现的 数据
9、流分割成一系列片段并加以传输,每个片断单独保护和传输 为实现完整性保护,对片段进行MAC保护 为实现机密性保护,对片段进行加密保护 传输的是安全记录,2019/6/6,西安电子科技大学计算机学院,15,记录头(Head),ContentType; 8位,上层协议类型 Major version; Minnor version 16位,主次版本 Compressed Length:16位 加密后数据的长度,不超过214+2048字节(SSL 几乎不用压缩,虽然支持) EncryptedData fragment; 密文数据,2019/6/6,西安电子科技大学计算机学院,16,记录负荷(Paylo
10、ad),支持4种协议消息: application_data、alert、handshake、change_cipher_spec . Alert协议消息: 报警等级(warning/fatal)+ 具体报警编码 2字节 change_cipher_spec协议消息: 1字节,将挂起状态变成当前状态,指示在此之后的所有消息都将使用刚刚商定的密码进行加密。 handshake协议消息:类型( 1字节 )长度( 3字节 )消息,类型共10种,2019/6/6,西安电子科技大学计算机学院,17,记录负荷(Payload),2019/6/6,西安电子科技大学计算机学院,18,完整SSL会话握手协议,交
11、换Hello消息,对于算法、交换随机值等协商一致 交换必要的密码参数,以便双方得到统一的premaster secret 交换证书和相应的密码信息,以便进行身份认证 产生master secret 把安全参数提供给SSL记录层 检验双方是否已经获得同样的安全参数,2019/6/6,西安电子科技大学计算机学院,19,2019/6/6,西安电子科技大学计算机学院,20,第一阶段:建立起安全协商,客户发送一个client_hello消息,包括以下参数:版本、随机数(32位时间戳+28字节随机序列)、会话ID、客户支持的密码算法列表(CipherSuite)、客户支持的压缩方法列表.然后,客户等待服务
12、器的server_hello消息 服务器发送server_hello消息,参数:客户建议的低版本以及服务器支持的最高版本、服务器产生的随机数、会话ID、服务器从客户建议的密码算法和压缩方法中确定一套本次连接使用的确定方法.,2019/6/6,西安电子科技大学计算机学院,21,CipherSuite,指定了密钥交换的方法,SSL支持以下一些方法: RSA,要求服务器提供一个RSA证书 DH(Diffie-Hellman),要求服务器的证书中包含了由CA签名的DH公开参数。客户或者在证书中提供DH公开参数,或者在密钥交换消息中提供此参数 EDH(Ephemeral Diffie-Hellman),
13、产生临时的密钥,DH公开参数由发送者的私钥进行签名,接收者用对应的公钥进行验证 匿名的DH,不加鉴别。会受到中间人攻击 然后,指定以下信息 加密算法和类型(流还是分组密码算法) HMAC、MD5还是SHA-1 是否可出口 HashSize Key Material IV Size,2019/6/6,西安电子科技大学计算机学院,22,第二阶段:服务器鉴别和密钥交换,服务器发送certificate消息,消息包含一个X.509证书,或者一条证书链 除了匿名DH之外的密钥交换方法都需要 服务器发送server_key_exchange消息 可选的,有些情况下可以不需要。只有当certificate消
14、息没有包含必需的数据的时候才发送此消息 消息包含签名,被签名的内容包括两个随机数以及服务器参数 服务器发送certificate_request消息(可选) 非匿名server可以向客户请求一个证书 包含证书类型和CAs 服务器发送server_hello_done, 然后等待应答,2019/6/6,西安电子科技大学计算机学院,23,第二阶段:服务器鉴别和密钥交换,2019/6/6,西安电子科技大学计算机学院,24,第三阶段:客户鉴别和密钥交换,客户收到server_done消息后,它根据需要检查服务器提供的证书,并判断server_hello的参数是否可以接受,如果都没有问题的话,发送一个或
15、多个消息给服务器。 如果服务器请求证书的话,则客户首先发送一个certificate消息,若客户没有证书,则发送一个no_certificate警告。 然后客户发送client_key_exchange消息,消息的内容取决于密钥交换的类型(如果是RSA,则含加密的PreMasterSecret)。 最后,客户发送一个certificate_verify消息(可选),其中包含一个签名,对从第一条消息以来的所有握手消息的HMAC值(用master_secret)进行签名,2019/6/6,西安电子科技大学计算机学院,25,第三阶段:客户鉴别和密钥交换,2019/6/6,西安电子科技大学计算机学院,
16、26,第四阶段:结束,第四阶段建立起一个安全的连接 客户发送一个change_cipher_spec消息,并且把协商得到的CipherSuite拷贝到当前连接的状态之中 然后,客户用本次连接协商的算法、密钥参数发送一个finished消息,这条消息可以检查密钥交换和鉴别过程是否已经成功。其中包括一个校验值,对所有以来的消息进行校验。 服务器同样发送change_cipher_spec消息和finished消息。 握手过程完成,客户和服务器可以交换应用层数据。,2019/6/6,西安电子科技大学计算机学院,27,第四阶段:结束,2019/6/6,西安电子科技大学计算机学院,28,密钥交换算法,S
17、SL记录协议需要:CipherSuite, master secret, the client & server random values 在hello消息中,交换随机数以及各种算法 两类密钥交换算法: RSA,客户产生一个48字节的pre_master_secret,然后通过服务器的公钥传递给服务器 Diffie-Hellman,双方协商得到的密钥被用作pre_master_secret 对于各种密钥交换算法,从pre_master_secret计算得到Master_secret,然后从内存中删除 Master_secret总是48字节长,而pre_master_secret长度不定,取决
18、于密钥交换算法,2019/6/6,西安电子科技大学计算机学院,29,密钥导出,2019/6/6,西安电子科技大学计算机学院,30,Master_secret的产生,SSL 3.0 Master_secret = MD5(pre_master_secretSHA-1(Apre_master_secret| ClientHello.random ServerHello.random) MD5(pre_master_secretSHA-1(BBpre_master_secret| ClientHello.random ServerHello.random) MD5(pre_master_secret
19、SHA-1(CCCpre_master_secret| ClientHello.random ServerHello.random) TLS 1.0 master_secret = PRF(pre_master_secret, “master secret” , ClientHello.random, + ServerHello.random)047 * PRF(secret, label, seed)为伪随机函数,2019/6/6,西安电子科技大学计算机学院,31,伪随机函数PRF(secret, label, seed),P_hash(secret, seed) = +HMAC_hash(
20、secret, A(1) + seed)+HMAC_hash(secret, A(2) + seed) +HMAC_hash(secret, A(3) + seed)+ . 这里A()定义如下: A(0) = seed A(i) = HMAC_hash(secret, A(i-1) 伪随机函数 PRF(secret, label, seed) =P_MD5(S1, label + seed) XOR P_SHA-1(S2, label + seed); 这里,S1和S2为secret的各一半,如果secret为奇数个字节,则S1和S2共享一个字节,2019/6/6,西安电子科技大学计算机学院,
21、32,最终需要的密钥导出,2019/6/6,西安电子科技大学计算机学院,33,密钥导出公式,Key_block= MD5(master_secret|SHA-1(A+master_secret + server_random + client_random ) | MD5(master_secret|SHA-1(BB+master_secret + server_random + client_random ) | MD5(master_secret|SHA-1(CCC+master_secret + server_random + client_random ) | MD5(master_s
22、ecret|SHA-1(DDDD+master_secret + server_random + client_random ) | ,2019/6/6,西安电子科技大学计算机学院,34,MAC计算,使用共享的密钥MAC_write_secret hash(MAC_write_seret|pad_2|hash(MAC_write_secret|pad_1|seq_num|SSLCompressed.type|SSLCompressed.length|SSLCompressed.fragment) 其中: MAC_write_secret : 共享的保密密钥 hash : 密码散列函数(MD5或
23、SHA-1) pad_1 : 0x36重复48次(MD5);或40次(SHA-1) pad_2 : 0x5C重复48次(MD5);或40次(SHA-1) seq_num : 该消息的序列号 SSLCompressed.type : 更高层协议用于处理本分段 SSLCompressed.length : 压缩分段的长度 SSLCompressed.fragment : 压缩的分段(无压缩时为明文段) 注:非常类似HMAC,2019/6/6,西安电子科技大学计算机学院,35,报警(Alert)协议,用来一方向另一方报告例外情况,两个级别:warning/fatal 如果是Fatal级别的报警,则应
24、终止连接. 报警种类: unexpected_message bad_record_mac decryption_failed record_overflow decompression_failure handshake_failure no_certificate bad_certificate unsupported_certificate certificate_revoked certificate_expired certificate_unknown illegal_parameter unknown_ca access_denied decode_error decrypt_e
25、rror export_restriction protocol_version insufficient_security internal_error user_cancelled no_renegotiation,2019/6/6,西安电子科技大学计算机学院,36,会话恢复,整个握手协议开销巨大,如果集成会话恢复机制,则可以在客户和服务器通信过一次的情况下,可以跳过握手阶段而直接进行数据传输. 通过使用上一次握手中确立的pre_master_secret,则可以避免许多计算开销。 恢复允许根据共同的master_secret,来产生新的密钥。 通过客户使用ClientHello中的Ses
26、sion_id,申请会话恢复,服务器通过使用ServerHello中相同的Session_id,来同意会话恢复,接下来就会跳过其余步骤而使用保存的master_secret来产生新的所有的加密密钥(由于新的随机数不同,而使得新产生的加密密钥与以前不同)。,2019/6/6,西安电子科技大学计算机学院,37,客户端认证,实现服务器对客户端的认证 服务器通过向客户端发送CertificateRequest消息,客户端通过Certificate和CertificateVerify消息予以应答 CertificateVerify消息是一个使用与其传输的证书关联的私钥签名的消息。,2019/6/6,西安
27、电子科技大学计算机学院,38,临时RSA,因受出口限制,为配合客户端,服务器会产生一个临时的低强度密钥,并用高强度密钥签名,客户端将验证临时密钥上的服务器签名,并使用它来打包pre_master_Secret. 服务器向客户端发送消息 ServerKeyExchange,2019/6/6,西安电子科技大学计算机学院,39,再握手,是在当前受保护的连接上进行的一次新的SSL握手,因而传输过程中的握手消息是经过加密的 一旦新的握手完成,将使用新的会话状态来保护数据 客户端可以简单的通过发送一条ClientHello消息来初始化一次新的握手 服务器端可以通过HelloRequest消息来初始化一次新
28、的握手,2019/6/6,西安电子科技大学计算机学院,40,SSL的安全性,保护master_secret 保护服务器的私钥 使用良好的随机数 证书链检查 算法选择(强度),2019/6/6,西安电子科技大学计算机学院,41,SSL实现,OpenSSL, 最新0.9.8, 实现了SSLv2,SSLv3, TLSv1.0 Openssl a command line tool. ssl(3) the OpenSSL SSL/TLS library. crypto(3) the OpenSSL Crypto library. URL: http:/www.openssl.org SSLeay ht
29、tp:/www2.psy.uq.edu.au/ftp/Crypto/ Internet号码分配当局已经为具备SSL功能的应用分配了固定的端口号 例如带SSL的HTTP(https)被分配以端口号443 带SSL的SMTP(ssmtp)被分配以端口号465 带SSL的NNTP(snntp)被分配以端口号563,2019/6/6,西安电子科技大学计算机学院,42,Windows 2000和XP下的IPSec,文章 http:/ http:/ http:/ 实现特点 与IETF兼容 支持Kerberos、基于证书的认证、基于共享密钥的认证 一些不受IPSec保护的流量:广播包、组播包、RSVP包、I
30、KE包、Kerberos包 与L2TP结合起来提供安全的VPN远程访问 不能与NAT协同工作 仍然面临一些攻击:DOS,其他层上协议的攻击 对比FreeBSD的实现: http:/www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ipsec.html,SET协议,Secure Electronic Transaction,2019/6/6,西安电子科技大学计算机学院,44,第三部分 SET协议,Secure Electronic Transaction,SET 安全电子交易协议 1996年,由Visa和MasterCard两大国际信用卡组织联
31、合开发的电子商务交易参考标准(复杂、开放)。为在Internet上从事在线交易而设立的一个开放的以信用卡交易为特征的规范。 得到IBM、HP、Microsoft、Verifone、RSA、Terisa、GTE、Verisign等公司的支持,成为事实上的工业标准,并为IETF所认可。 SET本身不是一个支付系统,而是一个安全协议和格式集。 实现交易参与者行为的安全性、一致性、广泛性 支持产品包括IBM的Net.Commerce、CommercePoint,Verifone的vWallet、vPos、vGate,Microsft的MS-Wallet等 其他产品还包括:CyberCash、Globa
32、lSet、TrinTech、DigiCash、OpenMarket等。,2019/6/6,西安电子科技大学计算机学院,45,SET协议的发展历史,1996年, Visa MasterCard 作为主要制定者发起并公布。1997年出版规范,长达971页。 1998年出现SET兼容的产品。 SET协议标准组织SETCo 在1998和1999年提出许多协议扩展。 目前因各种原因,该协议因其复杂性,而受到冷落,前途比较渺茫。 其设计思想值学习和探讨。,2019/6/6,西安电子科技大学计算机学院,46,电子商务(Electronic Commerce,EC),是指利用简单、快捷、低成本的电子通信方式,
33、买卖双方从事的商贸活动(不谋面或少谋面)。 内容: 电子方式为特征 商贸活动 电子方式:电话、传真、EMAIL、Internet、EDI等。 最终模式应是建立在Internet上 活动流:网络上信息流、商流、资金流、部分物流的实现。 具体活动:交易方匹配、洽谈、订货、合同、支付、发票、报关、纳税、售后服务等。 涉及的机构:消费者、商家、金融机构、政府机构、认证机构、配送中心等。 特征:普遍性、方便性、整体性、安全性、协调性等。,2019/6/6,西安电子科技大学计算机学院,47,电子商务发展阶段,20世纪6090年代,基于EDI(电子数据交换)的电子商务 是指业务文件按照一个公认的标准从一台计
34、算机传输到另一台计算机上的电子传输方式。 依赖于专用网络和专用EDI软件 标准: 美国X12 联合国UN/EDIFACT 20世纪90年代以后,基于Internet的电子商务 Dell公司的网络直销 Amazon公司的网上书店 eBay公司的个人拍卖网站 应用模式: 支付角度:支付型非支付型 服务角度:B2B B2C C2C B2G C2G ,2019/6/6,西安电子科技大学计算机学院,48,电子商务分类支付角度,电子商务 业务,支付型,非支付型,NON-SET 支付,SET支付,税务申报、电子选举、 在线报表、安全政务等,电子银行、代缴代付、 电子证券、网上购物等,支付卡交易、电子银行、
35、网上购物等,2019/6/6,西安电子科技大学计算机学院,49,电子商务安全需求与措施,安全性需求 有效性 机密性 完整性 可靠性/不可抵赖性/鉴别 可审查性 措施 加密技术 对称加密/公钥加密 密钥管理技术 数字证书 数字签名 安全电子商务协议 安全电子邮件/SSL/SET ,2019/6/6,西安电子科技大学计算机学院,50,SET协议安全支付商业需求,提供付款和订购信息的保密性 确保传送数据的完整性 为持卡人是否为信用卡帐号合法用户提供认证 为商家提供认证 确保交易各方利益 创建不依赖于传输安全机制也不妨碍其使用的协议 在软件和网络提供者之间提供功能设施和互操作性,2019/6/6,西安
36、电子科技大学计算机学院,51,SET协议中安全特性和实现,SET协议中安全考虑 信息保密性帐号和支付信息等的传输安全,加密技术 认证持卡人帐号和商家认证,通过数字证书机制,确认参与者的真实身份 防止抵赖 数字签名技术 数据完整性防止客户发送给商家的信息被篡改 ,数字签名和HASH、MAC手段 授权 安全实现 在消费者端 实现 安全电子钱包 在商家 实现 安全电子商家 在银行等金融机构 实现安全支付网关,完成SET协议和银行金融系统相关标准(如ISO8583)的转换。,2019/6/6,西安电子科技大学计算机学院,52,SET 协议规范概述,规范涉及的内容: 加密算法的应用 证书消息和对象格式
37、购买消息和对象格式 请款消息和对象格式 交易实体之间消息协议 SET 规范描述了系统设计考虑、证书管理、支付系统正式的协议定义、传输机制以及增加的扩展(支持硬件设备、特殊消息等)。 大量采用已经存在的、相关的、用于支持的国际标准。,2019/6/6,西安电子科技大学计算机学院,53,SET组件,2019/6/6,西安电子科技大学计算机学院,54,涉及的实体和概念,持卡人(Cardholder) 商家(Merchant) 发卡行(Issuer) 收单行(Acquirer) 支付网关(Payment Gateway) 支付卡品牌(Brand) 认证中心(Certificate Authority,
38、CA),2019/6/6,西安电子科技大学计算机学院,55,双签名,目的在于(持卡人)将商家订单信息(Order Information,OI)和 收单行支付信息(Payment Instructions, PI)连接起来一起发送(保证商家只能看到OI,收单行只能看到PI ),但是又要保证OI和PI的一致性关联性,而采用的一种组合签名方法。 首先分别计算OI的HASH值和PI的HASH值,二者连接后再次执行HASH,然后签名。即: DSEKRcH( H(PI) | H(OI) ),2019/6/6,西安电子科技大学计算机学院,56,双签名,2019/6/6,西安电子科技大学计算机学院,57,证
39、书类型,持卡者证书 保证签署支付者和正确的支付卡帐号一致,帐号信息通过HASH方法作为持卡者证书中的一部分内容。 商家证书 需要两个密钥对参与SET交易,一个是签名密钥和证书,一个是密钥交换密钥和证书。 支付网关证书 需要两个密钥对参与SET交易,一个是签名密钥和证书,一个是密钥交换密钥和证书。 收单行证书 发卡行证书 证书链确认 证书注销列表检查,2019/6/6,西安电子科技大学计算机学院,58,发证机构,涉及的发证机构 根CA(RCA)、支付卡品牌CA(BCA)、区域CA(GCA)、持卡者CA(CCA)、商家CA(MCA)、支付CA(PCA) 信任层次,RCA,BCA,GCA,CCA,M
40、CA,PCA,Cardholder,Merchant,Payment Gateway,2019/6/6,西安电子科技大学计算机学院,59,支付处理,支付处理是SET规范中最为关键的描述部分 支付处理的基本步骤和流程 持卡者注册(Cardholder Registration) 顾客开通帐号 获取证书 商家注册 (Merchant Registration) 获取签名证书和密钥交换证书 购买请求(Perchase Request) 顾客商品订购,发送订单信息和支付信息 支付授权(Payment Authorization) 商家向支付网关获取支付授权信息,使得发卡行对交易担保。 支付请款(Pay
41、ment Capture) 商家向支付网关申请处理支付,获得支付款项。,2019/6/6,西安电子科技大学计算机学院,60,SET交易类型(1),2019/6/6,西安电子科技大学计算机学院,61,SET交易类型(2),2019/6/6,西安电子科技大学计算机学院,62,持卡者注册,持卡者初始注册 CA发出响应 持卡者接收到响应并请求注册表 CA处理请求和发送适当的注册表 持卡者接收注册表,并请求证书 CA处理请求和产生证书(有关帐号信息的HASH值将成为证书中的一部分内容) 持卡者接收证书,2019/6/6,西安电子科技大学计算机学院,63,商家注册,商家请求注册表 CA发出响应 商家接收注
42、册表和请求证书 CA处理请求和产生证书 商家接收证书,2019/6/6,西安电子科技大学计算机学院,64,购买请求,持卡者初始化购买请求 持卡者完成浏览、挑选、定购后,SET协议启动。提供订购表完全的内容、选择支付卡品牌、请求支付网关证书。 商家发出证书 商家为请求消息制定一个唯一的交易识别号,将商家和相应的支付网关证书一起发给持卡者。 持卡者接收响应和发出请求 持卡者检验响应的证书并保存候用,产生有效的OI和PI,并进行双签名,将PI和OI封装数字信封,发送给商家。 商家处理请求消息 验证持卡者证书,验证数字信封的数字签名。 持卡者接收购买响应 验证,并更新本地定购状态数据库。,2019/6
43、/6,西安电子科技大学计算机学院,65,持卡者购买请求构造,2019/6/6,西安电子科技大学计算机学院,66,商家购买请求验证,2019/6/6,西安电子科技大学计算机学院,67,支付授权,商家请求授权:商家产生一个安全的授权请求,发送给支付网关。 购买相关信息:PI双签名OI摘要持卡者数字信封 认可相关信息:认证分组(商家签名交易标识)和商家数字信封 证书:持卡人签名证书、商家签名证书、商家密钥交换证书 支付网关处理授权请求 安全验证,解密PI,验证与OI的一致性和关联性,通过后支付网关将通过一个支付系统向发卡行发出一个授权请求。一旦从发卡行接收到一个授权响应,支付网关将签署一个授权认可消息,安全处理后发送给商家。 商家处理响应 验证有效性,保存授权认可消息和请款标识(Capture Token)。,2019/6/6,西安电子科技大学计算机学院,68,支付请款,商家请求支付 商家产生一个请款请求(包含交易金额、交易标识等),和请款标识一起发给支付网关。 支付网关处理请款请求 验证请款请求的有效性,得到请款标识,形成清算请求,并创建清算请求,通过一个支付卡系统发给发卡行。并给商家发送请款响应消息。 商家接收响应 商家验证有效性,并保存请款响应消息,以备与收单行得到的付款进行对帐。,2019/6/6,西安电子科技大学计算机学院,69,第17章作业,思考题 习题,
链接地址:https://www.31doc.com/p-2920225.html