电子商务活动中电子支付与认证的标准与法规
http://finance.sina.com.cn 1999年12月23日 14:25 国研网
电子商务活动需要保证活动的安全可靠，一般应建立信用认证系统、采取安全支付方式、进行严格的金融交易
管理。本文进行安全、认证、交易及管理方面的研讨、介绍现有的协议和标准，指出涉及到的和应该建立的法律法规等问题。
一、电子商务主要的安全要素
电子商务活动的正常可靠进行必须考虑如下安全要素： 1、有效性
必须保证电子商务活动所传输的数据在确定的时刻、确定的地点是有效的。 2、机密性
信息存取和信息在传输过程中不能被非法窃取。应该保证公共网络商信息的机密性。 3、完整性
电子交易各方信息的完整性是电子商务的基础。应该防止对信息的随意生成、修改和删除，同时要防止数据传
送过程中信息的丢失和重复并保证信息传送次序的统一。 4、不可抵赖性
电子商务方式下，必须在交易信息的传输过程中为参与交易的个人、企业或服务部门提供可靠的标识。有第三方
提供有效的数字化过程记录，以防止任何一方出现的抵赖行为。 5、审查能力
根据机密性和完整性的要求，应对数据审查的结果进行记录。
二、网上支付标准
电子支付是资金在INTERNET上的传输，主要方式有企业对企业（B TO B）、企业对个人（B T
O C）等方式。电子支付涉及到的标准有： lPKI标准：公共密钥体系 (Public Key Infrast
ructure) lSSL标准：安全套接层协议（Secure Sockets Layer） lSET标准：
安全电子交易标准(Secure Electronic Transactions，简称 SET) lX5.95
标准：帐户数字签名工业标准 (Account Authority Digital Signatures, or
AADS), 提供了标准化信用卡处理和帐户管理方法。 lX.509标准：电子商务证书发放标准（ISO/IEC
/ITU X.509，基于PKI，简称PKIX ) lX.500标准：电子出版目录查询标准（目录服务协议L
DAP（X.500协议））
（一）PKI：公开密钥基础设施(PKI: Public Key Infrastructure)
PKI是一种遵循标准的密钥管理平台,它能够为所有网络应用透明地提供采用加密和数字签名等密码服务所必需的密钥和证
书管理。PKI是新的安全技术和安全规范。PKI必须具有认证机关(CA)、证书库、密钥备份及恢复系统、证书作废处
理系统、客户端证书处理系统等基本成分,构建PKI也将围绕着这五大系统来构建。
1.认证机关
CA是证书的签发机构。构建密码服务系统的核心内容是如何实现密钥管理，公钥体制涉及到一对密钥,即私
钥和公钥,私钥只由持有者秘密掌握,无须在网上传送,而公钥是公开的,需要在网上传送,故公钥体制的密钥管理主要是公
钥的管理问题,目前较好的解决方案是引进证书（certificate）机制。
证书是公开密钥体制的一种密钥管理媒介。它是一种权威性的电子文档，形同网络计算环境中的一种身份证，用
于证明某一主体（如人、服务器等）的身份以及其公开密钥的合法性。在使用公钥体制的网络环境中,必须向公钥的使用者证
明公钥的真实合法性。因此,在公钥体制环境中,必须有一个可信的机构来对任何一个主体的公钥进行公证,证明主体的身份
以及他与公钥的匹配关系。CA正是这样的机构,它的职责归纳起来有:
l验证并标识证书申请者的身份; l确保CA用于签名证书的非对称密钥的质量; l确保整个签证过程
的安全性,确保签名私钥的安全性; l证书材料信息（包括公钥证书序列号、CA标识等）的管理; l确定并检查证
书的有效期限; l确保证书主体标识的唯一性,防止重名; l发布并维护作废证书表; l对整个证书签发过程做
日志记录; l向申请人发通知。
2.证书库
证书库是证书的集中存放地,它与网上“白页”类似,是网上的一种公共信息库,用户可以从此处获得其他用户
的证书和公钥。构造证书库的最佳方法是采用支持LDAP协议的目录系统,用户或相关的应用通过LDAP来访问证书库。
系统必须确保证书库的完整性,防止伪造、篡改证书。
3.密钥备份及恢复系统
如果用户丢失了用于脱密数据的密钥,则密文数据将无法被脱密,造成数据丢失。为避免这种情况的出现,PK
I应该提供备份与恢复脱密密钥的机制。密钥的备份与恢复应该由可信的机构来完成，例如CA可以充当这一角色。值得强调
的是，密钥备份与恢复只能针对脱密密钥，签名私钥不能够作备份。
4.证书作废处理系统（X.509 Version 3、CRL Version 2）
证书作废处理系统是PKI的一个重要组件。同日常生活中的各种证件一样,证书在CA为其签署的有效期以内
也可能需要作废,例如,A公司的职员a辞职离开公司,这就需要终止a证书的生命期。为实现这一点,PKI必须提供作废
证书的一系列机制。作废证书有如下三种策略:
l作废一个或多个主体的证书; l作废由某一对密钥签发的所有证书; l作废由某CA签发的所有证书
。 作废证书一般通过将证书列入作废证书表（CRL）来完成。通常，系统中由CA负责创建并维护一张及时更新的CR
L,而由用户在验证证书时负责检查该证书是否在CRL之列。CRL一般存放在目录系统中。证书的作废处理必须在安全及
可验证的情况下进行,系统还必须保证CRL的完整性。
（二）SSL安全协议（Secure Sockets Layer）
SSL（安全套接层)协议最初是由网景公司研究制定的安全协议，该协议向基于TCP/IP的客户/服务器
应用程序提供了客户端和服务器的鉴别、数据完整性及信息机密性等安全措施。该协议通过在应用程序进行数据交换前交换S
SL初始握手信息来实现有关安全特性的审查。在SSL握手信息中采用了DES、MD5等加密技术来实现机密性和数据完
整性,并采用X.509的数字证书实现鉴别。 1. SSL安全协议的基本概念 SSL安全协议主要提供三方面的
服务： l认证用户和服务器，使得它们能够确信数据将被发送到正确的客户机和服务器上； l加密数据以隐藏被传送
的数据； l维护数据的完整性，确保数据在传输过程中不被改变。
2. SSL安全协议的运行步骤
SSL运行步骤包括六步：
l接通阶段：客户通过网络向服务商打招呼，服务商回应； l密码交换阶段：客户与服务商之间交换双方认
可的密码。一般选用RSA密码算法，也有的选用Diffie-Hellman和Fortezza-KEA密码算法；
l会谈密码阶段：客户与服务商间产生彼此交谈的会谈密码； l检验阶段：检验服务商取得的密码； l客户认证阶
段：验证客户的可信度； l结束阶段：客户与服务商之间相互交换结束的信息。
当上述动作完成之后，两者间的资料传送就会加以密码，等到另外一端收到资料后，再将编码后的资料还原。即使盗
窃者在网络上取得编码后的资料，如果没有原先编制的密码算法，也不能获得可读的有用资料。
在电子商务交易过程中，由于有银行参与，按照SSL协议，客户购买的信息首先发往商家，商家再将信息转发
银行，银行验证客户信息的合法性后，通知商家付款成功，商家再通知客户购买成功，并将商品寄送客户。
3. SSL安全协议的应用
SSL安全协议也是国际上最早应用于电子商务的一种网络安全协议，至今仍然有许多网上商店在使用。在点对
点的网上银行业务中也经常使用。该协议已成为事实上的工业标准,并被广泛应用于Internet和Intranet的
服务器产品和客户端产品中。如网景公司、微软公司、IBM公司等领导Internet/Intranet网络产品的公
司已在使用该协议。
（三）SHTTP
SHTTP(安全的超文本传输协议)是对HTTP扩充安全特性、增加了报文的安全性,它是基于SSL技术
的。该协议向WWW的应用提供完整性、鉴别、不可抵赖性及机密性等安全措施。目前,该协议正由Internet工程任
务组起草RFC草案。
SHTTP(Secure HTTP)容许Web浏览器对每个被检索的文档均要求核对电子签名。SSL和
SHTTP协议均提供了用户到服务器的传输数据的安全性保护。其实现方法是用对称密钥加密数据流。为防范窃听，对称密
钥经公共密钥加密后再传输至服务器。同样的方法还用于用户口令和信用卡号码到鉴别服务器的安全传输。
（四）SET安全协议(Secure Electronic Transactions，简称 SET)
SET标准（http://www.setco.com） SET是为了在Internet上进行在线交
易时保证信用卡支付的安全而设立的一个开放的规范。它是由Visa国际组织和万事达组织共同制定的一个能保证通过开放
网络(包括Internet)进行安全资金支付的技术标准。SET主要由三个文件组成,分别是SET业务描述、SET
程序员指南和SET协议描述。SET1.0版已经公布并可应用于任何银行支付服务。
由于设计合理，SET协议得到了IBM、HP、Microsoft、Netscape、VeriFone
、GTE、VeriSign等许多大公司的支持，目前已获得IETF标准的认可，成为B TO C业务事实上的工业标
准。
安全电子交易是基于因特网的银行卡支付系统，是授权业务信息传输的安全标准，它采用RSA公开密钥体系对
通信双方进行认证。利用DES、RC4或任何标准对称加密方法进行信息的加密传输，并用HASH算法来鉴别消息真伪，
有无篡改。在SET体系中有一个关键的认证机构（CA），CA根据X.509标准发布和管理证书。
1. SET安全协议运行的目标
SET协议要达到的的目标主要有五个： （1）保证信息在因特网上安全传输，防止数据被黑客或被内
部人员窃取。 （2）保证电子商务参与者信息的相互隔离。客户的资料加密或打包后通过商家到达银行，但是商家不
能看到客户的帐户和密码信息。 （3）解决多方认证问题，不仅要对消费者的信用卡认证，而且要对在线商店的信誉程度
认证，同时还有消费者、在线商店与银行间的认证。 (4)保证了网上交易的实时性，使所有的支付过程都是在线的。
(5)效仿EDI贸易的形式，规范协议和消息格式，促使不同厂家开发的软件具有兼容性和互操作功能，并且可以运行
在不同的硬件和操作系统平台上。
2. SET安全协议涉及的范围
SET协议规范所涉及的对象有：
(1)消费者，包括个人消费者和团体消费者，按照在线商店的要求填写定货单，通过由发卡银行发行的信用卡
进行付款。 (2)在线商店，提供商品或服务，具备相应电子货币使用的条件。 (3)收单银行，通过支付网关处理
消费者和在线商店之间的交易付款问题。 (4)电子货币（如智能卡、电子现金、电子钱包）发行公司，以及某些兼有电
子货币发行的银行。负责处理智能卡的审核和支付工作。 (5)认证中心（CA）。负责对交易对方的身份确认，对厂商
的信誉度和消费者的支付手段进行认证。
3、SET的认证
在用户身份认证方面，SET引入了证书（Certificates）和证书管理机构（Certifica
tes Authorities）机制。 (a)证书证书就是一份文档，它记录了用户的公共密钥和其他身份信息。在
SET中，最主要的证书是持卡人证书和商家证书。 持卡人证书：它实际上是支付卡的一种电子化表示。它是由金融机构
以数字签名形式签发的，不能随意改变。持卡人证书并不包括帐号和终止日期信息，取而代之的是用单向哈希算法根据帐号、
截止日期生成的一个编码，如果知道帐号、截止日期、密码值即可导出这个码值，反之不行。 商家证书：表示可接受何种
卡来进行商业结算。它是由金融机构签发的，不能被第三方改变。在SET环境中，一个商家至少应有一对证书。一个商家也
可以有多对证书，表示它与多个银行有合作关系，可以接受多种付款方法。 除了持卡人证书和商家证书以外，还有支付
网关证书、银行证书、发卡机构证书。 （b） 证书管理机构 CA是受一个或多个用户信任，提供用户身份验证的第
三方机构。证书一般包含拥有者的标识名称和公钥，并且由CA进行过数字签名。 CA的功能主要有：接收注册请求，处
理、批准/拒绝请求，颁发证书。用户向CA提交自己的公共密钥何代表自己身份的信息（如身份证号码或E-mail地址
），CA验证了用户的有效身份之后，向用户颁发一个经过CA私有密钥签名的证书。 （c）证书的树形验证结构 在
两方通信时，通过出示由某个CA签发的证书来证明自己的身份，如果对签发证书的CA本身不信任，则可验证CA的身份，
依次类推，一直到公认的权威CA处。就可确信证书的有效性。SET证书正是通过信任层次来逐级验证的。 通过SET
的认证机制，用户不再需要验证并信任每一个想要交换信息的用户的公共密钥，而只需要验证并信任颁发证书的CA的公共密
钥就可以了。
4、SET标准的应用
自1996年始，34个国家的150多家金融机构制定了SET试行方案。从新加坡到旧金山的信用卡公司都
开始建造SET交易网关，软件厂家则着手开发支持SET的应用软件。 （五）证书标准（x.509）PKIX（Pu
blic Key Infrastructure）公开密钥体制下的证书标准X.509 认证机构发放的数字证书
主要应用于： l通过S/MIME协议实现安全的电子邮件系统 l通过SSL协议实现浏览器与Web服务器之间的
安全通信 l通过SET协议实现信用卡网上安全支付。 l提供电子商务中认证证书标准。 ISO/IEC/IT
U X.509标准对证书格式的定义已被广泛接受（1988年为Ver 1，1993年为Ver 2，1996年发布
Ver 3）。 1、X.509的具体内容 X.509标准是在通用的网络安全工具如公共密钥加密系统和使用CA
(Certificate Authority ,证书管理机构),被用以保证在Internet及内部网上传送数据
的安全的认证标准。它基于公共密钥密码格式。X.509证书已用于许多网络安全应用程序,其中包括IP安全(IPSe
c)、安全套层(SSL)、安全电子交易(SET)、安全多用途 Internet邮件扩展(S/MIME)、NON
-SET认证等。
证书由CA根据X.509协议产生，应具备下列信息：
(1)版本号（V）：用来区分X.509的不同版本； (2)序列号（SN）：由CA给予每一个证书的
特殊编码； (3)签名算法（AI）：用于产生证书所用的方法以及一切参数； (4)发出该证书的认证机构（CA
）：CA的识别名字； (5)有效期限（TA）：包括两个日期，在所指定的两个时间之间有效； (6)主题信息
（A）：证书持有人的姓名、服务处所等信息； (7)公钥信息（TP）：被证明的公钥值，加上使用这个公钥的方法名
称； (8)认证机构的数字签名。
（六）X.500电子出版目录查询标准（目录服务协议LDAPX.500）
目录服务是用于网络信息查询的技术。目前网络上有大量的对象信息，这些对象可以是人，组织，国家，计算机
，甚至可以是计算机中的某个网络通信进程。人们经常需要查询它们的信息。虽然这些对象在不断变化着，但相对于查询的频
率而言，对象信息稳定时间是较长的。另外人们在日常生活中希望记住的是对方的名字，而不是给计算机读的地址，而且地址
也比名字更容易变化，所以经常要做“名字-地址”映射。基于这种需求，人们开发了目录服务网络应用。
目录中按一定的格式记录了现实世界中大量对象的信息，供用户（人，计算机应用程序等）做各种频繁查询和相
对少量的修改。实现目录服务的方式有多种，但目前趋于统一到ITU-TX.500系列建议标准。CCITT在1988
年制定了第一版X.500建议，后ITU-T又在1993年做了显著的修订和补充，产生了第二版建议（但版本编号仍为
1），ISO接受了此建议，把它作为ISO/IEC9594国际标准。
lX.500系列建议由9个建议组成： lX.500是目录服务的概要介绍； lX.501定义了目
录服务的模型； lX.511对目录的各种抽象服务作了定义； lX.518描述分布操作的实现过程；X.519
是传输协议； lX.520和X.521定义了常用对象类和属性； lX.509提出了一种认证的框架； lX
.525规定了备份。
X.500系列建议的目录服务是分布式的。每个目录的用户由一个目录用户代理（DUA）代表，它就是用户
用于访问目录服务的进程。在用户看来，整个目录在逻辑上是统一的整体，但实际上目录信息可以分布在不同组织管理的计算
机上。这些计算机中运行的相互配合提供服务的进程是目录服务代理（DSA），目录的分布式功能模型。
三、安全认证中心CA
CA是受一个或多个用户信任，提供用户身份验证的第三方机构。目前在世界范围内CA的主要功能都是接收
注册请求，处理、批准/拒绝请求，颁发证书。用户向CA提交自己的公共密钥和代表自己身份的信息（如身份证号码或E－
mail地址），CA验证了用户的有效身份之后，向用户颁发一个经过CA私有密钥签名的证书。
近年来，国际组织为建立全球电子认证中心制订了一系列的标准与法规，如ISO已颁布的密钥鉴别架构(Au
thentication Framework)标准ISO 9594-8、开放系统连接安全架构(Security
Frameworks in Open Systems) ISO 10181与ISO/IEC JTC1/WG2正
草拟中的存证 (Non-repudiation)标准ISO 13888等。
根据ISO各项已颁布及草拟中的相关标准，因特网网络工程技术小组(Internet Engineer
ing Task Force，简称IETF)在安全领域方面，正进行基于X.509的公开密钥基础建设(Publi
c Key Infrastructure (X.509)，简称PKIX)标准订定工作订定PKIX、通用鉴别技术
(Common Authentication Technology，简称CAT)、防火墙通过鉴别(Authen
ticated Firewall Traversal，简称AFT)、简单公开密钥基础建设(Simple Pub
lic Key Infrastructure，简称SPKI)、交易层安全 (Transport Layer S
ecurity，简称TLS)、网络交易安全(Web Transaction Security，简称WTS)等相
关标准，将逐步建成世界权威性的全球电子认证中心机制。
认证中心就是一个负责发放和管理数字证书的权威机构。对于一个大型的应用环境，认证中心往往采用一种多层
次的分级结构，各级的认证中心类似于各级行政机关，上级认证中心负责签发和管理下级认证中心的证书，最下一级的认证中
心直接面向最终用户。处在最高层的是认证中心（Root CA），它是所有人公认的权威，如人民银行总行的CA。
认证中心主要有以下几种功能：
1、证书的颁发
中心接收、验证用户（包括下级认证中心和最终用户）的数字证书的申请，将申请的内容进行备案，并根据申请
的内容确定是否受理该数字证书申请。如果中心接受该数字证书申请，则进一步确定给用户颁发何种类型的证书。新证书用认
证中心的私钥签名以后，发送到目录服务器供用户下载和查询。为了保证消息的完整性，返回给用户的所有应答信息都要使用
认证中心的签名。
2、证书的更新
认证中心可以定期更新所有用户的证书，或者根据用户的请求来更新用户的证书。
3、证书的查询
证书的查询可以分为两类，其一是证书申请的查询，认证中心根据用户的查询请求返回当前用户证书申请的处理
过程；其二是用户证书的查询，这类查询由目录服务器来完成，目录服务器根据用户的请求返回适当的证书。
4、证书的作废
当用户的私钥由于泄密等原因造成用户证书需要申请作废时，用户需要向认证中心提出证书作废请求，认证中心
根据用户的请求确定是否将该证书作废。
另外一种证书作废的情况是证书已经过了有效期，认证中心自动将该证书作废。认证中心通过维护证书作废列表
(CertificateRevocationList，CRL)来完成上述功能。
5、证书的归档
证书具有一定的有效期，证书过了有效期之后就将被作废，但是我们不能将作废的证书简单地丢弃，因为有时我
们可能需要验证以前的某个交易过程中产生的数字签名，这时我们就需要查询作废的证书。基于此类考虑，认证中心还应当具
备管理作废证书和作废私钥的功能。
四、安全认证的法律问题
安全认证需要的法律问题包括：
1、信用立法 2、电子签名法 3、电子交易法 4、认证管理法律
五、认证中心应有的管理机制
认证中心（CA）是进行网上合法身份和合法交易认证的权威证明机构，它依据国家法律、法规开展工作。它
坚持公平、公正、信誉第一的原则，起到维护网上金融信誉、防止金融诈骗的作用。
认证CA以独立于认证用户（商家和消费者）和参与者（检查和使用证书的相关方）的第三方的地位证明网上活
动的合法有效性。其本身不从事商业业务，不进行网上采购和消费活动。它接受国家政府部门的监督和管理。
认证中心具有独立法人地位，为用户管理认证证书；认证用户自原向认证中心申请认证证书以开展电子商务活动
；参与方是自愿加入认证中心的会员单位，必须接受有效证书的信用，完成用户涉及的电子商务活动。
1、各方的义务分别有：
1）、认证中心：发布用户认证证书、管理认证证书、保证认证的安全可靠，其本身必须满足管理、操作于系
统的有关要求。 l对参与者进行严格的审查和认证 l保证发放的证书具有可靠的权威性和信任度 l发布可靠及时
的认证信息
2）、认证用户（商家、消费者等）：合法使用认证机制、获得证书，开展电子商务活动。
l报出本身准确的相关信息 l及时检查证书内容和信息 l妥善包管好私人密钥 l及时汇报出现的
问题，例如密钥泄露、交易异常等现象
3）、参与者（银行等其他相关方）：合法使用认证机制，按照有关规定进行电子商务操作。
l检查证书本身的合法有效性 l进行证书失效检查 l通过其他方法确认证书的可靠性 l保证业务2
4小时正常运行
2、各方的责任：
1）、认证中心负有责任：
l由于管理漏洞出现问题，存在犯罪活动引起用户损失； l由于CA方密钥泄露出现问题，引起用户损失；
l由于认证操作出现问题，证书不完善引起用户损失； l由于失效信息发布问题，引起用户损失； l由于用户注
册信息泄露引起的用户损失； l由于CA系统和设备问题（停机、终止、信息丢失等）引起的用户损失。
2）、用户责任：
l用户信息问题出现的损失； l个人密钥丢失没有及时通知CA 引起的损失 l证书不全时进行交易产
生的损失 l非法使用证书产生的损失
3）参与者责任：
l证书检查不严格产生的损失； l密钥泄露产生的损失； l用户个人信息泄露产生的损失； l超限
制额度交易产生的损失； l其他非法交易产生的损失。
认证中心操作分为用户信用认证、交易合法认证两中证书，需要经过用户情况登记、资格审查、认证批准和证书
发放四个过程。认证证书的信用具有一定的限制条件。
认证中心必须保护用户有关信息的秘密，不能以任何方式恶意泄露私人信息。认证中心必须确保认证信息的安全
，包括管理、储存、传输过程中的安全。认证中心要建立定期的两级审查制度，由内部审查人员经常审查认证过程、证书发放
和证书注销等情况，并及时汇报人民银行；由人民银行进行年度全面审查认证中心管理、认证操作、证书发放、运行状态、用
户投诉、服务质量等情况。
3、认证中心具有严格的认证操作规则，具体有：
1）组织规则
l独立的中间机构：认证中心是独立于交易双方的中间机构，CA不能参加交易，也不能于交易双方具有利益关
系。
l发挥权威作用：认证中心必须以信誉为基础，获得公认的权威可靠性。 l严格的内部管理制度：保证操作
安全和信息安全。
2）操作规则
l操作要求：规定操作要求。 l安全控制规则：规定个人活动范围、处理的业务、期限和权限。 l密钥
管理规则：规定密钥产生、传输和管理的责任制度。 l审核规则：规定定期审核制度。
3）信息控制规则
l认证声明：公开有关认证活动的责任、义务、操作方式及相关措施。 l信息公开制度：发布相关认证信息
，例如证书生效、失效等公开信息。 l用户信息保护制度：保护认证中心、用户的机密信息。
4、网上问题处理
网上交易出现纠纷问题后，可由当事人提出仲裁申请，人民银行进行仲裁处理；如需要上诉，可上诉法院解决
。具体程序为：
l问题申诉程序 l分级仲裁措施 l政府部门协调 l问题处理依据北京天爱公共关系公司供稿
中国金融学院电子商务研究所所长 陈进
| 
![](http://images.sina.com/cgi-bin/staff/tagme"){kind=small}
