WO2018195759A1 - Procédé, dispositif et système de vérification de signature - Google Patents

Procédé, dispositif et système de vérification de signature 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)
Chinese (zh)
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/fr
Priority to CN201780000335.5A priority patent/CN107223322B/zh
Publication of WO2018195759A1 publication Critical patent/WO2018195759A1/fr

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

Des modes de réalisation de la présente invention concernent un procédé, un dispositif et un système de vérification de signature. Le procédé comprend les étapes suivantes : selon une clé privée et un algorithme de signature numérique, un côté émetteur détermine une signature d'un message à envoyer; un hôte vérifie le message et la signature selon une clé publique et l'algorithme de signature numérique; lorsque la clé publique correspond à la clé privée, l'hôte détermine un code de vérification du message selon une clé prédéfinie, la complexité d'un algorithme utilisé par le code de contrôle étant inférieure à celle de l'algorithme de signature numérique, et l'hôte et le côté d'envoi ayant une capacité d'une signature numérique; et un côté réception vérifie le message selon le code de vérification et obtient le message, le côté réception étant un système intégré. Dans les modes de réalisation de la présente invention, l'ordinateur hôte exécute l'algorithme de signature numérique au lieu d'un côté réception, de sorte que le côté réception n'a pas besoin d'utiliser un algorithme de signature numérique de complexité élevée pour vérifier des données; en conséquence, au moyen des modes de réalisation de la présente invention, l'authenticité et l'intégrité des données reçues par le côté réception avec de faibles coûts matériels peuvent être assurées.
PCT/CN2017/081812 2017-04-25 2017-04-25 Procédé, dispositif et système de vérification de signature WO2018195759A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/CN2017/081812 WO2018195759A1 (fr) 2017-04-25 2017-04-25 Procédé, dispositif et système de vérification de signature
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 (fr) 2017-04-25 2017-04-25 Procédé, dispositif et système de vérification de signature

Publications (1)

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

Family

ID=59954328

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2017/081812 WO2018195759A1 (fr) 2017-04-25 2017-04-25 Procédé, dispositif et système de vérification de signature

Country Status (2)

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

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
US20120005466A1 (en) * 2004-12-20 2012-01-05 Koninklijke Philips Electronics N.V. 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
CN107223322A (zh) 2017-09-29
CN107223322B (zh) 2020-07-24

Similar Documents

Publication Publication Date Title
CN109074449B (zh) 在安全飞地中灵活地供应证明密钥
CN108476404B (zh) 用于配对的设备和方法
KR101904177B1 (ko) 데이터 처리 방법 및 장치
WO2018177124A1 (fr) Procédé et dispositif et de traitement de service, système de partage de données et support de stockage
US9386045B2 (en) Device communication based on device trustworthiness
EP3613169B1 (fr) Procédé d'authentification symétrique réciproque entre une première application et une seconde application
US12003505B2 (en) Custom authorization of network connected devices using signed credentials
CN106576043B (zh) 病毒式可分配可信消息传送
US20160125180A1 (en) Near Field Communication Authentication Mechanism
CN109361508B (zh) 数据传输方法、电子设备及计算机可读存储介质
US11050570B1 (en) Interface authenticator
WO2016200535A1 (fr) Système, appareil et procédé de transfert de propriété d'un dispositif du fabricant à l'utilisateur à l'aide d'une ressource intégrée
CN114710351A (zh) 用于在通信过程中改进数据安全性的方法和系统
WO2018195759A1 (fr) Procédé, dispositif et système de vérification de signature
WO2019205895A1 (fr) Procédé de radiomessagerie, dispositif de réseau et terminal
CN105376067A (zh) 一种数字签名方法及系统
CN111600704B (zh) 基于sm2的秘钥交换方法、系统、电子设备及存储介质
CN114065170A (zh) 平台身份证书的获取方法、装置和服务器
CN115146253A (zh) 一种移动App登录方法、移动设备及系统
WO2017143570A1 (fr) Procédé et dispositif pour une authentification de dispositif, dispositif d'authentification, véhicule aérien sans équipage et télécommande
JP2011197912A (ja) シンクライアントシステム、完全性検証サーバ、プログラム、記憶媒体、シンクライアント通信中継方法
CN116186709B (zh) 基于虚拟化VirtIO技术卸载UEFI安全启动的方法、装置及介质
KR20230160744A (ko) 계산적 스토리지 다운로드 프로그램을 위한 인증 메커니즘
CN117081729A (zh) 交换和管理密钥的方法、构建方法和认证的方法
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