+

WO2018195759A1 - 签名验证的方法、设备和系统 - Google Patents

签名验证的方法、设备和系统 Download PDF

Info

Publication number
WO2018195759A1
WO2018195759A1 PCT/CN2017/081812 CN2017081812W WO2018195759A1 WO 2018195759 A1 WO2018195759 A1 WO 2018195759A1 CN 2017081812 W CN2017081812 W CN 2017081812W WO 2018195759 A1 WO2018195759 A1 WO 2018195759A1
Authority
WO
WIPO (PCT)
Prior art keywords
message
public key
receiving end
check code
host
Prior art date
Application number
PCT/CN2017/081812
Other languages
English (en)
French (fr)
Inventor
孔维国
王兵
孙文彬
Original Assignee
深圳市汇顶科技股份有限公司
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 深圳市汇顶科技股份有限公司 filed Critical 深圳市汇顶科技股份有限公司
Priority to PCT/CN2017/081812 priority Critical patent/WO2018195759A1/zh
Priority to CN201780000335.5A priority patent/CN107223322B/zh
Publication of WO2018195759A1 publication Critical patent/WO2018195759A1/zh

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
    • H04L9/3249—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 using RSA or related signature schemes, e.g. Rabin scheme
    • 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/3236—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 using cryptographic hash functions
    • H04L9/3242—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 using cryptographic hash functions involving keyed hash functions, e.g. message authentication codes [MACs], CBC-MAC or HMAC

Definitions

  • the present application relates to the field of communications and, more particularly, to a method, apparatus and system for signature verification in the field of communications.
  • Digital signature technology is widely used in the security field, which enables the receiver to effectively verify the authenticity and non-repudiation of the data.
  • the digital signature algorithm may be, for example, an RSA public key cryptography algorithm, an Elliptic curve cryptography (ECC) algorithm, or the like.
  • ECC Elliptic curve cryptography
  • the hash hash function can guarantee the integrity of the input data, usually the digital signature technology combined with the hash function can guarantee the integrity, authenticity and non-repudiation of the data.
  • Digital signature algorithms are usually large numbers of operations that consume CPU runtime. In order to reduce costs, embedded systems cannot use high-performance processing hardware and do not have the ability to perform digital signatures. In embedded systems that require reliable and secure security, in order to protect the authenticity and integrity of data, it is necessary to use related security measures such as digital signature and verification, but this will inevitably require additional costs.
  • the embodiment of the present application provides a method, device, and system for signature verification, which can ensure the authenticity and integrity of data received by a receiving end with low hardware cost.
  • a method for signature verification comprising:
  • the host receives the message sent by the sender and the signature of the message, where the signature of the message is determined by the sender according to the private key and the digital signature algorithm;
  • the host verifies the message and the signature according to the public key and the digital signature algorithm
  • the host determines a check code of the message according to the preset key, wherein the complexity of the algorithm used to determine the check code is lower than the complexity of the digital signature algorithm;
  • the host sends the message and the check code to the receiving end, so that the receiving end verifies the message according to the check code, where the receiving end is an embedded system.
  • the host performs digital signature verification according to the data sent by the sending end to the receiving end, that is, the host performs a digital signature algorithm instead of the receiving end, so that the receiving end does not need to use a highly complex digital signature algorithm to verify the data.
  • embodiments of the present application can guarantee low hardware The authenticity and integrity of the data received by the receiving end of the cost.
  • the method is performed by a host having the capability of a digital signature, and the sender also has the ability to digitally sign.
  • the method further includes: the host receiving the public key sent by the receiving end; the host receiving the check code of the public key sent by the receiving end, where the check code is the receiving end According to the preset key, the host verifies the public key and the check code of the public key according to the preset key.
  • the receiving end sends the public key to the host, so that the host can perform digital verification on the data to be forwarded to the receiving end according to the public key provided by the receiving end, thereby improving the reliability of the verification.
  • the receiving end While the receiving end sends the public key to the host, the receiving end can send the check code of the public key to the host, so that the host can verify the received public key, thereby further improving the security of data transmission.
  • the host before receiving the public key sent by the receiving end, the host sends a request message to the receiving end, where the request message is used to request the receiving end to send the public key.
  • the request message is further used to request the receiving end to send a check code of the public key.
  • the digital signature algorithm is an RSA public key cryptography algorithm
  • the check code is a hash authentication based message authentication code HMAC.
  • the embedded system is a biometric embedded system.
  • a method of signature verification includes:
  • the sender determines the signature of the message to be sent according to the private key and the digital signature algorithm, and sends the message and the signature to the host;
  • the host verifies the message and the signature according to the public key and the digital signature algorithm.
  • the host determines a check code of the message according to the preset key, where the check is determined.
  • the complexity of the algorithm used by the code is lower than the complexity of the digital signature algorithm;
  • the host sends the message and the check code to the receiving end;
  • the receiving end verifies the message according to the check code, and acquires the message.
  • the host performs digital signature verification according to the data sent by the sending end to the receiving end, that is, the host performs a digital signature algorithm instead of the receiving end, so that the receiving end does not need to use a highly complex digital signature algorithm to verify the data. Therefore, the embodiment of the present application can ensure the authenticity and integrity of data received by the receiving end with low hardware cost.
  • the method is performed by a signature verification system, the system comprising a sender, a host, and a receiver, the host and the sender having the capability of digital signature, the receiver being an embedded system.
  • the method further includes: the receiving end sends the public key to the host, the receiving end determines a check code of the public key according to the preset key, and sends the public key to the host Check code; the host verifies the public key and the check code of the public key according to the preset key.
  • the receiving end sends the public key to the host, so that the host can perform digital verification on the data to be forwarded to the receiving end according to the public key provided by the receiving end, thereby improving the reliability of the verification.
  • the receiving end sends the public key to the host
  • the receiving end can send the check code of the public key to the host, so that the host can verify the received public key, thereby further improving the security of data transmission.
  • the method before the receiving end sends the public key to the host, the method further includes:
  • the host sends a request message to the receiving end, where the request message is used to request the receiving end to send the public key.
  • the request message is further used to request the receiving end to send a check code of the public key.
  • the digital signature algorithm is an RSA public key cryptography algorithm
  • the check code is a hash authentication message based authentication code HMAC.
  • the embedded system is a biometric embedded system.
  • the third aspect provides a device for performing signature verification, which is used to perform the method in any of the foregoing first aspect or any possible implementation manner of the first aspect, and the device includes the first aspect or the first A module of a method in any of the possible implementations.
  • a device for signature verification comprising: a memory, a processor, and a transceiver.
  • the memory is for storing instructions for executing the instructions stored by the memory, and when the processor executes the instructions stored by the memory, the executing causes the processor to perform any of the first aspect or the first aspect The method in the implementation.
  • a computer readable medium for storing a computer program, the computer program comprising instructions for performing the method of the first aspect or any of the possible implementations of the first aspect.
  • FIG. 1 is a schematic flow chart of data transmission by digital signature technology.
  • FIG. 2 is a structural diagram of a system for signature verification according to an embodiment of the present application.
  • FIG. 3 is a structural diagram of another system for signature verification according to an embodiment of the present application.
  • FIG. 4 is a schematic flowchart of a method for signature verification according to an embodiment of the present application.
  • FIG. 5 is a schematic block diagram of a device for signature verification according to an embodiment of the present application.
  • FIG. 6 is a schematic block diagram of another device for signature verification according to an embodiment of the present application.
  • FIG. 1 shows a schematic flow diagram of data transmission by digital signature technology.
  • the digital signature algorithm used in the method of transmitting data in FIG. 1 is an RSA public key cryptography algorithm.
  • both the transmitting end 10 and the receiving end 11 have the capability of digital signature, including:
  • the transmitting end 10 acquires the signature Sig M of the data M to be transmitted.
  • the transmitting end 10 sends the data M and the signature Sig M to the receiving end 11.
  • the receiving end 11 verifies the signature Sig M and the data M.
  • Alice and Bob use the sender and the receiver respectively for identity authentication as an example.
  • Alice needs to send data M to Bob, it uses its own private key (SK) to sign the data M to get Sig M .
  • the data M is plaintext data.
  • Alice's private key is only owned by Alice himself, and Alice's public key owner can reliably obtain it.
  • Bob can determine according to the signature Sig M that the data M is issued by Alice, and because only Alice himself uses it for himself.
  • the private key Alice can't deny the fact that the data M was sent.
  • FIG. 2 shows a system architecture diagram of an embodiment of the present application.
  • the system includes three entities: a transmitting end 10, a host 30 and a receiving end 20.
  • the host 30 and the transmitting 10 have the capability of digital signature, and the receiving end 20 can be an embedded system, and the receiving end 20 can have no digital signature capability.
  • the data is transmitted between the transmitting end 10 and the host 30 through the clear text channel, and the host 30 and the receiving end 20 can also transmit data through the clear text channel.
  • the host 30 includes a verification module 301, which is used to verify the authenticity and integrity of the data sent by the sender 10, and uses a hash-based message authentication code (HMAC). Replace the signature data.
  • the verification module 301 verifies the data and signature signed by the RSA public key cryptography algorithm, and simultaneously calculates the HMAC of the data.
  • the verification module 301 can run in a trusted execution environment (Trusted Execution Environment, TEE).
  • the receiving end 20 can be a low-cost, low-performance embedded system, and the embedded system has relatively high security requirements at the same time, for example, a biometric authentication system.
  • the HMAC operation process for verifying data is not a large number operation, and its hardware performance requirements are lower than those required by digital signature technology. Therefore, the receiving end 20 only needs to perform the HMAC operation process without performing the digital signature operation process.
  • FIG. 3 shows an overall architectural diagram of another specific embodiment of the present application.
  • the transmitting end 10 may specifically be FactoryTool 10.
  • the receiving end 20 may specifically include a Micro Control Unit (MCU) 201, and the receiving end 20 may further include a sensor.
  • the host 30 may specifically be a Windows PC.
  • the Windows PC 30 may include a verification module (VerifyModule) 301 and a daemon 302, and the VerifyModule 301 runs in a TEE (for example, Inter SGX (Software Guard Extensions)), and the daemon 302 runs in a normal software execution environment (Rich Execution). Environment, REE).
  • the operation speed of the MCU 201 can be slow.
  • the MCU 201 can only handle simple logic operations, and the space in which the software code is stored in the MCU 201 is limited.
  • the daemon 302 is a bridge for data transmission between FactoryTool 10, VerifyModule 301, and MCU 201.
  • the FactoryTool 10 and the daemon 302 can transmit data through the network channel, and the daemon 302 and the MCU 201 can be transmitted through a Serial Peripheral Interface (SPI) or a Universal Serial Bus (USB).
  • SPI Serial Peripheral Interface
  • USB Universal Serial Bus
  • Data, data between daemon 301 and VerifyModule 302 can be transferred via ECALL/OCALL.
  • the host 30 for example, Windows PC
  • the receiving end 20 for example, the MCU 201 in the present application may set a preset key PSK during production, and may preset a used end (for example, FactoryTool 10) in the receiving end device.
  • the public key PK corresponding to the private key SK.
  • FIG. 4 is a schematic flowchart of a method for signature verification according to an embodiment of the present application.
  • the method can be performed by various entities in the architecture of FIG. 2 or FIG.
  • FIG. 4 illustrates steps or operations of the method of signature verification, but these steps or operations are merely examples, and other embodiments of the present application may also perform other operations or variations of the operations in FIG.
  • the various steps in FIG. 4 may be performed in a different order than that presented in FIG. 4, and it is possible that not all operations in FIG. 4 are to be performed.
  • the same reference numerals in FIG. 2, FIG. 3 or FIG. 4 denote the same or similar meanings, and are not described herein again for brevity.
  • the method shown in Figure 4 includes:
  • the transmitting end 10 acquires a signature of data to be transmitted.
  • the sending end may be the FactoryTool 10 shown in FIG. 3, the data to be transmitted may be the message M, and the message M may be a command or other information.
  • the sender 10 can sign the message M according to the digital signature algorithm and the preset private key in the sender, and obtain the signature sig M of the message M.
  • the digital signature algorithm can be, for example, an RSA public key cryptography algorithm or an ECC cryptography algorithm.
  • the FactoryTool 10 and the VerifyModule 301 can adopt an RSA signature and a verification signature algorithm of a 2048 bit length key.
  • the sender 10 sends the data and signature to the host 30.
  • FactoryTool 10 can send the message M and its signature sig M to the daemon 302 in the PC.
  • the host 30 sends a request message to the receiving end 20.
  • the daemon 302 can send the request message to the MCU 201 via SPI or USB.
  • the request message is used to request the receiving terminal 20 to send the public key PK to the host 30.
  • the public key may be pre-configured in the receiving end 20.
  • the request message is further used to request the receiving end 20 to send the check code of the public key PK.
  • the S230 may be executed after the S220, or may be performed before the S220, or may not be performed.
  • the embodiment of the application is not limited thereto.
  • the receiving end 20 sends the public key and the check code of the public key to the host 30.
  • the receiving end 20 may calculate the check code of the public key PK according to the preset key PSK shared by the host 30, and determine that the complexity of the algorithm of the check code is lower than the digital signature algorithm, for example, the check code. It may be a message authentication code HMAC based on a hash function, and the check code of the public key PK is HMAC PK . Specifically, the MCU 201 can send the public key PK and the check code HMAC PK to the daemon 302 through the SPI.
  • the hash hash algorithm may use a Security Hash Algorithm (SHA)-256, and the VerifyModule 301 and the MCU use a SHA-256-based HMAC algorithm.
  • the HMAC algorithm is a hash-based Message Authentication Code (MAC).
  • MAC hash-based Message Authentication Code
  • the HMAC algorithm can share the code of the Hash function to a certain extent. Therefore, when the receiving end 20 verifies the validity of the data by using the HMAC algorithm instead of the RSA or ECC cryptography algorithm, the size of the software of the receiving end 20 can be reduced.
  • the hash algorithm may also use other hash algorithms such as SHA-1, and the HMAC algorithm between VerifyModule 301 and MCU 201 may adopt other MAC algorithms based on HASH functions such as SHA-1.
  • the host 30 uses the PSK authentication public key PK and the check code HMAC PK shared with the receiving end 20. After verification by S250, host 30 can determine the legitimacy of public key PK.
  • the daemon 302 may send the received public key PK and the check code HMAC PK to the VerifyModule 301, and verify the validity of the public key PK in the TEE environment by the VerifyModule 301.
  • the host 30 verifies the message M and its signature sig M using the verified legal public key PK. Specifically, the Validity of the message M and its sig M is verified by the VerifyModule 301 in the TEE environment.
  • the receiving end verifies the signature sig M of the M according to the preset public key PK.
  • the receiving end has higher requirements on hardware, for example, the receiving end needs to have faster processing capability, and can Store large code and cost more hardware.
  • the verification of M and sig M is performed by the host 30.
  • the hardware performance of the receiving end 20 is lower, for example, the receiving end 20 may have a lower running speed and a smaller storage. Low-cost embedded systems such as space.
  • the host 30 calculates a verification code HMAC M of the validated message M using the preset key PSK.
  • S270 may calculate the check code HMAC M of the message M in the TEE environment by the VerifyModule 301.
  • the host 30 determines the check code HMAC M of the message M based on the preset key PSK shared with the receiving end 20.
  • the check code is a message authentication code HMAC based on a hash function
  • the check code of the message M may be represented as HMAC M .
  • the host 30 sends a message M and a check code HMAC M to the receiving end 20.
  • the VerifyModule 301 can send the message M and the check code HMAC M to the daemon 302, and then the daemon 302 sends the message M and the check code HMAC M to the MCU 201.
  • the receiving end 30 verifies the message M and the check code HMAC M by using the shared HMAC M PSK. Specifically, the validity of the message M and the check code HMAC M can be verified by the MCU 201.
  • the host 30 performs digital signature verification according to the data sent by the transmitting end 10 to the receiving end 20, that is, the host 30 performs a digital signature algorithm instead of the receiving end 20, so that the receiving end 20 does not need to use a complicated number.
  • the signature algorithm verifies the data, and thus the embodiment of the present application can ensure the authenticity and integrity of the data received by the receiving end 20 with low hardware cost.
  • FIG. 5 shows a device 500 for signature verification according to an embodiment of the present application.
  • the device 500 has the capability of digital signature, and the device 500 includes:
  • the receiving unit 510 is configured to receive a message sent by the sending end and a signature of the message, where the sending end also has the capability of digital signature, and the signature of the message is determined by the sending end according to the private key and the digital signature algorithm;
  • the verification unit 520 is configured to verify the message and the signature according to a public key and a digital signature algorithm.
  • the verification unit 520 is further configured to determine a check code of the message according to the preset key, where the algorithm used to determine the check code has a lower complexity than the digital signature. The complexity of the algorithm;
  • the sending unit 530 is configured to send the message and the check code to the receiving end, so that the receiving end verifies the message according to the check code, where the receiving end is an embedded system.
  • the host performs digital signature verification according to the data sent by the sending end to the receiving end, that is, the host performs a digital signature algorithm instead of the receiving end, so that the receiving end does not need to use a highly complex digital signature algorithm to verify the data. Therefore, the embodiment of the present application can ensure the authenticity and integrity of data received by the receiving end with low hardware cost.
  • the receiving unit 510 is further configured to: receive, by the host, the public key sent by the receiving end.
  • the receiving unit 510 is further configured to receive a check code of the public key sent by the receiving end, where the check code is determined by the receiving end according to the preset key.
  • the verification unit 520 is further configured to verify the public key and the check code of the public key according to the preset key.
  • the sending unit 530 is further configured to send a request message to the receiving end, where the request message is used to request the receiving end to send the public key.
  • the request message is further used to request the receiving end to send the check code of the public key.
  • the digital signature algorithm is an RSA public key cryptography algorithm
  • the check code is a hash authentication message based authentication code HMAC.
  • the embedded system is a biometric embedded system.
  • the verification unit 520 may be implemented by a processor, and the receiving unit 510 and the sending unit 530 may be implemented by a transceiver.
  • device 600 can include a processor 610, a memory 620, and a transceiver 630.
  • the memory 620 can be used to store code and the like executed by the processor 610.
  • each step of the foregoing method may be completed by an integrated logic circuit of hardware in the processor 610 or an instruction in a form of software.
  • the steps of the method disclosed in connection with the embodiments of the present invention can be directly implemented as a hardware processor or completed by a combination of hardware and software modules in the processor.
  • the software module can be located in a conventional storage medium such as random access memory, flash memory, read only memory, programmable read only memory or electrically erasable programmable memory, registers, and the like.
  • the storage medium is located in the memory 620, and the processor 610 reads the information in the memory 620 and completes the steps of the above method in combination with its hardware. To avoid repetition, it will not be described in detail here.
  • the apparatus 500 shown in FIG. 5 or the apparatus 600 shown in FIG. 6 can implement the respective processes corresponding to the foregoing method embodiment shown in FIG. 4 .
  • the device 500 or the device 600 can refer to the description in FIG. 4 above. Avoid repetition, no more details here.
  • the embodiment of the invention further provides a system for signature verification, which comprises the above device 500 or device 600, the above-mentioned sender device and the above-mentioned receiver device.
  • the size of the sequence numbers of the foregoing processes does not mean the order of execution sequence, and the order of execution of each process should be determined by its function and internal logic, and should not be applied to the embodiment of the present application.
  • the implementation process constitutes any limitation.
  • the disclosed systems, devices, and methods may be implemented in other manners.
  • the device embodiments described above are merely illustrative.
  • the division of the unit is only a logical function division.
  • there may be another division manner for example, multiple units or components may be combined or may be Integrate into another system, or some features can be ignored or not executed.
  • the mutual coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection through some interface, device or unit, and may be in an electrical, mechanical or other form.
  • the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, may be located in one place, or may be distributed to multiple network units. You can choose some of them according to actual needs or All units are used to achieve the objectives of the solution of this embodiment.
  • each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.
  • the above integrated unit can be implemented in the form of hardware or in the form of a software functional unit.
  • the integrated unit if implemented in the form of a software functional unit and sold or used as a standalone product, may be stored in a computer readable storage medium.
  • the technical solution of the present application which is essential or contributes to the prior art, or a part of the technical solution, may be embodied in the form of a software product, which is stored in a storage medium, including
  • the instructions are used to cause a computer device (which may be a personal computer, server, or network device, etc.) to perform all or part of the steps of the methods described in various embodiments of the present application.
  • the foregoing storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, and the like. .

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Power Engineering (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Storage Device Security (AREA)

Abstract

本申请实施例提供了签名验证的方法、设备和系统，包括：发送端根据私钥和数字签名算法确定需要发送的消息的签名；主机根据公钥和该数字签名算法对该消息和该签名进行验证，当公钥和私钥对应时，主机根据预置密钥确定该消息的校验码，其中，确定该校验码所使用的算法的复杂度低于该数字签名算法的复杂度，主机和发送端具有数字签名的能力；接收端根据该校验码对该消息进行校验，并获取该消息，接收端为嵌入式系统。本申请实施例中，即主机代替接收端执行数字签名算法，从而使得接收端不需要使用复杂度高的数字签名算法对数据进行验证，因而本申请实施例能够保证低硬件成本的接收端接收的数据的真实性和完整性。

Description

签名验证的方法、设备和系统 技术领域
本申请涉及通信领域，并且更具体的，涉及通信领域中的签名验证的方法、设备和系统。
背景技术
数字签名技术在安全领域的应用非常广泛，其可以使得接收方有效验证数据的真实性和不可抵赖性。数字签名算法例如可以为RSA公钥密码学算法、椭圆曲线密码学(Elliptic curve cryptography，ECC)算法等。并且，因为哈希Hash函数能够保证输入数据的完整性，通常数字签名技术结合Hash函数可以保证数据的完整性、真实性和不可抵赖性。
数字签名算法通常是大数运算，非常消耗CPU运行时间。嵌入式系统为了降低成本，无法采用高性能的处理硬件，不具备执行数字签名的能力。在需要可靠、安全性保障的嵌入式系统中，为了保护数据的真实性和完整性，需要使用数字签名和验证等相关的安全措施，但这必然需要增加额外的成本。
发明内容
本申请实施例提供了一种签名验证的方法、设备和系统，能够保证低硬件成本的接收端接收的数据的真实性和完整性。
第一方面，提供了一种签名验证的方法，该方法包括：
主机接收发送端发送的消息和该消息的签名，其中，该消息的签名是该发送端根据私钥和数字签名算法确定的；
主机根据公钥和该数字签名算法对该消息和该签名进行验证；
当该公钥和该私钥对应时，该主机根据预置密钥确定该消息的校验码，其中，确定该校验码所使用的算法的复杂度低于该数字签名算法的复杂度；
主机将该消息和该校验码发送给接收端，使得该接收端根据该校验码对该消息进行校验，其中，该接收端为嵌入式系统。
本申请实施例中，主机根据对发送端向接收端发送的数据进行数字签名验证，即主机代替接收端执行数字签名算法，从而使得接收端不需要使用复杂度高的数字签名算法对数据进行验证，因而本申请实施例能够保证低硬件 成本的接收端接收的数据的真实性和完整性。
该在一些可能实现的方式中，所述方法由具有数字签名的能力的主机执行，且所述发送端也具有数字签名的能力。
该在一些可能实现的方式中，该方法还包括：主机接收该接收端发送的该公钥；主机接收该接收端发送的该公钥的校验码，其中，该校验码是该接收端根据该预置密钥确定的，主机根据该预置密钥对该公钥和该公钥的校验码进行验证。
本申请中，接收端将公钥发送给主机，使得主机可以根据接收端提供的公钥对将要转发给接收端的数据进行数字验证，提高验证的可靠性。
在接收端将公钥发送给主机的同时，接收端可以将该公钥的校验码发送给主机，使得主机能够对接收到的公钥进行验证，进一步提高数据传输的安全性。
在一些可能实现的方式中，主机接收该接收端发送的该公钥之前，向该接收端发送请求消息，该请求消息用于请求该接收端发送该公钥。
在一些可能实现的方式中，该请求消息还用于请求该接收端发送该公钥的校验码。
在一些可能实现的方式中，其特征在于，该数字签名算法为RSA公钥密码学算法，该校验码为基于Hash函数的消息认证码HMAC。
在一些可能实现的方式中，该嵌入式系统为生物识别嵌入式系统。
第二方面，提供了一种签名验证的方法。该方法包括：
发送端根据私钥和数字签名算法确定需要发送的消息的签名，并将该消息和该签名发送给该主机；
主机根据公钥和该数字签名算法对该消息和该签名进行验证，当该公钥和该私钥对应时，该主机根据预置密钥确定该消息的校验码，其中，确定该校验码所使用的算法的复杂度低于该数字签名算法的复杂度；
主机将该消息和该校验码发送给该接收端；
接收端根据该校验码对该消息进行校验，并获取该消息。
本申请实施例中，主机根据对发送端向接收端发送的数据进行数字签名验证，即主机代替接收端执行数字签名算法，从而使得接收端不需要使用复杂度高的数字签名算法对数据进行验证，因而本申请实施例能够保证低硬件成本的接收端接收的数据的真实性和完整性。
在一些可能的实现方式中，该方法由签名验证系统执行，该系统包括发送端、主机和接收端，该主机和该发送端具有数字签名的能力，该接收端为嵌入式系统。
在一些可能的实现方式中，该方法还包括：该接收端向该主机发送该公钥，该接收端根据该预置密钥确定该公钥的校验码，并向该主机发送该公钥的校验码；该主机根据该预置密钥对该公钥和该公钥的校验码进行验证。
本申请中，接收端将公钥发送给主机，使得主机可以根据接收端提供的公钥对将要转发给接收端的数据进行数字验证，提高验证的可靠性。在接收端将公钥发送给主机的同时，接收端可以将该公钥的校验码发送给主机，使得主机能够对接收到的公钥进行验证，进一步提高数据传输的安全性。
在一些可能的实现方式中，该接收端向该主机发送该公钥之前，还包括：
该主机向该接收端发送请求消息，该请求消息用于请求该接收端发送该公钥。
在一些可能的实现方式中，该请求消息还用于请求该接收端发送该公钥的校验码。
在一些可能的实现方式中，该数字签名算法为RSA公钥密码学算法，该校验码为基于Hash函数的消息认证码HMAC。
在一些可能的实现方式中，该嵌入式系统为生物识别嵌入式系统。
第三方面，提供了一种签名验证的设备，用于执行上述第一方面或第一方面的任意可能的实现方式中的方法，具体的，该设备包括用于执行上述第一方面或第一方面任意可能的实现方式中的方法的模块。
第四方面，提供了一种签名验证的设备，该设备包括：存储器、处理器和收发器。其中，该存储器用于存储指令，该处理器用于执行该存储器存储的指令，并且当该处理器执行该存储器存储的指令时，该执行使得该处理器执行第一方面或第一方面的任意可能的实现方式中的方法。
第五方面，提供了一种计算机可读介质，用于存储计算机程序，该计算机程序包括用于执行第一方面或第一方面的任意可能的实现方式中的方法的指令。
附图说明
图1是通过数字签名技术进行数据传输的示意性流程图。
图2是本申请实施例的一种签名验证的系统的架构图。
图3是本申请实施例的另一种签名验证的系统的架构图。
图4是本申请实施例的一种签名验证的方法的示意性流程图。
图5是本申请实施例的一种签名验证的设备的示意性框图。
图6是本申请实施例的另一种签名验证的设备的示意性框图。
具体实施方式
图1示出了通过数字签名技术进行数据传输的示意性流程图。图1中的传输数据的方法中使用的数字签名算法为RSA公钥密码学算法。该方法中，发送端10和接收端11都具有数字签名的能力，包括：
S110，发送端10获取将要传输的数据M的签名SigM。
S120，发送端10向接收端11发送该数据M和签名SigM。
S130，接收端11验证该签名SigM和数据M。
具体的，以Alice和Bob分别使用发送端和接收端进行身份认证为例进行说明。当Alice需要向Bob发送数据M时，使用自身的私钥(SK)对数据M进行签名，得到SigM。其中，数据M为明文数据。应注意，Alice的私钥只有Alice本人拥有，而Alice的公钥所有人都可以可靠获取到。并且根据RSA公钥密码学算法的理论，只有Alice的公钥数据，难以获得对应的RSA私钥，所以Bob可以根据签名SigM确定数据M是Alice发出的，并且，因为只有Alice本人用于自己的私钥，Alice无法抵赖曾经发送过数据M的事实。
图2示出了本申请一个实施例的系统架构图。在该系统包括发送端10、主机30和接收端20三个实体，主机30和发送10端具有数字签名的能力，接收端20可以为嵌入式系统，该接收端20可以不具备数字签名的能力。其中，发送端10和主机30之间通过明文信道传输数据，主机30和接收端20之间也可以通过明文信道传输数据。
其中，主机30中包括验证模块301，该验证模块301用于校验发送端10发送的数据的真实性和完整性，并且使用基于Hash函数的消息认证码(Hash-based Message Authentication Code，HMAC)替换签名数据。具体的，验证模块301对经过RSA公钥密码学算法进行签名过的数据和签名进行验证，同时计算数据的HMAC。该验证模块301可以运行在可信执行环境 (Trusted Execution Environment，TEE)中。
本申请实施例中，接收端20可以为低成本、低性能的嵌入式系统，并且该嵌入式系统同时对安全性的要求比较高，例如为生物识别认证系统。应注意，验证数据的HMAC的运算过程并不是大数运算，其对硬件性能的要求也低于使用数字签名技术对硬件性能的要求。因此，接收端20仅需要执行HMAC运算过程，而不需要执行数字签名运算过程。
图3示出了本申请另一个具体的实施例的整体架构图。在图3中，发送端10具体可以是FactoryTool10。接收端20具体可以包括微控制单元(Microcontroller Unit，MCU)201，接收端20中还可以包括传感器。主机30具体可以是Windows PC。其中，Windows PC 30中可以包括验证模块(VerifyModule)301和守护进程(daemon)302，并且VerifyModule301运行在TEE(例如Inter SGX(Software Guard Extensions))中，daemon302运行在普通的软件执行环境(Rich Execution Environment，REE)中。本申请中，MCU201的运算速度可以较慢，例如MCU201仅可以处理简单的逻辑运算，并且MCU201中存储软件代码的空间有限。
在图3所示的架构中，daemon302是FactoryTool 10、VerifyModule301和MCU201进行数据传输的桥梁。具体的，FactoryTool 10和daemon 302之间可以通过网络信道传输数据，daemon 302和MCU201之间可以通过串行外设接口(Serial Peripheral Interface，SPI)或通用串行总线(Universal Serial Bus，USB)传输数据，daemon 301和VerifyModule302之间可以通过ECALL/OCALL传输数据。
本申请中的主机30(例如Windows PC)和接收端20(例如MCU201)在生产的过程中可以设置预置密钥PSK，并且在接收端设备中可以预置发送端(例如FactoryTool10)所使用的私钥SK对应的公钥PK。
图4示出了本申请一个实施例的签名验证的方法的示意性流程图。该方法可以由图2或图3的架构中的各个实体执行。应理解，图4示出了签名验证的方法的步骤或操作，但这些步骤或操作仅是示例，本申请实施例还可以执行其他操作或者图4中的各个操作的变形。此外，图4中的各个步骤可以按照与图4呈现的不同的顺序来执行，并且有可能并非要执行图4中的全部操作。图2、图3或图4中相同的附图标记表示相同或相似的含义，为了简洁，此处不再赘述。图4所示的方法包括：
S210，发送端10获取将要传输的数据的签名。
具体地，该发送端可以为图3中所示的FactoryTool10，该将要传输的数据可以为消息M，消息M可以是命令或者其他信息。发送端10可以根据数字签名算法和该发送端中的预置的私钥对消息M进行签名，得到消息M的签名sigM。该数字签名算法例如可以为RSA公钥密码学算法或者ECC密码学算法。本申请实施例中，FactoryTool10和VerifyModule301可以采用2048bits长度密钥的RSA签名和验证签名算法。
S220，发送端10向主机30发送该数据和签名。
具体地，FactoryTool10可以向PC机中的daemon302发送消息M及其签名sigM。
S230，主机30向接收端20发送请求消息。具体地，daemon302可以通过SPI或USB向MCU201发送该请求消息。该请求消息用于请求接收端20中向主机30发送公钥PK。该公钥可以是预先配置在接收端20中。可选地，该请求消息还用于请求接收端20发送该公钥PK的校验码。
应注意，本申请实施例中，S230可以在S220之后执行，也可以在S220之前执行，或者也可以不执行S230的步骤本申请实施例对此并不限定。
S240，接收端20向主机30发送公钥和该公钥的校验码。
具体地，接收端20可以根据其与主机30共享的预置密钥PSK计算公钥PK的校验码，确定该校验码的算法的复杂度低于上述数字签名算法，该校验码例如可以为基于Hash函数的消息认证码HMAC，则该公钥PK的校验码为HMACPK。具体地，MCU201可以通过SPI将公钥PK和校验码HMACPK发送给daemon302。
本申请实施例中，哈希Hash算法可以使用安全哈希函数(Security Hash Algorithm，SHA)-256，VerifyModule301和MCU使用基于SHA-256的HMAC算法。HMAC算法是基于Hash的消息认证码(Message Authentication Code，MAC)，HMAC算法在一定程度上可以共享Hash函数的代码。因此，当接收端20采用HMAC算法而不是RSA或ECC密码学算法对数据的合法性验证时，可以减小接收端20的软件的大小。
本申请实施例中，Hash算法也可使用SHA-1等其他Hash算法，VerifyModule301和MCU201之间的HMAC算法可以采用基于SHA-1等HASH函数的其他MAC算法。
S250，主机30使用与接收端20共享的PSK验证公钥PK和校验码HMACPK。经过S250的验证，主机30可以确定公钥PK的合法性。
具体地，daemon302可以将接收到的公钥PK和校验码HMACPK发送至VerifyModule301，由VerifyModule301在TEE环境中对公钥PK的合法性进行验证。
S260，主机30使用验证合法的公钥PK验证消息M及其签名sigM。具体的，由VerifyModule301在TEE环境中对消息M及其sigM的合法性进行验证。
可以理解，现有技术中是由接收端根据预置的公钥PK验证M的签名sigM，此时接收端对硬件的要求比较高，例如，接收端需要有较快的处理能力，并且能够存储较大的代码，硬件成本较高。本申请实施例中，对M和sigM的验证由主机30执行，此时，对接收端20的硬件性能的要求较低，例如接收端20可以为具有较低的运行速度和较小的存储空间等低成本的嵌入式系统。
S270，主机30使用预置密钥PSK计算验证合法的消息M的校验码HMACM。可选地，S270可以由VerifyModule301在TEE环境计算消息M的校验码HMACM。
具体地，主机30根据与接收端20共享的预置密钥PSK确定消息M的校验码HMACM。当该校验码为基于Hash函数的消息认证码HMAC，则该消息M的校验码可以表示为HMACM。
S280，主机30向接收端20发送消息M和校验码HMACM。
具体地，VerifyModule301可以将消息M和校验码HMACM发送至daemon302，再由daemon302将消息M和校验码HMACM发送至MCU201。
S290，接收端30利用共享的HMACMPSK验证消息M和校验码HMACM。具体地，可以由MCU201对消息M和校验码HMACM的合法性进行验证。
本申请实施例中，主机30根据对发送端10向接收端20发送的数据进行数字签名验证，即主机30代替接收端20执行数字签名算法，从而使得接收端20不需要使用复杂度高的数字签名算法对数据进行验证，因而本申请实施例能够保证低硬件成本的接收端20接收的数据的真实性和完整性。
图5示出了本申请实施例的签名验证的设备500，该设备500该具有数字签名的能力，该设备500包括：
接收单元510，用于接收发送端发送的消息和该消息的签名，其中，该发送端也具有数字签名的能力，该消息的签名是该发送端根据私钥和数字签名算法确定的；
验证单元520，用于根据公钥和数字签名算法对该消息和该签名进行验证。当该公钥和该私钥对应时，该验证单元520还用于根据预置密钥确定该消息的校验码，其中，确定该校验码所使用的算法的复杂度低于该数字签名算法的复杂度；
发送单元530，用于将该消息和该校验码发送给接收端，使得该接收端根据该校验码对该消息进行校验，其中，接收端为嵌入式系统。
本申请实施例中，主机根据对发送端向接收端发送的数据进行数字签名验证，即主机代替接收端执行数字签名算法，从而使得接收端不需要使用复杂度高的数字签名算法对数据进行验证，因而本申请实施例能够保证低硬件成本的接收端接收的数据的真实性和完整性。
在一些可能的实现方式中，该接收单元510还用于主机接收该接收端发送的该公钥。
在一些可能的实现方式中，该接收单元510还用于接收该接收端发送的公钥的校验码，其中，该校验码是该接收端根据该预置密钥确定的。
验证单元520还用于根据预置密钥对公钥和该公钥的校验码进行验证。
在一些可能的实现方式中，该发送单元530还用于向该接收端发送请求消息，该请求消息用于请求该接收端发送该公钥。
在一些可能的实现方式中，该请求消息还用于请求接收端发送该公钥的校验码。
在一些可能的实现方式中，该数字签名算法为RSA公钥密码学算法，该校验码为基于Hash函数的消息认证码HMAC。
在一些可能的实现方式中，该嵌入式系统为生物识别嵌入式系统。
应注意，本发明实施例中，验证单元520可以由处理器实现，接收单元510和发送单元530可以由收发器实现。如图6所示，设备600可以包括处理器610、存储器620和收发器630。其中，存储器620可以用于存储处理器610执行的代码等。
在实现过程中，上述方法的各步骤可以通过处理器610中的硬件的集成逻辑电路或者软件形式的指令完成。结合本发明实施例所公开的方法的步骤 可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器620，处理器610读取存储器620中的信息，结合其硬件完成上述方法的步骤。为避免重复，这里不再详细描述。
图5所示的设备500或图6所示的设备600能够实现前述图4所示的方法实施例对应的各个过程，具体的，该设备500或设备600可以参见上述图4中的描述，为避免重复，这里不再赘述。
本发明实施例还提供一种签名验证的系统，该系统包括上述设备500或设备600、上述发送端设备和上述接收端设备。
应理解，在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，该单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或 者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以该权利要求的保护范围为准。

Claims (26)

  1. 一种签名验证的方法，其特征在于，包括：
    接收发送端发送的消息和所述消息的签名，所述消息的签名是所述发送端根据私钥和数字签名算法确定的；
    根据公钥和所述数字签名算法对所述消息和所述签名进行验证；
    当所述公钥和所述私钥对应时，根据预置密钥确定所述消息的校验码，其中，确定所述校验码所使用的算法的复杂度低于所述数字签名算法的复杂度；
    将所述消息和所述校验码发送给接收端，使得所述接收端根据所述校验码对所述消息进行校验，其中，所述接收端为嵌入式系统。
  2. 根据权利要求1所述的方法，其特征在于，所述方法由具有数字签名的能力的主机执行，且所述发送端也具有数字签名的能力。
  3. 根据权利要求1或2所述的方法，其特征在于，所述方法还包括：
    接收所述接收端发送的所述公钥；
    接收所述接收端发送的所述公钥的校验码，其中，所述校验码是所述接收端根据所述预置密钥确定的；
    根据所述预置密钥对所述公钥和所述公钥的校验码进行验证。
  4. 根据权利要求3所述的方法，其特征在于，还包括：
    在接收所述接收端发送的所述公钥之前，向所述接收端发送请求消息，所述请求消息用于请求所述接收端发送所述公钥。
  5. 根据权利要求4所述的方法，其特征在于，所述请求消息还用于请求所述接收端发送所述公钥的校验码。
  6. 根据权利要求1-5任一项所述的方法，其特征在于，所述数字签名算法为RSA公钥密码学算法，所述校验码为基于哈希Hash函数的消息认证码HMAC。
  7. 根据权利要求1-6任一项所述的方法，其特征在于，所述嵌入式系统为生物识别嵌入式系统。
  8. 一种签名验证的方法，其特征在于，包括：
    发送端根据私钥和数字签名算法确定需要发送的消息的签名，并将所述消息和所述签名发送给主机；
    所述主机根据公钥和所述数字签名算法对所述消息和所述签名进行验 证，并在所述公钥和所述私钥对应时，根据预置密钥确定所述消息的校验码，其中，确定所述校验码所使用的算法的复杂度低于所述数字签名算法的复杂度；
    所述主机将所述消息和所述校验码发送给接收端；
    所述接收端根据所述校验码对所述消息进行校验，并获取所述消息。
  9. 根据权利要求8所述的方法，其特征在于，所述方法由签名验证系统执行，所述签名验证系统包括所述发送端、所述主机和所述接收端，所述主机和所述发送端具有数字签名的能力，所述接收端为嵌入式系统。
  10. 根据权利要求8或9所述的方法，其特征在于，所述方法还包括：
    所述接收端向所述主机发送所述公钥；
    所述接收端根据所述预置密钥确定所述公钥的校验码，并向所述主机发送所述公钥的校验码；
    所述主机根据所述预置密钥对所述公钥和所述公钥的校验码进行验证。
  11. 根据权利要求10所述的方法，其特征在于，还包括：
    在所述接收端向所述主机发送所述公钥之前，所述主机向所述接收端发送请求消息，所述请求消息用于请求所述接收端发送所述公钥。
  12. 根据权利要求11所述的方法，其特征在于，所述请求消息还用于请求所述接收端发送所述公钥的校验码。
  13. 根据权利要求8-12任一项所述的方法，其特征在于，所述数字签名算法为RSA公钥密码学算法，所述校验码为基于哈希Hash函数的消息认证码HMAC。
  14. 根据权利要求8-13任一项所述的方法，其特征在于，所述嵌入式系统为生物识别嵌入式系统。
  15. 一种签名验证的设备，其特征在于，所述设备具有数字签名的能力，所述设备包括：
    接收单元，用于接收发送端发送的消息和所述消息的签名，所述消息的签名是所述发送端根据私钥和数字签名算法确定的；
    验证单元，用于根据公钥和所述数字签名算法对所述消息和所述签名进行验证，并在所述公钥和所述私钥对应时，根据预置密钥确定所述消息的校验码，其中，确定所述校验码所使用的算法的复杂度低于所述数字签名算法的复杂度；
    发送单元，用于将所述消息和所述校验码发送给接收端，使得所述接收端根据所述校验码对所述消息进行校验，其中，所述接收端为嵌入式系统。
  16. 根据权利要求15所述的设备，其特征在于，所述接收单元还用于接收所述接收端发送的所述公钥，并接收所述接收端发送的所述公钥的校验码，其中，所述校验码是所述接收端根据所述预置密钥确定的；
    所述验证单元还用于根据所述预置密钥对所述公钥和所述公钥的校验码进行验证。
  17. 根据权利要求16所述的设备，其特征在于，所述发送单元还用于向所述接收端发送请求消息，所述请求消息用于请求所述接收端发送所述公钥。
  18. 根据权利要求17所述的设备，其特征在于，所述请求消息还用于请求所述接收端发送所述公钥的校验码。
  19. 根据权利要求15-18任一项所述的设备，其特征在于，所述数字签名算法为RSA公钥密码学算法，所述校验码为基于哈希Hash函数的消息认证码HMAC。
  20. 根据权利要求15-19任一项所述的设备，其特征在于，所述嵌入式系统为生物识别嵌入式系统。
  21. 一种签名验证的系统，其特征在于，包括发送端、主机和接收端，所述主机和所述发送端具有数字签名的能力，所述接收端为嵌入式系统；
    所述发送端用于根据私钥和数字签名算法确定需要发送的消息的签名，并将所述消息和所述签名发送给所述主机；
    所述主机用于根据公钥和所述数字签名算法对所述消息和所述签名进行验证，并在所述公钥和所述私钥对应时，根据预置密钥确定所述消息的校验码，并且将所述消息和所述校验码发送给所述接收端，其中，确定所述校验码所使用的算法的复杂度低于所述数字签名算法的复杂度；
    所述接收端用于根据所述校验码对所述消息进行校验，并获取所述消息。
  22. 根据权利要求21所述的系统，其特征在于，所述接收端还用于向所述主机发送所述公钥，根据所述预置密钥确定所述公钥的校验码，并向所述主机发送所述公钥的校验码；
    所述主机还用于根据所述预置密钥对所述公钥和所述公钥的校验码进 行验证。
  23. 根据权利要求22所述的系统，其特征在于，所述主机还用于向所述接收端发送请求消息，所述请求消息用于请求所述接收端发送所述公钥。
  24. 根据权利要求23所述的系统，其特征在于，所述请求消息还用于请求所述接收端发送所述公钥的校验码。
  25. 根据权利要求21-24任一项所述的系统，其特征在于，所述数字签名算法为RSA公钥密码学算法，所述校验码为基于哈希Hash函数的消息认证码HMAC。
  26. 根据权利要求21-25任一项所述的系统，其特征在于，所述嵌入式系统为生物识别嵌入式系统。
PCT/CN2017/081812 2017-04-25 2017-04-25 签名验证的方法、设备和系统 WO2018195759A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/CN2017/081812 WO2018195759A1 (zh) 2017-04-25 2017-04-25 签名验证的方法、设备和系统
CN201780000335.5A CN107223322B (zh) 2017-04-25 2017-04-25 签名验证的方法、设备和系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2017/081812 WO2018195759A1 (zh) 2017-04-25 2017-04-25 签名验证的方法、设备和系统

Publications (1)

Publication Number Publication Date
WO2018195759A1 true WO2018195759A1 (zh) 2018-11-01

Family

ID=59954328

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2017/081812 WO2018195759A1 (zh) 2017-04-25 2017-04-25 签名验证的方法、设备和系统

Country Status (2)

Country Link
CN (1) CN107223322B (zh)
WO (1) WO2018195759A1 (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111835508B (zh) * 2019-04-23 2023-02-28 深圳市汇顶科技股份有限公司 一种密钥分配部署方法和系统
DE102020212451A1 (de) * 2020-10-01 2022-04-07 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren zum digitalen Signieren einer Nachricht
CN114826772B (zh) * 2022-05-30 2024-03-08 中国联合网络通信集团有限公司 数据完整性验证系统

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030167407A1 (en) * 2002-03-01 2003-09-04 Brett Howard Authenticated file loader
CN101442408A (zh) * 2007-11-23 2009-05-27 上海千镭星电子科技有限公司 嵌入式加密系统
CN101458638A (zh) * 2007-12-13 2009-06-17 安凯（广州）软件技术有限公司 一种用于嵌入式系统的大规模数据验证方法
CN105787390A (zh) * 2016-03-02 2016-07-20 深圳大学 一种数据完整性的验证方法及其系统

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006067665A1 (en) * 2004-12-20 2006-06-29 Philips Intellectual Property & Standards Gmbh Data processing device and method for operating such data processing device
US8874896B2 (en) * 2010-06-18 2014-10-28 Intertrust Technologies Corporation Secure processing systems and methods
CN102572609B (zh) * 2010-12-08 2014-10-08 中国科学院声学研究所 一种嵌入式系统中的视频完整性认证方法
CN102819706B (zh) * 2012-07-26 2014-12-10 重庆大学 在现有嵌入式设备上实现可信嵌入式系统的装置和方法
CN103297429B (zh) * 2013-05-23 2016-12-28 北京大学 一种嵌入式升级文件传输方法
US9621525B2 (en) * 2014-06-02 2017-04-11 Qualcomm Incorporated Semi-deterministic digital signature generation
CN104052606B (zh) * 2014-06-20 2017-05-24 北京邮电大学 数字签名、签名认证装置以及数字签名方法
CN106096420A (zh) * 2016-06-15 2016-11-09 京信通信技术(广州)有限公司 嵌入式设备安全启动的方法和装置

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030167407A1 (en) * 2002-03-01 2003-09-04 Brett Howard Authenticated file loader
CN101442408A (zh) * 2007-11-23 2009-05-27 上海千镭星电子科技有限公司 嵌入式加密系统
CN101458638A (zh) * 2007-12-13 2009-06-17 安凯（广州）软件技术有限公司 一种用于嵌入式系统的大规模数据验证方法
CN105787390A (zh) * 2016-03-02 2016-07-20 深圳大学 一种数据完整性的验证方法及其系统

Also Published As

Publication number Publication date
CN107223322B (zh) 2020-07-24
CN107223322A (zh) 2017-09-29

Similar Documents

Publication Publication Date Title
US12003505B2 (en) Custom authorization of network connected devices using signed credentials
KR101904177B1 (ko) 데이터 처리 방법 및 장치
CN109074449B (zh) 在安全飞地中灵活地供应证明密钥
US9386045B2 (en) Device communication based on device trustworthiness
EP3613169B1 (en) Method for mutual symmetric authentication between a first application and a second application
WO2018177124A1 (zh) 业务处理方法、装置、数据共享系统及存储介质
US11050570B1 (en) Interface authenticator
US20160125180A1 (en) Near Field Communication Authentication Mechanism
CN114301590B (zh) 基于tpm的无人机机载控制系统的可信启动方法及系统
WO2018195759A1 (zh) 签名验证的方法、设备和系统
CN111656729A (zh) 用于为编码两台设备之间的数字通信计算托管会话密钥和私人会话密钥的系统和方法
WO2019205895A1 (zh) 寻呼方法、网络设备及终端
CN117614652A (zh) 基于can总线的车载网络消息认证方法及相关设备
CN117544328A (zh) 物联网接入方法、装置、终端及计算机可读存储介质
CN114065170A (zh) 平台身份证书的获取方法、装置和服务器
CN115146253A (zh) 一种移动App登录方法、移动设备及系统
CN114390478A (zh) 设备认证系统、方法及终端设备
JP2011197912A (ja) シンクライアントシステム、完全性検証サーバ、プログラム、記憶媒体、シンクライアント通信中継方法
CN110460567A (zh) 一种身份鉴权方法及装置
CN116186709B (zh) 基于虚拟化VirtIO技术卸载UEFI安全启动的方法、装置及介质
CN114710351B (zh) 用于在通信过程中改进数据安全性的方法和系统
CN117081729A (zh) 交换和管理密钥的方法、构建方法和认证的方法
CN119030971A (zh) 云端应用同步登录方法、装置、设备及存储介质
KR20230160744A (ko) 계산적 스토리지 다운로드 프로그램을 위한 인증 메커니즘
CN117035793A (zh) 资源交易认证方法和装置、设备及存储介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17906875

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 17906875

Country of ref document: EP

Kind code of ref document: A1

点击 这是indexloc提供的php浏览器服务，不要输入任何密码和下载