国 立 中 央 大 学
资 讯 管 理 研 究 所
硕 士 论 文
电子商务上应用XML安全技术的架构:
XMLSeF
研 究 生:简 长 成
指导教授:林 熙 祯 博士
中 华 民 国 九 十 一年 六 月30日
I
国立中央大学图书馆
硕博士论文授权书
(91年5月最新修正版)
本授权书所授权之论文全文与电子档,为本人於国立中央大学,撰
写之硕/博士学位论文.(以下请择一勾选)
( V )同意 (立即开放)
( )同意 (一年后开放),原因是:
( )同意 (二年后开放),原因是:
( )不同意,原因是:
以非专属,无偿授权国立中央大学图书馆与国家图书馆,基於推
动读者间「资源共享,互惠合作」之理念,於回馈社会与学术研究之
目的,得不限地域,时间与次数,以纸本,光碟,网路或其它各种方
法收录,重制,与发行,或再授权他人以各种方法重制与利用.以提
供读者基於个人非营利性质之线上检索,阅览,下载或列印.
研究生签名: 简 长 成
论文名称: 电子商务上应用XML安全技术的架构:XMLSeF
指导教授姓名: 林 熙 祯 博士
系所 : 资讯管理研究 所 o博士 硕士班
学号: 8 9 4 2 3 0 0 6
日期:民国 91 年 6 月 30 日
备注:
1. 本授权书请填写并亲笔签名后,装订於各纸本论文封面后之次页(全文
电子档内之授权书签名,可用电脑打字代替).
2. 请加印一份单张之授权书,填写并亲笔签名后,於办理离校时交图书馆(以
统一代转寄给国家图书馆).
3. 读者基於个人非营利性质之线上检索,阅览,下载或列印上列论文,应依
著作权法相关规定办理.
II
电子商务上应用XML安全技术的架构:XMLSeF
研究生:简长成 指导教授:林熙祯 博士
摘要
XML安全技术与相关规范是为了让结构性XML文件有属於自己的安全保护
标准,促使XML标准更能安全地应用在电子商务上,利用XML安全技术来保
护XML文件比传统安全技术更能发挥XML本身的结构性与延展性.目前网站
架构发展是以XML为基础的网站服务导向,但是,如何应用XML安全技术来
设计网站服务的安全机制甚少讨论.以及其他XML为基础的商务架构也不是应
用XML安全技术来保护资讯,所以,我们在此整合W3C组织公布的XML安全
规范,应用XML安全技术作为网站服务环境之安全保护,建立一个XML为基
础的安全通讯架构XMLSeF,并依据XML安全的标准规范,制定安全交易授权
书,XMLSeF架构是个集中授权的环境,使用者只要向网站服务安全提供者取
得安全授权书,就可以与众多合作网站进行交易,并且可以与其他网站服务安全
提供者转换安全授权书,到另一个网路联盟进行交易.
研究实作方面,以XMLSeF架构为基础实作具有「电子钱币保护」与「电
子钱币付款系统之间沟通能力」的电子付款系统雏型-XMLSePay系统,提供
电子钱币便利流通环境的建置参考,希望为线上电子钱币付款系统提供目前电子
现金流通困境的解决方法.最后再提出旅游行程规划与电子交易网两个XMLSeF
架构应用剧本,映证XMLSeF架构的实用性与可行性,以及XMLSeF架构可以
为网站联盟提供一个具有安全交易的网站服务互动环境.
最终说明XMLSeF架构的五个主要特性:便利性,开放性,发展性,相容
性,安全性,让大众更了解XML安全技术为XMLSeF架构所带来的优势.
关键字:XML安全,XML为基础的架构,电子付款系统,XML加密,XML数位签
章,SAML安全声明书,XML存取控制.
III
Abstract
Many organizations have instituted XML security technology and
specification to protect the XML documents or files. That is to prompt XML
standard to securely apply to E-Commerce. Using XML security technology to
protect XML documents is better than traditional security information
technology. Because XML security technology can retain structure and
expansibility of XML documents. And now the development of Web-based
framework is trending to XML-based Web Service. But there is less discussion
or survey to introduce how to use XML security technology to build security
model of Web Service. And many XML-based E-Commerce framework don't
use XML security technology to protect XML information. The result is that we
integrate the XML security Specification that is published by W3C.org.
Applying XML security technology to protect the Web Service environment and
build a XML-based framework, XMLSeF, to support security communication
between Web sites. According to XML Security specification to build Security
Transactions Authorization. XMLSeF framework is a centralized authorized
environment and users only need to get a Security Transactions Authorization
from Web Service Security Provider. Then this user can proceed transactions
with many Web sites.
In the research implementation, we build an e-payment system model in
accordance with XMLSeF framework. This e-payment system can protect
e-cash and have an ability to transfer e-cash between the different e-payment
systems. Its name-XMLSePay. XMLSePay can be a reference resource to
support e-payment system and XMLSePay be a resolution for the convenient
using of e-cash.
IV
Finally, introduce the five characteristic of XMLSeF framework:
Convenience, Opening, Expansibility, Compatibility, Security.
Keyword:XML Security, XML-based Framework, e-payment, XML
Encryption,XML Signature,SAML,XACL.
V致 谢
论文的顺利完成,首先要感谢的是我的论文指导教授林熙祯博士.从论文方
向的选定,资料的收集,研究方法及架构的建立,这一路走来,林熙祯博士对学
生论文写作过程中的指导及要求,让我逐渐培养出清晰的逻辑思考,敏锐的观察
力以及细心踏实的写作态度.
论文口试期间罗济群博士,侯永昌博士以及方文昌博士的宝贵意见,让我的
论文研究能更加周延与完整,在此致上学生由衷的感谢.
再来要感谢电子商务实验室的学长,同学及学弟们对我的帮助与指教,谢谢
你们.感谢与我一同成长的朋友们,你们的关心与鼓励伴随我共度过这些岁月.
最后要感谢我的家人,感谢父亲的教诲及母亲的悉心照料,你们的细心呵
护,成就了现在的我.感谢哥哥与姊姊的照顾,鼓励与包容.
谨以本论文献给大家.
VI
目录
第一章 绪论..........1
1.1 研究背景与动机...........1
1.2 研究目的.......................2
1.3 研究方法.......................3
1.4 章节概述.......................5
第二章 文献探讨..6
2.1 XML与电子商务..........6
2.1.1 电子商务上XML的应用................6
2.1.2 电子商务上XML所带来技术面的解决方案..........7
2.1.3 XML Security的重要性...................9
2.2 W3C与XML SECURITY.......................10
2.2.1 XML Encryption....11
2.2.2 XML Signature......16
2.2.3 XML Key Management Specification (XKMS).........21
2.2.4 Security Assertion Markup Language (SAML).........24
2.2.5 XML Access Control Markup Language (XACL).....28
2.2.6 Simple Object Access Protocol(SOAP)与安全性.....31
2.2.7 XML安全技术工具组....................35
2.3 XML-BASED的标准与架构..................35
2.3.1 XML为基础的标准........................35
2.3.2 BizTalk Framework.........................36
2.3.3 E-speak Service.....38
2.4 线上电子付款系统.....40
2.4.1 Millicent................40
2.4.2 eCoin.....................42
2.4.3 NetBill...................44
2.4.4 HiNet AAA.............45
2.5 网站服务的安全性(WEB SERVICE SECURITY)...............47
2.6 单一登录模式(SINGLE SIGN-ON).........48
2.6.1 Microsoft Passport49
2.6.2 Sun One Platform for Network Identity....................50
第三章 网站服务的安全架构:XMLSEF...........52
3.1设计理念与架构目标..52
3.2 系统架构与组成元件.52
3.2.1 网站服务安全提供者(Web Service Security Provider, WSSP)........54
3.2.2 网站服务提供者(Web Service Provider)................55
VII
3.2.3 安全授权书讯息的架构................56
3.2.4 联盟交易网中各个网站的密钥管理模式..............58
3.2.5 网站与网站之间的通讯方式........59
3.3 XMLSEF架构的交易流程...................60
3.3.1 安全授权书的产生,验证与交易资讯记录..........60
3.3.2 交易讯息的传输流程....................61
3.3.3 交易讯息的回收流程....................64
3.4 评估与比较.................67
3.4.1安全评估准则.......67
3.4.2 相关架构与议题的评估................67
第四章 应用XMLSEF架构的电子付款系统.....69
4.1 系统设计.....................69
4.1.1 XMLSeF系统角色与功能.............69
4.1.2 电子钱币内容结构与参数格式介绍......................70
4.1.3 电子钱币的讯息结构....................71
4.1.4 信任关系(Trust Relation)..............73
4.2 系统架构.....................73
4.3 系统交易流程.............74
4.3.1 电子钱币的产生,验证与购物结算......................74
4.3.2 购物与付款交易流程....................76
4.3.3 电子钱币回收流程........................79
4.5 系统实作.....................81
4.5.1 系统环境与工具组........................81
4.5.2 系统执行架构......82
4.5.3 系统运作流程实作........................83
4.6 系统评估与分析.........89
4.6.1 小额电子付款系统的需求原则....89
4.6.2 与之前介绍电子付款系统的分析90
第五章 架构的应用发展..............94
5.1 旅游排程应用-旅游经纪人应用模式.........................94
5.1.1 国内旅游行程规划模式................95
5.1.2 国外旅游行程规划模式................96
5.1.3 旅游行程规划模式的特色............97
5.2 电子交易网采购模式.98
5.2.1 单一电子交易网环境采购模式....98
5.2.2 两个以上电子交易网环境的采购模式................100
5.2.3 电子交易网采购模式的特色......101
5.3 XMLSEF架构的发展情况.................101
VIII
第六章 结论与未来研究............102
6.1 结论.102
6.2 研究贡献与研究限制.........................103
6.3 未来发展与建议.......106
参考文献............108
附录....................111
附录一,XML安全技术相关范例..........111
附录二,XMLSEPAY电子付款系统实作结果参考.........113
附录三,其他研究相关资讯....................119
IX
图目录
图 1 XML加密之核心元素EncryptedData....12
图 2 XML Encryption对整份文件进行加密...13
图 3 XML Encryption对单一元素节点进行加密.....................13
图 4 XML Encryption对单一元素节点的内容进行加密之1..14
图 5 XML Encryption对单一元素节点的内容进行加密之2..14
图 6 利用XML Encryption对非XML资讯进行加密..............15
图 7 Imran将他的公钥传送给Ali的请求.......15
图 8 Ali利用Imran公钥将Secret key加密传送给Imran回应讯息..............16
图 9 Imran使用安全密钥对重要资讯加密传输给Ali..............16
图 10 XML Signature结构.....17
图 11 XML Signature参照摘要集合结构.......19
图 12 XML Signature的元素结构.....................19
图 13 XML Signature的密钥相关资讯...........20
图 14 XML Signature完整讯息范例...............20
图 15 XKMS架构图................22
图 16 SAML安全声明书讯息结构..................25
图 17 利用SAML进行单一登录.....................27
图 18 SAML服务导向的交易模式..................28
图 19 XACL机制的Policy内容范例..............29
图 20 XACL机制的存取请求(Access Request)内容范例.....29
图 21 XACL授权决定范例.....30
图 22 XACL存取控制机制运作范例...............31
图 23 SOAP讯息结构............32
图 24 SOAP请求讯息范例....33
图 25 SOAP回应讯息............33
图 26 Biztalk运作图...............37
图 27 Millicent交易流程.........41
图 28 eCoin付款系统交易流程.......................43
图 29 NetBill交易流程............45
图 30 HiNet AAA交易流程....46
图 31 SOAP讯息的传输安全架构..................48
图 32 Passport的认证流程示意图.................49
图 33 Network Idnetity的作业流程示意图....51
图 34 应用XML安全技术的架构XMLSeF...53
图 35 安全授权书所包含的内容参考架构范本........................58
图 36 XKMS密钥管理架构....58
X
图 37 网站服务安全提供者的安全授权书产生流程................60
图 38 服务提供者(SP)验证安全授权书流程..61
图 39 交易资讯写入安全授权书流程..............61
图 40 网站服务安全提供者与网站服务提供者沟通模式........63
图 41 WSSP与WSSP沟通模式....................64
图 42 安全授权书交易传输路径......................65
图 43 安全证明书交易流程回溯追踪..............66
图 44 电子钱币的讯息结构....72
图 45 应用XMLSeF架构的电子付款系统XMLSePay..........73
图 46 付款经纪人的电子钱币产生流程..........74
图 47 网路商店电子钱币验证流程..................75
图 48 交易资讯写入流程........75
图 49 单一个付款经纪人与网路商店进行购物模式................76
图 50 两个以上的付款经纪人互动所建立的网路购物模式....78
图 51 三层式架构运作模式....82
图 52 XMLSePay电子钱包登录服务...............83
图 53 电子钱包服务界面........84
图 54 电子钱币初版结构内容84
图 55 电子钱币讯息架构........85
图 56 付款经纪人所提供的合作网站列表......85
图 57 网路商店对电子钱币验证结果..............86
图 58 付款经纪人於XACLProcesspr回应的讯息..................87
图 59 与网路商店1的交易结果......................87
图 60 应用XMLSeF架构的国内与国外旅游行程规划模式...96
图 61 应用XMLSeF架构的电子交易网环境.99
图 62 XMLSeF架构特性......102
XI
表目录
表 1 XML安全工具组.............35
表 2 以XML为基础的架构比较表..................68
表 3 XMLSePay付款系统与XMLSeF架构之角色参照........69
表 4 实作XMLSePay系统环境......................81
表 5 实作XMLSePay系统的功能部分..........88
表 6 五种电子付款系统特性比较....................91
表 7 XMLSePay的优劣势.....93
表 8 旅游行程规划应用XMLSeF架构的角色对照.................95
表 9 电子交易网应用XMLSeF架构的角色对照.....................98
1
第一章 绪论
1.1 研究背景与动机
一,目前正积极地推广网站服务与XML标准
在分散式运算环境不断发展的今日,从传统的静态网页到动态网页,目前已
经发展到以网站应用程式(Web Application)来称呼,网站的规模无限延伸,为了达到这种扩展的弹性,以服务为导向的架构就被提出了,被称为网站服务
(Web Service)[11].微软与IBM创建网站服务标准组织,称为网路服务相容
性组织(WS-I),提供公司简便的制造软体方式与企业间更容易的交易模式,网路
服务也可让消费者经由各类电子装置取得个人资讯,直接在线上进行各种活动.
另外,目前在电子商务上正积极地进行XML应用,包含有以XML作为B2B
企业电子资料交换的标准,与让内容提供者(ICP)网站只要利用XML标准,就可
以为其他网站提供标准化的可读性与可扩展性的资讯,分散式异质资讯系统的资
源整合也是以XML做为基础标准,最重要的是W3C组织已经为XML定订专属
XML标准的安全技术规范书,让XML文件的保护有标准规范可依循.
二,网站服务的安全性考量
现在商业网站正积极地往网站服务架构发展,目前网站服务的安全性却面临
了挑战,在新的网站服务环境下如何做到安全机制的考量,如认证性与不可否认
性等等,因此需要有开放式的安全标准或架构,来支援安全服务的界面开发,例
如使用XML格式来表现各种安全声明书(Assertion)[15].
三,W3C组织公布XML安全技术规范书
XML是专为网路文件而设计,可以让网页设计者自行定义标签的HTML延
伸规格,使用者可自行设计结构性资料及文件格式,XML文件可以用来储存与
2
接收资讯,或是於软体应用上提供描述方法,在目前应用XML来解决异质性系
统之间的沟通整合,为系统之间的沟通提供一个最佳界面,且目前的网站服务几
乎都是以XML为基础来开发[46].W3C与OASIS组织於近年来正陆续为XML
标准规格,与资讯业知名相关厂商,如微软与IBM等等,共同制定XML标准安
全相关的规格书与草案,一般总称为「XML Security」[21],所以,XML Security
的范畴当然也包含了一般的资讯安全技术,如XML Encryption[18],XML
Signature[30],XML Key Management Specification(XKMS)[1]与Secure
Assertion Markup Language(SAML)[24],这些规格书与技术让XML不再利用
传统的加密方式来对文件的进行保护,藉由XML安全相关规格书的实作来保护
XML文件的弹性与结构性.
四,电子付款系统对於电子商务的重要性
在电子商务的领域中,线上电子付款系统扮演著很重要的角色,线上电子付
款系统主要目的是要让消费者利用线上电子付款系统,自由地於网际网路上获得
想要商品的资讯并进行购买,却因为电子商务环境不同的付款需求,产生了不同
的交易架构,也造成网路上金钱的流动不如实际生活上那般简单.在线上金融交
易安全方面,已经有很多线上电子付款机制与架构被提出与实际地在运作,如电
子现金,电子支票,或者网路信用卡等等相类似的产品服务.由於电子付款机制
还是存有安全性与便利性等问题[42],让消费者不愿意去使用电子付款机制,促
使电子付款机制无法积极地推行.
1.2 研究目的
电子商务上积极推展XML应用,已有众多的资讯安全机制或方法来帮助保
护XML文件安全,但是,保护XML文件的方法都是将整份XML文件给加密封
装起来,无法弹性地做到保护的特定资讯区块,只能够被特定的被授权者存取;
3
另外,W3C与OASIS组织於近年来为XML标准制定了XML文件安全相关的
规格书或草案,目前对於XML安全技术的整合应用与实作系统的相关研究甚少
详细说明;虽说已经有很多以XML为基础的系统架构被提出,但是,甚少应用
XML安全技术到他们系统架构中,都只是藉由传统的安全技术来对XML资讯进
行保护,却往往造成XML本身结构与语意上原有的弹性与延展性失去,这不是
我们所希望看到的.
本研究就利用由W3C,OASIS组织与众多资讯界厂商极力地推展与制定出
来XML安全领域的规范书,藉由XML的结构性,延展性与XML安全技术的实
作,为网站服务建构一个以XML为基础的安全性支援架构XMLSeF,且利用本
架构来表现整体XML安全技术的特色,最后以架构为基础实作具有「电子钱币
保护」与「电子钱币付款系统之间沟通能力」的电子付款系统,提供电子钱币便
利流通环境的建置参考,希望为线上电子钱币付款系统提供目前电子现金流通困
境的解决参考方法,此电子钱币就如中央银行发行的货币一样,消费者只要持有
此电子钱币,就可以自由地到相关合作网站进行购买商品与结帐的动作,简化交
易付款的流程,加速了网路付款的效率,此电子钱币的设计上使用数位签章来保
障双方权益的不可否认性,与利用XML安全技术来保护电子钱币的安全性与消
费者资讯,并让电子钱币可靠地於各个网路商店间流通.最后,希望XMLSeF
架构可以作为联盟网站之间的合作参考方案.
1.3 研究方法
本论文主要的资讯文献来源包含有探讨W3C组织公布的XML安全相关标
准规格书中所描述的XML语法涵义,相关XML语法的处理流程与实作应用技
术,与相关XML安全领域的学术研究期刊,以了解正确的XML安全的语法定
义与处理流程或规则,进一步去探究XML安全如何於电子商务上的应用.参照
已经被提出以XML为基础的应用架构或系统,做为本研究架构的建置参考,例
4
如BizTalk,E-speak.并且研讨电子现金付款系统环境的背景资讯,参考传统
资讯安全的技术,利用本研究的XML安全技术架构模型来建置的电子现金付款
系统,实作XMLSeF架构以映证XML安全於电子商务上的助益.
本研究的实作辅助工具是依据参与XML安全相关规格书制定的厂商,他们
所发表与提供的XML 安全技术报告书与XML安全相关技术实作工具组,利用
这些实作工作组来研讨实作XML安全的技术.
依据以上的相关研究为基础,为网站服务建立一个安全交易架构XMLSeF,并以XMLSeF架构为基础,实作线上电子钱币付款系统XMLSePay,以SSL
安全通道来传输电子钱币与授权认证资讯,电子钱币的内容以XML文件格式来
规范,由XML Signature与XML Encryption来提供电子钱币的防伪性,完整性
与不可否认性;利用SAML(Security Assertion Markup Language)提供单一登录
(Sign Sign-on)授权与认证,让电子钱币持有者可以於合作网站之间授权购物;
并以SOAP(Simple Object Access Protocol)简单物件存取协定来传输电子钱
币,让电子钱币可以跟著使用者浏览到各个网路商店并进行结帐付款.
使用网路安全上最常使用的五个基本的安全评估准则,来衡量本系统架构与
流程,确保本系统架构的可行性[45]:
l 机密性(Confidentiality):
保证没有经过授权的使用者,无法窃取资讯.预防非法的资讯存取和资讯在
传输过程中被非法窃取.
l 授权 (Authorization.):
给予使用者可以进行执行特定程序的权力许可.将不同的特权给予不同类型
的使用者.
l 资料完整性(Data integrity):
保证没有经过授权的使用者不能改变或者删除资讯,资讯在传送的过程中不
会遭到偶然或故意破坏,保持资讯的完整.
l 不可抵赖性(Nonrepudiation):
5
保证该资讯的传送者不能抵赖或否认对资讯的传送,当然资讯传送之前,需
要对传送者进行安全认证.
1.4 章节概述
第二章描述XML安全技术与规范书,XML基础的应用架构,电子付款系统
等等相关文献探讨,第三章提出应用XML安全技术的架构-XMLSeF,利用XML
全技术建置电子商务安全架构以支援网站服务的安全机制,让电子商务交易的资
讯交换流程更便利与安全.第四章应用此架构於电子现金付款系统上,建置
XMLSePay电子付款系统,并与目前现行的电子现金付款系统相互比较映证.
第五章藉由剧本模拟来说明本雏型架构的其他实作应用方案,以论证XMLSeF
架构於电子商务环境上的实用性.第六章结论说明本研究贡献与未来发展.
6
第二章 文献探讨
2.1 XML与电子商务
2.1.1 电子商务上XML的应用
XML与B2B电子资料交换(EDI; Electronic Data Interchange)
B2B(Business To Business)企业对企业的电子商务是指整个供应链上合作
夥伴间资讯流的整合与互动,早期是在加值网路服务上使用EDI来交换资讯,虽说EDI系统提供了企业之间沟通的方式,但是,传统上EDI的问题是系统开
发时间长,建置成本高,这是小型企业所不能克服的问题,导致於制造商与零售
商之间渐渐地减少他们本身的供应商数目,趋向於单一供应链模式,对於企业这
是很不好的情况[15].这些问题都可以经由使用W3C组织所提出的XML交换标
准来解决,名为EDI/XML组织正积极在EDI的开放式版本上做努力,目标是要
建立一种通用的方式执行电子商业活动[11].
XML与内容提供者
现在很多内容丰富的网站,都是由数个网站以联合的方式提供内容,这种联
合方式的范例之一就是电子新闻网站.假若有一个新闻资讯网站需要依照地域性
来提供给使用者所预期的资讯,该网站就需要与不同的区域性新闻网站订立合约
且说服他们转换资料格式,最后需要花费时间分别开发转换筛选器来解译他们的
资料,以符合本新闻网站资料格式[11].若采用XML标准作为解决方案,每一
个资料提供者只需要建立一个转换筛选器,将提供者的格式转换为XML格式,让所有的网站使用相同定义的字汇进行通讯,然后网站就可以利用取得的XML
格式资讯来转换为各网站系统自己所需的格式.好处是可以减少网站经营者分别
为每一个资料提供者建立转换软体的需求,降低了网站经营的成本.
7
XML Web Service
XML Web Service是一个具有开放性,分散式的软体元件,基础建立在
HTTP,XML,SOAP,WSDL等标准的协定上,使用者可利用任何的程式语言
开发工具和作业系统来描述与撰写Web Service.Web Service提供一个标准的
(远端)物件呼叫介面和应用程式写作规格,程式设计师可运用他所熟悉的程式语
言与网路上的其它Web Service元件进行存取与呼叫.无论是电子企业内各单
位的资讯沟通,或是与外部合作夥伴之间的异质系统资讯交换,网站服务架构皆
可提供一致性的资讯传输与整合服务.企业运用网站服务来整合他们的商业流
程,例如购买者可以开发一个采购应用程式,自动地获取来自不同供应商的价格
资讯,进而选择供应商与提交订单,并进行货物运输的追踪,直至收到货物;另
一方面供应商的应用程式除了在网站上提供服务外,还可以使用 XML 网站服务
检查客户的信用,收取货款,并与货运公司办理货运手续[34,35].
XML Web Service 体系结构的主要优点是允许在不同平台上,以不同语言
编写的各种程式以标准的方式相互通信,网站服务提供了一种类似「黑箱」的包
装,服务的要求者对於服务的细节不需要去了解,只要知道服务所回覆的资料内
容是什麼.相对以前的方案而言,XML 网站服务的另一大优点是使用标准的
Web协定,如XML,HTTP 和 TCP/IP[41].
2.1.2 电子商务上XML所带来技术面的解决方案
跨系统间的资讯整合(结构化的资料格式)
在网际网路的基础架构建立之后,B2B的通讯问题得到了最佳的解决,剩
下的就是资料格式的问题,过去由於网路频宽不足,电子资料都以简单的符号化
资料格式传递,虽然可以节省频宽,但是资料的可读性却很低,而且结构性,扩
充性不佳.直到XML出现,它具备了所有特性,马上被这个电子商务领域所注
目,并且被公认是资讯交换格式的最佳选择.企业间的B2B电子商务,由於系
8
统相异性与商业机密性的原因,资讯沟通的困难度较高与B2C电子商务,原因
是B2B是应用程式之间自动进行沟通,且B2B通常需要与众多厂商沟通交易,而且资料的格式往往不同.XML具有应付复杂资料格式的特点,以及容易编写
与阅读的特性,因此成为B2B最受推崇的资料格式[17].
分散式应用程式的解决方案
企业内或是企业间的应用程式若是需要协力工作,资料的安全传输是最大的
议题.理想的资料流是能够如同在单一应用程式内般畅通使用.以往是利用远端
程序呼叫(Remote Procedure Call,RPC)的方法,但是RPC涉及网路传输
与异质性系统间的沟通,效率与可携性一直是难以两全的问题,例如CORBA架
构太过严谨,兼顾的范围过广,有实际运作上的困难,Java RMI缺点则在於一
定要两边都使用Java程式才能沟通[11].
因此XML over HTTP技术提供RPC难题的解决方案,XML标准容易实作
且物件资料容易以XML形式表达,以HTTP为RPC的通讯协定,可以通过企
业大部分的防火墙,没有沟通的障碍.SOAP协定就是针对XML over HTTP的
诉求,不管通讯两端实作的系统为何,只要传递的资讯是XML就可以接收.藉
由XML over HTTP的RPC,远端系统所提供的程序,可以被近端以如同呼叫近
端程序的方式执行.让不同硬体,不同作业系统,不同语言所写的应用程式,可
以很自然有效率地联手运作.
XML Security相关规范与技术
W3C组织与OASIS组织於近年来正陆续为XML标准规格,与资讯业知名
相关厂商,如微软与IBM等等,共同制定XML安全相关的规范书与草案,一般
总称为「XML Security」,这个范畴包含了一般的资讯安全技术,如XML
Encryption,XML Signature,XKMS与SAML,这些规范书与技术让XML文件
有一套最适合XML文件的安全保护措施.
9
2.1.3 XML Security的重要性
W3C与知名资讯厂商正努力地制定与推动XML Security相关规范书与草
案,XML Security如此重要的原因如下:
提供便利的单一登录(Single Sign-on)
在网际网路上要管理合作网站之间的使用者名称及密码,是件很不容易的
事,如台湾Yahoo及奇摩网站Kimo合并案就是一例,双方会员资料的整合,不只是网站方面得花费长时间来设计程式处理,使用者也得再一次进行会员身份
认证手续,类似这样的问题已被很多联盟的网站所重视,每个网站都有自己的认
证保护系统,但是又考虑到要将网站的服务提供给联盟网站的会员使用,因此单
一会员登录相关技术产生,XML安全范畴的SAML安全声明书就提供这类的解
决方案[26].
建构Web Service之间的安全通讯
目前网站服务的推动大部分是采用XML为基础,且不同区域的网站伺服器
可能有各自的安全保护系统,资讯厂商为了让不同架构下的安全系统之间可以进
行沟通,依据XML标准制定了XML安全相关的规格书,来提供符合资讯保护
的交换标准,包含认证,授权与使用者相关资讯,并应用於异质性的线上交易系
统之间传输与沟通[8].
XML Security剔除去PKI架构的缺点
以往利用PKI软体与各家厂商进行互动是很困难的,现有很多家厂商提供
PKI架构的软体,如Java Security Packages, Microsoft CAPI, RSA BSAFE等
等,它们各自拥有自己的凭证与密钥管理的解决方法,这些软体套件之间可能是
相容也可能不相容,若要使用这些PKI厂商套件来建置出一个可互相沟通的安
全通讯环境,将要花费很多精力去学习与研究.现在,XML安全资讯技术也是
10
以PKI架构为基础发展出来,XML安全技术剔除PKI架构的繁复运算,减低PKI
架构上的数位签章与加解密的昂贵成本,也让厂商不必花太多时间去撰写安全资
讯处理程式,例如XKMS藉由XML来简化密钥的管理与存取的任务[19].
保护XML文件中特定的内容节点
XML的好处在於本身弹性标签的设计,若是使用传统的加密方式,将整份
文件加密起来传输,就失去XML原本的结构性与弹性.W3C组织所制定XML
安全相关规格书,都是用来保护特定XML标签而设计的.例如,利用XML
Encryption来保护特定的XML文件内容节点,可控制特定使用者有权来存取
XML文件中的特定内容.XML的结构性让一份XML文件内容中,可以存在有
多个或者多重式的数位签章,以便利此XML文件於多个网站之间进行认证[33].
提供Secure Socket Layer (SSL)安全机制的补足
现在Transport Layer Security (TLS)是网际网路上的安全通讯标准,TLS是
一种端点对端点的安全通讯协定,是依据Secure Socket Layer(SSL)所延伸发展
的,SSL是由Netscape公司所设计,后来IETF组织发展设计了TLS,是用於
端点对端点安全通讯上非常安全与可靠的协定,XML安全规范不是意图取代
SSL/TLS,它只是提供一个安全需求的机制而非替代SSL,因为在SSL机制下,有两点是SSL所不能做到的:(1)针对交换的资讯内容,进行部分的加密,(2)
可以与两个以上的合作夥伴进行安全通讯,但是利用XML加密技术,参与通讯
的使用者就可以控制机密资讯的显现与否,受保护与不受保护的资讯可以存在同
一份文件中来进行传输[28].
2.2 W3C与XML Security
目前是越来越多的企业将结构化资料都采用XML文件格式来制定,再利用
网路来传输这份XML文件,在加密XML文件,认证此加密过的XML文件,与
11
确认传送方的可靠性等方面,这些XML相关安全领域方面的发展规范,陆续地
有草案与规格书在W3C组织网站上公布,包含XML Encryption[36],XML
signature[29],XACL(XML Access Control Language)[12],SAML(Secure
Assertion Markup Language)[13]和XKMS(XML Key Management
Language)[1],参与制定规范标准的厂商也正在积极地推广与发展应用,促使
XML文件可以更安全地在网际网路上传输[21].
2.2.1 XML Encryption
XML文件格式是现在结构化资讯的主流,在XML文件内容中有时候会储存
机密资讯,这些资讯只允许给特定授权者才可以存取,目前现行保护XML文件
的方法是使用传统加密方式,将整份XML文件给加密封装起来,虽说可以保护
XML文件,但是无法弹性地保护的特定资讯区块只能够被特定的被授权者存
取,为了保留原本XML结构化与弹性等特点,并做到XML文件特定内容区块
的安全保护,W3C组织的XML Encryption Working Group组织单位已经提出
XML Encryption规范书,制定了XML加密标准语法与XML加密内容区块的处
理流程,XML 加密技术可以保护XML文件中的特定元素不被未授权者存取,不必再使用传统加密法将整份XML文件进行繁琐的加密处理[8].
XML Encryption的语法结构
依据W3C组织所公布的XML Encryption Syntax and Processing规范,在
此使用范例来说明XML加密语法与XML加密语法中的各个元素定义含义[18].
XML加密语法结构中主要的核心元素是元素,若是为XML文
件中某一特定元素节点加密,此EncryptedData元素可以取代被加密的该元素
节点;若是针对整份XML文件进行加密,EncryptedData元素就被当成为XML
文件的根节点.EncryptedData元素的其他子节点元素於接续介绍[18].
12
图 1 XML加密之核心元素EncryptedData
[资料来源:Imamura,2002]
图中的「 」符号代表此元素或者此属性是可选择性的,也就是可有可无.
:对XML文件的特定元素节点进行加密后的整体相关资讯;
属性ID是个可选择性的属性,提供给此份文件一个此元素标准的识别字串;属
性Type是可选择性的属性,用来说明被加密的资讯是属於何种型态的资讯.
:选择性的元素节点,描述使用何种加密演算法来产生密
文,假若无此元素节点,必须使用其他方式让接收方知道传送方是使用何种加密
方法来产生此密文.
:这是选择性的元素节点,包含要对密文解密所用的密钥相关资
讯,这些资讯表现在此节点的子节点部分来说明.
:传送者传输密钥相关资讯到接收方,接收方依据这些资讯将
知道使用何把密钥与演算法来解密.
:必要的元素节点,包含被加密资讯的或者
,包含如base64编码的加密密文,而
提供加密密文於外部的参照位置资讯.
:提供陈述EncryptedKey元素节点内容包含解密
CipherData所需要的密钥资讯[33].
13
XML Encryption的处理方式
1. 利用XML Encryption对整份文件进行加密
加密之后产生密文元素取代原本的XML文件的根节点元素,将全部资讯隐藏於密文中.
图 2 XML Encryption对整份文件进行加密
[资料来源:Imamura,2002]
2. 利用XML Encryption对单一元素节点进行加密
范例如下将整个CreditCard元素从起始标签到结束标签都加密起来,也将
该节点本身的识别ID给隐藏起来,窃听者无法知道他是使用了信用卡付款,而
CipherData 元素包含加密处理后CreditCard元素的值.
原始未加密的XML文件内容
John Smith
4019 2445 0277 5567
Example Bank
针对元素区块进行加密
John Smith
ddsdew1q13fdf33124
图 3 XML Encryption对单一元素节点进行加密
[资料来源:Imamura,2002]
原始未加密的XML文件内容
John Smith
4019 2445 0277 5567
Example Bank
将整份文件加密之后
A23B45C56
14
3. 利用XML Encryption对单一元素节点的内容进行加密
为了让接受方可以知道John使用credit card,但是不知道卡号,发行者与
信用卡期限,这里就是将CreditCard节点元素的内容加密起来.
图 4 XML Encryption对单一元素节点的内容进行加密之1
[资料来源:Imamura,2002]
图 5 XML Encryption对单一元素节点的内容进行加密之2
[资料来源:Imamura,2002]
4. 利用XML Encryption对非XML资讯进行加密
利用XML Encryption对JPEG档案进行加密,整个JPEG档案被加密成密
文,置放为CipherValue元素节点的内容,由EncryptedData元素节点的Type
属性来说明此为JPEG档案,此例依据IANA型态来制定JPEG格式,在IANA's
Web site提供了一般资料型态的订义参照[28].
加密之前
John Smith
4019 2445 0277 5567
Example Bank
04/02
John Smith
A23B45C56
Example Bank
15
Adsdawq313sds312ffdfd6755
图 6 利用XML Encryption对非XML资讯进行加密
[资料来源:Siddiqui,2002]
XML Encryption与密钥使用
在XML Encryption范畴中密钥的使用与交换方式:使用非对称加密法来进
行安全密钥(Secret Key)的交换,再使用对称式加密法与配合之前透过非对称式
加密法取得的安全密钥来对XML文件进行加密[28].
Step1. 使用非对称式加密法交换安全密钥
假设Imran与Ali要进行通讯,Imran建立包含有公钥的请求讯息,将他的
公钥置放於元素中,CarriedKeyName表示所传输密钥的名称,EncryptedKey节点下包含的与元素是依据XML
Digital Signature (ds:)的名称空间所设定.在Ali接收到Imran所传送的密钥资
讯时,CipherValue元素放置著Ali新产生的安全密钥,利用Imran的公钥对此
安全密钥进行加密产生密文,此回应给Imran讯息的EncryptedKey元素也包含
CarriedKeyName 这个属性,用来与前面Imran所传送的公钥做区别[28].
图 7 Imran将他的公钥传送给Ali的请求
[资料来源:Siddiqui,2002]
1asd25fsdf2dfdsfsdfds2f1sd23
16
xyza21212sdfdsfs7989fsdbc
图 8 Ali利用Imran公钥将Secret key加密传送给Imran回应讯息
[资料来源:Siddiqui,2002]
Step2. 使用对称式加密法与安全密钥对XML文件加密
利用之前双方交换所取得的安全密钥来进行资讯加密,假设Imran传送XML
讯息给Ali,Imran使用安全密钥对重要资讯加密并置放於CipherValue元素中,元素所包含的内容就是安全密钥的识别名称[28].
图 9 Imran使用安全密钥对重要资讯加密传输给Ali
[资料来源:Siddiqui,2002]
2.2.2 XML Signature
XML Signature由W3C组织及Internet Engineering Task Force (IETF)所
制定,定义了将数位签章的运算结果如何应用於XML档案上的标准,XML 数
book
123-958-74598
12
Visa
10-10-2005
Imran ali
A23B45C564587
17
位签章具有认证性,资料完整性与支援对於已签名的资料不可否认性[30].
XML数位签章不只是将整份XML文件进行数位签章,也有能力为XML文
件中的特定部份进行签章的动作,而不破坏整个XML文件的结构,且也可以突
显出该XML文件中何者为重要的元件及确保该重要部份的资料完整性.企业之
间的讯息交换大多也是以XML做为基础,因此更重视讯息的可信赖性,资料正
确性,不可否认性等等特点,因此更突显XML Signature的重要性[30].
XML Signature的组成元件
参照图10的XML数位签章结构,说明如下:
()
(
()
()
())+
()
()
(Object)*
每一个要被签章的资源都
有自己的元
素,以URI属性来判别
元素说明处
理程式,参照到原本未被
签章的资源
元素具有
参照资源经过处理的摘要
值(digest Value)
元素指示出用来
验证签章的key相关资讯,可能包括凭证,key名称,处理的演算法
图 10 XML Signature结构
[资料来源:Simon,2002]
SignedInfo:实际上被签章的资讯,SignedInfo的核心验证由两个必要过程组
成:对 SignedInfo 的签名验证和 SignedInfo内部每个 Reference 摘要的验
证.计算SignatureValue所使用的演算法也包括在已签章的资讯中.
CanonicalizationMethod:签章在进行讯息摘要作业之前,用来标准化
SignedInfo元素节点内容的演算法.标准化(Canonicalization)是一种方法,18
处理可能包含在同一资料元素内部的不同资料串列,例如解释空格显示为空格,而非以ASCII 码的方法表示.
SignatureMethod:用来转换标准化SignedInfo元素成为数位签章值
(SignatureValue)的演算法,也就是签章所用的演算法.
KeyInfo:用来验证签章的密钥(key)相关资讯,表示用於验证签名的密钥.
KeyInfo是可选性元素的有两个原因:(1)签名者可能不希望向所有文件处理对象
披露任何密钥信息,(2)该资讯在应用程式上下文中可能是已知的,且不需要明
确表示.由於KeyInfo元素在 SignedInfo元素之外,所以如果签名者希望将密
钥资讯与签名绑定,Reference元素可以容易地将 KeyInfo元素作为签名的一部
分标签并将其包括在内.
Reference:参照特定XML文件的资料物件,包括摘要演算法与产生讯息摘要
值(digest value)的方法.用来参照与验证签名,这些验证将重新产生摘要值并确
保它与该资料物件中的内容一样.URI 属性标识出要签名的资料物件所在.
Transforms:选择性的元素节点,描述资讯内容的处理步骤排序列表,在摘要
资源内容之前,对它处理的步骤,这是解密所需遵循的轨迹.如果不存在
Transforms元素,则直接编辑资源内容的摘要.
DigestMethod:产生摘要密文(DigestValue)的演算法.
DigestValue:依据DigestMethod演算法将该Reference元素进行摘要处理所
取得的摘要密文[29].
如何建构XML Signature与验证
1. 决定哪一部份的资源需要进行签章
藉由Uniform Resource Identifier (URI)来识别需要被签章的资源,URI值如下:
"http://www.abccompany.com/index.html" 参照到HTML网页资源
"/Article/UploadFiles/200510/20051013143544832.gif"参照到网路上影像图
"http://www.abccompany.com/xml/po.xml" 参照到网站上的XML文件
19
"http://www.abccompany.com/xml/po.xml#sender1"参照到网站上XML档案中
的特定元素sender1
2. 演算出每一个资源的讯息摘要 (digest)
讯息摘要值是将元素的URI所识别的资源,进行摘要处理,而非只
是将元素进行摘要处理,取得的讯息摘要置放入中.
图 11 XML Signature参照摘要集合结构
[资料来源:Simon,2002]
3. 集合之前处理好的元素集合具有讯息摘要的元
素,将其置入於元素中,元素指示出封
装元素所用的演算法, 因为在同样的XML资讯集合里的不同资料
流,有不同的文字表示法,为了避免不正确的认证,XML资讯集合必须先要标
准化封装(canonized ),再进行数位签章程序.元素指出产
生数位签章值所用的演算法.参照图12.
图 12 XML Signature的元素结构
[资料来源:Simon,2002]
j6lwx3rvEPO0vKtMup4NbeVu8nk=
UrXLDLBIta6skoV5/A8Q38GEw44=
j6lwx3rvEPO0vKtMup4NbeVu8nk=
UrXLDLBIta6skoV5/A8Q38GEw44=
20
4. 进行签章
计算出元素的讯息摘要值,对讯息摘要进行签章动作,将签章值置
放到元素,如MC0ELE=
5. 加入密钥的资讯
若密钥的资讯有需要加入,就新增元素节点,如下密钥资讯是包含传
送者X.509凭证,这个凭证具有签章验证的公开金钥(public key).
图 13 XML Signature的密钥相关资讯
[资料来源:Simon,2002]
6. 封装成一份签章 (Signature element)
将,与元素封装成根节点
之下,元素包含XML数位签章的整体资讯,如图14所示.
j6lwx3rvEPO0vKtMup4NbeVu8nk=
UrXLDLBIta6skoV5/A8Q38GEw44=
MC0E~LE=
CN=Ed Simon,O=XMLSec Inc.,ST=OTTAWA,C=CA
MIID5jCCA0+gA...lVN
图 14 XML Signature完整讯息范例
[资料来源:Simon,2002]
ssdwe232gk,jriori4232kfdmfdffs
MIID5jCCA0+gA...lVN
21
验证XML Signature
第一阶段为验证元素的签章,接受方依据
元素所描的讯息摘要演算法,将元素再计算出讯息摘要,使用公开
验证密钥将元素解密取得讯息摘要,若此讯息摘要与再计算的
讯息摘要一样,验证通过.若第一阶段通过,将的元
素相对应的资讯进行讯息摘要计算,此讯息摘要值与元素内容比
较,若是一样,则签章验证通过[30].
2.2.3 XML Key Management Specification (XKMS)
XKMS密钥管理规范书是由VeriSign, Microsoft, webMethods合力制定送
交给W3C组织审核与公布,XKMS也已经被全球知名企业所接受与推广使用,如IBM, HP, SUN, Baltimore, Entrust, RSA, IONA, PureEdge[38].此规范书提
供XML发展者可以将PKI架构(Public Key Infrastructure)应用到XML开发上,PKI让我们对文件可以进行数位签章以及验证这些签章,PKI是数位通讯上最让
人信任的架构[19].
然而PKI需要高复杂度与昂贵成本来处理这些简单的工作,开发者可能得
花费很多时间将PKI整合到他们的应用当中,如整合到电子信件或者ERP系统
中.XKMS解决了这个问题,让客户端的应用可以委托给伺服器服务代为处理,PKI的复杂度被XKMS的架构给隐藏起来,让加密信任服务可以容易地整合到
更多应用当中.XKMS将客户应用与PKI之间的界面给简化与标准化,标准化
的界面让PKI与其他应用间的互动更为具有弹性.XKMS架构里面信任功能(trust
functions)常驻在伺服器端,透过XML程式就可以进行存取[19].
22
XKMS Server
立式盒
PKI Infrastructure
Supporting
DB
PKI DB
Keys,identities,status
XML
Public key
User
Key Pair
Holder
1.Validate
2.Validate
response
3.Locate
4.Locate
responseRevocation request
Registration request
Registration response
Revocation response
图 15 XKMS架构图
[资料来源:VeriSign,2002,38]
XKMS Service Architecture
XML提供了企业系统间资料的可携性,XKMS提升这个轻便性,让传统复
杂的PKI执行更为简单容易.XKMS以广泛性,开放性以及标准性为基础,为
XML於密码学上的应用新增信任处理程序(trust processing),此架构设计用来补
足W3C所公布的XML Signature以及XML Encryption两个标准[37].
XKMS机制让XML应用程式可以很容易地结合PKI架构来支援XML文件
的加密与数位签章,主要目的是帮助使用者更易於使用公钥来执行加密或者对数
位签章进行验证.XKMS主要包括两个子部份:
l XML Key Information Service Specification (X-KISS)
支援可信赖的使用者取得相关於XML数位签章,XML加密或其他使用公钥
的XML应用程式所需的密钥资讯,依据给定的识别ID资讯找出公钥所在的
相关资讯.
l XML Key Registration Service Specification (X-KRSS)
提供成对密钥持有者注册或注销他的密钥资讯.
23
XML Key Information Service Specification (X-KISS)
XML密钥资讯服务(X-KISS)帮助开发者或可信赖方取得相关於XML数位签
章或XML加密资讯所用的密钥资讯.X-KISS定义了两个处理流程[37]:
Key Location-找出必要公钥所在并加以取得
Key Validation-描述公钥与识别资讯之间的绑定方式(Binding),绑定资讯包含
密钥名称,密钥的值,是否已经撤销,X509凭证等等.
以下是X-KISS范例[38]:
1. Alice要传送已签章的XML文件给Bob,Alice对此文件签章并置放於此XML
文件中,在XML文件中有一个公钥的元素节点描述密钥名称与其相关资讯.
2. Alice将此文件送给Bob.Bob接收到该份文件并且验证该文件中Alice的签
章,Bob由包含密钥资讯的节点取得资讯并产生一份XML格式的请求讯息.
3. Bob将此请求讯息传送给XKMS服务来进行密钥验证.
4. XKMS service回送给Bob一个回应讯息,针对Alice密钥验证的相关讯息.
5. Bob依据XKMS service回送的密钥资讯对文件中的数位签章进行验证.
Bob若对Alice的数位签章验证通过,代表此份文件未被修改.
XML Key Registration Service Specification (X-KRSS)
XML密钥的注册服务(X-KRSS)描述公钥与密钥相关资讯的注册协定.成对
密钥持有者藉由注册服务(Registration Service),将它的公钥与相关此密钥资讯
注册到具有注册服务的XKMS Server.
l 这个注册请求包括资讯[1]:
1. 密钥持有者姓名与相关资讯
2. 认证资讯:认证密钥持有者的资讯,一般由非公钥持有者所提供,即是由负
责XKMS机制的公正伺服器所提供.
3. 私钥的持有者证据(Proof-of-possession):当注册数位签章所用的成对密钥
时,使用者利用私钥对注册请求进行数位签章,当成持有者证据.
24
l XML密钥的注册服务支援以下的作业[38]:
1. 密钥注册(Key Registration)
在公正第三者XKMS伺服器上注册公钥.成对的公钥与私钥可以是由客户
端产生或者由XKMS伺服器产生,注册请求是用来声明此成对密钥绑定的
相关资讯(binding of information).
2. Key Revocation密钥撤销
依据客户端请求来撤销之前注册的密钥资讯,XKMS 服务允许客户端撤销
之前所发布的密钥持有声明书.
l 注册请求流程如下[38]:
1. 由客户端产生他所需要成对的公钥与私钥
客户端产生公钥与私钥之后,将公钥注册到XKMS伺服器上的密钥注册服
务,XKMS服务也许会要求客户端提供私钥的持有证明.
2. 由XKMS伺服器为Client端产生成对的密钥
客户端可以要求XKMS伺服器的XKMS服务产生成对的公钥与私钥,所产
生的公钥与私钥要回传给客户端.当要求注册由XKMS伺服器所产生的密
钥时,客户不必将公钥资讯回传给XKMS伺服器,只要利用私钥对注册请
求进行签章,回传该已签章的注册请求即可.
l 密钥撤销方式[38]:
Alice传送讯息要求XKMS 伺服器撤销之前注册的密钥资讯,Alice藉由使
用她的私钥对密钥撤销请求讯息进行签章,要求XKMS service撤销与她有
关的公钥的一切相关资讯.
2.2.4 Security Assertion Markup Language (SAML)
OASIS国际联合组织正在进行的另一个有关XML安全的专案是SAML安全
声明书定义语言,用在促进企业间互动的XML为基础的标准规格书.SAML允
许各企业於线上交换认证和授权资料,公司之间就能进行不同的安全技术协同运
25
作.SAML允许用户在不同的网站之间移动时携带授权和验证证件.SAML技术
能相容於多种传输协议,如HTTP和几种XML架构,如BizTalk.SAML不是
定义任何新的授权与认证技术,它只是用一般XML语言来描述这些认证与授权
系统所输出的资讯[13].
SAML主要应用
l 企业交易夥伴之间交换企业本身重要安全资讯与授权资讯.
l 企业间的垂直整合架构:单一登录,应用在异质性系统间的整合[13].
SAML规格书主要部分
包括三个不同部分:assertions, protocol, bindings,如下图16,详细范例
参照附录一:
Protocol
Request/Response pair for processing assertions
Assertions
Authentication and authorization
Bindings
How assertions are communicated over industry-
standard transport and message
图 16 SAML安全声明书讯息结构
[资料来源:Netegrity,2001,26]
l 声明书(Assertions)
SAML assertion是一段关於使用者的安全资讯,包含有认证与授权资讯.
它是由授权机构(SAML authority)产生且可以使用XML数位签章来加强它
的可证性.声明书类型样式[13]:
1. 认证声明书(Authentication assertion)
26
声明该使用者已经通过特定认证机构的成功认证,此声明书定义发行此证
明书的机构,发布时间,声明期限与其他认证相关属性.
2. 授权声明书(Attribute assertion)
声明使用者相关特定属性,这个声明书是由属性授权单位(attribute
authority)所发给,用来描述使用者的授权权利.
声明书的组成元素(Assertion)
不同的SAML安全声明书都是使用XML schema来规定,至少包含内容元素
如下[13]:
1. Basic information
包含有一份说明SAML安全声明书所用语法版本的声明书(assertion),一个
唯一的声明书名称,唯一发行者名称,声明书发布的时间与日期,声明书的
有效期限.
2.元素
代表SAML安全声明书的资讯核心节点.具有AssertionID属性,这是SAML
安全声明书的唯一识别ID,Version属性说明参照的是哪一个版本的SAML
规格书,Issuer属性是指安全声明书的发行单位,IssueInstant属性是依据
Universal Coordinated Time(UTC)时间来说明发行安全声明书的时间.
3.Claims元素
持有享有的权利:由发布声明书的单位说明.
4.Conditions元素
包含从认证服务取得的额外资讯,附属性(dependency)由其他的声明书来认
证,是否有其他可依赖的会员.
l SAML Protocol
SAML安全声明书的产生与交换都是透过SAML protocol,依据XML
schema来制定,是由一群请求与回应讯息成对的集合.SAML请求讯息可
以包含认证,授权等查询[13].
27
l SAML Bindings 资讯绑定
说明交换SAML请求与回应的讯息的方法,如标准讯息传输协定,可使用
的绑定方式如下[13]:
SAML HyperText Transport Protocol (HTTP) Binding:
描述SAML request/response讯息交换如何符合HTTP讯息交换.
SAML Simple Object Access Protocol (SOAP) Binding:
描述SAML request/response讯息交还如何符合SOAP讯息交换.
l SAML互动方式
范例(1)单一登录[27]
使用者登入到SiteA存取SiteA上被保护的资讯,依据User的登入时间资
讯,SiteA为使用者产生SAML安全声明书,若使用者点选SiteA上SiteB
的连结,就可以携带著SAML授权书一起到SiteB网站,不需要再登入
SiteB,只要SiteB对SAML验证无误,使用者就可以使用SiteB所提供的
服务[27].
End UserSite 1
Site 2
Security
Engine
Security
Engine
Trusted Relation
12
3
4
SAML
SAML
图 17 利用SAML进行单一登录
[资料来源:Netegrity,2000,27]
28
范例(2)服务导向的交易:电子交易网A与电子交易网B之间进行授权交易
BuyerSupplier
Security EngineSecurity Engine
ExchangeAExchangeB
SAMLSAML
1
2
3
45
SOAP,ebXML
HTTPS, SMTP, MSMQ, etc.
图 18 SAML服务导向的交易模式
[资料来源:Netegrity,2000,27]
(1) 购买者传送包含使用者姓名与密码等资讯的XML文件到电子交易网A.
(2) 电子交易网A依据这些证明资讯产生一份安全声明书(assertion),内容
说明一些使用者的授权资讯,如使用者信用说明.电子交易网A可能将不
必公开的使用者机密资讯给移除或隐藏起来.
(3) 电子交易网A将讯息传送给电子交易网B,这个传递的讯息可以利用
SOAP, ebXML标准来封装,藉由HTTPS,SMTP,FTP等协定传输.
(4) 电子交易网B依据储存在Security Engine中的决策来检查该讯息中的
安全授权资讯.
(5) 若这些授权资讯认证通过,电子交易网B将资讯传送给适当的供应商,此时代表购买者有权利可以向电子交易网B的该供应商进行购物的交易.
2.2.5 XML Access Control Markup Language (XACL)
OASIS组织所制定的XML存取控制规范书(XACL)是以XML标准来提供
复杂的存取控制机制,安全地控管使用者浏览XML文件与更新XML文件的权
限,藉由特定的安全策略(Policy)来控管存取XML文件权限.跟目前既定的决策
描述语言(Policy Languages)相似,XACL依据Object,Subject和Action三个
元件为导向,主要对象(Subject)指示被授权者的使用者识别ID,使用者所属群
组或者代表角色;参照物件(Object)指示策略所要保护的是XML文件中的哪一
29
个元素;允许处理的动作(Action)包含读取,写入,新增与删除等四个动作[20].
XACL语法说明
图 19 XACL机制的Policy内容范例
[资料来源:Hada,2001]
图19说明授权策略(Policy),Alice归属於Employee雇员角色,拥有对XML
文件中contractor元素的写入权限,一份可包括多个控制说明,一个可包含多个规则,且一个可包含多个特定角色的存
取控制规则,每一个被管理物件(object)用一个来描述他的存取原则[12].
假设现在使用者Alice送出存取请求讯息,请求讯息如下,内容注明使用者
身份与读取目标元素节点所在以及存取执行动作为"Read":
图 20 XACL机制的存取请求(Access Request)内容范例
[资料来源:Hada,2001]
XACL处理者将会依据使用者请求讯息与相关策略(Policy)进行评估,产生
存取控制决定(Decision),然后依据此决定将资讯呈现给Alice观看,如图21.
Alice
Alice
Employee
30
Alice
图 21 XACL授权决定范例
[资料来源:Hada,2001]
授权架构Authorization Architecture
参照图22 XACL存取控制机制运作范例:
Step 1. 使用者传送一个包含存取的目标节点,使用者ID,所要进行的处理动作
的存取要求到XACL处理者(Processor)里的存取评估器(Access Evaluation).
Step 2. 存取要求会在於存取评估器模组(Access Evaluation)中被分析,主要依
据是XACL规格所写成的策略及目标XML文件,存取评估器去读取控制策略
(access policies)与目标XML文件,进而产生存取决定(Access Decision)及其他
相关处理动作.
Step 3. 这个请求的被执行,是经由请求执行(request execution)模组来执行,包括请求行为(requested action)及在存取决定(access decision),此目标文件将
会依据所请求的动作进行写入,新增或删除等动作.
Step 4. 将执行结果呈现给使用者观看[20].
31
使用者
XACL Processor
Access
Evaluation
Request
Execution
Step1.Access Request
Step4.View document
Step2.
Access
Decision
Target XML
Document
AAA
BBB
CCC
Associated Policy...
AAA
BBB
ABC
Step3.
Update
图 22 XACL存取控制机制运作范例
[资料来源:Kudo,2001]
2.2.6 Simple Object Access Protocol(SOAP)与安全性
在2001年4月,W3C组织提出以SOAP简单物件存取协定作为网站服务
传输XML讯息的一种普遍性协定.SOAP是在分散式的环境中,交换资讯的简
单型通讯协定,以XML为基础的通讯协定,由Microsoft,IBM,DevelopMentor
与UserLand Software等公司共同发展出来的技术.SOAP技术与任何程式设计
模式无关,不论是使用微软的COM/DCOM物件或Java,只要利用SOAP技术,不同平台的程式设计模式都可以顺利沟通.SOAP可以与HTTP,SMTP,POP3
等协定共同应用,获取现有通讯技术最大程度的相容[5].
SOAP的组成
l SOAP envelope:定义了一个封装结构,描述SOAP讯息中的内容是什 ,是谁发送的,谁应当接受并处理它以及如何处理这些资讯.
l SOAP encoding rules:编码规则用於表示应用程式需要使用的资料类型规
则,并可用於交换由这些应用程式定义的资料类型所衍生的实例.
32
l SOAP RPC Representation:处理远端程序呼叫和回应的方法,例如使用
HTTP或SMTP协定与SOAP结合,如何传输程序呼叫 [46].
SOAP讯息架构
图 23 SOAP讯息结构
[资料来源:梁中平,2000]
图23所示,SOAP讯息包含一个Envelope元素,它有Header与Body子
元素[46].Body为SOAP讯息的主要元素,为Envelop元素的子元素.接下来
介绍SOAP请求讯息与SOAP回应讯息,本例子是先向书本报价服务送出一个
获取书本编号B001的SOAP请求讯息.此SOAP请求讯息包含内容:
l SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope"为SOAP
Envelope预设的名称空间
l Envelope元素为SOAP讯息的根元素
l HTTP标头名称为SOAPaction的目的告知伺服器端执行此SOAP请求的方
法,#字号之前的字串具有如防火墙般过滤SOAP请求讯息功能,#字号后
面指出真正需要执行的方法.
客户端向伺服器传输一个SOAP讯息,这个请求讯息如图24,依据Body
内的code元素属性查询书号B001的详细图书资料[47].
33
图 24 SOAP请求讯息范例
[资料来源:陈会安,2000]
然后伺服器端依据该SOAP请求讯息,取得该书本商品的资讯,封装成
SOAP回应讯息,如图25,藉由HTTP传输回客户端,下图内容是伺服器取得
HTTP请求,执行getBookDetail方法之后,若没有问题传回SOAP回应讯息,就是图书详细资料,该回应讯息中,200代表伺服器处理成功,500表示有错误
讯息,此时传回的Body就是包含错误讯息[47].
图 25 SOAP回应讯息
[资料来源:陈会安,2000]
34
SOAP安全性
SOAP讯息的加密,认证和授权等安全机制一直受到人们广泛关注,但在制
定SOAP规范时并没有太多的安全性要求,这是因为SOAP的设计目标在於它
的简单性,尽可能利用已有的标准和协定来实现相关的功能以提高相容性[36].
一般SOAP讯息可利用SSL(Secure Sockets Layer)安全通道来传输资讯,避免SOAP讯息内容被窃听,并保证客户端和伺服器端可互相验证身份.HTTPS
虽可防止对窃听者窃取讯息,但不满足特定网站对於客户端用户认证的需求,如
下几个场景,仅仅依靠SSL的安全机制是不满足资讯的安全要求的,所以需求
XML安全技术来帮助SOAP协定做到XML讯息的安全保护[43]:
l 端对端的资讯传送
SOAP讯息可以与不同的传输层协定(如HTTP,SMTP等)结合在一起进
行传输,传输的过程中可能经过一系列中间设备或应用程式,假如应用程式
对SOAP讯息进行恶意破坏,在SOAP讯息插入一段相似的header元素,再传给下一个中间设备或程式,就破坏了资讯的完整性.
l 中间界面的独立性(Middleware independence)
如果在传输中的传输讯息是明文,而不是是经过加密的密文,极易受到骇客
的攻击.但假如在应用程式中进行安全加密的处理,需要用户对加密演算法
有详细的了解,这对於用户来说是额外的负担.
l 驻留资讯的安全性
传输层可以进行安全传输,但不能保证资讯驻留时也是安全的.如消息保存
后继续向前传输,驻留资讯的安全十分重要.
以上这些SOAP安全上的问题考量,都可以藉由XML安全技术来保护与完
成,也可以保有原本SOAP讯息的简易性与实用性.
35
2.2.7 XML安全技术工具组
由於XML安全技术相关规范书的制定,也有众多知名资讯厂商参与,因此
有些资讯厂商就依据规范书的内容,加以研发XML安全技术的开发辅助工具组
(Toolkit),并分享给有需要的XML程式开发者使用,藉由XML安全技术工具组
的分享与取得,来推广XML安全技术的应用,这些开发工具资讯如下:
研发者 工具组名称 XML安全技术范围 备注
IBM IBM XML Security
Suite 20011029
XML Encryption
XML Signature
XML Access Control Language
与Java SDK
1.4诸多不相容
Phoas Phoas XML XML Encryption
XML Signature
有试用限期
Netegrity JSAML-toolkit-1.01 Secret Assertion Markup
Language
VeriSign Trust Services
Integration Kit 1.0
XML Encryption
XML Signature
XML Key Management
Specification
只支援
Triple-Des加
密演算法
Microsoft
(ASP.NET)
XKMS client and
server sample code
XML Key Management
Specification
VisualSaft VisualSoft
XMLSecure
XML Encryption COM 元件
表 1 XML安全工具组
[资料来源:W3C]
目前可以取得大多数的工具组都是Java为基础,只有VisualSaft公司所提
供的工具组是COM元件,但它只提供XML加解密技术.这些工具组都可以在
厂商相关网站下载试用,部份工具组有附加详细的程式码范例.
2.3 XML-based的标准与架构
2.3.1 XML为基础的标准
由於XML标准具有良好的结构与延申弹性,已被用来定义与发展具有功能
性架构与产业相关的标准,可分成三类说明[46]:
36
XML基础标准
定义XML语法规范,XML资讯呈现方式,资料定义模式等基本标准,让
XML开发者利用这些标准来发展XML相关软体,如:XSLT(Extensible
Stylesheet Language Transformations)负责XML文件资料的呈现方式,DTD
(Document Type Definition)说明XML文件的结构.多半是由W3C组织等国际
标准组织所制定.
特定的XML产业标准
依据不同产业的需求,建立以XML为基础的商业文件格式,并且制定企业
与企业之间电子化交易的作业程序标准,RosettaNet组织为资讯技术产业,半
导体产业所制定的XML为基础的商业文件规范,通常是产业组成的标准组织所
定义.
跨产业架构的XML标准
定义跨产业,跨平台可达到电子化企业作业环境的标准架构,包括讯息结
构,通讯协定与注册机制等标准,如微软BizTalk与HP公司E-speak服务平台.
2.3.2 BizTalk Framework
BizTalk是以XML为基础的开放式的电子商务讯息交换架构,由微软公司所
主导制定,目的是让企业之间不同平台各种应用软体可以进行沟通.当同一种产
业或企业需要同时采用两种以上类似的资料交换标准时,只要这些标准采用
BizTalk的讯息规范,就可藉由BizTalk架构所规定的转换机制,互相转换成所
需要的标准格式[23].
BizTalk架构的组成
l BizTalk Framework:规范BizTalk讯息结构与特定标签的功能与使用方法,元素是指示BizTalk文件是由何处传输过来,并将传输到往何处.
37
l BizTalk Schema Library:规范各产业之间常用的商业标签语法,如在营建
业的标准AecXML.
l BizTalk Server:各项讯息处理服务功能的伺服器,负责传输BizTalk文件.
BizTalk架构的逻辑运作方式分成三层:Application Layer,BizTalk Server
ayer,Transport Layer.首先由企业或组织产生一份商业文件,与贸易夥伴的应
用程式进行交换,Application Layer将商业文件(Business Document)封装成
BizTalk文件格式,并传输到BizTalk Server Layer;BizTalk Server Layer将该
BizTalk文件与额外资讯(BizTalk Message Header)结合建构成BizTalk讯息,再传输给Transport Layer透过HTTP或者SMTP等通讯协定,将BizTalk讯息
封装成可在网路上可传输的封包,传输给远方目的端的BizTalk伺服器;目的端
接收到贸易夥伴BizTalk伺服器的BizTalk讯息,验证其合法性,再传送到
Application Layer中做进一步的处理[46].运作图如下图26:
图 26 Biztalk运作图
[资料来源:BizTalk.org]
Biztalk讯息主要包含元素
:Biztalk文件最基本之元素,用来包含整个文件.
:与交易讯息传输有关的资讯,用来定义Biztalk文件之来源(From)
及去处(To),其子元素为及两元素,用以记录资料传送端与接收端
38
的Biztalk伺服器相关资讯.
:包含一个或多个商业文件(Business Document),其子元素为
,是用来存放欲传送之资讯,而之属性xmlns,是用来
指定xml名称空间,也就是该商业文件所选择BizTalk Schema Library[23].
Biztalk的安全面与优缺点
由Biztalk Server负责提供讯息传输的安全保护,根据微软产品Biztalk
Server产品的说明,它支援PKI架构,数位签章与一般加密技术,且利用伺服
器之间所持有的伺服器凭证可以建立起SSL安全通道来传输Biztalk讯息.目前
的Biztalk伺服器讯息安全保护技术,还没有将XML安全技术整合到产品应用
上,因此就无法弹性地为特定交易内容元素进行保护.BizTalk的竞争优势在於
它的易用性.不过,它的缺点是目前依据BizTalk架构的产品只有微软的BizTalk
伺服器产品,只能在Windows环境中运行,不能在Unix或其他作业系统上使用,以及该产品价格昂贵(参照附录三).另外,由於参与通讯的双方都得具有BizTalk
伺服器来处理交易讯息,所以,一般不具有该伺服器的客户端是无法参与BizTalk
的B2B通讯环境[3].
2.3.3 E-speak Service
E-speak是HP公司为网站环境所设计的开放式应用平台,平台由E-speak
服务规范(E-speak Service Framework Specification, e-speak SFS) 和
E-speak服务引擎(E-speak Service Engine)组成,服务规范提供建立电子化服
务的蓝图与基础,而服务引擎则用来实作与建置服务规范.两者共同帮助企业与
顾客,供应商建立线上信任关系,使得已有或还没有商务往来关系的企业之间能
够做到联系和交流,迅速找到提供者,并让双方就具体的要求进行协商,监督各
自电子化服务的运用[2].
E-speak服务规范内容主要在说明企业对企业间的电子服务(e-services)互
39
动方式,主要依据服务架构规范(Service Framework Specification, SFS)标准进
行交易沟通;企业网站可以利用e-speak服务引擎自动地去发现其他的e-speak
企业网站,并动态地与这些e-speak所提供的电子服务进行整合,为企业需求提
供复杂的服务,另外服务引擎也会管理与监控电子服务(e-service)的存取与交易
资讯[2].
SFS主要提供B2B的e-services互动方式,如依据使用者定义内容进行协
商,完成产品契约与交货,SFS比传统软体元件架构(Software component
framework)更有能力,因为SFS的架构具有呈述企业协商,动态关系建立与企
业间互动的能力,且SFS可以於任何硬体与作业环境下进行B2B互动,SFS的
主要组成有:
l Messaging Sepcification
处理电子服务之间的交易讯息,如交易内容.电子服务之间沟通的讯息都是
XML为基础,具有根节点,有两个子节点与,节点描述资讯的传输路径相关资讯,描述著应用程式之间
交易与处理的资讯.另外在服务规范中还有讯息路由传输相关资讯,如通讯
连线管道方式[2].
l Introspection, Security, Application Management specification
决定客户端与服务提供者之间的交易讯息内容与互动程序,如定义属性表单
(Property Sheet)与双方沟通处理程序(Conversation Process Definition).
l Dynamic negotiation, Service Composition and Deployment Specification
藉由仲介者(matchmaker)提供的其他相关企业电子服务的资讯,来进行电
子服务间的合作协商.
每一个e-speak的服务都提供两个界面文件:服务属性定义(Service
Property Definition)与服务对话处理定义(Service Conversation Process
Definition),前者提供一般服务相关资讯,说明服务能够提供的功能模组是什麼,如服务提供者是谁,服务注册识别资讯与服务对话内容资讯是什麼;后者服务对
40
话处理定义是交易处理规则,如只接受何种请求与回应何种处理结果.
e-speak允许在网路上的设备和服务以安全的方式互相连线和交换资讯,并
自动做出相对应的反应.但是,若只有端点对端点的服务互动,只需要仰赖SSL
安全通道,就可以作到讯息保护,但是,若是作到多个服务进行互动,特定资讯
的保护就显得特别重要,但是E-speak服务环境未加入XML安全技术,就无法
做到这样地保护方式,这是E-speak於安全面待加强的地方[2].
2.4 线上电子付款系统
网际网路的发展促使很多商业服务与资讯商品都於线上进行销售,且传统付
款方式的交易处理成本高於这类资讯商品的交易利润,因此众多的电子付款机制
出现,来提供低成本与高效率的线上电子付款系统,快速处理线上商品付款交
易.太过於复杂的付款机制就不符合网际网路上的小型交易成本,而电子钱币
(Electronic Cash)付款就是处理的线上小额交易的付款服务,它以数位方式来储
存货币的价值,即是将原本的现金改以电子的方式存在.电子钱币和实际的现金
一样,具有匿名性让使用者的身份无法追踪,保护使用者的隐私权,使用电子现
金不必像信用卡签帐般必须留下信用卡卡号或个人资料.而小额付款指的是付款
金额介於几块钱到数百块台币间之交易.
在此介绍四个电子付款系统(1)Compaq/Digital公司的小额付款系统
Millicent,(2)美国著名eCoin公司所提供的eCoin电子钱币系统,(3)美国
Carnegie Mellon University的资讯网路研究所(Information Networking Institute)
所开发的NetBill,(4)国内中华电信公司所提供小额付款系统HiNet AAA系统.
2.4.1 Millicent
Compaq/Digital公司於1995年发展出的小额付款系统Millicent,主要特点
在於经纪商(Broker)与凭据(Scrip)两者的设立.由经纪商负责扮演介於网路商店
41
及消费者之间会计中间人的角色,经纪商发行凭据Scrip,让消费者以凭据Scrip
来与网路商店进行交易,故经纪商所提供的服务就是对消费者或商店买卖凭据
Scrip的服务[10].凭据Scrip是一种数位现金,每一参与Millicent机制的网路商
店都有其专用凭据,所以网路商店能检查出凭据Scrip的真伪或是否重复使用.
凭据Scrip是由网路商店或经纪商以单向杂凑函数制作,同时经纪商制作经纪商
凭据Scrip,网路商店制作商店专用凭据Scrip[10].此Scrip所包含的资讯:
l 网路商店名称:限制与指定Scrip只能在该家网路商店使用
l 面额:此Scrip的价值.
l Scrip识别编号:商店用以查询验证该Scrip密钥与检验Scrip是否重复使用.
l 顾客编号:代表持有此Scrip的消费者身份.
l 有效期限:此Scrip使用的时间限期,可以减少检验重复使用.
l 额外资讯:供网路商店弹性运作的讯息.
仲介商Broker
消费者网路商店
S
te
p
1
S
te
p
2
S
te
p
6S
te
p
3
Step 4
Step 5
图 27 Millicent交易流程
[资料来源:Glassman,1995]
交易流程如图27,流程说明如下[10]:
Step 1 :消费者使用信用卡线上刷卡,电话订购或其他大额付款方式,向经纪
商购买经纪商所发行的凭据Scrip.
Step 2 :经纪商如果没有网路商店专用凭据,经纪商要先向网路商店购买网路
商店所发行的专用凭据,网路商店会回覆网路商店专用凭据及相关安全资讯.
42
Step 3 :消费者以经纪商所发行的凭据向经纪商兑换特定网路商店的凭据.
Step 4 :消费者传送Millicent 付款相关讯息给网路商店,包括特定网路商店的
专用凭据Scrip,购买要求及购买签章(消费者密钥的杂凑函数值).
Step 5 :网路商店回传商品及交易结果,包括特定网路商店专用凭据Scrip 余
额,购买商品及网路商店回应签章.
Step 6 :网路商店持交易之后的Scrip与仲介商清偿帐目.
Millicent机制的优点有使用快速的杂凑函数运算降低交易成本,确保交易额
低廉且安全,采取离线方式,减少交易时与经纪商的连线处理.Millicent机制的
缺点包含有凭据只能针对某家特定网路商店使用,可携性差,且凭据含有消费者
资料,交易的匿名性差,以及反覆交换凭据增加消费者使用上困扰[42].
2.4.2 eCoin
eCoin代表是由美国eCoin.net所发行的电子代币,是线上电子钱币付款服
务,模仿真实世界的造币方式,利用数位代币(digital token)字串来表示一定金
额,每一个eCoin包含内容有eCoin型态,本质标签(Internal flags),使用期限,识别编号.由使用期限与识别编号结合形成eCoin的唯一识别码[7].
整个eCoin主要参与角色有三者:使用者,网路商店与eCoin伺服器.使
用者安装eCoin Wallet Manager电子钱包软体於使用者电脑上,以进行电子钱
币eCoin的管理.网路商店跟eCoin伺服器请求为特定商品产生适当产品标签
(invoice tags),将产品标签嵌入到商品清单网页上,即可让消费者使用eCoin
对该商品进行消费购买.eCoin伺服器为经纪人或仲介商的角色,维护与管理消
费者与网路商店的会员帐号,接受消费者电子钱包所发出的付款请求处理与为网
路商店产生特定商品的商品标签.eCoin机制让网路商店与处理作业的负担减
低,因为网路商店不需要安装任何交易处理软体,所有交易处理都交给线上的
eCoin伺服器来负责发行eCoin电子钱与回收.eCoin的交易流程如下说明 [7]:
43
eCoin伺服器
eCoin伺服器eCoin伺服器
1
5
2
3
4
6
7
8
图 28 eCoin付款系统交易流程
[资料来源:eCoin.net]
Step 1:消费者利用电子钱包软体登录到eCoin伺服器的帐号下载eCoins,储
存到他的电子钱包中.
Step 2:网路商店向eCoin伺服器取得可嵌入式产品标签作为该商品标价识别.
Step 3:网路商店将这些invoice tag建置到它的商品清单网页上供消费者点选
购买.消费者的电子钱包软体会自动判读这些产品标签背后的付款含义.
Step 4:消费者点选购买商品,电子钱包将判读完后的商品标签资讯(invoice
data)与同等价位的eCoins传输到eCoin伺服器,也就是付款请求.
Step 5:eCoin伺服器对所接收到的商品标签资讯(invoice data)解码与验证,并
对eCoins也加以检验.eCoin伺服器将验证完后的eCoins 储存到网路商店的
帐户里,代表消费者利用eCoin向网路商店购买商品标签的内容.
Step 6:eCoin伺服器回应一个导引指令(redirect command)到消费者的浏览器
上,并附上一个所购买商品於该网路商店的URL所在.
Step 7:消费者的浏览器依据所取得的URL,到该位址下载资讯商品.
Step 8:消费者下载取得购买的资讯商品.
eCoin需要在客户端安装电子钱包,要求交易之前得先去eCoin伺服器下载
电子钱币到客户端电子钱包中储存,若电子钱包软体或者客户端电脑系统有问
题,就可能造成已下载的电子钱币的损毁.
44
2.4.3 NetBill
NetBill系统包含有三个主要角色:消费者,网路商店与NetBill交易伺服器.
整个交易的过程分成三个阶段:商店和消费者商议商品的价格,商店将商品传送
给消费者和消费者付款等三阶段.前面两个阶段,是由消费者和商店之间传输资
讯,NetBill交易伺服器没有介入,在第三个付款阶段交易伺服器才会和商家有
所互动[6].整个NetBill交易过程如图29:
Step1:商品议价阶段,消费者与商店进行商品的议价.消费者可以向商店对想
要购买的商品进行喊价,商店考虑之后,将可接受的价格告知消费者,若消费者
也同意,那两者就以此价格成交.
Step2:商品传送阶段1,消费者向网路商店要求商品.
Step3:商品传送阶段2,商店将该商品用密钥加密保护起来,传送给消费者.
Step4:付款阶段1,消费者利用自己的私钥签署一份电子付款订单(Electronic
Payment Order, EPO)表明愿意付款给商家.
Step5:付款阶段2,网路商店接到消费者的EPO,使用商店私钥对EPO,商
品解密密钥与必要参数进行数位签章,再传送给NetBill 交易伺服器请求核准此
交易.
Step6:付款阶段3,NetBill交易伺服器经过必要的验证后(如检查消费者帐户内
的存款是否足够),若都没有问题则核可此次交易,同时将结果传回给商店;若
不核可此次交易也必须将结果传回给商店NetBill.
Step7:商店将结果及商品解密密钥传送给消费者,让消费者可以对商品进行解
密而得到购买的东西,如此就完成了整个交易过程[6].
45
NetBill交易伺服器
消费者网路商店
Step1
Step2
Step3
Step4
Step5
Step6
Step7
图 29 NetBill交易流程
[资料来源:Cox,1995]
NetBill只有在消费者付了钱之后,他才能得到而且一定能得到他购买的商
品;消费者在进行消费时,使用假名(Pseudonyms)的方式进行购物,稍微确保
消费者的隐私权.但是NetBill的交易成本颇高,整个进行交易的步骤,比一般
小额付款系统的交易步骤要多.使用线上检验(On-line Checking)的方式来作为
交易时的验证,在交易量大的时候NetBill交易伺服器的负荷可能遇到瓶颈[42].
2.4.4 HiNet AAA
中华电信所提供的HiNet AAA小额电子付款收费机制是整合认证
(Authentication),授权(Authorization),和计费(Accounting)三方面的
电子付款平台,提供网路商店安全与便利的网路收费系统,并依据中华电信帐单
向HiNet客户收取服务费[40].HiNet AAA使用电子钱的作法,是将原本电子钱
帐号的密码,转换成只能使用一次的密码(电子代币),当然此时网路商店要先向
HiNet加值服务中心,查询一次有效密码(电子代币)的真伪,才能接受此次消费
交易.这样做到电子钱的密码不会泄露给网路商店,达到保护密码的目的,也让
消费者无法重复使用已用过的电子钱[40].
HiNet AAA付款系统的交易流程[40]:
Step1:消费者登录购物网站会员,使用网站的购物车购买商品.
Step2:消费者使用网站所提供HiNet小额付款服务,消费者选定付款额度,就
46
会透过SSL 加密传输的方式与AAA 伺服器取得连线.
Step3:消费者使用HiNet帐号与密码登录AAA伺服器,AAA伺服器依据消费
者帐号,密码与付款额度转换出一份一次有效的密码(电子代币).并将此电子代
币传输给该网路商店,消费者凭此电子代币向网路商店进行消费交易.
Step4:网路商店伺服器收取消费者的一次有效的密码(电子代币),转向AAA 伺
服器(可信赖的第三者)进行验证,验证一次有效的密码(电子代币)的真伪.
Step5:电子代币验证通过,网路商店传送购买商品给消费者.
Step6: HiNet AAA伺服器将此费用储存到消费者HiNet帐单,并传送消费通
知到消费者电子信箱中.
消费者网路商店
HiNet AAA
伺服器
Step 1
Step 2Step 3
Step 6
Step 5
Step 4
图 30 HiNet AAA交易流程
[资料来源:本研究]
HiNet AAA系统使用电子代币的方法,免除因公开加密法计算与数位签章等
处理所需要交易时间,增加交易的效率,且采用连线验证方式,免除离线处理之
复杂过程.缺点方面包括有因为采取连线验证,处理所有网路商店交易的计费资
料,须具有大型资料库的处理能力,系统运作成本较高,另外,只采用登入帐号
与密码方法做为存取权控制方式,无足够之安全防护等级,以及购物网站登录与
付款登录,每次付款一次就得登录HiNet AAA伺服器,非常地繁琐.
47
2.5 网站服务的安全性(Web Service Security)
为了让网路服务之间的互动与通讯可以做到认证性,资讯完整性,不可否认
性与机密性,就需要有开放式的安全服务模式来支援,网站安全模式必须是独立
式的协定,如此网站服务才能够将安全策略附加到网站服务定义上,让客户端可
以安全地存取服务,网站服务安全所注重的是保护通讯安全与对互动双方的身份
验证与授权.
网站服务的安全性考量在於开放性的安全服务模式的建立,目前以两种网站
服务安全机制的样版模式(Pattern)为基础,样版模式是由既存的网站应用程式所
演变出来的,用SOAP讯息触动既存於网站上的常驻应用程式(container),依据
此程式本身的安全模式来识别客户端的识别ID,这个过程对客户端来说是隐藏
看不到的,对伺服器来说是确保安全资讯的沟通模式之中间界面结构
(Middleware configuration),好处是常驻程式来对识别ID的辨识与有效期限的
检查.困难的是如何将中间界面与应用层级的逻辑(实际处理流程)做连结,如串
接安全讯息的查核与不可否认性[15].
另一种样版模式是将应用程式封装成为处理特定任务的模组,利用这些模组
执行复杂的交易处理,每一个元件处理完后的输出讯息为下一个处理元件的输入
资讯,例如使用SOAP讯息来触发处理事件,将描述安全的相关属性加入到讯
息的架构本身之中,如数位签章与SAML型态的安全授权书,SAML信任模式
让授权/认证机构可以为授权/认证事件签署安全声明;好处是讯息可以穿透多重
中间界面,授权与认证资讯以标准化方式来传输,缺点是最接近上一个处理流程
的元件得额外确保安全声明书或安全属性的正确性.以上两个模式相异之处是前
者使用识别编号ID的方式,后者是具体地指出安全相关资讯.
在网站服务的安全机制下,可设立公正的网站服务安全提供者(Web Service
Security Provider)[19]负责执行SAML认证或识别ID认证处理的任务,此网站
服务安全提供者依据授权策略来决定使用者是否有授权执行特定网站服务.
48
Yuichi等作者於2002年6月提出针对企业环境的网站服务安全系统[25],主要安全传输设计是利用SSL安全通道传输SOAP交易讯息,并利用XML数
位签章,XML加密与SAML安全声明书等来为SOAP讯息加强安全性,如在
SOAP讯息的header元素中加入来源服务的XML数位签章,以保证来源的可
靠性;为了防止多重网站服务处理过程程中,部分资讯只能被特定服务读取,利
用XML加密技术来为SOAP讯息中body元素下的特定资讯节点加密保护;另
外,为了双方网站服务可以自动地互相认证,先向授权单位(Authority)取得SAML
安全声明书,再将此份声明书封装到SOAP交易讯息中一起送到另一个交易服
务端进行处理.整个过程上,交易夥伴的密钥管理也是依据XKMS服务辅助[25].
Requestor
Company
Provider Company
SOAP Security
XML Signature
XML Encryption
SAML
Transport Security
SSL
Basic Authentication
Authentication
Authorization
Resource
XKMS Server
XKMS Service
图 31 SOAP讯息的传输安全架构
[资料来源:Nakamur,2002]
2.6 单一登录模式(Single Sign-On)
目前企业内不管对外的电子商务或对内的资讯系统,皆遇上网路资源整合的
困难,多系统多帐号已形成企业在管理上无谓的浪费,对於安全上的考量更是让
管理者伤透脑筋.针对这个问题可以运用单一登录的技术,对使用者帐号进行整
合,并具有身份确认的功能,加强网管的能力以减少企业资源的浪费.
由购物网站环境来看,消费者都得先成为它们的会员才能进行购物,让消费
49
者得记住很多个帐号与密码 单一登录让使用者在网路环境里的任何地方都使
用同一个使用者帐号和密码,就可以登录网路,资讯系统,资料库或是其他网路
应用.目前著名的单一登录服务是微软公司的Passport服务机制,另一个是美
国Sun Microsystems公司的Sun One Platform for Network Identity [33].
2.6.1 Microsoft Passport
微软公司所提供的单一登录机制,主要服务为「单一登入服务」允许用户使
用单一帐号和密码登入Passport 的合作网站;「电子钱包服务」让用户储存信
用卡及送货地址以进行线上购物服务.只需一组用户帐号和密码,登入任何一个
Passport 合作站台之后,再点选其他的合作站台即可登入[44].
微软Passport
服务
Passport
user
Browser
微软Passport服务
Passport
Login
Server
Passport
User
Database
3
4
Web
Server
Passport
Manager
Web
Page6
5
2
1
图 32 Passport的认证流程示意图
[资料来源:孙三才,2000]
Passport的认证流程如图32:
1. 消费者先向合作网站要求服务.
2. 合作网站导引使用者到微软Passport网站进行认证.
3. 消费者依据合作网站的指引到微软Passport网站进行认证.
4. 然后消费者取得微软Passport网站的认证与授权.
5. 消费者持有授权证明向合作网站要求服务.
6. 合作网站Passport Manager判读授权内容,检验通过就提供网站服务
网页给消费者进行服务执行.
50
2.6.2 Sun One Platform for Network Identity
美国Sun Microsystems於2002年公布了网路认证解决方案"Sun Open
Net Environment(Sun ONE)Platform for Network Identity",包含网路认证基
础的软硬体与服务的规范标准.主要目标有三个方面:(1)个人消费者和企业用
户能够安全保管个人资讯,推展可相互运用并跨越多个网路的服务.(2)制订实
现单一登录的开放标准.使用者在任何网站通过认证后,不必接受其他网站认证
就可以使用其服务.(3)制订所有接触网际网路的设备都可以使用的网路认证开
放标准[32].
网路识别(Network Identity)的运作如图33所示,当使用者要进行身份认
证,应用程式或服务会依据相关规则或策略来审核使用者的识别帐号,给予适当
的授权;授权处理(authorization process)依据识别编号(Identity Provisioning)
给予使用者存取应用程式的权限,认证与授权两个程序是Network Identity的核
心部分,使用者界面是藉由请求应用程式(requested applications)或者入口服务
(portal service)来处理,Portal架构提供两个功能:Portal提供一致性的传输服
务给企业使用,以及允许使用者依据企业间的信任关系与合作企业进行互动;与
提供单一的帐号管理程序,另外,Portal提供一般存取管道,如VPN,安全与
信任存取的网际网路环境.利用识别编号(identification),授权与认证与单一登
录,使用者可以取得有限期的授权来存取合作资讯,且帐号管理者(identity
administrators)容易进行管理,网站服务减低管理识别编号的处理的负担[32].
51
图 33 Network Idnetity的作业流程示意图
[资料来源:Sun Microsystems,2002]
每家大厂目前所推动的单一登入方案都各不相容,例如现行的Passport是
由微软统筹搜集,加密,认证使用者的资料;而自由联盟则采联邦制,亦即企业
或协力厂商可自行掌控使用者资讯.目前两种系统的资料互不交流[4].
52
第三章 网站服务的安全架构:XMLSeF
3.1设计理念与架构目标
电子商务环境中有越来越多的情境,需要企业与企业之间的应用程式共同协
力来完成工作,资料流能够如同像在单一应用程式内一般畅通使用,有不少产业
正进行著一些改革性的创新,且电子商务的应用发展常常需要标准化的参考,例
如在企业间整合传输讯息的BizTalk架构,让企业有效整合商业活动与应用程式.
目前网站发展以网站服务为导向,以及网站服务安全机制甚少有较为完整的
参考架构与设计,在此提出一个应用XML安全技术的电子商务交易架构,以作
为网站服务安全机制的参考架构,以支援安全网站服务界面的开发,并探讨XML
安全技术如何帮助企业之间安全地传输XML文件资讯,证明XML确是电子商
务上资讯流方面的良好解决方案.本架构主要设计理念是利用使用者持有网站服
务安全提供者(Web Service Security Provider, WSSP)所提供的认证与授权资
讯,去与各个联盟服务提供者进行交易互动.本架构所依据的正式与非正式规格
标准:Extensible Markup Language 1.0,Simple Object Access Protocol
Version 1.1,XML Encryption Syntax and Processing,XML Key Management
Specification 2.0,XML-Signature Syntax and Processing,XML Assertion
Markup Language,XML Access Control Markup Language.
3.2 系统架构与组成元件
应用XML安全技术所设计出的核心架构如图34所示,我们称此架构为
XMLSeF(XML Security Framework),这是一个以联盟网站环境为基础的架构模
型,主要角色有使用者,网站服务安全提供者(Web Service Security Provider),网站服务提供者(Web Service Provider).网站服务安全提供者的责任是当使用
53
者通过身份认证之后,给予他一份XML格式的授权证明书,让使用者持有证明
书去与接下来的网站服务进行交易互动;网站服务提供者会检验使用者持有的授
权证明,并提供它的网站服务给该使用者,使用者不必於每个网站之间都要进行
登录,就可以使用各家合作服务提供者的服务项目,使用者与该网站的交易内容
就记载於使用者所带来XML格式安全授权书内的特定标签位置.
Service Request
Service
Provider D
Web Service Security Provider
Web Service Handler
XML Security Service
授权与认
证资讯
Service Provider A
XML Security Check
Web Service Engine
Service Provider E
XML Security Check
Web Service Engine
Service回应
Service
Provider C
Service
Provider B
授权与认
证资讯
(1)
(1)
授权与认
证资讯
(2)
(2)
URL Link
A B C D
URL Link list
B C D E
URL Link list
A B C D E
图 34 应用XML安全技术的架构XMLSeF
[资料来源:本研究]
本架构的设计目标:
1. 提供Web Service安全的通讯模型,以建置一个安全的网站服务互动架
构环境,让网站服务之间可以无障碍又安全地进行沟通.
2. 提高跨企业的XM为基础的讯息之互通性,降低企业进入电子商务之障
碍和资讯交换系统之间的建置成本
54
3. 为电子商务环境提供一致性的架构基础,此架构是与商业交易内容无关
的,商业交易内容可由依企业需求而设立.
4. 详细地说明XML安全技术之间的整合互动,以呈现出XML安全技术的
功能性,让XML安全技术更容易为大众所了解与应用.
3.2.1 网站服务安全提供者(Web Service Security Provider,WSSP)
这是整个网站联盟中可信任的公正者,主要任务是使用者身份认证,这是整
个交易过程中,唯一一次使用者登录动作,以及负责为特定使用者产生包含认证
与授权资讯的证明书,让使用者可以持有此份证明书,要求接下来接触的网站服
务提供者提供交易服务.在网站服务安全提供者主要运作服务有两大部份:
网站服务处理者(Web Service Handler)
负责提供该网站的各式服务给予适当的使用者,在本架构中,Web Service
Handler基本功能是使用者身份认证与授权,XML安全服务(XML Security
Service)会依据此服务认证的结果,如安全授权书的基本产生用意,发行者是谁
以及产生时间等等基本资讯,为这位使用者产生XML安全授权书,让接收到此
安全授权书的网站对使用者的交易用意有所了解;其他所提供的网站服务,就依
据本网站服务安全提供者本身的规划设计,例如电子钱包管理服务让使用者提领
电子钱币,或者资讯查询服务等等.
XML安全服务(XML Security Service)
XML安全服务包含XML加密,XML数位签章,SAML安全授权书产生,XKMS密钥管理与XACL策略控管等等功能模组.
l 使用XML加密对证书检查码进行加密,做为证书回收后的验证之用.
l 为该使用者需求产生一份符合SAML规范的认证与授权声明,加入到网站
55
服务安全提供者供给使用者的安全授权书中.
l WSSP会使用XML数位签章为这份安全授权书进行签章,以提升该安全授
权书的可信任性与不可否认性.
l 依据XKMS规范为本提供者产生公钥与私钥,并将公钥注册到另一个公正
可信者XKMS伺服器的XKMS Web Service上,以供其他合作联盟网站透
过XKMS Web Service查询到网站服务安全提供者的公钥资讯,以进行对
该提供者数位签章的认证.
l XACL处理者依据提供者所制定存取控制策略,来控管哪些联盟网站有权利
可以将交易资讯写入到安全授权书中,以确保有效写入的动作.
3.2.2 网站服务提供者(Web Service Provider)
网站联盟的成员之一,负责接收与验证安全授权书,并提供授权书所指示的
网站服务给该使用者使用,且批次处理回送安全授权书给网站服务安全提供者.
XML安全检验(XML Security Check)
常驻的网站服务,负责对接收到的证明书进行验证,负责将使用者於本网站
所进行交易记录写入到证书中与对交易内容进行保密处理.主要任务如下:
l 安全交易授权证明书检验
由接收到证明书讯息事件来触动执行,主要是负责检验一切证书中安全相关
的资讯,利用网站服务安全提供者的公钥来检验证书中的数位签章,与上游
来源位址元素的数位签章;若这两者都正确无误,再利用SAML检
验模组功能检验SAML安全声明书内容是否合法正确,若SAML内容也正
确无误,就代表此份证书是可信,将导引使用者到该网站所提供的网站服务
进行交易.
56
l 交易记录的保密处理
当使用者交易完成,网站的结算服务会传送交易记录资讯,触动安全服务的
加密与签章功能模组,本功能模组会向原本服务安全提供者(WSSP)取得允
许写入授权码,为该交易记录做证明.若有需要可以利用服务提供者(SP)
的密钥对交易记录内容进行签章与加密保护,交易记录只能被网站服务安全
提供者与本网站解密存取原文内容.
网路服务引擎(Web Service Engine)
包含数个主要功能模组如下说明,提供给使用者进行交易的网站服务与将含
有完成交易资讯的安全授权书进行回收处理.
l 网站基本交易服务
该网站所提供给使用者使用的网站服务,例如购物服务,拍卖服务,下单服
务,下载服务,查询服务等等交易服务.
l 安全授权书的回收服务
在证明书中会记载著此次交易的所有资讯与证书的传输与交易路径,并且每
经过一个网站,就使用该网站的数位签章来保证这是由本网站所传输,本架
构使用与两个元素节点来记录,本回收服务会根据证书使用时
间限制与这两个元素节点,来判读是否本网站为本证书交易传输的最后一
站,若是最后一站,本网站使用批次处理这些证书回送到网站服务安全提供
者,让它可以进行清偿与记录本证明书的交易过程.
3.2.3 安全授权书讯息的架构
整个安全授权书结构是依据XML安全规范书标准所设计而成,由交易目的
资讯,安全认证与授权资讯,交易记录资讯与传输过程记录资讯所组成的一个
XML安全交易记录档,整体交易资讯置入到XML资料格式的核心元素
57
之下.请参照图35.
l 交易目的资讯
说明这次交易的用意或目的,所有的内容描述是利用XML资料格式来表
现,并且放置於元素节点的基本资讯元素节点之
下,依据交易状况,自行自定基本交易资讯内容.
l 安全认证与授权资讯
使用网站服务安全提供者的密钥加密保护元素的子元素
检查码,只有本安全提供者可以解密这个检查码;另外当使用
身份认证确认,由网站服务安全提供者产生一份SAML安全声明书置放於
元素的子节点,描述本证书是由谁发
行,为谁发行,使用时间期限,使用者享有的权力等等资讯;网站服务安全
提供者会对交易目的资讯与安全认证与授权资讯,即是元素
进行数位签章保护,置放元素中.的ID属性
是网站服务安全提供者给予的安全授权书之识别编号,检查码
是由网站服务安全提供者为安全授权书乱数产生的识别字串.
l 交易记录资讯
每产生一笔交易记录就使用元素来表示,这个节点是
用来封装交易记录元素与该交易网站为本次交易记录所签
署的数位签章元素.元素的AuthID属
性是由参与交易的网站服务提供者向网站服务安全提供者索取的交易写入
授权码,做为交易授权许可的凭证.
l 传输过程记录
每次证明书由一个网站传输到下一个网站,就分别新增一笔包含元
素与元素的记录到元素节点之下,并且来源网站都
得对元素进行签章,保证这是由本网站所传输.
58
图 35 安全授权书所包含的内容参考架构范本
[资料来源:本研究]
3.2.4 联盟交易网中各个网站的密钥管理模式
图 36 XKMS密钥管理架构
[资料来源:John,2001]
()
()
59
藉由公正的XKMS伺服器所提供的XKMS 网站服务来简化联盟网站各台主
机的公钥管理工作,包括有注册密钥,撤销密钥,查询与验证密钥,以支援XML
文件的加解密与数位签章验证处理工作.XKMS於XMLSeF中的应用如图36.
所有联盟网站的各个主机网站伺服器,得先利用应用程式产生一对符合XKMS
规格书规范的公钥与私钥.(密钥内容范例参照附录一)
各网站将它本身的公钥向XKMS伺服器的XKMS Web Service注册,如此
就可以提供给需要的合作夥伴取得对应的公钥,合作网站透过应用程式向XKMS
Server提出特定合作夥伴的公钥相关资讯的供给请求,以进行相互之间的数位
签章验证.XKMS Web Service还有提供撤销密钥,查询与验证密钥等服务.
3.2.5 网站与网站之间的通讯方式
本架构为了让网站服务安全提供者(WSSP)提供给使用者的证明书,可以与
使用者一起绑定传输於各个网站之间,利用SOAP可以在HTTP连线呼叫物件
的方式,将使用者持有的XML资料格式证明书给封装成SOAP讯息,藉由SSL
安全通道来传送此封装讯息到下一个服务提供者网站.由於SOAP解决了多种
平台在存取资料上不相容的问题与SSL安全通道让SOAP讯息可以安全地在网
站之间传输,让整个架构在传输通讯上具有相容性与安全性.以网站服务安全提
供者(WSSP)与服务提供者(SP)之间的沟通为例来详细说明:
1. WSSPSP
WSSP将安全授权书识别ID封装成SOAP讯息,藉由SSL 安全通道传输
到SP,通知SP有一份安全授权书要传送过来.
2. SPWSSP
SP藉由SSL 安全通道,将此份安全授权书的识别ID传送回给WSSP要
求它传送该份安全授权书.
3. WSSPSP
60
WSSP就将安全授权书封装成SOAP讯息,藉由SSL 安全通道传输到SP,并将使用者导引到该SP网站上.
3.3 XMLSeF架构的交易流程
3.3.1 安全授权书的产生,验证与交易资讯记录
收到产生的安全授权书请求
产生安全授权书的基本交易资
讯与检查码
XML Encryption功能模组
用K
PB_SEC
对检查码加密
SAML产生器模组为使用者
产生SAML安全声明书
使用KPB_PRV对安全授权书
进行签章
安全授权书
图 37 网站服务安全提供者的安全授权书产生流程
[资料来源:本研究]
使用者登录到网站服务安全提供者,要求为特定交易服务产生所需的安全授
权书,主要应用是XML安全技术:XML Encryption,XML Signature,SAML.
而数位签章验验证所用的密钥都是交由公正第三者依据XKMS规范建立XKMS
伺服器来代为管理.图37说明网站服务安全提供者为使用者产生安全授权书的
流程,流程中的XML安全功能模组是归属於网站服务安全提供者的XML安全
服务.
当服务提供者接收到使用者所持有的安全授权书,服务提供者对使用者所持
有的安全授权书验证流程如下图38,这些验证功能模组是归属於服务提供者的
XML安全检验服务.图中来源网站是指安全授权书的传输来源.
61
接到使用者持有的安全授权书
对安全授权书中来源网站的位置作验证
对WSSP的数位签章作验证
回覆错误讯息
对SAML安全声明书作查核
对安全授权书其他交易资讯作检查
使用者进入服务提供者网站执行服务
图 38 服务提供者(SP)验证安全授权书流程
[资料来源:本研究]
服务提供者
网站服务安全提供者
接收到交易结算资讯
XACL请求写入授权模组
XACL处理功能模组
验证服务提供者资格
XACL请求授权讯息
资格通过,传回交易授权码
资格不通过,传回空白交易授权码
将授权码与交易资讯
Binding在一起
对此交易资讯进行服务
提供者的数位签章
1
2
3
4
5
6
图 39 交易资讯写入安全授权书流程
[资料来源:本研究]
在使用者持有安全授权书到服务提供者网站完成交易之后,服务提供者(SP)
得将交易资讯写入安全授权书,这个处理流程如图39,主要是依据服务提供者
的XML安全检验服务与WSSP的XML安全服务互动所进行.目的是为防止非
授权者任意资讯.
3.3.2 交易讯息的传输流程
网站服务安全提供者与网站服务提供者沟通模式:
62
Step1. 使用者向WSSP送出登录身份的请求,WSSP的网站服务处理者验证
成功后,WSSP会呈现交易服务列表给使用者,使用者选取交易服务并且产生
基本交易资讯,封装成XML格式的安全授权书初稿.
Step2. WSSP使用XML安全服务为该证书进行加密与签章保护,先使用XML
加密对证书检查码进行加密,并且为该使用者交易需求产生一份符合SAML规
范的认证与授权声明,加入到使用者的安全授权书中,最后WSSP会使用XML
数位签章为这份安全授权书进行签章.
Step3. 使用者点选WSSP网站上所提供的服务提供者(SP)的超连结,然后传送
证明书的识别ID通知该SP的XML安全检验服务,告知有份证书正要传输过
来,XML安全检验服务回送包含证明书ID编号的请求通知WSSP传输证明书,并将使用者导引到该SP的网站上.
Step4. SP网站上的XML安全检验服务会先检验证书中的WSSP的数位签章与
传输此证明书的网站签章,若两者签章正确无误,SAML验证模式针对SAML
安全声明进行验证,SAML验证通过,就将SP的网站服务提供给使用者.
Step5. 使用者与服务提供者交易完成后,要将交易资讯写入到证明书之前,要
先透过XML安全检验服务向WSSP的XML安全服务的XACL处理模组请求以
取得写入授权码,将授权码与交易记录绑定结合在一起,XML安全检验服务使
用XML加密与XML数位签章进行加密保护.
Step6. 使用者再点选SP网站上其他合作网站的超连结,再将使用者与他持有
的安全证书再导引到新交易SP网站,继续进行交易.
63
图 40 网站服务安全提供者与网站服务提供者沟通模式
[资料来源:本研究]
网站服务安全提供者与网站服务安全提供者沟通模式:
这个模式是原本架构模型的延伸发展,假设现在有众多个网站联盟采用
XMLSeF架构来整合网站之间的资源,只要在各个联盟网站的网站服务安全提
供者上新增转换服务引擎(Transfer Web Service Engine),它负责分析与验证跨
联盟网站的安全授权书,并依据该安全授权书的规范来为使用者产生新的安全授
权书,使用者持著新的安全授权书於该网站联盟进行交易.
交易剧本:假设使用者想与另一个网站服务安全提供者2所负责控管的某一
网站服务提供者进行交易,但是使用者只是网站服务安全提供者1的会员,所
以,使用者从网站服务安全提供者1提出交易授权证明书,持有本证书到网站服
务安全提供者2请求要与服务提供者A进行交易,网站服务安全提供者2检验
证书内容无误,将原本使用者持有的证书转换产生可适用於本联盟交易网的证
书,让使用者持有该证书与网站服务提供者2管辖的服务提供者A进行交易.
64
Service Request
Service
Provider D
Web Service Security Provider 1
Web Service Handler
XML Security Service
授权与认
证资讯 1
Web Service Security Provider2
XML Security Check
Transfer Web Service Engine
Service Provider A
XML Security Check
Web Service Engine
Service回应
Service
Provider C
Service
Provider B
授权与认
证资讯 1
(1)
(1)
授权与认
证资讯 2
(2)
(2)
授权与认
证资讯 2
Local
Alliance
Web Service
Security
Provider 3
Web Service
Security
Provider N
URL
Link
B C D
图 41 WSSP与WSSP沟通模式
[资料来源:本研究]
3.3.3 交易讯息的回收流程
本架构是采取充份信任模式为基础,意指整个交易联盟网站之间,是彼此互
相充份信任,所以,XMLSeF架构的设计目的在於保证交易可以安全的完成.
由於信任关系的建立,因此,由网站服务安全提供者所发行的安全授权书,就可
以信任各个服务提供者,要求这些服务提供者得负责执行安全授权书回收到网站
服务安全提供者的工作.
当使用者不再继续与目前所在服务提供者网站或其他网站进行交易时,回收
安全授权书的方法有两种,第一种是使用者自行将完成交易的安全授权书带回给
65
网站服务安全提供者;第二种各网站服务提供者批次方式或定时地检验交易记
录,是否存在有未回送给网站服务安全提供者的交易安全授权书.
当使用者不再继续进行交易,使用者可以点选回到网站服务安全提供者的连
结,将安全授权书给回送到WSSP,回送程序是使用者点选SP所提供WSSP
的URL超连结,触动SP的网站服务引擎将安全授权书藉由SSL安全通道传送
回WSSP,当SP传送回WSSP完成,元素的最后一个
元素得记载著传输回到WSSP的讯息.
但是,一般使用者在结束交易之后,都是将浏览器直接关闭结束交易,类似
这样情形之下的安全授权书回收方式,就是由各网站服务提供者定时地检验在本
网站中有哪些安全授权书是未回收给WSSP,此处理主要依据每一份安全授权
书的元素所记载,若此节点的每一个成对的子
节点,它们之中最后一个节点的文字节点内容(Text Content)是为空白,代
表当初交易完成时本站是最后一站,使用者没有继续与其他网站进行交易,那麼
本站就要负责将这份安全授权书回送给WSSP.
图 42 安全授权书交易传输路径
[资料来源:本研究]
由於在交易的过程当中,使用者持有的安全授权书都会保留一份记录於各个
服务提供者网站之中,以备争议查验与回收安全授权书之用,虽说每份安全授权
书都具有使用时间限制,与SAML安全声明书中有指示使用者主机名称与IP位
址,但是,为了防止有意破坏的恶劣服务提供者,在某份安全授权书的使用期限
之内,再度假造原本使用者资格,如假造跟安全授权书中SAML指明的使用者
主机名称与IP位址,来使用该安全授权书进行交易,这样的情境在XMLSeF架
SP_1SP_2
SP_2 SP_3
SP_2
66
构中是使用事后调查的方式来警惕服务提供者不要以身设险.
XMLSeF的调查方式是当网站服务安全提供者接受到两份同样编号的安全
授权书时,代表出现有恶意的网站重复使用,出现依据安全授权书中的
元素所记载的交易路径资讯来回溯追踪,如下图43,从两份
有争议的安全授权书的元素的最后一个子节点往回追踪,发
现最后在「从服务提供者E到服务提供者A的路径,两份文件是一样的,之后
从服务提供者A开始的路径是不一样的」代表服务提供者A有恶意伪造使用者
身份,重复使用安全授权书进行交易,验证根据是每个交易路径的节点
内容都是经过服务提供者的私钥进行数位签章,此私钥只有服务提供者自己持
有,所以可以证明此次交易的争议或者错误之处在该地点.
恶意的服务
提供者A
完成交易的
安全证明书
(正常交易)
完成交易的
安全证明书
(重复使用)
网路服务
安全提供者
WSSP
服务
提供者D
EA
AD
D WSSP
争议发生
EA
AB
B C
C WSSP
服务
提供者B
服务
提供者C
服务
提供者E
图 43 安全证明书交易流程回溯追踪
[资料来源:本研究]
67
3.4 评估与比较
3.4.1安全评估准则
使用网路安全上最常使用的五个基本的安全评估准则,来衡量XMLSeF以
确保其可行性:
l 机密性
联盟网站之间藉由SSL安全通道传输XML资料格式的安全授权书;各个网
站利用XML安全服务,使用XML加密技术将机密的资讯加以加密保护.
可预防非授权者存取传输过程中的资讯.
l 授权性
藉由SAML安全声明书可以授权给予使用者进行执行特定交易程序的权力
许可,且由於SAML安全声明书格式是通过国际组织加以标准化的XML文
件格式,让网站服务之间更容易存取与分析.
l 资料完整性
使用XML数位签章技术为安全授权书内容进行签章,来确保资料的完整
性,让安全授权书在传送的过程中,不会遭到偶然或故意破坏.
l 不可否认性
安全授权书有网站服务安全提供者的数位签章与每次的交易记录也有交易
网站的数位签章,以及讯息传递路径记录也使用XML数位签章来映证,若
有争议时,有数位签章做为验证标识,提供了不可否认性.
3.4.2 相关架构与议题的评估
在单一登录方面来考量,目前提供单一登录的联盟团体有Sun等多家企业
的自由联盟计画与微软公司的Passport服务,两个阵营是对立的,若是全球各
68
区域的网站都如此的作法,形成各自对立联盟阵营,使用者最后还是得记住多个
特定联盟阵营的会员帐号与密码,此结果只是局部的做到单一登录而已,而不是
真正的让使用者只要记住单一会员帐号与密码进行单一次登录动作.XMLSeF
架构强调的是除了联盟自己本身的沟通之外,还可以依据联盟与联盟之间的结
盟,让使用者真的只需要单一帐号与密码,就可以在各联盟之间进行交易.
XMLSeF架构设计主旨在於利用XML安全技术为网站服务之间的互动建立
安全机制架构,与其他XML为基础的架构是有很多不同的地方,如表2:
XMLSeF BizTalk E-speak
应用范围 支援网站服务安全
的电子商务交易架
构
电子商务产业整合 应用在Web结构下
的电子化服务平台
商务产业整合
安全保密 XML Encryption,XML Signature,SAML,XKMS,XACL
一般PKI架构,数
位签章与加密技术 一般PKI架构,数位
签章与加密技术
通讯协定 HTTP,SOAP HTTP, MSMQ HTTP,SMTP,SOAP
资料交换格式 XML文件 BizTalk文件 XML文件
讯息规范 XML安全技术相关
规范书
BizTalk架构规范
的Biztags
E-speak服务规范
讯息交换伺服
器
一般网站伺服器 BizTalk 架构相容
的伺服器
E-speak电子商务
平台
单一登录模式 有 无 无
企业对企业的
应用(B2B)
有 有 有
企业对顾客的
应用(B2C)
有 无 有
表 2 以XML为基础的架构比较表
[资料来源:本研究]
69
第四章 应用XMLSeF架构的电子付款系统
本章是介绍应用XMLSeF架构实作电子付款系统雏型,我们称为XML
Security Payment System,简称XMLSePay,我们的目标在於建立具有便利性
与延展性的电子付款系统,解决电子钱币系统目前发展上的困境,本系统提供便
利的电子钱币转换与单一登录模式的网路购物环境,并做到资讯机密性,完整性
等特点,让XMLSePay成为未来电子付款系统的参考方案,最后将XMLSePay
系统加以实作以验证XMLSeF架构的可行性与实用性.
4.1 系统设计
4.1.1 XMLSeF系统角色与功能
XMLSePay电子付款系统是XMLSeF架构的应用范例之一,主要角色有
三:消费者(Customer, C),付款经纪人(Payment Broker, PB)与网路商店
(Merchant, M),参照XMLSeF架构如下表所示:
XMLSePay付款系统应用角色 XMLSeF架构角色
电子钱包持有者(消费者) 使用者
付款经纪人
l 电子钱包管理服务,联盟
网站连结提供
l 电子钱币产生相关的功能
模组
网站服务安全提供者(WSSP)
l 网站服务处理者
l XML安全服务
网路商店
l XML安全检验服务
l 购物车与结算服务,联盟
网站连结提供,回收电子
钱币
服务提供者(SP)
l XML安全检验服务
l 网站服务引擎
表 3 XMLSePay付款系统与XMLSeF架构之角色参照
[资料来源:本研究]
70
XMLSePay是以XML安全技术,帐户与储值制为基础,每个使用者得先在
付款经纪人网站上建立会员资料,并先使用其他大额付款方式向付款经纪人购买
储值点数,储存於使用者於付款经纪人网站的个人电子钱包里面.所谓储值制意
指使用者先以信用卡,金融卡,划拨或汇款方式预付给付款系统一些实际金额,作为储值制的储值金额,在日后付款时即可从中扣款.
XMLSePay电子付款系统中的付款经纪人主要会提供电子钱包网站服务与
XML安全服务两部分,电子钱包服务相当於WSSP的网站服务处理者的功能.
电子钱包服务提供消费者线上电子钱包的登录与管理服务,XML安全服务提供
电子钱币产生相关的功能模组;网路商店也会具有两个主要网站服务:XML安
全检验(XML Security Check)网站服务与购物服务,XML安全检验服务负责电子
钱币的验证,与交易资讯写入电子钱币的工作,购物服务负责将产品清单呈现给
消费者选购与结算此次交易内容,并传递交易资讯给XML安全检验服务将交易
资讯写入到电子钱币.
消费者於付款经纪人网站上建立线上电子钱包并藉由此服务从网站上提出
适当额度的电子钱币进行交易;付款经纪人负责电子钱币的产生与验证,并控管
网路商店将交易记录写入到电子钱币;网路商店负责检验消费者带来的电子钱币
与提供购物服务.
4.1.2 电子钱币内容结构与参数格式介绍
在接下来的说明中,使用到一些缩写代表符合,说明如下:
KPB_PRV 付款经纪人依据XKMS规范所产生的签章私钥
KPB_PUB 付款经纪人依据XKMS规范所产生的签章公钥
KPB_SEC 付款经纪人所拥有的安全密钥(Secret Key),次密钥只有付款经纪
人自己安全地持有
BrokerInfo 付款经纪人基本资讯,如付款经纪人的识别编号与名称
71
MoneyInfo 电子钱币基本资讯,如金额数目,发行时间与使用期限
Challenge 电子钱币防伪检查码,使用付款经纪人的安全密钥KPB_SEC加密
TransactionRecord 与网路商店的交易资讯内容
AuthCheckSum 向付款经纪人取得写入电子钱币的授权码
KME_PRV 网路商店依据XKMS规范所产生的签章私钥
KME_PUB 网路商店依据XKMS规范所产生的签章公钥
KPB_SEC 付款经纪人的安全密钥(Secret Key),此密钥只有付款经纪人持有
KM_SEC 网路商店的安全密钥(Secret Key),此密钥只有该商店与付款经纪
人持有,其他合作网站是无法取得的
Enc(Key, Message) 使用安全密钥(Secret key )对讯息Message加密
Sign(Key, Message) 使用私钥Key对讯息Message进行数位签章
4.1.3 电子钱币的讯息结构
将架构中所提供的讯息结构应用到XMLSePay电子付款系统中,成为电子
钱币的讯息结构,消费者持有的电子钱币内容有:
:产生此电子钱币的厂商讯息
:包含有描述电子钱币金额的元素,电子钱币
发行时间与使用期限.
:电子钱币查核检查码,由付款经纪人使用乱数运算产生的随机
字串,在此使用取代,代表付款经纪人使用安全密钥
KPB_SEC对此加密后的结果.
:付款经纪人为该消费者所发行的SAML安全声明书
:付款经纪人对该电子钱币基本资讯与SAML安全声明书两者资
讯所签署的数位签章.
:元素节点的属性AuthID描述著付款经纪人给予的写入
72
交易记录授权码,若无此授权码,网路商店无法将消费者购物资讯写入.子节点
记录著购物商品名称与购物单位数,使用网路商店的KM_SEC 进行加
密保护,只有本交易网站与付款经纪人可以解密取得.子节点记录
此次购物所用金额,作为计算此份电子钱币 余使用金额的依据,以及
网路商店对此次交易的数位签章,保证确实是该网站的交易.
:描述该电子钱币的传输路径,每个上游网站来源都会使用
签章签署保证是由该网站所传输.
图 44 电子钱币的讯息结构
[资料来源:本研究]
()
()
73
4.1.4 信任关系(Trust Relation)
XMLSePay是联盟购物网环境,要让此系统运作的前提是付款经纪人得先
与它的合作网站建立信任关系,让他们可以依据电子钱币进行查核与验证,交易
合作夥伴之间的信任关系可记录在XML资料档案中,依据此XML档案来查核.
4.2 系统架构
XMLSePay系统主要应用XML安全技术来对交易讯息内容进行保护,消费
者登录在付款经纪人网站上的电子钱包取出适当额度的电子钱币,持有此电子钱
币到采用付款经纪人A付款系统的合作网站购物;或者将电子钱币携带到付款
经纪人B的网站要求转换同等的电子钱币,然后消费者持有新转换的电子钱币
到采用付款经纪人B付款系统的合作网站购物.
消费者只需要一次登录,就可以持有电子钱币到众多网站进行消费,不必在
每个网路商店建立会员资料,为消费者带来莫大的便利性;每家付款经纪人的电
子钱币可以可靠地相互转换使用,让电子付款系统的拓展性或延伸性有更多的选
择,且消费者也不必在每家付款经纪人都登录资料成为会员.
消费者付款经纪人 A
网路
商店 A1
网路
商店 A2
网路
商店 AN
付款经纪人 B
付款经纪人 N
网路
商店 B1
网路
商店 B2
网路
商店 BN
图 45 应用XMLSeF架构的电子付款系统XMLSePay
[资料来源:本研究]
74
4.3 系统交易流程
4.3.1 电子钱币的产生,验证与购物结算
收到产生的电子钱币请求
产生电子钱币的基本资讯
与代币检查码
XML Encryption功能模组
用KPB_SEC对检查码加密
SAMLGenerator功能模组
为消费者产生SAML安全
声明书
使用KPB_PRV对电子钱币进
行签章
电子钱币
图 46 付款经纪人的电子钱币产生流程
[资料来源:本研究]
消费者登录到付款经纪人要求电子钱币服务,建立他所要求金额数目的电子
钱币,主要应用为XML安全技术有XML Encryption,XML Signature,SAML.
而数位签章所用的密钥都是交由公正第三者依据XKMS规范,交由XKMS
Server来代为管理.图46说明付款经纪人为消费者产生电子钱币的流程,XML
安全技术的功能模组是归属於付款经纪人的XML安全服务的功能模组.
网路商店对消费者所持有的电子钱币的验证流程如图47,这些验证功能模
组是归属於网路商店的XML安全检验服务.图47中来源网站的意思是指电子
钱币由网站A传输到网站B,来源网站指的是网站A.
75
接到消费者持有的电子钱币
对电子钱币中来源网站的位置作验证
对付款经纪人的数位签章作验证
回覆错误讯息
对SAML安全声明书作查核
对电子钱币剩余余额作检查
消费者进入网路商店购物服务
图 47 网路商店电子钱币验证流程
[资料来源:本研究]
网路商店
付款经纪人
接收到购物交易结算资讯
XACL请求写入授权模组
XACL处理功能模组
验证网路商店资格
XACL请求授权讯息
资格通过,传回交易授权码
资格不通过,传回空白交易授权码
将授权码与交易资讯
Binding在一起
对此交易资讯进行网路
商店的数位签章
1
2
3
4
5
6
图 48 交易资讯写入流程
[资料来源:本研究]
当消费者持有电子钱币到网路商店进行购交易完成之后,网路商店得将交易
资讯写入电子钱币,这个处理流程如图48,主要是依据网路商店的XML 安全
检验服务与付款经纪人的XML安全服务互动所进行.目的是为了防止非法商店
进行写入资讯到电子钱币中.
76
4.3.2 购物与付款交易流程
XMLSePay有两种主要交易模式,第一种是消费者由付款经纪人网站取得
电子钱币到采用本电子付款系统的合作网路商店购物;第二种是消费者由付款经
纪人A取得电子钱币,到付款经纪人B的合作网路商店购物.
藉由单一个付款经纪人与网路商店进行购物模式
消费者
付款经纪人
网路商店1网路商店2
S
t
e
p
1
S
te
p
2
S
te
p
3
Step 4
Step 5
Step 6
S
t
e
p
7
图 49 单一个付款经纪人与网路商店进行购物模式
[资料来源:本研究]
Step1. 消费者登录付款经纪人所提供的电子钱包网站服务,这是唯一一次登录
动作(Single Sign-on),向付款经纪人要求取出适当额度的电子钱币,付款经纪
人的XML安全服务依据消费者请求,利用XML安全技术产生电子钱币,付款
经纪人会呈列出合作网路商店的超连结给消费者.
电子钱币内容:Sign(KPB_PRV, (BrokerInfo + MoneyInfo + Enc(KPB_SEC,Challenge)
+ SAMLAssertionList ) )
Step2. 消费者点选网路商店1的超连结,付款经纪人会先传送电子钱币编号给
网路商店的XML安全检验服务,通知该网路商店有一份电子钱币要传送过来,网路商店的XML安全检验服务会回送讯息给付款经纪人要求它传输电子钱币,付款经纪人就将消费者与电子钱币传输与导引到网路商店1.
77
Step3. 网路商店1接收到电子钱币之后,藉由它的XML安全检验服务来查验
该电子钱币,若查验通过就让消费者进入购物阶段,当消费者购物完成进入结
算,XML安全检验服务会向付款经纪人取得写入交易资讯的授权码,一起与交
易资讯写入到电子钱币当中.网路商店1呈现其他合作网路商店超连结,让消费
者持有电子钱币继续与其他网站进行交易.
电子钱币内容:Sign(KPB_PRV , (BrokerInfo + MoneyInfo + Enc(KPB_SEC,Challenge) + SAMLAssertionList ) ) + Sign(KME_PRV_1, AuthID +
TransactionRecord)
Step4. 在浏览网路商店1的消费者点选网路商店2的超连结,商店1将消费者
电子钱币编号传送给商店2的XML安全检验服务,通知有一份电子钱币要传输
过来,商店2的XML安全检验服务会回送讯息给商店1要求传输电子钱币,商
店1就将消费者与电子钱币传输与导引到网路商店2.
Step5. 同样地,网路商店2利用XML安全检验服务对电子钱币检验,检验通
过,让消费者进行购物阶段,当交易进入到结算阶段,XML安全检验服务会向
付款经纪人取得写入交易资讯的授权码,一起与交易资讯写入到电子钱币当中.
电子钱币内容:Sign(KPB_PRV , (BrokerInfo + MoneyInfo + Enc(KPB_SEC,Challenge) + SAMLAssertionList ) ) + Sign(KME_PRV_1, AuthID1 +
TransactionRecord1) + Sign(KME_PRV_2, AuthID2 + TransactionRecord2)
Step6. 若消费者不再购物或进行交易,消费者可立即点选网路商店2上回到付
款经纪人网站,将电子钱币回收;或者消费者就直接离开商店2,由商店2批次
地检查是否有未回收到付款经纪人的电子钱币存在,将未回收的电子钱币加以回
收,让付款经纪人依据这些回收的电子代币与各家网路商店进行清偿帐目程序.
Step7. 付款经纪人於电子代币回收与清偿完帐目,以电子邮件方式将帐目内容
寄送给消费者.
78
两个以上的付款经纪人互动所建立的网路购物模式
本模式是让消费者可以使用付款经纪人A给予的电子钱币,去向付款经纪
人B的合作网路商店1或网路商店2进行购物.
消费者
付款经纪人A
网路商店2
S
te
p
1
Step 2
Step 3
Step 4
S
te
p
9
付款经纪人B
网路商店1
Step 5
S
tep
6
Step7
Step 8
图 50 两个以上的付款经纪人互动所建立的网路购物模式
[资料来源:本研究]
Step1. 消费者登录付款经纪人A所提供的电子钱包网站服务,这是唯一一次登
录动作,由付款经纪人A取出适当额度的电子钱币,付款经纪人A的XML 安
全服务依据消费者请求,利用XML安全技术产生电子钱币,经纪人A会呈列出
其他付款经纪人的超连结与它们的合作商店资讯给消费者.
Step2. 消费者点选付款经纪人B的超连结,付款经纪人A会先传送电子钱币编
号给付款经纪人B的XML安全服务,以通知有一份电子钱币要传送过来,经纪
人B的XML安全检验服务会回送讯息给经纪人A要求它传输电子钱币,经纪人
A就将消费者与电子钱币传输与导引到经纪人B.
Step3. 付款经纪人B接收到电子钱币之后,藉由它的XML安全检验服务查验
该电子钱币,若检验通过,经纪人B将会依据原本电子钱币的内容,为这位使
用者产生一份可用於经纪人B所属交易网的电子钱币.然后消费者就持有付款
经纪人B所给予的电子钱币,与经纪人B的合作商店进行交易购物.
Step4. 网路商店1接收到电子钱币之后,藉由它的XML安全检验服务检验该
电子钱币,若检验通过,让消费者进行购物阶段,当消费者购物完成进入结算,XML安全检验服务会向付款经纪人B取得写入交易资讯的授权码,一起与交易
79
资讯写入到电子钱币当中.网路商店1呈现其他合作网路商店超连结,让消费者
持有电子钱币继续与经纪人B的其他合作网站进行交易.
Step5. 在浏览网路商店1的消费者点选网路商店2的超连结,商店1会将消费
者电子钱币编号传送给商店2的XML安全检验服务,通知有一份电子钱币要传
输过来,商店2的XML安全检验服务会回送讯息给商店1要求它传输电子钱币,网路商店1就将消费者与电子钱币传输与导引到网路商店2.
Step6. 同样地,网路商店2利用XML安全检验服务对电子钱币检验,检验通
过后让消费者进行购物.当消费者购物完成进入结算,XML安全检验服务会向
付款经纪人B取得写入交易资讯的授权码,一起与交易资讯写入到电子钱币.
Step7. 若消费者不再购物或进行交易,消费者可以立即点选网路商店2上回到
付款经纪人B网站,将电子钱币回收;或者消费者就直接离开商店2,由商店2
检查是否有未回收到付款经纪人B的电子钱币,未回收的电子钱币加以回收,让付款经纪人B依据这些回收的电子代币与各家网路商店进行清偿帐目程序.
Step8. 付款经纪人B回收电子钱币之后,会将消费者於本交易联盟的交易资
讯,从新的电子钱币写入到原本消费者从付款经纪人A所带来的电子钱币当中,然后付款经纪人B将付款经纪人A所发行的电子钱币回送给付款经纪人A.
Step9. 付款经纪人A於电子代币从付款经纪人B回收后,清偿完毕帐目之后,将帐目内容以电子邮件方式寄送给消费者.
4.3.3 电子钱币回收流程
当消费者不再继续与目前所在网站商店进行交易时,回收电子钱币的方法有
两种,第一种是消费者自行将完成交易的电子钱币带回给发行该电子钱币的付款
经纪人;第二种方式是各网路网站以批次或定时的方式,来检验本身网站所收到
的电子钱币留存票据,是否存有未送回给发行该电子钱币的付款经纪人的记录.
80
消费者自行将电子钱币带回到发行该电子钱币的付款经纪人
每个合作的网路商店都得提供让消费者回到付款经纪人的管道,消费者利用
此管道,可以将本身导引回到付款经纪人网站,也可以将他持有的电子钱币给携
带回付款经纪人的网站,交由付款经纪人的清偿服务进行处理.
单一个付款经纪人与网路商店的回收模式
一般消费者习惯於交易完成就与该网路商店离线,不会再经由所提供的管道
回到付款经纪人网站,所以,回收电子钱币的重任就交给各个合作网路商店,藉
由分散式系统环境的合作,将回收处理的工作利用各个合作网路商店的软硬体资
源来进行,如每个网路商店定期或者批次的方式,检查在该商店中是否存有交易
授权过期并且最后传输路径记录为空白者的电子钱币记录,代表该商店是该电子
钱币交易的最后一站,有责任将该电子钱币藉由SSL安全通道传输给发行该电
子钱币的付款经纪人网站;让付款经纪人进行清偿帐目,清偿之后再统计该付予
网路商店多少款项.
两个以上的付款经纪人互动所建立的回收模式
1. 消费者向付款经纪人A提出电子钱币M,经由付款经纪人B的转换产生新
的同额度电子钱币N,消费者持有新的电子钱币N向付款经纪人B所属网
路商店进行购物所产生.
2. 归属於付款经纪人B的网路商店会定期或者批次的方式,检查在该商店中
是否存有交易授权过期,且最后传输路径记录元素为空白者的电子钱
币记录,代表该商店是该电子钱币N交易的最后一站,有责任将该电子钱
币N藉由SSL安全通道传输给付款经纪人B网站.
3. 付款经纪人B接到回收的电子钱币N进行清偿帐目,并统计该付予网路商
店多少款项.
4. 付款经纪人B会将交易完成的内容,从电子钱币N取出写入到消费者之前
81
持有的付款经纪人A所发行电子钱币M中,将此电子钱币M传输回到付款
经纪人A做为付款请求,付款经纪人A清偿帐目之后,将统计该给予付款
经纪人B多少款项.
4.5 系统实作
为实现上面说明的XMLSePay电子付款系统,接下来对XMLSePay雏型系
统建置来阐述该电子付款系统的功能与系统运作,并显示系统相关画面.
4.5.1 系统环境与工具组
依据以上的分析实作一个电子钱币付款系统雏型,系统发展工具与环境如下表:
项目 开发工具
作业系统 Microsoft Windows 2000 Server
资料库 Microsoft SQL Server 2000
浏览器与网站伺服器 Internet Explorer 6.0 与Apache Tomcat Version 4.0.3
XML文件编辑工具 XML SPY 3.5
网站服务程式 Java Server Pages
网页编辑工具 Macromedia Dreameaver 4.0
讯息传输协定 HTTP与SOAP
XML剖析器 Java Sun Parser
XML安全技术工具组 VeriSign公司的Trust Services Integration Kit 1.0
Netegrity公司的JSAML Toolkit 1.01
IBM XML Security Suite套件中的XACL Processor
表 4 实作XMLSePay系统环境
[资料来源:本研究]
采用Apache Tomcat作为网站伺服器是由於XML安全技术工具组都是
Java为基础的开发环境,Tomcat是Apach软体公司Jakarta project计画设计
用来专为执行Java为基础的网站服务程式的伺服器平台,因此利用Tomcat
Version 4.0.3网站建置工具,来建置网站模拟环境,并使用JSP(Java Server
82
Pages)撰写主要网站服务的程式语言;JSP是由Sun Microsystem公司基於
Java Servlet以及整个java体系的网站开发技术,是Servlet2.1 API的扩展.利
用这一技术可以建立先进,安全和跨平台的动态网站.
依据W3C与XML.org组织等所提供的工具组资讯,一一尝试执行的结果,发现IBM的安全套件(XML Security Suite)工具组所提供的范例,执行测试的错
误非常地多,参照IBM研发单位的讨论区,也无从得到解决,以及Phoas公司
所提供的XML安全工具有试用天数限制.测试没有问题的XML安全技术工具
组是VeriSign公司的XML Trust Center网站所提供的信任服务整合工具组
(Trust Services Integration Kit, TSIK),本系统藉由此工具组来执行与处理XML
数位签章,XML加密,XKMS机制的密钥管理与验证;另外,利用Netegrity公
司所提供的SAML执行解决方案的JSAML Toolkit,来为电子钱币产生SAML
安全声明书与验证处理,利用IBM DeveloperWorks组织所提供的XML安全套
件中的XACL处理物件,帮助本系统建立XACL处理者来进行XACL存取控制.
4.5.2 系统执行架构
Data LayerBusiness Logic
Layer
Presentation Layer
SQL Server
XML安
全资讯
文件
使用者浏览器
Client应用程式
Apache Tomcat/JSP
XML Security
Service
Web Service
图 51 三层式架构运作模式
[资料来源:本研究]
本系统采用三层式架构来建置XMLSePay电子付款系统雏型,分别是使用
者端的展示层(Presentation Layer),中介处理的企业逻辑层(Business Layer)与
83
资讯储存的资料层(Data Layer).客户端的展示层负责处理使用者的资料输入与
交易结果显示,让使用者与网站服务进行互动;企业逻辑层的网站服务,接收到
前端使用者的请求或相关资讯,进行商业流程处理,它是身为展示层与资料层的
中介层角色,藉由ODBC将资料传输给资料层,或者XML剖析器将XML内容
资给剖析出来;资料层主要是负责资料库或XML文件资讯处理.
4.5.3 系统运作流程实作
图 52 XMLSePay电子钱包登录服务
[资料来源:本研究]
首先消费者必须登录XMLSePay电子付款经纪人网站的电子钱包服务,利
用使用者帐号与密码进行身份认证,这是交易环境唯一一次的身份登录如图52.
在使用者身份确认无误之后,消费者就可以进入他个人的电子钱包当中,如
图53,系统会将个人基本资讯与电子钱包中的电子钱币储值点数呈现给消费者
了解,消费者可以利用电子钱包的「新增电子钱币储值点数」与「查询交易记录」
来新增电子钱币储值数目与过往交易资讯查看.消费者若要提取电子钱币进行交
易,电子钱包服务的提领对话框,输入消费者要提取的电子钱币数目,然后电子
钱包服务将资讯传输给付款经纪人的XML 安全服务来为消费者产生电子钱币.
84
图 53 电子钱包服务界面
[资料来源:本研究]
付款经纪人的XML Security Service负责电子钱币的产生,产生过程如下:
Step 1. 依据消费者与取款金额资讯,为消费者产生电子钱币初版(讯息详细内
容参照附录二之1),并从消费者的电子钱包中扣除同等金额数的电子钱币储值
数.电子钱币初版树状结构如图54.
XMLSecurityRecord
AuthRecord
AuthBroker
MoneyUser
Emoney
ThisMoneyAmount
AuthChecksum
xenc:EncryptedData
取代
图 54 电子钱币初版结构内容 [资料来源:本研究]
Step 2. 使用付款经纪人的安全密钥为电子钱币检查码加密,加密
后的结果请参照附录二之2.
Step 3. 为此电子钱币产生一份SAML安全声明书,并将此SAML安全声明书
放置到元素之下,此份SAML安全声明书内容请参照附录二之3.
85
然后再使用付款经纪人私钥为元素进行数位签章(签章范例请参
照付录二之4)与加入交易路径资讯元素,结果讯息如下图.
图 55 电子钱币讯息架构 [资料来源:本研究]
当付款经纪人为消费者产生适当额度的电子钱币,会将合作网路商店与其他
付款经纪人的连结呈现给消费者点选进行交易.如图56所示.
图 56 付款经纪人所提供的合作网站列表 [资料来源:本研究]
86
假设消费者点选Shopping Store 1网路商店,付款经纪人会将消费者所持
有的电子钱币传输到Shopping Store 1并且将消费者导引到该商店,该商店会
进行钱币的验证,验证结果如下图57所示.
图 57 网路商店对电子钱币验证结果
[资料来源:本研究]
若电子钱币验证通过,消费者则可以点选进入网路商店购物服务(参照附录
二之5),当消费者选定商品进行结算的动作,若交易付款成功,将会显示如图
59所示结果,过程如下:
Step1. 由消费者点选结算钮所触发付款过程,Shopping Store1检查电子钱币
是否足够为交易付款,若有足够余额来付款,Shopping Store1会先向付款经纪
人发出一个XACL标准的请求(参照附录二之6),要求授权写入交易资讯.
Step2. 付款经纪人会根据记录合作关系的XML档案来验证授权(参照附录二之
7),利用XACL处理器验证商店权限,回应给予一个写入授权码与相关资讯.如
下图所示,元素告知付款经纪人XACL处理结果,元素结果告知付款经纪人授予商店此次交易的授权码.
87
图 58 付款经纪人於XACLProcesspr回应的讯息
[资料来源:本研究]
Step3. Shopping Store1接收到回应的XML讯息加以剖析,并取得交易写入授
权码,将该授权码与此次交易资讯一起写入到电子钱币.结帐结果如图59所示:
图 59 与网路商店1的交易结果
[资料来源:本研究]
NoError
991ms
write
8381761497767842338
88
实作完成的XMLSePay系统功能部分有如下表所示:
参与角色 网站服务功能模组 服务内容
电子钱包服务 电子钱包登录与管理服务,如提款功能与
XML格式的电子钱币初稿产生
XML加解密 为电子钱币的检查码加密与解密
SAML产生器与验证 为钱币产生SAML安全声明书,或者为电
子钱币中SAML安全声明书进行验证
XML数位签章与验证 为钱币中的元素进行签
章,或者电子钱币中的数位签章进行验证
SOAP传输封装 将电子钱币封装成SOAP来传输
XACL处理器 接收商店XACL请求,检验商店权限
交易写入授权码给予 依据XACL处理器产生的结果,为商店的
特定交易产生写入授权码,该授权码为随
机产生之字串
电子钱币转换 依据消费者持有的电子钱币余额,产生适
用於本付款经纪人消费环境使用的电子
钱币
付款经纪人
合作网站列表 呈列出合作交易网站与付款经纪人连结
XML数位签章验证 为交易< |
