网络银行文档格式.docx
《网络银行文档格式.docx》由会员分享，可在线阅读，更多相关《网络银行文档格式.docx（15页珍藏版）》请在冰豆网上搜索。
特殊性
Millicent
M签名的票据
M/B
借记
离线
对称，hash
根据安全性和效率有三种协议形式
MicroMint
满足hash冲突的硬币
B
Hash
货币只能由中间人产生
SubScrip
票据
M
在线
无
简单但不安全，可进行公钥扩展
PayWord
PayWord支付字
C
信用
公钥，hash
同一支付链适合于单个M
NetCard
硬币及hash值
B/C
公钥，对称，hash
基于hash链的微电子现金，有多种协议形式
Paytree
树结构的叶子节点
同一支付树可应用于多个M
μ-iKP
基于hash链的息票
具有重复和非重复两种支付形式
LITESET
基于信用卡
使用Signcryption技术
SVP
支付额和其hash值
采用抗篡改硬件
3.2票据微支付机制
票据是微支付交易中用来代表小额货币的一系列数据。
作为支付的凭证，它具有如下特点：
一个票据代表一定的预付值，它和电话预付卡、消费卡和息票相似；
票据的安全性基于它仅代表小额现金的假设；
票据是由商家或商家授权的经纪人生成的，因而它只有在特定的商家处才能使用；
票据只能被消费一次，重复花费可以在消费者支付的过程中被商家检测出来；
票据只能被其合法拥有者使用，它通过消费者密钥来防止被窃取的票据用于花费；
票据可以抗破坏，消费者也不能对其面值或属性进行修改；
票据可以抗伪造伪造，票据花费的代价比票据本身的价值要高得多；
票据可以方便有效地产生和验证，由于它没有使用公钥加密技术，因而通过使用散列算法和对称密钥加密技术可以高效地生成并验证票据；
票据不能提供完全的匿名性服务，由于其序列号是可见的，因而可以被记录和跟踪，通过使用一个匿名的大额支付系统购买经纪人票据可以提供有限的匿名性服务。
为了获取票据的如上特性，一般在票据生成过程中采用了如下技术；
票据结构中给出了票据面额和商家标识；
每张票据都有一个唯一的序列号以防止重复花费；
利用单向散列函数（如SHA-1）创建和验证“数字签名”；
使用“数字签名”来防止破坏和伪造；
消费者使用与票据相关的密钥来对每次票据使用进行“数字签名”。
目前比较典型的票据微支付系统主要有Millicent和Subscrip等。
3.3subscrip关键技术
SubScrip是澳大利亚的Newcastle大学开发的一种很简单的微支付系统，最初是为Internet的按次计费而设计的。
它基于预支付机制，不需要对C进行身份验证。
SubScrip同Millicent的实现技术基本类似，都只需M在本地验证，而不需要TTP的参与在线清算。
同样，对一个新的M进行支付时，也需要一个初始化过程。
这两个微支付机制对于短时间内对同一M的重复消费是有效的。
但与Millicent不同的是，SubScrip不需要介于C和M之间的B，而是使用一个C和M都认可的宏支付系统来担当这个角色，该宏支付用于在M处建立一个临时账号，以进行后续的购买。
所以，SubScrip中用户的匿名性也依赖于该宏支付系统。
SubScrip中的账号标识以明文形式编码在SubScrip票据中，以同M数据库中的相应账号对应。
当进行购买时，用户把SubScrip票据提交给M，M通过检查数据库来验证票据的有效性。
小额支付后的数额从数据库账户中扣除，然后产生一新的账号标识和新的余额票据，并连同购买的信息或服务结果返回给C。
C把该新的SubScrip票据保存在本地，以备后用。
同Millicent中的凭据（电子硬币）不同，SubScrip票据本身不具有任何价值，只是通过票据中的C标识来在M数据库中查找相应账号，真正的价值存在于M的数据库中。
SubScrip的基本形式中没有采用加密和hash算法，票据和相应信息以明文的形式传输，所以很容易被篡改或截获，并被非法使用。
篡改后的SubScrip票据将是无效的，因为它无法同M数据库中的真正用户账户相对应。
一个SubScrip票据只在一个M处有效，且本身的交易额小，所以，可以在一定程度上防止SubScrip票据的非法截获和使用。
为了提高安全性，SubScrip可进行公钥扩展，在建立账户的宏支付中，C把自己的公钥发送给M，M发送信息或新的票据时可使用该公钥进行加密。
4.具体应用
4.1基于用户与商家共享密钥机制的微支付系统
为了减少同经纪人的在线通信消耗，有些微支付机制没有使用第三方经纪人，而是在用户与商家之间直接进行支付，当达到一定的支付额或一定时期后，商家可以通过一次传统的宏支付完成所收集到的多次微支付。
这种机制比较适合对某些商家的重复支付。
典型的机制为SubScrip，它基于预支付机制，不需对C进行身份验证；
且支付只需V在本地验证，而不需要TTP的参与在线清算。
同样，对一个新的V进行支付时，也需要一个初始化过程，对于短时间内对同一V的重复消费是有效的。
SubScript不需要介于C和V之间的B，而是使用一个C和V都认可的宏支付系统来担任这个角色，该宏支付用于在V处建立一个临时账号，以进行后续的购买。
SubScrip中的账号标识ID（可以看作用户和商家之间的共享密钥）以明文形式编码在SubScrip票据中，以同V数据库中的相应账号对应。
当进行购买时，用户把SubScrip票据提交给V，V通过检查数据库来验证票据的有效性。
支付后的数额从数据库账户中扣除，然后产生一新的账号标识ID和新的余额票据，并连同购买的信息或服务结果返回给C。
C把新的SubScrip的票据保存在本地，以备后用。
与Millicent中的凭据（电子硬币）不同，SubScrip票据本身不具有任何价值，只是通过票据中的C标识，在V数据库中查找相应账号，真正的价值存在于V的数据库中。
SubScrip的基本形式中没有采用加密和散列算法，票据和相应信息以明文的形式传输，所以很容易被篡改或截获，并被非法使用。
篡改后的SubScrip票据将是无效的，因为它无法同V数据库中的真正用户账号相对应。
一个SubScrip票据只在一个V处有效，且本身的交易额小，所以，可以在一定程度上防止SubScrip票据的非法截获和使用。
因此，SubScrip只适用于那些安全的网络或截获的微支付价值低于截获者耗费的场合。
为了提高安全性，SubScrip可进行公钥扩展，在建立账户的宏支付中，C把自己的公钥PKc发送给V，V发送信息或新的票据时可使用该公钥进行加密，如{New_accountID}Pku。
但公钥的引入会极大降低微支付的效率。
对于这类微支付而言，对每一个商家，用户都要保留一个共享密钥。
当商家较多或商家的更换频率快时，仅客户端密钥的管理就是一个很大的负担。
有人提供了一种密钥管理方式，它由用户选择一个秘密密钥Kc，并根据需要，利用用户标识IDc和商家标识IDv来产生用户和商家的共享密钥，用表达式Kcv=f（IDc，IDv，Kc）来表示。
新产生的密钥用商家的公钥加密后发送给商家，该密钥只用于特定的商家。
当需要更换或更新密钥时，可根据Kcv，在用户端和商家端分别导出新的密钥，如h（Kcv，n），其中n为整数，可根据密钥更换次数增加，这样可以避免密钥的传输。
5.使用情况
5.1性能对比分析
对SubScript来说，由于对商家微支付之前需要进行一次宏支付操作，所以它需要存储证书，其证书和密钥的存储需求和基于公钥证书的NetBill和Mini-Pay类似。
SubScrip具有很小的存储需求，单在证书和密钥的存储方面却很大。
SubScript由于对每一个商家需要完成一次安全宏支付，Millicent的票据也需要传输，所以这两种微支付机制总的通信量比较大。
SubScript虽然通信量也比较小，只有30多个字节，但却没有提供安全功能，无法防止非法者窃听。
SubScript由于采用了初始的宏支付机制，也有很大的计算消耗。
SubScript不再需要任何安全操作，其安全算法的计算消耗为0，但却不能提供任何安全性。
微支付性能分析
在做存储分析时，我们做了如下合理的假设。
对一些普通的消息类型域，如用户名、用户地址或URL等，我们假定为16个字节，在实际系统中可能会比这大，也可能比这小，但在微支付系统中是合理的。
RC6的密钥为16个字节，其加密后的消息大小是与原消息值最为接近的16字节的倍数，即为
。
根据PKCS#1标准，RSA的签名为128字节，但要附带原始的消息以验证签名。
公钥指数e为两个字节，n为128个字节，长度信息为4个字节，所以，RSA的公钥为134个字节。
对公钥信息进行签名产生的数字证书格式如下，其中用户的身份U、经纪人的身份标识B和其他信息Other（可能为有效期等）都为16个字节，用户的公钥为134个字节，签名为128个字节，所以证书的大小为310个字节。
证书的拥有者需要存储其私钥和相应的公钥证书，证书的发行者，如经纪人，也需要一份用户证书的拷贝，以对用户证书的有效性进行检查和验证相应私钥的签名。
对于交易的另一方，如商家，当验证用户签名时需要用户证书，但验证以后就不再需要，所以，在商家可以不存储用户证书，但需要存储经纪人的证书，以完成对用户证书的验证。
在一些需要HASH链的微支付机制中，需要用一个序号来记录当前HASH链的位置，我们采用了两个字节，最大可记录65,535长度的HASH链。
表1给出了部分微支付基本元素的消息大小。
基本元素
大小（字节）
普通消息域
16
SHA-1散列值
20
散列链序号
2
RC6密钥
RC6加密后的消息
RSA私钥（d）
128
RSA公钥（e,n）
134
RSA签名
RSA公钥证书
310
下面我们就对证书和密钥，以及支付信息分别分析存储需求，以判断用户在支付前、商家在支付后和经纪人在清算完成后对微支付机制的存储需求。
另外，在后续的计算中，我们假定用户要进行1000次的支付，每次支付为0.1个货币单位。
一、证书和密钥存储分析
为了完成支付交易，在每一个微支付系统中，都需要在一定时间范围内长期存储某些证书、密钥和支付信息，这些都会占用系统的存储空间，特别是对一些用户使用的具有有限存储空间的设备而言，如手机、智能卡和PDA等，都会产生很大的影响。
对商家和经纪人而言，对每一个用户都需要一定的存储空间，如匿名电子现金中所存储的序列号，所以，微支付的存储要求也会显著影响商家和经纪人的可扩展性和性能。
我们把微的存储空间需求分为两个部分，第一部分为证书和密钥存储，用于交易方的认证和安全通信，另外一部分为支付指令信息，用于完成整个支付交易。
在整个分析过程中，如果没有特别指出，我们假定交易方为一个用户（U），一个商家（V）和一个经纪人（B）。
由于不同的微支付机制的实现原理和使用的安全算法不同，所以，其存储空间的要求也会不同，下面以PayWord为例。
PayWord为一基于信用的散列链微支付机制，在证书和密钥存储方面，在用户端，用户需要存储自己的私钥128字节和经纪人颁发的证书310字节，总共438字节。
在商家端，商家只需存储经纪人的证书即可，占用310字节。
而在经纪人端，经纪人需要存储用户证书310字节，自己的整数310字节和自己的私钥128字节，总共748字节。
图10显示了对11种典型的微支付机制证书和密钥存储要求，以不同的微支付类型进行分类。
图10不同微支付机制在交易各方的证书和密钥存储需求
从上图中可以看出，任何微支付系统在任何一方的证书和密钥存储都在1100字节以下，但在一些情况下还是认为比较高的。
如某些智能卡或手持设备，他们几K到10几K的存储容量，其中还要存储保证其运行的嵌入式操作系统和应用代码。
所以，小的证书和密钥存储需求对这些应用来说非常重要。
另外可以看出，需要公钥证书的微支付机制的存储要求就高的多，一个公钥证书就要310字节，而对称密钥却只需16字节。
但公钥机制可以提供在电子支付中很重要的不可否认性，而对称密码系统却不能。
另外，对称密码系统还存在一个密钥分配和管理的问题。
从图中可以看出，基于对称密码体制的微支付系统所要求的存储空间基本类似，如Millicent，它在用户端和经纪人端只需要40字节的存储容量，在商家端只需要20字节的存储容量。
但Millicent要求用户和商家共享一秘密密钥，所以，对每一个新的商家，用户都要存储一秘密密钥，这在图10中没有显示，而对证书以及用户与经纪人之间的密钥却保持不变。
所以，对于同时拥有16个商家的票据的Millicent用户，其存储需求和证书机制类似。
另外，基于散列冲突的MicroMint不需要证书和密钥存储空间。
基于概率的微支付机制在需要支付时使用hash链，所以其存储需求和hash链支付机制类似，如PayWord和UOBT等。
基于信用的HASH链支付机制（如PayWord）和基于预支付（Prepaid）的HASH链机制相比，在商家端的存储需求相同，都需要经纪人的证书，因为在验证完用户的支付承诺以后，用户证书就不再需要。
在对PayWord而言，在用户端还要存储用户的私钥。
对基于预支付的hash链机制，因为hash链和支付承诺由经纪人产生，用户只需存储经纪人证书即可。
二、支付信息存储需求
支付信息存储需求是指交易各方为完成支付所需要存储的信息大小，其中不包括证书和密钥。
这些支付需求不能单单指一个独立的支付，而是在完成一系列微支付之前和之后的稳定数据。
在本地的分析中，还是假定用户拥有10个金融单位（如元），对一个特定的商家，能够进行1000次的独立支付。
对PayWord而言，用户端需要保存产生hash链的根（20个字节）和所支付的链的序号（2个字节），所以，用户端的存储量为22个字节；
对商家而言，需要包含支付承诺的签名120个字节，支付链的根20个字节，用户标识和有效期标识各20个字节，以及最后一个收到的支付链20个字节，总共200个字节；
对经纪人端，需要包含支付链根20个字节，支付承诺签名128个字节，用户标识和商家标识各20个字节，总共180个字节。
其他微支付机制的计算方法类似。
支付信息的存储结果如图11所示，其中达到1000的表示其值已经超过了20000，远远大于其它微支付机制。
图11不同微支付机制在交易各方的支付指令消息存储需求
从图中可以看出，基于散列冲突的MicroMint所需要的存储大小有非常显著的增加，甚至达到了80,000字节，以存储1000个支付硬币。
而对基于银行签名电子硬币的宏支付电子现金系统，其所需的存储容量可能还会更大。
所以，MicroMint不需要证书和密钥存储的优势也被抵消的一干二净。
但如果对1000个不同的商家进行1000个独立的支付的话，对用户而言，MicroMint的存储需求只是PayWord的四倍，而对商家而言，MicroMint的存储需求比PayWord还要小好多。
然而，在大多数情况下，用户对同一商家的重复支付还是最为常见的。
对一些在线微支付机制，它只在经纪人处需要存储，支付信息由用户动态产生并实时进行清算，但却需要较大的交易日志存储，甚至能达到一些宏支付的存储需求。
基于信用的hash机制，如PayWord，在用户端需要的存储容量较小，因为支付链和支付承诺都可以根据需要动态产生。
相反，对基于预支付的hash链，由经纪人签署支付的承诺需要保存，约200个字节。
用于PayTree需要在用户端存储额外的hash链，其存储容量达到了800多个字节；
UOBT把这些负担转移给了商家，由商家来存储所有树的叶子节点。
虽然如此，它们的效率还是很高的，这可以从后续的讨论看出。
由于采用了基于信用的HASH链机制，由于基于概率的微支付机制的存储需求和基于信用的HASH链类似。
另外，SubScrip具有很小的存储需求，单在证书和密钥的存储方面却很大。
最后，图12给出了总的存储结果，其中达到1300的表示其值已经超过了20000，远远大于其它微支付机制。
图12不同微支付机制在交易各方的总存储需求
4.2通信量（带宽）分析
在微支付机制中，微支付交易各方相互之间通信量的大小和次数也是影响微支付应用的一个很重要的方面，特别是对带宽资源有限的无线通信环境，所以，对微支付的通信量或带宽需求进行分析也是体现微支付性能的很重要的方面。
在我们的分析中，只是包含了需要在线完成的交易信息，而对于一些离线完成的交易，如离线清算，我们没有考虑在内。
另外，我们也没有包含完成交易需要的网络连接通信量消耗和时间消耗，它和网络的类型和基础设施有很大的关系。
我们把微支付的交易过程分成了首次支付和后续支付。
相对后续支付而言，首次支付需要完成一些额外的通信过程和计算消耗。
对某些基于公钥机制的微支付，首次支付需要使用数字签名和证书，而后续支付则不需要，这样可以节省大部分通信量；
而对MicroMint和Millicent而言，其首次支付和后续支付的通信量相同。
微支付机制的通信量和带宽是交易双方为完成一次完整的交易需要传输的所有信息的大小，它与每次的通信量和通信次数有关。
和前面相同，在我们的计算中，对每一次支付都支付一个支付单元（即10个金融单位的1000分之1），包括首次支付和后续支付，然后计算交易各方相互之间的通信量，以字节为单位。
以PayWord为例，由于用户和经纪人，以及商家和经纪人的交易都可以离线完成，所以，其交易通信只存在于用户和商家之间。
对首次支付，用户需向商家提交用户证书310字节，商家标识和其他信息（如有效期等）各16个字节，支付链根20个字节，支付承诺签名128字节，支付单元链20个字节，共510字节。
而对于后续的支付，用户只需向商家提交20个字节的支付链即可。
对其他的微支付，如Mini-Pay，只有消费达到了一定的信用极限，它才会和经纪人进行交互，而一般情况下不会。
对基于预支付的hash链，首次通信时需要同经纪人进行安全交互，以购买hash链和支付承诺。
对PayTree和UOBT机制，只有用户和商家的通信交互，而和经纪人的都可以通过离线来完成。
对基于概率的微支付机制，我们假定概率为0.01，即100次支付中中奖一次，每次的价值为1.00个金融单位，即100个支付单元。
另外，如果出现用户或商家与经纪人的交互，则表明该支付交易为在线交易。
一、首次支付
图13给出了首次支付时常见微支付机制通信量大小示意图，以微支付类型分类。
从图中可以看出，大部分微支付机制的通信量都在600字节以下，特别是MicroMint的通信量更少，只有用户和商家之间的80个字节。
但如果一次需要支付多个支付单元的话，MicroMint的通信量会成倍增加，而PayWord则基本不变。
如一次支付7个单元的话，MicroMint和PayWord的通信量基本相同。
Wheeler由于采用了概率机制，实际支付发生的很少，所以其通信量也非常少。
对PayTree，由于其支付树与特定的商家有关，如果事先知道商家的话，可以离线完成，所以，其通信量也比较小。
但UOBT在对新的商家支付时，需要把支付树的叶子发送给商家，所以其通信量就比较大。
从总的通信量上来看（即完成一次交易相互各方通信量的总和），SubScript由于对每一个商家需要完成一次安全宏支付，Millicent的票据也需要传输，所以这两种微支付机制总的通信量比较大。
对基于hash链的微支付机制，不管是基于信用的机制还是基于预支付机制，其总的通信量相同，因为我们假定对预支付链机制，它需要在线同经纪人交互。
图13不同微支付机制首次支付时的通信量大小
二、后续支付
图14中给出了后续支付时常见微支付机制通信量大小示意图，以微支付类型分类。
为显示起见，U-V的NetBill和Mini-Pay分别为448和582字节，V-B的NetBill为880字节。
从这些图中可以很明显地看出，基于hash链的微支付机制（包括PayWord、预支付hash链、PayTree、UOBT和LotteryTicket等）在后续支付中的通信量非常小，只需传输一个hash值20个字节，这在安全微支付机制的通信中是非常小的。
MicroMint的通信量和首次支付相同，没有任何变化。
Millicent的依然很高，已经超过了250字节，是hash链机制的10几倍，只主要是由于所传输的票据以及返回的票据比较大。
NetBill和Mini-Pay的通信量也比较高，超过了400个字节，所以，它们不适合重复性的微支付，而只适合一次性的小额支付。
图14不同微支付机制后续支付时的通信量大小
另外，在图15中给出了完成每次后续支付所需要交易的次数，其中NetBill为在线机制。
所以基于hash链的微支付机制只需要1次交易，不需要商家的反馈，所以其效率比较高，特别适合于一些传输服务收费的场合。
而Millicent和SubScript则相反，它需要两次交易，其中一次是商家返回剩余的票据。
图15后续支付的交易的信息数目（即发送信息的次数）
4.3计算消耗分析
在支付过程中，支付各方为完成一次支付需要进行多个安全计算，如hash计算、加密计算
升级会员 