




已阅读5页,还剩66页未读, 继续免费阅读
版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领
文档简介
第九章 安全电子交易协议 v教学内容: v9.1 SSL协议 v9.2 SET协议概述 v9.3 SSL与SET协议的比较 v9.4 在线支付 v9.5 本章小结 v9.6 习题 v学习目标: v1、掌握SSL的概念、安全内容及体系结构并 理解其安全漏洞。 v2、掌握SET的概念、安全目标及工作流程并 了解其安全保障。 v3、掌握SSL和SET协议的不同。 v4、了解网上安全支付和手机支付的应用 v电子商务实施初期采用的安全措施 v部分告知(partial order)。在网上交易中将 最关键的数据,如信用卡帐号及交易金额等 略去,然后再用电话告知,以防泄密。 v另行确认 (order confirmation)。在网上传输 交易信息之后,再用电子邮件对交易进行确 认,才认为有效。 v在线服务 (online service)。为了保证信息传 输的安全,用企业提供的内部网来提供联机 服务。 v 实现真正安全的网上购物,必须进入 应用SSL或SET的网站。 SSL是对会话 的保护。 SSL所提供的安全业务有实体 认证、完整性、保密性,还可通过数字 签名提供不可否认性。 v SET是一种以信用卡为基础的,在因 特网上交易的付款协议,利用公钥体系 对通信双方进行认证,用加密算法对信 息加密传输,并用散列函数算法来鉴别 信息的完整性。 9.1 SSL协议 v SSL所提供的安全业务类似于S-HTTP:有 实体认证,完整性,保密性,还可通过数字 签名提供不可否认性。 一、 SSL协议的概念 v SSL协议(Secure Socket Layer,安全套接层)是 由网景(Netscape)公司推出的一种安全通信协议 ,在1995年发表。它能够对信用卡和个人信息提供 较强的保护。SSL是对计算机之间整个会话进行加 密的协议。 v 在SSL中,采用了公开密钥和私有密钥两种加 密方法。它是一个保证任何安装了安全套接层的客 户和服务器间事务安全的协议,该协议向基于TCP IP的客户/服务器应用程序提供了客户端和服务器 的鉴别、数据完整性及信息机密性等安全措施。目 的是为用户提供互联网和企业内联网的安全通信服 务。 v v是保证计算机之间通信安全的一种协议。 秘密通道 internet v SSL支持HTTP,是其安全版,名为 HTTPS。在URL前用HTTPS协议就意味着要 和服务器之间建立一个安全的连接。例如, 输入的 URL为 https:/www.amazon .com, 就会同 建立安全的连接,这时 浏览器状态栏会显示出一个锁表示已建立安 全连接,如图下所示。 SSL有两种安全级别:40位和128位。这是 指每个加密交易所生成的私有会话密钥的长 度。会话密钥是加密算法为在安全会话过程 中将明文转成密文所用的密钥。密钥越长, 加密对攻击的抵抗就越强。美国政府批准可 以出口较短的48位密钥,但不允许128位密 钥的出口。你可根据互联网 Explorer和 Netscape浏览器状态条上锁头的开关来判别 洲览器是否进入了SSL会话。如果未进入, 则锁头处于打开状态。一旦会话结束,会话 密钥将被永远抛弃,以后的会话也不再使用 。 v二、SSL提供的安全内容 vSSL提供的安全内容:机密性,完整性和认 证性 1、机密性:加密数据以隐藏被传送的数据。 2、完整性:确保数据在传输过程中不被改变 。 v3、认证性:认证用户和服务器,使得它们能 够确信数据将被发送到正确的客户机和服务 器上。 v三、 SSL体系结构 v SSL协议建立在传输层和应用层之间,包括两 个子协议:SSL记录协议和SSL握手协议,其中记 录协议在握手协议下端。 v1、SSL记录协议 v 在SSL协议中,所有的传输数据都被封装在记录 中。记录是由记录头和记录数据组成的。所有的 SSL通信包括握手消息、安全空白记录和应用数据 都使用SSL记录层。 v2、SSL握手协议 v SSL握手协议允许服务器与客户机在应用 程序传输和接收数据之前互相认证、协商加 密算法和密钥。它包含两个阶段,第一个阶 段用于建立私密性通信信道,第二个阶段用 于客户认证。 HTTPS FTPS SSL握手协议 SSL记录协议 TCP IP SSL协议与TCP/IP协议间的关系 v 第一阶段是通信的初始化阶段,首先SSL要求 服务器向浏览器出示证书。证书包含有一个公钥, 这个公钥是由一家可信证书授权机构签发的。通过 内置的一些基础公共密钥,客户的浏览器可以判断 服务器证书正确与否。然后,浏览器中的SSL软件 发给服务器一个随机产生的传输密钥,此密钥由已 验证过的公钥加密。由于传输密钥只能由对应的私 有密钥来解密,这证实了该服务器属于一个认证过 的公司。随机产生的传输密钥是核心机密,只有客 户的浏览器和此公司的Web服务器知道这个数字序 列。这个两方共享密钥的密文可以通过浏览器安全 地抵达Web服务器,Internet上的其他人无法解开它 。 v 第二阶段的主要任务是对客户进行 认证,此时服务器已经被认证了。服务 器方向客户发出认证请求消息。客户收 到服务器方的认证请求消息后,发出自 己的证书,并且监听对方回送的认证结 果。而当服务器收到客户的证书后,给 客户回送认证成功消息,否则返回错误 消息。到此为止,握手协议全部结束。 v四、SSL的优缺点 v 由于SSL协议的成本低、速度快、使用简 单,对现有网络系统不需进行大的修改,因 而目前取得了广泛的应用。但是SSL协议也 有缺点:首先,客户的信息可能先到商家, 被商家阅读,这样客户资料的安全性就得不 到保证;其次,SSL只能保证资料信息传递 的安全,而传递过程是否有人截取就无法保 证了。所以,SSL并没有实现电子支付所要 求的保密性、完整性,而且多方互相认证也 是很困难的。 v五、SSL安全 v 数字证书是一种能在完全开放系统中准确 标识某些主体的机制。一个数字证书包含的 信息必须能鉴定用户身份,确保用户就是其 所持有证书中声明的用户。除了唯一的标识 信息外,数字证书还包含了证书所有者的公 共密钥。数字证书的使用允许SSL提供认证 功能保证用户所请求连接的服务器身份 正确无误。 v 在信用卡号或PIN号码等机密信息被发送 出去前让用户确切知道通讯的另一端的身份 是毫无疑问的重要的。很明显的,SSL技术提 供了有效的认证。然而大多数用户并未能正 确意识到通过SSL进行安全连接的必需性。除 非越来越多的用户了解SSL和安全站点的基本 知识,否则SSL仍不足以成为保护用户网络连 接的必需技术。除非用户能够充分意识到访 问站点时应该注意安全连接标识,否则现有 的安全技术仍不能称为真正有效。 v 目前几乎所有处理具有敏感度的资料,财 务资料或者要求身分认证的网站都会使用 SSL加密技术(当你看到https在你的网页浏 览器上的URL出现时,你就是正在使用具有 SSL保护的网页服务器。)。在这里我把 SSL比喻成是一种在浏览器跟网络服务器之 间“受密码保护的导管”(cryptographic pipe ),也就是我们常说的安全通道。这个安全 通道把使用者以及网站之间往返的资料加密 起来。 v 但是SSL并不会消除或者减弱网站所将受 到的威胁性。在SSL这个安全通道的背后, 一般没有受到SSL防护的网站一样具备了相 同的网页服务器程序,同样的网页应用程序 ,CGI的script以及后端数据库。目前普遍存 在这么一个错误的认识:很多系统管理者却 认为,受到SSL防护的网页服务器自动就变 得安全了。其实不然,事实上,受到SSL防 护的网页服务器同样还是会受到与一般其它 网站服务器遭受攻击的威胁,受到SSL防护 的网页服务器不一定是万无一失的。 v(一)SSL的安全漏洞 v 虽然一个网站可能使用了SSL安全技术,但这 并不是说在该网站中正在输入和以后输入的数据也 是安全的。所有人都应该意识到SSL提供的仅仅是 电子商务整体安全中的一小部份解决方案。SSL在 网站上的使用可能会造成管理员对其站点安全性的 某些错觉。使用了SSL的网站所可能受到的攻击和 其它服务器并无任何区别,同样应该留意各方面的 安全性。简言之,加密和数字证书,SSL的主要组 成,从来都无法保护服务器它们仅仅可以保护 该服务器所收发的数据。 vSSL常见安全问题下面三种: v1、攻击证书 类似Verisign之类的公共CA机构并不总是可靠的 ,系统管理员经常犯的错误是过于信任Verisign等 的公共CA机构。例如,如果Verisign发放一个证书 说我是“某某某”,系统管理员很可能就会相信“我是 某某某”。但是,对于用户的证书,公共CA机构可 能不象对网站数字证书那样重视和关心其准确性。 例如,Verisign发放了一个“keyman“组织的证书, 而我是其中一员“JACK”。当一个网站要求认证用户 身份时,我们提交了“JACK”的证书。你可能会对其 返回的结果大吃一惊的。更为严重的是,由于微软 公司的IIS服务器提供了“客户端证书映射”(Client Certificate Mapping)功能,用于将客户端提交证 书中的名字映射到NT系统的用户帐号,在这种情况 下我们就能够获得该主机的系统管理员特权! v 如果黑客不能利用上面的非法的证书突 破服务器,他们可以尝试暴力攻击(brute- force attack)。虽然暴力攻击证书比暴力攻 击口令更为困难,但仍然是一种攻击方法。 要暴力攻击客户端认证,黑客编辑一个可能 的用户名字列表,然后为每一个名字向CA机 构申请证书。每一个证书都用于尝试获取访 问权限。用户名的选择越好,其中一个证书 被认可的可能性就越高。暴力攻击证书的方 便之处在于它仅需要猜测一个有效的用户名 ,而不是猜测用户名和口令。 v2、窃取证书 除上面的方法外,黑客还可能窃取有效 的证书及相应的私有密钥。最简单的方法是 利用特洛伊木马。这种攻击几乎可使客户端 证书形同虚设。它攻击的是证书的一个根本 性弱点:私有密钥整个安全系统的核心 经常保存在不安全的地方。对付这些攻 击的唯一有效方法或许是将证书保存到智能 卡或令牌之类的设备中。 v 3、安全盲点 系统管理员没办法使用现有的安全漏洞 扫描(vulnerability scanners)或网络入侵侦 测系统(intrusion detection systems,IDS) ,来审查或监控网络上的SSL交易。网络入 侵侦测系统是通过监测网络传输来找寻没有 经过认证的活动。任何符合已知的攻击模式 或者并未经过政策上授权的网络活动都被标 起来以供系统管理者检视。而要让IDS能够发 生作用,IDS必须能够检视所有的网络流量信 息,但是SSL的加密技术却使得通过http 传 输的信息无法让IDS辨认。 v再者,虽然我们可以用最新的安全扫描软件 审查一般的网页服务器来寻找已知的安全盲 点,这种扫描软件并不会检查经过SSL保护 的服务器。受到SSL保护的网页服务器的确 拥有与一般服务器同样的安全盲点,可是也 许是因为建立SSL连结所需要的时间以及困 难度,安全漏洞扫描软件并不会审查受到 SSL 保护的网页服务器。没有网络监测系统 再加上没有安全漏洞审查,使得最重要的服 务器反而成为受到最少防护的服务器。 v(二)、解决方法 至于如何保护证书的安全,你可以采用IDS(Intrusion Detection System),它是一种用于监测攻击服务器企图的 技术和方法。典型的IDS监视网络通讯,并将其与保存在数 据库中的已知攻击“特征”或方法比较。如果发现攻击,IDS 可以提醒系统管理员、截断连接或甚至实施反攻击等。问题 在于如果网络通讯是加密的,IDS将无法监视。这反而可能 会使攻击更为轻松。假设在一个典型的被防火墙和IDS防护 的DMZ环境中,黑客能轻松地探测被SSL保护的网站,因为 SSL对数据的加密使得IDS无法正常监测攻击。通常一台单 一的网站服务器会同时使用SSL和普通的TCP协议。由于黑 客攻击的服务器而不是网络连接,他们可以选择任意一种途 径。通过SSL途径,黑客知道SSL加密为他们带来的好处, 这样更容易避开IDS系统的监测。在这里我主要介绍的是如 何解决系统管理员没办法使用现有的安全漏洞扫描或网络入 侵侦测系统而存在的网页服务器安全盲点的情况,目前解决 这个困扰的常用方法大致有以下三种: v1、通过Proxy代理服务器的SSL 我们可以在一个SSL Proxy代理程序上使用这项资料审 查技术。SSL Proxy是一个在连接埠80上接收纯文字的 HTTP通讯请求的软件,它会将这些请求通过经由SSL加密 过的连结,转寄到目标网站。我们在连接埠80开一个听取的 socket,通过上述的OpenSSL指令,将所有进入这个proxy 的数据传送出去。这在Unix上,只是个小技巧:你只须将以 下的指令加到你们的/etc/inetd.conf档案里面,这个 inetd.conf包含所有inetd所提供的网络服务的设定: www stream tcp nowait root /usr/sbin/tcpd /usr/local/bin/ssl_proxy.sh 而/usr/local/bin/ssl_proxy.sh的内容则如下所述: #!/bin/sh /usr/local/ssl/bin/openssl s_client -no_tls1 -quiet - connect 0:443 2/dev/null v2、OpenSSL v OpenSSL(/)包含 了一套程序以及函式库,提供前端使用者 SSL功能,并且允许软件工程师将SSL模块 与他们的程序结合。在众多由SSL提供的产 品里面,最能够用来让我们在这里讨论的是 命令列模式的(command-line)SSL客户端 以及伺服端工具软件。OpenSSL程序是一个 指令列接口的程序,它是用来以手动的方式 起始SSL连结。OpenSSL让你重新导引与其 它程序之间的资料输入以及输出。 v3、监测SSL服务器 现在的网络IDS只能够监视纯文字资 料内容,所以我们只能够有两项选择: 监视服务器上的SSL连结或者将整个连 结资料转为纯文字格式。大部分的网页 服务器都有一些基本的日志纪录功能。 例如:Microsoft的IIS Web server有内 建的日志制作功能,使用的是W3svc1 格式,它可以侦测到很多一般的网络攻 击状况。我通过前述的SSL proxy针对 Windows NT 4.0上具备有SSL防护的IIS 服务器,来作示范性的攻击。我们用的 是由Rain Forest Puppy发现的一般性常 见的msadc安全穿透技术。 v我们的IIS服务器在C:WINNTsystem32LogFiles 的目录下,记载了以下的日志: 12:25:45 GET /msadc/msadcs.dll 200 12:25:48 POST / msadc/msadcs.dll 200 然而,因为这些日志文件通常是存在网页服务器上 面,因此,一个成功的攻击事件表示黑客很可能已 经对日志文件下了手脚了。此外,安全管理员必须 每天检查服务器上的日志文件(另外还有IDS,防 火墙等等),这实在不是个最佳的解决方案。 v 除了使用主机日志文件的以外,另一个方式是 将SSL连结转换成纯文字格式。如此一来网络的 IDS就能够监视资料往来。有几种产品提供这项功 能,不过他们主要是为了要提升数据处理效能,而 不是为了网络安全的理由。建立以及维护SSL连结 ,必须耗用相当的CPU时间,如此一来会减损网页 服务器的效能。市面上有几家厂商提供“电子商务 加速器”,用来将与SSL交涉的工作移到不同的装置 或处理器。你可以将IDS置放于加速器跟网页服务 器之间,以监控纯文字格式的网络交通。用这种方 式监控的话,有一个问题。那就是你必须有至少一 个网络区隔(network segment)。这个网络区隔 必须是安全的,而且与其它的网络装置分开来。 9.2 SET协议概述 v 网上消费者发出的支付指令在由商户送 到支付网关之前,是在公用网上传送的,这 一点与持卡POS消费者有着本质的不同,后者 从商家POS到银行之间使用的是专线。因此, 在开放的网络上处理交易,如何保证传输数 据的安全成为电子商务能否普及的最重要的 因素之一,SET正是在这种需求的推动下应运 而生的,它是由VISA和MasterCard两大信用 卡公司发起,会同IBM、Microsoft等信息产 业巨头于1997年6月正式制定发布的用于因特 网事务处理的一种标准。 v 1995年,SET(Secure Electronic Transaction,安全电子交易协议)是由VISA 和MasterCard开发,是为了在互联网上进行 在线交易时保证用卡支付的安全而设立的一 个开放的规范。由于得到了IBM、HP、 Microsoft、Netscape、GTE、Verisign等很 多大公司的支持,它已形成了事实上的工业 标准,目前它已获得互联网工程任务组标准 的认可。 v一、 SET协议简介 1、安全电子交易是基于因特网的银行卡 支付系统,是授权业务信息传输的安全标准 ,它采用RSA公开密钥体系对通信双方进行 认证。利用DES、RC4或任何标准对称加密 方法进行信息的加密传输,并用HASH算法 来鉴别消息真伪,有无篡改。在SET体系中 有一个关键的认证机构(CA),CA根据 X.509标准发布和管理证书。 v2、SET协议的设计指导思想 v(1)保证信息的加密性:通过使用公共密钥和对 称密钥方式加密,保证在公网上的信息安全传输, 只有收件人才能访问和解密该信息 v(2)验证交易各方:通过使用CA安全认证技术确 认交易各方的真实身份。 v(3)保证支付的完整性和一致性:通过使用Hash 算法和数字签名来确定数据是否被篡改,以确保数 据完整(末被篡改)地被收件人接收,并可以完成交 易而防止抵赖。 v(4)保证互操作性:保证不同厂商的产品使用同 样的通信协议和信息格式,从而可互相集成。 v二、SET协议要达到的的目标主要有五个: v1、保证信息在因特网上安全传输,防止数据被黑 客或被内部人员窃取。 v2、保证电子商务参与者信息的相互隔离。客户的 资料加密或打包后通过商家到达银行,但是商家不 能看到客户的帐户和密码信息。 v3、解决多方认证问题,不仅要对消费者的信用卡 认证,而且要对在线商店的信誉程度认证,同时还 有消费者、在线商店与银行间的认证。 v4、保证了网上交易的实时性,使所有的支付过程 都是在线的。 v5、效仿EDI贸易的形式,规范协议和消息格式, 促使不同厂家开发的软件具有兼容性和互操作功能 ,并且可以运行在不同的硬件和操作系统平台上。 三、参与SET的交易成员 n n 收单银行收单银行 n n 认证中心认证中心 n n 支付网关支付网关 n n 持卡人持卡人 n n 商家商家 n n 发卡银行发卡银行 发卡银行 持卡人 银行网络 收单银行 认证中心 网际网络网际网络 支付网关 v1、消费者即持卡人:包括个人消费者和团体 消费者,按照在线商店的要求填写定货单, 通过由发卡银行发行的信用卡进行付款。 v2、在线商店:即提供商品或服务,具备相应 电子货币使用的条件、从事商业交易的公司 组织。 v3、收单银行:主要是负责授权与管理往来的 特约商店,并且负责在交易进行的时候,提 供信用卡付款的授权(Payment Authorization)申请及付款取得(Payment Capture)的服务。为了完成付款取得的服务 ,通过支付网关处理消费者和在线商店之间 的交易付款问题。 v 4、 发卡行(Issuer): 指向持卡人提供 支付卡的金融机构。这张卡可以是Visa、 MasterCard、AE或是JCB,依照持卡人的申 请而定。当收款行透过金融网络要求付款授 权的时候,发卡行就应该响应付款授权的申 请,等到交易完成后再与收单行进行帐务清 算并且交换讯息。 v 5、认证中心(CA):在基于SET协议的电 子商务体系中起着重要作用。可以为持卡人 、商家和支付网关签发X.509V3数字证书,让 持卡人、商家和支付网关通过数字证书进行 认证。负责对交易对方的身份确认,对厂商 的信誉度和消费者的支付手段进行认证。 CA 同时要对证书进行管理。 v6、支付网关(payment gateway)。 v 它是连接银行专用网络和Internet的一组服 务器,其主要作用是完成两者之间的通信、 协议转换和进行数据加密、解密,以保护银 行内部网络的安全。 v 支付网关的主要功能有:将Internet传来的 数据包解密,并按照银行系统内部的通信协 议将数据重新打包;接收银行系统内部反馈 的响应信息,将数据转换为Internet上传送的 数据格式,并对其进行加密。 v四、 SET的工作流程 v1、消费者在网上选购好商品,下订单(订单 上含在线商店和购买物品的名称、数量、交 货时间和地点等信息)。 v2、通过电子商务服务器与在线商店联系并作 出应答,告诉消费者所添订单的单价、应付 款数、交货方式等信息是否准确。 v3、消费者选择付款方式、确认订单、签发付 款指令,此时SET介入。 v4、消费者对订单和付款指令进行数字签名, 同时利用“双重签名”技术使商家看不到消费者 的帐号信息。 v5、商店接受订单后,向消费者所在银行请求 支付认可。信息通过支付网关到收单银行,由 发卡机构审核后返回确认信息给商店。 v6、 商店发送订单确认信息给消费者。消费者 软件记录交易日志以被查询。 v7、商店发送货物或提供服务,并通知收单银 行将钱从消费者帐号上转移到商店帐号上,或 通知发卡银行请求支付。 v v SET的工作流程图如下:由确认订单开始,SET开 始介入。在操作的每一步,均通过CA来验证通信主体 的身份。以确保通信的对方不是冒名顶替。这里充分发 挥了认证中心的作用。 消费者 在线商店 收单银行 发卡银行 认证中心 支 付 网 关 认证 认证 协商 订单 确认 确认 审核 审核 v五、SET的安全保障 v(一)、SET的主要安全保障: 1、将所有消息文本用双钥密码机制加 密。 v 2、将上述密钥的公钥和私钥的字长 增加到512B-2048B 。 3、采用联机动态的授权和认证检查, 以确保交易过程的安全可靠。 v(二)、SET安全保障措施的技术: 1、通过加密方式确保信息机密性, 2、通过数字签名确保数据的完整性, 3、通过数字签名和商家认证确保交易 各方身份的真实性, 4、通过特殊的协议和消息形式确保动 态交互式系统的可操作性。 v六、SET安全协议的缺陷 1、协议没有说明收单银行给在线商店付款前,是否 必须收到消费者的货物接受证书。否则的话,在线 商店提供的货物不符合质量标准,消费者提出疑义 ,责任由谁承担。 2、协议没有担保“非拒绝行为”,这意味着在线商店 没有办法证明订购是不是由签署证书的消费者发出 的。 3、SET技术规范没有提及在事务处理完成后,如何 安全地保存或销毁此类数据,是否应当将数据保存 在消费者、在线商店或收单银行的计算机里。 4、SET协议过于复杂,使用麻烦,成本高。 5、SET支付方式和认证结构适应于卡支付,对其他 支付方式是有所限制的。 v3、SET与SSL的比较 vSET是一个多方的消息报文协议,SET定义了银行、商户、持卡人之间 必需的报文规范,而SSL只是简单地在两方之间建立了一条安全连接。 SSL报文能够在银行内部网或者其他网络上传输,而SSL之上的卡支付 系统只能与Web浏览器捆绑在一起。具体来说: v(1)在认证方面,SET的安全需求较高,因此所有参与 SET 交易的成员都必须先申请书库集资证书来识别身份。而 在SSL 中,只有商户端的服务器需要认证,客户认证责是有 选择性得。 v(2)对消费者而言,SET保证了商户的合法性,并且用户 的信用卡号不会被窃取,SET替消费者保守了更多的秘密使 其在线购物更加轻松。 v(3)在安全性方面,一般公认SET 得安全性较SSL高,主 要原因是在这个交易过程中,包括持卡人到商家、商家到支 付网关再到银行网络,都受到严密的保护。而SSL的安全范 围指限于持卡人到商家的信息交流。 v(4)SET对于参与交易的各方定义了互操作接口,一个系 统可以由不同的厂商的产品构筑。 v(5)在采用比率方面,由于SET的设置成本较SSL高很多 ,并且进入国内市场的时间尚短,因此目前还是SSL的普及 率高。但是,由于网上交易的安全性需求不多提高,SET的 市场占有率将会增加。 v SET协议的缺陷在于:SET要求在银行网络、商 户服务器、顾客的PC机上安装相应的软件。这给顾 客、商家和银行增加了许多附加的费用,成了SET 被广泛接受的阻碍。另外,SET还要求必须向各方 发放证书,这也成为阻碍之一。所有这些使得使用 SET要比使用SSL昂贵得多。 v SET的优点在于:它可以用在系统的一部分或者 全部。例如,一些商户正在考虑在与以后连接中使 用SET,而与顾客连接时仍然使用SSL。这种方案 既回避了在顾客机器上安装电子钱包软件,同时又 获得了SET提供的很多优点。目前,大多数的SET 软件提供商在其产品中都提供了灵活构筑系统的手 段。 SET与SSL机制的比较 v认证机制:SET要求所有参与交易各方均必须先申请数字证书以识别 身份,而SSL只有商家 的服务器需要认证,客户端的认证是可选择的 (optional); v设置成本:希望申请SET交易者除必须申请数字证书之外,也必须在 计算机上安装符合SET规格的电子钱包软件,而SSL交易无须另外安装 软件; v安全性:SET的安全性比SSL高,SSL的安全范围只限于持卡人到商家 的信息交换; v目前采用率:SET的成本较高,目前SSL的普及率较高。 比较项目SETSSL 认证机制 设置成本 安全性 采用比率 所有参与SET的成员 较高 较高 约 商家服务器 较低 较低 约 9.3 SSL协议和SET协议的比较 v电子商务具有商务性、服务性、协调性、集成 性、可扩展性及安全性等特点,为满足上述要求, 当前电子商务交易大多采用信用卡支付,这类系统 主要基于SSL和SET,但两者网上安全支付中是有 差别的。 SET是一个多方的消息报文协议,SET定 义了银行、商户、持卡人之间必需的报文规范,而 SSL只是简单地在两方之间建立了一条安全连接。 SSL报文能够在银行内部网或者其他网络上传输, 而SSL之上的卡支付系统只能与Web浏览器捆绑在 一起。 v一、 功能方面的异同 v 这两种协议在网络层的位置和功能并不相 同。SSL是基于传输层的通用安全协议,可 以看作用于传输的那部分技术规范。而SET 位于应用层,对网络上其他各层也有所涉及 。SET规范了整个商务活动的流程,从持卡 人到商家,到支付网关,到认证中心及信用 卡结算中心之间的信息流走向及必须采用的 加密、认证都制定了严密的标准,从而最大 限度地保证了商务性、服务性、协调性和集 成性。 v二、 安全方面的异同 v SET由于采用了公钥机制、信息摘要和认证体系 ,完全可以保证机密性、可鉴别性及信息完整性。 SSL中也采用了公钥机制、信息摘要和证书,可以 保证机密性和完整性,但SSL缺乏有效的数字签名 。从网上安全结算这一角度来看,显然SET比SSL 针对性更强,更受顾客青睐。SET在信用卡账号在 网上交易安全性方面控制远比SSL严密,它的针对 性远比SSL强。 v SET与SSL最大的不同在于它引入了一套完整的 认证体系,其中认CA就是该体系的重要执行者。与 此同时,它还明确规定了整套协议中信息流的加密 、验证乃至整个交易的处理过程。它不仅可以实现 客户的身份鉴别,同时也最大限度地确保了客户信 息保密性。在电子商务系统中建立完整的认证体系 ,是SET在信用卡结算方面安全性较高的重要原因 。 v三、 加密机制 v 从加密机制来看,SET与SSL侧重点各不相同。 由于SSL对网上传输的所有信息都加密,因此每次 传输速度相对较慢,尤其是当网页中图片较多时; 而SET对网上传输的信息进行加密,是有选择的, 它只对敏感性信息加密,比如只对Form中输入的信 用卡帐号加密。 v 由于SSL是基于传输层加密, SSL为高层提供了 特定接口,使得应用方无须了解传输层情况,对用 户完全透明;但SSL大都采用40位密钥。 vSET的加密过程则不同于SSL。在很大程度上加密 对它而言只是一种普及的技术手段,而不像SSL中 把加密看作一种重要组成部分。SET中广泛使用了 数字信封等技术,并采用严密的系统约束来保证数 据传输的安全性。 v四、 系统负载能力 v 系统负载能力对于SSL或SET都是一个严 重的问题。目前Internet用户增长极为迅猛, 而SSL和SET由于采用了大量加密及验证。 例如,在一次交易过程中,对SET商家服务 器要进行6次操作,SSL要4次(商家和支付网 关之间只要2次),而公钥加密计算量本身就 很大,因此商家服务器工作量极大。按目前 技术状况来看,很有可能发生无法应付高峰 负载的情况。 v五、 平台开放性 v 从平台开放性来看,SSL和SET都努力满足 客户的需要。目前几乎所有浏览器都支持 SSL,可用于Windows95/NT、Unix等多种操 作系统;而SET也得到了包括Unix、NT等网 络操作系统的支持。 v 当今市场上,已有许多SSL相关产品及工 具,它们大多较为成熟,能提供相当稳定的 服务。而关于SET的相关产品却相对较少, 也不够成熟。 9.4 在线支付 v一、网上安全支付 v1、中国银联的网上安全支付协议 v 近几年来,属于中国银联的上海Chinapay和广州好 易联的B2C电子商务有了很大发展。特别是广州好易联公 司的B2C电子商务,实现了以银行卡作支付工具的B2C网 上购物结算。好易联公司设置了支付网关,安装有服务 器证书,提供支付网关与开放式的互联网用户之间建立 通道安全。对于持卡人通过卡号和口令方式进行身份认 证,持卡人不安装CA证书,持卡人和支付网关不需要安 装其他与安全相关的软件。这是一种SSL协议+用户名 口令的认证方式,由银联银行卡交换中心系统进行跨行 交易,实现发卡行与收单行之间的划账清算。 v这种网上交易协议的最大问题是如何保证持卡人的网上 身份认证,保证数据的完整性以及交易的不可否认性。 v2、北京首都电子商城在线安全支付协议 v 北京首都电子商城在线支付协议是建立 在SSL安全协议之上的,采用PKI/CA证书机 制,通过几次点对点完成的安全交易。 v 首都电子商城在线安全支付协议,虽说 是支持SET或虚拟POS,但主要的还是基于 SSL协议结合PKI/CA证书机制,提供可靠的 交易各方的身份认证、保障网上数据的机密 性、完整性和不可否认性。 v 该协议的大致流程如下: v 网上消费者登录网上商城,浏览或检索商品; v 网上商户下订单给消费者; v 消费者填写订单及支付信息,并加密传输给电 子商城安全支付平台; v 电子商城安全支付平台向相关银行传递支付信 息; v首都电子商城在线支付流程 v 相关银行经授权后将确认信息返回给首都电子 商城安全支付平台; v 电子商城安全支付平台得到确认后通知商户; v 商户执行物流配送; v 日结时银行与商户完成清算。 v 该协议具有安全性、便捷性及开放性,是国内 较好的B2C电子商务安全协议。 v3、B2B的安全协议 v 国内在B2B的在线安全支付协议开发方面,由 于各种电子商务模式尚未成型,所以,目前尚没 见有成熟的品牌产品。一般来讲,基于SSL协议 的较多,即SSL+口令的简单认证。 v 解决网上在线安全支付,首先要制定网上安 全交易规范,即制定B2B、B2C电子商务参与各 方在网上进行交易的“游戏规则”。这就必须要有 人民银行清算中心、中国银联和相关商业银行以 及商家积极参与,共同研究制定网上交易规则。 在B2C方面中国银联具有得天独厚的优势地位; 而在B2B方面,因为涉及到跨行交易,所以支持 跨行网上交易统一认证的中国金融认证中心及人 民银行清算中心处于重要地位,他们是解决B2B 网上在线支付的关键环节。 v二、手机支付 v(一)手机支付的流程 1、概念: v 手机支付,就是消费用户用手机(载体)来进行 支付。手机支付的基本原理是将用户手机SIM卡与 用户本人的银行卡账号建立一种一一对应的关系, 用户只需通过发送短信MO方式,在系统的短信指 令的引导下完成交易支付请求,操作非常简单,随 时随地可以进行交易。 v2、手机支付功能: v 对于商家来说,也就是可让消费用户(买家)通 过手机来(向您)进行支付缴款的接口功能。 v3、手机支付种类 v 从支付数额角度来看,手机支付分为两大类:一 类是小额支付,即交易额在10元以下的支付;大额 支付是相对于小额支付而发生的数额较大的支付行 为,比如在线购物,近距离支付等。 v 小额支付和大额支付的区别主要在于两点:一是 两 类支付的实现方式不同,小额支付一般仅需要消 费者、商家、银行三方当事人就可以了,不需要认 证中心,而大额交易一般至少需要四方,比小额支 付多一个认证当事方;第二个不同点是二者对安全 级别的要求不同,对于大额支付而言,通过可靠的 金融机构进行鉴定是确保交易安全的一个必备条件 ,而对于小额支付来说,使用移动通信网络的SIM 卡鉴定机制就可以了。 v4、手机支付流程 v 1)、用户决定采购商品或者服务,并向销售者提 供个人信息和支付卡信息,这一过程所采用的通信 渠道独立于支付所采用的渠道(互联网、移动电话 等)。 2)、销售者用适用于支付工具的支付协议,将交 易控制转移
温馨提示
- 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
- 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
- 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
- 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
- 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
- 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
- 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。
评论
0/150
提交评论