CN101645890B - 验证信源完整性的方法、系统及相应设备 - Google Patents

Abstract

本发明的实施例公开了一种验证信源完整性的方法、系统及相应设备，涉及信源安全领域，解决了现有技术中由两方参与的信源完整性保护易被破解的技术问题。本发明实施例在请求用户端向接收服务器提交第一信源后，所述请求用户端接收到所述接收服务器发送的第一验证因子，并根据所述第一验证因子获取第一验证码；接收用户端从所述接收服务器获取第二验证信息；所述验证服务器接收所述接收用户端提交的第二验证信息，还接收所述请求用户端发来的第一验证码；并根据所述第一验证码和所述第二验证信息验证所述第一信源的完整性。本发明实施例主要应用在对信源的完整性保护方面。

Description

验证信源完整性的方法、系统及相应设备

技术领域

本发明涉及信源安全领域，尤其涉及一种验证信源完整性的方法、系统和及相应设备。 

背景技术

网络技术的发展使网络系统可提供各种应用服务，对于每种应用服务，网络系统都可能产生起信令作用的html(hyper text make-up language，超文本标识语言)文档。但是，即便是采用https(hyper text transfer protocol secure，安全超文本传输协议)的网络系统，也只能够保证用户端和网络端之间的信源传输的安全性，并不能够保证应用服务产生的html文档的完整性。例如，在转帐交易的应用服务中，若不能够验证转帐交易时应用服务产生的html文档的完整性，则将会给用户端在控制交易的过程中带来隐患。例如根据错误的html文档信息进行操作，导致交易业务无法正常进行等。 

在现有技术中，对于信息完整性的保护方法主要包括：由提供应用服务的网络系统，通常为网络侧主机先将公钥分发到用户端，再将经过私钥签名的信息发送到用户端，用户端在接收到信息后，根据该公钥对经过私钥签名的信息进行完整性验证。以便保证该信息没有在传输的过程中未被恶意篡改。 

但在实际操作中，上述方法对于信源信息完整性的保护还是存在一定缺陷的。例如：钓鱼网站仿制公钥，向用户端分发假公钥和用假私钥签名过的信源，使得用户端验证通过的信源是一条假信源。如此，同样可使得用户端根据该假信源进行操作，导致用户端无法正常工作，甚至影响网络系统，使应用服务无法正常进行，使用户蒙受到不必要的损失。 

发明内容

本发明的实施例提供一种验证信令完整性的方法和系统，提高对订单验证的可靠性，以便保证订单的完整性。 

为达到上述目的，本发明的实施例采用如下技术方案： 

一种验证订单完整性的方法，在请求用户端向接收服务器提交第一订单后，包括： 

所述请求用户端接收到所述接收服务器发送的第一验证因子，并根据所述第一验证因子获取第一验证码；所述第一验证因子包括：所述第一订单，所述接收服务器为所述第一订单分配的订单序列号，以及所述接收服务器存储的对应所述请求用户端的参数；所述请求用户端根据所述第一验证因子获取第一验证码包括：所述请求用户端根据所述第一验证因子中的参数和自身存储的来自密钥提供服务器的参数获取共享密钥，并用所述共享密钥加密第一验证因子的部分运算结果以获取第一验证码；所述第一验证因子的部分运算结果为对所述第一验证因子中的第一订单和订单序列号进行运算后得到的第一数字摘要； 

接收用户端从所述接收服务器获取第二验证信息； 

所述第二验证信息包括：第二验证码，第二订单，以及所述接收服务器为所述第一订单分配的订单序列号，其中，所述第二订单与所述第一订单拥有相同的订单序列号； 

验证服务器接收所述接收用户端提交的第二验证信息，还接收所述请 求用户端发来的第一验证码；所述验证服务器根据所述第一验证码获取第一数字摘要，具体包括：所述验证服务器根据所述第一验证码获取第一数字摘要的过程具体为：所述验证服务器存储有来自密钥提供服务器的对应所述请求用户端的参数；所述接收服务器存储有对应所述请求用户端的参数；所述验证服务器从所述接收服务器获取对应所述请求用户端的参数；所述验证服务器根据其存储的对应请求用户端的参数和所述来自接收服务器的对应请求用户端的参数获取共享密钥，并用所述共享密钥解密所述第一验证码获取第一数字摘要；所述验证服务器根据所述第二验证信息获取第二数字摘要和第三数字摘要，具体包括：所述验证服务器根据所述第二验证信息获取第二数字摘要和第三数字摘要包括：所述验证服务器存储有来自密钥提供服务器的对应所述请求用户端的参数；所述接收服务器存储有对应所述请求用户端的参数；所述验证服务器从所述接收服务器获取对应所述接收用户端的参数；所述验证服务器根据其存储的对应接收用户端的参数和所述来自接收服务器的对应接收用户端的参数获取共享密钥，并用所述共享密钥解密所述第二验证码获取第二数字摘要；所述验证服务器根据所述第二订单和所述订单序列号获取第三数字摘要； 

所述验证服务器判断所述第一数字摘要、所述第二数字摘要以及所述第三数字摘要是否一致；如果判定一致，则确定所述第一订单具备完整性；否则，提示出错信息； 

在请求用户端向接收服务器提交第一订单后，该方法还包括：所述接收服务器根据所述第一订单和所述订单序列号获取第二数字摘 要；所述接收服务器发送所述订单序列号到所述接收用户端；所述接收用户端存储有来自密钥提供服务器的参数； 

在所述接收用户端从所述接收服务器获取第二验证信息之前，该方法还包括：所述接收用户端提交第二验证因子到所述接收服务器，所述第二验证因子包括：所述订单序列号和所述接收用户端存储的参数；所述接收服务器存储有来自所述密钥提供服务器的对应所述接收用户端的参数；所述接收服务器根据所述第二验证因子和所述第二数字摘要获取第二验证码，包括：所述接收服务器根据所述第二验证因子中的订单序列号查找到所述第二订单和所述第二数字摘要；所述接收服务器根据所述第二验证因子中的参数和其存储的参数获取共享密钥，并用所述共享密钥对所述第二数字摘要加密获取第二验证码并发送包含所述第二验证码的第二验证信息到所述接收用户端。一种验证订单完整性的系统，包括： 

如权利要求1所述的请求用户端； 

如权利要求1所述的接收服务器； 

如权利要求1所述的接收用户端； 

如权利要求1所述的验证服务器； 

所述第一验证因子具体包括：所述第一订单，所述接收服务器为所述第一订单分配的订单序列号，以及所述接收服务器存储的对应请求用户端的参数； 

所述第二验证信息包括：第二验证码，第二订单，以及接收服务器为所述第一订单分配的订单序列号，其中所述第二订单与所述第一 订单拥有相同的订单序列号； 

所述第二验证因子包括：所述订单序列号和所述接收用户端存储的参数。 

本发明实施例提供的方案通过采用在用户端和接收服务器之间增加第三方验证环节的技术方案，解决了现有技术中仅需假冒接收服务器一方分发的公钥便可使用户端通过假订单的验证，从而导致用户端因遵从该假订单进行操作，引发的业务无法正常进行的技术问题，进而取得了提高对订单验证的可靠性，增强订单传递的完整性，从而保证了验证订单完整性的技术效果。 

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。 

图1为本发明实施例1验证信源完整性方法中消费者用户端提交订单阶段的流程图； 

图2为本发明实施例1验证信源完整性方法中商家用户端接收订单阶段的流程图； 

图3为本发明实施例1验证信源完整性方法中验证订单阶段的流程图； 

图4为本发明实施例2用户端400的结构示意图； 

图5为本发明实施例2接收服务器500的结构示意图； 

图6为本发明实施例2验证服务器600的结构示意图； 

图7为本发明实施例2密钥提供服务器700的结构示意图； 

图8为本发明实施例3验证信源完整性的系统800的结构示意图。 

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。并且，以下各实施例均为本发明的可选方案，实施例的排列顺序及实施例的编号与其优选执行顺序无关。 

实施例1 

本实施例具体结合在淘宝网上进行交易的场景下，当信源为订单时的一种验证信源完整性的方法。即：在本实施例中，提供一种验证订单完整性的方法。 

其中，在本实施例里，所述订单具体为一种html文档。 

请求用户端可具体为：消费者用户端，属于用户端； 

接收用户端可具体为：商家用户端，属于用户端； 

接收服务器具体为：用于展示各类商品信息、并接收消费者订单的订单接收服务器，属于淘宝网； 

验证服务器可具体为：用于作为第三方验证设备的订单验证服务器，属于网银； 

密钥提供服务器可具体为：交易支付平台系统的密钥提供服务器，属于网银。 

在本实施例中，整个方法的流程可主要分为四个阶段，包括：消费者用户端和商家用户端注册阶段，消费者用户端订单提交阶段，商家用户端订单接收阶段，订单的验证阶段。 

其中，在消费者用户端和商家用户端注册阶段主要包括： 

消费者用户端和商家用户端分别在交易支付平台系统注册，提交各自的用户信源，对于其中的任意一份用户信息，以消费者用户端提交的用户信息为例，交易支付平台系统的密钥提供服务器在接收到该用户信息后，生成共享密钥的三个参数，并将该共享密钥的三个参数分别分发到消费者用户端、订单接收服务器和订单验证服务器。该消费者用户端、该订单接收服务器和改订单验证服务器接收并存储各自的共享密钥的参数。 

同理，对应商家用户端提交的用户信息，交易支付平台系统的密钥提供服 务器在接收到该用户信息生成共享密钥的三个参数，并将该共享密钥的三个参数分别分发到商家用户端、订单接收服务器和订单验证服务器。该商家用户端、该订单接收服务器和订单验证服务器接收并存储各自的共享密钥的参数。 

本实施例中，对于任意一份来自用户端的用户信息，密钥提供服务器具体通过拉格朗日方程生成对应的共享密钥的三个参数，采用该方法的优点在于：消费者用户端、订单接收服务器和订单验证服务器中的任意一方获取对应三个参数中的任意两个，均可以计算出完整的共享密钥；同理，商家用户端、订单接收服务器和订单验证服务器中的任意一方获取对应三个参数中的任意两个，也均可以计算出完整的共享密钥。 

通过拉格朗日方程生成共享密钥的方法具体内容如下： 

struct shadow_struct{ 

    int    x； 

    unsigned  y； 

}； 

typedef struct shadow_struct shadow_type； 

int GFinv[257]＝ 

{0，1，129，86，193，103，43，147，225，200，180，187，150，178， 

202，120，241，121，100，230，90，49，222，190，75，72，89，238， 

101，195，60，199，249，148，189，235，50，132，115，145，45，163， 

153，6，111，40，95，175，166，21，36，126，173，97，119，243， 

179，248，226，61，30，59，228，102，253，87，74，234，223，149， 

246，181，25，169，66，24，186，247，201，244，151，165，210，96， 

205，127，3，65，184，26，20，209，176，152，216，46，83，53， 

139，135，18，28，63，5，215，164，177，245，188，224，250，44， 

218，116，124，38，113，134，159，54，15，17，158，140，114，220， 

51，85，255，2，172，206，37，143，117，99，240，242，203，98， 

    123，144，219，133，141，39，213，7，33，69，12，80，93，42， 

    252，194，229，239，122，118，204，174，211，41，105，81，48，237， 

    231，73，192，254，130，52，161，47，92，106，13，56，10，71， 

    233，191，88，232，76，11，108，34，23，183，170，4，155，29， 

    198，227，196，31，9，78，14，138，160，84，131，221，236，91， 

    82，162，217，146，251，104，94，212，112，142，125，207，22，68， 

    109，8，58，197，62，156，19，168，185，182，67，35，208，167， 

    27，157，136，16，137，55，79，107，70，77，57，32，110，214， 

    154，64，171，128，256 

}； 

long int GFpow(x，y) 

long int x，y； 

{ 

   long int    i，z； 

      z＝1； 

   if(y！＝0){ 

     for(i＝1；i＜＝y；i++){ 

      z*＝x； 

      if(z＞＝257)z％＝257； 

      } 

   }/*end if*/ 

   return z； 

} 

long int solve_system(long int**a，long int n) 

{ 

   long int eqn，var，inv，i； 

   for(eqn＝n；eqn＞＝0；eqn--){/*Eliminate orders from highest down*/ 

       inv＝GFinv[a[eqn][eqn]]； 

      for(var＝0；var＜＝eqn；var++){/*mult row by inv*/ 

       a[eqn][var]＝(a[eqn][var]*inv)％257； 

      } 

      a[eqn][n+1]＝(a[eqn][n+1]*inv)％257； 

      for(i＝0；i＜eqn；i++){/*eliminate variable from all lower equations*/ 

       a[i][n+1]＝(a[i][n+1]-(a[eqn][n+1]*a[i][eqn])％257+257)％257； 

       for(var＝0；var＜＝eqn；var++){ 

         a[i][var]＝(a[i][var]-(a[eqn][var]*a[i][eqn])％257+257)％257； 

        } 

      } 

    } 

    return a[0][n+1]； 

} 

shadow_type*make_shadow(n，m，sec) 

long int n，m，sec； 

{ 

    long int i，j； 

    shadow_type*s； 

    unsigned coef； 

    s＝(shadow_type*)malloc((m*sizeof(shadow_type)))； 

    if(s＝＝NULL){ 

      printf(″Could not allocate memory for shadows\n″)； 

      exit(0)； 

    } 

    for(j＝1；j＜＝m；j++){ 

      s[j-1].y＝sec；/*initialize shadows with secret*/ 

      s[j-1].x＝j； 

    } 

    for(i＝1；i＜n；i++){/*create the polynomial x...x^(n-1)*/ 

     coef＝prand(1)％257； 

     for(j＝1；j＜＝m；j++){/*calculate the shadows*/ 

        s[j-1].y＝(s[j-1].y+(coef*GFpow(j，i)))％257；/*add in orders*/ 

      } 

    } 

    return(s)； 

} 

long int combine_shadows(n，s) 

long int n； 

shadow_type*s； 

{ 

    long int i，j，**a； 

    a＝make_matrix(0L，n-1，0L，n)； 

    if(a＝＝NULL)exit(0)； 

    for(i＝0；i＜n；i++){/*by rows*/ 

      a[i][n]＝s[i].y； 

      a[i][0]＝1； 

      for(j＝1；j＜n；j++){/*collomns in row i*/ 

         a[i][j]＝GFpow(s[i].x，j)； 

      } 

     } 

  return solve_system(a，n-1)； 

} 

在本实施例中，设密钥提供服务器与消费者用户端之间的共享密钥为KeyC，其中，消费者用户端持有的参数记作KeyC1，存储在订单接收服务器的参数记作KeyC2，存储在订单验证服务器的参数记作KeyC3。 

设密钥提供服务器与商家用户端之间的共享密钥为KeyB，其中，商家用户 端持有的参数记作KeyB1，存储在订单接收服务器的参数记作KeyB2，存储在订单验证服务器的参数记作KeyB3。 

在该方法中，如图1所示为本发明实施例提供的方法中的消费者用户端提交订单阶段流程图，包括： 

步骤101：消费者用户端登录交易支付平台系统，填写订单页面，生成订单，设该订单为D，并提交D到订单接收服务器。 

步骤102：订单接收服务器接收到D，为D分配唯一的序列号SN(D)，根据D和SN(D)计算数字摘要H0(D)，并将包含D、SN(D)和其存储的KeyC2的第一验证因子发送到消费者用户端。 

其中，步骤102还包括：订单接收服务器在为D分配了SN(D)后，发送SN(D)到商家用户端，该商家用户端在登陆后，便可获取该SN(D)。 

步骤103：消费者用户端接收到包含D、SN(D)和KeyC2的第一验证因子，根据D和SN(D)计算数字摘要H1(D)，根据KeyC1和KeyC2计算得到KeyC，用KeyC对H1(D)加密得到验证码EH1(D)，并将该EH1(D)发送到订单接收服务器。 

步骤104：订单接收服务器保存D，H0(D)和EH1(D)，等待商家查询时，供商家下载。 

如图2所示为本发明实施例提供的方法中的商家用户端订单接收阶段流程图，包括： 

步骤201：商家用户端登陆交易支付平台系统，并向订单接收服务器提交包含获取的SN(D)和其持有的KeyB1的第二验证因子，请求下载D； 

步骤202：订单接收服务器根据SN(D)检索得到订单D’和摘要H0(D)。 

步骤203：订单接收服务器根据KeyB1和自身存储的KeyB2计算出KeyB， 并用KeyB对H0(D)进行加密，从而得到验证码EH0(D)。 

步骤203：订单接收服务器将包含D’、SN(D)和EH0(D)的第二验证信息发送到该商家用户端。 

如图3所示为本发明实施例提供的方法中的订单验证阶段流程图，包括： 

步骤301：订单验证服务器分别接收到来自上述消费者用户端的EH1(D)，和来自商家用户端的包含SN(D)、D’和EH0(D)的第二验证信息。 

步骤302：订单验证服务器从订单接收服务器获取其存储的对应消费者用户端的KeyC2和对应商家用户端的KeyB2。 

步骤303：订单验证服务器根据KeyB2和自身存储的KeyB3计算出KeyB，并用KeyB解密EH0(D)得到H0(D)；同理，订单验证服务器根据KeyC2和自身存储的KeyC3计算出KeyC；并用KeyC解密EH1(D)得到H1(D)；并且订单验证服务器还根据D’和SN(D)计算得到H2(D)。 

步骤304：判断H0(D)、H1(D)和H2(D)是否一致，如果判定一致，则确定D具备完整性，即该订单有效。因为当判定一致时，则代表D与D’为同一份订单，即是也说明D未被篡改，此时，商家用户端可根据所述订单进行操作；否则，提示出错信息。 

此外，在本实施例所提供的方案中，从步骤301可以看出D’、SN(D)、EH0(D)是订单服务器从商家用户端获取的，EH1(D)是订单服务器从消费者用户端获取的，如果判定H0(D)、H1(D)和H2(D)三者不一致，则订单验证服务器还可从订单接收服务器获取D’、SN(D)、EH0(D)以及EH1(D)，进行进一步的解密和比对，以便确定到底是消费者用户端，还是商家的环节出了问题。 

优选地，本发明实施例中，消费者用户端和密钥提供服务器之间的共享密钥KeyC可以经常变换。在每一次消费者用户端和密钥提供服务器之间的共享密钥发生变化时，密钥提供服务器都会生成三个更新后的参数，并将该更新后的三个参数分别分发给消费者用户端、订单接收服务器和订单验证服务器。上述消费者用户端、上述订单接收服务器和上述订单验证服务器接收到各自的参数后，分别用该新接收到的参数更新已存储的对应参数。 

同样地，本发明实施例中，商家用户端和密钥提供服务器之间的共享密钥KeyB也可以经常变换。在每一次商家用户端和密钥提供服务器之间的共享密钥变化时，密钥提供服务器同样会生成三个更新后的参数，并同样将该更新后的三个参数分别发放到商家用户端、订单接收服务器和订单验证服务器。上述消费者用户端、上述订单接收服务器和上述订单验证服务器接收到各自的参数后，分别用该新接收到的参数更新已存储的对应参数。同理，当商家用户端和密钥提供服务器之间的共享密钥变化时，密钥提供服务器同样会生成三个更新后的参数，并同样将该更新后的三个参数分别发放到消费者用户端、订单接收服务器和订单验证服务器。 

在现有技术中，验证订单的完整性的方法仅涉及用户端和订单接收服务器两方，由此导致了钓鱼网站等冒充订单接收服务器向用户端发放假公钥和假订单的技术问题，而本发明实施例通过采用在用户端和订单接收服务器之间引入第三方验证环节的技术方案，解决了现有技术中的验证信源完整性时仅需一方的密钥的技术问题，进而取得了提高对信源验证的可靠性，增加信源传递的完整性的技术效果。 

实施例2 

本实施例具体提供一种客户端主机400，该客户端主机即可作为实施例1方 法中消费者用户端，也可以作为实施例1方法中商家用户端。如图4所示，该客户端主机400包括：信源发送模块41，第一提交模块42，因子发送模块43，第二提交模块44。 

信源发送模块41，用于向接收服务器发送第一信源；第一提交模块42，用于在信源发送模块41发送第一信源后，接收所述接收服务器发送的第一验证因子，并向验证服务器提交根据所述第一验证因子获取的第一验证码；因子发送模块43，用于发送第二验证因子到所述接收服务器；第二提交模块44，用于在因子发送模块43发送第二验证因子后，从所述接收服务器获取第二验证信息，并提交所述第二验证信息到所述验证服务器。 

其中，第一提交模块42包括：获取单元421。获取单元421，用于根据所述第一验证因子获取第一验证码。 

进一步，在本实施例中还包括如下可选模块：注册模块45，存储模块46，更新接收模块47，更新模块48。 

注册模块45用于在密钥提供服务器进行注册，并提交用户信息到所述密钥提供服务器；存储模块46用于在注册模块45注册时，接收并存储来自密钥提供服务器的至少一个共享密钥的参数，所述至少一个共享密钥的参数包括对应客户端主机作为消费者用户端时的参数，和/或对应客户端主机作为商家用户端时的参数。 

更新接收模块47，用于接收到来自所述密钥提供服务器的更新后的共享密钥的参数；更新模块48，用于用更新接收模块47接收到的共享密钥的参数对应替换参数存储模块46已存储的共享密钥的参数。 

在本实施例中的第一提交模块42接收到的第一验证因子包括：所述第一信源，信源序列号，以及所述接收服务器存储的对应请求用户端的参数； 

因子发送模块43发送的所述第二验证因子包括：存储模块46存储的参数和所述信源序列号。 

本实施例继续提供一种接收服务器500，以便实施例1方法中涉及订单接收服务器的方法的部署。如图5所示，该接收服务器500包括：信源接收模块51，第一发送模块52，因子接收模块53，第二发送模块54。 

信源接收模块51，用于接收请求用户端提交的第一信源；第一发送模块52，用于发送第一验证因子到所述请求用户端；因子接收模块53，用于接收用户端提交第二验证因子；第二发送模块54，用于发送第二验证信息到接收用户端。 

其中，因子接收模块53接收到的所述第二验证因子包括：所述信源序列号和所述接收用户端存储的参数。 

进一步，在本实施例中接收服务器500还可包括如下模块：存储模块55，分配模块56，第二摘要获取模块57，第二验证码获取模块58，更新接收模块59，更新模块510。 

存储模块55，用于接收并存储来自密钥提供服务器的对应各个用户端的参数，所述参数至少包括对应所述请求用户端的参数和对应所述接收用户端的参数。 

分配模块56，用于为信源接收模块51接收到的所述第一信源分配信源序列号。在分配模块56分配信源序列号后，第一发送模块52发送所述第一验证因子到请求用户端，所述第一验证因子包括所述第一信源，所述信源序列号，以及所述存储模块存储的对应请求用户端的参数。并且，第一发送模块52还用于将分配模块56分配的信源序列号发送到所述接收用户端。 

第二摘要获取模块57，用于根据信源接收模块51接收到的第一信源和分配模块56分配的信源序列号获取第二数字摘要；第二验证码获取模块58，用于根据所述第二验证因子和所述第二数字摘要获取第二验证码。 

更新接收模块511用于接收到来自所述密钥提供服务器的更新后的共享密 钥的参数；更新模块512，用于用更新接收模块511接收到的参数对应替换存储模块55已存储的参数。 

在本实施例中，第二验证码获取模块58包括：信源查找单元581，第二验证码获取单元582。 

信源查找单元581，用于根据所述第二验证因子中的信源序列号查找第二信源和所述第二数字摘要，其中，所述第二信源与所述第一信源拥有相同的信源序列号； 

第二验证码获取单元582，用于根据所述第二验证因子中的参数和存储模块55存储的参数获取共享密钥，并用所述共享密钥对所述第二数字摘要加密获取第二验证码。 

具体地，第二发送模块54发送第二验证信息包括：第二验证码获取模块58获取的所述第二验证码，信源查找单元581查找到的所述第二信源，以及因子接收模块53接收到的所述信源序列号。 

本实施例继续提供一种验证服务器600，以便实施例1中涉及订单验证服务器的方法的部署，如图6所示，包括：第一接收模块61，第二接收模块62，验证模块63。 

第一接收模块61，用于接收来自请求用户端的第一验证码；第二接收模块62，用于接收来自接收用户端的第二验证信息；验证模块63，用于根据所述第一验证码以及所述第二验证信息验证所述第一信源的完整性。。 

其中，第二接收模块62接收的第二验证信息具体包括第二验证码、第二信源，和信源序列号，需要说明的是：所述第二信源的序列号为所述信源序列号。 

进一步，在本实施例中的验证服务器600还可包括如下可选模块：存储模块64，更新接收模块65，更新模块66。 

存储模块64，用于接收并存储来自密钥提供服务器的对应各个用户端的参数，所述参数至少包括对应所述消费者用户端的参数和对应所述商家用户端的 参数。 

更新接收模块65，用于接收到来自所述密钥提供服务器的更新后的共享密钥的参数；更新模块66，用于用更新接收模块65接收到的参数对应替换存储模块64已存储的参数。 

具体的，验证模块63包括：摘要获取单元631，确定单元632。 

摘要获取单元631，用于根据所述第一验证码获取第一数字摘要，根据所述第二验证信息获取第二数字摘要和第三数字摘要；确定单元632，用于判断所述第一数字摘要、所述第二数字摘要以及所述第三数字摘要是否皆一致；如果判定一致，则确定所述第一信源具备完整性；否则，提示出错信息。 

进一步的，在本实施例中，摘要获取单元631包括：参数获取子单元6311，第一摘要获取子单元6312，第二摘要获取子单元6313，第三摘要获取子单元6314。 

参数获取子单元6311，用于从所述接收服务器获取对应所述请求用户端的参数和对应所述接收用户端的参数；第一摘要获取子单元6312，用于根据存储模块64存储的对应请求用户端的参数和所述来自接收服务器的对应请求用户端的参数获取共享密钥，并用所述共享密钥解密所述第一验证码获取第一数字摘要；第二摘要获取子单元6313，用于根据存储模块64存储的对应接收用户端的参数和所述来自接收服务器的对应接收用户端的参数获取共享密钥，并用所述共享密钥解密所述第二验证码进获取第二数字摘要；第三摘要获取子单元6314，用于根据所述第二信源和所述信源序列号获取第三数字摘要。 

本实施例再继续提供一种密钥提供服务器700，以便实施例1中涉及交易支付平台系统中的密钥提供服务器的方法的部署。如图7所示，包括：生成模块71，分发模块72。 

生成模块71用于在用户端注册时，生成共享密钥的三个参数；分发模块72 用于将生成的共享密钥的三个参数对应分发到设备中，其中，所述设备包括：接收服务器，验证服务器以及所述用户端，其中，所述用户端包括所述消费者用户端和所述商家用户端。 

其中，生成模块71包括：生成单元711。 

生成单元711用于在用户端注册时通过拉格朗日方程计算出共享密钥的三个参数，以使任意一个设备通过所述三个参数中的任意两个参数可计算出对应的共享密钥。 

进一步，该密钥提供服务器还可包括如下可选模块：更新模块73。 

更新模块73用于更新对应所述消费用户端生成的三个共享密钥的参数，和/或所述商家用户端生成的三个共享密钥的参数。 

其中，分发模块72还用于将更新模块73更新后的各个参数分别分发到对应的设备中。 

本发明实施例提供的方案具有如下有益效果：通过采用在用户端和接收服务器之间增加第三方验证环节的技术方案，解决了现有技术中仅需假冒接收服务器一方分发的公钥便可使用户端通过假信源的验证，从而导致用户端因遵从该假信源进行操作，引发的业务无法正常进行的技术问题，进而取得了提高对信源验证的可靠性，增强信源传递的完整性，从而保证了验证信源完整性的技术效果。 

实施例3 

本实施例提供一种验证信源完整性的系统800，如图8所示，该系统包括：请求用户端81，接收服务器82，接收用户端83，验证服务器84。 

请求用户端81用于在向接收服务器82发送第一信源后，接收来自接收服务器82的第一验证因子，并向验证服务器83提交根据所述第一验证因子获取 的第一验证码。 

接收服务器82用于在接收到请求用户端81提交的第一信源后，发送第一验证因子到请求用户端81，在接收到接收用户端83发送的第二验证因子后，发送第二验证信息到接收用户端83。 

接收用户端83用于发送第二验证因子到接收服务器82，并在发送所述第二验证因子后，接收到来自接收服务器82的第二验证信息，提交所述第二验证信息到验证服务器84。 

验证服务器84用于接收来自请求用户端81的第一验证码，和接收来自接收用户端83的第二验证信息，并根据所述第一验证码以及所述第二验证信息验证所述第一信源的完整性。 

在本实施例的系统800中还可包括：密钥提供服务器85。 

该密钥提供服务器85用于在所述请求用户端81注册时，根据拉格朗日方程为所述请求用户端81生成共享密钥的三个参数，并将所述三个参数对应分发到所述接收服务器82，所述验证服务器84以及所述请求用户端81。 

相应地，接收服务器82、所述验证服务器84以及所述请求用户端81中的任意一个设备，在接收到其对应的参数后，存储所述参数。 

密钥提供服务器85，还用于在所述接收用户端83注册时，根据拉格朗日方程为所述接收用户端83生成共享密钥的三个参数，并将所述三个参数对应分发到所述接收服务器82，所述验证服务器84以及所述接收用户端。 

相应地，接收服务器82、所述验证服务器84以及所述接收用户端83中的任意一个设备，在接收到其对应的参数后，存储所述参数。 

其中，接收服务器82发送到请求用户端81的第一验证因子具体包括：所述第一信源，接收服务器82为所述第一信源分配的信源序列号，以及接收服务器82存储的对应请求用户端81的参数。 

在本实施例中，接收用户端83发送到验证服务器84的第二验证信息具体包括：第二验证码，第二信源，以及接收服务器82为所述第一信源分配的信源序列号，其中，所述第二信源与所述第一信源拥有相同的信源序列号。 

那么，验证服务器84根据所述第一验证码以及所述第二验证信息验证所述第一信源的完整性具体为： 

验证服务器84从所述接收服务器82获取对应所述请求用户端81的参数和对应所述接收用户端83的参数，并根据所述其存储的对应请求用户端81的参数和所述来自接收服务器82的对应请求用户端的参数获取共享密钥，再用所述共享密钥解密所述第一验证获取第一数字摘要；根据所述其存储的对应接收用户端83的参数和所述来自接收服务器82的对应接收用户端83的参数获取共享密钥，再用所述共享密钥解密所述第二验证码获取第二数字摘要。 

验证服务器84根据所述第二信源和所述信源序列号获取第三数字摘要，并判断所述第一数字摘要、所述第二数字摘要以及所述第三数字摘要是否皆一致；如果判定一致，则所述第一信源具备完整性；否则，提示出错信息。 

本发明实施例提供的系统具有如下有益效果：在用户端和订单接收服务器之间引入第三方验证环节的技术方案，解决了现有技术中的验证信源完整性时仅需一方的密钥的技术问题，进而取得了提高对信源验证的可靠性，增加信源传递的完整性的技术效果。 

通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到本发明可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在可读取的存储介质中，如计算机的软盘，硬盘或光盘等，包括若干指令用以使得一台设备执行本发明各个实施例所述的方法。 

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应所述以权利要求的保护范围为准。 

Claims (5)

1.一种验证订单完整性的方法，其特征在于，在请求用户端向接收服务器提交第一订单后，包括：

所述请求用户端接收到所述接收服务器发送的第一验证因子，并根据所述第一验证因子获取第一验证码；所述第一验证因子包括：所述第一订单，所述接收服务器为所述第一订单分配的订单序列号，以及所述接收服务器存储的对应所述请求用户端的参数；所述请求用户端根据所述第一验证因子获取第一验证码包括：所述请求用户端根据所述第一验证因子中的参数和自身存储的来自密钥提供服务器的参数获取共享密钥，并用所述共享密钥加密第一验证因子的部分运算结果以获取第一验证码；所述第一验证因子的部分运算结果为对所述第一验证因子中的第一订单和订单序列号进行运算后得到的第一数字摘要；

接收用户端从所述接收服务器获取第二验证信息；所述第二验证信息包括：第二验证码，第二订单，以及所述接收服务器为所述第一订单分配的订单序列号，其中，所述第二订单与所述第一订单拥有相同的订单序列号；

验证服务器接收所述接收用户端提交的第二验证信息，还接收所述请求用户端发来的第一验证码；所述验证服务器根据所述第一验证码获取第一数字摘要，具体包括：所述验证服务器存储有来自密钥提供服务器的对应所述请求用户端的参数；所述接收服务器存储有对应所述请求用户端的参数；所述验证服务器从所述接收服务器获取对应所述请求用户端的参数；所述验证服务器根据其存储的对应请求用户端的参数和所述来自接收服务器的对应请求用户端的参数获取共享密钥，并用所述共享密钥解密所述第一验证码获取第一数字摘要；

所述验证服务器根据所述第二验证信息获取第二数字摘要和第三数字摘要，具体包括：所述验证服务器存储有来自密钥提供服务器的对应所述接收用户端的参数；所述接收服务器存储有对应所述接收用户端的参数；所述验证服务器从所述接收服务器获取对应所述接收用户端的参数；所述验证服务器根据其存储的对应接收用户端的参数和所述来自接收服务器的对应接收用户端的参数获取共享密钥，并用所述共享密钥解密所述第二验证码获取第二数字摘要；所述验证服务器根据所述第二订单和所述订单序列号获取第三数字摘要；

所述验证服务器判断所述第一数字摘要、所述第二数字摘要以及所述第三数字摘要是否一致；如果判定一致，则确定所述第一订单具备完整性；否则，提示出错信息；

在请求用户端向接收服务器提交第一订单后，该方法还包括：所述接收服务器根据所述第一订单和所述订单序列号获取第二数字摘要；所述接收服务器发送所述订单序列号到所述接收用户端；所述接收用户端存储有来自密钥提供服务器的参数；

在所述接收用户端从所述接收服务器获取第二验证信息之前，该方法还包括：所述接收用户端提交第二验证因子到所述接收服务器，所述第二验证因子包括：所述订单序列号和所述接收用户端存储的参数；所述接收服务器存储有来自所述密钥提供服务器的对应所述接收用户端的参数；所述接收服务器根据所述第二验证因子和所述第二数字摘要获取第二验证码，包括：所述接收服务器根据所述第二验证因子中的订单序列号查找到所述第二订单和所述第二数字摘要；所述接收服务器根据所述第二验证因子中的参数和其存储的参数获取共享密钥，并用所述共享密钥对所述第二数字摘要加密获取第二验证码并发送包含所述第二验证码的第二验证信息到所述接收用户端。

2.根据权利要求1所述的方法，其特征在于，该方法还包括：

在用户端注册时，密钥提供服务器为所述用户端生成共享密钥的至少三个参数，以使任意一个设备通过所述至少三个参数中的任意两个参数可获取所述共享密钥；所述密钥提供服务器将所述至少三个参数分发到各个设备中；所述各个设备中的任意一个设备，在接收到其对应的参数后，存储所述参数，所述各个设备至少包括：接收服务器，验证服务器以及所述用户端。

3.根据权要求2所述的方法，其特征在于，

当所述用户端为请求用户端时，所述密钥提供服务器为所述用户端生成共享密钥的至少三个参数，以使任意一个设备通过所述至少三个参数中的任意两个参数可获取所述共享密钥具体为：所述密钥提供服务器根据拉格朗日方程为所述请求用户端生成共享密钥的三个参数，以使任意一个设备通过所述三个参数中的任意两个参数可获取所述共享密钥；则所述密钥提供服务器将所述至少三个参数分发到各个设备中具体为：所述密钥提供服务器将所述三个参数对应分发到所述接收服务器，所述验证服务器以及所述请求用户端；

当所述用户端为接收用户端时，所述密钥提供服务器为所述用户端生成共享密钥的至少三个参数，以使任意一个设备通过所述至少三个参数中的任意两个参数可获取所述共享密钥具体为：所述密钥提供服务器根据拉格朗日方程为所述接收用户端生成共享密钥的三个参数，以使任意一个设备通过所述三个参数中的任意两个参数可获取所述共享密钥；则所述密钥提供服务器将所述至少三个参数分发到各个设备中具体为：所述密钥提供服务器将所述三个参数对应分发到所述接收服务器，所述验证服务器以及所述接收用户端。

4.根据权利要求2所述的方法，其特征在于，在所述请求用户端和所述接收用户端分别在密钥提供服务器注册后，该方法还包括：

所述密钥提供服务器更新为请求用户端生成的共享密钥的三个参数，并将更新后的三个参数对应分发到三个设备中；对于所述三个设备中的任意一个设备，在接收到更新后的所述参数后，用更新后的所述参数对应替换已存储的参数；和/或

所述密钥提供服务器更新为接收用户端生成的三个共享密钥的参数，并将更新后的三个参数对应分发到三个设备中；对于所述三个设备中的任意一个对应的设备，在接收到更新后的所述参数后，用更新后的所述参数替换已存储的参数。

5.一种验证订单完整性的系统，特征在于，包括：

如权利要求1所述的请求用户端；

如权利要求1所述的接收服务器；

如权利要求1所述的接收用户端；

如权利要求1所述的验证服务器；

所述第一验证因子具体包括：所述第一订单，所述接收服务器为所述第一订单分配的订单序列号，以及所述接收服务器存储的对应请求用户端的参数；

所述第二验证信息包括：第二验证码，第二订单，以及接收服务器为所述第一订单分配的订单序列号，其中所述第二订单与所述第一订单拥有相同的订单序列号；

所述第二验证因子包括：所述订单序列号和所述接收用户端存储的参数。

Images