Key management method and device, storage medium and chip

Abstract

The invention relates to a secret key management method and device, a storage medium and a chip, and relates to the technical field of communication encryption, and the secret key management method comprises the steps: determining a first candidate secret key conforming to a first target equipment trust level from original secret keys under the condition that home terminal equipment has the original secret keys for communicating with opposite terminal equipment, the method comprises the following steps: acquiring a first candidate key, authenticating the first candidate key, and under the condition that the first candidate key passes authentication, determining the first candidate key as a target key for communication between home terminal equipment and opposite terminal equipment, the first target equipment trust level being the current equipment trust level of the home terminal equipment and the opposite terminal equipment, and the first target equipment trust level being the current equipment trust level of the opposite terminal equipment; therefore, it can be ensured that the selected target key conforms to the current equipment trust level, and under the condition that the first candidate key passes authentication, it is determined that the first candidate key can be directly used by both parties, so that the communication security is ensured under the condition that the communication response speed is accelerated.

Description

Technical Field

[0001] The present disclosure relates to the field of communication encryption technology, and in particular to a key management method, device, storage medium and chip. Background Art

[0002] In the related art, during the communication process between the local device and the opposite device, if the local device has the original key for communicating with the opposite device, the key indexes corresponding to all the existing original keys will be sent to the opposite device, and the opposite device will select one from them as the target key for communication between the two parties. Summary of the invention

[0003] In order to overcome the communication security problems existing in the related art, the present disclosure provides a key management method, apparatus, storage medium and chip, wherein different device trust levels correspond to different levels of keys, and when there is an original key for communicating with a peer device on a local device, a first candidate key that meets the trust level of a first target device is determined from the original key, and the first candidate key is authenticated, and when the first candidate key passes the authentication, the first candidate key is determined as the target key for communication between the local device and the peer device, wherein the trust level of the first target device is the current device trust level of the local device and the peer device, thereby ensuring that the selected target key meets the current device trust level and can be used directly by both parties, thereby ensuring communication security while accelerating the communication response speed.

[0004] According to a first aspect of an embodiment of the present disclosure, there is provided a key management method, including:

[0005] In response to a communication request with a peer device, if the local device has an original key for communicating with the peer device, and if the original key contains a first candidate key that meets the trust level of a first target device, then authenticating the first candidate key, where the trust level of the first target device is the current device trust level of the local device and the peer device;

[0006] In a case where the first candidate key passes the authentication, the first candidate key is determined as a target key for communication between the local device and the opposite device.

[0007] Optionally, the first candidate key is a symmetric key;

[0008] The authenticating the first candidate key includes:

[0009] Sending authentication information to the peer device, the authentication information including a target key version number corresponding to the first candidate key, the target key version number being used by the peer device to search for the first candidate key;

[0010] When it is confirmed that the opposite device has found the first candidate key, it is determined that the first candidate key passes the authentication.

[0011] Optionally, the authentication information further includes first encrypted authentication data, where the first encrypted authentication data is obtained by encrypting the first original authentication data using the first candidate key;

[0012] When it is confirmed that the opposite device has found the first candidate key, before determining that the first candidate key has passed the authentication, the method further includes:

[0013] Acquire decrypted authentication data, where the decrypted authentication data is data obtained by the peer device decrypting the first encrypted authentication data using the found second candidate key;

[0014] In a case where the decrypted authentication data matches the first original authentication data, it is confirmed that the second candidate key found by the opposite device is the first candidate key.

[0015] Optionally, when confirming that the opposite device has found the first candidate key, before determining that the first candidate key has passed authentication, the method further includes:

[0016] Receiving second encrypted authentication data, where the second encrypted authentication data is obtained by encrypting the second original authentication data by the peer device using the found third candidate key;

[0017] When the second encrypted authentication data is successfully decrypted using the first candidate key, it is confirmed that the third candidate key found by the opposite device is the first candidate key.

[0018] Optionally, the method further comprises:

[0019] In the case that the local device does not have an original key for communicating with the opposite device, or in the case that the original key does not contain a first candidate key that meets the trust level of the first target device, the local device authenticates the opposite device;

[0020] When the authentication is successful, the key generated by the successful authentication is determined as the target key.

[0021] Optionally, the local device and the opposite device perform authentication, including:

[0022] Determine a device trust level between the local device and the opposite device;

[0023] Determining a second target device trust level according to a specified trust level and a device trust level between the local device and the opposite device;

[0024] The local device and the opposite device perform authentication according to the authentication method corresponding to the trust level of the second target device.

[0025] Optionally, determining the second target device trust level according to the specified trust level and the device trust level existing between the local device and the opposite device includes:

[0026] The device trust level that matches the specified trust level and has the highest level among the device trust levels existing between the local device and the opposite device is determined as the second target device trust level.

[0027] Optionally, the method further comprises:

[0028] If the first candidate key fails to pass authentication, the local device re-authenticates with the peer device;

[0029] When the authentication is successful, the key generated by the successful authentication is determined as the target key.

[0030] Optionally, when the authentication is successful, the method further includes:

[0031] A corresponding key version number is generated for the key generated by successful authentication, and the key version number includes a key index and a key sequence number. The key sequence number of the key generated later is greater than the key sequence number of the key generated earlier. The first candidate key is the key with the largest key sequence number among the keys that meet the trust level of the first target device.

[0032] According to a second aspect of an embodiment of the present disclosure, there is provided a key management device, including:

[0033] A first determination module is configured to, in response to a communication request with a peer device, authenticate the first candidate key if there is an original key for communicating with the peer device in the local device and if the original key contains a first candidate key that meets the trust level of a first target device, wherein the trust level of the first target device is a current device trust level between the local device and the peer device;

[0034] The second determination module is configured to determine the first candidate key as a target key for communication between the local device and the opposite device if the first candidate key passes the authentication.

[0035] According to a third aspect of an embodiment of the present disclosure, there is provided a key management device, including:

[0036] processor;

[0037] a memory for storing processor-executable instructions;

[0038] The processor is configured to implement the steps of the key management method provided in the first aspect of the present disclosure when executing.

[0039] According to a fourth aspect of an embodiment of the present disclosure, a computer-readable storage medium is provided, on which computer program instructions are stored. When the program instructions are executed by a processor, the steps of the key management method provided in the first aspect of the present disclosure are implemented.

[0040] According to a fifth aspect of an embodiment of the present disclosure, a chip is provided, including a processor and an interface; the processor is used to read instructions to execute the key management method provided by the first aspect of the present disclosure.

[0041] The technical solution provided by the embodiments of the present disclosure may have the following beneficial effects:

[0042] Different levels of keys correspond to different device trust levels. When the local device has an original key for communicating with the opposite device, a first candidate key that meets the first target device trust level is determined from the original key, and the first candidate key is authenticated. When the first candidate key passes the authentication, the first candidate key is determined as the target key for communication between the local device and the opposite device, wherein the first target device trust level is the current device trust level of the local device and the opposite device, thereby ensuring that the selected target key meets the current device trust level. When the first candidate key passes the authentication, it is determined that the first candidate key can be directly used by both parties, thereby ensuring communication security while accelerating the communication response speed.

[0043] 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 disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present disclosure and, together with the description, serve to explain the principles of the present disclosure.

[0045] Figure 1 The diagram is a schematic diagram of a communication scenario according to an exemplary embodiment.

[0046] Figure 2 The present invention is a flowchart of a key management method according to an exemplary embodiment.

[0047] Figure 3The figure is a flowchart of a method for authenticating a first candidate key according to an exemplary embodiment.

[0048] Figure 4 The present invention is a flowchart of a method for authenticating a local device and a peer device according to an exemplary embodiment.

[0049] Figure 5 The figure is a block diagram of a key management device according to an exemplary embodiment.

[0050] Figure 6 It is a block diagram of yet another key management device according to an exemplary embodiment. DETAILED DESCRIPTION

[0051] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present disclosure. Instead, they are merely examples of devices and methods consistent with some aspects of the present disclosure as detailed in the appended claims.

[0052] It should be noted that all actions of acquiring signals, information or data in the present disclosure are carried out in compliance with the relevant data protection laws and policies of the country where the device is located and with the authorization given by the owner of the corresponding device.

[0053] In the process of communication between devices, both parties are usually required to authenticate first. During the authentication process, the two parties negotiate the key and each saves the negotiated key after the authentication is completed so that the negotiated key can be used to encrypt the data in the communication during the communication process, thereby improving the security of the communication.

[0054] In the related art, during the communication process between a local device and a peer device, if the local device has an original key for communicating with the peer device, that is, the local device stores a key negotiated with the peer device, then the key indexes corresponding to all existing original keys will be sent to the peer device, and the peer device will select one from them as the target key for communication between the two parties. However, the process of selecting the target key is relatively cumbersome, resulting in a longer communication response time and the selected target key may be a relatively simple key, which does not meet the confidentiality requirements of the current communication transmission between devices, resulting in low security for communication between devices.

[0055] In response to the communication security problems existing in the related technologies, the present disclosure provides a key management method, apparatus, storage medium and chip, wherein different levels of keys correspond to different device trust levels, and when a local device has an original key for communicating with a peer device, a first candidate key that meets the trust level of a first target device is determined from the original key, and the first candidate key is authenticated, and when the first candidate key passes the authentication, the first candidate key is determined as the target key for communication between the local device and the peer device, wherein the trust level of the first target device is the current device trust level of the local device and the peer device, thereby ensuring that the selected target key meets the current device trust level, and when the first candidate key passes the authentication, it is determined that the first candidate key can be directly used by both parties, thereby ensuring communication security while accelerating the communication response speed.

[0056] Figure 1 is a schematic diagram showing a communication scenario according to an exemplary embodiment. Figure 2 is a flowchart of a key management method according to an exemplary embodiment. Figure 1 and Figure 2 As shown, the method can be used in a terminal device and includes the following steps.

[0057] In step S201, in response to a communication request with a peer device, when the local device has an original key for communicating with the peer device, if the original key contains a first candidate key that meets the trust level of the first target device, the first candidate key is authenticated, and the trust level of the first target device is the current device trust level between the local device and the peer device.

[0058] In this embodiment, the local device may be a terminal device that initiates communication, and the method may be applied to the local device. The opposite device may be a target device that initiates communication with the local device. Figure 1 As shown, if the user wants to transfer the target data to the computer via a mobile phone, the mobile phone is the local device and the computer is the peer device. For different devices or different communication scenarios, there may be different device trust levels between the local device and the peer device, and the number of levels can be set according to actual conditions. For example, it can be divided into three device trust levels, namely the first device trust level, the second device trust level and the third device trust level, among which the first device trust level may be the same account device, the second device trust level may be a point-to-point device, and the third device trust level may be an untrusted device. For different device trust levels, different levels of authentication methods can be used in the process of authentication of both devices, thereby generating different levels of keys.

[0059] When a user uses a local device, if he wants to communicate with a peer device through the local device, such as transmitting data, he can issue a communication request to the local device through the operation of the local device. In response to the communication request with the peer device, the local device can first determine whether the local device has an original key for communicating with the peer device. The original key can be a key stored in the local device and negotiated with the peer device. If the local device has an original key for communicating with the peer device, it will then search whether there is a first candidate key that meets the trust level of the first target device in the original key. If there is a first candidate key that meets the trust level of the first target device in the original key, the first candidate key can be authenticated so as to seek reuse of the first candidate key and avoid re-authentication with the peer device. Among them, the trust level of the first target device is the current device trust level of the local device and the peer device, so that it can be ensured that the selected target key meets the current device trust level, that is, it meets the encryption requirements of the current communication between the local device and the peer device, and ensures communication security.

[0060] In step S202, when the first candidate key passes the authentication, the first candidate key is determined as the target key for communication between the local device and the opposite device.

[0061] In this embodiment, if the first candidate key passes the authentication, the first candidate key can be reused in both the local device and the opposite device, and the first candidate key can be determined as the target key for communication between the local device and the opposite device. During the communication between the local device and the opposite device, the target key can be used for data encryption and decryption.

[0062] In a possible implementation, a method for determining the current device trust level of the local device and the opposite device may be: obtaining basic feature information of the local device and the opposite device, and determining the connection relationship between the local device and the opposite device based on the basic feature, thereby determining the current device trust level of the local device and the opposite device.

[0063] Figure 3 is a flowchart of a method for authenticating a first candidate key according to an exemplary embodiment. Figure 3 As shown, in a possible implementation, the first candidate key is a symmetric key, that is, after the local device and the peer device complete authentication, the keys stored at both ends are the same. Authentication of the first candidate key may include the following steps:

[0064] In step S301, authentication information is sent to a peer device, the authentication information including a target key version number corresponding to a first candidate key, the target key version number being used by the peer device to search for the first candidate key.

[0065] In this embodiment, whether the first candidate key can pass the authentication can be verified by sending a target key version number corresponding to the first candidate key to the opposite device. The local device can generate authentication information based on the target key version number corresponding to the first candidate key, and send the authentication information to the opposite device. After receiving the authentication information, the opposite device can respond to the authentication information and search for the locally stored key according to the target key version number in the authentication information, in the expectation of finding the first candidate key corresponding to the target key version number.

[0066] In step S302, when it is confirmed that the opposite device has found the first candidate key, it is determined that the first candidate key has passed the authentication.

[0067] In this embodiment, if it is confirmed that the opposite device has found the first candidate key, it proves that the opposite device also stores the first candidate key, and then it is determined that the first candidate key has passed the authentication, and the local device and the opposite device can use the first candidate key to encrypt and decrypt communication data.

[0068] In a possible implementation, the authentication information further includes first encrypted authentication data, where the first encrypted authentication data is obtained by encrypting the first original authentication data using a first candidate key.

[0069] When it is confirmed that the opposite device has found the first candidate key, before determining that the first candidate key has passed the authentication, a method for confirming whether the opposite device has found the first candidate key may be: obtaining decrypted authentication data, the decrypted authentication data being data after the opposite device decrypts the first encrypted authentication data using the found second candidate key; when the decrypted authentication data matches the first original authentication data, confirming that the second candidate key found by the opposite device is the first candidate key.

[0070] In this embodiment, the authentication information also includes first encrypted authentication data, which is obtained by encrypting the first original authentication data with the first candidate key, wherein the first original authentication data is an arbitrary piece of data, for example, a pre-set piece of data, or a temporarily generated piece of arbitrary data. After the local device sends the authentication information to the opposite device, the opposite device can respond to the authentication information and search for the key stored locally according to the target key version number in the authentication information after receiving the authentication information. If the key is found, the found key is determined as the second candidate key, and the first encrypted data is decrypted according to the second candidate key to obtain decrypted authentication data. The opposite device returns the obtained decrypted authentication data to the local device. After receiving the decrypted authentication data, the local device matches it with the first original authentication data. If the decrypted authentication data matches the first original authentication data, it is confirmed that the second candidate key found by the opposite device is the first candidate key, that is, the second candidate key found by the opposite device is the same as the first candidate key. It can then be determined that the first candidate key has passed the authentication. If the decrypted authentication data does not match the first original authentication data, it is confirmed that the second candidate key found by the opposite device is different from the first candidate key, and it can be determined that the first candidate key has not passed the authentication.

[0071] If the key corresponding to the target key version number is not found, a search failure message may be returned. After receiving the search failure message, the local device confirms that the first candidate key authentication has failed. Alternatively, if the key corresponding to the target key version number is not found, the first encrypted authentication data is directly returned. After receiving the first encrypted authentication data, the local device determines that it does not match the first original authentication data and confirms that the first candidate key authentication has failed.

[0072] In a possible implementation, when confirming that the peer device has found the first candidate key, before determining that the first candidate key has passed authentication, the method for confirming whether the peer device has found the first candidate key may also include: receiving second encrypted authentication data, where the second encrypted authentication data is obtained by the peer device after encrypting the second original authentication data using the found third candidate key. When the second encrypted authentication data is successfully decrypted using the first candidate key, confirming that the third candidate key found by the peer device is the first candidate key.

[0073] In this embodiment, after the local device sends the authentication information to the peer device, after the peer device receives the authentication information, it can respond to the authentication information and search for the locally stored key according to the target key version number in the authentication information. If the key is found, the found key is determined as the third candidate key, and the second original authentication data is encrypted according to the third candidate key to obtain the second encrypted authentication data, wherein the second original authentication data can be any piece of data. The peer device sends the obtained second encrypted authentication data to the local device. After the local device receives the second encrypted authentication data, it can use the first candidate key to decrypt the second encrypted authentication data. If the decryption is successful, it is confirmed that the third candidate key found by the peer device is the first candidate key, that is, the third candidate key found by the peer device is the same as the first candidate key, and then it can be determined that the first candidate key has passed the authentication. If the decryption is unsuccessful, it is confirmed that the third candidate key found by the peer device is different from the first candidate key, and then it can be determined that the first candidate key has not passed the authentication.

[0074] In a possible implementation, the key management method further includes: when the local device does not have an original key for communicating with the opposite device, or when the original key does not have a first candidate key that meets the trust level of the first target device, the local device authenticates the opposite device. When the authentication is successful, the key generated by the successful authentication is determined as the target key.

[0075] In this embodiment, if the local device does not have the original key for communicating with the opposite device, or the first candidate key that meets the trust level of the first target device does not exist in the original key, there is no key that can be directly used to encrypt and decrypt the communication data between the local device and the opposite device. The local device can authenticate with the opposite device so that after the authentication is successful, a key is generated for encryption and decryption of the communication data between the local device and the opposite device.

[0076] Figure 4 is a flow chart showing a method for authenticating a local device and a peer device according to an exemplary embodiment. Figure 4 As shown, in a possible implementation manner, the authentication between the local device and the opposite device may include the following steps:

[0077] In step S401, the device trust level between the local device and the opposite device is determined.

[0078] In this embodiment, there may be multiple levels of trust between the local device and the peer device. For example, there may be same-account connection, point-to-point connection and untrusted connection at the same time. The business scenarios for same-account connection may be clipboard, the business scenarios for point-to-point connection may be wearable devices and screen projection, and the business scenarios for untrusted connection may be file transfer and MiaoBo, etc.

[0079] In step S402, the second target device trust level is determined according to the designated trust level and the device trust level existing between the local device and the opposite device.

[0080] In this embodiment, the specified trust level can be determined based on the default trust level of the current business function, or it can be a trust level specified by the user. The specified trust level is the security authentication requirement level. For example, if the security authentication requirement is only for the same account, the security authentication requirement level corresponds to the device trust level corresponding to the same account connection. If the security authentication requirement is only trusted, the security authentication requirement level corresponds to the device trust level corresponding to the point-to-point connection.

[0081] The second target device trust level may be determined from the device trust levels existing between the local device and the opposite device based on the specified trust level.

[0082] In step S403, the local device and the opposite device perform authentication according to the authentication method corresponding to the trust level of the second target device.

[0083] In this embodiment, after determining the trust level of the second target device used for authentication between the local device and the opposite device, the authentication method corresponding to the trust level of the second target device can be obtained, and the local device and the opposite device can be authenticated based on the authentication method to ensure the authentication level requirements and improve communication security.

[0084] In a possible implementation, based on the specified trust level and the device trust level existing between the local device and the opposite device, the method for determining the second target device trust level may be: determining the device trust level that matches the specified trust level and has the highest level among the device trust levels existing between the local device and the opposite device as the second target device trust level.

[0085] In this embodiment, the device trust level that matches the specified trust level among the device trust levels existing between the local device and the opposite device can be determined first. Among them, the matching device trust level can be the currently available device trust level among the device trust levels between the local device and the opposite device, that is, the device trust level among the device trust levels between the local device and the opposite device whose level is less than or equal to the current device trust level, and then the highest device trust level among them is determined as the second target device trust level, so that the level of authentication can be improved as much as possible under the premise of using the device trust level that meets the current device connection form, thereby ensuring the security of authentication and being able to generate a key of the corresponding level, wherein the higher the second target device trust level, the higher the level of the corresponding authentication method, and the higher the level of the generated key, so that the security of using its key for communication is higher.

[0086] In a possible implementation, when the first candidate key fails to pass authentication, the local device and the opposite device re-authenticate, and when the authentication succeeds, the key generated by the successful authentication is determined as the target key.

[0087] In this embodiment, if the first candidate key fails to pass the authentication, it is confirmed that the local device and the opposite device cannot communicate using the existing first candidate key, and then re-authentication can be performed to generate a new key as the target key to support communication between the local device and the opposite device. The re-authentication method can be the same as the above-mentioned authentication method between the local device and the opposite device, and reference can be made to the relevant explanation of authentication between the local device and the opposite device.

[0088] In a possible implementation, in order to facilitate the search of the key, a corresponding key version number may be generated for the key generated by the successful authentication, and the key version number may include a key index and a key sequence number, wherein the key index may be used to search for the corresponding key, and the key sequence number may be used to distinguish and select the key. Among them, the key sequence number of the key generated later is greater than the key sequence number of the key generated earlier. For example, each time a key is generated, the key sequence number of the key is the key sequence number of the previous key plus 1. When determining the first candidate key, a set of candidate keys that meet the trust level of the first target device may be determined from the original key. Among them, meeting the trust level of the first target device means matching the level of the key generated by the authentication method corresponding to the trust level of the first target device. Then, the key corresponding to the largest key sequence number is determined as the first candidate key, wherein the key level of the key generated by the later verification is greater than or equal to the key level of the previously generated key, so that the key that meets the current device trust level and is newly generated can be found as the target key for the current data transmission.

[0089] Figure 5is a block diagram of a key management device according to an exemplary embodiment. Figure 5 The key management device includes a first determination module 501 and a second determination module 502.

[0090] The first determination module 501 is configured to, in response to a communication request with a peer device, authenticate the first candidate key if there is an original key for communicating with the peer device in the local device and if the original key contains a first candidate key that meets the trust level of a first target device, where the trust level of the first target device is the current device trust level of the local device and the peer device;

[0091] The second determination module 502 is configured to determine the first candidate key as a target key for communication between the local device and the opposite device if the first candidate key passes the authentication.

[0092] Optionally, the first candidate key is a symmetric key;

[0093] The first determining module 501 includes:

[0094] a sending submodule, configured to send authentication information to the peer device, the authentication information including a target key version number corresponding to the first candidate key, the target key version number being used by the peer device to search for the first candidate key;

[0095] The first determination submodule is configured to determine that the first candidate key is authenticated if it is confirmed that the opposite device has found the first candidate key.

[0096] Optionally, the authentication information further includes first encrypted authentication data, where the first encrypted authentication data is obtained by encrypting the first original authentication data using the first candidate key;

[0097] The key management device 500 further includes:

[0098] an acquisition module, configured to acquire decrypted authentication data, wherein the decrypted authentication data is data obtained by the peer device decrypting the first encrypted authentication data using the found second candidate key;

[0099] The first confirmation module is configured to confirm that the second candidate key found by the opposite device is the first candidate key if the decrypted authentication data matches the first original authentication data.

[0100] Optionally, the key management device 500 further includes:

[0101] A receiving module, configured to receive second encrypted authentication data, where the second encrypted authentication data is obtained by the peer device encrypting the second original authentication data using the found third candidate key;

[0102] The second confirmation module is configured to confirm that the third candidate key found by the opposite device is the first candidate key when the second encrypted authentication data is successfully decrypted using the first candidate key.

[0103] Optionally, the key management device 500 further includes:

[0104] A first authentication module is configured to authenticate the local device with the opposite device when the local device does not have an original key for communicating with the opposite device, or when the original key does not contain a first candidate key that meets the trust level of the first target device.

[0105] The third determination module is configured to determine the key generated by the successful authentication as the target key when the authentication is successful.

[0106] Optionally, the first authentication module includes:

[0107] A second determination submodule is configured to determine a device trust level between the local device and the opposite device;

[0108] A third determination submodule is configured to determine a second target device trust level according to a specified trust level and a device trust level between the local device and the opposite device;

[0109] The authentication submodule is configured to authenticate the local device and the opposite device according to an authentication method corresponding to the trust level of the second target device.

[0110] Optionally, the third determining submodule includes:

[0111] The determination subunit is configured to determine the device trust level that matches the specified trust level and has the highest level among the device trust levels existing between the local device and the opposite device as the second target device trust level.

[0112] Optionally, the key management device 500 further includes:

[0113] A second authentication module is configured to, if the first candidate key fails to pass authentication, cause the local device to re-authenticate with the peer device;

[0114] The fourth determination module is configured to determine the key generated by the successful authentication as the target key when the authentication is successful.

[0115] Optionally, the key management device 500 further includes:

[0116] The generation module is configured to generate a corresponding key version number for the key generated by the successful authentication when the authentication is successful, and the key version number includes a key index and a key sequence number. The key sequence number of the key generated later is greater than the key sequence number of the key generated earlier. The first candidate key is the key with the largest key sequence number among the keys that meet the trust level of the first target device.

[0117] Regarding the device in the above embodiment, the specific manner in which each module performs operations has been described in detail in the embodiment of the method, and will not be elaborated here.

[0118] The present disclosure also provides a computer-readable storage medium having computer program instructions stored thereon, which implement the steps of the key management method provided by the present disclosure when the program instructions are executed by a processor.

[0119] Figure 6 6 is a block diagram of another key management device according to an exemplary embodiment. For example, the key management device 600 may be a mobile phone, a computer, a digital broadcast terminal, a messaging device, a game console, a tablet device, a medical device, a fitness device, a personal digital assistant, etc.

[0120] Reference Figure 6 The key management device 600 may include one or more of the following components: a processing component 602 , a memory 604 , a power component 606 , a multimedia component 608 , an audio component 610 , an input / output interface 612 , a sensor component 614 , and a communication component 616 .

[0121] The processing component 602 generally controls the overall operation of the key management device 600, such as operations associated with display, phone calls, data communications, camera operations, and recording operations. The processing component 602 may include one or more processors 620 to execute instructions to complete all or part of the steps of the key management method described above. In addition, the processing component 602 may include one or more modules to facilitate the interaction between the processing component 602 and other components. For example, the processing component 602 may include a multimedia module to facilitate the interaction between the multimedia component 608 and the processing component 602.

[0122] The memory 604 is configured to store various types of data to support the operations of the key management device 600. Examples of such data include instructions for any application or method operating on the key management device 600, contact data, phone book data, messages, pictures, videos, etc. The memory 604 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk.

[0123] The power supply component 606 provides power to various components of the key management device 600. The power supply component 606 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the key management device 600.

[0124] The multimedia component 608 includes a screen that provides an output interface between the key management device 600 and the user. In some embodiments, the screen may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen may be implemented as a touch screen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touch, slide, and gestures on the touch panel. The touch sensor may not only sense the boundaries of the touch or slide action, but also detect the duration and pressure associated with the touch or slide operation. In some embodiments, the multimedia component 608 includes a front camera and / or a rear camera. When the key management device 600 is in an operating mode, such as a shooting mode or a video mode, the front camera and / or the rear camera may receive external multimedia data. Each front camera and rear camera may be a fixed optical lens system or have focal length and optical zoom capabilities.

[0125] The audio component 610 is configured to output and / or input audio signals. For example, the audio component 610 includes a microphone (MIC), and when the key management device 600 is in an operation mode, such as a call mode, a recording mode, and a speech recognition mode, the microphone is configured to receive an external audio signal. The received audio signal can be further stored in the memory 604 or sent via the communication component 616. In some embodiments, the audio component 610 also includes a speaker for outputting audio signals.

[0126] The input / output interface 612 provides an interface between the processing component 602 and the peripheral interface modules, which may be keyboards, click wheels, buttons, etc. These buttons may include but are not limited to: a home button, a volume button, a start button, and a lock button.

[0127] The sensor assembly 614 includes one or more sensors for providing various aspects of the status assessment of the key management device 600. For example, the sensor assembly 614 can detect the open / closed state of the key management device 600, the relative positioning of components, such as the display and keypad of the key management device 600, the sensor assembly 614 can also detect the position change of the key management device 600 or a component of the key management device 600, the presence or absence of user contact with the key management device 600, the orientation or acceleration / deceleration of the key management device 600, and the temperature change of the key management device 600. The sensor assembly 614 can include a proximity sensor configured to detect the presence of a nearby object without any physical contact. The sensor assembly 614 can also include an optical sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, the sensor assembly 614 can also include an accelerometer, a gyroscope sensor, a magnetic sensor, a pressure sensor, or a temperature sensor.

[0128] The communication component 616 is configured to facilitate wired or wireless communication between the key management device 600 and other devices. The key management device 600 can access a wireless network based on a communication standard, such as WiFi, 2G or 3G, or a combination thereof. In an exemplary embodiment, the communication component 616 receives a broadcast signal or broadcast-related information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component 616 also includes a near field communication (NFC) module to facilitate short-range communication. For example, the NFC module can be implemented based on radio frequency identification (RFID) technology, infrared data association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology and other technologies.

[0129] In an exemplary embodiment, the key management device 600 can be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors or other electronic components to execute the above-mentioned key management method.

[0130] In an exemplary embodiment, a non-transitory computer-readable storage medium including instructions is also provided, such as a memory 604 including instructions, and the instructions can be executed by a processor 620 of a key management device 600 to complete the above-mentioned key management method. For example, the non-transitory computer-readable storage medium can be a ROM, a random access memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, etc.

[0131] In addition to being an independent electronic device, the above-mentioned device can also be a part of an independent electronic device. For example, in one embodiment, the device can be an integrated circuit (IC) or a chip, wherein the integrated circuit can be an IC or a collection of multiple ICs; the chip can include but is not limited to the following types: GPU (Graphics Processing Unit), CPU (Central Processing Unit), FPGA (Field Programmable Gate Array), DSP (Digital Signal Processor), ASIC (Application Specific Integrated Circuit), SOC (System on Chip, SoC, system on chip or system-level chip), etc. The above-mentioned integrated circuit or chip can be used to execute executable instructions (or codes) to implement the above-mentioned key management method. The executable instructions can be stored in the integrated circuit or chip, or can be obtained from other devices or equipment, such as the integrated circuit or chip including a processor, a memory, and an interface for communicating with other devices. The executable instruction can be stored in the memory, and when the executable instruction is executed by the processor, the above-mentioned key management method is implemented; alternatively, the integrated circuit or chip can receive the executable instruction through the interface and transmit it to the processor for execution, so as to implement the above-mentioned key management method.

[0132] In another exemplary embodiment, a computer program product is further provided. The computer program product includes a computer program executable by a programmable device. The computer program has a code portion for executing the above-mentioned key management method when executed by the programmable device.

[0133] Those skilled in the art will readily appreciate other embodiments of the present disclosure after considering the specification and practicing the present disclosure. The present disclosure is intended to cover any variations, uses or adaptations of the present disclosure that follow the general principles of the present disclosure and include common knowledge or customary techniques in the art that are not disclosed in the present disclosure. The description and examples are to be considered as exemplary only, and the true scope and spirit of the present disclosure are indicated by the following claims.

[0134] It should be understood that the present disclosure is not limited to the exact structures that have been described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present disclosure is limited only by the appended claims.

Claims

1. A key management method, characterized in that: include: In response to a communication request with a peer device, if the local device has an original key for communicating with the peer device, and if the original key contains a first candidate key that meets the trust level of a first target device, then authenticating the first candidate key, where the trust level of the first target device is the current device trust level of the local device and the peer device; In a case where the first candidate key passes the authentication, the first candidate key is determined as a target key for communication between the local device and the opposite device.

2. The key management method according to claim 1, characterized in that: The first candidate key is a symmetric key; The authenticating the first candidate key includes: Sending authentication information to the peer device, the authentication information including a target key version number corresponding to the first candidate key, the target key version number being used by the peer device to search for the first candidate key; When it is confirmed that the opposite device has found the first candidate key, it is determined that the first candidate key passes the authentication.

3. The key management method according to claim 2, characterized in that: The authentication information further includes first encrypted authentication data, where the first encrypted authentication data is obtained by encrypting the first original authentication data using the first candidate key; When it is confirmed that the opposite device has found the first candidate key, before determining that the first candidate key has passed the authentication, the method further includes: Acquire decrypted authentication data, where the decrypted authentication data is data obtained by the peer device decrypting the first encrypted authentication data using the found second candidate key; In a case where the decrypted authentication data matches the first original authentication data, it is confirmed that the second candidate key found by the opposite device is the first candidate key.

4. The key management method according to claim 2, characterized in that: When it is confirmed that the opposite device has found the first candidate key, before determining that the first candidate key has passed the authentication, the method further includes: Receiving second encrypted authentication data, where the second encrypted authentication data is obtained by encrypting the second original authentication data by the peer device using the found third candidate key; When the second encrypted authentication data is successfully decrypted using the first candidate key, it is confirmed that the third candidate key found by the opposite device is the first candidate key.

5. The key management method according to any one of claims 1 to 4, characterized in that: The method further comprises: In the case that the local device does not have an original key for communicating with the opposite device, or in the case that the original key does not contain a first candidate key that meets the trust level of the first target device, the local device authenticates the opposite device; When the authentication is successful, the key generated by the successful authentication is determined as the target key.

6. The key management method according to claim 5, characterized in that: The local device and the opposite device perform authentication, including: Determine a device trust level between the local device and the opposite device; Determining a second target device trust level according to a specified trust level and a device trust level between the local device and the opposite device; The local device and the opposite device perform authentication according to the authentication method corresponding to the trust level of the second target device.

7. The key management method according to claim 6, characterized in that: Determining the trust level of the second target device according to the specified trust level and the device trust level between the local device and the opposite device includes: The device trust level that matches the specified trust level and has the highest level among the device trust levels existing between the local device and the opposite device is determined as the second target device trust level.

8. The key management method according to claim 5, characterized in that: The method further comprises: If the first candidate key fails to pass authentication, the local device re-authenticates with the peer device; When the authentication is successful, the key generated by the successful authentication is determined as the target key.

9. The key management method according to claim 5, characterized in that: In the event that the authentication is successful, the method further comprises: A corresponding key version number is generated for the key generated by successful authentication, and the key version number includes a key index and a key sequence number. The key sequence number of the key generated later is greater than the key sequence number of the key generated earlier. The first candidate key is the key with the largest key sequence number among the keys that meet the trust level of the first target device.

10. A key management device, characterized in that: include: A first determination module is configured to, in response to a communication request with a peer device, authenticate the first candidate key if there is an original key for communicating with the peer device in the local device and if the original key contains a first candidate key that meets the trust level of a first target device, wherein the trust level of the first target device is a current device trust level between the local device and the peer device; The second determination module is configured to determine the first candidate key as a target key for communication between the local device and the opposite device if the first candidate key passes the authentication.

11. A key management device, characterized in that: include: processor; a memory for storing processor-executable instructions; The processor is configured to implement the steps of the key management method according to any one of claims 1 to 9 when executed.

12. A computer-readable storage medium having computer program instructions stored thereon, characterized in that: When the program instructions are executed by a processor, the steps of the key management method described in any one of claims 1 to 9 are implemented.

13. A chip, characterized in that: The method comprises a processor and an interface; the processor is used to read instructions to execute the key management method according to any one of claims 1 to 9.

Images