[go: up one dir, main page]

HK40028648B - Securely performing cryptographic operations - Google Patents

Securely performing cryptographic operations Download PDF

Info

Publication number
HK40028648B
HK40028648B HK62020017125.9A HK62020017125A HK40028648B HK 40028648 B HK40028648 B HK 40028648B HK 62020017125 A HK62020017125 A HK 62020017125A HK 40028648 B HK40028648 B HK 40028648B
Authority
HK
Hong Kong
Prior art keywords
user
biometric information
cryptographic operations
computer
encryption
Prior art date
Application number
HK62020017125.9A
Other languages
Chinese (zh)
Other versions
HK40028648A (en
Inventor
冯志远
李艳鹏
程龙
Original Assignee
创新先进技术有限公司
Filing date
Publication date
Application filed by 创新先进技术有限公司 filed Critical 创新先进技术有限公司
Publication of HK40028648A publication Critical patent/HK40028648A/en
Publication of HK40028648B publication Critical patent/HK40028648B/en

Links

Description

Securely performing cryptographic operations
Technical Field
This document relates to identity authentication techniques and data security.
Background
Authentication techniques are commonly used in computer networks to verify user identity and ensure data security. Identity information may be represented by a data set, as well as other information digitally stored or transmitted in a computer network. The computer may identify and authenticate the user based on the user's digital identity. For data security, it is important to ensure that the digital identity belongs to an authorized user, or in other words that the digital identity matches the actual identity.
With the development of technology, decentralized systems such as blockchain networks and internet of things (IoT) networks have emerged. Under decentralized systems, individuals can safely store their own identity information themselves. For example, a user may hold a digital wallet that stores a private key that the user may use to add a digital signature to authorize a transaction on a blockchain network or IoT device. The private key is typically stored on the computing device as a data string with cryptographic semantics and is intended to be accessible only to the user. As with other data strings, the private key can potentially be copied and shared. Any user having a private key can control the digital asset associated with the private key. Furthermore, if the private key is lost, the digital asset cannot be retrieved. Therefore, secure storage and efficient use of encryption keys can be important.
It is desirable to develop a key management technique that can securely manage an encryption key and perform an encryption operation based on the true identity of a user.
Disclosure of Invention
Techniques for securely managing encryption keys and performing encryption operations based on user identity information are described herein. These techniques generally involve: receiving biometric information associated with a user and a request to perform one or more cryptographic operations; in response to determining that the biometric information matches pre-stored biometric information, authorizing performance of one or more cryptographic operations.
Also provided herein are one or more non-transitory computer-readable storage media coupled to one or more processors and having instructions stored thereon that, when executed by the one or more processors, cause the one or more processors to perform operations in accordance with embodiments of the methods provided herein.
Also provided herein are systems for implementing the methods provided herein. The system includes one or more processors, and a computer-readable storage medium coupled to the one or more processors and having instructions stored thereon that, when executed by the one or more processors, cause the one or more processors to perform operations in accordance with embodiments of the methods provided herein.
It should be understood that any combination of the aspects and features described herein may be included in accordance with the methods herein. That is, methods according to the present disclosure are not limited to the combinations of aspects and features specifically described herein, but also include any combination of the aspects and features provided.
The details of one or more embodiments of the disclosure are set forth in the accompanying drawings and the description below. Other features and advantages will be apparent from the description and drawings, and from the claims.
Drawings
Fig. 1 is a diagram illustrating an example of an identity encryption chip that may be used to perform the processing of embodiments herein.
Fig. 2 is a flow diagram illustrating an example of a process for performing an encryption operation using an identity encryption chip (ICC) according to embodiments herein.
Fig. 3 is a flow diagram illustrating an example of a process for generating a token for performing one or more cryptographic operations using ICC in accordance with embodiments herein.
Fig. 4 is a flow diagram illustrating an example of a process for performing one or more cryptographic operations using ICC based on tokens according to embodiments herein.
Fig. 5 is a diagram illustrating an example of a key management device according to embodiments herein.
Fig. 6 is a swim lane diagram illustrating an example of a process of performing data encryption and decryption using an Identity Information Card (IIC) according to an embodiment herein.
Figure 7 depicts an example of a computing device into which an IIC may be inserted, integrated, or communicatively coupled according to embodiments herein.
Fig. 8 is a swim lane diagram illustrating an example of processing according to an embodiment herein.
Fig. 9 depicts an example of a method that may be performed in accordance with embodiments herein.
Fig. 10 depicts an example of modules of an apparatus according to embodiments herein.
Like reference numbers and designations in the various drawings indicate like elements.
Detailed Description
Techniques for securely managing encryption keys and performing encryption operations based on user identity information are described herein. These techniques generally involve: receiving biometric information associated with a user and a request to perform one or more cryptographic operations; in response to determining that the biometric information matches pre-stored biometric information, authorizing performance of one or more cryptographic operations.
Fig. 1 is a diagram illustrating an example of an ICC100 for performing a process that may be used to perform embodiments herein.
At a higher level, the ICC100 can be a computer chip that includes a memory 102 and a logic computation component 104. The ICC100 may be used to securely perform encryption operations. In some embodiments, ICC100 may be a chip set that includes one or more chip components. The memory 102 and the logic computation component 104 may be integrated into different chip components. In some embodiments, memory 102 may be used to provide persistent storage. In some examples, the memory 102 may be a programmable read-only memory (PROM) that allows data to be written once and only read thereafter. In some examples, the memory 102 may be an Electrically Erasable Programmable Read Only Memory (EEPROM) or flash memory, which may be reformatted and reprogrammed. In some embodiments, the logic computation component may be an Application Specific Integrated Circuit (ASIC) or a Single Chip Microcomputer (SCM).
In some computer networks, cryptography is implemented to maintain the privacy of data or transactions. For example, in a blockchain network, if two nodes want to maintain transaction privacy so that other nodes in the blockchain network cannot discern the details of the transaction, the nodes may encrypt the transaction data. Exemplary encryption operations include, but are not limited to, symmetric key encryption and asymmetric key encryption. Symmetric encryption refers to an encryption process that uses a single key to both encrypt (generate ciphertext from plaintext) and decrypt (generate plaintext from ciphertext).
Asymmetric encryption uses key pairs, each key pair comprising a private key and a public key, the private key being known only to the respective user, and the public key being publicly disseminated. A user may encrypt data using a public key of another user, and the encrypted data may be decrypted using a private key of the other user.
The digital signature may be provided using asymmetric encryption, which enables a participant in a transaction to confirm other participants in the transaction and the validity of the transaction. For example, a user may digitally sign a message, while another user may confirm that the message was sent by the user based on the digital signature. Digital signatures may also be used to ensure that messages are not tampered with during transmission. For example, user a will send a message to user B. User a generates a hash value for the message and then encrypts the hash value using its private key to provide a digital signature that is the encrypted hash value. User a attaches a digital signature to the message and sends the message with the digital signature to user B. User B decrypts the digital signature using user a's public key and extracts the hash value. User B hashes the message and compares the hash values. If the hash values are the same, user B can confirm that the message is indeed from user A and has not been tampered with.
The ICC100 may be used to securely manage a user's encryption key and perform encryption operations based on authenticating the user's identity information. In some embodiments, the identity information may be biometric information of the user such as a fingerprint, voiceprint, heartbeat information, and iris information. The memory 102 may be used to store identity information and encryption keys for users of the ICC 100. The memory 102 may also store an authentication algorithm (e.g., as computer executable code) and an encryption operation algorithm (e.g., as computer executable code). In some embodiments, the information and algorithms stored in the memory 102 are encrypted to prevent leakage even if the ICC100 is reverse engineered. When a request is received from a user to perform a cryptographic operation, the logical compute component 104 can use the identity information collected from the user and the trusted user identity information stored in the memory 102 to verify the identity of the user based on an authentication algorithm. For example, if the identity information is a user fingerprint image of a user fingerprint. The identity authentication algorithm may be a local authentication algorithm that compares the fingerprint image collected from the user with the stored fingerprint image. If the collected fingerprint image matches the stored fingerprint image, the identity of the user is successfully verified, and the logical computing component 104 can then allow the encryption key to be stored, or allow the requested encryption operation to be performed using an existing encryption key stored in the memory 102. After the encryption operation is performed, the operation result may be output by the ICC 100. By using the ICC100, encryption operations can be stored or performed only after verifying or authenticating that the identity of the user is authentic. In this way, the authority of the user to use the ICC100 can be guaranteed. Further, since the encryption key is stored as a ciphertext in the ICC100, the encryption operation is performed inside the ICC 100. Only the operation result is output from the ICC 100. In this way, the security of the encryption key can be ensured.
At 108, the encryption operation algorithm is written to the ICC 100. Encryption operation algorithms may be used to perform encryption operations such as data encryption, data decryption, and digital signature verification. At 110, an authentication algorithm may be written to the ICC 100. An authentication algorithm may be used to authenticate the identity of a user to determine whether the user may be allowed to perform encryption operations using the ICC 100.
At 112, the authorization identity information is input to the ICC 100. The authorisation identity information may be input to the ICC100 during initialisation of the ICC 100. In some embodiments, the authorized identity information may be biometric information of the user, such as a fingerprint, voiceprint, heartbeat information, or iris information. In some embodiments, the authorization identity information may be input by the owner of the ICC 100. As will be discussed further in embodiments herein, a user entering the authorization identity information may use the authorization identity information to control the encryption key input to the ICC 100. The encryption key cannot be input to the ICC100 unless the user identity can be verified based on the authorization identity information.
The authorization identity information may be used to perform authentication to provide authorization to store encryption keys or perform encryption operations. The identity information may be collected by a computing device communicatively coupled with the ICC 100. For example, the computing device may be a smart watch capable of detecting biometric information of a user.
In some embodiments, the contents of memory 102 are cleared and authorization identity information is written to memory 102. In some embodiments, memory 102 is a persistent storage memory. In some embodiments, to prevent tampering, the user's identity information can only be written to the memory location of memory 102 once. If the existing identity information needs to be replaced with new identity information, the contents of the memory 102 may be erased before the new identity information is written. In some embodiments, the authorization identity information may be encrypted before being written to memory 102 to enhance security.
At 114, one or more encryption keys are written to the memory 102 of the ICC 100. In some embodiments, the identity information of the user and the request to write the one or more encryption keys to memory 102 are received before writing the one or more encryption keys to memory 102. The identity information may be biometric information such as a fingerprint, voiceprint, heartbeat information, or iris information. The identity information may be collected by a computing device communicatively coupled with the ICC 100. In some embodiments, the authorized identity information is read from the memory 102 to verify the identity of the user. Authentication may be performed based on matching the identity information of the user received at 114 with authorized identity information. If the identity information matches, the verification is successful. The user is then determined to be an authorized user of the ICC100 and one or more encryption keys are allowed to be written to the memory 102. Otherwise, the request is denied. In some embodiments, one or more encryption keys are encrypted prior to being written to memory 102 to enhance security. In some embodiments, the one or more encryption keys may be written to a memory location of the memory 102 that is separate from the memory location in which the authorization information is stored.
In some embodiments, the ICC100 can receive identity information of a user and a request to perform an encryption operation. The identity information may be collected by a computing device communicatively coupled with the ICC 100. For example, the computing device may be a smart watch capable of detecting biometric information of a user. After collecting the identity information, it may be sent to the ICC 100. In some embodiments, data to perform an encryption operation is also sent to the ICC 100. For example, if the encryption operation is encryption, the corresponding data may be a data file to be encrypted. The authorized identity information written in memory 102 at 112 may then be read from memory 102 to perform authentication. Authentication may be performed based on comparing the identity information received at 114 with authorized identity information. If the identity information matches, the authentication is successful and the corresponding encryption key information is read from memory 102 to perform the encryption operation. If the identity information does not match, the verification is unsuccessful. The request to perform the cryptographic operation may then be denied. In some embodiments, authentication may be performed using an authentication algorithm written at 110 to the ICC100 based on the particular type of identity information received. In some embodiments, the cryptographic operations may be performed based on a cryptographic operation algorithm written to the ICC100 at 108. As described above, the encryption operation may be encryption, decryption, or adding a digital signature to the data. After the encryption operation is performed, the operation result may be output at 116.
Fig. 2 is a flow diagram illustrating an example of a process 200 for performing an encryption operation using ICC according to embodiments herein. At 202, a request to perform an encryption operation is received. Examples of encryption operations may include data encryption, decryption, and adding digital signatures.
At 204, identity information of the user is received. As discussed in the description of fig. 1, identity information may be collected by a computing device and sent to the ICC. At 206, the identity information may be verified. In some embodiments, the identity information may be compared to identity information stored in a memory of the ICC. If the identity information matches the stored identity information, the authentication is successful and the requested encryption operation may then be performed at 208 using the user's encryption key stored in the memory of the ICC. Otherwise, process 200 ends at 212. After 208, process 200 proceeds to 210 where the results of the operation are returned. The result of the operation may depend on the encryption operation performed at 208. For example, if the encryption operation is file encryption, a file encrypted using the user's public key may be returned. Similarly, if the encryption operation is file decryption, a file decrypted using the user's private key may be returned. If the encryption operation is the addition of a digital signature, a file with the user's digital signature generated by the user's private key may be returned. After 210, processing ends at 212.
Fig. 3 is a flow diagram illustrating an example of a process 300 for generating a token for performing one or more cryptographic operations using ICC in accordance with embodiments herein. At 302, a request to authorize performance of one or more cryptographic operations is received by an ICC. The requested authorization may be one or more authorizations to perform the cryptographic operation multiple times or within a predetermined time period. For example, after verifying the user's identity, the user may perform an encryption operation using the ICC in the requested amount or for the requested period of time without verifying his identity again. Exemplary encryption operations may include data encryption, decryption, or adding a digital signature.
At 304, the icc receives identity information of the user. The identity information may be collected by a computing device communicatively coupled with the ICC 100. For example, the computing device may be a smart watch capable of detecting biometric information of the user, such as heartbeat or fingerprint information. After collecting the identity information, it may be sent to the ICC 100.
At 306, the received identity information may be verified. Verification may be performed based on matching the identity information of the user with authorized identity information. If the identity information matches, the verification is successful. The user is then determined to be an authorized user of the ICC100 and one or more encryption keys are allowed to be written to the memory 102. Otherwise, the verification is not successful, and process 300 ends at 312. If the identity information is successfully verified, a token is generated and temporarily stored in the ICC at 308. A token may be generated based on the request received at 302. In some embodiments, the token may provide authorization to perform cryptographic operations multiple times or within a predetermined time without verifying the user's identity. For example, a token may be generated to provide authorization to add a digital signature to the next five files received or files received in the next three hours, whichever condition is first satisfied. In some embodiments, tokens may be cleared and removed from the ICC when they expire or run out.
At 310, token information is returned. In some embodiments, the returned token information may be viewable by a computing device into which the user is inserted or integrated or communicatively coupled via the ICC. For example, if a token is generated based on a request to perform five file encryptions without verifying the user's identity, the user may return and view such information. After 310, process 300 ends at 312. After generating the token, the cryptographic operation may be performed based on the user authorization indicated by the token. An example of such a process is discussed in the description of fig. 4.
Fig. 4 is a flow diagram illustrating an example of a process 400 for performing one or more cryptographic operations using ICC based on tokens according to embodiments herein. At 402, a request to perform an encryption operation is received. At 404, a token temporarily stored in the ICC is retrieved. At 406, it is determined whether the requested cryptographic operation is authorized based on the token. If so, process 400 proceeds to 408 where an encryption operation is performed at 408. The encryption operation results may be returned at 410 before process 400 ends at 412. For example, if the token indicates that the encryption operation can be performed three times before user authentication is required, and the request is to perform data encryption, then the encryption operation on the data can be authorized and performed. The encrypted data may be returned at 410. If the token indicates that decryption of the file is possible within the next 30 minutes, the token will expire after 30 minutes and the subsequently received request to perform file decryption will be unauthorized and denied. If at 406 it is determined that the requested operation is unauthorized, process 400 ends at 412. In some embodiments, rather than ending process 400 at 412, the user may be prompted to verify his identity information again to obtain authorization to perform the requested cryptographic operation.
Fig. 5 is a diagram illustrating an example of a key management apparatus 500 according to embodiments herein. In some embodiments, the encryption key used by the ICC to perform an encryption operation for a user may be managed by the key management device 500. The key management device 500 may perform key management 504 and algorithm management 514. Key management 504 may include storage 506, writing 508, random generation 510, and deletion 512 of encryption keys. The encryption key is a key associated with an authorized user of the ICC to perform an encryption operation.
The algorithms managed by algorithm management 514 may include storing and managing authentication algorithms 516, digital signature verification algorithms 518, encryption and decryption algorithms 520, and token algorithms 522. Authentication algorithm 516 may be used to perform authentication as discussed in the description of step 306 of fig. 3. Digital signature verification algorithm 518 may be used to perform digital signature verification. The encryption and decryption algorithm 520 may be used to perform the requested encryption operation as discussed in step 208 of fig. 2 and step 408 of fig. 4. The token algorithm 522 may be used to manage a time limit or a number limit for performing the requested cryptographic operations without verifying the user's identity, as discussed in the description of fig. 3 and 4.
In some embodiments, the key management device 500 may serve as a backup to the ICC. The encryption key and algorithm used to perform the encryption operation may be retrieved from the key management device 500 even if the ICC is lost or corrupted.
In some embodiments, key management device 500 may also perform input management 524. The key management device 500 may be communicatively coupled to the ICC to manage algorithm input 526, identity information input 528, encryption key input 530, digital signature generation 532, and identity verification 534.
Fig. 6 is a swim lane diagram illustrating an example of a process 600 of performing data encryption and decryption using an Identity Information Card (IIC) 604 according to embodiments herein. At a higher level, the process 600 is performed between the computing device 602 and the IIC 604. The computing device 602 requests the IIC604 to decrypt the encrypted file so that it can update the file. After updating the file, the computing device 602 may request that the updated file be encrypted by the IIC604 and store the encrypted file.
Computing device 602 may be any computing device, such as the computing device depicted in fig. 7. Figure 7 depicts an example 700 of a computing device into which an IIC may be inserted, integrated, or communicatively coupled according to embodiments herein. In some embodiments, the IIC 702 may be an electronic card that may be conveniently inserted into a computing device. In some embodiments, the IIC 702 may be a housing or hardware package that houses the IIC 702. In some embodiments, ICC 704 may be integrated or embedded into IIC 702.
Exemplary computing devices to which the IIC 702 may be integrated or plugged into or communicatively coupled may include, but are not limited to, an internet of things (IoT) device 706, a smart bracelet 708, a smart watch 710, a laptop 712 (or desktop computer), or a smartphone 714. The IIC 702 may communicate with the computing device over a wired or wireless connection.
Referring back to FIG. 6, at 606, the computing device 602 initiates or receives a file decryption request. In some embodiments, the computing device 602 can initiate a file decryption request. The computing device 602 may include a computer, server, or smartphone. In some embodiments, computing device 602 may be a wearable device, such as a smart band or smart watch, that may receive a decryption request from another computing device capable of initiating the request. At 608, the computing device 602 retrieves the file to decrypt. At 610, the computing device 602 collects identity information for authentication using the ICC included in the IIC 604. In some embodiments, the identity information may be biometric information of the user, such as a fingerprint, voiceprint, heartbeat information, and iris information. The computing device 602 may include a fingerprint sensor, microphone, heartbeat sensor, or iris scanner to collect biometric information. The file decryption request, the file, and the collected identity information may then be sent to the IIC 604.
The iic604 receives the file decryption request, the file, and the identity information 612. At 614, the iic604 verifies that the received identity information matches the pre-stored authorized identity information. Details of performing the verification are discussed in the description of FIG. 1. If the verification is successful, the file may be decrypted 616 by the ICC included in the IIC 604. Otherwise, processing ends at 632. The decrypted file may be returned to the computing device 602. After receiving the decrypted file, the file may be displayed on the computing device 602 at 618. In some embodiments, the file may be sent to a computer or a separate display device for display. At 620, the displayed file may be updated and a request may be sent back to the IIC 640 for encryption. At 622, the computing device may collect identity information of the user to be authenticated by the IIC for file encryption.
The iic604 receives the file encryption request, the updated file, and the identity information at 624. At 626, the iic604 verifies that the identity information matches the pre-stored authorized identity information. If the verification is successful, process 600 proceeds to 628 where IIC604 encrypts the updated file and returns the encrypted updated file to computing device 602. Otherwise, process 600 ends at 632. At 630, the computing device 602 receives and stores the encrypted file. In some embodiments, the computing device 602 may forward the encrypted file to another computing device for storage.
FIG. 8 is a swim lane diagram illustrating an example of a process 800 according to embodiments herein. In particular, process 800 may be performed to securely and conveniently add a digital signature to a blockchain transaction. At a higher level, process 800 may be performed by wearable device 802, smart terminal 804, and block link point 806. The smart terminal 804 may be a computing device such as a computer, smartphone, or point of sale terminal. The wearable device 802 may be a wearable computing device such as a smart watch or smart bracelet. Wearable device 802 may include integrated, embedded, or inserted ICCs such as the ICCs discussed in the description of fig. 1. Blockchain node 806 may be referred to as a consensus node, which may be operated by a respective entity (e.g., blockchain user, financial institution, insurance company). Consensus nodes in the blockchain may execute consensus protocols to add transactions to the blockchain and update the overall state of the blockchain network.
At 808, the intelligent terminal 804 receives the transaction request. At 810, the smart terminal collects transaction data to perform transactions on the blockchain. The transaction data may represent a transaction between two or more participants. Examples of transactions may include, but are not limited to, exchanging things of value (e.g., assets, products, services, currency).
At 812, the smart terminal 804 calculates a hash value of the transaction data. The hash process is a process of converting transaction data (provided as character string data) into a hash value of a fixed length (also provided as character string data). The hash value cannot be de-hashed to obtain the transaction data. The hashing process ensures that even slight changes in the transaction data result in an entirely different hash value. Further, as described above, the hash value has a fixed length. That is, the length of the hash value is fixed regardless of the size of the transaction data. The hash process includes processing the transaction data through a hash function to generate a hash value. Examples of hash functions include, but are not limited to, secure Hash Algorithm (SHA) -256, which outputs a 256-bit hash value.
At 814, the smart terminal requests the wearable device to add a digital signature to the hashed transaction data. The digital signature may be generated using asymmetric encryption, which enables a participant in the transaction to confirm another participant in the transaction and the validity of the transaction. For example, a user of the smart terminal 804 may digitally sign the hashed transaction data using a private key, and a recipient may confirm that the hashed transaction data was sent by the user based on the digital signature. Digital signatures may also be used to ensure that messages are not tampered with during transmission.
At 816, wearable device 802 may verify the identity of the user using the embedded ICC. The smart terminal 804 or the wearable device 802 may collect identity information of the user. The collected identity information may be compared to authorized identity information previously stored on wearable device 802. If the identity used is successfully verified, the ICC of the wearable device 802 can be used to add a digital signature to the hashed transaction data and return the digitally signed hashed transaction data to the smart terminal 804 at 818.
At 820, the intelligent terminal 804 completes the transaction preparation. At 822, the smart terminal 804 initiates a transaction. At 824, the block link point performs the transaction. At 826, the block link returns the transaction results to the smart terminal 804. Thereafter, process 800 ends at 828.
Fig. 9 depicts an example of a method 900 that may be performed in accordance with embodiments herein. For clarity of presentation, the following description generally describes the method 900 in context with other figures herein. However, it should be understood that the method 900 may be performed, for example, by any suitable system, environment, software, and hardware, or combination of systems, environments, software, and hardware. In some embodiments, the various steps of method 900 may be performed in parallel, in combination, in a loop, or in any order. In some embodiments, method 900 may be performed by an ICC as described according to embodiments herein.
At 902, biometric information associated with a user and a request to perform one or more cryptographic operations based on one or more cryptographic keys stored in memory of an ICC are received. In some embodiments, the one or more encryption operations are performed based on an asymmetric key pair associated with the user, and the encryption operation (cryptographic operation) includes one or more of an encryption operation, a decryption operation, and a digital signature generation operation. In some embodiments, the memory is a programmable read-only memory (PROM), electrically Erasable PROM (EEPROM), or flash memory, and the biometric information and asymmetric key pair are stored in separate memory locations of the memory.
At 904, biometric information associated with the user is compared with biometric information pre-stored in memory of the ICC as pre-stored biometric information.
At 906, in response to determining that the biometric information matches the pre-stored biometric information, one or more cryptographic operations are authorized to be performed. In some embodiments, one or more cryptographic operations are performed to produce an operation result. The operation result is sent to a computing device communicatively coupled to the ICC for presentation to the user.
In some embodiments, the request is for performing one or more cryptographic operations at least one of a predetermined number of times or over a predetermined period of time, the one or more cryptographic operations authorized to be performed at least one of the predetermined number of times and over the predetermined period of time, and the computer-implemented method 900 further comprises: generating a token recording at least one of a predetermined number of times and a predetermined time period; temporarily storing the token until the token expires, wherein the token expires in response to performing the one or more cryptographic operations a predetermined number of times or a predetermined period of time; and transmit the token to the computing device.
In some embodiments, the request is a first request, the operation result is a first operation result, and the method 900 further comprises: receiving a second request for performing an encryption operation; determining that the token has not expired; and performing an encryption operation to produce a second operation result. In some embodiments, the first request is for decrypting the first data, the second operation results in plaintext of the first data, the biometric information is first biometric information, and the computer-implemented method further comprises: receiving second biometric information and a third request for encrypting second data associated with the plaintext of the first data; in response to determining that the second biometric information matches pre-stored biometric information, encrypting the second data to provide encrypted second data; and transmitting the encrypted second data to the computing device.
In some embodiments, the comparison of the biometric information with pre-stored biometric information is performed based on biometric identification; and the biometric identification includes one or more of fingerprint identification, voiceprint identification, iris scan, facial identification, and heartbeat identification.
Fig. 10 depicts an example of modules of an apparatus according to embodiments herein. Apparatus 1000 may be an example of an embodiment of an ICC. The apparatus 1000 may correspond to the embodiments described above, and the apparatus 1000 comprises the following:
a receiving module 1002 for receiving biometric information associated with a user and a request to perform one or more cryptographic operations based on one or more cryptographic keys stored in a memory of an ICC.
An identity information comparison module 1004 for comparing biometric information associated with the user with biometric information pre-stored in the memory of the ICC as pre-stored biometric information.
An authorization module 1006 authorizes execution of one or more cryptographic operations in response to determining that the biometric information matches pre-stored biometric information.
In an alternative embodiment, the comparison of the biometric information with the pre-stored biometric information is performed based on biometric identification; biometric identification includes one or more of fingerprint identification, voiceprint identification, iris scan, facial identification, and heartbeat identification.
In an alternative embodiment, the one or more encryption operations are performed based on an asymmetric key pair associated with the user, and the encryption operations include one or more of an encrypt operation, a decrypt operation, and a digital signature generation operation.
In an alternative embodiment, the memory is a programmable read-only memory (PROM), electrically Erasable PROM (EEPROM) or flash memory, and the biometric information and the asymmetric key pair are stored in separate memory locations of the memory.
The systems, apparatuses, modules or units shown in the foregoing embodiments may be implemented by using a computer chip or entity, or may be implemented by using an article having a specific function. A typical implementation device is a computer, and the computer may be a personal computer, laptop computer, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email messaging device, game console, tablet, wearable device, or any combination of these devices.
For the implementation of the functions and roles of each module in the device, reference may be made to the implementation of the corresponding steps in the previous method. Details are omitted here for simplicity.
Since the device implementation substantially corresponds to the method implementation, reference may be made to the relevant description in the method implementation for the relevant components. The previously described device implementations are merely examples. Modules described as separate parts may or may not be physically separate, and parts shown as modules may or may not be physical modules, may be located in one location, or may be distributed across multiple network modules. Some or all of the modules may be selected based on actual needs to achieve the goals addressed herein. Those of ordinary skill in the art will understand and appreciate the embodiments of the present application without inventive effort.
The techniques described herein produce several technical effects. For example, embodiments of the subject matter allow a user of the ICC to store multiple encryption keys to securely perform an encryption operation. The encryption key may be stored to the ICC based on verifying the identity information of the user. If the authentication of the identity information fails, the ICC will reject the input of the encryption key information.
In order to request the ICC to perform an encryption operation, it is necessary to collect the identity information of the user, and this collected identity information needs to be verified as authentic by the identity information previously authenticated and stored in the ICC. In this way, it can be ensured that the user requesting the encryption operation is the owner of the encryption key.
Furthermore, the identity information and encryption key may be encrypted before storage to the memory of the ICC. This information is only decrypted in the ICC to perform the corresponding authentication and encryption operations. The encryption operation is performed inside the ICC, and only the operation result is output from the ICC. Thus, the identity information and encryption key of the ICC user are secure and will not be revealed even if the ICC is hacked or reverse engineered. In some embodiments, the key management device may be used to store the identity information and encryption key in ciphertext to provide backup to the ICC and further enhance data security.
The computing device may be operable to collect user identity information and initiate a request for an encryption operation. The ICC can communicate wirelessly with the computing device through various communication protocols or it can be integrated or plugged into the computing device to be readily used for secure cryptographic operations.
Implementations of the subject matter, the acts, and the operations described herein may be implemented in digital electronic circuitry, tangibly embodied computer software or firmware, computer hardware, including the structures disclosed herein and their structural equivalents, or combinations of one or more of them. Implementations of the subject matter described herein may be implemented as one or more computer programs, e.g., one or more modules of computer program instructions encoded on a computer program carrier for execution by, or to control the operation of, data processing apparatus. For example, a computer program carrier may include one or more computer-readable storage media having instructions encoded thereon or stored thereon. The carrier may be a tangible, non-transitory computer-readable medium such as a magnetic, magneto-optical disk or optical disk, a solid state drive, random Access Memory (RAM), read Only Memory (ROM), or other media types. Alternatively or additionally, the carrier may be an artificially generated propagated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal, that is generated to encode information for transmission to suitable receiver apparatus for execution by the data processing apparatus. The computer storage medium may be or be partially a machine-readable storage device, a machine-readable storage substrate, a random or serial access memory device, or a combination of one or more of them. Computer storage media is not a propagated signal.
A computer program, which may also be referred to or described as a program, software application, app, module, software module, engine, script, or code, may be written in any form of programming language, including compiled or interpreted languages, or declarative or procedural languages; it can be deployed in any form, including as a stand-alone program or as a module, component, engine, subroutine, or other unit suitable for execution in a computing environment, which may include one or more computers at one or more locations interconnected by a data communication network.
A computer program may, but need not, correspond to a file in a file system. The computer program may be stored in: a portion of a file that holds other programs or data, e.g., one or more scripts stored in a markup language document; a single file dedicated to the program in question; or a plurality of coordinated files, such as files that store one or more modules, sub programs, or portions of code.
Processors for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Typically, a processor will receive instructions and data from a non-transitory computer-readable medium coupled to the processor for execution of a computer program.
The term "data processing apparatus" includes all types of apparatus, devices, and machines for processing data, including by way of example a programmable processor, a computer, or multiple processors or computers. The data processing apparatus can comprise special purpose logic circuitry, e.g., an FPGA (field programmable gate array), an ASIC (application-specific integrated circuit), or a GPU (graphics processing unit). The apparatus can include, in addition to hardware, code that creates an execution environment for the computer program, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them.
The processes and logic flows described herein can be performed by one or more computers or processors executing one or more computer programs to perform operations by operating on input data and generating output. The processes and logic flows can also be performed by, and in combination with, special purpose logic circuitry, e.g., an FPGA, an ASIC, or a GPU, and one or more programmed computers.
A computer suitable for executing a computer program may be based on a general and/or special purpose microprocessor, or any other kind of central processing unit. Generally, a central processing unit will receive instructions and data from a read-only memory and/or a random access memory. Elements of a computer may include a central processing unit for executing instructions and one or more memory devices for storing instructions and data. The central processing unit and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.
Typically, a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices. The mass storage device may be, for example, a magnetic, magneto-optical disk or optical disk, a solid state drive, or any other type of non-transitory computer readable medium. However, a computer need not have such devices. Thus, a computer may be coupled to one or more mass storage devices, e.g., local and/or remote to one or more memories. For example, the computer may include one or more local memories as an integral part of the computer, or the computer may be coupled to one or more remote memories in a cloud network. Moreover, a computer may be embedded in another device, e.g., a mobile telephone, a Personal Digital Assistant (PDA), a mobile audio or video player, a game console, a Global Positioning System (GPS) receiver, or a portable storage device, e.g., a Universal Serial Bus (USB) flash drive, to name a few.
Components may be "coupled" to one another by being connected in communication with one another either directly or through one or more intermediaries, e.g., electrical or optical connections. Components may also be "coupled" to one another if one of the components is integrated into another component. For example, a mass storage component (e.g., an L2 cache component) integrated into a processor is "coupled" to the processor.
To provide for interaction with a user, embodiments of the subject matter described herein can be implemented on or configured to communicate with a computer having: a display device, e.g., an LCD (liquid crystal display) monitor, for displaying information to a user; and input devices through which a user may provide input to the computer, such as a keyboard and a pointing device, such as a mouse, trackball or touch pad. Other types of devices may also be used to provide for interaction with a user; for example, feedback provided to the user can be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback; and may receive any form of input from the user, including acoustic, speech, or tactile input. In addition, the computer may interact with the user by sending and receiving documents to and from the device used by the user; for example, by sending a web page to a web browser on the user device in response to a request received from the web browser, or by interacting with an application (app) running on the user device, such as a smartphone or electronic tablet. In addition, the computer may interact with the user by taking turns sending text messages or other forms of messages to the personal device (e.g., a smartphone running a messaging application) and receiving response messages from the user.
The term "configured" is used herein in connection with systems, apparatuses, and computer program components. For a system of one or more computers configured to perform a particular operation or action, it is meant that the system has installed thereon software, firmware, hardware, or a combination thereof that in operation causes the system to perform that operation or action. For one or more computer programs configured to perform a particular operation or action, it is meant that the one or more programs include instructions, which when executed by a data processing apparatus, cause the apparatus to perform the operation or action. For a specific logic circuit configured to perform a particular operation or action, it means that the circuit has electronic logic to perform the operation or action.
While this document contains many specific implementation details, these should not be construed as limitations on the scope of what is claimed, as defined by the claims themselves, but rather as descriptions of specific features of particular embodiments. Various features that are described in the context of a single embodiment herein can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination.
Similarly, while operations are depicted in the drawings and are recited in the claims in a particular order, this should not be understood as: it may be desirable to perform the operations in the particular order shown, or in sequence, or to perform all of the operations shown, in order to achieve desirable results. In some cases, multitasking and parallel processing may be advantageous. Moreover, the division of the various system modules and components in the embodiments described above should not be understood as requiring such division in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.
Specific embodiments of the subject matter have been described. Other embodiments are within the scope of the following claims. For example, the actions recited in the claims can be performed in a different order and still achieve desirable results. As one example, the processes depicted in the accompanying figures do not require the particular order shown, or sequential order, to achieve desirable results. In some cases, multitasking and parallel processing may be advantageous.

Claims (8)

1. A computer-implemented method for securely performing cryptographic operations, the method comprising:
receiving biometric information associated with a user and a first request to perform one or more cryptographic operations based on one or more cryptographic keys stored in a memory of an identity cryptographic chip ICC; wherein the first request is for performing the one or more cryptographic operations a predetermined number of times and/or for a predetermined period of time, the one or more cryptographic operations being authorized to be performed a predetermined number of times and/or for a predetermined period of time;
comparing the biometric information associated with the user with biometric information pre-stored in the memory of the ICC as pre-stored biometric information; and
authorizing the one or more cryptographic operations to be performed in response to determining that the biometric information matches the pre-stored biometric information;
generating a token recording the predetermined number of times and/or the predetermined period of time;
temporarily storing the token until the token expires, wherein the token expires in response to the performance of the one or more cryptographic operations the predetermined number of times or the predetermined period of time having elapsed; and
transmitting the token to a computing device communicably coupled to the ICC;
receiving a second request to perform an encryption operation;
determining that the token is not expired; and
the cryptographic operation is performed to produce a second operation result.
2. A computer-implemented method for securely performing cryptographic operations as recited in claim 1, further comprising:
performing the one or more cryptographic operations to produce a first operation result; and
transmitting the first operation result to a computing device communicably coupled to the ICC for presentation to the user.
3. A computer-implemented method for securely performing cryptographic operations as in claim 1, wherein the first request is for decrypting first data, the second operation result is plaintext of the first data, the biometric information is first biometric information, and the computer-implemented method further comprises:
receiving second biometric information and a third request to encrypt second data associated with plaintext of the first data;
in response to determining that the second biometric information matches the pre-stored biometric information, encrypting the second data to provide encrypted second data; and
sending the encrypted second data to the computing device.
4. A computer-implemented method for securely performing cryptographic operations as recited in claim 1, wherein:
performing a comparison of the biometric information with the pre-stored biometric information based on biometric identification; and
the biometric identification includes one or more of fingerprint identification, voiceprint identification, iris scan, facial identification, and heartbeat identification.
5. A computer-implemented method for securely performing cryptographic operations as in claim 1,
performing the one or more cryptographic operations based on an asymmetric key pair associated with the user, an
The encryption operation includes one or more of an encryption operation, a decryption operation, and a digital signature generation operation.
6. A computer-implemented method for securely performing cryptographic operations as in claim 5,
the memory is a programmable read-only memory PROM, an electrically erasable PROM, EEPROM or flash memory, and
the biometric information and the asymmetric key pair are stored in separate memory locations of the memory.
7. A system for securely performing cryptographic operations, comprising:
one or more processors; and
one or more computer-readable memories coupled to the one or more processors and having instructions stored thereon that are executable by the one or more processors to perform the method of any of claims 1-6.
8. An apparatus for securely performing cryptographic operations, the apparatus comprising a plurality of modules for performing the method of any of claims 1-6.
HK62020017125.9A 2019-03-29 Securely performing cryptographic operations HK40028648B (en)

Publications (2)

Publication Number Publication Date
HK40028648A HK40028648A (en) 2021-02-05
HK40028648B true HK40028648B (en) 2023-05-12

Family

ID=

Similar Documents

Publication Publication Date Title
US11258591B2 (en) Cryptographic key management based on identity information
CN110999254B (en) Securely performing cryptographic operations
US11251941B2 (en) Managing cryptographic keys based on identity information
HK40028648B (en) Securely performing cryptographic operations
HK40028648A (en) Securely performing cryptographic operations
HK40016698B (en) Managing cryptographic keys based on identity information
HK40016698A (en) Managing cryptographic keys based on identity information
HK40029012A (en) Cryptographic key management based on identity information
HK40029012B (en) Cryptographic key management based on identity information