短信平台验签方法、服务器及计算机可读存储介质与流程

文档序号:18737212发布日期:2019-09-21 01:20阅读:259来源:国知局
短信平台验签方法、服务器及计算机可读存储介质与流程

本发明涉及信息安全技术领域,尤其涉及一种短信平台验签方法、服务器及计算机可读存储介质。



背景技术:

短信平台现有的服务模式为,服务方开放restful接口给渠道方接入,为渠道方提供发送短信服务,并向渠道方收取所发送短信的服务费。若当前有多个渠道方同时需要服务,或者某个渠道方想冒充其他渠道方来发送自己的短信,则当前这种服务模式是不安全的,也会引起被冒充的渠道方的质疑。例如,服务方为两个渠道A和B提供服务,B渠道作弊,因为发短信是要收费的,B渠道想用A渠道的渠道号来发短信,这样所发送的短信收费是算在A渠道上的。而现有的一些签名验签方法,要么是密钥在网上传播,要么是容易被破解的,依旧无法防止渠道方被冒充。



技术实现要素:

有鉴于此,本发明提出一种短信平台验签方法、服务器及计算机可读存储介质,以解决如何防止渠道方被冒充的问题。

首先,为实现上述目的,本发明提出一种短信平台验签方法,该方法包括步骤:

设置restful接口,以提供给各渠道方调用,为渠道方提供服务;

接收渠道方发送的服务请求;

为所述渠道方分配一个渠道编码,并发送至所述渠道方;

与所述渠道方通过服务协议约定对数据报文进行签名验签,并与所述渠道方分别生成RSA非对称公私钥对;

保存服务方私钥,将服务方公钥发送给所述渠道方,并接收所述渠道方发送的渠道方公钥;

接收渠道方发送的交易请求,包括交易请求参数和交易数据,所述交易数据使用所述渠道方私钥进行签名;

根据所述交易请求参数查询对应的渠道方公钥;

利用查询到的所述渠道方公钥对所述交易数据进行验签;及

当验证通过后,处理所述交易请求。

可选地,该方法在处理所述交易请求之后还包括步骤:

当服务方向所述渠道方返回数据时,对所述返回数据用所述服务方私钥进行签名,以使所述渠道方利用保存的所述服务方公钥对所述返回数据进行验签。

可选地,所述服务方在映射关系数据库中以所述渠道方的渠道编码为标识,对应保存所述服务方公钥、服务方私钥、渠道方公钥。

可选地,所述交易请求参数中包括所述渠道方的渠道编码,所述根据所述交易请求参数查询对应的渠道方公钥的步骤包括:

从所述交易请求参数中获取所述渠道方的所述渠道编码,然后根据所述渠道编码从所述映射关系数据库中查询所述渠道编码对应的渠道方公钥。

可选地,所述当验证通过后,处理所述交易请求,包括:当所述验签的结果为验证通过时,表示所述交易请求确实是所述渠道方发出的,服务方向所述渠道方提供发送短信的服务;

所述利用查询到的所述渠道方公钥对所述交易数据进行验签之后,还包括:当所述验签的结果为验证失败时,表示所述交易请求不是所述渠道方发出的,而是其他渠道方冒充的,服务方拒绝所述交易请求。

此外,为实现上述目的,本发明还提供一种服务器,包括存储器、处理器,所述存储器上存储有可在所述处理器上运行的短信平台验签系统,所述短信平台验签系统被所述处理器执行时实现如下步骤:

设置restful接口,以提供给各渠道方调用,为渠道方提供服务;

接收渠道方发送的服务请求;

为所述渠道方分配一个渠道编码,并发送至所述渠道方;

与所述渠道方通过服务协议约定对数据报文进行签名验签,并与所述渠道方分别生成RSA非对称公私钥对;

保存服务方私钥,将服务方公钥发送给所述渠道方,并接收所述渠道方发送的渠道方公钥;

接收渠道方发送的交易请求,包括交易请求参数和交易数据,所述交易数据使用所述渠道方私钥进行签名;

根据所述交易请求参数查询对应的渠道方公钥;

利用查询到的所述渠道方公钥对所述交易数据进行验签;及

当验证通过后,处理所述交易请求。

可选地,所述短信平台验签系统被所述处理器执行时,在处理所述交易请求之后还实现步骤:

当服务方向所述渠道方返回数据时,对所述返回数据用所述服务方私钥进行签名,以使所述渠道方利用保存的所述服务方公钥对所述返回数据进行验签。

可选地,所述服务方在映射关系数据库中以所述渠道方的渠道编码为标识,对应保存所述服务方公钥、服务方私钥、渠道方公钥。

可选地,所述交易请求参数中包括所述渠道方的渠道编码,所述根据所述交易请求参数查询对应的渠道方公钥的步骤包括:

从所述交易请求参数中获取所述渠道方的所述渠道编码,然后根据所述渠道编码从所述映射关系数据库中查询所述渠道编码对应的渠道方公钥。

进一步地,为实现上述目的,本发明还提供一种计算机可读存储介质,所述计算机可读存储介质存储有短信平台验签系统,所述短信平台验签系统可被至少一个处理器执行,以使所述至少一个处理器执行如上述的短信平台验签方法的步骤。

相较于现有技术,本发明所提出的短信平台验签方法、服务器及计算机可读存储介质,可以通过服务方和渠道方分别生成的RSA非对称公私钥对进行交易数据的签名和验签,其中各方的私钥自己保存,交易传输过程中不包含任何私钥,保证了接口安全。服务方通过渠道方公钥对交易数据进行验签,可以确定交易请求是否确实由该渠道方发出,既可以防止该渠道方日后抵赖,也可以防止其他渠道方冒充该渠道方,避免收费时出现错误。

附图说明

图1是本发明服务器一可选的硬件架构的示意图;

图2是本发明短信平台验签系统第一实施例的程序模块示意图;

图3是本发明短信平台验签系统第二实施例的程序模块示意图;

图4是本发明短信平台验签方法第一实施例的流程示意图;

图5是本发明短信平台验签方法第二实施例的流程示意图;

本发明目的的实现、功能特点及优点将结合实施例,参照附图做进一步说明。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白,以下结合附图及实施例,对本发明进行进一步详细说明。应当理解,此处所描述的具体实施例仅用以解释本发明,并不用于限定本发明。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。

需要说明的是,在本发明中涉及“第一”、“第二”等的描述仅用于描述目的,而不能理解为指示或暗示其相对重要性或者隐含指明所指示的技术特征的数量。由此,限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。另外,各个实施例之间的技术方案可以相互结合,但是必须是以本领域普通技术人员能够实现为基础,当技术方案的结合出现相互矛盾或无法实现时应当认为这种技术方案的结合不存在,也不在本发明要求的保护范围之内。

参阅图1所示,是本发明服务器2一可选的硬件架构的示意图。

本实施例中,所述服务器2可包括,但不仅限于,可通过系统总线相互通信连接存储器11、处理器12、网络接口13。需要指出的是,图1仅示出了具有组件11-13的服务器2,但是应理解的是,并不要求实施所有示出的组件,可以替代的实施更多或者更少的组件。

其中,所述服务器2可以是机架式服务器、刀片式服务器、塔式服务器或机柜式服务器等计算设备,该服务器2可以是独立的服务器,也可以是多个服务器所组成的服务器集群。

所述存储器11至少包括一种类型的可读存储介质,所述可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如,SD或DX存储器等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁性存储器、磁盘、光盘等。在一些实施例中,所述存储器11可以是所述服务器2的内部存储单元,例如该服务器2的硬盘或内存。在另一些实施例中,所述存储器11也可以是所述服务器2的外部存储设备,例如该服务器2上配备的插接式硬盘,智能存储卡(Smart Media Card,SMC),安全数字(Secure Digital,SD)卡,闪存卡(Flash Card)等。当然,所述存储器11还可以既包括所述服务器2的内部存储单元也包括其外部存储设备。本实施例中,所述存储器11通常用于存储安装于所述服务器2的操作系统和各类应用软件,例如短信平台验签系统200的程序代码等。此外,所述存储器11还可以用于暂时地存储已经输出或者将要输出的各类数据。

所述处理器12在一些实施例中可以是中央处理器(Central ProcessingUnit,CPU)、控制器、微控制器、微处理器、或其他数据处理芯片。该处理器12通常用于控制所述服务器2的总体操作。本实施例中,所述处理器12用于运行所述存储器11中存储的程序代码或者处理数据,例如运行所述的短信平台验签系统200等。

所述网络接口13可包括无线网络接口或有线网络接口,该网络接口13通常用于在所述服务器2与其他电子设备之间建立通信连接。

至此,己经详细介绍了本发明相关设备的硬件结构和功能。下面,将基于上述介绍提出本发明的各个实施例。

首先,本发明提出一种短信平台验签系统200。

参阅图2所示,是本发明短信平台验签系统200第一实施例的程序模块图。

本实施例中,所述短信平台验签系统200包括一系列的存储于存储器11上的计算机程序指令,当该计算机程序指令被处理器12执行时,可以实现本发明各实施例的短信平台验签操作。在一些实施例中,基于该计算机程序指令各部分所实现的特定的操作,短信平台验签系统200可以被划分为一个或多个模块。例如,在图2中,所述短信平台验签系统200可以被分割成设置模块201、收发模块202、分配模块203、生成模块204、获取模块205、验证模块206、处理模块207。其中:

所述设置模块201,用于设置restful接口,以提供给各渠道方调用,为渠道方提供服务。

具体地,服务方即短信平台服务系统,作为短信服务的提供者,为渠道方提供restful接口;渠道方即该短信平台的上游系统,通过调用服务方提供的restful接口完成交易,渠道方可以有多个。

所述收发模块202,用于接收渠道方发送的服务请求。

具体地,当某个渠道方需要服务方的短信平台服务时,在首次交易前需要向所述服务方发送服务请求。服务方接收到该服务请求后,与该渠道方建立服务关系,为其开放该restful接口。

所述分配模块203,用于为该渠道方分配一个渠道编码,并发送至该渠道方。

具体地,当服务方接收到渠道方的服务请求后,为该渠道方分配一个专属的渠道编码,用于后续为多个渠道方提供服务时区分各个渠道方。所述渠道编码还可以作为该渠道方的唯一标识,用来保存和查询该渠道方相关的密钥。

所述生成模块204,用于与该渠道方通过服务协议约定对数据报文进行签名验签,服务方和该渠道方分别生成RSA非对称公私钥对。

具体地,为了防止渠道方进行冒充,提高接口安全性,本实施例中采用RSA非对称公私钥对对服务方和渠道方之间的数据报文进行签名和验签。服务方和该渠道方之间通过服务协议约定该服务模式,并分别生成对应的RSA非对称公私钥对,包括服务方公钥A和私钥A,渠道方公钥B和私钥B。其中,每方的私钥用于自己保存,不能泄露,公钥发送给对方。

所述收发模块202,还用于保存服务方私钥,将服务方公钥发送给该渠道方,并接收该渠道方发送的渠道方公钥。

具体地,服务方将服务方公钥A发送给该渠道方,并接收该渠道方发送的渠道方公钥B,然后服务方在映射关系数据库中以该渠道方的渠道编码为标识,对应保存所述服务方公钥A、服务方私钥A、渠道方公钥B。

所述收发模块202,还用于接收渠道方发送的交易请求,包括交易请求参数和交易数据,所述交易数据使用渠道方私钥进行签名。

具体地,当渠道方需要通过所述短信平台发送短信时,向所述服务方发送交易请求。所述交易请求中包括交易请求参数和交易数据,所述交易请求参数中包括该渠道方的渠道编码,所述交易数据使用渠道方私钥B进行签名。服务方接收所述交易请求。

所述获取模块205,用于从所述交易请求参数中获取该渠道方的渠道编码,并根据该渠道编码查询对应的渠道方公钥。

具体地,服务方接收到所述交易请求后,从交易请求参数中获取该渠道方对应的唯一的渠道编码,然后根据该渠道编码从所述映射关系数据库中查询该渠道编码对应的渠道方公钥B。

所述验证模块206,用于利用查询到的渠道方公钥对所述交易数据进行验签。

具体地,服务方查询到该渠道编码对应的渠道方公钥B后,则可使用该渠道方公钥B对所述交易数据进行验签。如果所述交易数据是采用渠道方私钥B进行签名的,则使用渠道方公钥B验签可以验证通过;如果所述交易数据是采用其他渠道方的私钥进行签名的,则使用渠道方公钥B验签无法验证通过。

例如,渠道方C冒充渠道方B向服务方发出交易请求,则该交易请求参数中包含的是渠道方B的渠道编码,而交易数据是采用渠道方私钥C进行签名的。当服务方接收到该交易请求后,从交易请求参数中获取到渠道方B的渠道编码,然后从所述映射关系数据库中查询到的是渠道方公钥B,则使用该渠道方公钥B对所述交易数据进行验签时,结果肯定是验证失败。

所述处理模块207,用于当验证通过后,处理所述交易请求。

具体地,当所述验签的结果为验证通过时,表示该交易请求确实是该渠道方发出的,没有被冒充。此时服务方可以进一步处理所述交易请求,即向该渠道方提供发送短信的服务。当所述验签的结果为验证失败时,表示该交易请求不是该渠道方发出的,而是其他渠道方冒充的。此时服务方可以拒绝该交易请求。

本实施例提供的短信平台验签系统,可以通过服务方和渠道方分别生成的RSA非对称公私钥对进行交易数据的签名和验签,其中各方的私钥自己保存,交易传输过程中不包含任何私钥,保证了接口安全。服务方通过渠道方公钥对交易数据进行验签,可以确定交易请求是否确实由该渠道方发出,既可以防止该渠道方日后抵赖,也可以防止其他渠道方冒充该渠道方,避免收费时出现错误。

参阅图3所示,是本发明短信平台验签系统200第二实施例的程序模块图。本实施例中,所述的短信平台验签系统200除了包括第一实施例中的所述设置模块201、收发模块202、分配模块203、生成模块204、获取模块205、验证模块206、处理模块207之外,还包括签名模块208。

所述签名模块208,用于当服务方向该渠道方返回数据时,对所述返回数据用服务方私钥进行签名,以使该渠道方利用保存的服务方公钥对所述返回数据进行验签。

反过来,当服务方向该渠道方返回数据时,则对所述返回数据采用服务方私钥A进行签名。该渠道方保存有服务方公钥A,当该渠道方接收到所述返回数据时,获取所述服务方公钥A,然后使用所述服务方公钥A对所述返回数据进行验签。当验证通过后,该渠道方可以解析所述返回数据。

本实施例提供的短信平台验签系统,可以通过服务方和渠道方分别生成的RSA非对称公私钥对进行交易数据的签名和验签,其中各方的私钥自己保存,交易传输过程中不包含任何私钥,保证了接口安全。服务方通过渠道方公钥对交易数据进行验签,可以确定交易请求是否确实由该渠道方发出,既可以防止该渠道方日后抵赖,也可以防止其他渠道方冒充该渠道方,避免收费时出现错误。另外,渠道方也可以通过服务方公钥对服务方返回的数据进行验签,从而解析所述返回数据。

此外,本发明还提出一种短信平台验签方法。

参阅图4所示,是本发明短信平台验签方法第一实施例的流程示意图。在本实施例中,根据不同的需求,图4所示的流程图中的步骤的执行顺序可以改变,某些步骤可以省略。

该方法包括以下步骤:

步骤S400,设置restful接口,以提供给各渠道方调用,为渠道方提供服务。

具体地,服务方即短信平台服务系统,作为短信服务的提供者,为渠道方提供restful接口;渠道方即该短信平台的上游系统,通过调用服务方提供的restful接口完成交易,渠道方可以有多个。

步骤S402,接收渠道方发送的服务请求。

具体地,当某个渠道方需要服务方的短信平台服务时,在首次交易前需要向所述服务方发送服务请求。服务方接收到该服务请求后,与该渠道方建立服务关系,为其开放该restful接口。

步骤S404,为该渠道方分配一个渠道编码,并发送至该渠道方。

具体地,当服务方接收到渠道方的服务请求后,为该渠道方分配一个专属的渠道编码,用于后续为多个渠道方提供服务时区分各个渠道方。所述渠道编码还可以作为该渠道方的唯一标识,用来保存和查询该渠道方相关的密钥。

步骤S406,与该渠道方通过服务协议约定对数据报文进行签名验签,服务方和该渠道方分别生成RSA非对称公私钥对。

具体地,为了防止渠道方进行冒充,提高接口安全性,本实施例中采用RSA非对称公私钥对对服务方和渠道方之间的数据报文进行签名和验签。服务方和该渠道方之间通过服务协议约定该服务模式,并分别生成对应的RSA非对称公私钥对,包括服务方公钥A和私钥A,渠道方公钥B和私钥B。其中,每方的私钥用于自己保存,不能泄露,公钥发送给对方。

步骤S408,保存服务方私钥,将服务方公钥发送给该渠道方,并接收该渠道方发送的渠道方公钥。

具体地,服务方将服务方公钥A发送给该渠道方,并接收该渠道方发送的渠道方公钥B,然后服务方在映射关系数据库中以该渠道方的渠道编码为标识,对应保存所述服务方公钥A、服务方私钥A、渠道方公钥B。

步骤S410,接收渠道方发送的交易请求,包括交易请求参数和交易数据,所述交易数据使用渠道方私钥进行签名。

具体地,当渠道方需要通过所述短信平台发送短信时,向所述服务方发送交易请求。所述交易请求中包括交易请求参数和交易数据,所述交易请求参数中包括该渠道方的渠道编码,所述交易数据使用渠道方私钥B进行签名。服务方接收所述交易请求。

步骤S412,根据所述交易请求参数查询对应的渠道方公钥。

具体地,服务方接收到所述交易请求后,从交易请求参数中获取该渠道方对应的唯一的渠道编码,然后根据该渠道编码从所述映射关系数据库中查询该渠道编码对应的渠道方公钥B。

步骤S414,利用查询到的渠道方公钥对所述交易数据进行验签。

具体地,服务方查询到该渠道编码对应的渠道方公钥B后,则可使用该渠道方公钥B对所述交易数据进行验签。如果所述交易数据是采用渠道方私钥B进行签名的,则使用渠道方公钥B验签可以验证通过;如果所述交易数据是采用其他渠道方的私钥进行签名的,则使用渠道方公钥B验签无法验证通过。

例如,渠道方C冒充渠道方B向服务方发出交易请求,则该交易请求参数中包含的是渠道方B的渠道编码,而交易数据是采用渠道方私钥C进行签名的。当服务方接收到该交易请求后,从交易请求参数中获取到渠道方B的渠道编码,然后从所述映射关系数据库中查询到的是渠道方公钥B,则使用该渠道方公钥B对所述交易数据进行验签时,结果肯定是验证失败。

步骤S416,当验证通过后,处理所述交易请求。

具体地,当所述验签的结果为验证通过时,表示该交易请求确实是该渠道方发出的,没有被冒充。此时服务方可以进一步处理所述交易请求,即向该渠道方提供发送短信的服务。当所述验签的结果为验证失败时,表示该交易请求不是该渠道方发出的,而是其他渠道方冒充的。此时服务方可以拒绝该交易请求。

本实施例提供的短信平台验签方法,可以通过服务方和渠道方分别生成的RSA非对称公私钥对进行交易数据的签名和验签,其中各方的私钥自己保存,交易传输过程中不包含任何私钥,保证了接口安全。服务方通过渠道方公钥对交易数据进行验签,可以确定交易请求是否确实由该渠道方发出,既可以防止该渠道方日后抵赖,也可以防止其他渠道方冒充该渠道方,避免收费时出现错误。

如图5所示,是本发明短信平台验签方法的第二实施例的流程示意图。本实施例中,所述短信平台验签方法的步骤S500-S516与第一实施例的步骤S400-S416相类似,区别在于该方法还包括步骤S518。

该方法包括以下步骤:

步骤S500,设置restful接口,以提供给各渠道方调用,为渠道方提供服务。

具体地,服务方即短信平台服务系统,作为短信服务的提供者,为渠道方提供restful接口;渠道方即该短信平台的上游系统,通过调用服务方提供的restful接口完成交易,渠道方可以有多个。

步骤S502,接收渠道方发送的服务请求。

具体地,当某个渠道方需要服务方的短信平台服务时,在首次交易前需要向所述服务方发送服务请求。服务方接收到该服务请求后,与该渠道方建立服务关系,为其开放该restful接口。

步骤S504,为该渠道方分配一个渠道编码,并发送至该渠道方。

具体地,当服务方接收到渠道方的服务请求后,为该渠道方分配一个专属的渠道编码,用于后续为多个渠道方提供服务时区分各个渠道方。所述渠道编码还可以作为该渠道方的唯一标识,用来保存和查询该渠道方相关的密钥。

步骤S506,与该渠道方通过服务协议约定对数据报文进行签名验签,服务方和该渠道方分别生成RSA非对称公私钥对。

具体地,为了防止渠道方进行冒充,提高接口安全性,本实施例中采用RSA非对称公私钥对对服务方和渠道方之间的数据报文进行签名和验签。服务方和该渠道方之间通过服务协议约定该服务模式,并分别生成对应的RSA非对称公私钥对,包括服务方公钥A和私钥A,渠道方公钥B和私钥B。其中,每方的私钥用于自己保存,不能泄露,公钥发送给对方。

步骤S508,保存服务方私钥,将服务方公钥发送给该渠道方,并接收该渠道方发送的渠道方公钥。

具体地,服务方将服务方公钥A发送给该渠道方,并接收该渠道方发送的渠道方公钥B,然后服务方在映射关系数据库中以该渠道方的渠道编码为标识,对应保存所述服务方公钥A、服务方私钥A、渠道方公钥B。

步骤S510,接收渠道方发送的交易请求,包括交易请求参数和交易数据,所述交易数据使用渠道方私钥进行签名。

具体地,当渠道方需要通过所述短信平台发送短信时,向所述服务方发送交易请求。所述交易请求中包括交易请求参数和交易数据,所述交易请求参数中包括该渠道方的渠道编码,所述交易数据使用渠道方私钥B进行签名。服务方接收所述交易请求。

步骤S512,根据所述交易请求参数查询对应的渠道方公钥。

具体地,服务方接收到所述交易请求后,从交易请求参数中获取该渠道方对应的唯一的渠道编码,然后根据该渠道编码从所述映射关系数据库中查询该渠道编码对应的渠道方公钥B。

步骤S514,利用查询到的渠道方公钥对所述交易数据进行验签。

具体地,服务方查询到该渠道编码对应的渠道方公钥B后,则可使用该渠道方公钥B对所述交易数据进行验签。如果所述交易数据是采用渠道方私钥B进行签名的,则使用渠道方公钥B验签可以验证通过;如果所述交易数据是采用其他渠道方的私钥进行签名的,则使用渠道方公钥B验签无法验证通过。

例如,渠道方C冒充渠道方B向服务方发出交易请求,则该交易请求参数中包含的是渠道方B的渠道编码,而交易数据是采用渠道方私钥C进行签名的。当服务方接收到该交易请求后,从交易请求参数中获取到渠道方B的渠道编码,然后从所述映射关系数据库中查询到的是渠道方公钥B,则使用该渠道方公钥B对所述交易数据进行验签时,结果肯定是验证失败。

步骤S516,当验证通过后,处理所述交易请求。

具体地,当所述验签的结果为验证通过时,表示该交易请求确实是该渠道方发出的,没有被冒充。此时服务方可以进一步处理所述交易请求,即向该渠道方提供发送短信的服务。当所述验签的结果为验证失败时,表示该交易请求不是该渠道方发出的,而是其他渠道方冒充的。此时服务方可以拒绝该交易请求。

步骤S518,当服务方向该渠道方返回数据时,对所述返回数据用服务方私钥进行签名,以使该渠道方利用保存的服务方公钥对所述返回数据进行验签。

反过来,当服务方向该渠道方返回数据时,则对所述返回数据采用服务方私钥A进行签名。该渠道方保存有服务方公钥A,当该渠道方接收到所述返回数据时,获取所述服务方公钥A,然后使用所述服务方公钥A对所述返回数据进行验签。当验证通过后,该渠道方可以解析所述返回数据。

本实施例提供的短信平台验签方法,可以通过服务方和渠道方分别生成的RSA非对称公私钥对进行交易数据的签名和验签,其中各方的私钥自己保存,交易传输过程中不包含任何私钥,保证了接口安全。服务方通过渠道方公钥对交易数据进行验签,可以确定交易请求是否确实由该渠道方发出,既可以防止该渠道方日后抵赖,也可以防止其他渠道方冒充该渠道方,避免收费时出现错误。另外,渠道方也可以通过服务方公钥对服务方返回的数据进行验签,从而解析所述返回数据。

本发明还提供了另一种实施方式,即提供一种计算机可读存储介质,所述计算机可读存储介质存储有短信平台验签程序,所述短信平台验签程序可被至少一个处理器执行,以使所述至少一个处理器执行如上述的短信平台验签方法的步骤。

上述本发明实施例序号仅仅为了描述,不代表实施例的优劣。

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

以上仅为本发明的优选实施例,并非因此限制本发明的专利范围,凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换,或直接或间接运用在其他相关的技术领域,均同理包括在本发明的专利保护范围内。

当前第1页1 2 3 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1