Key distribution method and device, and storage medium
By verifying the public identification of IoT devices and encrypted the keys generated by encrypted, the problem of unable to use the SM9 algorithm to generate key generate key to generate the key to generate the key to generate key transmission.
Patent Information
- Application Number
- CN202411267225.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-09-10
- Publication Date
- 2025-01-24
AI Technical Summary
IoT devices usually lack mobile phone numbers or email accounts when leaving the factory, cannot use the SM9 algorithm to generate keys, and public information is easily forged, resulting in insufficient security of key transmission.
By verifying the device public identity carried in the key application request initiated by the target device, if it complies with the rules, the target key is generated, encrypted and sent to the device.
It ensures the security of the key transmission process, prevents key leaks and device identity theft, and realizes safe key application and distribution.
Smart Images

Figure CN119363325A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of information security technology, and in particular to a key distribution method, device and storage medium. Background Art
[0002] In the digital age, information security is becoming increasingly important. When private data is transmitted, it is usually encrypted, and encryption methods require the use of keys.
[0003] At present, common keys include keys generated based on the SM9 algorithm. It mainly selects a unique identification ID, such as a mobile phone number, email address, etc., as the SM9 public key. The key management center generates a private key based on the identification and issues the private key by mobile phone number or email, so only people who own the phone or know the email password can get the private key, thereby ensuring the security of SM9 key transmission. On the device side, the device's unique identification ID, such as the device's serial number, MAC address and other unique information, is usually selected as the SM9 identifier.
[0004] However, some IoT devices usually do not have information such as mobile phone numbers or email accounts when they leave the factory, so they cannot be used as identifiers for the SM9 algorithm. If public information such as device serial numbers, MAC addresses, and IP addresses are used as key identifiers for SM9, on the one hand, key crackers can easily forge these public information to replace the device; on the other hand, the device itself cannot provide the key management center with valid proof that it owns the identifier. Summary of the invention
[0005] The present application at least provides a key distribution method, apparatus, system, device and computer-readable storage medium.
[0006] The first aspect of the present application provides a key distribution method, including: in response to receiving a key application request initiated by a target device, verifying the device public identification carried by the key application request; determining a target key based on a verification result of compliance of the device public identification and the device public identification; encrypting the target key, and sending the encrypted target key to the target device.
[0007] In one embodiment, the method of determining the target key based on the verification result of the compliance of the device public identification and the device public identification includes: if the verification result of the device public identification indicates that the identification is compliant, generating random data and sending it to the target device end, so that the target device end determines the information to be authenticated based on the random data and the device private identification of the target device end, and sends the information to be authenticated to the server end; in response to receiving the information to be authenticated sent by the target device end, judging whether the information to be authenticated is correct; if the information to be authenticated is correct, generating the target key based on the device public identification.
[0008] In one embodiment, in response to receiving the information to be authenticated sent by the target device, determining whether the information to be authenticated is correct includes: searching for a preset compliant private identifier based on the device public identifier; determining the authentication information based on the random data and the compliant private identifier; if the information to be authenticated matches the authentication information, determining that the information to be authenticated is correct; if the information to be authenticated does not match the authentication information, determining that the information to be authenticated is incorrect.
[0009] In one embodiment, the verification of the device public identification carried by the key application request includes: based on the device public identification, performing identification search processing in preset compliant public identifications; if the search is successful, the identification is determined to be compliant; if the search fails, the identification is determined to be non-compliant.
[0010] In one embodiment, before responding to receiving a key application request initiated by the target device end, the method also includes: in response to receiving an identification application request initiated by the production line end, generating an identification pair accordingly, the identification pair including the compliance public identification and the compliance private identification; sending the identification pair to the production line end, so that the production line end enters the identification pair into the corresponding device end to obtain the device public identification and device private identification of the device end.
[0011] In one embodiment, the target key is encrypted and the encrypted target key is sent to the target device, including: encrypting the target key based on a compliant private identifier corresponding to the device public identifier to obtain the encrypted target key; and sending the encrypted target key to the target device.
[0012] In one embodiment, the target key is encrypted based on the compliant private identifier corresponding to the device public identifier to obtain the encrypted target key, including: generating an encryption key based on the compliant private identifier; encrypting the target key according to the encryption key to obtain the encrypted target key.
[0013] In one embodiment, the server side includes a key management center and a cloud platform, and the method includes: the key management center generates the target key based on the device public identifier; the cloud platform encrypts the target key based on the compliant private identifier to obtain the encrypted target key.
[0014] The second aspect of the present application provides a key distribution device, including: a verification module, used to verify the device public identification carried by the key application request in response to receiving a key application request initiated by the target device end; a key generation module, used to determine the target key based on the verification result of the compliance of the device public identification and the device public identification; an encryption transmission module, used to encrypt the target key and send the encrypted target key to the target device end.
[0015] The third aspect of the present application provides a key distribution system, which includes: a key management center and a cloud platform; the key management center, in response to receiving a key application request initiated by a target device, sends the device public identifier carried in the key application request to the cloud platform; the cloud platform verifies the device public identifier and sends the verification result to the key management center; if the key management center receives a verification result indicating that the device public identifier is compliant, a target key is generated based on the device public identifier and sent to the cloud platform; after receiving the target key, the cloud platform encrypts the target key and sends the encrypted target key to the target device.
[0016] A fourth aspect of the present application provides an electronic device, including a memory and a processor, wherein the processor is used to execute program instructions stored in the memory to implement the above-mentioned key distribution method and / or key distribution system.
[0017] A fifth aspect of the present application provides a computer-readable storage medium on which program instructions are stored. When the program instructions are executed by a processor, the above-mentioned key distribution method and / or key distribution system is implemented.
[0018] In the above scheme, in response to a key application request initiated by a target device, the server verifies the device public identification carried in the key application request, and verifies whether the target device is compliant through the device public identification; if a verification result indicating that the device public identification is compliant is obtained, the corresponding target key is determined based on the device public identification; the target key is encrypted and sent to the target device, thereby ensuring security during key transmission. The target device decrypts the encrypted target key to obtain the target key, thereby realizing a secure process of key application and key distribution and transmission.
[0019] It is to be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present application. BRIEF DESCRIPTION OF THE DRAWINGS
[0020] The drawings herein are incorporated into the specification and constitute a part of the specification. These drawings illustrate embodiments consistent with the present application and are used together with the specification to illustrate the technical solution of the present application.
[0021] Figure 1 is a flowchart of an exemplary embodiment of the key distribution method of the present application;
[0022] Figure 2 It is a flowchart of the production phase in the key distribution method of the present application;
[0023] Figure 3 This is an exemplary overall flow chart of the key distribution method of the present application;
[0024] Figure 4 is a block diagram of a key distribution device shown in an exemplary embodiment of the present application;
[0025] Figure 5 It is a structural schematic diagram of an embodiment of the electronic device of the present application;
[0026] Figure 6 It is a structural diagram of an embodiment of a computer-readable storage medium of the present application. DETAILED DESCRIPTION
[0027] The scheme of the embodiment of the present application is described in detail below in conjunction with the drawings of the specification.
[0028] In the following description, for the purpose of explanation rather than limitation, specific details such as specific system structures, interfaces, and technologies are provided to facilitate a thorough understanding of the present application.
[0029] The term "and / or" in this article is only a description of the association relationship of associated objects, indicating that there may be three relationships. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. In addition, the character " / " in this article generally indicates that the objects associated before and after are in an "or" relationship. In addition, "many" in this article means two or more than two. In addition, the term "at least one" in this article means any combination of at least two of any one or more of a plurality of, for example, including at least one of A, B, and C, can mean including any one or more elements selected from the set consisting of A, B, and C.
[0030] See also Figure 1 , Figure 11 is a flowchart of an exemplary embodiment of the key distribution method of the present application. The key distribution method of the present application can be applied to the server side. Specifically, it can include the following steps:
[0031] Step S110, in response to receiving the key application request initiated by the target device, verifying the device public identification carried in the key application request.
[0032] A key application request refers to a request initiated by the target device to the server to apply for a key. After receiving the key application request initiated by the target device, the server generates a key and sends it to the target device, thereby completing the key application, key generation, and key distribution processes between the target device and the server. The relationship between the device and the server can be one-to-one, one-to-many, many-to-one, or many-to-many, which is not limited in this application. For the sake of illustration, this application mainly takes the key application and transmission process between the target device and the server as an example.
[0033] The device public identification refers to some identification information that is in a public state on the target device side, which can be one or multiple. For example, the device's IP address (Internet Protocol Address), MAC address (Media Access Control Address), device serial number, etc., can also be some other identification information pre-entered by the device during the production stage, etc., which are not limited here. For example, the key distribution method of the present application can be based on the SM9 cryptographic algorithm. SM9 is an identification cryptographic standard, and its principle is to generate a key based on the device identification (usually a unique identification of the selected device); in addition, it can also be performed with reference to other identification-based cryptographic algorithms, which are not limited here.
[0034] Exemplarily, the device public identification of the present application may be some identification information pre-entered during the device production stage, for example, AK (Access Key) may be set and AK may be used as the device public identification of the device end; corresponding to AK, SK (Secret Key) may also be set and SK may be used as the device private identification of the device end. Among them, AK and SK should be stored in the device end as a unique identification pair, and the unique identification pair will also be stored in the server accordingly. The device private identification is different from the device public identification. The device private identification cannot be made public, and usually needs to be encrypted and stored inside the device and in the server so that the device end and the server can communicate encrypted. In addition to using SK as a device private identification, some non-public identification information may be preset as a device private identification through other technical means, such as a custom device private identification or a randomly generated device private identification, etc., which will not be elaborated here. For details, please refer to the description of the subsequent embodiments, which will not be elaborated here.
[0035] It should be noted that a cloud platform may be provided in the server side of the present application, and the cloud platform and the target device side communicate and interact, thereby realizing functions including but not limited to key application, data upload and download, or other common business logic functions, which are not described in detail here. For example, the cloud platform can be used to process key application requests initiated by the target device side, which may include but is not limited to verifying the target device side, generating the key required by the target device side, and encrypting and transmitting the key.
[0036] In addition, in addition to the cloud platform, the server side may also be provided with a key management center. The cloud platform and the key management center may be respectively set up on different nodes of different servers and are responsible for processing different business logic functions. For example, in the key distribution method of the present application, the key management center communicates and interacts with the target device side, and is responsible for responding to the key application request of the target device side, generating keys and managing keys, etc.; then the key management center communicates and interacts with the cloud platform, and the cloud platform is responsible for the verification process, key encryption process, etc., which are not limited here.
[0037] Therefore, after the target device initiates a key application request to the server, the server can determine whether the target device is a legal and compliant device relative to the server by verifying the target device's public identification. That is, it can determine whether the server needs to respond to the target device's key application request, generate a key for it and send it to the target device.
[0038] Step S120: determining a target key according to the verification result of compliance of the device public identification and the device public identification.
[0039] In conjunction with the above steps, the server can determine whether the target device that initiates the key application request is a compliant and legal device through the device's public identification, and decide whether to process the key application request from the target device.
[0040] The target key refers to the key generated by the server for the target device after confirming that the device public identification of the target device is a compliant identification.
[0041] Exemplarily, in the present application, the same device identification as the target device side may be stored in advance on the server side (which may include a device public identification and a device private identification). Therefore, in the process of judging the compliance of the device based on the device public identification, the server side can find out whether there is a device public identification same as the target device side in its own internal, and judge whether the target device side is compliant. In addition, the target device side may initiate a device registration request to the server in a certain period of time (the device registration request may carry a device public identification), and after the server passes the device registration request (it may be that the server decides whether to agree to the device registration request based on a preset registration verification rule, or it may be that the server decides whether to agree to the device registration request in response to the operation instructions of relevant technicians, which will not be repeated here), the device public identification of the target device side may be stored in the server, so as to achieve the effect of registering the target device side in the server. Therefore, when the target device side initiates a key application request to the server, the server may refer to the aforementioned example and judge whether the target device side is compliant based on its device public identification.
[0042] Furthermore, when the server verifies that the device public identification of the target device is a compliance identification, the key generation process can be performed based on the preset SM9 algorithm and the device public identification to obtain the target key. The specific calculation process can refer to the calculation process of the SM9 algorithm (which may include but is not limited to bilinear pairing operations, zero-knowledge proofs, and commitment mechanisms, etc.), which will not be repeated here.
[0043] Step S130, encrypt the target key and send the encrypted target key to the target device.
[0044] In conjunction with the above steps, the server has determined the target key based on the device's public identification and the preset key generation algorithm. However, if the server directly sends the generated target key to the target device, it may be intercepted during the key transmission process, causing key leakage; it is also possible that the target device to which the server is sending the key is not a compliant device due to the theft of the device's public identification, which can also cause key leakage.
[0045] Therefore, in this application, before sending the target key to the target device, the server needs to encrypt the target key first, and then send the encrypted target key to the target device, thereby avoiding the key leakage problem.
[0046] Furthermore, the method for the server to encrypt the target key may include but is not limited to encrypting it using the device private identifier mentioned in the above example. Thus, after the server sends the encrypted target key to the target device, the target device can decrypt the encrypted target key according to the device private identifier it has to obtain the target key.
[0047] In addition, in addition to using the device private identifier to encrypt and decrypt the target key, the server and the target device may be pre-set with the same encryption and decryption algorithm (including encryption algorithm and decryption algorithm), and the server may encrypt the target key based on the preset encryption algorithm to obtain the encrypted target key and send it to the target device, which then uses the corresponding decryption algorithm to decrypt the encrypted target key to obtain the target key. Among them, the target device may have entered the same encryption and decryption algorithm as the server during the production stage, or the target device may obtain the same encryption and decryption algorithm as the server after successfully registering with the server, which is not limited here. It should also be noted that there may be one or more encryption and decryption algorithms in the server, and for multiple different device terminals, the server may allocate the same or different encryption and decryption algorithms to different device terminals based on preset encryption and decryption rules (for example, based on the device type of each device terminal, based on the security level of each device terminal, and / or based on the application scenario of each device terminal, etc.).
[0048] It can be seen that in this application, in response to a key application request initiated by a target device, the server side verifies the device public identification carried in the key application request, and verifies whether the target device is compliant through the device public identification; if a verification result indicating compliance of the device public identification is obtained, the corresponding target key is determined based on the device public identification; the target key is encrypted and sent to the target device, thereby ensuring security during key transmission; the target device decrypts the encrypted target key to obtain the target key, thereby realizing a secure process of key application and key distribution and transmission.
[0049] Based on the above embodiments, the present embodiment of the present application describes the steps of determining the target key based on the verification result of the compliance of the device public identification and the device public identification. Specifically, the method of this embodiment includes the following steps:
[0050] If the verification result of the device's public identification indicates that the identification is compliant, random data is generated and sent to the target device, so that the target device determines the information to be authenticated based on the random data and the target device's device private identification, and sends the information to be authenticated to the server; in response to receiving the information to be authenticated sent by the target device, it is determined whether the information to be authenticated is correct; if the information to be authenticated is correct, a target key is generated based on the device's public identification.
[0051] In conjunction with the above-mentioned embodiment, if the server-side verification result of the target device's device public identification indicates that the identification is compliant, the server can generate the corresponding target key based on the device public identification. However, since the device public identification is in a public state, other electronic devices can also obtain device public identifications that do not belong to themselves through certain technical means, which is equivalent to explaining that the device public identification included when the target device initiates a key application request is not necessarily the real device identification of the target device. Therefore, the security of verifying the target device based on the device public identification is still slightly lacking.
[0052] In this regard, in this embodiment, after the server verifies that the public identification of the device is compliant, there is a further authentication process. Exemplarily, the server can generate random data as one of the verification elements. The random data can be a random number temporarily generated by the server, which can be destroyed after the random data is used up; or it can be a long-term random number generated, which is not destroyed after the random data is used up, which is not limited here. In addition, in addition to the random data generated by the server as a verification element, the specified data pre-stored in the server can also be used as a verification element, but the security of random data will be better than that of specified data to a certain extent.
[0053] Further, according to the above-mentioned embodiment, for a compliant target device end, its device public identification and device private identification should correspond, and this identification pair is not only stored in the target device end, but also stored in the server. Therefore, the device private identification can be used as one of the other verification elements. The server can send random data to the target device end, and the target device end uses the received random data and its device private identification as data input, and processes the data through a preset algorithm to obtain the information to be authenticated of the target device end. Among them, the preset algorithm can refer to the common encryption algorithm calculation process (such as symmetric encryption, asymmetric encryption, hash algorithm encryption, etc.), and can also be data splicing processing of random data and device private identification (for example, splicing random data and device private identification), data insertion processing (for example, inserting random data into device private identification), data operation processing (for example, based on random data and device private identification, including but not limited to addition, subtraction, multiplication and division, etc.). The target device end of the present application can refer to one or more of the above-mentioned processing methods to process the received random data and its device private identification to obtain the information to be authenticated of the target device end. Then the target device end sends its information to be authenticated to the server end.
[0054] After receiving the information to be authenticated sent by the target device, the server determines whether the information to be authenticated is correct. If the information to be authenticated is correct, the server can generate the target key according to the device public identifier; if the information to be authenticated is wrong, the server will suspend or stop processing the key application request of the target device.
[0055] Among them, there are many ways for the server to determine whether the information to be authenticated is correct, which is not limited in this application. For example, one method can be that the server searches for the device private identifier corresponding to the device public identifier in the server local storage or external storage based on the device public identifier of the target device when initiating the key application request, and then uses the previously generated random data and the device private identifier to perform the same data processing process as the target device in the above example to obtain authentication information, and compares the authentication information with the information to be authenticated sent by the target device to determine whether the information to be authenticated is correct.
[0056] The second method is that the server performs data restoration processing on the information to be authenticated based on the random data or the device private identifier corresponding to the device public identifier in the key application request, and obtains the device private identifier and / or random data sent by the target device. The restoration process refers to the reverse process of the data processing process on the target device in the aforementioned example. For example: 1. The target device performs an addition calculation on the random data and the device private identifier to obtain the information to be authenticated, and the server performs a subtraction calculation on the device private identifier based on the random data or local search; 2. If the target device inserts the random data into the device private identifier to obtain the information to be authenticated, the server separates the random data and the device private identifier from the information to be authenticated according to the insertion position of the random data.
[0057] Among them, the data processing process on the target device side and the data restoration process on the server side can be pre-set between the two, or determined during the communication process between the target device side and the server side, which is not limited here. For example, the target device side inserts random data into the specified position of the device private identifier to obtain the information to be authenticated, and the server side can extract data from the information to be authenticated based on the pre-set specified position; or the target device side inserts random data into the device private identifier to obtain the information to be authenticated, and sends the index information of the insertion position to the server, so that the server can extract data from the information to be authenticated based on the received index information. Among them, the index information can be processed with certain data encryption, or it can be processed without data encryption, which is not limited here. Then the server can search for the device private identifier corresponding to the public identifier of the target device side device from the local or external storage of the server, compare the found device private identifier with the restored device private identifier, and / or compare the random data sent by the server with the restored random data, thereby judging whether the information to be authenticated is correct.
[0058] Based on the above embodiments, the embodiment of the present application describes the steps of determining whether the information to be authenticated is correct in response to receiving the information to be authenticated sent by the target device. Specifically, the method of this embodiment includes the following steps:
[0059] The preset compliant private identifier is searched based on the device public identifier; the authentication information is determined based on the random data and the compliant private identifier; if the information to be authenticated matches the authentication information, the information to be authenticated is determined to be correct; if the information to be authenticated does not match the authentication information, the information to be authenticated is determined to be incorrect.
[0060] Among them, the compliant private identifier refers to the device private identifier pre-stored on the server side, which is used to indicate that the target device side with the device private identifier is compliant. Similarly, if the device public identifier of the target device side is also pre-stored on the server side, then the device public identifier is also compliant, and it can also be called a compliant public identifier.
[0061] In combination with the above-mentioned embodiment, in this embodiment, it is explained that the server can determine the authentication information based on the generated random data and the compliant private identifier found based on the corresponding device public identifier, and judge whether the information to be authenticated sent by the target client is correct through the authentication information.
[0062] Exemplarily, the data processing method by which the server uses random data and the found compliant private identifier to determine the authentication information should be consistent with the data processing method by which the target client uses random data and its device private identifier to determine the information to be authenticated. Specifically, it may be preset on the target device side during the production stage, or configured based on communication interaction between the target client and the server side in a subsequent process. This is not limited here, and please refer to the description of the aforementioned embodiment for details.
[0063] Furthermore, in this embodiment, the server matches the information to be authenticated sent by the target device with the authentication information generated by itself, which may include but is not limited to one or more of numerical matching, feature matching, length matching, etc. of the authentication information and the information to be authenticated, which are not limited here. If the authentication information generated by the server matches the information to be authenticated generated by the target device, it is determined that the information to be authenticated is correct, and the target device has completely passed the verification of the server, that is, the server can process the key application request of the target device and generate a target key for it. If the information to be authenticated does not match the authentication information, it is determined that the information to be authenticated is wrong, and the server suspends or stops processing the key application request.
[0064] Based on the above embodiment, the present embodiment of the present application describes the steps of verifying the public identification of the device carried in the key application request. Specifically, the method of this embodiment includes the following steps:
[0065] Based on the device's public identification, an identification search is performed in the preset compliant public identification; if the search is successful, the identification is determined to be compliant; if the search fails, the identification is determined to be non-compliant.
[0066] In conjunction with the above-mentioned embodiment, the server side will search for identification information identical to the device public identification in the pre-stored compliance public identification. If the search is successful (existence), the device public identification is determined to be compliant; otherwise, if the search fails (does not exist), the device public identification is determined to be non-compliant, and the key application request is suspended or stopped.
[0067] Based on the above embodiment, the embodiment of the present application describes the steps before responding to the key application request initiated by the target device. Specifically, the method of this embodiment includes the following steps:
[0068] In response to receiving an identification application request initiated by the production line end, a corresponding identification pair is generated, and the identification pair includes a compliant public identification and a compliant private identification; the identification pair is sent to the production line end, so that the production line end enters the identification pair into the corresponding device end to obtain the device public identification and device private identification of the device end.
[0069] In conjunction with the above embodiments, in the specific application scenario of the present application, the device identification and other information may be entered into the corresponding device end during the production stage. Therefore, when the server end receives the key application request from the device end, it can refer to the method provided in the above embodiments to verify the device end, generate keys, and encrypt and transmit keys.
[0070] For example, reference may be made to Figure 2 As shown, Figure 2 This is a flow chart of the production phase in the key distribution method of this application. Among them, the production line end (production line tool) is responsible for the development and production of the device end, and there is a direct communication connection between the production line end and the device end; the production line end can be connected to the server end (such as the IoT cloud platform), and there can also be a communication connection between the production line end and the server end.
[0071] In the production stage, the production line needs to initiate an identification application request to the server to apply for the identification information of the current device from the server (which may include corresponding device public identification and device private identification, such as the unique identification pair AK and SK in the aforementioned embodiment). Then the server will generate an identification pair and send the identification pair to the production line, so that the production line can burn the received identification pair into the corresponding device, and the device can save the received identification pair (it can be conventional or encrypted. If the device is equipped with an encryption chip with a secure storage function, the identification pair can be stored in the encryption chip first, which is not limited here), and can also return the burning result to the production line to determine whether the burning is successful. It should be noted that after generating the identification pair, the server will also save the identification pair, that is, obtain a compliant identification pair (including a compliant public identification and a compliant private identification); and after the device saves the identification pair, it will obtain a device identification pair (including a device public identification and a device private identification). Therefore, for compliant device ends, the server can find the same identification information; for non-compliant device ends, the server cannot find the same identification information.
[0072] It should also be noted that in the process of generating identification pairs on the server, a one-machine-one-secret certificate mechanism can be used to generate unique identification pairs for different device ends. The core of the one-machine-one-secret certificate is AK and SK. In the production process, it is necessary to ensure that the AK and SK in the one-machine-one-secret certificate of each device are unique and corresponding. The AK of the device can be made public, while the SK needs to be encrypted and stored inside the device. It can also be stored in the internal database of the device manufacturer after irreversible conversion processing. The storage method of the identification is not limited here.
[0073] Based on the above embodiments, the embodiment of the present application exemplarily illustrates the steps of encrypting the target key and sending the encrypted target key to the target device. Specifically, the method of this embodiment includes the following steps:
[0074] The target key is encrypted based on the compliant private identifier corresponding to the device public identifier to obtain the encrypted target key; the encrypted target key is sent to the target device end.
[0075] In conjunction with the foregoing embodiments, when the server sends the target key to the target device, an encrypted transmission method can be used. Specifically, according to the foregoing embodiments, for the target device to be verified as compliant, the target device and the server should have the same private identifier, so the server can use the compliant private identifier corresponding to the device public identifier to encrypt the target key, obtain the encrypted target key, and then send the encrypted target key to the target device. In essence, the compliant private identifier determined by the server based on the device public identifier and the device private identifier of the target device should be the same. As a result, the target device can decrypt the encrypted target key through its device private identifier to obtain the target key.
[0076] Based on the above embodiment, the embodiment of the present application describes the steps of encrypting the target key based on the compliant private identifier corresponding to the device public identifier to obtain the encrypted target key. Specifically, the method of this embodiment includes the following steps:
[0077] An encryption key is generated based on the compliant private identifier; the target key is encrypted according to the encryption key to obtain the encrypted target key.
[0078] In conjunction with the above-mentioned embodiment, in the process of encrypting the target key based on the compliance private identifier, the server can specifically generate an encryption key based on the compliance private identifier SK according to a preset key derivation algorithm. The key derivation algorithm can refer to the prior art and is not limited here. Then, the target key is encrypted based on the encryption key, thereby obtaining the encrypted target key.
[0079] On the basis of the above embodiments, the embodiments of the present application also need to explain that the server side of the present application may include at least a key management center and a cloud platform. Specifically, when the method of this embodiment is executed in each platform of the server side, it may include the following steps:
[0080] The key management center generates a target key based on the device's public identifier; the cloud platform encrypts the target key based on the compliant private identifier to obtain the encrypted target key.
[0081] In conjunction with the above-mentioned embodiments, in the key distribution method of the present application, the steps of device verification, key generation, key encryption transmission, etc. are mainly implemented by the server side. In the server side of the present application, these steps can be handed over to the cloud platform node for execution. The cloud platform node, such as the Internet of Things cloud platform, is mainly responsible for communicating and interacting with various Internet of Things devices. In addition, in order to improve the overall security performance, at least a key management center node can be set in the server, and the above steps can be implemented by communication and interaction between the key management center and the cloud platform.
[0082] For reference Figure 3 , Figure 3It is an exemplary overall process diagram of the key distribution method of the present application, which shows the main execution process of the key distribution method of the present application when there are a key management center and a cloud platform on the server side. Among them, the key management center is responsible for receiving the key application request initiated by the target device side, and initiating a device verification request to the cloud platform based on the device public identification carried by the key application request. After the cloud platform verifies that the device public identification is compliant, it generates random data and returns it to the key management center. The key management center sends the received random data to the target device side, so that the target device side calculates based on the received random data and its own device private identification, obtains the information to be authenticated and sends it to the key management center. The key management center sends the received information to be authenticated to the cloud platform, and the cloud platform uses the same calculation method as the target device side to calculate based on the random data and the compliant private identification found based on the device public identification to obtain the authentication information, and then matches the authentication information with the information to be authenticated, obtains the matching result and sends it to the key management center. The key management center decides whether to generate a target key (such as an SM9 key) for the target device based on the matching result. If the authentication information matches the information to be authenticated, the key management center generates the target key based on the device public identifier of the target device and the preset key generation algorithm (such as the SM9 algorithm). The key management center then sends the target key to the cloud platform and requests the cloud platform to encrypt the target key. After receiving the key encryption request from the key management center, the cloud platform generates an encryption key based on the SK of the target device and the preset key derivation algorithm, and then uses the encryption key to encrypt the target key to obtain the encrypted target key, and then returns the encrypted target key to the key management center. After receiving the encrypted target key, the key management center issues the encrypted target key to the target device (the specific key issuance method can refer to the prior art and will not be repeated here). After receiving the encrypted target key, the target device can use the same key derivation algorithm as the cloud platform and its own device private identifier to derive the key, and obtain the decryption key that is the same as the encryption key in the server. Based on the decryption key, the encrypted target key can be decrypted to obtain the target key in plain text.
[0083] It should be further explained that the execution subject of the key distribution method may be a key distribution device, for example, the key distribution method may be executed by a terminal device or a server or other processing device, wherein the terminal device may be a user equipment (UE), a computer, a mobile device, a user terminal, a terminal, a cellular phone, a cordless phone, a personal digital assistant (PDA), a handheld device, a computing device, a vehicle-mounted device, a wearable device, etc. In some possible implementations, the key distribution method may be implemented by a processor calling a computer-readable instruction stored in a memory.
[0084] Figure 4 FIG. 1 is a block diagram of a key distribution device shown in an exemplary embodiment of the present application. Figure 4 As shown, the exemplary key distribution device 400 includes: a verification module 410, a key generation module 420 and an encryption transmission module 430. Specifically:
[0085] The verification module 410 is used to verify the device public identification carried in the key application request in response to receiving the key application request initiated by the target device.
[0086] The key generation module 420 is used to determine the target key according to the verification result of the compliance of the device public identification and the device public identification.
[0087] The encryption transmission module 430 is used to encrypt the target key and send the encrypted target key to the target device.
[0088] In this exemplary key distribution device, the server side responds to a key application request initiated by a target device side by verifying the device public identification carried in the key application request, and verifies whether the target device side is compliant through the device public identification; if a verification result indicating that the device public identification is compliant is obtained, the corresponding target key is determined based on the device public identification; the target key is encrypted and sent to the target device side after encryption, thereby ensuring security during the key transmission process; the target device side decrypts the encrypted target key to obtain the target key, thereby realizing the process of secure key application and key distribution and transmission.
[0089] It should be noted that the device provided in the above embodiment and the method provided in the above embodiment belong to the same concept, wherein the specific manner in which each module and unit performs the operation has been described in detail in the method embodiment, and will not be repeated here. In practical applications, the device provided in the above embodiment can distribute the above functions to different functional modules as needed, that is, divide the internal structure of the device into different functional modules to complete all or part of the functions described above, and this is not limited here.
[0090] Among them, the functions of each module can be found in the key distribution method embodiment, and will not be repeated here.
[0091] It should also be noted that the present application also provides a key distribution system, which includes at least a key management center and a cloud platform; during the operation of the key distribution method of the present application, the key management center responds to receiving a key application request initiated by the target device end, and sends the device public identification carried in the key application request to the cloud platform; the cloud platform verifies the device public identification and sends the verification result to the key management center; if the key management center receives a verification result indicating that the device public identification is compliant, it generates a target key based on the device public identification and sends it to the cloud platform; after receiving the target key, the cloud platform encrypts the target key and sends the encrypted target key to the target device end.
[0092] Furthermore, the key distribution system of the present application may also include a production line end, which is responsible for applying for a device identifier for the device and burning it during the production stage of the device. The specific implementation process and related instructions can be similarly referred to the example description of the key distribution method in the aforementioned embodiment, and can also be referred to the present application. Figure 2 and Figure 3 , which will not be elaborated here.
[0093] In this exemplary key distribution system, the production line can initiate an identification application request to the server to apply for the identification information of the current device from the server. The server will then generate an identification pair and send the identification pair to the production line, so that the production line can burn the received identification pair into the corresponding device, and the device can save the received identification pair. In response to the key application request initiated by the target device, the server verifies the device public identification carried by the key application request, and verifies whether the target device is compliant through the device public identification; if a verification result indicating compliance of the device public identification is obtained, the corresponding target key is determined based on the device public identification; the target key is encrypted and sent to the target device, thereby ensuring security during the key transmission process. The target device decrypts the encrypted target key to obtain the target key, thereby realizing the process of secure key application and key distribution transmission.
[0094] See also Figure 5 , Figure 5 1 is a schematic diagram of the structure of an embodiment of an electronic device of the present application. The electronic device 100 includes a memory 101 and a processor 102, and the processor 102 is used to execute program instructions stored in the memory 101 to implement the steps in any of the above-mentioned key distribution method embodiments. In a specific implementation scenario, the electronic device 100 may include but is not limited to: a microcomputer, a server, and in addition, the electronic device 100 may also include a mobile device such as a laptop computer and a tablet computer, which is not limited here.
[0095] Specifically, the processor 102 is used to control itself and the memory 101 to implement the steps in any of the above-mentioned key distribution method embodiments. The processor 102 can also be called a CPU (Central Processing Unit). The processor 102 may be an integrated circuit chip with signal processing capabilities. The processor 102 can also be a general-purpose processor, a digital signal processor (Digital Signal Processor, DSP), an application-specific integrated circuit (Application Specific Integrated Circuit, ASIC), a field programmable gate array (Field-Programmable Gate Array, FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor, etc. In addition, the processor 102 can be implemented by an integrated circuit chip.
[0096] In this exemplary electronic device, in response to a key application request initiated by a target device, the server verifies the device public identification carried in the key application request, and verifies whether the target device is compliant through the device public identification; if a verification result indicating that the device public identification is compliant is obtained, the corresponding target key is determined based on the device public identification; the target key is encrypted and sent to the target device, thereby ensuring security during key transmission; the target device decrypts the encrypted target key to obtain the target key, thereby realizing a secure process of key application and key distribution and transmission.
[0097] See also Figure 6 , Figure 6 The computer-readable storage medium 110 stores program instructions 111 that can be executed by a processor, and the program instructions 111 are used to implement the steps in any of the above-mentioned key distribution method embodiments.
[0098] In this exemplary storage medium, by running the program instructions in the storage medium, the server responds to the key application request initiated by the target device end, verifies the device public identification carried in the key application request, and verifies whether the target device end is compliant through the device public identification; if a verification result indicating that the device public identification is compliant is obtained, the corresponding target key is determined based on the device public identification; the target key is encrypted and sent to the target device end after encryption, thereby ensuring security during the key transmission process; the target device end decrypts the encrypted target key to obtain the target key, thereby realizing the process of secure key application and key distribution and transmission.
[0099] In some embodiments, the functions or modules included in the device provided by the embodiments of the present disclosure can be used to execute the method described in the above method embodiments. The specific implementation can refer to the description of the above method embodiments, and for the sake of brevity, it will not be repeated here.
[0100] The above description of various embodiments tends to emphasize the differences between the various embodiments. The same or similar aspects can be referenced to each other, and for the sake of brevity, they will not be repeated herein.
[0101] In the several embodiments provided in the present application, it should be understood that the disclosed methods and devices can be implemented in other ways. For example, the device implementation described above is only schematic. For example, the division of modules or units is only a logical function division. There may be other division methods in actual implementation, such as units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, and the indirect coupling or communication connection of devices or units can be electrical, mechanical or other forms.
[0102] In addition, each functional unit in each embodiment of the present application can be integrated into a processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of a software functional unit. If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including several instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) or a processor (processor) to perform all or part of the steps of each implementation method of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk and other media that can store program code.
Claims
1. A key distribution method, characterized in that: The method is applied to the server side, and the method comprises: In response to receiving a key application request initiated by a target device, verifying a device public identifier carried in the key application request; Determine a target key according to a verification result of compliance of the device public identification and the device public identification; The target key is encrypted and sent to the target device.
2. The method according to claim 1, characterized in that The determining the target key according to the verification result of compliance of the device public identification and the device public identification includes: If the verification result of the device public identification indicates that the identification is compliant, random data is generated and sent to the target device end, so that the target device end determines the information to be authenticated based on the random data and the device private identification of the target device end, and sends the information to be authenticated to the server end; In response to receiving the information to be authenticated sent by the target device, determining whether the information to be authenticated is correct; If the information to be authenticated is correct, the target key is generated according to the public identification of the device.
3. The method according to claim 2, characterized in that The step of determining whether the information to be authenticated is correct in response to receiving the information to be authenticated sent by the target device includes: Searching for a preset compliance private identifier based on the public identifier of the device; determining authentication information based on the random data and the compliance private identifier; If the information to be authenticated matches the authentication information, then it is determined that the information to be authenticated is correct; If the information to be authenticated does not match the authentication information, it is determined that the information to be authenticated is wrong.
4. The method according to claim 1, characterized in that The verifying the public identification of the device carried in the key application request includes: Based on the public identification of the device, perform identification search processing in preset compliant public identifications; If the search is successful, the identification is determined to be compliant; If the search fails, the identifier is deemed noncompliant.
5. The method according to claim 4, characterized in that Before the responding to receiving the key application request initiated by the target device, the method further includes: In response to receiving an identification application request initiated by the production line, generating an identification pair, the identification pair including the compliance public identification and the compliance private identification; The identification pair is sent to the production line end, so that the production line end enters the identification pair into the corresponding device end to obtain the device public identification and the device private identification of the device end.
6. The method according to claim 1, characterized in that The encrypting the target key and sending the encrypted target key to the target device end includes: Encrypting the target key based on the compliant private identifier corresponding to the device public identifier to obtain the encrypted target key; The encrypted target key is sent to the target device.
7. The method according to claim 6, characterized in that The encrypting the target key based on the compliant private identifier corresponding to the device public identifier to obtain the encrypted target key includes: generating an encryption key based on the compliant private identifier; The target key is encrypted according to the encryption key to obtain the encrypted target key.
8. The method according to claim 6, characterized in that The server side includes a key management center and a cloud platform, and the method includes: The key management center generates the target key based on the device public identifier; The cloud platform encrypts the target key based on the compliant private identifier to obtain the encrypted target key.
9. An electronic device, characterized in that: The method comprises a memory and a processor, wherein the processor is used to execute program instructions stored in the memory to implement the method according to any one of claims 1 to 8.
10. A computer-readable storage medium having program instructions stored thereon, characterized in that: When the program instructions are executed by a processor, the method according to any one of claims 1 to 8 is implemented.