CN108092775B - 一种校验方法及装置、电子设备 - Google Patents
一种校验方法及装置、电子设备 Download PDFInfo
- Publication number
- CN108092775B CN108092775B CN201611044124.5A CN201611044124A CN108092775B CN 108092775 B CN108092775 B CN 108092775B CN 201611044124 A CN201611044124 A CN 201611044124A CN 108092775 B CN108092775 B CN 108092775B
- Authority
- CN
- China
- Prior art keywords
- client
- server
- public key
- service request
- signature
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
- H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
- H04L63/1441—Countermeasures against malicious traffic
- H04L63/1466—Active attacks involving interception, injection, modification, spoofing of data unit addresses, e.g. hijacking, packet injection or TCP sequence number attacks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/16—Implementing security features at a particular protocol layer
- H04L63/168—Implementing security features at a particular protocol layer above the transport layer
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/14—Session management
- H04L67/141—Setup of application sessions
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
- H04L9/3268—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Computer And Data Communications (AREA)
Abstract
本申请提供一种校验方法及装置、电子设备;所述校验方法包括:服务端收到客户端的业务请求后,根据第一加签因子以及预定的加签算法,对所述业务请求的请求参数进行计算,得到计算结果;所述第一加签因子包括:所述客户端对应的应用密码、服务端公钥;所述服务端判断所述计算结果和所述业务请求的签名是否相同;所述业务请求的签名由所述客户端根据第二加签因子以及预定的加签算法,对所述业务请求的请求参数进行计算得到;所述第二加签因子包括:打包在所述客户端中的应用密码、所述客户端本地保存的服务端公钥。本申请可以防止数据在网络传输中受到中间人攻击。
Description
技术领域
本发明涉及网络安全领域,尤其涉及一种校验方法及装置、电子设备。
背景技术
互联网客户端(包括但不限于iOS、Android、个人电脑等操作系统或者机器的应用软件,简称APP)是基于安全套接层上的超文本传输协议(Hyper Text Transfer Protocolover Secure Socket Layer,HTTPS)/安全套接层(Secure Socket Layer,SSL)/安全传输层协议(Transport Layer Security Protocol,TLS)通讯的产品。
目前很多互联网接口为了网络传输安全性会基于HTTPS/SSL/TLS来传输数据。但是就算HTTPS/SSL/HTTPS也会遇到中间人攻击的风险。中间人攻击是一种“间接”的入侵攻击,这种攻击模式是通过各种技术手段将受入侵者控制的一台设备虚拟放置在网络连接中的两台通信设备之间(比如客户端所在的计算机和服务端所在的计算机之间),这台设备就称为“中间人”。
为了防止中间人攻击,客户端请求建立连接时一般会把服务端返回的数字证书拿本地的证书认证机构(Certificate Authority,CA)证书链(一般操作系统层面预埋)、或者自签发根证书(应用预装或者用户手工安装)、或者应用预埋的数字证书(或者公钥)来校验对应的服务端是否受信合法。
采用CA证书链校验和自签发根证书校验时,服务端通过私钥对发送的数据进行签名,客户端对收到的数据使用与服务端所用私钥对应的公钥进行校验;隐患在于:私钥存在被第三方偷窃或者泄露的可能,而第三方得到私钥后可以在客户端安装根证书;或者证书认证机构本身也有能力作为中间人,在客户端安装根证书。
不管是CA证书链校验,还是自签发根证书校验,对于操作系统被黑客(中间人)安装了黑客(中间人)的根证书且应用软件处于黑客(中间人)代理网络下的情况,应用软件在网络中发起的所有请求/响应数据将被黑客(中间人)劫持。如图1所示,假设客户端已被中间人安装自签发根证书,这样在HTTPS握手时,中间人的证书会被客户端所在操作系统中的中间人自签发根证书认可,所建立的实际上是客户端和中间人之间的HTTPS连接,以及中间人和服务端之间的HTTPS连接;客户端的网络业务请求数据将会被中间人劫持解析后,再组装转发到服务器。
预埋服务端证书校验,是针对HTTPS/SSL/TLS连接在客户端层面进行服务端证书的强校验。该方案的缺陷在于:服务端证书需要定期更新,导致预埋的服务端证书也需要定期更新,因此需要对客户端定期重新打包预埋新的服务端证书,如果到期没有重新打包预埋并让用户升级,当服务端证书过期更新后,会导致客户端业务请求的网络调用无法建立连接。
发明内容
本申请提供一种校验方法及装置、电子设备,可以防止数据在网络传输中受到中间人攻击。
本申请采用如下技术方案。
一种校验方法,包括:
服务端收到客户端的业务请求后,根据第一加签因子以及预定的加签算法,对所述业务请求的请求参数进行计算,得到计算结果;所述第一加签因子包括:所述客户端对应的应用密码、服务端公钥;
所述服务端判断所述计算结果和所述业务请求的签名是否相同;其中,所述业务请求的签名由所述客户端根据第二加签因子以及预定的加签算法,对所述业务请求的请求参数进行计算得到;所述第二加签因子包括:打包在所述客户端中的应用密码、所述客户端本地保存的服务端公钥。
可选地,所述根据第一加签因子以及预定的加签算法,对所述业务请求的请求参数进行计算前还包括:
所述服务端根据预先保存的应用标识和应用密码之间的对应关系、以及所述业务请求中携带的应用标识,确定所述客户端对应的应用密码。
可选地,所述服务端收到客户端的业务请求前还包括:
所述服务端当和所述客户端建立连接握手时,将服务端公钥发送给所述客户端。
一种校验方法,包括:
客户端发起业务请求,根据第二加签因子以及预定的加签算法,对所述业务请求的请求参数进行计算,将计算结果作为所述业务请求的签名;所述第二加签因子包括:打包在所述客户端中的应用密码、所述客户端本地保存的服务端公钥;
所述客户端将所述业务请求发送给服务端。
可选地,所述客户端将所述业务请求发送给服务端前还包括:
所述客户端将打包在本客户端中的应用标识携带在所述业务请求中。
可选地,所述客户端发起业务请求前还包括:
所述客户端在和所述服务端建立连接握手时,获取服务端公钥。
一种校验方法,包括:
客户端调用预定接口接收服务端的返回结果,所述返回结果中携带服务端公钥;其中,所述返回结果的签名由所述服务端根据第一加签因子以及预定的加签算法,对所述返回结果的参数进行计算得到;所述第一加签因子包括:所述客户端对应的应用密码、服务端公钥;
所述客户端根据第三加签因子以及预定的加签算法,对所述返回结果的参数进行计算,比较计算结果和所述返回结果的签名,如果一致则保存所述返回结果中的服务端公钥;所述第三加签因子包括:打包在所述客户端中的应用密码、所述返回结果中的服务端公钥。
可选地,所述接收服务端的返回结果前还包括:
所述客户端在建立握手连接时,用本地保存的根证书链校验收到的服务端证书,如果校验失败,则停止本次接口调用;如果校验成功,则继续接口调用。
可选地,所述的校验方法还包括:
所述客户端发起业务请求,建立握手连接时,用本地根证书链校验收到的服务端证书,获取服务端公钥;比较本地保存到服务端公钥和获取到的服务端公钥,如果一致则继续进行业务请求。
一种校验方法,包括:
服务端当客户端调用预定接口时,将服务端公钥携带在返回结果中;根据第一加签因子以及预定的加签算法,对所述返回结果的参数进行计算,将计算结果作为所述返回结果的签名;所述第一加签因子包括:所述客户端对应的应用密码、服务端公钥;
所述服务端发送所述返回结果给所述客户端。
可选地,所述的校验方法还包括:
所述服务端当客户端发起业务请求,建立握手连接时,发送包括服务端公钥的服务端证书给客户端。
一种校验装置,包括:
计算模块,用于在收到客户端的业务请求后,根据第一加签因子以及预定的加签算法,对所述业务请求的请求参数进行计算,得到计算结果;所述第一加签因子包括:所述客户端对应的应用密码、服务端公钥;
判断模块,用于判断所述计算结果和所述业务请求的签名是否相同;其中,所述业务请求的签名由所述客户端根据第二加签因子以及预定的加签算法,对所述业务请求的请求参数进行计算得到;所述第二加签因子包括:打包在所述客户端中的应用密码、所述客户端本地保存的服务端公钥。
可选地,所述计算模块还用于在根据第一加签因子以及预定的加签算法,对所述业务请求的请求参数进行计算前,根据预先保存的应用标识和应用密码之间的对应关系、以及所述业务请求中携带的应用标识,确定所述客户端对应的应用密码。
可选地,所述的校验装置还包括:
反馈模块,用于在所述计算模块收到客户端的业务请求前,当和所述客户端建立连接握手时,发送所述服务端公钥给所述客户端。
一种校验装置,包括:
签名模块,用于发起业务请求,根据第二加签因子以及预定的加签算法,对所述业务请求的请求参数进行计算,将计算结果作为所述业务请求的签名;所述第二加签因子包括:打包在客户端中的应用密码、本地保存的服务端公钥;
发送模块,用于将所述业务请求发送给服务端。
可选地,所述签名模块还用于将打包在客户端中的应用标识携带在所述业务请求中。
可选地,所述的校验装置还包括:
获取模块,用于在所述签名模块发起业务请求前,当和所述服务端建立连接握手时,获取服务端公钥。
一种校验装置,包括:
调用模块,用于调用预定接口接收服务端的返回结果,所述返回结果中携带服务端公钥;其中,所述返回结果的签名由所述服务端根据第一加签因子以及预定的加签算法,对所述返回结果的参数进行计算得到;所述第一加签因子包括:所述客户端对应的应用密码、服务端公钥;
比较模块,用于根据第三加签因子以及预定的加签算法,对所述返回结果的参数进行计算,比较计算结果和所述返回结果的签名,如果一致则保存所述返回结果中的服务端公钥;所述第三加签因子包括:打包在所述客户端中的应用密码、所述返回结果中的服务端公钥。
可选地,所述调用模块还用于在接收服务端的返回结果前,在建立握手连接时,用本地保存的根证书链校验收到的服务端证书,如果校验失败,则停止本次接口调用;如果校验成功,则继续接口调用。
可选地,所述的校验装置还包括:
校验模块,用于在发起业务请求,建立握手连接时,用本地根证书链校验收到的服务端证书,获取服务端公钥;比较本地保存到服务端公钥和获取到的服务端公钥,如果一致则继续进行业务请求。
一种校验装置,包括:
加签模块,用于当客户端调用预定接口时,将服务端公钥携带在返回结果中;根据第一加签因子以及预定的加签算法,对所述返回结果的参数进行计算,将计算结果作为所述返回结果的签名;所述第一加签因子包括:所述客户端对应的应用密码、服务端公钥;
返回模块,用于发送所述返回结果给所述客户端。
可选地,所述返回模块还用于当客户端发起业务请求,建立握手连接时,发送包括服务端公钥的服务端证书给客户端。
一种进行校验的电子设备,包括:第一处理器和第一存储器;
所述第一存储器用于保存用于进行校验的程序;所述用于进行校验的程序在被所述第一处理器读取执行时,执行以下操作:
收到客户端的业务请求后,根据第一加签因子以及预定的加签算法,对所述业务请求的请求参数进行计算,得到计算结果;所述第一加签因子包括:所述客户端对应的应用密码、服务端公钥;
判断所述计算结果和所述业务请求的签名是否相同;其中,所述业务请求的签名由所述客户端根据第二加签因子以及预定的加签算法,对所述业务请求的请求参数进行计算得到;所述第二加签因子包括:打包在所述客户端中的应用密码、所述客户端本地保存的服务端公钥。
一种进行校验的电子设备,包括:第二处理器和第二存储器;
所述第二存储器用于保存用于进行校验的程序;所述用于进行校验的程序在被所述第二处理器读取执行时,执行以下操作:
发起业务请求,根据第二加签因子以及预定的加签算法,对所述业务请求的请求参数进行计算,将计算结果作为所述业务请求的签名;所述第二加签因子包括:打包在所述客户端中的应用密码、所述客户端本地保存的服务端公钥;
将所述业务请求发送给服务端。
一种进行校验的电子设备,包括:第三处理器和第三存储器;
所述第三存储器用于保存用于进行校验的程序;所述用于进行校验的程序在被所述第三处理器读取执行时,执行以下操作:
调用预定接口接收服务端的返回结果,所述返回结果中携带服务端公钥;其中,所述返回结果的签名由所述服务端根据第一加签因子以及预定的加签算法,对所述返回结果的参数进行计算得到;所述第一加签因子包括:所述客户端对应的应用密码、服务端公钥;
根据第三加签因子以及预定的加签算法,对所述返回结果的参数进行计算,比较计算结果和所述返回结果的签名,如果一致则保存所述返回结果中的服务端公钥;所述第三加签因子包括:打包在所述客户端中的应用密码、所述返回结果中的服务端公钥。
一种进行校验的电子设备,包括:第四处理器和第四存储器;
所述第四存储器用于保存用于进行校验的程序;所述用于进行校验的程序在被所述第四处理器读取执行时,执行以下操作:
当客户端调用预定接口时,将服务端公钥携带在返回结果中;根据第一加签因子以及预定的加签算法,对所述返回结果的参数进行计算,将计算结果作为所述返回结果的签名;所述第一加签因子包括:所述客户端对应的应用密码、服务端公钥;
发送所述返回结果给所述客户端。
本申请包括以下优点:
本申请至少一个实施例中,在数据传输过程中,由于颁发给客户端的应用密码不作为数据传输,只作为加签因子,因此黑客无法从传输的数据中拦截得到该应用密码,因此无法对客户端和服务端之间传输的数据进行劫持或篡改。假如黑客作为中间人发送了假的服务端公钥给客户端,由于服务端公钥也是加签因子之一,因此客户端在进行业务请求时也同样无法通过服务端的校验。
本申请至少一个实施例中,黑客由于无法获得作为加签因子之一的应用密码,无法伪造出正确的签名,因此黑客发送的数据不会在客户端校验成功,即黑客无法冒充合法的服务端。由于客户端会在收到服务端公钥时进行签名校验,因此黑客在不知道加签因子之一的情况下,也无法发送假的服务端公钥给客户端。
本申请至少一个实施例中,由于校验时真实的服务端公钥是加签因子之一,因此如果客户端所保存的服务端公钥不是真实的服务端公钥,将无法校验成功。这样可以杜绝黑客以安装根证书的方式,来欺骗客户端受信于中间人的证书,在CA证书或根证书不再安全的情况下,依然能保证网络传输数据的安全。
当然,实施本申请的任一产品必不一定需要同时达到以上所述的所有优点。
附图说明
图1是相关技术中的中间人攻击的示意图;
图2是实施例一的校验方法的流程图;
图3是实施例二的校验方法的流程图;
图4是实施例三的校验方法的流程图;
图5是实施例四的校验方法的流程图;
图6是实施例五中服务端校验方案的示意图;
图7(a)、(b)是实施例五中客户器端校验方案的示意图;
图8是实施例六的校验装置的示意图;
图9是实施例七的校验装置的示意图;
图10是实施例八的校验装置的示意图;
图11是实施例九的校验装置的示意图。
具体实施方式
下面将结合附图及实施例对本申请的技术方案进行更详细的说明。
需要说明的是,如果不冲突,本申请实施例以及实施例中的各个特征可以相互结合,均在本申请的保护范围之内。另外,虽然在流程图中示出了逻辑顺序,但是在某些情况下,可以以不同于此处的顺序执行所示出或描述的步骤。
在一种配置中,客户端、服务端所在的计算设备可包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存(memory)。
内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。内存可能包括模块1,模块2,……,模块N(N为大于2的整数)。
计算机可读介质包括永久性和非永久性、可移动和非可移动存储介质,可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM),快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括非暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
本申请实施例可以但不限于适用于使用HTTPS/SSL/TLS网络协议进行数据传输的情况下;对于HTTPS/SSL/TLS对应的升级、关联网络协议,包括但不限于Google开发的基于传输控制协议(Transmission Control Protocol,TCP)的应用层协议SPDY等,也可以适用。
实施例一、一种校验方法,如图2所示,包括步骤S110~S120:
S110、服务端收到客户端的业务请求后,根据第一加签因子以及预定的加签算法,对所述业务请求的请求参数进行计算,得到计算结果;所述第一加签因子包括:所述客户端对应的应用密码、服务端公钥;
S120、所述服务端判断所述计算结果和所述业务请求的签名是否相同;其中,所述业务请求的签名由所述客户端根据第二加签因子以及预定的加签算法,对所述业务请求的请求参数进行计算得到;所述第二加签因子包括:打包在所述客户端中的应用密码、所述客户端本地保存的服务端公钥。
本实施例中,应用密码可以但不限于由所述服务端颁发给客户端,并打包在客户端中。用户在设备中下载客户端时,该客户端中就包含了本客户端的应用密码。服务端也保存有颁发给客户端的应用密码。
本实施例中,服务端保存的颁发给客户端的应用密码,即该客户端对应的应用密码,也就是说所述第一加签因子中客户端对应的应用密码,和第二加签因子中打包在该客户端中的应用密码是相同的;也就是说,在客户端保存的服务端公钥正确的情况下,第一加签因子和第二加签因子应该是相同的;因此客户端和服务端在利用相同的预定的加签算法对同样的请求参数进行计算的情况下,得到的签名和计算结果将是相同的。
本实施例中,上述步骤S110~S120是服务端对业务请求的签名进行校验的过程;如果签名和计算结果不同,可以表明校验失败;签名和计算相同时,可以表明校验成功。
本实施例中,在数据传输过程中,由于颁发给客户端的应用密码不作为数据传输,只作为加签因子,因此黑客无法从传输的数据中拦截得到该应用密码,因此无法对客户端和服务端之间传输的数据进行劫持或篡改。即使黑客也下载了该客户端,但需要具备反编译客户端的能力,并需要能知道应用密码在客户端代码或安全文件中的位置,才能得到该应用密码,对黑客而言非常困难。在得不到加签因子之一的情况下,无法伪造出正确的签名,因此黑客发送的数据不会在服务端校验成功,即黑客无法冒充合法的客户端。而假如黑客作为中间人发送了假的服务端公钥给客户端,由于服务端公钥也是加签因子之一,因此客户端在进行业务请求时也同样无法通过服务端的校验。
本实施例中,所述应用密码保存在服务端中、打包在客户端中时可以是明文的应用密码,也可以是密文的应用密码。
本实施例中,业务请求的请求参数可以但不限于包括业务请求的长度、业务请求中某个字段的值等。
一种实现方式中,所述根据第一加签因子以及预定的加签算法,对所述业务请求的请求参数进行计算前还可以包括:
所述服务端根据预先保存的应用标识和应用密码之间的对应关系、以及所述业务请求中携带的应用标识,确定所述客户端对应的应用密码。
本实现方式中,应用标识同样可以由所述服务端颁发给客户端,并打包在客户端中。用户在设备中下载客户端时,该客户端中不仅包含本客户端的应用密码,还包括应用标识。服务端中对应保存有颁发给客户端的应用标识和应用密码,即:颁发给同一个客户端的应用标识和应用密码是对应保存的。本实现方式中,不同设备上的同一种客户端的应用标识和应用密码可以是相同的(即:每种客户端各自打包有本种类客户端的应用标识及应用密码),也可以是不同的(即:每个客户端各自打包有本客户端的应用标识及应用密码)。无论相同或不同,服务端中会保存颁发的应用标识及应用密码,其中,颁发给同一个或同一种客户端的应用标识和应用密码是对应保存的。
本实现方式中,黑客即使拦截得到应用标识,由于无法得知应用标识和应用密码之间的对应关系,所以仍无法得到客户端对应的应用密码。
其它实现方式中,服务端也可以根据客户端的唯一标识来确定客户端对应的应用密码。
一种实现方式中,所述服务端判断所述计算结果和所述业务请求的签名是否相同后还可以包括:
如果不同,则所述服务端返回表示所述服务端公钥错误的错误代码给所述客户端。
本实现方式中,计算结果和签名不同意味着有可能客户端本地保存的服务端公钥是错误的,比如已经过期,再比如是非法的。因此该情况下服务端可以先不发送业务数据,而是先告知客户端服务端公钥错误。客户端可以重新和服务端进行握手,以重新获取服务端公钥。
本实现方式中,如果计算结果和签名相同则服务端可以继续正常的业务处理过程,比如返回和所述业务请求对应的业务数据给客户端。
一种实现方式中,所述服务端收到客户端的业务请求前还可以包括:
所述服务端当和客户端建立连接握手时,将服务端公钥发送给客户端。
本实现方式中,当客户端和服务端建立连接握手时,如果中间人有监听则客户端会获取到中间人的证书和公钥,如果没有中间人监听则客户端获取到的是服务端的证书和公钥;而如果获取的是中间人公钥,当客户端发送业务请求时,签名将无法通过服务端的校验。而中间人由于无法获得应用密码,因此也无法伪造出能够通过服务端校验的签名。
实施例二、一种校验方法,如图3所示,包括S210~S220:
S210、客户端发起业务请求,根据第二加签因子以及预定的加签算法,对所述业务请求的请求参数进行计算,将计算结果作为所述业务请求的签名;所述第二加签因子包括:打包在所述客户端中的应用密码、所述客户端本地保存的服务端公钥;
S220、所述客户端将所述业务请求发送给服务端。
本实施例中,服务端收到业务请求后,可以进行实施例一的步骤S110~S120。
本实施例中,在数据传输过程中,由于打包客户端中的应用密码不作为数据传输,只作为加签因子,因此黑客无法从传输的数据中拦截得到该应用密码,因此无法对客户端和服务端之间传输的数据进行劫持或篡改。假如黑客作为中间人发送了假的服务端公钥给客户端,由于服务端公钥也是加签因子之一,因此客户端在进行业务请求时也同样无法通过服务端的校验。
一种实现方式中,所述客户端将所述业务请求发送给服务端前还可以包括:
所述客户端将打包在本客户端中的应用标识携带在所述业务请求中。
一种实现方式中,所述客户端发起业务请求前还可以包括:
所述客户端在和服务端建立连接握手时,获取服务端公钥。
本实现方式适用于客户端中没有服务端公钥的情况。
本实现方式中,当客户端和服务端建立连接握手时,如果中间人有监听则客户端会获取到中间人的证书和公钥,如果没有中间人监听则客户端获取到的是服务端的证书和公钥;而如果获取的是中间人公钥,当客户端发送业务请求时,签名将无法通过服务端的校验。而中间人由于无法获得应用密码,因此也无法伪造出能够通过服务端校验的签名。
实施例三、一种校验方法,如图4所示,包括S310~S320:
S310、客户端调用预定接口接收服务端的返回结果,所述返回结果中携带服务端公钥;其中,所述返回结果的签名由所述服务端根据第一加签因子以及预定的加签算法,对所述返回结果的参数进行计算得到;所述第一加签因子包括:所述客户端对应的应用密码、服务端公钥;
S320、所述客户端根据第三加签因子以及预定的加签算法,对所述返回结果的参数进行计算,比较计算结果和所述返回结果的签名,如果一致则保存所述返回结果中的服务端公钥;所述第三加签因子包括:打包在所述客户端中的应用密码、所述返回结果中的服务端公钥。
本实施例中,所述预定接口可以是获取服务端公钥的专用接口。
本实施例中,在数据传输过程中,由于应用密码不作为数据传输,只作为加签因子,因此黑客无法从传输的数据中拦截得到该应用密码。而即使黑客也下载了该客户端,但需要具备反编译客户端的能力,并需要能知道应用密码在客户端代码或安全文件中的位置,才能得到该应用密码,对黑客而言非常困难。在得不到加签因子之一的情况下,无法伪造出正确的签名,因此黑客发送的数据不会在客户端校验成功,即黑客无法冒充合法的服务端。由于客户端会在收到服务端公钥时进行签名校验,因此黑客在不知道加签因子之一的情况下,也无法发送假的服务端公钥给客户端。
本实施例中,返回结果的参数可以但不限于包括返回结果的长度、返回结果中某个字段的值等。
本实施例中,客户端当本地没有服务端公钥、或本地服务端公钥为非法时,进行步骤S310~S320。
一种实现方式中,所述接收服务端的返回结果前还可以包括:
所述客户端在建立握手连接时,用本地保存的根证书链校验收到的服务端证书,如果校验失败,则停止本次接口调用;如果校验成功,则继续接口调用。
一种实现方式中,所述的校验方法还可以包括:
所述客户端发起业务请求,建立握手连接时,用本地根证书链校验收到的服务端证书,获取服务端公钥;比较本地保存到服务端公钥和获取到的服务端公钥,如果一致则继续进行业务请求。
本实现方式适用于客户端本地已经保存有服务端公钥且服务端公钥为合法的情况;如果本地根证书链校验服务端证书失败,则停止业务接口的调用;如果服务端公钥和本地保存的不一致,则将本地保存的服务端公钥删除,或者将本地保存的服务端公钥的状态设置为“非法”。删除或设置为“非法”后,可以按照S310~320再请求服务端公钥。
实施例四、一种校验方法,如图5所示,包括S410~S420:
S410、服务端当客户端调用预定接口时,将服务端公钥携带在返回结果中;根据第一加签因子以及预定的加签算法,对所述返回结果的参数进行计算,将计算结果作为所述返回结果的签名;所述第一加签因子包括:所述客户端对应的应用密码、服务端公钥;
S420、所述服务端发送返回结果给所述客户端。
本实施例中,所述预定接口可以是获取服务端公钥的专用接口。
本实施方式中,在数据传输过程中,由于应用密码不作为数据传输,只作为加签因子,因此黑客无法从传输的数据中拦截得到该应用密码。而即使黑客也下载了该客户端,但需要具备反编译客户端的能力,并需要能知道应用密码在客户端代码或安全文件中的位置,才能得到该应用密码,对黑客而言非常困难。在得不到加签因子之一的情况下,无法伪造出正确的签名,因此黑客发送的数据不会在客户端校验成功,即黑客无法冒充合法的服务端。由于客户端会在收到服务端公钥时进行签名校验,因此黑客在不知道加签因子之一的情况下,也无法发送假的服务端公钥给客户端。
本实施例中,客户端接收到返回结果后的做法可参见实施例三。
一种实现方式中,所述的校验方法还可以包括:
所述服务端当客户端发起业务请求,建立握手连接时,发送包括服务端公钥的服务端证书给客户端。
本实现方式适用于客户端本地已经保存有服务端公钥且服务端公钥为合法的情况。
实施例五、一种校验方法,包括:
本实施例以HTTPS为例说明HTTPS/SSL/TLS等类似概念网络协议中的实现方案,服务端公钥为服务端HTTPS公钥。
本实施例的前提:客户端调用服务端接口,需要服务端授权,服务端给客户端颁发应用标识(可称为AppCode)、应用密码(可称为AppSecret),打包在客户端的代码或者安全文件里,类似APP应用级别的帐号和密码。客户端与服务端接口数据交互传输过程中,应用密码不需要传输,只作为请求参数签名的一个加签因子,请求/响应传输过程中,中间人无法截取到该应用密码。
本实施例有两个方案可选。一个是发起请求时,服务端HTTPS公钥在服务端校验合法性。另一个是发起请求时,服务端HTTPS公钥在客户端校验合法性。
方案一:服务端HTTPS公钥在服务端校验合法性。
客户端先判断当前本地是否存在服务端HTTPS公钥(客户端安装后第一次被使用时不存在服务端HTTPS公钥)。
1.1客户端可以发起正常业务请求。建立HTTPS握手连接时,用本地根证书链校验收到的服务端证书,如果校验失败,则停止本次请求,如果校验成功,则请求继续。但每次发起业务请求都需要把本次建立连接时获取到的服务端HTTPS公钥、和应用密码作为签名的加签因子,业务请求中携带应用标识。具体加签算法不限,除了服务端HTTPS公钥和应用密码,也可以包括其他加签因子。
1.2服务端收到业务请求后,需要用相同的加签算法判断业务请求的签名是否正确(因为服务端已知当前的服务端HTTPS公钥,根据应用标识也能获取到当前客户端的应用密码),如果正确(即计算结果和签名相同),则表明客户端存的服务端公钥是合法的。如果合法,则返回正常的业务返回值(比如但不限于业务数据),如果非法(即计算结果和签名不同,这里一般情况是服务端HTTPS公钥更新后导致客户端本地的已过期),则返回表示服务端HTTPS公钥错误的错误码。
本方案中,客户端建立连接握手时,获取到服务端证书。此时拿到的服务端HTTPS公钥可能是正确的服务端HTTPS公钥,也可能是中间人的HTTPS公钥。但因为公钥在服务端校验,所以不会造成安全漏洞,可参考1.2的做法。
在服务端校验的方案如图6所示,客户端进行业务请求时,将应用密码和服务端公钥等作为请求参数的加签因子,得到业务请求的签名;服务端校验签名,如果校验成功,则正常返回业务数据,客户端后续执行正常处理;如果校验失败,则不返回业务数据。
在该方案中,由于中间人无法得知应用密码这个加签因子,因此无法篡改签名和服务端HTTPS公钥。
方案二:服务端HTTPS公钥在客户端校验合法性。
客户端先判断当前本地是否存在服务端HTTPS公钥,并且状态为合法(客户端安装后第一次被使用时不存在服务端HTTPS公钥)。
1、如果客户端本地已存在服务端HTTPS公钥,且状态为合法。
客户端可以发起正常业务请求,建立HTTPS握手连接时,用本地根证书链校验收到的服务端证书,获取到服务端HTTPS公钥,并用本地的服务端HTTPS公钥校验服务端HTTPS公钥(即:比较是否相同),如果服务端证书和服务端HTTPS公钥都校验成功,则走正常业务接口流程。如果用本地根证书链校验服务端证书失败,则停止本次业务接口调用,不修改本地服务端公钥的状态。如果本地服务端公钥校验失败,则把本地服务端公钥设置成非法状态(或者直接删除),并停止业务接口调用。
2、如果客户端本地不存在服务端HTTPS公钥,或者存在但状态为非法。
客户端不能发起业务请求调用。只能指定调用一个获取服务端HTTPS公钥的专用接口。建立HTTPS握手连接时,用本地根证书链校验收到的服务端证书,如果校验失败,则停止本次接口调用。如果校验成功,则继续接口调用,服务端返回当前的服务端HTTPS公钥(返回结果需要根据客户端对应的应用密码、服务端公钥等数据作为加签因子生成签名,因为中间人不知道应用密码所以签名无法伪造)。客户端校验签名是否合法(即采用和服务端相同的加签算法,用返回的服务端公钥、打包在本客户端的应用密码作为加签因子进行计算,计算结果和签名相同则合法),如果合法则把返回的服务端HTTPS公钥保存或替换本地公钥(状态设置为合法),接下来可以正常请求业务接口。如果不合法则忽略返回值,下次还是只能调用获取服务端HTTPS公钥的专用接口,跟本项流程一致,直到返回合法的服务端HTTPS公钥。
客户端中公钥不存在或公钥非法时在客户端校验的方案的情况如图7(a)所示,客户端调用获取服务端HTTPS公钥的专用接口;服务端返回服务端HTTPS公钥,将应用密码和服务端HTTPS公钥等作为加签因子;客户端校验签名,如果签名合法,则保存返回的服务端HTTPS公钥,如果本地原先保存有服务端HTTPS公钥,则用返回的服务端HTTPS公钥替换本地保存的服务端HTTPS公钥。
客户端中存在合法公钥时在客户端校验的方案的情况如图7(b)所示,建立HTTPS握手连接时,判断服务端HTTPS公钥是否和本地保存的服务端HTTPS公钥一致;如果一致则继续请求;如果不一致则停止请求,删除本地服务端HTTPS公钥或设置为非法。
在该方案中,同样地,由于中间人无法得知应用密码这个加签因子,因此无法篡改接口签名和服务端HTTPS公钥。
实施例六、一种校验装置,如图8所示,包括:
计算模块61,用于在收到客户端的业务请求后,根据第一加签因子以及预定的加签算法,对所述业务请求的请求参数进行计算,得到计算结果;所述第一加签因子包括:所述客户端对应的应用密码、服务端公钥;
判断模块62,用于判断所述计算结果和所述业务请求的签名是否相同;其中,所述业务请求的签名由所述客户端根据第二加签因子以及预定的加签算法,对所述业务请求的请求参数进行计算得到;所述第二加签因子包括:打包在所述客户端中的应用密码、所述客户端本地保存的服务端公钥。
本实施例中,计算模块61是上述校验装置中负责对请求参数进行计算的部分,可以是软件、硬件或两者的结合。
本实施例中,判断模块62是上述校验装置中负责判断计算结果和签名是否相同的部分,可以是软件、硬件或两者的结合。
本实施例的校验装置可以实现实施例一中的所述服务端的功能。
一种实现方式中,所述计算模块还可以用于在根据第一加签因子以及预定的加签算法,对所述业务请求的请求参数进行计算前,根据预先保存的应用标识和应用密码之间的对应关系、以及所述业务请求中携带的应用标识,确定所述客户端对应的应用密码。
一种实现方式中,本实施例所述的校验装置还可以包括:
反馈模块,用于在所述计算模块收到客户端的业务请求前,当和所述客户端建立连接握手时,发送所述服务端公钥给所述客户端。
本实施例的各模块的操作可以对应于实施例一的步骤S110~S120,其它实现细节可参见实施例一。
实施例七、一种校验装置,如图9所示,包括:
签名模块71,用于发起业务请求,根据第二加签因子以及预定的加签算法,对所述业务请求的请求参数进行计算,将计算结果作为所述业务请求的签名;所述第二加签因子包括:打包在客户端中的应用密码、本地保存的服务端公钥;
发送模块72,用于将所述业务请求发送给服务端。
本实施例中,签名模块71是上述校验装置中负责对业务请求进行签名的部分,可以是软件、硬件或两者的结合。
本实施例中,判断模块62是上述校验装置中负责发送业务请求的部分,可以是软件、硬件或两者的结合。
本实施例的校验装置可以实现实施例二中的所述客户端的功能。
一种实现方式中,所述签名模块还可以用于将打包在客户端中的应用标识携带在所述业务请求中。
一种实现方式中,所述的校验装置还可以包括:
获取模块,用于在所述签名模块发起业务请求前,当和服务端建立连接握手时,获取服务端公钥。
本实施例的各模块的操作可以对应于实施例二的步骤S210~S220,其它实现细节可参见实施例二。
实施例八、一种校验装置,如图10所示,包括:
调用模块81,用于调用预定接口接收服务端的返回结果,所述返回结果中携带服务端公钥;其中,所述返回结果的签名由所述服务端根据第一加签因子以及预定的加签算法,对所述返回结果的参数进行计算得到;所述第一加签因子包括:所述客户端对应的应用密码、服务端公钥;
比较模块82,用于根据第三加签因子以及预定的加签算法,对所述返回结果的参数进行计算,比较计算结果和所述返回结果的签名,如果一致则保存所述返回结果中的服务端公钥;所述第三加签因子包括:打包在所述客户端中的应用密码、所述返回结果中的服务端公钥。
本实施例中,调用模块81是上述校验装置中负责调用接口接收返回结果的部分,可以是软件、硬件或两者的结合。
本实施例中,比较模块82是上述校验装置中负责校验返回结果的签名的部分,可以是软件、硬件或两者的结合。
本实施例的校验装置可以实现实施例三中的所述客户端的功能。
一种实现方式中,所述调用模块还可以用于在接收服务端的返回结果前,在建立握手连接时,用本地保存的根证书链校验收到的服务端证书,如果校验失败,则停止本次接口调用;如果校验成功,则继续接口调用。
一种实现方式中,本实施例所述的校验装置还可以包括:
校验模块,用于在发起业务请求,建立握手连接时,用本地根证书链校验收到的服务端证书,获取服务端公钥;比较本地保存到服务端公钥和获取到的服务端公钥,如果一致则继续进行业务请求。
本实施例的各模块的操作可以对应于实施例三的步骤S310~S320,其它实现细节可参见实施例三。
实施例九、一种校验装置,如图11所示,包括:
加签模块91,用于当客户端调用预定接口时,将服务端公钥携带在返回结果中;根据第一加签因子以及预定的加签算法,对所述返回结果的参数进行计算,将计算结果作为所述返回结果的签名;所述第一加签因子包括:所述客户端对应的应用密码、服务端公钥;
返回模块92,用于发送所述返回结果给所述客户端。
本实施例中,加签模块91是上述校验装置中负责携带服务端公钥的部分,可以是软件、硬件或两者的结合。
本实施例中,返回模块92是上述校验装置中负责发送返回结果的签名的部分,可以是软件、硬件或两者的结合。
本实施例的校验装置可以实现实施例四中的所述服务端的功能。
一种实现方式中,所述返回模块还可以用于当客户端发起业务请求,建立握手连接时,发送包括服务端公钥的服务端证书给客户端。
本实施例的各模块的操作可以对应于实施例四的步骤S410~S420,其它实现细节可参见实施例四。
实施例十、一种进行校验的电子设备,包括:第一处理器和第一存储器;
所述第一存储器用于保存用于进行校验的程序;所述用于进行校验的程序在被所述第一处理器读取执行时,执行以下操作:
收到客户端的业务请求后,根据第一加签因子以及预定的加签算法,对所述业务请求的请求参数进行计算,得到计算结果;所述第一加签因子包括:所述客户端对应的应用密码、服务端公钥;
判断所述计算结果和所述业务请求的签名是否相同;其中,所述业务请求的签名由所述客户端根据第二加签因子以及预定的加签算法,对所述业务请求的请求参数进行计算得到;所述第二加签因子包括:打包在所述客户端中的应用密码、所述客户端本地保存的服务端公钥。
本实施例的电子设备可以作为运行实施例一中的服务端的设备;本实施例的用于进行校验的程序在被读取执行时进行的操作可以对应于实施例一的步骤S110~S120,其它实现细节可参见实施例一。
实施例十一、一种进行校验的电子设备,包括:第二处理器和第二存储器;
所述第二存储器用于保存用于进行校验的程序;所述用于进行校验的程序在被所述第二处理器读取执行时,执行以下操作:
发起业务请求,根据第二加签因子以及预定的加签算法,对所述业务请求的请求参数进行计算,将计算结果作为所述业务请求的签名;所述第二加签因子包括:打包在所述客户端中的应用密码、所述客户端本地保存的服务端公钥;
将所述业务请求发送给服务端。
本实施例的电子设备可以作为运行实施例二中的客户端的设备;本实施例的用于进行校验的程序在被读取执行时进行的操作可以对应于实施例二的步骤S210~S220,其它实现细节可参见实施例二。
实施例十二、一种进行校验的电子设备,包括:第三处理器和第三存储器;
所述第三存储器用于保存用于进行校验的程序;所述用于进行校验的程序在被所述第三处理器读取执行时,执行以下操作:
调用预定接口接收服务端的返回结果,所述返回结果中携带服务端公钥;其中,所述返回结果的签名由所述服务端根据第一加签因子以及预定的加签算法,对所述返回结果的参数进行计算得到;所述第一加签因子包括:所述客户端对应的应用密码、服务端公钥;
根据第三加签因子以及预定的加签算法,对所述返回结果的参数进行计算,比较计算结果和所述返回结果的签名,如果一致则保存所述返回结果中的服务端公钥;所述第三加签因子包括:打包在所述客户端中的应用密码、所述返回结果中的服务端公钥。
本实施例的电子设备可以作为运行实施例三中的客户端的设备;本实施例的用于进行校验的程序在被读取执行时进行的操作可以对应于实施例三的步骤S310~S320,其它实现细节可参见实施例三。
实施例十三、一种进行校验的电子设备,包括:第四处理器和第四存储器;
所述第四存储器用于保存用于进行校验的程序;所述用于进行校验的程序在被所述第四处理器读取执行时,执行以下操作:
当客户端调用预定接口时,将服务端公钥携带在返回结果中;根据第一加签因子以及预定的加签算法,对所述返回结果的参数进行计算,将计算结果作为所述返回结果的签名;所述第一加签因子包括:所述客户端对应的应用密码、服务端公钥;
发送所述返回结果给所述客户端。
本实施例的电子设备可以作为运行实施例四中的服务端的设备;本实施例的用于进行校验的程序在被读取执行时进行的操作可以对应于实施例四的步骤S410~S420,其它实现细节可参见实施例四。
本领域普通技术人员可以理解上述方法中的全部或部分步骤可通过程序来指令相关硬件完成,所述程序可以存储于计算机可读存储介质中,如只读存储器、磁盘或光盘等。可选地,上述实施例的全部或部分步骤也可以使用一个或多个集成电路来实现。相应地,上述实施例中的各模块/单元可以采用硬件的形式实现,也可以采用软件功能模块的形式实现。本申请不限制于任何特定形式的硬件和软件的结合。
当然,本申请还可有其他多种实施例,在不背离本申请精神及其实质的情况下,熟悉本领域的技术人员当可根据本申请作出各种相应的改变和变形,但这些相应的改变和变形都应属于本申请的权利要求的保护范围。
Claims (26)
1.一种校验方法,包括:
服务端收到客户端的业务请求后,根据第一加签因子以及预定的加签算法,对所述业务请求的请求参数进行计算,得到计算结果;所述第一加签因子包括:所述客户端对应的应用密码、服务端公钥;
所述服务端判断所述计算结果和所述业务请求的签名是否相同;其中,所述业务请求的签名由所述客户端根据第二加签因子以及预定的加签算法,对所述业务请求的请求参数进行计算得到;所述第二加签因子包括:打包在所述客户端中的应用密码、所述客户端本地保存的服务端公钥;
其中,所述应用密码由所述服务端颁发给所述客户端,所述服务端也保存有颁发给所述客户端的所述应用密码。
2.如权利要求1所述的校验方法,其特征在于,所述根据第一加签因子以及预定的加签算法,对所述业务请求的请求参数进行计算前还包括:
所述服务端根据预先保存的应用标识和应用密码之间的对应关系、以及所述业务请求中携带的应用标识,确定所述客户端对应的应用密码。
3.如权利要求1所述的校验方法,其特征在于,所述服务端收到客户端的业务请求前还包括:
所述服务端当和所述客户端建立连接握手时,将服务端公钥发送给所述客户端。
4.一种校验方法,包括:
客户端发起业务请求,根据第二加签因子以及预定的加签算法,对所述业务请求的请求参数进行计算,将计算结果作为所述业务请求的签名;所述第二加签因子包括:打包在所述客户端中的应用密码、所述客户端本地保存的服务端公钥;
所述客户端将所述业务请求发送给服务端;
其中,所述应用密码由所述服务端颁发给所述客户端,所述服务端也保存有颁发给所述客户端的所述应用密码。
5.如权利要求4所述的校验方法,其特征在于,所述客户端将所述业务请求发送给服务端前还包括:
所述客户端将打包在本客户端中的应用标识携带在所述业务请求中。
6.如权利要求4所述的校验方法,其特征在于,所述客户端发起业务请求前还包括:
所述客户端在和所述服务端建立连接握手时,获取服务端公钥。
7.一种校验方法,包括:
客户端调用预定接口接收服务端的返回结果,所述返回结果中携带服务端公钥;其中,所述返回结果的签名由所述服务端根据第一加签因子以及预定的加签算法,对所述返回结果的参数进行计算得到;所述第一加签因子包括:所述客户端对应的应用密码、服务端公钥;
所述客户端根据第三加签因子以及预定的加签算法,对所述返回结果的参数进行计算,比较计算结果和所述返回结果的签名,如果一致则保存所述返回结果中的服务端公钥;所述第三加签因子包括:打包在所述客户端中的应用密码、所述返回结果中的服务端公钥;
其中,所述应用密码由所述服务端颁发给所述客户端,所述服务端也保存有颁发给所述客户端的所述应用密码。
8.如权利要求7所述的校验方法,其特征在于,所述接收服务端的返回结果前还包括:
所述客户端在建立握手连接时,用本地保存的根证书链校验收到的服务端证书,如果校验失败,则停止本次接口调用;如果校验成功,则继续接口调用。
9.如权利要求7所述的校验方法,其特征在于,还包括:
所述客户端发起业务请求,建立握手连接时,用本地根证书链校验收到的服务端证书,获取服务端公钥;比较本地保存到服务端公钥和获取到的服务端公钥,如果一致则继续进行业务请求。
10.一种校验方法,包括:
服务端当客户端调用预定接口时,将服务端公钥携带在返回结果中;根据第一加签因子以及预定的加签算法,对所述返回结果的参数进行计算,将计算结果作为所述返回结果的签名;所述第一加签因子包括:所述客户端对应的应用密码、服务端公钥;
所述服务端发送所述返回结果给所述客户端;
其中,所述应用密码由所述服务端颁发给所述客户端,所述服务端也保存有颁发给所述客户端的所述应用密码。
11.如权利要求10所述的校验方法,其特征在于,还包括:
所述服务端当客户端发起业务请求,建立握手连接时,发送包括服务端公钥的服务端证书给客户端。
12.一种校验装置,其特征在于,包括:
计算模块,用于在收到客户端的业务请求后,根据第一加签因子以及预定的加签算法,对所述业务请求的请求参数进行计算,得到计算结果;所述第一加签因子包括:所述客户端对应的应用密码、服务端公钥;
判断模块,用于判断所述计算结果和所述业务请求的签名是否相同;其中,所述业务请求的签名由所述客户端根据第二加签因子以及预定的加签算法,对所述业务请求的请求参数进行计算得到;所述第二加签因子包括:打包在所述客户端中的应用密码、所述客户端本地保存的服务端公钥;
其中,所述应用密码由所述服务端颁发给所述客户端,所述服务端也保存有颁发给所述客户端的所述应用密码。
13.如权利要求12所述的校验装置,其特征在于:
所述计算模块还用于在根据第一加签因子以及预定的加签算法,对所述业务请求的请求参数进行计算前,根据预先保存的应用标识和应用密码之间的对应关系、以及所述业务请求中携带的应用标识,确定所述客户端对应的应用密码。
14.如权利要求13所述的校验装置,其特征在于,还包括:
反馈模块,用于在所述计算模块收到客户端的业务请求前,当和所述客户端建立连接握手时,发送所述服务端公钥给所述客户端。
15.一种校验装置,其特征在于,包括:
签名模块,用于发起业务请求,根据第二加签因子以及预定的加签算法,对所述业务请求的请求参数进行计算,将计算结果作为所述业务请求的签名;所述第二加签因子包括:打包在客户端中的应用密码、本地保存的服务端公钥;
发送模块,用于将所述业务请求发送给服务端;
其中,所述应用密码由所述服务端颁发给所述客户端,所述服务端也保存有颁发给所述客户端的所述应用密码。
16.如权利要求15所述的校验装置,其特征在于,所述签名模块还用于将打包在客户端中的应用标识携带在所述业务请求中。
17.如权利要求15所述的校验装置,其特征在于,还包括:
获取模块,用于在所述签名模块发起业务请求前,当和所述服务端建立连接握手时,获取服务端公钥。
18.一种校验装置,其特征在于,包括:
调用模块,用于调用预定接口接收服务端的返回结果,所述返回结果中携带服务端公钥;其中,所述返回结果的签名由所述服务端根据第一加签因子以及预定的加签算法,对所述返回结果的参数进行计算得到;所述第一加签因子包括:客户端对应的应用密码、服务端公钥;
比较模块,用于根据第三加签因子以及预定的加签算法,对所述返回结果的参数进行计算,比较计算结果和所述返回结果的签名,如果一致则保存所述返回结果中的服务端公钥;所述第三加签因子包括:打包在所述客户端中的应用密码、所述返回结果中的服务端公钥;
其中,所述应用密码由所述服务端颁发给所述客户端,所述服务端也保存有颁发给所述客户端的所述应用密码。
19.如权利要求18所述的校验装置,其特征在于:
所述调用模块还用于在接收服务端的返回结果前,在建立握手连接时,用本地保存的根证书链校验收到的服务端证书,如果校验失败,则停止本次接口调用;如果校验成功,则继续接口调用。
20.如权利要求18所述的校验装置,其特征在于,还包括:
校验模块,用于在发起业务请求,建立握手连接时,用本地根证书链校验收到的服务端证书,获取服务端公钥;比较本地保存到服务端公钥和获取到的服务端公钥,如果一致则继续进行业务请求。
21.一种校验装置,其特征在于,包括:
加签模块,用于当客户端调用预定接口时,将服务端公钥携带在返回结果中;根据第一加签因子以及预定的加签算法,对所述返回结果的参数进行计算,将计算结果作为所述返回结果的签名;所述第一加签因子包括:所述客户端对应的应用密码、服务端公钥;
返回模块,用于发送所述返回结果给所述客户端;
其中,所述应用密码由所述服务端颁发给所述客户端,所述服务端也保存有颁发给所述客户端的所述应用密码。
22.如权利要求21所述的校验装置,其特征在于:
所述返回模块还用于当客户端发起业务请求,建立握手连接时,发送包括服务端公钥的服务端证书给客户端。
23.一种进行校验的电子设备,包括:第一处理器和第一存储器;
其特征在于:
所述第一存储器用于保存用于进行校验的程序;所述用于进行校验的程序在被所述第一处理器读取执行时,执行以下操作:
收到客户端的业务请求后,根据第一加签因子以及预定的加签算法,对所述业务请求的请求参数进行计算,得到计算结果;所述第一加签因子包括:所述客户端对应的应用密码、服务端公钥;
判断所述计算结果和所述业务请求的签名是否相同;其中,所述业务请求的签名由所述客户端根据第二加签因子以及预定的加签算法,对所述业务请求的请求参数进行计算得到;所述第二加签因子包括:打包在所述客户端中的应用密码、所述客户端本地保存的服务端公钥;
其中,所述应用密码由所述服务端颁发给所述客户端,所述服务端也保存有颁发给所述客户端的所述应用密码。
24.一种进行校验的电子设备,包括:第二处理器和第二存储器;
其特征在于:
所述第二存储器用于保存用于进行校验的程序;所述用于进行校验的程序在被所述第二处理器读取执行时,执行以下操作:
发起业务请求,根据第二加签因子以及预定的加签算法,对所述业务请求的请求参数进行计算,将计算结果作为所述业务请求的签名;所述第二加签因子包括:打包在客户端中的应用密码、所述客户端本地保存的服务端公钥;
将所述业务请求发送给服务端;
其中,所述应用密码由所述服务端颁发给所述客户端,所述服务端也保存有颁发给所述客户端的所述应用密码。
25.一种进行校验的电子设备,包括:第三处理器和第三存储器;
其特征在于:
所述第三存储器用于保存用于进行校验的程序;所述用于进行校验的程序在被所述第三处理器读取执行时,执行以下操作:
调用预定接口接收服务端的返回结果,所述返回结果中携带服务端公钥;其中,所述返回结果的签名由所述服务端根据第一加签因子以及预定的加签算法,对所述返回结果的参数进行计算得到;所述第一加签因子包括:客户端对应的应用密码、服务端公钥;
根据第三加签因子以及预定的加签算法,对所述返回结果的参数进行计算,比较计算结果和所述返回结果的签名,如果一致则保存所述返回结果中的服务端公钥;所述第三加签因子包括:打包在所述客户端中的应用密码、所述返回结果中的服务端公钥;
其中,所述应用密码由所述服务端颁发给所述客户端,所述服务端也保存有颁发给所述客户端的所述应用密码。
26.一种进行校验的电子设备,包括:第四处理器和第四存储器;
其特征在于:
所述第四存储器用于保存用于进行校验的程序;所述用于进行校验的程序在被所述第四处理器读取执行时,执行以下操作:
当客户端调用预定接口时,将服务端公钥携带在返回结果中;根据第一加签因子以及预定的加签算法,对所述返回结果的参数进行计算,将计算结果作为所述返回结果的签名;所述第一加签因子包括:所述客户端对应的应用密码、服务端公钥;
发送所述返回结果给所述客户端;
其中,所述应用密码由所述服务端颁发给所述客户端,所述服务端也保存有颁发给所述客户端的所述应用密码。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201611044124.5A CN108092775B (zh) | 2016-11-23 | 2016-11-23 | 一种校验方法及装置、电子设备 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201611044124.5A CN108092775B (zh) | 2016-11-23 | 2016-11-23 | 一种校验方法及装置、电子设备 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN108092775A CN108092775A (zh) | 2018-05-29 |
CN108092775B true CN108092775B (zh) | 2021-04-23 |
Family
ID=62170943
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201611044124.5A Active CN108092775B (zh) | 2016-11-23 | 2016-11-23 | 一种校验方法及装置、电子设备 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN108092775B (zh) |
Families Citing this family (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109525554B (zh) * | 2018-10-12 | 2022-07-08 | 平安科技(深圳)有限公司 | 金融数据通信方法、装置、介质及电子设备 |
CN111314309B (zh) * | 2020-01-19 | 2022-04-15 | 中信银行股份有限公司 | 数据传输方法、装置、电子设备及计算机可读存储介质 |
CN111291393A (zh) * | 2020-01-21 | 2020-06-16 | 上海悦易网络信息技术有限公司 | 请求校验方法及设备 |
CN112737790B (zh) * | 2020-12-30 | 2023-04-07 | 北京天融信网络安全技术有限公司 | 数据传输方法、装置及服务器、客户终端 |
CN113221154A (zh) * | 2021-06-01 | 2021-08-06 | 平安信托有限责任公司 | 服务密码获取方法、装置、电子设备及存储介质 |
CN113872935A (zh) * | 2021-08-24 | 2021-12-31 | 青岛海尔科技有限公司 | 数据校验方法、装置、存储介质及电子装置 |
CN114844651B (zh) * | 2022-05-31 | 2024-05-28 | 唯思电子商务(深圳)有限公司 | 一种app客户端https证书强校验的方法及系统 |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102222390A (zh) * | 2011-06-30 | 2011-10-19 | 飞天诚信科技股份有限公司 | 一种多功能智能密钥装置及其工作方法 |
CN103095456A (zh) * | 2013-01-10 | 2013-05-08 | 天地融科技股份有限公司 | 交易报文的处理方法和系统 |
CN105827411A (zh) * | 2016-03-11 | 2016-08-03 | 联想(北京)有限公司 | 一种信息处理的方法及装置 |
CN106100848A (zh) * | 2016-06-14 | 2016-11-09 | 东北大学 | 基于智能手机和用户口令的双因子身份认证系统及方法 |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9489785B2 (en) * | 2013-03-14 | 2016-11-08 | Covidien Lp | RFID secure authentication |
-
2016
- 2016-11-23 CN CN201611044124.5A patent/CN108092775B/zh active Active
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102222390A (zh) * | 2011-06-30 | 2011-10-19 | 飞天诚信科技股份有限公司 | 一种多功能智能密钥装置及其工作方法 |
CN103095456A (zh) * | 2013-01-10 | 2013-05-08 | 天地融科技股份有限公司 | 交易报文的处理方法和系统 |
CN105827411A (zh) * | 2016-03-11 | 2016-08-03 | 联想(北京)有限公司 | 一种信息处理的方法及装置 |
CN106100848A (zh) * | 2016-06-14 | 2016-11-09 | 东北大学 | 基于智能手机和用户口令的双因子身份认证系统及方法 |
Also Published As
Publication number | Publication date |
---|---|
CN108092775A (zh) | 2018-05-29 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN108092775B (zh) | 一种校验方法及装置、电子设备 | |
CN107135073B (zh) | 接口调用方法和装置 | |
EP3453136B1 (en) | Methods and apparatus for device authentication and secure data exchange between a server application and a device | |
CN106487774B (zh) | 一种云主机服务权限控制方法、装置和系统 | |
US9003519B2 (en) | Verifying transactions using out-of-band devices | |
CN110300096B (zh) | 基于本地证书的自校验方法、装置、设备及存储介质 | |
EP2743827A1 (en) | Software upgrading system and method, and server and client | |
CN107124431A (zh) | 鉴权方法、装置、计算机可读存储介质和鉴权系统 | |
CN114900338A (zh) | 一种加密解密方法、装置、设备和介质 | |
US20170070486A1 (en) | Server public key pinning by url | |
CN104753674A (zh) | 一种应用身份的验证方法和设备 | |
CN111447184A (zh) | 单点登录方法及装置、系统、计算机可读存储介质 | |
CN110247897B (zh) | 一种系统登录方法、设备、网关及计算机可读存储介质 | |
CN112968910B (zh) | 一种防重放攻击方法和装置 | |
CN111460410A (zh) | 服务器登录方法、装置、系统与计算机可读存储介质 | |
CN113051539B (zh) | 一种数字证书的调用方法及装置 | |
US11153099B2 (en) | Reestablishing secure communication with a server after the server's certificate is renewed with a certificate authority unknown to the client | |
CN114944921A (zh) | 登录认证方法、装置、电子设备及存储介质 | |
CN116827551A (zh) | 一种防止全局越权的方法及装置 | |
JP6343928B2 (ja) | 携帯端末、認証システム、認証方法、および、認証プログラム | |
CN110830465B (zh) | 一种访问UKey的安全防护方法、服务器和客户端 | |
US10375056B2 (en) | Providing a secure communication channel during active directory disaster recovery | |
CN111953477A (zh) | 终端设备及其标识令牌的生成方法和客户端的交互方法 | |
KR101286767B1 (ko) | 동적 해싱을 이용한 애플리케이션 프로그램 검증 방법 | |
CN112464225A (zh) | 一种请求处理方法、请求处理装置及计算机可读存储介质 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |