专利名称：使用格式化数据结构进行安全支付交易的系统和方法
技术领域：
本发明涉及用于验证在诸如因特网的开放式电子网络上各方之间进行的交易，尤其涉及对客户以包括信用卡的支付卡支付的因特网交易的验证。
背景技术：
现在电子商务是流行的。在诸如因特网的电子网络上进行交易对商家和客户而言都具有常常提及的方便、低成本、市场覆盖面大和选择多的优点。然而，因特网的匿名性给商家或零售商带来欺骗和错用的问题。交易商家需要验证销售、认证销售、确认销售、确保销售的不抵赖、确保支付、并控制匿名。类似地，买家需要控制销售的验证、销售的完整性、不良销售的追索、销售的确认、私密性和匿名。
通过引用包括在此的共同委派的2002年3月11日提交的美国专利申请10/096,271描述了一种使用客户终端上的用户软件接收用于显示网页的包括一个或多个隐藏字段的一系列网页数据来进行安全支付交易的系统和方法。具有交易和持卡人数据的网页被作为购买数据发送给商家。商家可向例如发卡机构电子地提交该网页数据，用于验证或授权支付交易。
发卡机构和其它金融机构现在提供或使用标准化的因特网交易协议来改进在线交易性能并加速电子商务的增长。在某些标准化协议中(例如，Visa International开发的3D SecureTM协议)，发卡机构或发卡银行可验证交易，从而降低由于持卡人未授权交易造成的欺骗以及关联的退款的可能性。验证交易的出现可使发卡机构对尽管于在线购买期间验证了持卡人但仍然出现欺骗的情形承担责任。发卡机构或发行银行确保商家能得到经发卡机构验证的交易的支付。3-D SecureTM协议与发卡机构(例如通过Visa或MasterCard SecureCodeTM校验)提供的验证程序一致，并成为它们的基础，以在诸如关联于因特网的远程交易期间为商家验证客户。3-DSecureTM协议发挥现有安全套接字协议层(SSL)的加密功能，并通过在线购物会话期间发卡机构对持卡人的验证来提供增强的安全性。称为商家插件(MPI)的一种软件由参与的商家用来交换消息、传递信息和查询参与者，以便于在线购买期间建立持卡人及其发卡机构之间的验证会话。
3-D Secure协议服务是基于三域模型的-发卡机构域、收单银行(acquirer)和互操作性域。发卡机构负责管理持卡人在服务中的登记，并负责于在线交易期间验证持卡人。收单银行负责定义过程，使参与因特网交易的商家在与收单银行的协议下运行，并向验证交易提供后端处理。互操作性域便于交易在另两个域之间交换共用协议和共享服务。持卡人及其银行可归入“发卡机构域”，而商家及其银行可归入“收单银行域”。发卡或收单银行或金融机构、以及发卡机构基础结构之间的通信可归入“互操作性域”。在与符合3-D安全的银行和商家交易时，除了会有一个来自持卡人银行的独立验证窗口或弹出屏幕来确定交易方是否的确是所记录的持卡人之外，消费者可有与以前一样的因特网购物体验。在该协议下在线因特网购买交易的交易流程可如下(1)客户通过加密安全套接字协议层(SSL)连接，以常用方式在商家网站上填入支付数据。
(2)然后商家通过MPI向目录发送消息，而目录向发卡机构查询，来发现客户是否在3-D安全程序中登记。
(3)发卡机构用表示持卡人是否登记的消息对目录作出响应，且如果登记则提供发卡银行的web地址。然后处理该消息，并将响应转发给商家。
(4)然后商家通过持卡人设备发送消息到发卡银行，以启动并验证持卡人和发卡机构之间的会话，其中还可向持卡人提供诸如商家名称和交易金额的交易细节用于确认。
(5)发卡银行然后向验证窗口填入与交易相关的持卡人详细信息，诸如商家名称和金额、个人安全消息、以及可由持卡人输入验证细节的响应区域。
(6)取决于发卡银行选择如何实现系统，客户以各种方法之一来认可交易。选项可在输入静态密码或PIN、使用智能卡和个人卡读卡器(PCR)来产生验证令牌之中选择。
(7)发卡机构可处理交易和用于验证的持卡人数据。如果验证有效，则发卡机构向商家发送表示验证成功的消息。如果验证失败或不能完成，则发卡机构也会通知商家。消息可包括编码验证处理结果的帐户持有人授权值(AAV)。
现在考虑增强用于验证在电子交易中使用信用卡或借记卡支付的客户的系统和方法的方式。注意力导向用于安全验证客户或用于向商家支付的卡的数据和算法。所需方案应当与像3-D安全的公用协议的行业实现和其它诸如智能卡的EMV标准的行业标准兼容。
发明内容
根据本发明，提供了与3-D安全协议一致的验证程序，用于验证在线持卡人交易。这些验证程序使用访问控制服务器(ACS)来验证持卡人交易。安全支付算法(SPA)由ACS应用于持卡人和交易信息，以产生分配给验证交易的加密的帐户持有人验证值(AAV)。所产生的AAV具有适于包括在3-D安全协议消息中的数据结构。
在本发明的较佳实施例中，数据结构具有不超过20个字节的Base 64编码字符的长度。第一字节是控制字节，字节2-9可表示商家名称的散列，而字节10标识验证持卡人交易的特定ACS。各种验证方法(例如基于密码的、基于芯片的、或PC标识方法)可由ACS用来验证持卡人交易。AAV数据结构的字节11标识验证方法和保密的秘密密钥，该秘密密钥由ACS用来产生商家验证代码(MAC)。AAV数据结构的字节12-15标识由ACS处理的交易的序列号，而字节16-20表示MAC。
SPA可包括适当加密过程以产生特定交易的MAC值。一个加密过程使用秘密密钥来加密持卡人帐号和AAV字段1-6(或字节1-15)的串联。加密结果的前40比特(或5个二进制字节)被分配给MAC字段。在另一加密过程中，一对数据加密标准(DES)密钥用来加密持卡人帐号、卡的到期日和服务代码的串联，以产生三位持卡人校验代码(CVC2)号。该三位号码被转换成二进制编码的十进制数，然后被用来填充AAV数据结构中的MAC字段的一个半字节。MAC字段的剩余三个半字节可用二进制零来填充或填塞。
包括AAV数据的3-D安全协议电子消息可由访问控制服务器(ACS)数字签名。接收包含AAV数据的消息的商家在提取或使用AAV数据之前需要校验数字请符合3-D安全协议。商家可向支付授权请求消息传送AAV数据，特别是MAC数据。
从附图和以下详细描述中，本发明的其它特征、其本质和各种优点将更加显而易见。
图1是根据本发明各原理的使用安全支付算法(SPA)来产生支付交易的帐户持有人验证值(AAV)的示例性验证程序的示意图。
图2是根据本发明各原理的用于传送图1安全支付算法的输出的全球持卡人帐户字段的结构的示意图。
图3是根据本发明各原理的涉及示例性支付交易验证过程的各实体之间的一些步骤和消息链接的说明。
图4是在线支付交易的验证和授权中涉及的示例性验证和授权实体之间的交互的示意图。
在所有附图中，除非另外注明，相同标号和标注用来表示相同的特征、元件、组件或所示实施例的各个部分。
具体实施例方式
本发明提供用于在电子交易中验证远程各方的方案。特别地，这些方案涉及用于验证远程参与电子交易的持卡人的安全支付应用程序(例如图1的SPA 135)。这些方案可用于在诸如符合3-D安全的电子商务平台的行业标准电子商务平台上进行的交易验证，并且用于诸如邮购和电话订购的非电子商务环境，其中验证令牌或代码可由发卡机构用来验证持卡人。
表格1是用于本说明书的若干术语、首字母简略词或缩写的词汇表。
SPA 135可包括密码学算法(即“HMAC”和“CVC2”算法)，用来以与3-D安全消息格式兼容的格式产生持卡人授权校验值(CAAV)。
SPA 135可与发卡机构为验证其持卡人而选择或实现的任何适当验证程序集成。这些验证程序可包括基于智能卡或基于密码的方案(例如图1的基于芯片的验证程序141和3-D安全的基于密码的验证程序142)。验证程序还可包括例如基于PC标识的其它方案。
使用本发明的安全支付应用程序(SPA 135)的验证程序可以是用于保护在与3-D安全协议兼容的电子商务平台上进行的电子交易的方案或程序。出于该目的，SPA 135被设计成以可容易地用于3-D安全消息中的数据格式来使用和产生验证结果。特别地，具有规定字段和字节长度的格式化数据结构可用来帮助在3-D安全消息中传输验证结果。
为了示出示例性验证程序1000(图1)中的应用程序SPA 135，在此卡支付交易被用作示例性交易。卡支付交易中的参与者可包括持卡人、发卡机构、商家和收单银行。
持卡人是例如由验证程序1000的许可成员签发的支付卡的授权用户。持卡人可使用所签发的支付卡来为与商家的在线交易进行支付。验证程序1000可以是第三方(例如MasterCard)提供的验证程序或服务的一部分，该第三方可在完成交易之前适当验证持卡人的身份和出现。
发卡机构是签发有品牌(例如MasterCard和/或Maestro卡)的支付卡的成员(例如金融机构)。发卡机构根据支付卡品牌章程和当地立法来保证使用支付卡的授权交易的支付。该发卡机构除了向商家或其它各方提供验证服务之外，还可负责确定参与验证程序1000的持卡人资格。
商家是零售商、或任何其它人、厂商或公司，它们例如依照商家预订协议同意在发卡机构的支付卡适当出现时接受卡进行支付。通过向验证程序1000预订，商家可在因特网上向持卡人提供经验证的电子交互。接受支付卡的商家可与收单银行具有进一步的关系。参与验证程序1000的商家可以若干种方式受益，包括欺骗和纠纷成本减少、增大的交易量、防止未经授权的卡使用以及访问发卡机构的卡库。
收单银行是与商家保持关系，并从商家或收卡机构获得交易相关数据的实体。收单银行可负责确定参与验证程序1000的商家的资格。
如图1所示，示例性验证程序1000可实现为具有众多分层组件的安全电子商务方案或平台。这些分层组件包括数据传输层100、商家需求层120、验证层130和发卡机构平台140。验证层130相关于用来验证交易或支付的安全支付应用程序(SPA 135)。
数据传输层100与数据收集和传输基础结构相关，该基础结构用来在持卡人、发卡机构、商家和收单银行之间传送验证信息和结果。数据传输可例如基于诸如全球持卡人验证字段(UCAF)的标准化数据结构、体系结构或机制。
UCAF一般可定义为可变长度的32-字符字段，它具有可调整以支持各种发卡机构安全和验证方法的需要的灵活数据结构。图2示出UCAF的一般结构。UCAF中的第一控制字节包含每个安全支付应用程序或方面专用的值。UCAF中的剩余字节可包括应用特定数据。验证或授权提供者可负责分配和管理UCAF控制字节的值、以及UCAF应用特定数据的结构。
一示例性控制字节定义可如下使用用于第一和后续交易的3-D安全SPA AAV。
Base 64编码值j十六进制值 x’8C’另一示例性控制字节定义可如下使用用于尝试的3-D安全SPA AAV。
Base 64编码值j十六进制值 x’86’在常规的UCAF实现中，应用特定数据可被定义为具有最大长度为24个二进制字节(包括控制字节)的二进制数据。然而，一些交易授权网络限制二进制数据在授权信息中的传送。因此，由验证程序1000中的SPA 135产生的全部UCAF数据可在包括到授权消息中之前进行Base 64编码。Base 64编码产生相关联二进制数据的字符表示。得到的字符表示约比二进制的大1/3。因此，UCAF字段一般可用最大长度为32个字符进行定义。然而，为了与验证程序1000中的3-D安全消息通信兼容，UCAF字段在长度上被限制为28个字符。
帐户持有人验证值(AAV)是与结合SPA的发卡机构验证平台相关的UCAF的特定实现。AAV可由发卡机构产生，并在持卡人由发卡机构成功验证之后提供给商家用来置入(给收单银行的)交易授权请求。在退款或其它可能纠纷处理的情形中，AAV可用来标识与交易相关联的处理参数。UCAF是用于在授权过程期间为验证目的将AAV从商家传送给发卡结构的机制。
再参看图1，商家需求层110相关于商家与其它层和持卡人交互的能力。参与验证程序1000的商家可实现能处理3-D安全消息的应用软件能力(例如商家插件(MPI))。MPI可用作处理3-D安全消息的控制应用程序。
包括本发明SPA 135的验证层130表示用于校验持卡人帐户所有权的验证过程或服务(例如由发卡机构提供或签约的)。使用例如访问控制服务器(ACS)的发卡机构可结合AAV确认服务器/过程，来实现验证层130/SPA 135。
为进行说明，涉及验证过程的示例性电子商务网络组件或实体可组织为如表格2所示属于发卡机构、收单银行或互操作性域。
表格2
参照表格2，在发卡机构域中提供的功能包括持卡人浏览器，它可作为用于在(收单银行域中的)MPI和(发卡机构域中的)访问控制服务器之间传送消息的通道。例如，相关持卡人软件可包括支持智能卡使用的可任选软件。登记服务器便于为验证程序1000下发卡机构的3-D安全实现所作的持卡人登记过程。服务器可用来执行初始持卡人验证，以及诸如重置及查看3-D安全支付历史这样的管理动作。
访问控制服务器于在线购买期间提供至少两个基本功能。第一，ACS将校验给定持卡人帐号是否在程序1000中登记。第二，ACS将进行用于持卡人标识的验证过程。为此，ACS可连同AAV确认服务器/过程运行，或包括AAV确认服务器/过程。该AAV确认服务器/过程还用来确认从商家或收单银行接受的持卡人的验证数据。
收单银行域中的功能可包括商家插件(MPI)和签名确认服务器的功能。MPI可创建并处理支付者验证消息，然后向商家软件返回控制用于进一步授权处理。MPI验证处理可在持卡人提交包括用于支付的帐号的购买请求之后、但在获得购买授权之前调用。签名确认服务器可用来确认对已由发卡机构成功验证的购买请求的数字签名。
互操作性域中的功能可包括目录服务器。目录服务器可以是全球目录服务器，它向在验证程序1000登记的商家提供集中式决策能力。基于商家校验请求消息中包含的帐号，目录首先可确定该帐号是否是参与发卡机构的卡范围的一部分。然后它将入选的请求导向适当发卡机构的ACS，用于进行进一步的处理。互操作性域还可包括适当的证书授权机构，用于在所有三个域上按需产生全部专用的分层终端实体和子证书、并将其分发给各个组件和其它子证书授权机构。
程序1000中的持卡人验证过程涉及在三个域上交换消息和数据。在验证过程中可逐步骤地使用以下示例性3-D安全域间消息(1)校验请求/响应消息对VEReq/VERes验证过程中的第一个步骤是检查或确认持卡人帐号是参与验证程序1000的发卡机构的卡范围的一部分。为此，校验请求消息VEReq从MPI发送给目录以检查卡范围的可入选性。如果指定卡号包含在目录中入选的卡范围内，则该消息可从目录转发给发卡机构的ACS，以进一步检查指定帐号是否由作为程序100的参与者的发卡机构登记或激活。
MPI可具有本地缓存每个参与发卡机构的卡范围的可任选能力。在这些情形中，卡范围请求/响应消息可由MPI用来请求来自目录的对卡范围高速缓存的更新。对于高速缓存卡范围的商家，如果本地高速缓存指示发卡机构并未在验证程序1000中登记，则不可使用VEReq/VERes消息。
(2)支付者验证请求/响应消息对PAReq/PARes一旦确定持卡人已由发卡机构登记，或者是程序1000中的活动参与者，则验证特定持卡人的过程还涉及特定的发卡机构。支付者验证请求/响应消息可从MPI发送给特定的发卡机构的ACS以执行验证。在程序1000的该验证过程阶段中，可向持卡人呈现验证窗口。验证窗口可在持卡人浏览器上显示，并由发卡机构以相关信息填充之。可请求持卡人通过所显示的验证窗口输入用于个人标识或验证的密码、代码或令牌。然后特定发卡机构的ACS可使用例如SPA 135来验证所搜集或所输入的信息，并因此产生帐户持有人的验证值(AAV)。AAV在UCAF中指定的持卡人验证校验值(CAAV)字段的3-D安全PARes(支付者验证响应)中传送。
CAAV是由发卡机构返回给请求商家的消息对PAReq/PARes的响应部分中的数据字段之一。发卡机构可将适当的数字签名置于其响应之上。商家还可包括将所接收的AAV发送给收单银行，用于转发给作为支付/交易授权请求的一部分的发卡机构(参见例如图4)。
图3示意地示出验证程序1000下持卡人交易的示例性卡验证过程300。为进行说明，对过程300的描述假设持卡人310由发卡机构在验证程序1000中登记，并从发卡机构获得密码或代码，以在网上购物时在参与商家处使用。过程300还假设各组件(例如持卡人310、MPI 320、目录330和发卡机构ACS 340)之间的全部通信信道使用安全套接字协议层(SSL)链接(例如SSL-1、SSL-2、SSL-3、SSL-4、SSL-5和SSL-6)来适当保护。
在过程300的步骤351，持卡人310可在商家网站上购物，并且在准备结账时，通过链接SSL-1输入支付卡系信息(例如帐号)和其它信息(例如送货信息)。一旦输入了全部的支付和送货信息，商家可给予持卡人310在提交订单之前检查该购买的机会。
然后在步骤352，MPI 320通过链接SSL-2查询目录330，以使用校验请求消息VEReq来校验持卡人310向特定发卡机构的登记。步骤352可通过本地卡的目录高速缓存在MPI 320上本地执行。响应于VEReq消息，目录330可确定特定发卡机构正在参与，因此通过链接SSL-3向该特定发卡机构的ACS 340转发对检查持卡人310的当前登记状态的请求。结果响应可经相同链接(例如SSL-3和SSL-2)流回MPI 320。如果ACS 340指示持卡人310在程序1000中登记，则MPI 320在步骤354上可创建支付者验证请求消息，并通过链接SSL-4将其发送给持卡人的浏览器。然后在步骤355，持卡人的浏览器可将该消息再次导向适当发卡机构的ACS 340，以启动持卡人验证。当ACS 340接收支付者验证请求消息时，它可使用户验证对话开始。作为用户验证对话的一部分，ACS 340可使单个交互式验证窗口向持卡人310显示，以便于持卡人310输入密码、代码或其它数据。
在步骤356，ACS 340(使用SPA 135)可验证由持卡人310输入的密码或代码。ACS 340可根据验证程序提供者的3D安全实现，来构建SPAAAV。ACS 340可建立适当的支付者验证响应消息，并对其进行数字签名。然后支付者验证响应消息(通过链接SSL-6)被返回给MPI 320。显示给持卡人320的验证窗口此时可消失。
当持卡人验证过程300完成时，商家可能需要通过授权消息内的UCAF字段向收单银行传送所接收的SPA AAV。然后SPA AAV可从收单银行传送给发卡机构，作为常规授权消息处理的一部分。当由发卡机构接收时，AAV可被确认为授权请求处理的一部分，并存档用于解决后来可能产生的任何持卡人纠纷。
标准的3-D安全版本1.0.2消息格式和数据格式可用于参与各方或各实体之间的所有数据通信。具体地，ACS 340创建并返回给商家的包括在UCAF消息中的SPAAAV是28字符长，并包含用Base 64编码的为3-D安全定义的20-字节字段。
表格3示出20-字节SPA AAV的示例性数据结构或格式。
除3-D安全方案之外提供现有PC标识或其它验证方案(例如图1)的发卡机构可区分它们从不同验证方案接收的相应授权消息中的AAV值。从3-D安全兼容程序1000产生的20-字节AAV(例如表格2)可与普通的28-字节AAV结构(例如在非3-D安全程序中)有以下不同交易金额和货币代码并不包括在20-字节AAV中，因为该信息包括在签名后的PARes消息中；并不包括商家交易标签(MTS)，因为包括在签名后PARes消息中的交易标识符(XID)可提供相同的功能。此外，商家名称字段的散列可得到扩展。结果，在创建SHA-1散列之前只需要对商家名称进行最少的编辑。
商家可能不必更改控制字节用于后续授权(例如分开送货)。对于分开送货，商家可再次发送通过程序1000的3-D安全兼容实现产生的原始AAV。
20-字节SPA AAV中的控制字节值基于持卡人验证请求(PAReq)的结果。该结果可在支付者验证响应(PARes)消息的交易状态字段中表示。表格4示出PARes消息中交易状态字段的示例值。
表格4
PAReq消息中包含的商家名称可在创建商家名称散列之前进行编辑。这些编辑可具体地进行通用转换格式(UTF-8)编码，但仍然引用其它编码类型的Unicode字符。
编辑可删除不具有Unicode表示的任何UTF-8字节序列。这种编辑可删除以二进制数1111开始且所有后续字节以二进制数10开始的任何UTF-8字节。
另一编辑可删除任何UTF-8字节序列或具有以下Unicode表示的字节序列0000～001F(ASCI控制字符)；007F～00A0(DEL和C1控制字符)；00AD(软连字号)；以及2000～206F(一般标点符号)。
这种编辑可删除以下UTF-8字节Hex 00～IFHex 7FHex C2 80～C2 A0Hex C2 ADHex E2 80～E2 81 AF又一种编辑可删除任何前导或结尾空格(例如UTF-8字节Hex 20)。
在退款或其它可能纠纷处理的情形中，20-字节的AAV可用来标识与该交易相关联的处理参数。其中，AAV字段值可标识·处理交易的物理位置·可用来在该位置的全部交易中肯定地标识该交易的序列号·用来创建MAC的秘密密钥，它不仅确保AAV数据的完整性，而且将整个AAV结构绑定到用于实现3-D安全的特定PAN。
AAV中的字段依存关系可建立以确保处理参数的正常标识。这些字段依存关系可在建立或配置发卡机构ACS安装时考虑。对于用同一ACS标识符配置的每个ACS·BIN密钥标识符字段对所标识ACS处理的每个BIN范围都必须是唯一的。大多数发卡机构可将密钥的公共集合用于大多数或全部其BIN范围。然而，该配置允许在选择所支持的软件提供者或需要使用单独密钥集的发卡机构时的灵活性。
·交易序列号字段必须对退款发生时段内由所标识ACS产生的每个AAV是唯一的。
有能力在多个逻辑安装或物理机器上共享BIN密钥和公共的交易序列号集的ACS安装，可有利地配置成使用同一ACS标识符。或者，对于每个安装，都需要独立的ACS标识符或ACS标识符集。在一个ACS工具服务多个发卡机构的情形中，一个以上的发卡机构可共享一个ACS标识符。在这些情形中，用于相关联交易的BIN字段值可变成解释字段内容位置的决定因素。
特定算法可在SPA 135中使用，以创建商家验证代码(MAC)值。例如，“HMAC”算法或“CVC2”算法可由ACS标识符子字段所标识的ACS使用，以创建MAC值。
HMAC算法基于由BIN密钥标识符子字段标识的秘密密钥，通过密码学方法产生MAC值。该秘密密钥与发卡机构共享，并通过以下数据的串联将持卡人帐号绑定到AAV·帐号，由ACS在对应于当前支付者验证请求(PAReq)消息的校验请求(VEReq)消息中接收。该帐号可表示为二进制编码的十进制数，左对齐并在右边用十六进制的‘F’填充至20位长度(一共10个字节)。
·构建AAV的最左边15个字节，字段1～6秘密密钥长度可任选地选择，最小为128比特(16个字节)，最大为192比特(24个字节)。之间的任何密钥尺寸(例如160比特)都是可接受的。所使用的实际密钥长度尺寸可通过每次实现来独立地选择。为3-D安全验证程序(例如程序1000)定义的SPAAAV中的MAC字段可用通过应用算法HMAC获得的密码学结果的最左边40个比特(5个二进制字节)来填充。
示例1和2示出分别使用20个字节和16个字节密钥来产生SPA AAV值的HMAC算法的应用。
示例1(20字节密钥)假设帐号5432 109876543210假设商家名称SPA Merchant，Inc.(全部是ASCII字符，不需要编辑)假设AAV控制字节＝8C商家名称的前8个字节，SHA-1散列＝7CA7 FBB6 058B 5114假设ACS Id＝01假设验证方法＝1(密码)假设BIN密钥Id＝I假设交易序列号＝0000002F假设密钥(20字节)＝OBOBOBOBOBOBOBOBOBOBOBOBOBOBOBOBOBOBOBOB因此SHA-1HMAC基于5432 109876543210 FFFF 8C 7CA7FBB6058B51140111 0000002F。
这产生前5个字节为3547 BAIE FF的MAC。
因此，16进制的完整AAV是8C 7CA7FBB6058B5114 0111 0000002F 3547BAIEFF。
在Base-64编码之后，为jHyn+7YFiIEUAREAAAAvNUe6Hv8＝。
示例2(16字节密钥)
假设帐号5432 109876543210假设商家名称SPA Merchant，Inc.(全部是ASCII字符，不需要编辑)假设AAV控制字节＝8C商家名称的前8个字节，SHA-1散列＝7CA7 FBB6 058B 5114假设ACS Id＝01假设验证方法＝1(密码)假设BIN密钥Id＝1假设交易序列号＝0000002F假设密钥(16字节)＝00112233445566778899AABBCCDDEEFF因此SHA-1HMAC基于5432 109876543210 FFFF 8C 7CA7FBB6058B5114 0111 0000002F。
这产生前5个字节为EB27 FC7F AB的MAC。
因此，16进制的完整AAV是8C 7CA7FBB6058B5114 0111 0000002F EB27FC7FAB。
Base-64编码之后，为jHyn+7YFil EUAREAAAA v6yf8f6s＝。
CVC2算法还用密码学方法创建了MAC字段值。与使用一个密钥的HMAC算法相反，CVC2算法使用由BIN密钥标识符子字段标识的两个64比特的DES密钥。在CVC2算法中，全部加密和解密步骤都可使用DES的电子密码本(ECB)形式。
CVC2算法产生三位的CVC2值。用于产生该三位CVC2值的CVC2算法处理的输入数据在表格5中示出。
表格5
所得到的三位CVC2值被转换成二进制编码的十进数形式，并在MAC子字段的最左边两个字节中填充前导二进制零，这些零用来填充第一个未使用的半字节。MAC子字段的剩余三个字节可用二进制零来填充。例如CVC2＝123 MAC子字段＝0123000000(一共10位)。
示例3和表格6示出CVC2算法的应用，以及产生SPA AAV值的算法应用中所涉及的处理步骤。
示例3假设帐号5432109876543210假设商家名称SPA Merchant，Inc.(全部是ASCII字符，不需要编辑)假设AAV控制字节＝8C商家名称的前8个字节，SHA-1散列＝7CA7 FBB6 058B 5114假设ACS Id＝7假设验证方法＝1(密码)假设BIN密钥Id＝1假设交易序列号＝0000002F密钥A＝0011223344556677，密钥B＝8899AABBCCDDEEFF因此，CVC2算法计算基于帐号＝5432109876543210，到期日＝0047服务代码＝140这产生CVC2的3位值为439(计算参见表格6)。
基于所计算的CVC2值，MAC字段＝0439000000因此，16进制的完整AAV是8C 7CA7FBB6058B5114 01 11 0000002F 0439000000。
Base-64编码之后，为jHyn+7YFil EUAREAAAAvBDkAAAA＝。
示例3中使用的处理或计算步骤在表格6中示出。
表格6
如3-D安全协议所定义，所有返回给商家的PARes消息由相关联持卡人的发卡机构ACS数字签名。商家可被要求在从包括在发送给收单银行的授权请求中提取SPA AAV之前确认数字签名。如果发卡机构支持3-D安全和其它验证平台(例如PC验证平台)的实现，则在处理授权请求消息的处理期间有必要区分两个验证平台。这可用两种方法之一来完成1.第一个经Base 64编码的字符是a.3-D安全的定义实现内SPAAAV的“j”或“h”b.PC验证SPA AAV的“g”或“A”2.转换成二进制的控制字节，是a.对为3-D安全的MasterCard实现定义的AAV，为十六进制8C或十六进制86b.对PC验证SPAAAV，为十六进制82或十六进制02参与程序1000的每个发卡机构可确保ACS标识符子字段被适当设置成指示用来创建MAC的算法。未能正确设置该指示符将导致交易/支付授权过程期间的失败确认。
尽管本发明已结合特定示例性实施例进行了描述，应理解对公开实施例可作本领域技术人员显而易见的各种改变、替换和更改，而不背离本发明的精神和范围。
权利要求
1.一种用于验证持卡人与商家在电子网络上的交易的系统，所述系统包括发卡机构平台层，包括至少一个3-D安全验证程序；商家插件(MPI)；安全支付算法(SPA)；以及数据传输层，其中所述发卡机构平台包括访问控制服务器(ACS)，所述ACS使用SPA来处理交易和持卡人信息以通过验证方法进行验证，并产生帐户持有人验证值(AAV)，并且通过数据传输层将所述AAV传送到所述MPI，其中所述AAV是与3-D安全消息协议兼容的格式化数据结构，其中该格式化数据结构具有最多20个字节的长度，包括标识商家名称散列的字节、标识ACS的字节、标识验证方法的字节、标识秘密密钥的字节、以及包括商家验证代码(MAC)的字节。
2.如权利要求1所述的系统，其特征在于，所述AAV是经Base 64编码的格式化数据结构。
3.如权利要求1所述的系统，其特征在于，所述SPA包括用于产生所述MAC的加密算法，其中所述加密算法使用在AAV中标识的一个秘密密钥来加密持卡人帐号和AAV中除表示MAC的字节之外的各个字节的多个字段的串联，且其中加密结果的一部分形成AAV中的MAC字节。
4.如权利要求1所述的系统，其特征在于，所述SPA包括用于产生所述MAC的加密算法，其中所述加密算法使用在AAV中标识的一对秘密密钥A和B来加密持卡人帐号、卡到期日和服务代码的串联，来产生一个三位CVC2字段，并使用所得结果来填充MAC的两个字节。
5.如权利要求4所述的系统，其特征在于，所述一对密钥A和B是64比特的数据加密标准(DES)密钥。
6.如权利要求1所述的系统，其特征在于，所述ACS被配置成响应于从所述MPI到所述ACS的支付验证请求消息来产生AAV。
7.如权利要求1所述的系统，其特征在于，被配置成在来自ACS的支付验证响应消息中传输AAV。
8.如权利要求7所述的系统，其特征在于，所述ACS还被配置成将数字签名置入所述支付验证响应消息。
9.如权利要求1所述的系统，其特征在于，所述MPI被配置成校验所接收的支付验证响应消息上的数字签名。
10.如权利要求1所述的系统，其特征在于，所述MPI被配置成提取包括在来自ACS的支付验证响应消息中的MAC字段，并将所提取的MAC置入传送给第三方的支付授权请求消息。
11.一种用于在3-D安全环境中的风险承担者之间传送持卡人交易验证信息的数据结构，所述数据结构包括经Base 64编码的20个字节的字符，其中第一个字节是控制字节，字节2-9表示商家名称的散列，字节10标识通过验证方法验证持卡人交易的访问控制服务器(ACS)，字节11标识验证方法和由ACS用来产生商家验证代码(MAC)的秘密加密密钥，字节12-15表示用于标识由ACS处理的交易号的交易序列号，而字节16-20表示MAC。
12.如权利要求11所述的数据结构，其特征在于，所述MAC包括持卡人帐号和所述数据结构的1-15字节的多个字段的串联的加密的各个部分，且其中在字节11标识的单个密钥用于加密。
13.如权利要求11所述的数据结构，其特征在于，所述MAC包括持卡人帐号、卡到期日和服务代码的串联的加密的各个部分，且其中在字节11标识的一对密钥A和B用于加密。
14.如权利要求13所述的数据结构，其特征在于，三位加密结果用来填充MAC字节16-20的两个字节。
15.如权利要求13所述的数据结构，其特征在于，所述一对秘密密钥A和B是64比特的数据加密标准(DES)密钥。
16.一种用于验证持卡人与商家在电子网络上的交易的方法，所述方法包括使用访问控制服务器(ACS)来处理持卡人和交易信息以通过验证方法验证持卡人；使用安全支付算法(SPA)来产生帐户持有人验证值(AAV)，以表示验证结果；以及在3-D安全消息中将所述AAV传送到所述商家，其中所述AAV是具有最多20个字节的长度、包括标识商家名称散列的字节、标识ACS的字节、标识验证方法的字节、包括商家验证代码(MAC)的字节、以及标识由所述SPA用来产生MAC的秘密密钥的字节的格式化数据结构。
17.如权利要求16所述的方法，其特征在于，所述AAV是经Base 64编码的格式化数据结构。
18.如权利要求16所述的方法，其特征在于，使用SPA包括使用在AAV中标识的一个秘密密钥来加密持卡人帐号和AAV中除表示MAC的字节之外的各个字节的至少一部分的串联；以及将加密结果的一部分分配给AAV中的MAC字节。
19.如权利要求16所述的方法，其特征在于，使用SPA包括使用在AAV中标识的一对秘密密钥A和B来加密持卡人帐号、卡到期日和服务代码的串联，来产生一个三位CVC2字段；以及分配所得结果来填充MAC的两个字节。
20.如权利要求17所述的方法，其特征在于，所述一对秘密密钥A和B是64比特的数据加密标准(DES)密钥。
21.如权利要求16所述的方法，其特征在于，在3-D安全消息中向商家传送AAV包括在由ACS数字签名的支付验证响应消息中传送AAV。
22.如权利要求21所述的方法，其特征在于，还包括首先，由商家校验所接收的支付验证响应消息上的数字签名；以及然后，从商家接收的支付验证响应消息中提取MAC字段。
全文摘要
提供了一种结构化数据结构，用于传送用来验证持卡人的在线交易的电子商务验证程序的结果。最长为20－字节的该数据结构被设计成与电子商务中使用的3－D安全消息协议兼容。该数据结构包括各个指定字段，这些字段包括商家名称的散列、标识验证服务提供者、标识所使用的验证方法、及包括使持卡人信息与交易相连的商家验证代码。提供安全的支付算法由电子商务验证程序使用，用于产生所需格式的验证结果。在一安全支付算法中，一密钥用来加密持卡人帐号与来自该数据结构各指定字段的信息的串联。在另一安全支付算法中，一对密钥用来加密持卡人帐号、卡到期日和服务代码的串联。在两种情形中，加密结果的各个部分都用来定义商家验证代码。
文档编号G06Q30/00GK1926567SQ200480020116
公开日2007年3月7日 申请日期2004年6月10日 优先权日2003年6月10日
发明者A·D·克兰兹雷, S·W·奥菲, B·J·鲁特福德, M·威斯曼 申请人:运通卡国际股份有限公司