A key management method and device

Abstract

A key management method and device, in the present application, the key management device can store a key in a secure storage area in a device, and the key is the key required by the device during secure startup, software installation, or software upgrade. Afterwards, a key update request can be received, and the key update request is used to request an update of the key. The key update request includes an update credential, and the update credential is signed and issued by a trusted platform; the key management device first verifies the update credential, and after the verification is passed, the key is updated according to the key update request. The key management device can update the key stored in the secure storage area, and the key is no longer unmodifiable. In addition, before updating the key, the update credential needs to be verified. Only when the update credential is verified, the key can be updated, which also makes the key update method more secure.

Description

Technical Field

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

[0002] The corresponding public key is required during the secure startup, software installation, and software upgrade process of the device to verify the modules to be started, the installation packages to be installed, and the upgrade packages. Only after the verification is passed can the modules be started, the software can be installed, and the software can be upgraded to ensure the security of the secure startup, software installation, and software upgrade process.

[0003] The following takes secure boot as an example to explain. Secure boot means that during the device startup process, the previously started module (which can be understood as a software module) verifies the next module that needs to be started. If the verification passes, the next module that needs to be started is triggered to start. If the verification fails, the startup is terminated.

[0004] Currently, the public key used to verify the module during the secure boot process is stored in the electronic fuse (eFuse) in the device's processor. Since the content in the eFuse cannot be cleared or modified, the public key stored in the eFuse cannot be easily changed, resulting in the public key being unable to be updated and managed. Summary of the invention

[0005] The present application provides a key management method and device for updating the public key required during secure startup, software installation, and software upgrade.

[0006] In the first aspect, the embodiment of the present application provides a key management method, which can be executed by a key management device in a device. In the method, the key management device can store a key in a secure storage area in the device, and the key is a key required by the device during secure startup, software installation, or software upgrade. The secure storage area is located in a memory in the device, and in certain scenarios, the data in the secure storage area can be updated. After the key management device stores the key, it can receive a key update request, which is used to request an update of the key. The key update request includes an update credential, which is signed and issued by a trusted platform; the key management device first verifies the update credential, and after the verification is passed, the key is updated according to the key update request. Here, direct key management is taken as an example. In actual applications, a similar method can also be used to manage the relevant information of the key (the operation value after the key is operated, which can be a hash operation, a signature algorithm, or other operations). Here, whether it is direct key management or key-related information management, its essence refers to key management.

[0007] Through the above method, the key management device can update the key stored in the secure storage area, and the key is no longer unmodifiable. In addition, before updating the key, it is necessary to verify the update credentials. The key can only be updated if the update credentials are verified, which also makes the key update method more secure.

[0008] In one possible implementation, the key stored in the secure storage area may be a key required to verify the software code to be run in the device. In addition to the software code to be run, the device also needs to run firmware code, and this fixed code is the first to be started or run during the device startup process. The firmware key required to verify the firmware code to be run by the device can be stored in the secure storage area, or it can be stored in the electronic fuse of the device, that is, the firmware key and the software key are stored in different areas, and the firmware key stored in the electronic fuse cannot be modified. Of course, the firmware key can also be stored in other storage areas that are not allowed to be modified.

[0009] Through the above method, the keys required for software code and firmware code verification are stored in different locations respectively. Since the keys required for software code verification are stored in a secure storage area, the keys can be updated as needed, thereby releasing the binding relationship between the device and the manufacturer of the software code.

[0010] In a possible implementation, when securely booting the device, the key management device may read the firmware key from the electronic fuse, and use the firmware key to verify the firmware code, specifically, to verify the signature of the firmware code (the signature is generated using the private key corresponding to the firmware key). The software code and the firmware code may come from different manufacturers.

[0011] After the firmware code is verified by the firmware key, the firmware code is allowed to run. After the firmware code is run, the key management device can read the key from the secure storage area and use the key to verify the software code. Specifically, the signature of the software code (the signature is generated by the private key corresponding to the key) is verified. After the software code is verified by the key, the software code is allowed to run.

[0012] When the device is installing the software code, the key management device can obtain the key from the secure storage area and verify the installation package of the soft code, that is, verify the signature carried on the installation package. After the verification is passed, the software code is allowed to be installed, that is, the software code is installed through the installation package.

[0013] When the device is upgrading the software code, the key management device can obtain the key from the secure storage area and verify the upgrade package of the soft code, that is, verify the signature carried on the upgrade package. After the verification is passed, the software code is allowed to be upgraded, that is, the software code is upgraded through the upgrade package.

[0014] Through the above method, the device can obtain the key from the secure storage area during the process of running, installing, or upgrading the software code, so that the software code can be verified to ensure the security of the software code during operation, installation, and upgrading.

[0015] In a possible implementation, when the key management device stores the key in the secure storage area of ​​the device, it can directly store the key in the secure storage area, or it can first sign the key and store the signed key in the secure storage area. The private key used to sign the key is not limited here.

[0016] Through the above method, the key management device can store the key in the secure storage area in different ways, which is flexible and suitable for different scenarios.

[0017] In one possible implementation, when verifying the update credential, the key management device can confirm whether the signature of the update credential comes from a trusted platform, for example, by using the public key of the trusted platform to verify the signature. If the signature of the update credential comes from the trusted platform, the verification succeeds, otherwise the verification fails. If the update credential also indicates a key that needs to be updated, when verifying the update credential, in addition to confirming whether the signature of the update credential comes from the trusted platform, the key management device can also confirm whether the key that needs to be updated indicated by the update credential is consistent with the key stored in the secure storage area. When it is determined that the signature of the update credential comes from the trusted platform and the key that needs to be updated indicated by the update credential is consistent with the key stored in the secure storage area, it is determined that the verification of the update credential has succeeded. When it is determined that the signature of the update credential does not come from the trusted platform or the key that needs to be updated indicated by the update credential is inconsistent with the key stored in the secure storage area, it is determined that the verification of the update credential has failed.

[0018] Through the above method, when verifying the update certificate, the key management device can confirm the signature of the update certificate and the content indicated by the update certificate, thereby ensuring the validity of the update certificate and further ensuring that the key can be updated safely and effectively in the future.

[0019] In a possible implementation, after the key management device updates the key in the secure storage area, it can mark the update credential as invalid, so as to avoid receiving a key update request with the same update credential again and performing invalid operations on the key.

[0020] In a possible implementation, the key management device may also record the number of key updates, that is, after each key update in the secure storage area, the key management device also records the key update and adds 1 to the recorded number of key updates. The key management device records the number of key updates to facilitate subsequent key management, such as limiting the number of key updates allowed.

[0021] In one possible implementation, before the key management device updates the key in the secure storage area, it may first determine whether the number of key updates is not less than a preset number. If the number of key updates is less than the preset number, the key management device may update the key. If the number of key updates is greater than or equal to the preset number, it means that the number of key updates has reached the upper limit, and the key management device may refuse to update the key.

[0022] Through the above method, the number of times the key is allowed to be updated is limited by a preset number of times, which makes it easier for the key management device to manage the key and ensures that the key will not be modified unlimited times.

[0023] In a possible implementation, the secure storage area also includes a key blacklist, which is used to indicate expired keys. The key management device can use the key blacklist to limit the keys used by the device during secure boot, software installation, and software upgrade. When the key used by the device during secure boot, software installation, and software upgrade is a key indicated in the key blacklist, the use of the key is stopped, or the key is not allowed to be stored in the secure storage area (for example, the key is deleted or the key is refused to be stored in the secure storage area). When the key blacklist directly records the expired blacklist, the key is not allowed to be stored in the secure storage area here, which means that the key is not allowed to be stored in areas other than the area storing the key blacklist in the secure storage area.

[0024] In a possible implementation, the secure storage area is located in a flash memory or a processor. The data stored in the flash memory and the processor are highly secure, and can ensure that the key is not easily tampered with, thereby ensuring the security of the key.

[0025] In the second aspect, the embodiment of the present application also provides a key management device, which has the function of implementing the behavior in the method example of the first aspect above. The beneficial effects can be found in the description of the first aspect and will not be repeated here. The function can be implemented by hardware or by executing corresponding software through hardware. The hardware or software includes one or more modules corresponding to the above functions. In one possible design, the structure of the device includes a transmission unit, a storage unit, an update unit, and a verification unit, which can perform the corresponding functions in the method example of the first aspect above. Please refer to the detailed description in the method example for details, which will not be repeated here.

[0026] In the third aspect, the embodiment of the present application further provides a device, which has the function of implementing the behavior in the method example of the first aspect above. The beneficial effects can be found in the description of the first aspect and will not be repeated here. The structure of the device includes a processor and a memory, and the processor is configured to support the device to perform the corresponding functions in the method of the first aspect above. The memory is coupled to the processor, which stores the necessary program instructions and data for the communication device. The structure of the communication device also includes a communication interface for communicating with other devices, such as obtaining a key or receiving a key update request.

[0027] In a fourth aspect, the present application further provides a computer-readable storage medium, wherein the computer-readable storage medium stores instructions, which, when executed on a computer, enable the computer to execute the method described in the first aspect above.

[0028] In a fifth aspect, the present application also provides a computer program product comprising instructions, which, when executed on a computer, enables the computer to execute the method described in the first aspect above.

[0029] In a sixth aspect, the present application further provides a computer chip, wherein the chip is connected to a memory, and the chip is used to read and execute a software program stored in the memory to execute the method described in the first aspect above. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] Figure 1A A schematic diagram of the architecture of a system provided for this application;

[0031] Figure 1B A schematic diagram of a module required for a secure boot provided in this application;

[0032] Figure 2 A schematic diagram of a key management method provided for this application;

[0033] Figure 3 A schematic diagram of the structure of a key management device provided by this application;

[0034] Figure 4 A schematic diagram of the structure of a key management device provided in this application. DETAILED DESCRIPTION

[0035] like Figure 1A As shown, a system provided by an embodiment of the present application includes a key management device 100 and a key updating device 200 .

[0036] In an embodiment of the present application, the key management device 100 can be located in the device to manage the keys required by the device during secure startup, software installation, or software upgrade. The management operations include but are not limited to: storing the keys in a secure storage area and updating the keys stored in the secure storage area.

[0037] The key updating device 200 may be a device independent of the device or a device deployed in the device. When determining that the key needs to be updated, it can send a key update request to the key management device 100 to request the key management device 100 to update the key.

[0038] The method by which the key update device 200 determines that the key needs to be updated is not limited here. For example, the user can operate on the key update device 200, such as selecting the key to be updated, determining the updated key, and loading the update certificate. After detecting the user's operation, the key update device 200 can determine the key to be updated and the updated key, and can also obtain the update certificate; thereafter, the key update device 200 can send a key update request to the key management device 100 to request the key management device 100 to update the key.

[0039] The following describes the processes of secure boot, software installation, and software upgrade respectively:

[0040] (1) Secure Boot

[0041] Secure boot requires that during the device boot process, the first module to be started needs to verify the next module to be started. Only after the verification is passed, the next module is allowed to start.

[0042] The following example takes the secure boot process as an example, where four modules need to be started. Figure 1B ,like Figure 1B As shown in the figure, there are four modules that need to be started during the device startup process, namely module A, module B, module C and module D. The startup order of module A, module B, module C and module D is module A->module B->module C->module D.

[0043] Module A may be a firmware code in the device and is a module that needs to be started first. Module A may be a software module that matches the processor of the device and may be configured in the processor by the processor manufacturer (here the processor manufacturer is manufacturer 1 as an example).

[0044] Module B, module C, and module D may be software modules that need to be run on a processor, and may be software modules from other manufacturers. The manufacturer of module B is manufacturer 2, the manufacturer of module C is manufacturer 3, and the manufacturer of module D is manufacturer 4.

[0045] Module B carries signature B generated by manufacturer 2 using the private key corresponding to public key b, module C carries signature C generated by manufacturer 3 using the private key corresponding to public key c, and module D carries signature D generated by manufacturer 4 using the private key corresponding to public key d.

[0046] The public keys of module B, module C and module D pre-stored in the storage area of ​​the device are public key b, public key c and public key d respectively.

[0047] Since module A is a fixed code, it is started first. After starting, module A will first obtain the public key b of module B from the storage area of ​​the device, and use the public key b to verify the signature B carried in module B. If the verification passes, module B is triggered to start.

[0048] After module B is started, module B will first obtain the public key c of module C from the storage area of ​​the device, and use the public key c to verify the signature C carried in module C. If the verification passes, module C will be triggered to start.

[0049] After module C is started, module C will first obtain the public key d of module D from the storage area of ​​the device, and use the public key d to verify the signature D carried in module D. If the verification passes, module D will be triggered to start.

[0050] It should be noted that here, when the device is started, module A, module B, module C and module D all use similar methods to verify the modules started subsequently. In this case, multiple public keys will be stored in the access area of ​​the device. In actual applications, other methods are allowed to be used for verification between modules, that is, the device can use the method described in the above description to verify the modules started subsequently during the startup process in combination with other methods. For example, only public key b can be stored in the storage area of ​​the device, module A can verify module B in the above method, and module B and module C, module C and module D can be verified in other ways. Other verification methods are not limited here. In this case, the storage area only stores public key b.

[0051] In an embodiment of the present application, public key b, public key c or public key d can be stored in a secure storage area of ​​the device. In an embodiment of the present application, the secure storage area can be located in a flash memory, such as an embedded non-volatile flash memory block with replay protection (flash embeded multimedia card replay protect memory block, flashEMMC RPMB), flash persistent protection bits (flash persistent protection bits, flash PPB), flash solid protection bits (flash SPB), or a secure storage area located in the device processor.

[0052] In an embodiment of the present application, data (such as public keys) stored in the secure storage area is allowed to be updated, such as deleted, modified, etc.

[0053] (2) Software Installation

[0054] When software (also called software code) needs to be installed in a device, the device obtains the installation package of the software (the installation package can be understood as a module), which carries a signature generated by the private key corresponding to the public key e. When the software needs to be installed, the device first obtains the public key e, which can be stored in the storage area of ​​the device. The method and time of storing the public key e in the storage area are not limited here. It can be pre-configured in the storage area, or it can be written into the storage area by other devices when it is determined that the software needs to be installed. The public key e can also be carried in the installation package of the software. When the installation package is obtained, the device can obtain the public key e from the installation package.

[0055] The device uses the public key e to verify the signature in the installation package, and after the verification is passed, uses the installation package to install the software.

[0056] (3) Software upgrade

[0057] When the software in the device needs to be upgraded, the device first obtains the upgrade package of the software (the upgrade package can be understood as a module), which carries a signature generated by the private key corresponding to the public key f. When the software needs to be upgraded, the device first obtains the public key f, which can be stored in the storage area of ​​the device. The method and time of storing the public key f in the storage area are not limited here. It can be pre-configured in the storage area, or it can be written into the storage area by other devices when it is determined that the software needs to be upgraded. The public key f can also be carried in the upgrade package of the software. When the upgrade package is obtained, the device can obtain the public key f from the upgrade package.

[0058] The device uses the public key f to verify the signature in the upgrade package, and after the verification is passed, uses the upgrade package to upgrade the software.

[0059] From the above description, it can be seen that during the process of secure startup, software installation and software upgrade, the public key needs to be used to verify the module to be started, installed or upgraded. Only after the verification is passed can the startup, installation and upgrade be carried out to ensure the security of the startup, software installation and software upgrade process.

[0060] Currently, the public key required by the device during secure startup, software installation, or software upgrade is usually stored in the eFuse in the processor. Since the data stored in the eFuse cannot be modified once written, the board where the processor is located is "bound" to the manufacturer corresponding to the public key stored in the eFuse (the manufacturer is also the manufacturer of the module).

[0061] Taking the secure boot scenario as an example, the binding here refers to the binding relationship between the board and the manufacturer of module 2 (ie, manufacturer 2). Manufacturer 1, the maintenance manufacturer of the board where the processor is located, cannot change the data stored in the eFuse when receiving the board. That is, manufacturer 1 cannot change the public key stored in the eFuse.

[0062] In addition, for manufacturer 1, each single board can be bound to a manufacturer, and different single boards may be bound to different manufacturers. Manufacturer 1 needs to maintain multiple single boards bound to different manufacturers. This maintenance method is costly and inflexible. For example, there are currently two single boards, single board A is a single board bound to manufacturer 2, and single board B is a single board bound to manufacturer 3. When manufacturer 1 receives single board A and single board B, it repairs single board A and single board B. It can only return single board A to user A after single board A is repaired, and return single board B to user B after single board B is repaired. If user B urgently needs single board B, when single board B is not repaired but single board A is repaired, manufacturer 1 cannot rewrite the data stored in the eFuse, and cannot change the binding relationship between single board A and manufacturer 2 to meet the needs of user B.

[0063] In an embodiment of the present application, the key management device 100 can store the public key required by the device during secure startup, software installation, or software upgrade in a secure storage area of ​​the device, and can also update the public key after receiving a key update request. That is to say, the public key required by the device during secure startup, software installation, or software upgrade is not fixed after being saved in the device. When a software module installed in the device changes, such as a software module upgrade, or replacement with another software module, the public key can be updated to ensure that the device can still perform secure startup, software installation, or software upgrade processes normally after the software module changes, thereby improving the flexibility of the public key configuration.

[0064] In addition, in the single board maintenance manufacturer, the single board maintenance manufacturer can change the public key stored in the secure storage area through the key management device 100 to change the binding relationship between the single board and the manufacturer to meet the needs of different users, thereby effectively improving the flexibility of single board maintenance.

[0065] A key management method provided in an embodiment of the present application is described below in conjunction with the accompanying drawings. Here, the key management device 100 managing the public key is used as an example for description. Figure 2 , the method comprising:

[0066] Step 201: The key management device 100 obtains a public key, which is a public key required by the device during secure startup, software installation, or software upgrade.

[0067] The embodiment of the present application does not limit the way in which the key management device 100 obtains the public key. For example, the public key can be pre-configured to the key management device 100 before the device is released, or it can be sent to the key management device 100 after the device is released.

[0068] Step 202: After obtaining the public key, the key management device 100 may store the public key in a secure storage area in the device.

[0069] After obtaining the public key, the key management device 100 may directly store the public key in the secure storage area, or may first sign the public key and, after signing, store the signed public key in the secure storage area.

[0070] After the public key is stored in the secure storage area, the public key may then be updated.

[0071] Step 203: The key update device 200 sends a key update request to the key management device 100, and the key management device 100 receives the key update request. The key update request is used to request an update of the public key, and the key update request carries an update certificate. The update certificate is signed and issued by the trusted platform. The type of the trusted platform is not limited here. For example, the trusted platform can be the manufacturer of the device or the processor in the device, or it can be a platform trusted by the manufacturer, such as other manufacturers trusted by the manufacturer, the manufacturer of the module running the device, or an authoritative organization, such as a certificate authority.

[0072] Before sending a key update request, the key update device 200 needs to obtain an update credential. The update credential can be loaded in the key update device 200 by the user, or applied by the key update device 200 to the trust platform. For example, the key update device 200 can send a credential acquisition request to the trust platform, requesting the trust platform to issue an update credential. The credential acquisition request can carry the identity information of the key update device 200. The credential acquisition request can also indicate the key to be updated, the key update method, etc. After receiving the credential acquisition request, the trust platform can use the identity information of the key update device 200 for verification, and issue the update credential after the verification is passed. The embodiment of the present application does not limit the method in which the key update device 200 obtains the update credential.

[0073] The update certificate may carry the signature information of the trusted platform, which may be generated using the private key of the trusted platform. The update certificate also records the device or processor to which the update certificate applies. The update certificate does not limit the manner in which the update certificate also records the device or processor to which the update certificate applies. For example, the update certificate may record the model of the device or the processor of the device, or may carry information that can uniquely identify the device or the processor of the device.

[0074] The update certificate may also indicate the public key to be updated and the method of updating the public key. The method of indicating the public key to be updated by the update certificate is not limited here, for example, the public key to be updated may be directly recorded in the update certificate.

[0075] For another example, the update credential may record the identification information of the public key that needs to be updated, and the identification information may be pre-configured for the public key. The key management device 100 may be aware of the identification information of the public key stored in the secure storage area, and the method by which the key management device 100 obtains the identification information of the public key is not limited here. For example, when the key management device 100 receives the public key that needs to be stored in the secure storage area, it may simultaneously receive the identification information of the public key, and the key management device 100 may save the identification information of the public key. For another example, the key management device 100 may query other devices for the identification information of the public key by sending a query message.

[0076] In the embodiments of the present application, the public key update method includes but is not limited to: modification, deletion, and addition.

[0077] When the public key update mode is modification, it means that the public key stored in the secure storage area needs to be modified, and the modified public key can also be carried in the update certificate. When the public key update mode is deletion, it means that the public key to be updated needs to be deleted. When the public key update mode is addition, it means that a new public key is added in the secure storage area, and the public key to be added can also be carried in the update certificate.

[0078] It should be noted that, when only one public key is stored in the secure storage area of ​​the device, the update credential may not indicate the public key that needs to be updated.

[0079] Step 204: After receiving the key update request, the key management device 100 may first obtain the update credential in the key update request and verify the update credential.

[0080] When the key management device 100 verifies the update credential, it can use the public key of the trusted platform to verify whether the signature in the update credential comes from the trusted platform. The method in which the key management device 100 obtains the public key of the trusted platform is not limited here. For example, the public key of the trusted platform can be pre-stored in the key management device 100, and the key management device 100 can obtain the public key of the trusted platform locally. For another example, when the key management device 100 determines that the update credential needs to be verified, it can obtain the public key of the trusted platform from the trusted platform, such as obtaining the public key of the trusted platform from the website of the trusted platform.

[0081] If the signature of the update certificate does not come from the trusted platform, the key management device 100 fails to verify the update certificate. If the signature of the update certificate comes from the trusted platform, the key management device 100 can determine that the update certificate is verified. It can also further confirm whether the public key that needs to be updated indicated by the update certificate is consistent with the public key stored in the secure storage area. After confirming that they are consistent, it is determined that the update certificate is verified. Otherwise, the verification fails.

[0082] The way in which the key management device 100 confirms whether the public key to be updated indicated by the update certificate is consistent with the public key stored in the secure storage area is related to the way in which the update certificate indicates the public key to be updated; for example, the update certificate directly records the public key to be updated, and the key management device 100 can compare the public key to be updated recorded in the update certificate with the public key stored in the secure storage area to determine whether they are consistent. For example, the update certificate indicates the public key to be updated using the identification information of the public key to be updated, and the key management device 100 can determine whether the identification information recorded in the update certificate is consistent with the identification information of the public key stored in the secure storage area.

[0083] Step 205: After verifying the update credentials, the key management device 100 can update the public key stored in the secure storage area according to the update credentials.

[0084] When the update certificate indicates that the public key update method is modification, the key management device 100 can update the public key stored in the secure storage area to the modified public key indicated in the update certificate.

[0085] When the public key update method indicated by the update certificate is deletion, the key management device 100 may delete the public key stored in the secure storage area.

[0086] When the public key update method indicated by the update certificate is addition, the key management device 100 may add the public key to be added carried in the update certificate in the secure storage area.

[0087] For the public key stored in the secure storage area, in order to further ensure the validity of the update operation of the public key, the update operation of the public key can only be modified by a specific party holding an update certificate (such as only by the manufacturer of the device or a party trusted by the manufacturer), or can only be modified within a specific time period (such as during the return to the factory). To this end, the validity status of the update certificate can be set. An update certificate can only update the public key once. After the public key stored in the secure storage area is modified once using the update certificate, the update certificate will no longer be usable. In other words, after the key management device 100 updates the public key stored in the secure storage area according to the update certificate, the update certificate becomes an invalid certificate, and the key management device 100 can mark the update certificate as invalid.

[0088] The method of marking the update credential as invalid is not limited here. For example, the key management device 100 can save the update credential and mark the update credential as an invalid credential. When receiving the key update request again, the key management device 100 can first determine whether the update credential carried in the key update request is consistent with the saved and marked invalid credential. If they are consistent, it means that the update credential carried in the key update request is an invalid credential. The key management device 100 can reject the key update request and refuse to update the public key.

[0089] For another example, the key management device 100 may save the identification information of the update credential (the identification information of the update credential may be information assigned by the trusted platform and uniquely indicating the update credential, and the identification information of the update credential may be recorded in the update credential or carried in the key update request). When the key update request is received again, the key management device 100 may first determine whether the identification information of the update credential carried in the key update request is consistent with the identification information of the saved, invalid credential. If they are consistent, it means that the update credential carried in the key update request is an invalid credential, and the key management device 100 may reject the key update request and refuse to update the public key.

[0090] In addition to identifying the invalid state of the update credential, the validity of the update operation can also be ensured by limiting the number of public key updates. The key management device 100 can pre-configure the number of public key updates and set the number of public key updates to a preset number. Before each update of the public key in the secure storage area, it is also determined whether the number of public key updates exceeds the preset number, that is, whether the number of public key updates is greater than or equal to the preset number. Here, the number of public key updates refers to the number of completed updates for the public key stored in the secure storage area.

[0091] The method of pre-configuring the preset number of times by the key management device 100 is not limited here. For example, the key management device 100 can set a fixed number of bits, each bit corresponds to an update of the public key. After the public key is updated once, the key management device 100 can change the value of the bit to a set value (such as the initial value of the bit is 0, and the set value is 1). When the values ​​of the fixed number of bits are all changed to the set value, it means that the current number of updates of the public key has reached the preset number. For another example, the key management device 100 can maintain a cumulative value and set the initial value of the cumulative value to be equal to the preset number. Each time a pair of public keys stored in the secure storage area is updated, the number of the cumulative value decreases. When the cumulative value decreases to 0, it means that the current number of updates of the public key has reached the preset number.

[0092] If it is confirmed that the number of updates of the public key is greater than or equal to the preset number, the key management device 100 may reject the update of the public key stored in the secure storage area.

[0093] If it is confirmed that the number of updates of the public key is less than the preset number, the key management device 100 updates the public key stored in the secure storage area and records the update of the public key. That is, each time the public key stored in the secure storage area is updated, the number of updates of the public key will be increased by one. The number of updates of the public key is accumulated as the public key stored in the secure storage area is updated.

[0094] Of course, in the embodiment of the present application, the number of times the public key is updated may not be limited, but only the number of times the public key is updated is recorded locally.

[0095] In an embodiment of the present application, the invalid status of the identification update certificate and the limit on the number of updates of the public key can also be used in combination. For example, the key management device 100 can be set with a fixed number of bits, each bit corresponds to an update of the public key, and each bit corresponds to an update certificate. After the public key is updated once, the key management device 100 can change the value of the bit to a set value (such as the initial value of the bit is 0, and the set value is 1). The set value can indicate that the public key has been updated once, or that the update certificate corresponding to the bit is invalid. When the values ​​of the fixed number of bits are all changed to the set values, it means that the current public key has been updated a preset number of times, and the update certificates corresponding to the bits of the fixed data are also invalid.

[0096] In some scenarios, the private key is easily exposed or stolen. If the public key corresponding to the private key continues to be used during the device's secure startup, software installation, and software upgrade, it will pose a threat to the security of the device.

[0097] For private keys that have been exposed or stolen, the key management device 100 needs to be notified in a timely manner to prevent the use of the public key corresponding to the private key. In an embodiment of the present application, the secure storage area may include a public key blacklist, which may indicate expired public keys. The expired keys indicate public keys that have stopped being used (for example, the manufacturer of the software module running in the processor has explicitly indicated that the public key is no longer used).

[0098] The manner in which the public key blacklist indicates the expired public keys is not limited here. For example, the public key blacklist may directly record the expired public keys. For another example, the public key blacklist may directly record the identification information of the expired public keys.

[0099] When the key management device 100 receives a public key that needs to be stored in a secure storage area, it can first determine whether the public key is a public key indicated by the public key blacklist. If so, it refuses to store the public key in the secure storage area; otherwise, it stores the public key in the secure storage area.

[0100] When the key management device 100 receives a key update request, it can first determine whether the updated public key carried in the key update request is the public key indicated by the public key blacklist. If so, it refuses to update the public key stored in the secure storage area. Otherwise, it updates the public key stored in the secure storage area according to the update credentials.

[0101] When the device is in the process of secure booting, software installation and software upgrade, the public key blacklist can also be used to identify whether the public key used by the device in the process of secure booting, software installation and software upgrade has expired.

[0102] When the device is securely started, it obtains the public key required to verify the module to be started, such as the public key stored in the secure storage area or the public key carried in the installation package, and determines whether the public key is the public key indicated by the public key blacklist. If so, the module is stopped from starting; otherwise, the module is started.

[0103] When installing software, the device obtains the public key required to verify the installation package to be installed, such as the public key stored in the secure storage area or the public key carried in the installation package, and determines whether the public key is the public key indicated by the public key blacklist. If so, stop installing the software; otherwise, install the software.

[0104] When upgrading the software, the device obtains the public key required to verify the software upgrade package, such as the public key stored in the secure storage area or the public key carried in the upgrade package, and determines whether the public key is the public key indicated by the public key blacklist. If so, stop upgrading the software; otherwise, upgrade the software.

[0105] It should be noted that in the embodiment of the present application, the direct storage or update of the key is taken as an example. In actual applications, the associated information of the key can also be stored, such as the hash value obtained by performing a hash operation on the key. The function of the hash value of the key is equivalent to that of the key, and can be used as follows: Figure 2 The illustrated embodiment stores the associated information of the key and updates the associated information of the key.

[0106] Based on the same inventive concept as the method embodiment, the embodiment of the present application also provides a key management device for performing the above-mentioned Figure 2 The method performed by the key management device in the method embodiment shown, the relevant features can be found in the above method embodiment, and will not be repeated here.

[0107] like Figure 3 As shown, the key management device 300 includes a transmission unit 302 , a storage unit 301 , and an update unit 303 .

[0108] The storage unit 301 is used to store a key in a secure storage area in the device, where the key is a key required by the device during secure startup, software installation, or software upgrade.

[0109] The transmission unit 302 is used to receive a key update request, where the key update request includes an update credential, and the update credential is signed and issued by the trusted platform.

[0110] The updating unit 303 is used to update the key after the update credential is verified.

[0111] In a possible implementation, the key stored in the secure storage area may be a key required to authenticate the software code to be run in the device. In addition to the software code, the device may also include firmware code, which is the first fixed code to be started or run during the device startup process.

[0112] The firmware key required to verify the firmware code that the device needs to run can be stored in a secure storage area or in an electronic fuse of the device, that is, the firmware key and the software key are stored in different areas, and the firmware key stored in the electronic fuse cannot be modified. Of course, the firmware key can also be stored in other storage areas that are not allowed to be modified.

[0113] In a possible implementation, when the device is securely started, the key management device further includes a verification unit 304, which can read the firmware key from the electronic fuse, and use the firmware key to verify the firmware code, specifically, to verify the signature of the firmware code (the signature is generated using the private key corresponding to the firmware key). The software code and the firmware code can come from different manufacturers.

[0114] After the verification unit 304 verifies the firmware code with the firmware key, the firmware code is allowed to run. After the firmware code is run, the verification unit 304 can also read the key from the secure storage area and use the key to verify the software code, specifically, the signature of the software code (the signature is generated using the private key corresponding to the key). After the software code is verified with the key, the software code is allowed to run.

[0115] When the device is installing the software code, the verification unit 304 can obtain the key from the secure storage area and verify the installation package of the soft code, that is, verify the signature carried on the installation package. After the verification is passed, the software code is allowed to be installed, that is, the software code is installed through the installation package.

[0116] When the device is upgrading the software code, the verification unit 304 can obtain the key from the secure storage area and verify the upgrade package of the soft code, that is, verify the signature carried on the upgrade package. After the verification is passed, the software code is allowed to be upgraded, that is, the software code is upgraded through the upgrade package.

[0117] As a possible implementation, when the storage unit 301 stores the key in the secure storage area in the device, it may directly store the key in the secure storage area, or it may first sign the key and store the signed key in the secure storage area.

[0118] As a possible implementation, when verifying the update credential, the update unit 303 may confirm whether the signature of the update credential comes from a trusted platform; after determining that the signature of the update credential comes from a trusted platform, the update credential is verified to be successful, otherwise, the verification fails. If the update credential also indicates a key that needs to be updated, when verifying the update credential, in addition to confirming whether the signature of the update credential comes from a trusted platform, the update unit may also confirm whether the key that needs to be updated indicated by the update credential is consistent with the key stored in the secure storage area. When it is confirmed that the signature of the update credential comes from a trusted platform and the key that needs to be updated indicated by the update credential is consistent with the key stored in the secure storage area, the update credential is verified to be successful, otherwise, the verification fails.

[0119] As a possible implementation, after updating the key in the secure storage area, the updating unit 303 marks the update credential as being in an invalid state.

[0120] As a possible implementation, after updating the key in the secure storage area, the updating unit 303 may also record the number of times the key is updated.

[0121] As a possible implementation, before updating the key in the secure storage area, the update unit 303 may determine whether the number of key updates is less than a preset number. If so, the key in the secure storage area is updated; otherwise, the key update is refused.

[0122] As a possible implementation, the secure storage area further includes a key blacklist, where the blacklist is used to indicate expired keys.

[0123] As a possible implementation, the secure storage area is located in a flash memory or a processor.

[0124] It should be noted that the division of units in the embodiments of the present application is schematic and is only a logical function division. There may be other division methods in actual implementation. Each functional unit in the embodiments of the present application may be integrated into a processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0125] The above embodiments can be implemented in whole or in part by software, hardware, firmware or any other combination. When implemented by software, the above embodiments can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded or executed on a computer, the process or function described in the embodiment of the present invention is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from one website site, computer, server or data center to another website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server or data center that contains one or more available media sets. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium. The semiconductor medium can be a solid state drive (SSD).

[0126] In a simple embodiment, a person skilled in the art may think of Figure 3 In the embodiment shown, the key management device can be used Figure 4 The form shown.

[0127] like Figure 4 The device 400 shown includes at least one processor 401 , a memory 402 , and optionally, a communication interface 403 .

[0128] The memory 402 may be a volatile memory, such as a random access memory; the memory 402 may also be a non-volatile memory, such as a read-only memory, a flash memory, a hard disk drive (HDD) or a solid-state drive (SSD), or the memory 402 may be any other medium that can be used to carry or store the desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto. The memory 402 may be a combination of the above memories. The secure storage area in the embodiment of the present application may be located in the memory 402, such as in the non-volatile memory of the memory 402.

[0129] The specific connection medium between the processor 401 and the memory 402 is not limited in the embodiment of the present application.

[0130] The processor 401 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC), field programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, artificial intelligence chips, chips on chips, etc. A general-purpose processor may be a microprocessor or any conventional processor. It has data transmission and reception functions and can communicate with other devices, such as Figure 4 An independent data transceiver module, such as a communication interface 403, may also be provided in the device for transmitting and receiving data. When the processor 401 communicates with other devices, it may transmit data through the communication interface 403, such as receiving a key or a key update request.

[0131] When the key management device adopts Figure 4 When the form shown is Figure 4 The processor 401 in the embodiment can call the computer-executable instructions stored in the memory 402, so that the key management device can execute the method executed by the key management device in any of the above method embodiments.

[0132] Specifically, Figure 3 The functions / implementation processes of the transmission unit, storage unit, update unit and verification unit can be realized by Figure 4 The processor 401 in the embodiment calls the computer execution instructions stored in the memory 402 to implement. Or, Figure 3The storage unit and the function / implementation process of the update unit can be achieved by Figure 4 The processor 401 in the embodiment calls the computer execution instruction stored in the memory 402 to implement, Figure 3 The function / implementation process of the transmission unit can be achieved through Figure 4 It is implemented by the communication interface 403 in.

[0133] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application may adopt the form of a computer program product implemented in one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that include computer-usable program code.

[0134] The present application is described with reference to the flowchart and / or block diagram of the method, device (system), and computer program product according to the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the process and / or box in the flowchart and / or block diagram can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device produce a device for implementing the function specified in one process or multiple processes in the flowchart and / or one box or multiple boxes in the block diagram.

[0135] These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer-readable memory produce a manufactured product including an instruction device that implements the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0136] These computer program instructions may also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, whereby the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0137] Obviously, those skilled in the art can make various changes and modifications to the present application without departing from the scope of the present application. Thus, if these modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is also intended to include these modifications and variations.

Claims

1. A key management method, characterized in that: The method comprises: Storing a key in a secure storage area in a device, wherein the key is a key required by the device during secure startup, software installation, or software upgrade; receiving a key update request, wherein the key update request includes an update credential, wherein the update credential is signed and issued by a trusted platform, and wherein a valid state of the update credential indicates that the update credential updates the key once; After the update credential is verified and it is determined that the identification information of the update credential is inconsistent with the identification information of the stored, expired credential, updating the key; After the key is updated, marking the update credential as invalid; The step of marking the update credential as an invalid state comprises: marking the updated credential as an invalid credential; or The identification information of the updated credential is saved, and the identification information of the updated credential is used as the identification information of the invalid credential.

2. The method according to claim 1, characterized in that The key is a key required for verifying the software code to be run in the device. A firmware key is stored in an electronic fuse in the device. The firmware key is a key required for verifying the firmware code to be run in the device. The electronic fuse does not include the secure storage area.

3. The method according to claim 2, characterized in that The method further comprises: When the device is securely started, the firmware key is read from the electronic fuse, and after the firmware code is verified by using the firmware key, the firmware code is run; The key is read from the secure storage area, and after the software code is authenticated by the key, the software code is allowed to run.

4. The method according to any one of claims 1 to 3, characterized in that: The step of storing the key in a secure storage area in the device includes: The key is signed, and the signed key is stored in the secure storage area.

5. The method according to any one of claims 1 to 3, characterized in that: The update credential is used to indicate the key that needs to be updated, and the verification of the update credential includes: confirming that the signature of the update credential comes from the trusted platform; Confirm that the key to be updated indicated by the update credential is consistent with the key stored in the secure storage area.

6. The method according to any one of claims 1 to 3, characterized in that: After the key in the secure storage area is updated, the method further includes: The update credential is marked as being in an invalid state.

7. The method according to any one of claims 1 to 3, characterized in that: After the key in the secure storage area is updated, the method further includes: The number of times the key is updated is recorded.

8. The method according to claim 7, characterized in that Before the key in the secure storage area is updated, the method further includes: It is determined that the number of times the key is updated is less than a preset number.

9. The method according to any one of claims 1 to 3 and 8, characterized in that: The secure storage area also includes a key blacklist, where the blacklist is used to indicate expired keys.

10. The method according to any one of claims 1 to 3 and 8, characterized in that: The secure storage area is located in the flash memory or in the processor.

11. A key management device, characterized in that: The device comprises: A storage unit, used to store a key in a secure storage area in a device, wherein the key is a key required by the device during secure startup, software installation, or software upgrade; A transmission unit, configured to receive a key update request, wherein the key update request includes an update credential, wherein the update credential is signed and issued by a trusted platform, and wherein a valid state of the update credential indicates that the update credential updates the key once; an updating unit, configured to update the key after the update credential is verified and it is determined that the identification information of the update credential is inconsistent with the identification information of the stored, invalid credential; after the key is updated, mark the update credential as invalid; The step of marking the update credential as an invalid state includes: marking the updated credential as an invalid credential; or The identification information of the updated credential is saved, and the identification information of the updated credential is used as the identification information of the invalid credential.

12. The device according to claim 11, characterized in that The key is a key required for verifying the software code to be run in the device. A firmware key is stored in an electronic fuse in the device. The firmware key is a key required for verifying the firmware code to be run in the device. The electronic fuse does not include the secure storage area.

13. The device according to claim 12, characterized in that The device also includes a verification unit; The verification unit is used to read the firmware key from the electronic fuse when the device is securely started, and run the firmware code after the firmware code is verified by using the firmware key; The key is read from the secure storage area, and after the software code is authenticated by the key, the software code is allowed to run.

14. The device according to any one of claims 11 to 13, characterized in that: When storing the key in the secure storage area in the device, the storage unit is specifically used to: The key is signed, and the signed key is stored in the secure storage area.

15. The device according to any one of claims 11 to 13, characterized in that: The update credential is used to indicate the key that needs to be updated. When the update credential is verified successfully, the update unit is specifically used to: confirming that the signature of the update credential comes from the trusted platform; Confirm that the key to be updated indicated by the update credential is consistent with the key stored in the secure storage area.

16. The device according to any one of claims 11 to 13, characterized in that: After updating the key in the secure storage area, the updating unit is further used to: The update credential is marked as being in an invalid state.

17. The device according to any one of claims 11 to 13, characterized in that: After updating the key in the secure storage area, the updating unit is further used to: The number of times the key is updated is recorded.

18. The device according to claim 17, characterized in that Before updating the key in the secure storage area, the updating unit is further used to: Determine that the number of updates of the key does not exceed a preset number.

19. The device according to any one of claims 11 to 13 and 18, characterized in that: The secure storage area also includes a key blacklist, where the blacklist is used to indicate expired keys.

20. The device according to any one of claims 11 to 13 and 18, characterized in that: The secure storage area is located in the flash memory or in the processor.

21. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions, and the computer-executable instructions are used to enable a computer to execute the method according to any one of claims 1 to 10.

Images