Configuration method and device of one-time programmable memory, equipment and storage medium
By loading a trusted operating system into electronic devices and activating the trusted board boot function, the one-time programmable memory is configured automatically, solving the problem of low configuration efficiency in traditional methods and achieving efficient and secure trusted boot.
Patent Information
- Application Number
- CN202511083857.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-08-01
- Publication Date
- 2025-11-14
AI Technical Summary
In mass production equipment, the configuration efficiency of one-time programmable memory in traditional methods is low, requiring operators to manually repeat the configuration, which cannot achieve automation.
When the trusted board boot function of an electronic device is not activated, an untrusted boot is performed using the initial firmware image to load a trusted operating system and activate the trusted board boot function using trusted applications. Fields in the one-time programmable memory are automatically configured, including setting the trusted boot flag and writing preset field values.
It enables automated configuration of one-time programmable memory in a secure trusted execution environment, activates trusted board boot function, improves configuration efficiency, eliminates the need for manual operation, and ensures the security and efficiency of trusted boot.
Smart Images
Figure CN120951336A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of trusted computing technology, and in particular to methods, apparatus, devices and storage media for configuring one-time programmable memories. Background Technology
[0002] With the development of trusted computing technology, trusted boot technology has emerged. Devices build their own trusted boot system based on their Trusted Board Boot (TBB) function and by using data configured in One-Time Programmable (OTP) memory to verify firmware step by step.
[0003] In traditional technology, one-time programmable memory is manually configured by operators. However, this method is very limited. In the case of mass production equipment, operators need to manually repeat the above configuration for each device, which inevitably leads to low configuration efficiency. Summary of the Invention
[0004] Therefore, it is necessary to provide a configuration method, apparatus, device, and storage medium for a one-time programmable memory that can improve configuration efficiency in response to the above-mentioned technical problems.
[0005] In a first aspect, this application provides a method for configuring a one-time programmable memory, comprising: If the trusted board boot function is not activated on the local end, an untrusted boot operation is performed based on the initial firmware image to load a trusted operating system in the trusted execution environment on the local end. Run trusted applications through the trusted operating system; Based on the trusted application, the trusted boot flag in the one-time programmable memory is set to activate the trusted board boot function, and the fields in the one-time programmable memory are configured according to preset field values to obtain the configured fields; Wherein, after the trusted board boot function is activated, the configured fields are used to verify the trusted firmware image of the local end in order to build the trusted boot of the local end.
[0006] Secondly, this application also provides a configuration device for a one-time programmable memory, comprising: The startup module is used to perform an untrusted boot operation based on the initial firmware image when the trusted board boot function on the local end is not activated, so as to load a trusted operating system in the trusted execution environment on the local end. A configuration module is used to run trusted applications through the trusted operating system; based on the trusted application, it sets the trusted boot flag in the one-time programmable memory to activate the trusted board boot function, and configures the fields in the one-time programmable memory according to preset field values to obtain the configured fields; wherein, after the trusted board boot function is activated, the configured fields are used to verify the trusted firmware image of the local end to build the trusted boot of the local end.
[0007] Thirdly, this application also provides an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method.
[0008] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps in the above-described method.
[0009] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps in the above-described method.
[0010] The aforementioned configuration method, apparatus, device, and storage medium for one-time programmable memories cannot establish a trusted boot process on the local end if the trusted board boot function is not activated. In this case, an untrusted boot operation is performed based on the initial firmware image to load a trusted operating system within the trusted execution environment on the local end. The hardware isolation of the trusted execution environment ensures the security of the internal operations of the trusted operating system. Trusted applications are run through the trusted operating system. Based on the trusted applications, the trusted boot flag in the one-time programmable memory is set to activate the trusted board boot function. Fields in the one-time programmable memory are configured according to preset field values to obtain the configured fields, enabling automated configuration of the one-time programmable memory within a secure trusted execution environment. Furthermore, after the trusted board boot function is activated, the configured fields are used to verify the trusted firmware image on the local end to achieve trusted boot. By automatically configuring the one-time programmable memory within a secure trusted execution environment, activating the trusted board boot function, and configuring the preset field values required for trusted boot, a trusted boot can be established on the local end without requiring manual configuration of the one-time programmable memory, significantly improving the configuration efficiency of the one-time programmable memory. Attached Figure Description
[0011] Figure 1 This is a flowchart illustrating a method for configuring a one-time programmable memory, as provided in an embodiment of this application.
[0012] Figure 2This is a simplified flowchart illustrating a method for configuring a one-time programmable memory, as provided in an embodiment of this application.
[0013] Figure 3 This is a structural block diagram of a configuration device for a one-time programmable memory provided in an embodiment of this application.
[0014] Figure 4 This is an internal structural diagram of an electronic device provided in an embodiment of this application.
[0015] Figure 5 This is an internal structure diagram of another electronic device provided in an embodiment of this application. Detailed Implementation
[0016] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.
[0017] In one exemplary embodiment, such as Figure 1 The diagram shows a flowchart of a method for configuring a one-time programmable memory. Taking the application of this method to an electronic device as an example, the method includes the following steps 102 to 106.
[0018] Step 102: If the trusted board boot function is not activated on the local end, perform an untrusted boot operation based on the initial firmware image to load a trusted operating system in the trusted execution environment on the local end.
[0019] Trusted Board Boot (TBB) is a standardized technical solution for achieving trusted boot on the architecture platform provided by chip manufacturers. TBB verifies all firmware images to prevent the execution of malicious firmware, specifically by establishing a Chain of Trust (CoT). The Chain of Trust starts from the Root of Trust (RoT) embedded in the hardware and verifies the bootloader, operating system kernel, and other critical components at each stage, forming a complete security protection mechanism. Untrusted boot operations refer to booting without verifying the firmware image. A Trusted Execution Environment (TEE) is a secure execution zone created within the processor using hardware-level security isolation technology. A Trusted Execution Environment Operating System (TEE-OS) is a secure operating system running within the TEE, used to handle sensitive computing tasks. One-Time Programmable (OTP) memory is a non-volatile memory that is programmable only once, achieving permanent storage through fuse or antifuse physical structures; data written to it cannot be modified irreversibly.
[0020] For example, if the trusted boot flag in the one-time programmable memory is not set, it indicates that the trusted board boot function on this end is not activated. In this case, the electronic device can perform an untrusted boot operation based on the initial firmware image in the boot partition. During the untrusted boot operation, a trusted operating system is loaded in the trusted execution environment on this end. It can be understood that the difference between untrusted and trusted boot operations may include whether or not firmware image signature verification is performed. Since firmware image signature verification is not required during untrusted boot operations, the initial firmware image can be an unsigned firmware image, and correspondingly, the trusted firmware image can be a signed firmware image.
[0021] In some embodiments, the electronic device can perform an untrusted boot operation based on the initial firmware image even when the trusted board boot function is not activated on the local end. This allows it to load a trusted operating system in the local trusted execution environment and a general-purpose operating system in the local rich execution environment (REE). The rich execution environment is isolated from the trusted execution environment and is a non-secure execution environment used to handle most routine tasks. The general-purpose operating system is built on a simplified Linux kernel and file system, primarily used for firmware flashing and upgrades on the production line, automated hardware testing before shipment, and enabling the trusted board boot function. It is understood that, due to hardware isolation limitations, the general-purpose operating system cannot access one-time programmable memory.
[0022] In some embodiments, hardware-level security isolation technology may be, but is not limited to, TrustZone technology. A trusted execution environment can be a secure world partitioned within the processor using TrustZone technology. A rich execution environment can be a normal world partitioned within the processor using TrustZone technology.
[0023] In some embodiments, the initial firmware image may include at least one of the following: Boot Loader Stage 2 (BL2), Boot Loader Stage 3-1 (BL31), Boot Loader Stage 3-2 (BL32), and Boot Loader Stage 3-3 (BL33). BL2 is responsible for initializing the hardware and loading the firmware images for subsequent stages, namely BL31, BL32, and BL33. During trusted boot operations, BL2 is also responsible for verifying the signatures of BL31, BL32, and BL33. BL31 acts as a secure monitor, managing the switching between the trusted execution environment and the rich execution environment. BL32 acts as a trusted operating system. BL33 acts as the bootloader for the rich execution environment, responsible for loading the general-purpose operating system.
[0024] In some embodiments, the electronic device may perform an untrusted boot operation based on the initial firmware image, following the boot process of the Trusted Firmware-A (TF-A) architecture.
[0025] In some embodiments, the general-purpose operating system may be, but is not limited to, a recovery system.
[0026] Step 104: Run trusted applications through a trusted operating system.
[0027] Trusted Application (TA) refers to a secure application that runs in a trusted execution environment.
[0028] For example, during an untrusted boot operation, a trusted operating system is first loaded in a trusted execution environment, and then a general-purpose operating system is loaded in a rich execution environment. Therefore, after the untrusted boot operation is completed, the electronic device is in a rich execution environment. The electronic device can switch from the rich execution environment to the trusted execution environment after the untrusted boot operation is completed, and run trusted applications through the trusted execution environment.
[0029] In some embodiments, an electronic device can load a trusted operating system in a trusted execution environment during an untrusted boot process, and then run trusted applications through the trusted operating system.
[0030] Step 106: Based on trusted applications, set the trusted boot flag in the one-time programmable memory to activate the trusted board boot function, and configure the fields in the one-time programmable memory according to the preset field values to obtain the configured fields; wherein, after the trusted board boot function is activated, the configured fields are used to verify the trusted firmware image of the local end to build the trusted boot of the local end.
[0031] It is understandable that once the trusted board boot function is activated, it will trigger the electronic device to use a trusted boot operation to start the device. During the trusted boot operation, the electronic device will retrieve preset field values from the configured fields, and then use the preset field values to verify the trusted firmware image, thereby realizing the construction of a trusted boot.
[0032] For example, the One-Time Programmable Secure Boot Enable (OTPSECBTEN) flag is an enable bit used to activate the trusted board boot function. The electronic device can, based on a trusted application, perform a fuse operation on the trusted boot flag in the one-time programmable memory to set the trusted boot flag, thereby activating the trusted board boot function.
[0033] The fields in the one-time programmable memory are predefined configuration items. Fields may include a public key hash field. Preset field values may include the root of trust public key hash (ROTPKHASH). Electronic devices can write the root of trust public key hash to the public key hash field based on a trusted application, thus obtaining the configured public key hash field. Specifically, after the trusted board boot function is activated, the root of trust public key hash under the public key hash field is used to verify the signature of the trusted firmware image on the local device, thereby constructing a trusted boot on the local device. It can be understood that during the trusted boot operation, the electronic device can obtain the root of trust public key hash from the public key hash field in the one-time programmable memory, and then verify the signature of the trusted firmware image based on the root of trust public key hash.
[0034] The above-described configuration method for one-time programmable memory (IPM) cannot establish a trusted boot process if the trusted board boot function is not activated on the local end. In this case, an untrusted boot operation is performed based on the initial firmware image to load a trusted operating system within the trusted execution environment on the local end. The hardware isolation of the trusted execution environment ensures the security of the internal operations of the trusted operating system. Trusted applications are run through the trusted operating system. Based on these applications, the trusted boot flag in the IPM is set to activate the trusted board boot function. Fields in the IPM are configured according to preset field values, resulting in the configured fields. This allows for automated configuration of the IPM in a secure trusted execution environment. Furthermore, after the trusted board boot function is activated, the configured fields are used to verify the trusted firmware image on the local end, thus achieving a trusted boot. By automatically configuring the IPM in a secure trusted execution environment, activating the trusted board boot function, and configuring the preset field values required for trusted boot, a trusted boot can be established on the local end without requiring manual configuration of the IPM, significantly improving the configuration efficiency of the IPM.
[0035] In some embodiments, performing an untrusted boot operation based on an initial firmware image to load a trusted operating system in a trusted execution environment on the local end includes: performing an untrusted boot operation based on an initial firmware image to load a trusted operating system in a trusted execution environment on the local end, and loading a general-purpose operating system in a rich execution environment on the local end; running a trusted application through the trusted operating system includes: running a client application through the general-purpose operating system; establishing shared memory between the client application and the trusted execution environment based on the client application calling the client interface provided by the trusted execution environment, and writing trusted boot enable data to the shared memory; obtaining trusted boot enable data from the shared memory through the trusted operating system, and running a trusted application that matches the trusted boot enable data.
[0036] The Trusted Execution Environment (TEE) Client API is one of the external interfaces of the TEE. It's a programming interface for client applications within the TEE, providing a standardized way for them to request services from trusted applications within the TEE. The core functionality of the client interface includes managing shared memory allocation. The client interface can pass the physical address data of shared memory to the trusted operating system within the TEE, allowing the trusted operating system to establish a corresponding virtual address mapping based on this physical address data, thus obtaining virtual addresses accessible to the trusted application. Trusted boot enable data is used to request the trusted application to enable trusted boot. This can be understood as the trusted application enabling trusted boot by configuring one-time programmable memory.
[0037] For example, an electronic device can perform an untrusted boot operation based on an initial firmware image. During the untrusted boot process, a security monitor is loaded, a trusted operating system is loaded in the trusted execution environment on the local end based on the security monitor, and a general-purpose operating system is loaded in the rich execution environment on the local end. Upon receiving a trusted boot build command issued by a host computer, the client application runs through the general-purpose operating system.
[0038] The client application invokes the client interface provided by the trusted execution environment (TEE) to initiate a trusted boot enable request. This instructs the client interface to interact with the kernel driver, causing the kernel driver to allocate shared memory and write the trusted boot enable data carried in the trusted boot enable request to the shared memory. The kernel driver then initiates a SecureMonitor Call (SMC) instruction to instruct the security monitor to switch the processor from the rich execution environment (REA) state to the trusted execution environment (TEE) state and pass the physical address data of the shared memory to the trusted operating system (OS). The OS retrieves the trusted boot enable data from the shared memory based on the physical address data. The trusted boot enable data may include the identifier of the trusted application. The trusted application corresponding to this identifier is then run by the trusted OS. It is understood that in application software design, multiple identifier schemes are available; for example, the identifier can be, but is not limited to, a Universally Unique Identifier (UUID).
[0039] In some embodiments, the client interface can be the standard interface of the OP-TEE client library libteec. The kernel driver can be the OP-TEE driver in the Linux kernel. The trusted operating system can be the OP-TEE OS. The client interface can translate the trusted boot enable request into an ioctl system call to the / dev / teeprivX device file. Then, the OP-TEE driver in the Linux kernel processes the ioctl system call, triggers an environment switch via the SMC instruction, and passes the trusted boot enable data carried in the trusted boot enable request to the OP-TEE OS. The OP-TEE OS loads and verifies the corresponding trusted application based on the UUID, realizes data exchange between the client application and the trusted application through a shared memory mechanism, and finally, the trusted application performs configuration operations on the one-time programmable memory in the trusted execution environment and returns the configuration status data to the client application. The / dev / teeprivX device file is a virtual character device created by the OPTEE driver in the Linux kernel, used to realize physical memory mapping between the client and the trusted execution environment through shared memory. It is understandable that the client interface will instruct the OPTEE driver in the Linux kernel to allocate shared memory in the Direct Memory Access (DMA) protected area by calling the device file interface, and pass the physical address data of the shared memory to OP-TEEOS through the SMC instruction. The OP-TEE OS will then map it into virtual address data that can be accessed by trusted applications in the trusted execution environment.
[0040] In this embodiment, an untrusted boot operation is performed based on the initial firmware image to load a trusted operating system in the trusted execution environment on the local end, and a general operating system in the rich execution environment on the local end. The client application runs through the general operating system. Based on the client application calling the client interface provided by the trusted execution environment, a shared memory is established between the client application and the trusted execution environment, and trusted boot enable data is written to the shared memory. The trusted operating system obtains trusted boot enable data from the shared memory and runs a trusted application that matches the trusted boot enable data. After the untrusted boot operation, the client application can instruct the trusted operating system to run the corresponding trusted application to realize the configuration of the one-time programmable memory, thereby constructing trusted boot on the local end. No manual configuration by the operator is required, which improves the configuration efficiency.
[0041] In some embodiments, after configuring the fields in the one-time programmable memory according to preset field values to obtain the configured fields, the method further includes: writing configuration state data to shared memory based on a trusted application; obtaining configuration state data from shared memory based on a client application, and if the configuration state data indicates successful configuration, obtaining a trusted firmware image from the directory of the general operating system, and writing the trusted firmware image to the boot partition where the initial firmware image is located.
[0042] Among them, the configuration status data is data that characterizes the configuration status of the one-time programmable memory.
[0043] For example, an electronic device can, based on a trusted application, write configuration state data to shared memory after the configuration of the one-time programmable memory is complete. It then switches from a trusted execution environment to a rich execution environment. The client application accesses the shared memory to retrieve the configuration state data. The electronic device includes embedded memory, and the boot partition containing the initial firmware image is located within the embedded memory. Based on the client application, if the configuration state data indicates successful configuration, the trusted firmware image is retrieved from the directory of the general operating system and written to the boot partition of the embedded memory.
[0044] In some embodiments, the electronic device may, based on a client application, delete the initial firmware image in the boot partition if the configuration status data indicates successful configuration.
[0045] In this embodiment, configuration status data is written to shared memory based on a trusted application; configuration status data is obtained from shared memory based on a client application, and if the configuration status data indicates successful configuration, a trusted firmware image is obtained from the directory of the general operating system and written to the boot partition where the initial firmware image is located. This allows the trusted firmware image to be written to the boot partition after the one-time programmable memory is successfully configured, enabling the local end to verify the trusted firmware image based on the configured fields. Trusted boot can be built without manual configuration by operators, thus improving configuration efficiency.
[0046] In some embodiments, running a client application through a general-purpose operating system includes: obtaining a trusted boot build command issued by a host computer; and running the client application through the general-purpose operating system in response to the trusted boot build command. The method further includes: based on the client application, sending an error code to the host computer in the event that the configuration status data indicates a configuration failure, to instruct the host computer to display information indicating that the trusted boot build has failed.
[0047] In some embodiments, the configuration of the one-time programmable memory is part of the factory testing process. The factory test program runs on a host computer. The host computer can be connected to the electronic device via a network cable and communicate based on the Transmission Control Protocol (TCP). The host computer can send a trusted boot build command to the electronic device based on the factory test program.
[0048] In some embodiments, the electronic device may send a success status code to the host computer after the trusted firmware image is written to the boot partition, based on a client application.
[0049] In some embodiments, the host computer can display information about a failed trusted startup build on the interface.
[0050] In this embodiment, a trusted boot build command issued by the host computer is obtained; in response to the trusted boot build command, a client application is run through a general operating system; based on the client application, if the configuration status data indicates a configuration failure, an error code is sent to the host computer to instruct the host computer to display the trusted boot build failure information, which can promptly remind technicians of the configuration status of the one-time programmable memory and ensure the configuration effect of the one-time programmable memory.
[0051] In some embodiments, the electronic device may include at least one of a terminal or a server.
[0052] In some embodiments, the method is applied to an embedded device; the embedded device includes an embedded memory; the method further includes: obtaining a trusted firmware image from the boot partition of the embedded memory; and, if the trusted board boot function is activated on the local end, performing a trusted boot operation based on the configured fields and the trusted firmware image.
[0053] Embedded memory is a flash memory chip with an integrated controller, designed specifically for embedded devices that require compact, reliable, and low-cost storage. Embedded memory can be, but is not limited to, embedded multimedia cards (eMMC).
[0054] For example, the electronic device may be an embedded device. The embedded device boots in eMMC boot mode, ensuring that the firmware image in the eMMC is loaded first after the embedded device is powered on. The eMMC may include a boot partition and a recovery partition. During the device production phase, an unencrypted and unsigned initial firmware image is pre-burned to the boot partition, and a general operating system image is pre-burned to the recovery partition.
[0055] After the embedded device powers on, it retrieves the target firmware image from the boot partition of the embedded memory. The target firmware image includes at least one of an initial firmware image or a trusted firmware image. If the trusted board boot function is not activated, an untrusted boot operation is performed based on the initial firmware image. If the trusted board boot function is activated, preset field values are retrieved from the configured fields, and a trusted boot operation is performed based on the preset field values and the trusted firmware image.
[0056] In this embodiment, it is applied to an embedded device; the embedded device includes an embedded memory; a trusted firmware image is obtained from the boot partition of the embedded memory; when the trusted board boot function is activated on the local end, a trusted boot operation is performed based on preset field values and the trusted firmware image, which can complete the construction of trusted boot without manual configuration by the operator, thus improving configuration efficiency.
[0057] In some embodiments, the trusted execution environment is an execution environment partitioned from the security chip using hardware-level system isolation technology; the method further includes: obtaining security identification data for uniquely identifying the security chip; writing the security identification data to a one-time programmable memory based on a trusted application; wherein, during local operation, if the current identification data read from the one-time programmable memory is not security identification data, the local operation is interrupted.
[0058] In some embodiments, electronic devices can create security identification data (Security ID) for a security chip by calling an interface provided by a chip manufacturer based on a trusted application.
[0059] In some embodiments, the electronic device may read current identification data from a one-time programmable memory before performing a trusted boot operation. If the current identification data is not security identification data, the operation is interrupted.
[0060] In this embodiment, security identification data for uniquely identifying the security chip is obtained; the security identification data is written to a one-time programmable memory based on a trusted application; wherein, during the operation of the local device, if the current identification data read from the one-time programmable memory is not the security identification data, the operation of the local device is interrupted, which can resist attacks from counterfeit devices, such as chip replacement, and ensure security.
[0061] In some embodiments, the trusted firmware image is an encrypted firmware image; preset field values include a root trust public key hash value and a decryption key; fields include a public key hash field and a key field; the fields in the one-time programmable memory are configured according to the preset field values to obtain the configured fields, including: writing the root trust public key hash value under the public key hash field to obtain the configured public key hash field, and writing the decryption key under the key field to obtain the configured key field; wherein, after the trusted board boot function is activated, the configured public key hash field is used for signature verification of the trusted firmware image, and the configured key field is used to decrypt the trusted firmware image after the signature verification of the trusted firmware image is passed, so as to build the trusted boot of the local end.
[0062] In some embodiments, during the trusted boot process, the electronic device can obtain the root trust key hash value from the public key hash field in the one-time programmable memory, and perform signature verification on the trusted firmware image based on the root trust key hash value. Then, it can obtain the decryption key (DECRYPTKEY) from the key field in the one-time programmable memory, and decrypt the signed trusted firmware image based on the decryption key to obtain executable code.
[0063] In some embodiments, the root trust public key hash is used to verify the root trust public key that signs BL2. The verified root trust public key is used to verify the BL2 signature. It is understood that if the root trust public key fails verification, the entire trusted startup will abort.
[0064] In some embodiments, the trusted firmware image can be a signed and encrypted initial firmware image. The development server can sign and encrypt the initial firmware image to obtain the trusted firmware image.
[0065] In some embodiments, the development server can burn the initial firmware image, the trusted firmware image, and the image of the general operating system into the embedded memory during the device production stage.
[0066] In this embodiment, the trusted firmware image is an encrypted firmware image; the preset field values include the root trust public key hash value and the decryption key; the fields include a public key hash field and a key field; the root trust public key hash value is written under the public key hash field to obtain the configured public key hash field, and the decryption key is written under the key field to obtain the configured key field; wherein, after the trusted board boot function is activated, the configured public key hash field is used for signature verification of the trusted firmware image, and the configured key field is used to decrypt the trusted firmware image after the signature verification of the trusted firmware image is passed, so as to build the trusted boot on the local end. Trusted boot can be built without manual configuration by the operator, which improves configuration efficiency. Moreover, the trusted firmware image is encrypted, which can ensure the security of the firmware image during the trusted boot process and prevent the firmware image from being cracked by external parties.
[0067] In some embodiments, such as Figure 2 The diagram illustrates a simplified flowchart of the configuration method for a one-time programmable memory (PMMC). First, the eMMC boot mode is selected for the embedded device, ensuring that the firmware image in the eMMC is loaded first upon power-up. After power-up, the embedded device performs an untrusted boot operation based on the firmware image in the eMMC. This untrusted boot operation includes loading a trusted operating system in a trusted execution environment (TEA) and loading a general-purpose operating system in a rich execution environment (REE). After the untrusted boot operation is complete, the general-purpose operating system is entered. Upon receiving the trusted boot build command, the client application runs through the general-purpose operating system. The client application calls the client interface provided by the TEA to establish shared memory between the client application and the TEA, and trusted boot enable data is written to the shared memory. The trusted operating system retrieves trusted boot enable data from the shared memory and runs the trusted application based on the identifier in the trusted boot enable data. Based on the trusted application, security identification data, the hash value of the trust root public key, and the decryption key are written to the PMMC, and the trusted boot flag is enabled, thus enabling the trusted board boot function. Once the trusted board boot function is enabled, the hash value of the root trust public key in the one-time programmable memory is used to verify the signature of the trusted firmware image on the local end, and the decryption key in the one-time programmable memory is used to decrypt the trusted firmware image after the signature verification of the trusted firmware image is passed, so as to build a trusted boot for the embedded device.
[0068] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.
[0069] Based on the same inventive concept, this application also provides a configuration apparatus for a one-time programmable memory (IPM) to implement the configuration method of the one-time programmable memory described above. The solution provided by this apparatus is similar to the implementation described in the above method. Therefore, the specific limitations in one or more configuration apparatus embodiments of the one-time programmable memory provided below can be found in the limitations of the configuration method of the one-time programmable memory described above, and will not be repeated here.
[0070] In one exemplary embodiment, such as Figure 3 As shown, a configuration device 300 for a one-time programmable memory is provided, including a startup module 302 and a configuration module 304.
[0071] The boot module 302 is used to perform an untrusted boot operation based on the initial firmware image when the trusted board boot function on the local end is not activated, so as to load a trusted operating system in the trusted execution environment on the local end.
[0072] The configuration module 304 is used to run trusted applications through a trusted operating system. Based on the trusted application, the trusted boot flag in the one-time programmable memory is set to activate the trusted board boot function, and the fields in the one-time programmable memory are configured according to preset field values to obtain the configured fields. After the trusted board boot function is activated, the configured fields are used to verify the trusted firmware image of the local end to build the trusted boot of the local end.
[0073] In some embodiments, the boot module 302 is used to perform an untrusted boot operation based on the initial firmware image to load a trusted operating system in the trusted execution environment on the local end and a general operating system in the rich execution environment on the local end; the configuration module 304 is used to run a client application through the general operating system; establish shared memory between the client application and the trusted execution environment based on the client interface provided by the trusted execution environment called by the client application, and write trusted boot enable data to the shared memory; obtain trusted boot enable data from the shared memory through the trusted operating system, and run a trusted application that matches the trusted boot enable data.
[0074] In some embodiments, the configuration module 304 is used to write configuration status data to shared memory based on a trusted application; to obtain configuration status data from shared memory based on a client application; and, if the configuration status data indicates successful configuration, to obtain a trusted firmware image from the directory of the general operating system and write the trusted firmware image to the boot partition where the initial firmware image is located.
[0075] In some embodiments, the configuration module 304 is configured to obtain a trusted startup build command issued by the host computer; in response to the trusted startup build command, run a client application through a general operating system; and based on the client application, send an error code to the host computer in the event that the configuration status data indicates a configuration failure, so as to instruct the host computer to display information indicating that the trusted startup build has failed.
[0076] In some embodiments, the boot module 302 is used to obtain a trusted firmware image from the boot partition of the embedded memory; and when the trusted board boot function is activated on the local end, to perform a trusted boot operation based on the configured fields and the trusted firmware image.
[0077] In some embodiments, the trusted execution environment is an execution environment partitioned from the security chip using hardware-level system isolation technology; the configuration module 304 is used to obtain security identification data for uniquely identifying the security chip; and write the security identification data to a one-time programmable memory based on a trusted application; wherein, during the local operation, if the current identification data read from the one-time programmable memory is not the security identification data, the local operation is interrupted.
[0078] In some embodiments, the trusted firmware image is an encrypted firmware image; the preset field values include the root trust public key hash value and the decryption key; the fields include a public key hash field and a key field; the configuration module 304 is used to write the root trust public key hash value under the public key hash field to obtain the configured public key hash field, and write the decryption key under the key field to obtain the configured key field; wherein, after the trusted board boot function is activated, the configured public key hash field is used for signature verification of the trusted firmware image, and the configured key field is used to decrypt the trusted firmware image after the signature verification of the trusted firmware image is passed, so as to build the trusted boot of the local end.
[0079] Each module in the aforementioned one-time programmable memory configuration device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in hardware within or independently of the processor in the electronic device, or stored in software within the memory of the electronic device, so that the processor can call and execute the operations corresponding to each module.
[0080] In one exemplary embodiment, an electronic device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 4 As shown, this electronic device includes a processor, memory, input / output (I / O) interfaces, and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements a one-time programmable memory configuration method.
[0081] In one exemplary embodiment, an electronic device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 5As shown, this electronic device includes a processor, memory, input / output interface, communication interface, display unit, and input device. The processor, memory, and input / output interface are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interface. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The input / output interface is used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, NFC (Near Field Communication), or other technologies. When the computer program is executed by the processor, it implements a one-time programmable memory configuration method. The display unit is used to form a visually visible image and can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the electronic device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the electronic device, or external keyboards, touchpads, or mice, etc.
[0082] Those skilled in the art will understand that Figure 4 or Figure 5 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the electronic device to which the present application is applied. The specific electronic device may include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements.
[0083] In one embodiment, an electronic device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.
[0084] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above method embodiments.
[0085] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.
[0086] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.
[0087] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.
[0088] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.
Claims
1. A method for configuring a one-time programmable memory, characterized in that, The method includes: If the trusted board boot function is not activated on the local end, an untrusted boot operation is performed based on the initial firmware image to load a trusted operating system in the trusted execution environment on the local end. Run trusted applications through the trusted operating system; Based on the trusted application, the trusted boot flag in the one-time programmable memory is set to activate the trusted board boot function, and the fields in the one-time programmable memory are configured according to preset field values to obtain the configured fields; Wherein, after the trusted board boot function is activated, the configured fields are used to verify the trusted firmware image of the local end in order to build the trusted boot of the local end.
2. The method according to claim 1, characterized in that, The untrusted boot operation based on the initial firmware image to load a trusted operating system in the trusted execution environment on the local end includes: Untrusted boot operations are performed based on the initial firmware image to load a trusted operating system in the trusted execution environment on the local end, and a general operating system in the rich execution environment on the local end. Running trusted applications through the trusted operating system includes: The client application runs through the aforementioned general-purpose operating system; Based on the client application calling the client interface provided by the trusted execution environment, a shared memory is established between the client application and the trusted execution environment, and trusted boot enable data is written to the shared memory; The trusted operating system obtains the trusted boot enable data from the shared memory and runs a trusted application that matches the trusted boot enable data.
3. The method according to claim 2, characterized in that, After configuring the fields in the one-time programmable memory according to preset field values to obtain the configured fields, the process further includes: The trusted application writes the configuration status data into the shared memory. Based on the client application, the configuration status data is obtained from the shared memory. If the configuration status data indicates successful configuration, the trusted firmware image is obtained from the directory of the general operating system and written to the boot partition where the initial firmware image is located.
4. The method according to claim 3, characterized in that, The process of running the client application through the general-purpose operating system includes: Obtain the trusted startup build command issued by the host computer; In response to the trusted startup build command, the client application is run through the general operating system; The method further includes: Based on the client application, in the event that the configuration status data indicates a configuration failure, an error code is sent to the host computer to instruct the host computer to display information indicating that the trusted startup build has failed.
5. The method according to claim 3, characterized in that, Applied to embedded devices; The embedded device includes an embedded memory; The method further includes: Obtain the trusted firmware image from the boot partition of the embedded memory; When the trusted board boot function is activated, a trusted boot operation is performed based on the configured fields and the trusted firmware image.
6. The method according to claim 1, characterized in that, The trusted execution environment is an execution environment partitioned from the security chip using hardware-level system isolation technology; The method further includes: Obtain security identification data used to uniquely identify the security chip; The security identification data is written to the one-time programmable memory based on the trusted application. If, during the operation of this terminal, the current identification data read from the one-time programmable memory is not the security identification data, the operation of this terminal will be interrupted.
7. The method according to any one of claims 1 to 6, characterized in that, The trusted firmware image is an encrypted firmware image; the preset field values include the root trust public key hash value and the decryption key; the fields include a public key hash field and a key field; The step of configuring the fields in the one-time programmable memory according to preset field values to obtain the configured fields includes: Write the root trust public key hash value into the public key hash field to obtain the configured public key hash field, and write the decryption key into the key field to obtain the configured key field; Wherein, after the trusted board boot function is activated, the configured public key hash field is used to verify the signature of the trusted firmware image, and the configured key field is used to decrypt the trusted firmware image after the signature verification of the trusted firmware image is passed, so as to build the trusted boot of the local end.
8. A configuration device for a one-time programmable memory, characterized in that, The device includes: The startup module is used to perform an untrusted boot operation based on the initial firmware image when the trusted board boot function on the local end is not activated, so as to load a trusted operating system in the trusted execution environment on the local end. A configuration module is used to run trusted applications through the trusted operating system; based on the trusted application, it sets the trusted boot flag in the one-time programmable memory to activate the trusted board boot function, and configures the fields in the one-time programmable memory according to preset field values to obtain the configured fields; wherein, after the trusted board boot function is activated, the configured fields are used to verify the trusted firmware image of the local end to build the trusted boot of the local end.
9. An electronic device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.
10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.