CN106712937A - 数据的签名方法、装置及*** - Google Patents

数据的签名方法、装置及*** Download PDF

Info

Publication number
CN106712937A
CN106712937A CN201611205462.2A CN201611205462A CN106712937A CN 106712937 A CN106712937 A CN 106712937A CN 201611205462 A CN201611205462 A CN 201611205462A CN 106712937 A CN106712937 A CN 106712937A
Authority
CN
China
Prior art keywords
signed
data
transaction message
signature
heading
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.)
Pending
Application number
CN201611205462.2A
Other languages
English (en)
Inventor
胡伯良
管延军
蒋红宇
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Haitai Fangyuan High Technology Co Ltd
Original Assignee
Beijing Haitai Fangyuan High Technology Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Beijing Haitai Fangyuan High Technology Co Ltd filed Critical Beijing Haitai Fangyuan High Technology Co Ltd
Priority to CN201611205462.2A priority Critical patent/CN106712937A/zh
Publication of CN106712937A publication Critical patent/CN106712937A/zh
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • H04L69/162—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields involving adaptations of sockets based mechanisms
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • 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/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/562—Brokering proxy services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • 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/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

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

本发明公开了一种数据的签名方法、装置及***。其中，该方法包括：获取待签名的数据；判断待签名的数据是否满足预设条件；如果待签名的数据满足预设条件，则确定待签名的数据为认证数据，并对认证数据进行签名，得到第一签名结果；如果待签名的数据不满足预设条件，则确定待签名的数据为交易报文，并对交易报文进行签名，得到第二签名结果。本发明解决了现有技术中通过椭圆曲线算法对数据进行签名，无法判断数据是认证数据还是交易报文数据的技术问题。

Description

数据的签名方法、装置及***
技术领域
本发明涉及信息安全领域，具体而言，涉及一种数据的签名方法、装置及***。
背景技术
网上银行***中所使用的显示型USBKey，主要完成两种签名操作，一种是在SSL(安全套接层协议，Security Socket Layer的简写)双向认证时，利用私钥对认证服务器发过来的认证数据进行签名；另外一种是在转账交易时，对交易报文进行签名，为了到达所见即所签的目的，在使用显示型USBKey进行转账交易时，交易报文一般采用XML(可扩展标记语言，Extensible Markup Language的简写)的格式，如下所示，
USBKey在处理这些交易报文时，一方面将转入账号、转账金额等关键交易信息显示在显示屏上，供用户确认；另一方面，对交易报文的所有数据进行HASH(哈希)运算，当用户按下USBKey的确认按键时，利用私钥对交易报文的HASH结果进行签名，交易报文和签名结果一并发到银行服务器中，银行服务器验证无误后再进行实际的转账。为了防止黑客利用SSL签名伪造交易签名，USBKey需提供一种区分这两种签名的机制，在RSA体系中，业内的通常做法是：对于SSL签名，中间件利用SHA1算法(安全哈希算法，Secure Hash Algorithm的简写)对待签明文进行HASH运算，HASH结果发送给USBKey进行签名，对于交易签名，USBKey内部利用SHA256算法对交易报文进行HASH运算，再对HASH结果进行签名。在SM2(椭圆曲线算法)体系中，与签名配套使用的HASH算法只有SM3(密码杂凑算法)，无法采用RSA体系中通过不同的HASH算法区分SSL签名和交易签名的方法。为了达到区分SSL签名和交易签名，目前通用的做法是：在USBKey中下载两张证书，一张为RSA证书，另一张为SM2证书，SSL签名时使用RSA证书所关联的RSA私钥，交易签名时采用SM2证书所关联的SM2私钥。
针对现有技术中通过椭圆曲线算法对数据进行签名，无法判断数据是认证数据还是交易报文数据的问题，目前尚未提出有效的解决方案。
发明内容
本发明实施例提供了一种数据的签名方法、装置及***，以至少解决现有技术中通过椭圆曲线算法对数据进行签名，无法判断数据是认证数据还是交易报文数据的技术问题。
根据本发明实施例的一个方面，提供了一种数据的签名方法，包括：获取待签名的数据；判断待签名的数据是否满足预设条件；如果待签名的数据满足预设条件，则确定待签名的数据为认证数据，并对认证数据进行签名，得到第一签名结果；如果待签名的数据不满足预设条件，则确定待签名的数据为交易报文，并对交易报文进行签名，得到第二签名结果。
进一步地，判断待签名的数据是否满足预设条件包括：判断待签名的数据是否包含交易报文的报文头；如果待签名的数据不包含交易报文的报文头，则确定待签名的数据满足预设条件；如果待签名的数据包含交易报文的报文头，则确定待签名的数据不满足预设条件。
进一步地，判断待签名的数据是否包含交易报文的报文头包括：获取待签名的数据中从第一个字符开始的预设个数的字符；判断预设个数的字符与交易报文的报文头是否相同；如果预设个数的字符与交易报文的报文头相同，则确定待签名的数据包含交易报文的报文头；如果预设个数的字符与交易报文的报文头不同，则确定待签名的数据不包含交易报文的报文头。
进一步地，对认证数据进行签名，得到第一签名结果包括：基于密码杂凑算法，计算认证数据的哈希值，得到第一哈希值；基于椭圆曲线算法，对第一哈希值进行签名，得到第一签名结果。
进一步地，对交易报文进行签名，得到第二签名结果包括：显示交易报文中的关键交易信息；在接收到确认信息之后，基于密码杂凑算法，计算交易报文的哈希值，得到第二哈希值，其中，确认信息用于表征关键交易信息正确；基于椭圆曲线算法，对第二哈希值进行签名，得到第二签名结果。
进一步地，获取待签名的数据包括：接收中间件发送的待签名的数据。
进一步地，在对认证数据进行签名，得到第一签名结果，或对交易报文进行签名，得到第二签名结果之后，上述方法还包括：将第一签名结果或第二签名结果返回至中间件。
根据本发明实施例的另一方面，还提供了一种数据的签名装置，包括：获取单元，用于获取待签名的数据；第一判断单元，用于判断待签名的数据是否满足预设条件；第一签名单元，用于如果待签名的数据满足预设条件，则确定待签名的数据为认证数据，并对认证数据进行签名，得到第一签名结果；第二签名单元，用于如果待签名的数据不满足预设条件，则确定待签名的数据为交易报文，并对交易报文进行签名，得到第二签名结果。
进一步地，第一判断单元包括：判断模块，用于判断待签名的数据是否包含交易报文的报文头；第一确定模块，用于如果待签名的数据不包含交易报文的报文头，则确定待签名的数据满足预设条件；第二确定模块，用于如果待签名的数据包含交易报文的报文头，则确定待签名的数据不满足预设条件。
进一步地，判断模块包括：获取子模块，用于获取待签名的数据中从第一个字符开始的预设个数的字符；判断子模块，用于判断预设个数的字符与交易报文的报文头是否相同；第一确定子模块，用于如果预设个数的字符与交易报文的报文头相同，则确定待签名的数据包含交易报文的报文头；第二确定子模块，用于如果预设个数的字符与交易报文的报文头不同，则确定待签名的数据不包含交易报文的报文头。
进一步地，第一签名单元包括：第一计算模块，用于基于密码杂凑算法，计算认证数据的哈希值，得到第一哈希值；第一签名模块，用于基于椭圆曲线算法，对第一哈希值进行签名，得到第一签名结果。
进一步地，第二签名单元包括：显示模块，用于显示交易报文中的关键交易信息；第二计算模块，用于在接收到确认信息之后，基于密码杂凑算法，计算交易报文的哈希值，得到第二哈希值，其中，确认信息用于表征关键交易信息正确；第二签名模块，用于基于椭圆曲线算法，对第二哈希值进行签名，得到第二签名结果。
进一步地，获取单元包括：接收模块，用于接收中间件发送的待签名的数据。
进一步地，上述装置还包括：返回模块，用于将第一签名结果或第二签名结果返回至中间件。
根据本发明实施例的另一方面，还提供了一种数据的签名***，包括：中间件，用于发送待签名的数据；签名装置，与中间件具有通信关系，用于判断待签名的数据是否满足预设条件，如果待签名的数据满足预设条件，则确定待签名的数据为认证数据，并对认证数据进行签名，得到第一签名结果，如果待签名的数据不满足预设条件，则确定待签名的数据为交易报文，并对交易报文进行签名，得到第二签名结果。
进一步地，签名装置还用于发送第一签名结果或第二签名结果至中间件。
在本发明实施例中，获取待签名的数据，判断待签名的数据是否满足预设条件，如果待签名的数据满足预设条件，则确定待签名的数据为认证数据，并对认证数据进行签名，得到第一签名结果，如果待签名的数据不满足预设条件，则确定待签名的数据为交易报文，并对交易报文进行签名，得到第二签名结果，从而实现通过SM2算法对数据进行签名。容易注意到的是，在获取到待签名的数据之后，可以判断待签名的数据是否满足预设条件，从而确定待签名的数据是认证数据还是交易报文，实现了通过SM2算法对数据进行签名的过程中区分SSL签名和交易签名，解决了现有技术中通过椭圆曲线算法对数据进行签名，无法判断数据是认证数据还是交易报文数据的技术问题。因此，通过本发明上述实施例提供的方案，可以达到采用一张SM2证书进行SSL签名和交易签名，提高安全度，确保黑客无法通过非交易签名伪造交易签名的效果。
附图说明
此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：
图1是根据本发明实施例的一种数据的签名方法的流程图；
图2是根据本发明实施例的一种可选的数据的签名方法的流程图；
图3是根据本发明实施例的一种数据的签名装置的示意图；以及
图4是根据本发明实施例的一种数据的签名***的示意图。
具体实施方式
为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。
需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、***、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
首先，在对本申请实施例进行描述的过程中出现的部分名词或术语适用于如下解释：
USBKey：USBKey可以通过微型USB接口、蓝牙模块、音频串口等方式与计算机终端或移动设备相连、它内置安全芯片，有一定的存储空间，可以存储用户的私钥以及数字证书，利用USB Key内置的公钥算法实现对用户身份的认证。
SM2算法：由国家密码管理局于2010年12月17日发布，全称为椭圆曲线算法。椭圆曲线并不是椭圆，之所以称为椭圆曲线是因为它们是用三次方程来表示的，并且该方程与计算椭圆周长的方程相似。与RSA算法相比，签名速度和密钥对生成速度快，安全强度高。
SM3算法：由国家密码管理局于2010年12月17日发布，全称为密码杂凑算法，适用于数字签名和验证、消息认证码的生成与验证以及随机数的生成。
中间件：是一种独立的***软件或服务程序，分布式应用软件借助这种软件在不同的技术之间共享资源，中间件位于客户机/服务器的操作***上，管理计算资源和网络通信。
实施例1
根据本发明实施例，提供了一种数据的签名方法实施例，需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机***中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。
图1是根据本发明实施例的一种数据的签名方法的流程图，如图1所示，该方法包括如下步骤：
步骤S102，获取待签名的数据。
具体的，上述的待签名的数据可以是中间件发送给USBKey的数据，例如，可以是中间件发送给USBKey的认证数据的明文，或者是中间件发送给USBKey的交易报文。
步骤S104，判断待签名的数据是否满足预设条件。
具体的，上述的预设条件可以是用于确定待签名的数据是认证数据的条件，即如果待签名的数据满足该预设条件，则确定该待签名的数据为认证数据；否则，确定该待签名的数据为交易报文。
步骤S106，如果待签名的数据满足预设条件，则确定待签名的数据为认证数据，并对认证数据进行签名，得到第一签名结果。
步骤S108，如果待签名的数据不满足预设条件，则确定待签名的数据为交易报文，并对交易报文进行签名，得到第二签名结果。
在一种可选的方案中，USBKey在获取到待签名的数据之后，可以对待签名的数据的类型进行判断，判断待签名的数据是否满足预设条件，如果待签名的数据满足该预设条件，则确定待签名的数据为认证数据，需要进行SSL签名，可以通过USBKey中存储的SM2证书所对应的私钥对该待签名的数据进行SSL签名，得到SSL签名结果，即上述的第一签名结果；如果待签名的数据不满足该预设条件，则确定待签名的数据为交易报文，需要进行交易签名，可以通过USBKey中存储的SM2证书所对应的私钥对该待签名的数据进行交易签名，得到交易签名结果，即上述的第二签名结果。
根据本发明上述实施例，获取待签名的数据，判断待签名的数据是否满足预设条件，如果待签名的数据满足预设条件，则确定待签名的数据为认证数据，并对认证数据进行签名，得到第一签名结果，如果待签名的数据不满足预设条件，则确定待签名的数据为交易报文，并对交易报文进行签名，得到第二签名结果，从而实现通过SM2算法对数据进行签名。容易注意到的是，在获取到待签名的数据之后，可以判断待签名的数据是否满足预设条件，从而确定待签名的数据是认证数据还是交易报文，实现了通过SM2算法对数据进行签名的过程中区分SSL签名和交易签名，解决了现有技术中通过椭圆曲线算法对数据进行签名，无法判断数据是认证数据还是交易报文数据的技术问题。因此，通过本发明上述实施例提供的方案，可以达到采用一张SM2证书进行SSL签名和交易签名，提高安全度，确保黑客无法通过非交易签名伪造交易签名的效果。
可选的，根据本发明上述实施例，步骤S104，判断待签名的数据是否满足预设条件包括：
步骤S1042，判断待签名的数据是否包含交易报文的报文头。
具体的，在实际的SSL双向认证过程中，中间件发送的认证数据不会包含交易报文的报文头；而在交易签名的过程中，中间件会发送交易报文给USBKey。
步骤S1044，如果待签名的数据不包含交易报文的报文头，则确定待签名的数据满足预设条件。
步骤S1046，如果待签名的数据包含交易报文的报文头，则确定待签名的数据不满足预设条件。
在一种可选的方案中，USBKey在获取到中间件发送的待签名的数据之后，可以对待签名的数据进行检查，如果该待签名的数据不包含有交易报文的报文头，则确定待签名的数据为认证数据，需要进行SSL签名，可以通过USBKey中存储的SM2证书所对应的私钥对该待签名的数据进行SSL签名，得到SSL签名结果；如果该待签名的数据包含有交易报文的报文头，则确定待签名的数据为交易报文，需要进行交易签名，可以通过USBKey中存储的SM2证书所对应的私钥对该待签名的数据进行交易签名，得到交易签名结果。
此处需要说明的是，如果USBKey正在进行SSL签名，则USBKey在确定待签名的数据包含有交易报文头，则可以拒绝对待签名的数据进行签名。
可选的，根据本发明上述实施例，步骤S1042，判断待签名的数据是否包含交易报文的报文头包括：
步骤S10422，获取待签名的数据中从第一个字符开始的预设个数的字符。
具体的，由于交易报文的前38个字符为交易报文，因此，上述的预设个数可以是38个。
步骤S10424，判断预设个数的字符与交易报文的报文头是否相同。
具体的，上述的交易报文的报文头可以是<？xml version＝"1.0"encoding＝"utf-8"？>。
步骤S10426，如果预设个数的字符与交易报文的报文头相同，则确定待签名的数据包含交易报文的报文头。
步骤S10428，如果预设个数的字符与交易报文的报文头不同，则确定待签名的数据不包含交易报文的报文头。
在一种可选的方案中，USBKey在接收到中间件发送的待签名的数据之后，可以获取该待签名的数据的前38个字符，判断获取到的前38个字符是否为<？xml version＝"1.0"encoding＝"utf-8"？>，如果前38个字符不是<？xml version＝"1.0"encoding＝"utf-8"？>，则确定该待签名的数据为认证数据，需要进行SSL签名，可以通过USBKey中存储的SM2证书所对应的私钥对该待签名的数据进行SSL签名；如果如果前38个字符是<？xml version＝"1.0"encoding＝"utf-8"？>，则确定该待签名的数据为交易报文，需要进行交易签名，可以通过USBKey中存储的SM2证书所对应的私钥对该待签名的数据进行交易签名，得到交易签名结果。
可选的，根据本发明上述实施例，步骤S106，对认证数据进行签名，得到第一签名结果包括：
步骤S1062，基于密码杂凑算法，计算认证数据的哈希值，得到第一哈希值。
步骤S1064，基于椭圆曲线算法，对第一哈希值进行签名，得到第一签名结果。
在一种可选的方案中，在确定待签名的数据为认证数据，需要进行SSL签名之后，USBKey可以通过SM2证书所对应的SM3算法，对该待签名的数据所有字符进行HASH运算，得到HASH值，并通过SM2证书所对应的SM2私钥，对HASH值进行签名。
可选的，根据本发明上述实施例，步骤S108，对交易报文进行签名，得到第二签名结果包括：
步骤S1082，显示交易报文中的关键交易信息。
具体的，上述的关键交易信息可以是转入账号、转账金额等。
步骤S1084，在接收到确认信息之后，基于密码杂凑算法，计算交易报文的哈希值，得到第二哈希值，其中，确认信息用于表征关键交易信息正确。
步骤S1086，基于椭圆曲线算法，对第二哈希值进行签名，得到第二签名结果。
在一种可选的方案中，在确定待签名的数据为交易报文，需要进行交易签名之后，USBKey可以根据交易报文格式，在显示屏上显示转入账号、转账金额等关键交易信息供用户确认，用户如果确定关键交易信息正确，则可以按下USBKey的确认按键，在收到确认信息之后，USBKey可以通过SM2证书所对应的SM3算法，对该待签名的数据所有字符进行HASH运算，得到HASH值，并通过SM2证书所对应的SM2私钥，对HASH值进行签名。
此处需要说明的是，在USBKey接收到中间件发送的待签名的数据之后，为了能够区分是SSL签名还是交易签名，需要禁止USBKey对SM3算法直接得到的HASH值进行签名。
可选的，根据本发明上述实施例，步骤S102，获取待签名的数据包括：
步骤S1022，接收中间件发送的待签名的数据。
在一种可选的方案中，在SSL签名的过程中，中间件可以直接发送认证数据的明文给USBKey进行签名，在交易签名的过程中，中间件发送交易报文给USBKey进行签名。
可选的，根据本发明上述实施例，在步骤S106，对认证数据进行签名，得到第一签名结果，或步骤S108，对交易报文进行签名，得到第二签名结果之后，该方法还包括：
步骤S114，将第一签名结果或第二签名结果返回至中间件。
在一种可选的方案中，USBKey在对认证数据进行SSL签名，得到SSL签名结果之后，可以将签名结果返回给中间件，中间件将签名结果返回给认证服务器进行验证，在验证通过之后，可以进行SSL登陆，USBKey在对认证数据进行交易签名，得到交易签名结果之后，可以将签名结果返回给中间件，中间件将交易报文和交易签名结果一并发到银行服务器中，银行服务器验证无误后再进行实际的转账。
图2是根据本发明实施例的一种可选的数据的签名方法的流程图，下面结合图2对本发明一种优选的实施例进行详细说明，如图2所示，该方法可以包括如下步骤S21至步骤S28：
步骤S21，输入待签名的明文。
可选的，中间件可以将待签名的数据的明文发送给USBKey进行签名。
步骤S22，判断前38个字符是否等于<？xml version＝"1.0"encoding＝"utf-8"？>。
可选的，USBKey在接收到明文之后，需要对明文的类型进行判断，获取到明文的前38个字符，并判断前38个字符是否等于交易报文的报文头<？xml version＝"1.0"encoding＝"utf-8"？>，如果前38个字符不等于<？xml version＝"1.0"encoding＝"utf-8"？>，则确定中间件发送的明文为认证数据，需要进行SSL签名，进入步骤S23；如果前38个字符等于<？xml version＝"1.0"encoding＝"utf-8"？>，则确定中间件发送的明文为交易报文，需要进行交易签名，进入步骤S25。
步骤S23，对所有字符进行SM3HASH运算。
步骤S24，对HASH结果进行签名。
可选的，USBKey中存储有SM2证书，在确定需要对明文进行SSL签名之后，可以通过SM3算法对明文的所有字符进行HASH运算，得到明文的HASH值，并通过SM2算法对HASH值进行签名，得到SSL签名结果。在执行完步骤S24之后，进入步骤S28。
步骤S25，显示转入账号、转账金额等关键交易信息。
步骤S26，对所有字符进行SM3HASH运算。
步骤S27，对HASH结果进行签名。
可选的，USBKey中存储有SM2证书，在确定需要对明文进行交易签名之后，可以在显示屏上显示转入账号、转账金额等关键交易信息，待用户按键确认后，通过SM3算法对明文的所有字符进行HASH运算，得到明文的HASH值，并通过SM2算法对HASH值进行签名，得到交易签名结果。在执行完步骤S24之后，进入步骤S28。
步骤S28，将签名结果返回给中间件。
可选的，USBKey在进行SSL签名得到SSL签名结果，或者在进行交易签名得到交易签名结果之后，可以将签名结果返回给中间件。
通过上述步骤S21至步骤S28，提出了一种SM2算法显示型USBKey防止SSL签名伪造交易签名的方法，USBKey可以对区分SSL签名和交易签名，并采用一张SM2证书，既进行SSL签名，又进行交易签名，并且能确保黑客无法通过非交易签名伪造交易签名。
实施例2
根据本发明实施例，提供了一种数据的签名装置实施例。
图3是根据本发明实施例的一种数据的签名装置的示意图，如图3所示，该装置包括：
获取单元31，用于获取待签名的数据。
具体的，上述的待签名的数据可以是中间件发送给USBKey的数据，例如，可以是中间件发送给USBKey的认证数据的明文，或者是中间件发送给USBKey的交易报文。
第一判断单元33，用于判断待签名的数据是否满足预设条件。
具体的，上述的预设条件可以是用于确定待签名的数据是认证数据的条件，即如果待签名的数据满足该预设条件，则确定该待签名的数据为认证数据；否则，确定该待签名的数据为交易报文。
第一签名单元35，用于如果待签名的数据满足预设条件，则确定待签名的数据为认证数据，并对认证数据进行签名，得到第一签名结果。
第二签名单元37，用于如果待签名的数据不满足预设条件，则确定待签名的数据为交易报文，并对交易报文进行签名，得到第二签名结果。
在一种可选的方案中，USBKey在获取到待签名的数据之后，可以对待签名的数据的类型进行判断，判断待签名的数据是否满足预设条件，如果待签名的数据满足该预设条件，则确定待签名的数据为认证数据，需要进行SSL签名，可以通过USBKey中存储的SM2证书所对应的私钥对该待签名的数据进行SSL签名，得到SSL签名结果，即上述的第一签名结果；如果待签名的数据不满足该预设条件，则确定待签名的数据为交易报文，需要进行交易签名，可以通过USBKey中存储的SM2证书所对应的私钥对该待签名的数据进行交易签名，得到交易签名结果，即上述的第二签名结果。
根据本发明上述实施例，获取待签名的数据，判断待签名的数据是否满足预设条件，如果待签名的数据满足预设条件，则确定待签名的数据为认证数据，并对认证数据进行签名，得到第一签名结果，如果待签名的数据不满足预设条件，则确定待签名的数据为交易报文，并对交易报文进行签名，得到第二签名结果，从而实现通过SM2算法对数据进行签名。容易注意到的是，在获取到待签名的数据之后，可以判断待签名的数据是否满足预设条件，从而确定待签名的数据是认证数据还是交易报文，实现了通过SM2算法对数据进行签名的过程中区分SSL签名和交易签名，解决了现有技术中通过椭圆曲线算法对数据进行签名，无法判断数据是认证数据还是交易报文数据的技术问题。因此，通过本发明上述实施例提供的方案，可以达到采用一张SM2证书进行SSL签名和交易签名，提高安全度，确保黑客无法通过非交易签名伪造交易签名的效果。
可选的，根据本发明上述实施例，该第一判断单元包括：
判断模块，用于判断待签名的数据是否包含交易报文的报文头。
具体的，在实际的SSL双向认证过程中，中间件发送的认证数据不会包含交易报文的报文头；而在交易签名的过程中，中间件会发送交易报文给USBKey。
第一确定模块，用于如果待签名的数据不包含交易报文的报文头，则确定待签名的数据满足预设条件。
第二确定模块，用于如果待签名的数据包含交易报文的报文头，则确定待签名的数据不满足预设条件。
在一种可选的方案中，USBKey在获取到中间件发送的待签名的数据之后，可以对待签名的数据进行检查，如果该待签名的数据不包含有交易报文的报文头，则确定待签名的数据为认证数据，需要进行SSL签名，可以通过USBKey中存储的SM2证书所对应的私钥对该待签名的数据进行SSL签名，得到SSL签名结果；如果该待签名的数据包含有交易报文的报文头，则确定待签名的数据为交易报文，需要进行交易签名，可以通过USBKey中存储的SM2证书所对应的私钥对该待签名的数据进行交易签名，得到交易签名结果。
此处需要说明的是，如果USBKey正在进行SSL签名，则USBKey在确定待签名的数据包含有交易报文头，则可以拒绝对待签名的数据进行签名。
可选的，根据本发明上述实施例，该判断模块包括：
获取子模块，用于获取待签名的数据中从第一个字符开始的预设个数的字符。
具体的，由于交易报文的前38个字符为交易报文，因此，上述的预设个数可以是38个。
判断子模块，用于判断预设个数的字符与交易报文的报文头是否相同。
具体的，上述的交易报文的报文头可以是<？xml version＝"1.0"encoding＝"utf-8"？>。
第一确定子模块，用于如果预设个数的字符与交易报文的报文头相同，则确定待签名的数据包含交易报文的报文头。
第二确定子模块，用于如果预设个数的字符与交易报文的报文头不同，则确定待签名的数据不包含交易报文的报文头。
在一种可选的方案中，USBKey在接收到中间件发送的待签名的数据之后，可以获取该待签名的数据的前38个字符，判断获取到的前38个字符是否为<？xml version＝"1.0"encoding＝"utf-8"？>，如果前38个字符不是<？xml version＝"1.0"encoding＝"utf-8"？>，则确定该待签名的数据为认证数据，需要进行SSL签名，可以通过USBKey中存储的SM2证书所对应的私钥对该待签名的数据进行SSL签名；如果如果前38个字符是<？xml version＝"1.0"encoding＝"utf-8"？>，则确定该待签名的数据为交易报文，需要进行交易签名，可以通过USBKey中存储的SM2证书所对应的私钥对该待签名的数据进行交易签名，得到交易签名结果。
可选的，根据本发明上述实施例，该第一签名单元包括：
第一计算模块，用于基于密码杂凑算法，计算认证数据的哈希值，得到第一哈希值。
第一签名模块，用于基于椭圆曲线算法，对第一哈希值进行签名，得到第一签名结果。
在一种可选的方案中，在确定待签名的数据为认证数据，需要进行SSL签名之后，USBKey可以通过SM2证书所对应的SM3算法，对该待签名的数据所有字符进行HASH运算，得到HASH值，并通过SM2证书所对应的SM2私钥，对HASH值进行签名。
可选的，根据本发明上述实施例，该第二签名单元包括：
显示模块，用于显示交易报文中的关键交易信息。
具体的，上述的关键交易信息可以是转入账号、转账金额等。
第二计算模块，用于在接收到确认信息之后，基于密码杂凑算法，计算交易报文的哈希值，得到第二哈希值，其中，确认信息用于表征关键交易信息正确。
第二签名模块，用于基于椭圆曲线算法，对第二哈希值进行签名，得到第二签名结果。
在一种可选的方案中，在确定待签名的数据为交易报文，需要进行交易签名之后，USBKey可以根据交易报文格式，在显示屏上显示转入账号、转账金额等关键交易信息供用户确认，用户如果确定关键交易信息正确，则可以按下USBKey的确认按键，在收到确认信息之后，USBKey可以通过SM2证书所对应的SM3算法，对该待签名的数据所有字符进行HASH运算，得到HASH值，并通过SM2证书所对应的SM2私钥，对HASH值进行签名。
此处需要说明的是，在USBKey接收到中间件发送的待签名的数据之后，为了能够区分是SSL签名还是交易签名，需要禁止USBKey对SM3算法直接得到的HASH值进行签名。
可选的，根据本发明上述实施例，该获取单元包括：
接收模块，用于接收中间件发送的待签名的数据。
在一种可选的方案中，在SSL签名的过程中，中间件可以直接发送认证数据的明文给USBKey进行签名，在交易签名的过程中，中间件发送交易报文给USBKey进行签名。
可选的，根据本发明上述实施例，该装置还包括：
返回模块，用于将第一签名结果或第二签名结果返回至中间件。
在一种可选的方案中，USBKey在对认证数据进行SSL签名，得到SSL签名结果之后，可以将签名结果返回给中间件，中间件将签名结果返回给认证服务器进行验证，在验证通过之后，可以进行SSL登陆，USBKey在对认证数据进行交易签名，得到交易签名结果之后，可以将签名结果返回给中间件，中间件将交易报文和交易签名结果一并发到银行服务器中，银行服务器验证无误后再进行实际的转账。
实施例3
根据本发明实施例，提供了一种数据的签名***实施例。
图4是根据本发明实施例的一种数据的签名***的示意图，如图4所示，该***包括：
中间件41，用于发送待签名的数据。
具体的，上述的待签名的数据可以是中间件发送给USBKey的数据，例如，可以是中间件发送给USBKey的认证数据的明文，或者是中间件发送给USBKey的交易报文。
在一种可选的方案中，在SSL签名的过程中，中间件可以直接发送认证数据的明文给USBKey进行签名，在交易签名的过程中，中间件发送交易报文给USBKey进行签名。
签名装置43，与中间件具有通信关系，用于判断待签名的数据是否满足预设条件，如果待签名的数据满足预设条件，则确定待签名的数据为认证数据，并对认证数据进行签名，得到第一签名结果，如果待签名的数据不满足预设条件，则确定待签名的数据为交易报文，并对交易报文进行签名，得到第二签名结果。
具体的，上述的签名装置可以是显示型USBKey；上述的预设条件可以是用于确定待签名的数据是认证数据的条件，即如果待签名的数据满足该预设条件，则确定该待签名的数据为认证数据；否则，确定该待签名的数据为交易报文。
在一种可选的方案中，USBKey在获取到待签名的数据之后，可以对待签名的数据的类型进行判断，判断待签名的数据是否满足预设条件，如果待签名的数据满足该预设条件，则确定待签名的数据为认证数据，需要进行SSL签名，可以通过USBKey中存储的SM2证书所对应的私钥对该待签名的数据进行SSL签名，得到SSL签名结果，即上述的第一签名结果；如果待签名的数据不满足该预设条件，则确定待签名的数据为交易报文，需要进行交易签名，可以通过USBKey中存储的SM2证书所对应的私钥对该待签名的数据进行交易签名，得到交易签名结果，即上述的第二签名结果。
根据本发明上述实施例，获取待签名的数据，判断待签名的数据是否满足预设条件，如果待签名的数据满足预设条件，则确定待签名的数据为认证数据，并对认证数据进行签名，得到第一签名结果，如果待签名的数据不满足预设条件，则确定待签名的数据为交易报文，并对交易报文进行签名，得到第二签名结果，从而实现通过SM2算法对数据进行签名。容易注意到的是，在获取到待签名的数据之后，可以判断待签名的数据是否满足预设条件，从而确定待签名的数据是认证数据还是交易报文，实现了通过SM2算法对数据进行签名的过程中区分SSL签名和交易签名，解决了现有技术中通过椭圆曲线算法对数据进行签名，无法判断数据是认证数据还是交易报文数据的技术问题。因此，通过本发明上述实施例提供的方案，可以达到采用一张SM2证书进行SSL签名和交易签名，提高安全度，确保黑客无法通过非交易签名伪造交易签名的效果。
可选的，根据本发明上述实施例，签名装置还用于发送第一签名结果或第二签名结果至中间件。
在一种可选的方案中，USBKey在对认证数据进行SSL签名，得到SSL签名结果之后，可以将签名结果返回给中间件，中间件将签名结果返回给认证服务器进行验证，在验证通过之后，可以进行SSL登陆，USBKey在对认证数据进行交易签名，得到交易签名结果之后，可以将签名结果返回给中间件，中间件将交易报文和交易签名结果一并发到银行服务器中，银行服务器验证无误后再进行实际的转账。
上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。
在本发明的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。
在本申请所提供的几个实施例中，应该理解到，所揭露的技术内容，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，可以为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个***，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (16)

1.一种数据的签名方法，其特征在于，包括：
获取待签名的数据；
判断所述待签名的数据是否满足预设条件；
如果所述待签名的数据满足所述预设条件，则确定所述待签名的数据为认证数据，并对所述认证数据进行签名，得到第一签名结果；
如果所述待签名的数据不满足所述预设条件，则确定所述待签名的数据为交易报文，并对所述交易报文进行签名，得到第二签名结果。
2.根据权利要求1所述的方法，其特征在于，判断所述待签名的数据是否满足预设条件包括：
判断所述待签名的数据是否包含所述交易报文的报文头；
如果所述待签名的数据不包含所述交易报文的报文头，则确定所述待签名的数据满足所述预设条件；
如果所述待签名的数据包含所述交易报文的报文头，则确定所述待签名的数据不满足所述预设条件。
3.根据权利要求2所述的方法，其特征在于，判断所述待签名的数据是否包含所述交易报文的报文头包括：
获取所述待签名的数据中从第一个字符开始的预设个数的字符；
判断所述预设个数的字符与所述交易报文的报文头是否相同；
如果所述预设个数的字符与所述交易报文的报文头相同，则确定所述待签名的数据包含所述交易报文的报文头；
如果所述预设个数的字符与所述交易报文的报文头不同，则确定所述待签名的数据不包含所述交易报文的报文头。
4.根据权利要求1所述的方法，其特征在于，对所述认证数据进行签名，得到第一签名结果包括：
基于密码杂凑算法，计算所述认证数据的哈希值，得到第一哈希值；
基于椭圆曲线算法，对所述第一哈希值进行签名，得到所述第一签名结果。
5.根据权利要求1所述的方法，其特征在于，对所述交易报文进行签名，得到第二签名结果包括：
显示所述交易报文中的关键交易信息；
在接收到确认信息之后，基于密码杂凑算法，计算所述交易报文的哈希值，得到第二哈希值，其中，所述确认信息用于表征所述关键交易信息正确；
基于椭圆曲线算法，对所述第二哈希值进行签名，得到所述第二签名结果。
6.根据权利要求1至5中任意一项所述的方法，其特征在于，获取待签名的数据包括：
接收中间件发送的所述待签名的数据。
7.根据权利要求6所述的方法，其特征在于，在对所述认证数据进行签名，得到第一签名结果，或对所述交易报文进行签名，得到第二签名结果之后，所述方法还包括：
将所述第一签名结果或所述第二签名结果返回至所述中间件。
8.一种数据的签名装置，其特征在于，包括：
获取单元，用于获取待签名的数据；
第一判断单元，用于判断所述待签名的数据是否满足预设条件；
第一签名单元，用于如果所述待签名的数据满足所述预设条件，则确定所述待签名的数据为认证数据，并对所述认证数据进行签名，得到第一签名结果；
第二签名单元，用于如果所述待签名的数据不满足所述预设条件，则确定所述待签名的数据为交易报文，并对所述交易报文进行签名，得到第二签名结果。
9.根据权利要求8所述的装置，其特征在于，所述第一判断单元包括：
判断模块，用于判断所述待签名的数据是否包含所述交易报文的报文头；
第一确定模块，用于如果所述待签名的数据不包含所述交易报文的报文头，则确定所述待签名的数据满足所述预设条件；
第二确定模块，用于如果所述待签名的数据包含所述交易报文的报文头，则确定所述待签名的数据不满足所述预设条件。
10.根据权利要求9所述的装置，其特征在于，所述判断模块包括：
获取子模块，用于获取所述待签名的数据中从第一个字符开始的预设个数的字符；
判断子模块，用于判断所述预设个数的字符与所述交易报文的报文头是否相同；
第一确定子模块，用于如果所述预设个数的字符与所述交易报文的报文头相同，则确定所述待签名的数据包含所述交易报文的报文头；
第二确定子模块，用于如果所述预设个数的字符与所述交易报文的报文头不同，则确定所述待签名的数据不包含所述交易报文的报文头。
11.根据权利要求8所述的装置，其特征在于，所述第一签名单元包括：
第一计算模块，用于基于密码杂凑算法，计算所述认证数据的哈希值，得到第一哈希值；
第一签名模块，用于基于椭圆曲线算法，对所述第一哈希值进行签名，得到所述第一签名结果。
12.根据权利要求8所述的装置，其特征在于，所述第二签名单元包括：
显示模块，用于显示所述交易报文中的关键交易信息；
第二计算模块，用于在接收到确认信息之后，基于密码杂凑算法，计算所述交易报文的哈希值，得到第二哈希值，其中，所述确认信息用于表征所述关键交易信息正确；
第二签名模块，用于基于椭圆曲线算法，对所述第二哈希值进行签名，得到所述第二签名结果。
13.根据权利要求8至12中任意一项所述的装置，其特征在于，所述获取单元包括：
接收模块，用于接收中间件发送的所述待签名的数据。
14.根据权利要求13所述的装置，其特征在于，所述装置还包括：
返回模块，用于将所述第一签名结果或所述第二签名结果返回至所述中间件。
15.一种数据的签名***，其特征在于，包括：
中间件，用于发送待签名的数据；
签名装置，与所述中间件具有通信关系，用于判断所述待签名的数据是否满足预设条件，如果所述待签名的数据满足所述预设条件，则确定所述待签名的数据为认证数据，并对所述认证数据进行签名，得到第一签名结果，如果所述待签名的数据不满足所述预设条件，则确定所述待签名的数据为交易报文，并对所述交易报文进行签名，得到第二签名结果。
16.根据权利要求15所述的***，其特征在于，所述签名装置还用于发送所述第一签名结果或所述第二签名结果至所述中间件。
CN201611205462.2A 2016-12-22 2016-12-22 数据的签名方法、装置及*** Pending CN106712937A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201611205462.2A CN106712937A (zh) 2016-12-22 2016-12-22 数据的签名方法、装置及***

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201611205462.2A CN106712937A (zh) 2016-12-22 2016-12-22 数据的签名方法、装置及***

Publications (1)

Publication Number Publication Date
CN106712937A true CN106712937A (zh) 2017-05-24

Family

ID=58902579

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201611205462.2A Pending CN106712937A (zh) 2016-12-22 2016-12-22 数据的签名方法、装置及***

Country Status (1)

Country Link
CN (1) CN106712937A (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114614992A (zh) * 2022-03-11 2022-06-10 深圳市名竹科技有限公司 签名值输出及验证方法、装置、计算机设备、存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050091492A1 (en) * 2003-10-27 2005-04-28 Benson Glenn S. Portable security transaction protocol
CN101247225A (zh) * 2007-04-06 2008-08-20 李东声 一种电子签名工具的签名方法与电子签名工具
CN102420829A (zh) * 2011-12-15 2012-04-18 北京握奇数据***有限公司 业务数据签名的方法、装置和***及数字认证终端
CN105812134A (zh) * 2014-12-30 2016-07-27 北京握奇智能科技有限公司 一种数字签名方法、数字验签方法、安全认证设备及安全认证装置

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050091492A1 (en) * 2003-10-27 2005-04-28 Benson Glenn S. Portable security transaction protocol
CN101247225A (zh) * 2007-04-06 2008-08-20 李东声 一种电子签名工具的签名方法与电子签名工具
CN102420829A (zh) * 2011-12-15 2012-04-18 北京握奇数据***有限公司 业务数据签名的方法、装置和***及数字认证终端
CN105812134A (zh) * 2014-12-30 2016-07-27 北京握奇智能科技有限公司 一种数字签名方法、数字验签方法、安全认证设备及安全认证装置

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114614992A (zh) * 2022-03-11 2022-06-10 深圳市名竹科技有限公司 签名值输出及验证方法、装置、计算机设备、存储介质
CN114614992B (zh) * 2022-03-11 2023-10-13 深圳市名竹科技有限公司 签名值输出及验证方法、装置、计算机设备、存储介质

Similar Documents

Publication Publication Date Title
CN101651675B (zh) 通过认证码对客户端进行验证的方法和***
US7362869B2 (en) Method of distributing a public key
AU2002355593B2 (en) Data certification method and apparatus
EP2213044B1 (en) Method of providing assured transactions using secure transaction appliance and watermark verification
US9147064B2 (en) Method for carrying out an application with the aid of a portable data storage medium
WO2022037596A1 (zh) 组合签名及验证签名方法、***及存储介质
CN106779636A (zh) 一种基于手机耳机接口的区块链数字货币钱包
US9191395B2 (en) Method and apparatus for providing an adaptable security level in an electronic communication
WO2018133674A1 (zh) 一种银行支付许可认证信息的反馈验证方法
EP1142194B1 (en) Method and system for implementing a digital signature
CN102201137A (zh) 网络安全终端以及基于该终端的交互***和交互方法
CN101232377A (zh) 一种认证方法和认证***
CN110224985B (zh) 数据处理的方法及相关装置
Li et al. Securing credit card transactions with one-time payment scheme
CN102811203B (zh) 互联网中用户身份识别方法、***及用户终端
CN202206419U (zh) 网络安全终端以及基于该终端的交互***
CN106355496A (zh) 实现批量电子交易的方法、***和装置以及电子签名工具
CN104753879B (zh) 终端认证云服务提供者的方法及***、云服务提供者认证终端的方法及***
CN106712937A (zh) 数据的签名方法、装置及***
CA2898587C (en) Digitised handwritten signature authentication
JPH1065652A (ja) 機密情報通信システムおよび機密情報通信方法
CN107947935A (zh) 一种报文的签名方法、***及终端设备
EP2357596A1 (en) Secure online order confirmation method
Ortiz-Yepes Enhancing Authentication in eBanking with NFC-enabled mobile phones
CN106603238A (zh) 一种多数字证书的签发***、设备及其工作方法

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
RJ01 Rejection of invention patent application after publication

Application publication date: 20170524

RJ01 Rejection of invention patent application after publication