书城教材教辅电子商务安全与实训
32285200000049

第49章 SET协议的相关技术概述

在开放的网络上如何保证交易安全、可靠地进行,成为影响电子商务能否普及的最重要的因素之一。SET正是在这种背景下应运而生的,它针对开放网络上安全、有效的银行卡交易,为互联网上卡支付交易提供高层的安全和反欺诈保证。

9.2.1SET支付系统协议分析

1.SET协议简介

在互联网上开发对所有公众开放的电子商务系统,从技术角度讲,关键的技术问题有两个:一是信息传递的准确性;二是信息传递的安全可靠性。前者是各种数据交换协议已经解决了的问题,后者则是目前学术界、工商界和消费者最为关注的问题。为此,西方学者和企业界在这方面投入了大量的人力和物力。

Visa和Mastercard以及其他一些业界的主流厂商通过多年的研究,于1996年提出了SET(安全电子交易)协议,并在1997年5月正式发布了SET1.0标准。这个标准自推出之后,得到了IBM、Netscape、Microsoft、Oracle等众多厂商的支持。SET协议是应用层的协议,是一种基于消息流的协议,它是面向B2C(Business to Consumer,企业对消费者)模式的,完全针对信用卡来制定,涵盖了信用卡在电子商务交易中的交易协议信息保密、资料完整等各个方面。

在SET协议中主要定义了以下内容:

加密算法的应用。

证书消息和对象格式。

购买消息和对象格式。

请款消息和对象格式。

参与者之间的消息协议。

SET协议确保了网上交易所要求的保密性、数据的完整性、交易的不可否认性和交易的身份认证。SET协议主要使用的技术包括:对称密钥加密(Symmetric Key Cryptography)、公钥加密(Public Key Cryptography or Asymmetric Cryptograp)、Hash算法、数字签名(Digital Signature)、数字信封(Digital Envelope)以及数字证书(Digital Certificate)等技术。SET通过使用公钥和对称密钥方式加密,以保证数据的保密性;通过使用数字签名、Hash算法和数字证书实现交易各方的身份认证、数据的完整性和交易的不可否认性。

SET协议1.0版发布以后,有关专家就开始了SET2.0版内容的讨论研究,以适应技术发展、业务发展的需要。SET2.0版对1.0版的改进内容较多,涉及很多方面,最主要的是采用智能卡技术、借记卡的PIN(即个人识别号)输入以及加密算法独立等三项内容。

2.SET协议的功能和实现的目标

SET协议是一个基于可信的第三方认证中心的方案,其主要的实现目标是:

(1)保证电子商务参与者信息的相互隔离。持卡人的资料加密或打包后到达银行,商家看不到持卡人的账户和密码信息,银行看不到持卡人的购物信息。

(2)保证信息在互联网上安全传输,防止数据被“黑客”或被内部人员窃取。

(3)解决多方认证问题,不仅要对消费者的信用卡认证,而且要对在线商店的信誉程度认证,同时还有消费者、在线商店与银行间的认证,保证付款的安全。

(4)保证网上交易的实时性,使所有的支付过程都是在线的。

(5)提供一个开放式的标准、规范协议和消息格式,促使不同厂家开发的软件具有兼容性和互操作功能,并且可运行在不同的硬件和操作系统平台上。

3.SET交易的参与方介绍

SET改变了支付系统中各个参与者之间交互的方式。在面对面的零售交易或邮购交易中,电子处理过程始于商家或付款银行;而在SET交易中,电子支付始于持卡人。SET交易的参与方包括持卡人、发卡机构、商家、收单银行、支付网关和数字证书认证中心CA。

(1)持卡人。

在电子商务环境中,消费者和团体购买者通过计算机与商家交流,持卡人通过由发卡机构颁发的付款卡(如信用卡、借记卡)进行结算。在持卡人和商家的会话中,SET可以保证持卡人的个人账号信息不被泄漏。

(2)发卡机构。

它是一个金融机构,为每一个建立了账户的顾客颁发付款卡,发卡机构根据不同品牌卡的规定和政策,保证对每一笔认证交易的付款。

(3)商家。

它提供商品或服务,接受卡支付的商家必须和银行有关系。

(4)收单银行。

在线交易的商家在银行开立账号并且处理支付卡的认证和支付。

(5)支付网关。

是由银行操作的将Internet上的传输数据转换为金融机构内部数据的设备,或由指派的第三方处理商家支付信息和顾客的支付指令。

(6)数字证书认证中心(Certificate Authority,简称CA)。

它的主要工作是负责SET交易数字证书的发放、更新、废除、建立证书黑名单等各种证书管理。

4.SET规范和采用的外部标准

(1)SET技术规范。SET协议分为三个部分:

①商业描述(The Business Deion)。提供处理的总述。

②程序员指导(The Programmer's Guide)。介绍数据区、消息以及处理流程,分为系统设计考虑、证书管理、支付系统。

③正式的协议定义(The Formal Protocol Definition)。提供SET消息和数据区最严格的定义,协议定义采用ASN。1语法进行。

(2)SET扩展规范。

在SET原来的规范中没有提供其他的商业功能,这些商业功能是通过SET扩展来提供,截至2000年3月止,已经公布了以下批准的扩展:

①CVV2/CVC2扩展(The CVV2/CVC2extension)。允许购买请求信息携带附加的卡验证数据。

②通用密码产生器扩展(The Generic Cryptogram extensions)。允许信息从一个硬件标记(hardware token)得到,并包含在持卡人产生的支付指令中。

③日本支付选项扩展(The Japanese Payment Option extension)。允许持卡人和商家交互特殊信息,这些信息和日本国内特定交易相关的支付选项有关。

④商家开始非SET交易的授权扩展(The Merchant Initiated Authorization extension)。允许一个商家使用SET消息来为特定订购进行授权和请款,这些订购是由持卡人采用非SET的传输方式完成的。

⑤在线个人识别号扩展(The Online PIN extensions)。允许个人标识码PIN和相关信息包含在持卡人产生的支付指令中。

⑥通用IC卡扩展(The Common Chip Extension)。在购买请求消息中,为传输IC卡中的数据提供一种方式。

(3)SET采用的外部标准。SET的设计是基于各种工业、Internet和国际组织的标准,这些标准定义在ISO、IEFT、PKCS、ASN。1中,下面是SET支持的这些标准、算法、证书支持:

①ASN。1.ASN。1(Abstract Syntax Notation)是SET用于定义消息的符号。

②DER。DER(Distinguished Encoding Rules)以明确清楚的形式,实现支付消息和证书中的协议数据的编码。

③DES。DES(Data Encryption Standard)数据加密标准用于对称数据加密,DES密钥采用一个加密形式来分发,该加密形式是一个采用公钥加密的数字信封。

④HMAC。HMAC是指密钥Hash机制(Keyed-hashing mechanism),用于共享密钥的功能。

⑤HTTP。HTTP是World Wide Web的传输协议,在RFC1945中定义。

⑥MIME。MIME用于支付消息的封装编码,使浏览器支持和识别支付消息,也能够支持电子邮件方式的商务。

⑦PKCS。PKCS用于定义密码消息语法(PKCS#7)和证书请求语法(PKCS#10)。

⑧SHA-1.单向杂凑函数,SET的所有数字签名都采用SHA-1.

⑨TCP/IP。TCP/IP是支持Internet通信的协议集。

⑩X。509.公开证书的编码标准,SET支持的证书格式定义在ISO标准X。509版本3中。

9.2.2SET的加密技术和认证技术

SET协议是一种电子支付系统的安全协议,因此它涉及加密、认证等多种技术。

1.主要加密技术

加密技术是SET协议中的核心技术,在SET中使用的主要包括对称加密、非对称加密、数字签名、消息摘要、数字信封、双重签名等。通过这些加密技术的使用,为电子交易的过程提供了身份的认证、交易信息的完整性、信息的机密性和交易的不可否认性。

(1)消息摘要(Message Digest)。

交易双方在传送信息时,不仅要对数据进行保密,而且还要知道数据在传输过程中是否被别人篡改过,也就是要保证数据在传输过程中的完整性。采用的方法是将原文生成一个完整性值,将此完整性值与原文一起传送给接收者;接收者将收到的原文用与发送者同样的方法,生成另一个完整性值;然后将这个完整性值与收到的完整性值进行比较,如果相同,则说明原文没有被改变过,否则,原文已被改变。这个完整性值由原文通过某一加密算法产生,比原文短小,能代表原文,因而称为消息摘要。

对消息摘要有几个要求:第一,生成消息摘要的算法必须是一个公开的算法,数据交换的双方可以用同一算法对原始数据经计算而生成的消息摘要进行验证;第二,算法必须是一个单向算法,就是只能通过此算法从原始数据计算出消息摘要,而不能通过消息摘要得到原始数据;第三,不同的两条消息不能得到相同的消息摘要。

在SET系统中,消息摘要由Hash算法生成,它是一个单向的不可逆的算法,数据经此算法处理后,能产生一数据串,但不可能由此数据串再用任何办法还原成原来的数据。Hash算法是公开的,接收者收到消息和消息摘要后,用同样的Hash算法处理原始消息,得到新的消息摘要,只要比较两条消息摘要是否相同,就可以确定所收到的消息摘要是否是由所收到的原始消息生成的。

SET协议中采用的Hash算法可产生160位的消息摘要,不同的消息将产生不同的消息摘要,对消息哪怕只改变一位数据,产生的消息摘要都会发生很大的变化。

Hash算法本身并不能保证数据的完整性,它必须与其他密码技术结合起来才能保证数据的完整性。在SET系统中是将消息摘要用发送者的私有密钥加密,产生数字签名来保证数据的完整性;接收者收到加了密的消息摘要,就用发送者的公开密钥解密,然后,通过消息摘要就可以判断收到的消息的完整性。

(2)数字信封(Digital Envelope)。

为了充分发挥对称加密和非对称加密各自的优点,在SET协议中对信息的加密将两者充分结合起来同时使用。数字信封类似于普通信封,是为了解决密钥传送过程的安全而产生的技术。

它的基本原理是:首先将要传送的消息用对称密钥加密,但这个密钥不先由双方约定,而是由发送方随机产生,用此随机产生的对称密钥对消息进行加密;然后将此对称密钥用接收方的公开密钥加密,就好像用信封封装起来,所以称作数字信封;接收方收到消息后,用自己的私人密钥解密数字信封,得到随机产生的对称密钥;最后用此对称密钥对所收到的密文解密,得到消息原文。

由于数字信封是用消息接收方的公开密钥加密的,只能用接收方的私有密钥才能解密,别人无法得到信封中的对称密钥,因而确保了信息的安全。

(3)双重签名(Dual Signature)。

持卡人在网上向商家要求购买商品,如果商家接受这笔交易,就在网上向银行要求授权,但是持卡人不愿意让商家知道自己的账号等信息,也不愿意让银行知道他用这笔钱买了什么东西,为了解决这个问题就可以采用双重签名。

SET系统中双重数字签名的产生和验证过程如下:

双重数字签名的产生过程:

持卡人通过Hash算法分别生成订购信息OI和支付指令PI的消息摘要H(OI)和H(PI)。

把消息摘要H(OI)和H(PI)连接起来得到消息OP。

通过Hash算法生成OP的消息摘要H(OP)。

用持卡人的私有密钥加密H(OP)得到双重数字签名Sign(H(OP))。

持卡人将消息(OI,H(PI),Sign(H(OP)))用商家的公开密钥加密后发送给商家,将消息(PI,H(OI),Sign(H(OP)))用银行的公开密钥加密后发送给银行。

双重签名的验证过程:

商家将收到的消息用自己的私人密钥解密后,将消息OI生成消息摘要H(OI);同样银行将收到的消息用自己的私人密钥解密后,将消息PI生成消息摘要H(PI)。

商家将生成的消息摘要H(OI)和接收到的消息摘要H(PI)连接成新的消息OP1;银行将生成的消息摘要H(PI)和接收到的消息摘要H(OI)连接成新的消息OP2.

商家将消息OP1生成消息摘要H(OP1);银行将消息OP2生成消息摘要H(OP2)。

商家和银行均用持卡人的公开密钥解密收到的双重数字签名Sign(H(OP))得到H(OP)。

商家将H(OP1)和H(OP)进行比较,银行将H(OP2)和H(OP)进行比较,若相同,则证明商家和银行所接收到的消息是完整有效的。

经过这样处理后,商家就只能看到订购信息(OI),而看不到持卡人的支付信息(PI);同样银行只能看到持卡人的支付信息(PI),而看不到持卡人的订购信息(OI)。

2.认证技术

网上交易的买卖双方在进行每一笔交易时,为了保证交易的可靠性,买方和卖方都要鉴别对方的身份。交易双方可以通过互联网,在一些网站上获取对方的公开密钥,这种办法虽然有效可行,但这种方式获取的公开密钥不可靠,必须对这些密钥进行验证。例如,甲方不能简单地在互联网上向乙方询问他的公开密钥,因为在网络上可能存在居心叵测的第三者,他很有可能截获甲方请求,并发送他自己的公开密钥,借以阅读甲方传送给乙方的所有消息,并有可能假借乙方的名义欺骗、攻击甲方。因此,需要一个可靠的第三方来验证公钥确实属于乙方,这样的第三方就被称为认证机构(简称CA)。通过认证机构来认证交易双方身份的合法性,是保证电子支付系统安全的重要措施。CA的主要功能有:接收注册请求处理、批准/拒绝请求、发行证书。处理流程中,可能采取一个服务器设备来提供CA功能,或使用多个服务器来发行和处理请求。认证技术具体涉及以下一些内容。

(1)证书信息。

电子商务交易时,买方在向卖方发送购物信息的同时,还应向对方提交一个由CA签发的包含个人身份的证书,以使对方相信自己的合法身份。顾客向CA申请证书时,可提交自己的驾驶执照、身份证或护照,经认证机构验证后,向顾客颁发证书,证书包含了顾客的名字和他的公钥,以此作为网上证明顾客合法身份的依据。在SET中,最主要的证书是持卡人证书和商家证书。持卡人证书实际上是支付卡的一种电子化的表示,它是由金融机构以数字化形式签发的,因此不能随意改变。持卡人证书并不包括账号和终止日期信息这样的敏感信息,而是用单向Hash算法,根据账号、截止日期生成的一个代码。如果知道账号、截止日期和密码值,即可导出这个代码。商家证书与持卡人证书的内容基本一样,其作用表示在商家这里都可以用哪些品牌的卡来结算。它也是由金融机构签发的,不能被第三方改变。在SET环境中,与一个银行打交道,一个商家至少应有一对证书。一个商家也可以有多对证书,表示它与多个银行有合作关系,可以接受多种付款方法。除了持卡人证书和商家证书以外,还有支付网关证书、银行证书和发卡机构证书等。

①持卡人证书。

持卡人证书表明持卡人拥有的支付卡是合法的,它是由权威的金融机构数字签署的,不能由其他非法第三方产生。持卡人证书不包括账号和过期日期,代替账户信息的是仅仅由持卡人软件知道和使用单向Hash算法产生的一个秘密值。如果知道账号和过期日期以及该Hash值(数字指纹),可以验证对应的证书。但是不能从证书中直接得到这些敏感信息。在SET协议中,持卡人向支付网关提供用于验证的账户信息和该Hash值。只有当持卡人的发卡金融机构验证用户后,才向持卡人发布一个证书。在交易过程中,持卡人证书和加密的支付指示发向商家,商家收到持卡人证书,能够最低限度验证该持卡人的证书是由一个权威金融机构发行的,并且是可靠有效的。

②商家证书。

商家证书与持卡人证书基本一样,也是由商家的权威的金融机构数字签署的,商家证书不能由其他第三方非法发行,它表示商家能够接收该支付卡的消费。这些证书由收单行金融机构认证,说明商家与收单行达成协议。在SET协议中,对应于每个支付卡品牌,一个商家都拥有一个证书。一个商家至少拥有一个证书,也可以有多个证书。

③支付网关证书。

支付网关证书由收单行或收单行的处理系统拥有,持卡人从支付网关证书得到公钥来加密保护持卡人的账户信息,保证只有收单行才能看到持卡人的账户信息。支付网关证书由支付卡品牌的收单行发行。

④收单行证书。

一个收单银行必须拥有证书,才能使一个CA接收和处理商家从公共和专用网络发出的证书请求。

⑤发卡行证书。

一个发卡银行必须拥有证书,CA才能接收和处理来自持卡人的证书请求(通过公共或专用网络),那些选择支付卡品牌来代理处理证书请求的发卡行不需要证书。

(2)证书的发行。SET证书通过一个信任层次来验证,每个证书连接一个实体的数字签名的签名证书,沿着信任树到一个众所周知的信任机构,用户可以保证该证书是有效的。例如,一个持卡人证书连接一个发卡行的证书(或代表发卡行的品牌),发卡行证书通过品牌证书连接一个根证书。所有SET软件知道根证书的公用签名密钥,可用于验证每个证书。

根密钥(Root key)由根CA自己签名来发布,该根密钥证书由软件开发商插入他们的软件中。软件通过向CA发出一个初始化请求(包括根证书的Hash值),可以确定一个密钥的有效性。如果软件没有一个有效的根证书,CA将在响应中发出一个根密钥。

当根证书产生后,一个替代密钥也产生了,替代密钥将被安全保存直到需要使用,替代密钥的Hash值和自签名的根证书是同时发行的。软件将通过包括一个替代根密钥的自签名证书和下一个替代根密钥的Hash值的消息来指明替代者。软件通过计算它的Hash值与包括在根证书中的替代密钥的Hash值相比较,来确认替代根证书的有效性。

(3)认证信息和验证结构。

在应用认证技术时,要涉及到认证信息和验证结构。

在SET中,交易双方的身份必须要验证,CA是提供身份验证的第三方机构,由一个或多个用户信任的组织实体组成。例如,持卡人要向商家发送购物信息时,可以从公开媒体上获取商家的公开密钥,但持卡人无法确定这是否真是商家的公开密钥以及它的信誉度是多少。于是持卡人需要向CA请求对商家进行认证。CA通过对商家发送给持卡人的证书进行调查、验证和鉴别后,将权威机构发送的包含商家公钥的证书传给持卡人。同样,商家也可对持卡人进行验证。证书一般包含拥有者的标识名称和公钥,并且由CA进行过数字签名。在实际运作中,CA可由大家都信任的一方担当。例如,在客户、商家、银行三角关系中,客户使用的是由某个银行发的卡,而商家又与此银行有业务关系(有账号)。在此情况下,客户和商家都信任该银行,可由该银行担当CA角色。又例如,对商家自己发行的购物卡,则可由商家自己担当CA角色。

在通信时,交易双方可以通过出示由某个CA签发的证书来证明自己的身份。如果对签发证书的CA本身不信任,则可验证CA的身份,依此类推,一直到公认的权威CA处,就可确信证书的有效性。SET证书正是通过信任层来逐级验证的。沿着信任树一直到一个公认的信任组织,就可确认该证书是有效的,每一个证书与一个数字化签发证书的实体的签名证书相关联。例如,C的证书是由名称为B的CA签发的,而B的证书又是由名称为A的CA签发的,A是权威的机构,通常称为根(Root)CA。验证到了Root CA处,就可确信C的证书是合法的。在网上购物过程中,持卡人的证书与发卡机构的证书关联,而发卡机构的证书通过不同品牌卡的证书连接到Root CA,而Root CA的公共签名密钥对所有的SET软件都是已知的,因而可以校验每一个证书。

9.2.3SSL协议的加密原理

我们在了解SSL加密原理之前,需要理解加密及数字签名的概念,这里把需要的概念作一简单描述。

1.加密的密码算法

加密是指使用密码算法对数据作变换,使得只有密钥持有人才能恢复数据面貌,主要目的是防止信息的非授权泄露。

密码算法的分类:

(1)对称密钥算法。加密密钥和解密密钥相同,密钥必须特殊保管。

优点:保密强度高,计算开销小,处理速度快。缺点:密钥管理困难。

对称密钥法的典型例子是:DES、RC5、IDEA、RC4.

(2)公开密钥算法。加密密钥与解密密钥不同,不可能由加密密钥推导出解密密钥。每个用户都有两个密钥:一个在信息团体内公开称为公钥,一个由用户秘密保存,称为私钥。

优点:便于密钥管理、分发和签名。缺点:计算开销大,处理速度慢。

公开密钥法的典型例子是:RSA。

若以公钥Kp加密,用私钥Kr解密,可实现多个用户加密信息,只能由一个用户解读,适用于保密通信;若以私钥Kr加密,用公钥Kp解密,能实现由一个用户加密的信息而由多个用户解密,适用于数字签名。

(3)单向函数算法。也称Hash算法,能够非常容易地把明文变成密文,把密文转成明文是困难的。最常用的Hash算法是:MD5和SHA-1.

2.数字签名

数字签名是指使用密码算法对待发的数据(报文、票证等)进行加密处理,生成一段信息,附着在原文上一起发送,这段信息类似现实中的签名或印章,接收方对其进行验证,判断原文真伪。数字签名的目的是提供数据完整性保护。

3.数据完整性机制

定义:数据完整性机制是保证数据在存储、传输、处理过程中的真实有效和一致性。

方法:消息认证码MAC来保护待发的数据(报文、电文)。

数据鉴别DAC:保护存储的数据(数据库表中的字段)。

具体做法是:使用密码算法对原数据(报文及数据库中数据)或原数据中的关键字段进行计算,得到一小段附加数据。这一小段数据与原数据的每一位都相关,使得原数据的每一位的变化都会反映到这小段数据上来。因此,用它可判断原数据的内容是否被改变,出处是否真实。

4.SSL实现的工作流程

下面的例子包括Alice和Bob,演示了如何使用公用密钥密码系统来轻易地实现身份验证。{something}key表示something已经用密钥加密或解密。

Bob有一个密钥对,即一个公钥和一个私钥。

Bob如何以一种可信赖的方式分发他的公钥呢?

为了解决这个问题,标准化组织发明了证书,一个证书包括下面的一些内容:

证书发行者的名字;

证书拥有者的名字;

证书拥有者的公钥;

时间戳;

数字签名。

证书是由证书发行者的私钥签名的,每个人都知道证书发行者的公钥。证书是一种把公钥绑定到名字的标准方式。

通过使用证书这种技术,每个人都可以通过检查Bob的证书来判断Bob是不是伪造的。假设Bob严格地控制着他的私钥,并且的确是Bob得到了他的证书,那么一切都好。下面是补偿协议:

A→B hello

B→A Hi,I'm Bob,bobs-certificate

A→B prove it

B→A Alice,This is bob{digest[Alice,This is Bob]}bobs-private-key

当Alice收到Bob的第一条消息,他可以检查证书,核实签名,然后核实主题(Bob的名字)来判断那是不是真的Bob。这样他就相信公钥是Bob的公钥,然后要求Bob证明他的身份。Bob则重新进行一次上面的相同过程,计算消息的摘要,签名之后发给Alice,Alice可以用从证书得到的公钥检查Bob的消息摘要,从而判断Bob的身份。

一旦Alice认证了Bob,他就能发给一条只有Bob才能解码的消息:

A→B{secret}bobs-public-key

发现这个秘密的唯一方法就是用Bob的私钥来解密上面的消息,交换秘密是公用密钥密码系统的另一种强大的用法。

这项技术加强了互联网的安全性,它把这个密码当做另一个密钥,但是这时它是对称性密码系统算法的密钥(如DES,RC4,IDEA)。Alice知道这个秘密,因为这是自己在发送给Bob之前产生的。Bob知道这个秘密,因为Bob有私钥,能够解密Alice的消息。因为他们都知道这个秘密,所以他们就可以初始化一个对称的密码算法然后开始传输用它加密的消息。

Alice和Bob在他们的协议中引入了一种消息认证码(MAC)。MAC是根据秘密的密钥和传输的数据计算出来的,上面描述的摘要算法的属性正好可以用于构造MAC功能。

MAC:

Digest[some message,secret]

下面是样本协议:

A→B hello

B→A Hi,I'm Bob,bobs-certificate

A→B prove it

B→A{digest[Alice,This is Bob]}bobs-private-key

A→B ok bob,here is a secret{secret}bobs-public-key

A← →B{some message,MAC}secret-key