Key management method and embedded device

Abstract

The embodiment of the present disclosure provides a key management method and an embedded device. It relates to the technical field of embedded technology. The method comprises the following steps: after the operating system of the embedded device is started, the block device identifier corresponding to the secure storage partition of the embedded device and the mapping device identifier corresponding to the block device indicated by the block device identifier are obtained; if the acquisition is successful, the unique hardware identifier of the embedded device is obtained; the derived key is generated based on the unique hardware identifier, the secure storage partition is decrypted based on the derived key, and the file system stored in the secure storage partition is obtained; and the file system is mounted into the mapping device indicated by the mapping device identifier. The method generates a derived key based on the unique hardware identifier of the device, realizes the decryption of the secure storage partition, and thus improves the security and tamper-proofing capability of the key management of the secure storage partition of the embedded device without increasing the cost of additional security chips.

Description

Technical Field

[0001] This disclosure relates to the field of embedded technology, and more particularly to a key management method and an embedded device. Background Technology

[0002] Embedded devices are widely used in industrial control, the Internet of Things (IoT), consumer electronics, automotive electronics, and smart terminals. Their secure storage partitions are used to store sensitive information such as serial numbers, production line keys, calibration data, encryption certificates, and user privacy data. The encryption mechanism of the secure storage partition is a core element in ensuring device security, especially in scenarios involving device authentication, anti-cloning, data tamper-proofing, and compliance requirements. The key management of the secure storage partition directly affects the security level of the device.

[0003] In related technologies, encryption keys for secure storage partitions are typically generated in software and stored in ordinary storage areas, or managed by external security chips. Software-generated keys are vulnerable to reverse engineering or memory sniffing attacks; while external security chip solutions offer higher security, they increase device costs and design complexity, and the key transmission process still carries the risk of interception.

[0004] Therefore, the encryption key management of secure storage partitions in related technologies suffers from problems such as easy key leakage and low security, resulting in a reduction in the overall security of the device. Summary of the Invention

[0005] This disclosure provides a key management method and an embedded device. By generating a derived key based on the device's unique hardware identifier, the method enables the decryption of secure storage partitions. This improves the security and tamper-proof capability of secure storage partition key management in embedded devices without increasing the cost of additional security chips.

[0006] In a first aspect, embodiments of this disclosure provide a key management method applied to an embedded device, the method comprising:

[0007] After the operating system of the embedded device starts, obtain the block device identifier corresponding to the secure storage partition of the embedded device, and the mapping device identifier corresponding to the block device indicated by the block device identifier;

[0008] If successful, the unique hardware identifier of the embedded device is obtained; the unique hardware identifier is an identifier that corresponds one-to-one with the embedded device and is written to a preset storage location during the initialization of the embedded device.

[0009] Based on the unique hardware identifier, a derived key is generated. Based on the derived key, the secure storage partition is decrypted to obtain the file system stored in the secure storage partition.

[0010] The file system is mounted to the mapping device indicated by the mapping device identifier; wherein the file system is used to store sensitive information of the embedded device, and the mapping device is used to provide a transparent encryption and decryption interface when accessing the file system.

[0011] After the operating system boots, by obtaining the block device identifier and mapped device identifier corresponding to the secure storage partition, automatic location and logical mapping of the encrypted partition are achieved. This accurately identifies the area to be decrypted without manual intervention, improving the automation and reliability of the operating system boot process. By obtaining the unique hardware identifier written during embedded device initialization, a strong binding relationship is established between the device identity and the decryption key, ensuring that only the original device can generate the correct key, effectively preventing attacks such as storage media removal, device cloning, or offline brute-force attacks. By dynamically generating derived keys based on the unique hardware identifier and decrypting the secure storage partition, runtime key generation and immediate use are achieved. The key is not persistently stored on any medium, completely eliminating the persistent risk of key leakage. This achieves a protection level comparable to hardware security modules without requiring additional security chips. By mounting the decrypted file system to the mapped device, a transparent encryption / decryption interface is provided to upper-layer applications. Applications can access sensitive data through the standard file system interface without needing to understand the underlying encryption / decryption details, significantly reducing the integration difficulty and development cost of security functions. In summary, this technical solution generates a derived key based on the device's unique hardware identifier to decrypt the secure storage partition, thereby improving the security and tamper-proof capability of the embedded device's secure storage partition key management without increasing the cost of additional security chips.

[0012] In one possible implementation, obtaining the block device identifier corresponding to the secure storage partition within the device includes:

[0013] The block device identifier corresponding to the secure storage partition is found based on the preset partition mapping table; or, the block device identifier corresponding to the secure storage partition is parsed from the kernel command-line parameters. The partition mapping table includes the correspondence between the partition identifier of the secure storage partition and the block device identifier of the block device; the kernel command-line parameters include the correspondence between the partition identifier of the secure storage partition and the block device identifier of the block device.

[0014] If the block device identifier is not obtained, the process of obtaining the unique hardware identifier and subsequent mounting steps will be stopped.

[0015] If a block device identifier is obtained, then the mapping device identifier corresponding to the block device indicated by the block device identifier is obtained.

[0016] Through the above steps, this embodiment achieves dynamic and reliable positioning of the secure storage partition during the startup process of the embedded device and provides an exception handling mechanism, effectively improving the stability and security of the embedded device.

[0017] In one possible implementation, obtaining the mapped device identifier corresponding to the block device indicated by the block device identifier includes:

[0018] In the preset partition mapping table, look up the mapping device identifier corresponding to the block device identifier; the partition mapping table includes the correspondence between block device identifiers and mapping device identifiers;

[0019] If the mapped device identifier is not obtained, a device construction prompt message is generated. The device construction prompt message is used to prompt the user to build a mapped device corresponding to the block device and generate a mapped device identifier corresponding to the mapped device.

[0020] Through the above steps, this embodiment provides an exception handling mechanism in the process of obtaining the mapping device identifier, avoiding device mounting failure or data access abnormalities caused by the absence of the mapping device, and further improving the robustness and user-friendliness of embedded devices in secure storage partition management.

[0021] In one possible implementation, the method further includes, before the operating system of the embedded device boots:

[0022] The identifier is read using a preset method, which includes at least one of the following: reading an identifier pre-programmed into a one-time programmable memory, reading an identifier pre-written into a trusted execution environment, or reading a preset identifier through a program interface;

[0023] The read identifier is used as the unique hardware identifier and written to the kernel command line parameters or non-volatile storage. After successfully obtaining the block device identifier corresponding to the secure storage partition of the embedded device, the unique hardware identifier of the embedded device is obtained based on the kernel command line parameters or non-volatile storage.

[0024] Through the above steps, this embodiment completes the reading and storage of the unique hardware identifier before the operating system starts, providing a reliable data source for the subsequent generation of derived keys based on this identifier. Furthermore, by employing multiple preset reading methods, this embodiment takes into account the security and compatibility of different hardware platforms, further improving the versatility and security of the key management method.

[0025] In one possible implementation, the unique hardware identifier of the embedded device is obtained based on kernel command-line arguments or non-volatile memory, including:

[0026] Parse kernel command-line arguments to obtain a unique hardware identifier from the kernel command-line arguments; or read the unique hardware identifier from non-volatile memory.

[0027] By obtaining a unique hardware identifier based on kernel command-line parameters, this embodiment achieves efficient acquisition of the unique hardware identifier during the operating system startup process, providing a convenient data source for generating derived keys based on the identifier, and further improving the execution efficiency and device compatibility of the key management method.

[0028] Furthermore, since the unique hardware identifier is read from the hardware source and written into the kernel command-line parameters by the bootloader before the operating system boots—a process that occurs before the operating system kernel and user-space software are loaded—it effectively prevents unauthorized access or tampering of the hardware interface by malware or kernel modules that may exist after the operating system boots. In addition, the kernel command-line parameters are verified and protected for integrity by the bootloader through a secure boot chain during the boot phase; any tampering with the parameter content will result in verification failure, thus preventing the device from booting. Therefore, attackers cannot forge or replace the unique hardware identifier in the kernel command-line parameters through software means, ensuring the authenticity and integrity of the identifier's source. This mechanism establishes a hardware root of trust from the earliest stage of device boot, providing an unforgeable and tamper-proof input basis for subsequently derived keys generated based on this identifier, thereby significantly enhancing the overall security of the key management method at the device boot level.

[0029] By reading a unique hardware identifier from non-volatile memory, the operating system does not need to rely on the kernel command-line parameter passing mechanism. This is suitable for scenarios where the bootloader does not support or cannot easily modify the kernel command-line parameters. It also makes it easy for the device to read the identifier multiple times during operation without repeatedly accessing the underlying hardware resources.

[0030] In one possible implementation, the method further includes:

[0031] If a unique hardware identifier is not obtained, the subsequent key generation and mounting steps will be stopped.

[0032] Through the aforementioned anomaly handling mechanism, this embodiment can avoid the risk that the device will generate an incorrect derived key based on an incorrect or missing identifier when the unique hardware identifier is missing or invalid. This could lead to the inability to correctly decrypt or access data in the secure storage partition, or even cause data corruption or security vulnerabilities. Simultaneously, by promptly stopping subsequent steps, the device can return a clear error status to the user or upper-layer application, facilitating rapid problem location and appropriate measures (such as reprogramming the identifier or checking the hardware configuration), thereby further improving the robustness and security of the key management method.

[0033] In one possible implementation, the unique hardware identifier includes at least one of the following: chip serial number, device MAC address, identifier burned into one-time programmable memory, key hash value stored in trusted execution environment, and board-level unique identifier.

[0034] The aforementioned identification information cannot be modified during the device's lifecycle and is strongly bound to the device's hardware circuitry or chip manufacturing process. Even if an attacker obtains all the data in the storage medium through software means, they cannot reproduce the identification on other devices. This ensures that the derived key is uniquely bound to a specific physical device, effectively preventing unauthorized decryption or access on other devices after the storage medium is removed. This enhances the security of key management methods and data storage from the hardware perspective.

[0035] In one possible implementation, a derived key is generated based on a unique hardware identifier, including:

[0036] The unique hardware identifier is passed to the trusted execution environment. A derived key is generated in the trusted execution environment based on the unique hardware identifier, and the derived key released by the trusted execution environment is obtained.

[0037] Through the above implementation method, this embodiment places the key derivation process in a trusted execution environment, which makes full use of the hardware isolation characteristics of the trusted execution environment, effectively preventing the unique hardware identifier and the derived key from being leaked or tampered with during the generation process, and enhancing the overall security of the key management method. It is especially suitable for embedded device scenarios with high requirements for data protection.

[0038] In one possible implementation, a derived key is generated based on a unique hardware identifier, including:

[0039] In the normal execution environment of the operating system, a derived key is generated based on a unique hardware identifier.

[0040] Because this derivation process is completed entirely within a normal execution environment, without needing to call trusted execution environment interfaces or rely on hardware security zones, it offers advantages such as simple implementation, high execution efficiency, and low device overhead. While ensuring basic security, it effectively reduces device complexity and development costs, further enhancing the applicability and flexibility of the key management method.

[0041] In one possible implementation, a derived key is generated based on a unique hardware identifier, including any of the following:

[0042] Use any one of the unique hardware identifiers directly as the derived key;

[0043] Combine at least two identifiers from the unique hardware identifier to form the derived key;

[0044] Using a preset key derivation function, encrypt at least one identifier from at least one unique hardware identifier to obtain the derived key.

[0045] This implementation method further simplifies the key generation process, avoiding the computational overhead and latency caused by key derivation operations, making it particularly suitable for performance-sensitive or resource-constrained embedded device scenarios. Furthermore, since the unique hardware identifier itself possesses device uniqueness and is not easily copied, directly using it as the derived key improves the execution efficiency and ease of implementation of the key management method while meeting basic security requirements.

[0046] By combining at least two identifiers to generate a derived key, the entropy and complexity of the derived key are effectively increased, reducing the risk of the key being cracked due to the leakage or predictability of a single identifier. Even if an attacker obtains one of the identifiers, they will still be unable to reconstruct the final derived key due to the lack of information on the combination of other identifiers, thereby enhancing the security of the key management method.

[0047] By using a pre-defined key derivation function to perform encryption operations on the unique hardware identifier to generate a derived key, a derived key strongly associated with the hardware can be generated, thereby effectively preventing the key from being illegally copied or moved to other devices and significantly improving the security of key storage and use.

[0048] In one possible implementation, based on the derived key, the secure storage partition is decrypted to obtain the file system stored within the secure storage partition, including:

[0049] Based on the derived key, the secure storage partition is decrypted using a preset decryption tool to obtain the file system within the secure storage partition.

[0050] This implementation method enables decryption access to secure storage partitions using keys derived from unique hardware identifiers, ensuring that only devices possessing the correct unique hardware identifier can decrypt and access the protected file system content. Furthermore, it prevents unauthorized reading of data on other devices after the storage medium has been removed, thereby significantly enhancing the security of sensitive data storage in embedded devices.

[0051] In one possible implementation, after the operating system of the embedded device has started, the method further includes:

[0052] Query the file system write status of all block device partitions within the embedded device;

[0053] If none of the block device partitions within the embedded device have been written to the file system, then the process of obtaining the unique hardware identifier and subsequent mounting steps will be stopped.

[0054] If it is found that any block device partition within the embedded device has been written to the file system and the block device partition is in an unencrypted state, then a unique hardware identifier is obtained, and the block device partition is encrypted using a derived key generated based on the unique hardware identifier. The encrypted block device partition is then used as a secure storage partition.

[0055] Based on the partition identifier of the secure storage partition and the block device identifier of the block device partition, a mapping relationship between the partition identifier of the secure storage partition and the block device identifier of the block device is constructed, and the mapping relationship is passed to a pre-made partition mapping table or written to the kernel command line parameters.

[0056] Through the above implementation methods, this embodiment achieves intelligent detection and differentiated processing of block device partition status before the operating system starts: for devices that have not been written to the file system, unnecessary processes are avoided. For partitions that have been written to the file system but are not encrypted, encryption initialization is automatically completed and partition mapping relationships are established. This mechanism ensures the correct initialization of secure storage partitions and the reliability of subsequent mounting processes, effectively improving the automation capabilities and security of embedded devices in first-time boot or recovery scenarios.

[0057] Secondly, embodiments of this disclosure provide a key management device, including:

[0058] The device identifier acquisition module is used to acquire, after the operating system of the embedded device starts, the block device identifier corresponding to the secure storage partition of the embedded device, and the mapped device identifier corresponding to the block device indicated by the block device identifier;

[0059] The unique hardware identifier acquisition module is used to acquire the unique hardware identifier of the embedded device if the acquisition is successful; wherein, the unique hardware identifier is an identifier that is written to a preset storage location during the initialization of the embedded device and corresponds one-to-one with the embedded device;

[0060] The key generation and decryption module is used to generate a derived key based on a unique hardware identifier, and to decrypt the secure storage partition based on the derived key in order to obtain the file system stored in the secure storage partition.

[0061] The file system mounting module is used to mount the file system to the mapping device indicated by the mapping device identifier; wherein the file system is used to store sensitive information of the embedded device, and the mapping device is used to provide a transparent encryption and decryption interface when accessing the file system.

[0062] Thirdly, embodiments of this disclosure provide an embedded device, including: a memory and a processor;

[0063] The memory stores the instructions that the computer executes;

[0064] The processor executes computer execution instructions stored in memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0065] Fourthly, embodiments of this disclosure provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0066] Fifthly, embodiments of this disclosure provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0067] The key management method and embedded device provided in this disclosure, after the operating system starts, achieve automatic location and logical mapping of the encrypted partition by obtaining the block device identifier and mapping device identifier corresponding to the secure storage partition. This accurately identifies the area to be decrypted without manual intervention, improving the automation and reliability of the operating system startup. By obtaining the unique hardware identifier written during embedded device initialization, a strong binding relationship is established between the device identity and the decryption key, ensuring that only the original device can generate the correct key, effectively preventing attacks such as storage media removal, device cloning, or offline brute-force attacks. By dynamically generating derived keys based on the unique hardware identifier and decrypting the secure storage partition, runtime key generation and immediate use are achieved. The key is not persistently stored on any medium, completely eliminating the persistent risk of key leakage. This achieves a protection level comparable to a hardware security module without requiring an additional security chip. By mounting the decrypted file system to the mapping device, a transparent encryption / decryption interface is provided to upper-layer applications. Applications can access sensitive data through the standard file system interface without needing to understand the underlying encryption / decryption details, significantly reducing the integration difficulty and development cost of security functions. In summary, this technical solution generates a derived key based on the device's unique hardware identifier to decrypt the secure storage partition, thereby improving the security and tamper-proof capability of the embedded device's secure storage partition key management without increasing the cost of additional security chips. Attached Figure Description

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

[0069] Figure 1 A diagram illustrating an application scenario of the key management method provided in this disclosure;

[0070] Figure 2 Flowchart of the key management method provided in this disclosure Figure 1 ;

[0071] Figure 3 Flowchart of the key management method provided in this disclosure Figure 2 ;

[0072] Figure 4 This is a schematic diagram of the key management device provided in this disclosure;

[0073] Figure 5 This is a schematic diagram of the structure of the embedded device provided in this disclosure.

[0074] The accompanying drawings have illustrated specific embodiments of this disclosure, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concepts of this disclosure to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0075] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0076] Embedded devices are widely used in industrial control, the Internet of Things (IoT), consumer electronics, automotive electronics, and smart terminals. Their secure storage partitions are used to store sensitive information such as serial numbers, production line keys, calibration data, encryption certificates, and user privacy data. The encryption mechanism of the secure storage partition is a core element in ensuring device security, especially in scenarios involving device authentication, anti-cloning, data tamper-proofing, and compliance requirements. The key management of the secure storage partition directly affects the security level of the device.

[0077] In related technologies, encryption keys for secure storage partitions are typically generated in software and stored in ordinary storage areas, or managed by external security chips. Software-generated keys are vulnerable to reverse engineering or memory sniffing attacks; while external security chip solutions offer higher security, they increase device costs and design complexity, and the key transmission process still carries the risk of interception.

[0078] Therefore, the encryption key management of secure storage partitions in related technologies suffers from problems such as easy key leakage and low security, resulting in a reduction in the overall security of the device.

[0079] To address the aforementioned technical problems, this disclosure provides a key management method. This method utilizes the unique hardware identifier inherent in the embedded device (such as a chip serial number) as a key root factor to dynamically derive a decryption key after the operating system starts, thereby solving the problems of easy leakage and low security of secure storage partition encryption keys in related technologies.

[0080] The solution first obtains the block device identifier of the secure storage partition and its corresponding mapped device identifier. Then, it extracts a unique hardware identifier, one-to-one with the device, from a preset storage location. Based on this hardware identifier, a derived key is generated using a key derivation function, existing only in runtime memory. This derived key is then used to decrypt the secure storage partition to obtain the file system, which is then mounted to the mapped device. This mapped device provides a transparent encryption / decryption interface for subsequent access. Because the derived key is strongly bound to the device hardware and is not persistently stored, attackers cannot obtain the key through reverse engineering, memory sniffing, or device cloning. Thus, high-security key management is achieved at low cost without the need for additional security chips, effectively preventing sensitive information leakage, device cloning, and data tampering.

[0081] The key management method provided in this disclosure is applicable to scenarios involving access control of the secure storage partition of an embedded device.

[0082] For example, in the scenario of protecting production line keys and sensitive data for industrial control equipment (such as programmable logic controllers (PLCs) and remote terminal units (RTUs), the equipment needs to automatically decrypt the storage partition after startup to obtain core configuration information, while preventing the key from being extracted in reverse and causing the equipment to be cloned or tampered with.

[0083] In addition, the above methods can also be applied to scenarios involving encrypted storage of user privacy data in IoT terminals (such as smart door locks and cameras), as well as to scenarios involving the protection of sensitive information such as encryption certificates and security credentials in automotive electronics (such as T-Boxes and domain controllers), ensuring that sensitive information can only be accessed on legitimate devices.

[0084] In summary, any scenario that requires dynamic decryption of secure storage partitions based on the unique identity of the device hardware, and requires that the key not be persistently stored to resist offline attacks and device cloning, falls under the application scenarios of the decryption technology solution in this disclosure.

[0085] The following is combined Figure 1 The application scenarios to which the embodiments of this disclosure apply are described. Figure 1 This is a diagram illustrating an application scenario of the key management method provided in this disclosure.

[0086] See Figure 1In any of the above scenarios, such as in an IoT terminal scenario, the key management method provided in this disclosure involves an IoT terminal, which is an embedded device. The IoT terminal integrates a secure storage partition for storing sensitive information such as device serial numbers, production line keys, encryption certificates, and user privacy data.

[0087] Based on this, the key management method provided in this disclosure may include the following: after the IoT terminal operating system starts, first obtain the block device identifier and its mapped device identifier corresponding to the secure storage partition; then extract the unique hardware identifier (such as the chip serial number) of the IoT terminal from the preset storage location; dynamically derive a decryption key based on the unique hardware identifier, and use the derived key to decrypt the secure storage partition to obtain the file system therein; mount the file system to the mapped device, which provides a virtual access interface during subsequent access, ensuring that sensitive information is always under encrypted protection during storage and retrieval.

[0088] The above describes how, by dynamically binding the decryption key to the device's unique hardware identifier without persistent storage, the system achieves the beneficial effect of protecting sensitive information of embedded devices at low cost and with high security without the need for additional security chips.

[0089] The technical solutions of this disclosure and how they solve the aforementioned technical problems will be described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of this disclosure will now be described with reference to the accompanying drawings.

[0090] Figure 2 Flowchart of the key management method provided in this disclosure Figure 1 This method can be executed by a key management device, which can be an embedded device, a processor within an embedded device, or other hardware modules with data processing capabilities (such as microcontrollers, digital signal processors, field-programmable gate arrays, etc.). The method in this embodiment can be implemented through software, hardware, or a combination of both. Figure 2 As shown, the method includes:

[0091] Step S201: After the operating system of the embedded device starts, obtain the block device identifier corresponding to the secure storage partition of the embedded device, and the mapping device identifier corresponding to the block device indicated by the block device identifier.

[0092] In this embodiment, the startup of the embedded device's operating system can be understood as the complete startup process from power-on or reset until the operating system kernel completes initialization and has the ability to execute user-space programs.

[0093] Specifically, the process can include three stages: The first is the bootloader stage, where the device executes ROM boot code after power-on, completes basic hardware initialization, loads and executes the bootloader (such as U-Boot), which loads the kernel image from the storage medium into memory and transfers control. The second is the operating system kernel startup stage, where the kernel executes initialization code, including decompressing the kernel, initializing core subsystems (such as the process scheduler and memory management), enumerating and initializing hardware devices, mounting the initial root file system, and registering block device identifiers. The third is the user space initialization stage, where the kernel starts the first user space process, executes the operating system initialization script, and starts services. During this stage, the key management method disclosed herein begins execution; that is, the operating system has device management and process scheduling capabilities, and can securely obtain block device identifiers and perform decryption and mounting operations.

[0094] It should be noted that the operating system startup in this embodiment does not require the operating system to fully enter the user interface or all services to be started. As long as the operating system kernel has completed hardware enumeration and device registration and has the ability to execute user-space programs, the operating system can be considered to have finished starting and begin to execute operations such as obtaining block device identifiers and performing decryption and mounting. This allows the decryption operation of the secure storage partition to be completed in the early stages of the operating system, so that the sensitive information file system is already in a usable state before subsequent system services start or applications run, avoiding service startup failures or data access delays caused by the file system not being ready.

[0095] Furthermore, in embedded devices involving a Trusted Execution Environment (TEE) or Secure Boot, the operating system boot process may also involve the initialization of the secure and insecure worlds. For example, in the ARM TrustZone architecture, the secure world kernel (such as the Open Portable Trusted Execution Environment (OP-TEE)) may boot before the normal world kernel, extracting the hardware unique identifier and generating the derived key in the secure world, and then passing the mapped device identifier to the normal world. This cross-world boot collaboration further enhances the security of key management.

[0096] After the operating system of the embedded device completes its boot process, the embedded device (hereinafter referred to as the device) can obtain the block device identifier corresponding to the secure storage partition through the pre-defined security service module within the kernel. This block device identifier is used to uniquely identify the encrypted partition carrying the file system in the physical storage medium, and it usually exists in the form of a device file path. For example, in the Linux operating system, it is represented as ` / dev / mmcblk0p2` (for the second partition of the embedded Multi Media Card (eMMC) storage), ` / dev / sda3` (for the third partition of the Serial Advanced Technology Attachment (SATA) hard drive), or ` / dev / mtdblock4` (for the fourth MTD partition of NAND Flash).

[0097] Simultaneously or subsequently, the device further acquires the mapping device identifier corresponding to the block device indicated by that block device identifier. The mapping device identifier typically points to a virtual block device created by a device mapper (such as the dm-crypt module in the Linux kernel), a logical volume manager (LVM), or a virtual block device driver, such as ` / dev / mapper / secure_partition`, ` / dev / dm-0`, or ` / dev / loop0`. This mapping device will be mounted as the access point for the file system in subsequent steps, providing a transparent encryption / decryption interface. That is, when an upper-layer application reads or writes to this mapping device, the underlying driver automatically performs the encryption and decryption operations without the application needing to be aware of or process the key.

[0098] It should be further explained that the acquisition methods for block device identifiers and mapped device identifiers can be flexibly configured according to the operating system type, storage architecture, and security policy of the embedded device. In some implementations, the acquisition methods may include, but are not limited to, the following: First, based on pre-configured static mapping, that is, the identifiers are predefined in the firmware or system configuration file, and the operating system reads them directly after startup, which is relatively simple to implement. Second, based on dynamic scanning and matching, that is, after the operating system starts, it traverses the block devices and automatically identifies the secure partitions and creates mapped devices based on preset identifiers such as partition universal unique identifiers and tags, which is highly flexible. Third, based on negotiation acquisition by the security service module, that is, the security service module in the trusted execution environment communicates with the normal operating environment of the operating system and issues the identifiers. This method has high security and can effectively prevent the identifiers from being tampered with or forged.

[0099] After obtaining the block device identifier and the mapped device identifier through any of the above methods, the device gains the ability to accurately locate the secure storage partition and its virtual access interface, enabling subsequent key derivation, partition decryption, and file system mounting operations based on the unique hardware identifier. Simultaneously, because the mapped device provides a transparent encryption / decryption interface, all subsequent read / write operations on sensitive information can be automatically encrypted / decrypted without exposing the key, thus effectively improving the security and ease of use of the embedded device.

[0100] Step S202: If successful, obtain the unique hardware identifier of the embedded device; wherein, the unique hardware identifier is an identifier that is written to a preset storage location during the initialization of the embedded device and corresponds one-to-one with the embedded device.

[0101] In this embodiment, after successfully obtaining the block device identifier and its mapped device identifier corresponding to the secure storage partition, the embodiment further performs the operation of obtaining the unique hardware identifier. In this embodiment, the unique hardware identifier is an immutable identifier that is written to a preset storage location during the factory initialization phase or the first boot of the embedded device, and corresponds one-to-one with the device body. Moreover, the identifier has device-level uniqueness, unforgeability, and anti-cloning properties.

[0102] Specifically, the unique hardware identifier can be, but is not limited to, one or more of the following forms of identification information: chip serial number, device MAC address, identifier burned into One-Time Programmable (OTP) memory (i.e., OTP value), key hash value stored in a trusted execution environment, circuit board-level unique identifier, internal fuse status value of the chip, unique response value output by a physically unclonable function, or device certificate serial number generated by a security coprocessor, etc. This identification information cannot be modified during the device's lifecycle and is strongly bound to the device's hardware circuitry or chip manufacturing process. Thus, even if an attacker obtains all the data in the storage medium through software means, they cannot reproduce the identifier on other devices, ensuring that the derived key is uniquely bound to a specific physical device. This effectively prevents unauthorized decryption or access on other devices after the storage medium is removed, thereby enhancing the security of key management methods and data storage from the hardware level.

[0103] Regarding the acquisition method, this embodiment provides multiple implementation paths to adapt to different hardware architectures and security level requirements. As an optional implementation, the operating system kernel or security service module can directly read the unique hardware identifier from a preset storage location by calling the underlying hardware abstraction interface (such as the hardware abstraction layer library provided by the chip manufacturer, the device tree node reading interface, or the security monitoring unit interface built into the system-on-a-chip). For example, in embedded devices based on ARM Cortex-A series processors, the 128-bit or 256-bit unique hardware identifier can be obtained by reading the one-time programmable controller register or the chip unique identifier register (such as the UID Register). In RISC-V architecture devices, it can be obtained by accessing the physical memory protection area in machine mode or the manufacturer-defined control and status registers.

[0104] As an alternative implementation, in embedded devices supporting a trusted execution environment, the acquisition of the unique hardware identifier is performed by a trusted application or secure kernel (such as an OP-TEE) in the secure world. The operating system in the ordinary world initiates a request to the secure world via a secure monitor call or shared memory mechanism. After verifying the legitimacy of the request, the secure world extracts the unique hardware identifier from a hardware-protected secure storage area (such as one-time programmable memory, electronic fuses, or secure random access memory) and returns it to the ordinary world through a secure channel. This method effectively prevents malware or unauthorized processes from directly accessing the hardware identifier, further enhancing the security of the key derivation process.

[0105] Regarding the timing of acquisition, this embodiment can perform the extraction of the unique hardware identifier in the early stages of operating system startup (such as after kernel initialization and before user-space services start). This approach has two advantages: firstly, the operating system environment is relatively clean at this time, and a large number of user-space processes have not yet been loaded, reducing the risk of the identifier being intercepted or tampered with. Secondly, completing the identifier extraction as early as possible provides a time window for subsequent key derivation, partition decryption, and file system mounting, ensuring that the file system storing sensitive information is available before critical services start.

[0106] It should be noted that if the unique hardware identifier acquisition fails (e.g., due to a corrupted preset storage location, hardware interface malfunction, or security world response timeout), this embodiment can execute a preset exception handling strategy. This strategy includes, but is not limited to: recording an error log and triggering a system restart, rolling back to a secure mode allowing only basic functions to run, or reporting the device's abnormal status via a remote management interface. Through this fault-tolerance mechanism, the device can be effectively prevented from becoming unusable due to hardware identifier acquisition failure, thereby improving the robustness and maintainability of the embedded device.

[0107] In summary, this step extracts a unique hardware identifier, one-to-one with the device, from a preset storage location, providing an unforgeable and unclonable root key factor for subsequent key derivation operations based on this identifier. Because this identifier is strongly bound to the device hardware and does not rely on external storage or network transmission, attackers cannot obtain it through software reverse engineering, storage medium copying, or device cloning, thus ensuring the security of the key derivation process at its source.

[0108] Step S203: Generate a derived key based on the unique hardware identifier, and decrypt the secure storage partition based on the derived key to obtain the file system stored in the secure storage partition.

[0109] After successfully obtaining the unique hardware identifier of the embedded device, this embodiment further performs key derivation and partition decryption operations based on the identifier.

[0110] Specifically, by leveraging the unique hardware information inherent in the device, a decryption key is dynamically generated at runtime using cryptographic algorithms. This key is then used to decrypt the encrypted secure storage partition, thereby gaining access to the file system stored within. Since the derived key exists only in memory during operating system operation and is strongly bound to the device hardware, attackers cannot obtain a valid key through offline analysis, storage medium copying, or memory dumping. This achieves high-security key management in embedded devices without requiring additional security chips.

[0111] When generating derived keys based on unique hardware identifiers, this embodiment provides multiple implementation paths to adapt to different security level requirements and hardware capabilities.

[0112] As an optional implementation, the obtained unique hardware identifier (such as chip serial number, OTP value, or device MAC address) or its combination can be directly used as the derived key. As another optional implementation, to improve key security and resistance to analysis, a derived key can be generated by performing derivation operations on the unique hardware identifier based on a key derivation function. Of course, the above two methods are merely illustrative examples. This embodiment can also use any other feasible method to generate the derived key, such as generating a stable key based on the real-time response value of a physically non-clonable function combined with a fuzzy extractor, or generating a key based on key derivation instructions from a security coprocessor. As long as a derived key for decryption can be generated based on the device's unique hardware identifier, it falls within the protection scope of this embodiment, and no specific limitations are imposed.

[0113] After the derived key is generated, this embodiment further utilizes the derived key to decrypt the secure storage partition. The secure storage partition is encrypted using an encryption algorithm during factory initialization or initial configuration, and the encryption key is also derived from the unique hardware identifier of the embedded device and used for initial encryption. Thus, the derived key used for decryption and the encryption key used for encryption are generated based on the same unique hardware identifier, ensuring that the decryption process can correctly restore the encrypted data. Furthermore, the above-mentioned method of encryption and decryption based on the same root key factor also achieves cryptographic symmetry and consistency between the encryption and decryption keys, while avoiding persistent key storage within the device. Even if an attacker obtains all the stored data on the device, they cannot decrypt the secure storage partition because they cannot obtain the unique hardware identifier or reproduce the key derivation process, thereby effectively protecting the security of sensitive data.

[0114] After successfully decrypting the secure storage partition, this embodiment obtains the file system stored within that partition. This file system can be a file system for storing sensitive information in the embedded device, such as a dedicated file system for storing sensitive information such as device serial numbers, production line keys, calibration data, encryption certificates, user privacy data, device identity credentials, or security policy configuration files.

[0115] Specifically, the file system is created and encrypted and stored in a secure storage partition during factory initialization or initial configuration. The type of file system can be flexibly selected according to the hardware characteristics and application scenarios of the embedded device, including but not limited to: fourth-generation extended file system, flash-friendly file system, journal-structured file system, unordered block mirror file system, or temporary file system. All of the above file system types support running on encrypted block devices and can work in conjunction with the underlying transparent encryption and decryption mechanism.

[0116] After acquiring the file system, the device further parses the file system's metadata (such as the superblock, inode table, directory entries, etc.) to verify the file system's integrity and consistency, confirming that the file system is in a mountable state. At this point, sensitive data in the file system is already decrypted in memory but has not yet been exposed to user-space processes. Subsequent mounting operations are needed to make it accessible. This ensures that sensitive information is only accessible within the runtime environment of a legitimate device, and that the file system content remains encrypted and protected on the storage medium, effectively preventing the leakage of sensitive information due to device loss, storage medium removal, or offline analysis.

[0117] Furthermore, this embodiment includes a pre-defined exception handling mechanism to handle potential anomalies during the decryption process. For example, if derivation key generation fails (e.g., hardware identifier reading error, key derivation function calculation error), an error log is recorded and the decryption process is terminated to prevent the operating system from entering an inconsistent state. If partition decryption fails (e.g., encryption parameter mismatch, authentication tag verification failure), a security audit event is triggered, and the administrator is notified via system logs, remote alarms, or hardware indicator lights. After multiple decryption failures, the operating system can automatically enter a secure recovery mode, allowing key reset or partition repair operations to be performed through authorized external interfaces (e.g., secure debug ports, remote management channels).

[0118] In summary, this step achieves strong binding between the key and the device hardware, runtime generation and immediate destruction of the key, and integrity verification of the decryption process by dynamically deriving the decryption key based on the unique hardware identifier and using the key to decrypt the secure storage partition to obtain the file system.

[0119] Step S204: Mount the file system to the mapping device indicated by the mapping device identifier.

[0120] In this embodiment, the mount operation can be understood as establishing an association between the file system and a directory (mount point) in the operating system's directory tree, so that user space processes can access files and directories in the file system through that directory.

[0121] Specifically, the device invokes a mount system call (such as the mount system call in Linux), specifying the following parameters: the source device is the mapped device identifier (such as " / dev / mapper / secure_partition"), the mount point is a preset directory path (such as " / mnt / secure" or " / data / secure"), the file system type is the file system type obtained in the aforementioned embodiments (such as fourth-generation extended file system, flash-friendly file system, or journaling file system), and the mount options include read and write permissions (such as read-only or read-write), access control policies (such as allowing only specific users or groups to access), synchronization options (such as forced synchronous write), and security-related options (such as disabling device file creation, disabling SUID / SGID bits, etc.).

[0122] After the file system is mounted, this embodiment further implements access control policies to ensure that only authorized processes or users can access sensitive data under the mount point. As an optional implementation, a security context can be set for the mount point directory through the Linux kernel's mandatory access control mechanism, allowing only processes with specific security labels (such as system services or trusted applications) to access the directory. Alternatively, discretionary access control can be implemented through file system permission bits and access control lists.

[0123] Furthermore, this embodiment also supports dynamic unmounting and locking of mount points. When the system enters hibernation, a security event is triggered, or a user logs out, the file system in the mapped device can be automatically unmounted, and the derived key in memory can be cleared, ensuring that sensitive data remains encrypted and protected during system inactivity. Upon re-access, the steps described in the preceding embodiment must be executed again, namely, re-acquiring the hardware identifier, derived key, decrypting the partition, and mounting the file system, thereby ensuring that each access undergoes a complete authentication and key derivation process.

[0124] Through the above steps, this embodiment securely mounts the decrypted file system to the mapped device, enabling the authorized process to access sensitive data through the standard file system interface, while ensuring that the underlying storage medium is always under encrypted protection, effectively balancing the convenience and security of data access.

[0125] In the technical solution provided by this disclosure, after the operating system starts, the automatic location and logical mapping of the encrypted partition are achieved by obtaining the block device identifier and mapping device identifier corresponding to the secure storage partition. This accurately identifies the area to be decrypted without manual intervention, improving the automation and reliability of embedded device startup. By obtaining the unique hardware identifier written during embedded device initialization, a strong binding relationship is established between the device identity and the decryption key, ensuring that only the original device can generate the correct key, effectively preventing attacks such as storage media removal, device cloning, or offline brute-force attacks. By dynamically generating derived keys based on the unique hardware identifier and decrypting the secure storage partition, runtime key generation and immediate use are achieved. The key is not persistently stored on any medium, completely eliminating the persistent risk of key leakage. This achieves a protection level comparable to a hardware security module without requiring an additional security chip. By mounting the decrypted file system to the mapping device, a transparent encryption / decryption interface is provided to upper-layer applications. Applications can access sensitive data through the standard file system interface without needing to understand the underlying encryption / decryption details, significantly reducing the integration difficulty and development cost of security functions. In summary, this technical solution generates a derived key based on the device's unique hardware identifier to decrypt the secure storage partition, thereby improving the security and tamper-proof capability of the embedded device's secure storage partition key management without increasing the cost of additional security chips.

[0126] Figure 3 Flowchart of the key management method provided in the embodiments of this disclosure Figure 2 Next, we will combine Figure 3 The technical principles of the key management solution provided in this disclosure will be further explained. It should be noted that the following description is merely an exemplary implementation of the technical solution provided in this disclosure and does not constitute any limitation on the technical solution provided in this disclosure.

[0127] To ensure the correct initialization of the secure storage partition and the reliability of subsequent mounting processes, the technical solution provided in this embodiment further includes the following steps before the operating system of the embedded device starts: querying the file system write status of all block device partitions within the embedded device; if none of the block device partitions within the embedded device have been written to the file system, then stopping the execution of obtaining the unique hardware identifier and subsequent mounting steps; if it is found that any block device partition within the embedded device has been written to the file system and is in an unencrypted state, then obtaining the unique hardware identifier, encrypting the block device partition based on the derived key generated by the unique hardware identifier, and using the encrypted block device partition as the secure storage partition; based on the partition identifier of the secure storage partition and the block device identifier of the block device partition, constructing a correspondence between the partition identifier of the secure storage partition and the block device identifier of the block device, and passing the correspondence into a pre-built partition mapping table or writing it into kernel command line parameters.

[0128] Specifically, before the operating system of the embedded device boots, the file system write status of all block device partitions within the embedded device is queried. Specifically, during the boot phase (such as the bootloader or early system initialization phase), the device scans all available block devices and their partitions, checking whether each partition contains a valid file system. This query can be achieved by reading the partition table, the file system superblock, or specific flag bits.

[0129] If all block device partitions within the embedded device have not been written to the file system (i.e., all partitions are empty or unformatted), the device is determined to be in its factory initial state or initial boot state. At this time, the device stops executing the steps of obtaining a unique hardware identifier and subsequent mounting, avoiding unnecessary key generation and partition mounting operations without valid data. This approach saves device boot time and prevents errors caused by empty partitions.

[0130] If any block device partition within the embedded device is found to have been written to the file system and is in an unencrypted state, the device initiates a security initialization process. Specifically, the device obtains a unique hardware identifier and encrypts the block device partition using a derived key generated based on the unique hardware identifier, using the encrypted block device partition as a secure storage partition. This encryption process can be completed using any subsequent derived key generation method and preset encryption tools (such as dm-crypt, LUKS, etc.).

[0131] After encryption is completed, the device constructs a mapping between the partition identifiers of the secure storage partition (such as UUID, partition name, or partition number) and the block device identifiers of the block device partition (such as device node name / dev / mmcblk0p2, device path, or hardware identifier). This mapping is then passed to a pre-built partition mapping table or written to kernel command-line parameters. This mapping is used during subsequent operating system startup to quickly locate the corresponding encrypted block device based on the partition identifier, thereby correctly performing decryption and mounting operations.

[0132] Through the above implementation methods, this embodiment achieves intelligent detection and differentiated processing of block device partition status before the operating system starts: for devices that have not been written to the file system, unnecessary processes are avoided; for partitions that have been written to the file system but are not encrypted, encryption initialization is automatically completed and partition mapping relationships are established. This mechanism ensures the correct initialization of secure storage partitions and the reliability of subsequent mounting processes, effectively improving the automation capabilities and security of embedded devices in first-time boot or recovery scenarios.

[0133] In this embodiment, after the operating system of the embedded device starts, the block device identifier corresponding to the secure storage partition of the embedded device can be obtained. During the acquisition process, one optional implementation may include: searching for the block device identifier corresponding to the secure storage partition according to a preset partition mapping table; or, parsing the block device identifier corresponding to the secure storage partition from kernel command-line parameters; wherein the partition mapping table includes the correspondence between the partition identifier of the secure storage partition and the block device identifier of the block device; the kernel command-line parameters include the correspondence between the partition identifier of the secure storage partition and the block device identifier of the block device; if the block device identifier is not obtained, the process of obtaining the unique hardware identifier and subsequent mounting steps is stopped; if the block device identifier is obtained, the mapped device identifier corresponding to the block device indicated by the block device identifier is obtained.

[0134] In this embodiment, after the operating system of the embedded device successfully boots up, it first executes the step of obtaining the block device identifier corresponding to the secure storage partition. This acquisition process can employ various optional implementation methods to ensure reliable location of the secure storage partition under different system configurations.

[0135] As an optional implementation, the device can perform queries based on a pre-configured partition mapping table. This partition mapping table is pre-stored in the non-volatile storage medium of the embedded device, and explicitly records the correspondence between the partition identifier of the secure storage partition and the block device identifier of the block device. By reading this mapping table, the device can quickly find and determine the corresponding block device identifier based on the known secure storage partition identifier.

[0136] As an alternative implementation, the device can parse the block device identifier corresponding to the secure storage partition from kernel command-line parameters. In this implementation, the kernel command-line parameters are typically passed to the operating system kernel by the bootloader, and may contain the mapping between the secure storage partition's partition identifier and the block device identifier. By parsing these parameters, the device can directly obtain the required block device identifier without relying on additional configuration files or mapping tables.

[0137] During the above acquisition process, the device will also determine whether the block device identifier has been successfully obtained. If the identifier is not obtained, it indicates that the secure storage partition cannot be properly identified or located. In this case, the device will immediately stop executing the subsequent steps of obtaining the unique hardware identifier and mounting to avoid device malfunction or data corruption caused by the partition being unavailable. If the block device identifier is successfully obtained, the device will further obtain the mapping device identifier corresponding to the block device indicated by the block device identifier, so as to perform subsequent mounting and access operations on the secure storage partition.

[0138] Through the above steps, this embodiment achieves dynamic and reliable positioning of the secure storage partition during the startup process of the embedded device and provides an exception handling mechanism, effectively improving the stability and security of the embedded device.

[0139] In the process of the system successfully obtaining the block device identifier and further obtaining the mapping device identifier corresponding to the block device indicated by the block device identifier, an optional implementation may include: searching for the mapping device identifier corresponding to the block device identifier in a preset partition mapping table; wherein, the partition mapping table includes the correspondence between block device identifiers and mapping device identifiers; if the mapping device identifier is not obtained, generating device construction prompt information; wherein, the device construction prompt information is used to prompt the user to construct the mapping device corresponding to the block device and generate the mapping device identifier corresponding to the mapping device.

[0140] Specifically, the device can again use the pre-configured partition mapping table for lookup. This partition mapping table not only contains the correspondence between the partition identifier of the secure storage partition and the block device identifier, but also the correspondence between the block device identifier and the mapped device identifier. By using the obtained block device identifier as an index to search in the partition mapping table, the device can determine the mapped device identifier corresponding to the block device.

[0141] During the search process, the device will determine whether the mapped device identifier has been successfully obtained. If the identifier is not obtained, it indicates that a corresponding mapped device has not yet been built for this block device, or the mapped device identifier has not been correctly recorded. In this case, the device will generate a device build prompt message. This device build prompt message is used to notify users (such as device administrators or developers) that they need to manually or automatically build the mapped device corresponding to the current block device, and generate the corresponding mapped device identifier after the build is completed. Through this prompt message, users can promptly know the device status and take appropriate measures, thereby ensuring that subsequent mounting and access operations of the secure storage partition can proceed smoothly.

[0142] Through the above steps, this embodiment provides an exception handling mechanism during the process of obtaining the mapping device identifier, avoiding file system mounting failure or data access abnormalities caused by the absence of the mapping device, and further improving the robustness and user-friendliness of embedded devices in secure storage partition management.

[0143] If the device successfully obtains the mapped device identifier corresponding to the block device indicated by the block device identifier, it can further obtain the unique hardware identifier of the embedded device, and generate a derived key based on the unique hardware identifier, thereby realizing the encryption protection or access control of the data in the secure storage partition.

[0144] To ensure that the device can reliably obtain the unique hardware identifier, the key management method provided in this embodiment further includes: reading the identifier using a preset method before the operating system of the embedded device starts; the preset method for reading the identifier includes at least one of reading the identifier pre-programmed into a one-time programmable memory, reading the identifier pre-written into a trusted execution environment, and reading the preset identifier through a program interface; and writing the read identifier as the unique hardware identifier into the kernel command line parameters or non-volatile storage, so that after successfully obtaining the block device identifier corresponding to the secure storage partition of the embedded device, the unique hardware identifier of the embedded device can be obtained based on the kernel command line parameters or non-volatile storage.

[0145] Specifically, the device reads the identifier using a preset method to obtain a unique hardware identifier used subsequently to generate the derived key. This preset method of reading the identifier includes, but is not limited to, at least one of the following methods.

[0146] In one alternative approach, an identifier pre-programmed into a one-time programmable memory is read. In this embodiment, a one-time programmable memory is a storage medium whose data is written to it during chip manufacturing or shipping and cannot be altered; it is typically used to store a chip's unique serial number, key, or hardware fingerprint. The system reads the pre-set identifier data by accessing a designated address or register of the one-time programmable memory. This identifier is immutable and unique, and can serve as a hardware identity credential for the embedded device.

[0147] Alternatively, an identifier pre-written into the Trusted Execution Environment (TEE) can be read. Specifically, during device manufacturing or initialization, a unique hardware identifier can be written to the secure storage area of ​​the TEE. The system then reads this identifier in a secure environment by calling the secure application programming interface provided by the TEE, thereby ensuring the confidentiality and integrity of the identifier during the reading process and preventing it from being stolen by malware or unauthorized access.

[0148] In another alternative approach, a preset identifier is read via a programmable interface. In some implementations, the preset hardware identifier field can be read from the device tree; the preset identifier can also be read from firmware configuration (such as Bootloader parameters); or the identifier data can be read directly from dedicated registers (such as the chip's internal unique ID register, the SoC's electronic fuse register, or debug interface registers). These registers are assigned unique values ​​during the chip design phase, allowing the device to read them via memory-mapped input / output or dedicated instructions.

[0149] Through the above-mentioned multiple preset reading methods, this embodiment can adapt to the security levels and storage characteristics of different hardware platforms, ensuring the reliable acquisition of unique hardware identifiers.

[0150] After reading the above identifiers, the device will use the read identifiers as unique hardware identifiers and write them into the kernel command-line parameters.

[0151] Specifically, during the boot phase before the operating system starts (e.g., executed by the bootloader or initialization script), the device embeds a unique hardware identifier as a key-value pair by modifying or appending kernel command-line argument strings. For example, adding the parameter "hardware_id=<read identifier value>" or "unique_hw_id=<read identifier value>". This kernel command-line argument is then passed by the bootloader to the operating system kernel that is about to start.

[0152] By writing a unique hardware identifier into the kernel command-line parameters, the operating system can directly extract this unique hardware identifier from the kernel command-line parameters during the boot process using the standard kernel parameter parsing mechanism. This method eliminates the need for the operating system to access underlying hardware resources (such as OTP, TEE, or device tree) after boot, thus simplifying the acquisition process, reducing device boot latency, and decreasing dependence on specific hardware interfaces, further improving the execution efficiency and device compatibility of the key management method.

[0153] Furthermore, the device can also use the read identifier as a unique hardware identifier and write it into non-volatile storage. For example, the non-volatile storage medium can be at least one of the following: flash memory (such as NAND Flash, NOR Flash), embedded multimedia card (eMMC), secure digital memory card (SD card), ferroelectric random access memory (FRAM), or magnetoresistive random access memory (MRAM). The device persistently stores the unique hardware identifier in the form of a file (e.g., written to a configuration file at a specified path) or in the form of raw data blocks (e.g., written to a specific sector or partition of the storage medium) by calling the storage medium's driver or low-level write interface.

[0154] By writing a unique hardware identifier to non-volatile memory, the operating system can obtain this unique hardware identifier by reading a specified location or file in the storage medium after booting. This method does not rely on the kernel command-line parameter passing mechanism, making it suitable for scenarios where the bootloader does not support or finds it inconvenient to modify kernel command-line parameters. It also allows the device to read the identifier multiple times during operation without repeatedly accessing underlying hardware resources (such as OTP or TEE).

[0155] Through the above steps, this embodiment completes the reading and storage of the unique hardware identifier before the operating system starts, providing a reliable data source for the subsequent generation of derived keys based on this identifier. Furthermore, by employing multiple preset reading methods, this embodiment takes into account the security and compatibility of different hardware platforms, further improving the versatility and security of the key management method.

[0156] Based on the above implementation, when obtaining the unique hardware identifier of an embedded device, an optional implementation may include: parsing kernel command-line parameters to obtain the unique hardware identifier from the kernel command-line parameters.

[0157] In this embodiment, since the unique hardware identifier has been read in a preset way and written into the kernel command line parameters before the operating system starts, the operating system can extract the unique hardware identifier from the kernel command line parameters through the standard kernel parameter parsing mechanism during the startup process.

[0158] Specifically, when parsing kernel command-line arguments to obtain a unique hardware identifier, the operating system kernel parses each kernel command-line argument passed by the bootloader during the initialization phase. It identifies the parameter name or keyword (e.g., "hardware_id=xxxxxxxx" or "unique_id=yyyyyyyy") corresponding to the unique hardware identifier and extracts its corresponding parameter value. This parameter value is the pre-written unique hardware identifier. In this way, the operating system can quickly and reliably obtain the unique hardware identifier without needing to access hardware resources such as OTP memory, TEE, or device tree after startup, thus significantly reducing system startup latency and dependence on low-level hardware interfaces.

[0159] Through the above steps, this embodiment achieves efficient acquisition of a unique hardware identifier during the operating system startup process, providing a convenient data source for generating derived keys based on this identifier, and further improving the execution efficiency and device compatibility of the key management method.

[0160] Furthermore, since the unique hardware identifier is read from the hardware source (such as OTP memory, TEE, or fuse status) and written into the kernel command-line parameters by the bootloader before the operating system boots, this process occurs before the operating system kernel and user-space software are loaded. This effectively prevents malicious software or kernel modules from illegally accessing or tampering with the hardware interface after the operating system boots. In addition, the kernel command-line parameters are verified and protected for integrity by the bootloader through the Secure Boot chain during the boot phase. Any tampering with the parameter content will cause verification failure, thus preventing the device from booting. Therefore, attackers cannot forge or replace the unique hardware identifier in the kernel command-line parameters through software means, ensuring the authenticity and integrity of the identifier's source. This mechanism establishes a hardware root of trust from the earliest stage of device boot, providing an unforgeable and tamper-proof input basis for subsequently derived keys generated based on this identifier, thereby significantly enhancing the overall security of the key management method at the device boot level.

[0161] Another alternative implementation for obtaining the unique hardware identifier of an embedded device may include reading the unique hardware identifier from non-volatile memory.

[0162] Specifically, during the boot phase before the operating system starts, the device obtains a unique hardware identifier through a preset method (such as reading the OTP memory, TEE, or reading a preset identifier through a program interface) and writes it to a specified location in non-volatile storage. For example, it may be stored as a file in a specific path (such as " / factory / hardware_id" or " / misc / unique_id"), or written as raw data blocks to a specific sector or partition of the storage medium (such as the "misc" partition or the "factory" partition).

[0163] Thus, after the operating system boots up, when a unique hardware identifier is needed, the device reads the identifier from a specified location in non-volatile storage by calling the file system interface or the underlying storage driver. Specifically, if the unique hardware identifier is stored as a file, the device obtains the identifier value by opening and reading the contents of that file. If it is stored as raw data blocks, the device reads the data blocks of a specified sector or partition and parses the identifier value from them.

[0164] In this way, the operating system does not need to rely on the kernel command-line parameter passing mechanism, which is suitable for scenarios where the bootloader does not support or finds it inconvenient to modify the kernel command-line parameters. It also makes it easier for the device to read the identifier multiple times during operation without repeatedly accessing the underlying hardware resources (such as OTP or TEE).

[0165] By providing multiple reading methods in the above steps, this embodiment further enhances the flexibility and applicability of the key management method, enabling it to adapt to the boot architecture and storage configuration of different embedded devices.

[0166] In the above implementation process, the technical solution provided by this disclosure also includes: if a unique hardware identifier is not obtained, then stop executing the subsequent key generation and subsequent mounting steps.

[0167] Specifically, during the process of attempting to parse kernel command-line arguments or read a unique hardware identifier from non-volatile memory, the device also determines whether the unique hardware identifier has been successfully obtained. That is, the device checks whether the parameter value parsed from the kernel command-line arguments is empty, invalid, or does not conform to a preset format. Alternatively, it checks whether the data read from non-volatile memory is empty, corrupted, or cannot be parsed into a valid unique hardware identifier.

[0168] If any of the above checks result in a negative result, meaning the device fails to obtain a valid and unique hardware identifier, the device will immediately terminate subsequent operations, and will no longer execute the step of generating a derived key based on the identifier, nor the step of mounting the secure storage partition.

[0169] Through the aforementioned anomaly handling mechanism, this embodiment can avoid the risk that the device will generate an incorrect derived key based on an incorrect or missing identifier when the unique hardware identifier is missing or invalid. This could lead to the inability to correctly decrypt or access data in the secure storage partition, or even cause data corruption or security vulnerabilities. Simultaneously, by promptly stopping subsequent steps, the device can return a clear error status to the user or upper-layer application, facilitating rapid problem location and appropriate measures (such as reprogramming the identifier or checking the hardware configuration), thereby further improving the robustness and security of the key management method.

[0170] Having obtained a unique hardware identifier based on the above implementation method, the operating system also generates a derived key based on the unique hardware identifier. This derived key is used for subsequent encryption protection or access control of data in the secure storage partition.

[0171] It should be noted that the environment for generating the derived key can be multiple, and this embodiment does not limit this. Specifically, the derived key can be generated in a normal environment (i.e., an insecure environment when the operating system is running normally) or in a Trusted Execution Environment (TEE). When generated in a normal environment, the device calculates the derived key by calling a standard encryption algorithm library (such as a kernel encryption API or a user-space encryption library), using a unique hardware identifier as an input parameter, and combining it with a preset key derivation function (such as a hash-based message authentication code). When generated in a Trusted Execution Environment, the device performs key derivation operations within a secure area isolated by the TEE by calling the secure encryption service provided by the TEE, ensuring that the unique hardware identifier and the derived key are not accessed or leaked by an insecure environment during the generation process.

[0172] By providing multiple generation environments, this embodiment can adapt to application requirements with different security levels: for scenarios with high security requirements, derived keys can be generated in the TEE to enhance key confidentiality and resistance to attacks; for performance-sensitive scenarios or scenarios with limited TEE resources, generation can be carried out in a normal environment to reduce device overhead. This flexibility further enhances the applicability and configurability of the key management method.

[0173] In one alternative implementation of generating derived keys, in order to reduce reliance on hardware security resources such as trusted execution environments and simplify device implementation complexity, derived keys can be generated based on unique hardware identifiers within the normal execution environment of the operating system.

[0174] Specifically, after successfully obtaining a unique hardware identifier, the device passes the identifier to the key generation module in the normal execution environment of the operating system. This key generation module can be a kernel-space cryptographic service component (such as the kernel cryptographic API framework) or a user-space cryptographic library (such as OpenSSL, mbedTLS, or the system's built-in cryptographic tools).

[0175] In some implementations, the key generation module uses a unique hardware identifier as input and combines it with pre-configured derivation parameters (such as salt, iteration count, context information, or application-specific strings) to calculate a derived key. This key derivation function can be a hash-based message authentication code (HMAC) derivation algorithm, a key derivation function (KDF, such as HKDF or PBKDF2) algorithm, or other security-compliant key derivation algorithms. The length and format of the derived key can be configured according to subsequent encryption requirements; for example, generating a symmetric key of 128 bits, 256 bits, or other lengths.

[0176] The key generation module stores the generated derived key in the memory of the normal execution environment for subsequent use in mounting the secure storage partition, data encryption, or access control operations.

[0177] Because this derivation process is completed entirely in a normal execution environment, without calling TEE interfaces or relying on hardware security zones, it has the advantages of simple implementation, high execution efficiency, and low device overhead. While ensuring basic security, it effectively reduces device complexity and development costs, further enhancing the applicability and flexibility of the key management method.

[0178] In one alternative implementation of generating a derived key, to further enhance the security of the key generation process, the system can pass a unique hardware identifier into a trusted execution environment, generate a derived key based on the unique hardware identifier in the trusted execution environment, and obtain the derived key released by the trusted execution environment.

[0179] Specifically, after successfully obtaining a unique hardware identifier, the device securely transmits the unique hardware identifier from the normal execution environment of the operating system to the trusted execution environment (TEE) through a secure communication interface provided by the TEE (such as the SMC instruction of ARMTrustZone, the client API of OP-TEE, or the shared memory mechanism of QSEE). This allows the trusted execution environment to perform key derivation operations within its hardware-isolated secure area upon receiving the unique hardware identifier. This transmission process can be ensured by encrypting or encapsulating the identifier data to prevent it from being stolen or tampered with by insecure environments during transmission.

[0180] In some implementations, the trusted execution environment (TEE) has a pre-built secure key derivation function (such as HKDF, PBKDF2, or a derivation algorithm based on a hardware security module). This function uses a unique hardware identifier as input and combines it with a preset salt value or context information to calculate the derived key. Because this operation is performed within the TEE, the unique hardware identifier and the derived key are protected by hardware throughout the entire generation process, preventing malware or attackers in ordinary execution environments from directly accessing or stealing them.

[0181] After generating the derived key, the trusted execution environment (TEE) releases the derived key back to the normal execution environment via a secure communication interface. This release process may include: the TEE storing the derived key in a secure shared memory area accessible only to specific processes within the normal execution environment, or returning the derived key to the requester via an encrypted channel. Once the normal execution environment obtains the derived key, it can use it for subsequent operations such as mounting secure storage partitions, data encryption, or access control.

[0182] Through the above implementation method, this embodiment places the key derivation process in a trusted execution environment, making full use of the hardware isolation characteristics of TEE, effectively preventing the unique hardware identifier and derivation key from being leaked or tampered with during the generation process, enhancing the overall security of the key management method, and is especially suitable for embedded device scenarios with high data protection requirements.

[0183] In addition, in the two key generation environments mentioned above, an optional implementation of generating derived keys based on unique hardware identifiers may also include: directly using any one of the unique hardware identifiers as the derived key.

[0184] It should be noted that this implementation method is applicable to, but not limited to, scenarios where the unique hardware identifier itself has sufficient entropy and security, and its length meets the requirements of subsequent encryption or authentication. In a Trusted Execution Environment (TEE) or a Normal Execution Environment (REE), after successfully obtaining the unique hardware identifier, the device does not need to perform additional key derivation operations. Instead, it directly uses the unique hardware identifier itself or a specified part thereof (e.g., a specific byte segment, a specific field, or data after simple format conversion in the identifier) ​​as the derived key.

[0185] For example, if the unique hardware identifier is a 128-bit chip serial number, the device can directly use this 128-bit serial number as a derived key for subsequent encryption or access control of the secure storage partition. If the unique hardware identifier is a 256-bit device fingerprint, the device can extract the first 128 bits or the last 128 bits as a derived key, or directly use the complete 256-bit data as a derived key. This direct use method also applies to scenarios where the unique hardware identifier is stored as a string; the device can use the string as a key after hashing or direct byte conversion.

[0186] This implementation method further simplifies the key generation process, avoiding the computational overhead and latency caused by key derivation operations, making it particularly suitable for performance-sensitive or resource-constrained embedded device scenarios. Furthermore, since the unique hardware identifier itself possesses device uniqueness and is not easily copied, directly using it as the derived key improves the execution efficiency and ease of implementation of the key management method while meeting basic security requirements.

[0187] In the two key generation environments described above, an optional implementation of generating a derived key based on a unique hardware identifier may further include: combining at least two identifiers from the unique hardware identifier as a derived key.

[0188] In a Trusted Execution Environment (TEE) or a Normal Execution Environment (REE), after successfully acquiring at least two identifiers, the device concatenates, mixes, or performs operations on these identifiers according to preset combination rules to generate the final derived key.

[0189] Specifically, this embodiment provides a variety of flexible and secure combination methods, including: splicing combination, which involves splicing identifiers in sequence to form a new data block; hash combination, which involves generating a fixed-length digest through hash operation after splicing; XOR combination, which involves performing XOR operation by byte alignment; and weighted mixing, which involves performing mixing operation according to preset weights, etc.

[0190] By combining at least two identifiers to generate a derived key, the entropy and complexity of the derived key are effectively increased, reducing the risk of key cracking due to the leakage or predictability of a single identifier. Thus, even if an attacker obtains one of the identifiers, they cannot reconstruct the final derived key due to the lack of information about the combination of the other identifiers, thereby enhancing the security of the key management method.

[0191] After generating a derived key using any of the methods described above, the secure storage partition can be decrypted using the derived key to obtain the file system stored within the secure storage partition. In this embodiment, an optional implementation may include: decrypting the secure storage partition using a preset decryption tool based on the derived key to obtain the file system within the secure storage partition.

[0192] Specifically, the device invokes a preset decryption tool, using the derived key as the decryption key, to decrypt the secure storage partition. This preset decryption tool can be a cryptographic block device driver in the operating system kernel (such as dm-crypt, LUKS), a file system-level encryption tool (such as fscrypt, ecryptfs), or a user-space decryption application. The decryption tool uses the derived key to decrypt the encrypted data in the partition block by block, based on the encryption algorithm (such as AES-XTS, AES-CBC, SM4, etc.) and encryption mode used when the secure storage partition was created.

[0193] During the decryption process, the decryption tool first reads the header metadata of the secure storage partition to obtain encryption parameters (such as encryption algorithm identifier, initialization vector IV, salt value, etc.), and then uses the derived key in combination with these parameters to decrypt the encrypted data blocks in the partition.

[0194] This implementation method enables decryption access to secure storage partitions using keys derived from unique hardware identifiers, ensuring that only devices possessing the correct unique hardware identifier can decrypt and access the protected file system content. Furthermore, it prevents unauthorized reading of data on other devices after the storage medium has been removed, thereby significantly enhancing the security of sensitive data storage in embedded devices.

[0195] Once decryption is complete, the device can obtain the original file system within the secure storage partition and mount it to the operating system's designated mount point (such as " / data", " / secure", or " / private"), allowing upper-layer applications and system services to access it normally.

[0196] Figure 4 This is a schematic diagram of the key management device provided in this disclosure. Figure 4 As shown, the key management device 40 provided in this embodiment includes:

[0197] The device identifier acquisition module 401 is used to acquire, after the operating system of the embedded device starts, the block device identifier corresponding to the secure storage partition of the embedded device, and the mapped device identifier corresponding to the block device indicated by the block device identifier;

[0198] The unique hardware identifier acquisition module 402 is used to acquire the unique hardware identifier of the embedded device if the acquisition is successful; wherein, the unique hardware identifier is an identifier that is written to a preset storage location during the initialization of the embedded device and corresponds one-to-one with the embedded device;

[0199] The key generation and decryption module 403 is used to generate a derived key based on a unique hardware identifier, and to decrypt the secure storage partition based on the derived key to obtain the file system stored in the secure storage partition.

[0200] The file system mounting module 404 is used to mount the file system to the mapping device indicated by the mapping device identifier; wherein the file system is used to store sensitive information of the embedded device, and the mapping device is used to provide a transparent encryption and decryption interface when accessing the file system.

[0201] After the operating system boots, by obtaining the block device identifier and mapping device identifier corresponding to the secure storage partition, the encrypted partition is automatically located and logically mapped. This accurately identifies the area to be decrypted without manual intervention, improving the automation and reliability of the operating system boot process. By obtaining the unique hardware identifier written during embedded device initialization, a strong binding relationship is established between the device identity and the decryption key, ensuring that only the original device can generate the correct key. This effectively prevents attacks such as storage media removal, device cloning, or offline brute-force attacks. By dynamically generating derived keys based on the unique hardware identifier and decrypting the secure storage partition, runtime key generation and immediate use are achieved. The key is not persistently stored on any medium, completely eliminating the persistent risk of key leakage. This achieves a protection level comparable to hardware security modules without requiring additional security chips. By mounting the decrypted file system to the mapping device, a transparent encryption / decryption interface is provided to upper-layer applications. Applications can access sensitive data through the standard file system interface without needing to understand the underlying encryption / decryption details, significantly reducing the integration difficulty and development cost of security functions. In summary, this technical solution generates a derived key based on the device's unique hardware identifier to decrypt the secure storage partition, thereby improving the security and tamper-proof capability of the embedded device's secure storage partition key management without increasing the cost of additional security chips.

[0202] In one possible implementation, the device identifier acquisition module 401 is specifically used for:

[0203] The block device identifier corresponding to the secure storage partition is found based on the preset partition mapping table; or, the block device identifier corresponding to the secure storage partition is parsed from the kernel command-line parameters. The partition mapping table includes the correspondence between the partition identifier of the secure storage partition and the block device identifier of the block device; the kernel command-line parameters include the correspondence between the partition identifier of the secure storage partition and the block device identifier of the block device.

[0204] If the block device identifier is not obtained, the process of obtaining the unique hardware identifier and subsequent mounting steps will be stopped.

[0205] If a block device identifier is obtained, then the mapping device identifier corresponding to the block device indicated by the block device identifier is obtained.

[0206] In one possible implementation, the device identifier acquisition module 401 is specifically used for:

[0207] In the preset partition mapping table, look up the mapping device identifier corresponding to the block device identifier; the partition mapping table includes the correspondence between block device identifiers and mapping device identifiers;

[0208] If the mapped device identifier is not obtained, a device construction prompt message is generated. The device construction prompt message is used to prompt the user to build a mapped device corresponding to the block device and generate a mapped device identifier corresponding to the mapped device.

[0209] In one possible implementation, the device is also used for:

[0210] Before the operating system of the embedded device starts, the identifier is read in a preset way. The preset way of reading the identifier includes reading the identifier that has been pre-programmed into the one-time programmable memory, reading the identifier that has been pre-written into the trusted execution environment, and reading the preset identifier through the program interface.

[0211] The read identifier is used as the unique hardware identifier and written to the kernel command line parameters or non-volatile storage. After successfully obtaining the block device identifier corresponding to the secure storage partition of the embedded device, the unique hardware identifier of the embedded device is obtained based on the kernel command line parameters or non-volatile storage.

[0212] In one possible implementation, the unique hardware identifier acquisition module 402 is specifically used for:

[0213] Parse kernel command-line arguments to obtain a unique hardware identifier from the kernel command-line arguments; or read the unique hardware identifier from non-volatile memory.

[0214] In one possible implementation, the device is also used for:

[0215] If a unique hardware identifier is not obtained, the subsequent key generation and mounting steps will be stopped.

[0216] In one possible implementation, the unique hardware identifier includes at least one of the following: chip serial number, device MAC address, identifier burned into one-time programmable memory, key hash value stored in trusted execution environment, and board-level unique identifier.

[0217] In one possible implementation, the key generation and decryption module 403 is specifically used for:

[0218] A unique hardware identifier is passed into the trusted execution environment. A derived key is generated in the trusted execution environment based on the unique hardware identifier, and the derived key released by the trusted execution environment is obtained.

[0219] In one possible implementation, the key generation and decryption module 403 is specifically used to generate a derived key based on a unique hardware identifier in the normal execution environment of the operating system.

[0220] In one possible implementation, the key generation and decryption module 403 is specifically used for:

[0221] Use any one of the unique hardware identifiers directly as the derived key;

[0222] Combine at least two identifiers from the unique hardware identifier to form the derived key;

[0223] Using a preset key derivation function, encrypt at least one identifier from at least one unique hardware identifier to obtain the derived key.

[0224] In one possible implementation, the key generation and decryption module 403 is specifically used for:

[0225] Based on the derived key, the secure storage partition is decrypted using a preset decryption tool to obtain the file system within the secure storage partition.

[0226] In one possible implementation, the device is also used for:

[0227] After the operating system of the embedded device starts, query the file system write status of all block device partitions within the embedded device;

[0228] If none of the block device partitions within the embedded device have been written to the file system, then the process of obtaining the unique hardware identifier and subsequent mounting steps will be stopped.

[0229] If it is found that any block device partition within the embedded device has been written to the file system and the block device partition is in an unencrypted state, then a unique hardware identifier is obtained, and the block device partition is encrypted using a derived key generated based on the unique hardware identifier. The encrypted block device partition is then used as a secure storage partition.

[0230] Based on the partition identifier of the secure storage partition and the block device identifier of the block device partition, a mapping relationship between the partition identifier of the secure storage partition and the block device identifier of the block device is constructed, and the mapping relationship is passed to a pre-made partition mapping table or written to the kernel command line parameters.

[0231] Through the above implementation methods, this embodiment achieves intelligent detection and differentiated processing of block device partition status before the operating system starts: for devices that have not been written to the file system, unnecessary processes are avoided; for partitions that have been written to the file system but are not encrypted, encryption initialization is automatically completed and partition mapping relationships are established. This mechanism ensures the correct initialization of secure storage partitions and the reliability of subsequent mounting processes, effectively improving the automation capabilities and security of embedded devices in first-time boot or recovery scenarios.

[0232] The key management device provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0233] Figure 5 This is a schematic diagram of the embedded device provided in this disclosure. Figure 5 As shown, the embedded device 50 provided in this embodiment includes at least one processor 501 and a memory 502. In some embodiments, the embedded device 50 further includes a communication component 503. The processor 501, memory 502, and communication component 503 are connected via a bus 504.

[0234] In a specific implementation, at least one processor 501 executes computer execution instructions stored in memory 502, causing at least one processor 501 to perform the above-described method.

[0235] The specific implementation process of processor 501 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0236] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0237] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0238] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0239] This disclosure also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0240] This disclosure also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0241] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0242] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0243] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0244] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0245] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0246] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to related technologies, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0247] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0248] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A key management method, characterized in that, Applied to embedded devices, the method includes: After the operating system of the embedded device starts, the block device identifier corresponding to the secure storage partition of the embedded device is obtained, as well as the mapping device identifier corresponding to the block device indicated by the block device identifier; If successful, the unique hardware identifier of the embedded device is obtained; wherein, the unique hardware identifier is an identifier that is written to a preset storage location during the initialization of the embedded device and corresponds one-to-one with the embedded device; Based on the unique hardware identifier, a derived key is generated, and based on the derived key, the secure storage partition is decrypted to obtain the file system stored in the secure storage partition; The file system is mounted to the mapping device indicated by the mapping device identifier; wherein the file system is used to store sensitive information of the embedded device, and the mapping device is used to provide a transparent encryption / decryption interface when accessing the file system.

2. The method according to claim 1, characterized in that, Obtain the block device identifier corresponding to the secure storage partition within the device, including: The block device identifier corresponding to the secure storage partition is found according to a preset partition mapping table; or, the block device identifier corresponding to the secure storage partition is parsed from kernel command-line parameters; wherein, the partition mapping table includes the correspondence between the partition identifier of the secure storage partition and the block device identifier of the block device; the kernel command-line parameters include the correspondence between the partition identifier of the secure storage partition and the block device identifier of the block device; If the block device identifier is not obtained, the process of obtaining the unique hardware identifier and subsequent mounting steps will be stopped. If the block device identifier is obtained, then the mapping device identifier corresponding to the block device indicated by the block device identifier is obtained.

3. The method according to claim 2, characterized in that, Obtaining the mapped device identifier corresponding to the block device indicated by the block device identifier includes: In a pre-defined partition mapping table, the mapping device identifier corresponding to the block device identifier is searched; wherein, the partition mapping table includes the correspondence between block device identifiers and mapping device identifiers; If the mapped device identifier is not obtained, a device construction prompt message is generated; wherein, the device construction prompt message is used to prompt the user to construct a mapped device corresponding to the block device, and to generate a mapped device identifier corresponding to the mapped device.

4. The method according to claim 1, characterized in that, Before the operating system of the embedded device starts, the method further includes: The identifier is read using a preset method, which includes at least one of the following: reading an identifier pre-programmed into a one-time programmable memory, reading an identifier pre-written into a trusted execution environment, and reading a preset identifier through a program interface; The read identifier is used as the unique hardware identifier and written into the kernel command line parameters or non-volatile storage. After successfully obtaining the block device identifier corresponding to the secure storage partition of the embedded device, the unique hardware identifier of the embedded device is obtained based on the kernel command line parameters or non-volatile storage.

5. The method according to claim 4, characterized in that, The process of obtaining the unique hardware identifier of the embedded device based on kernel command-line parameters or non-volatile storage includes: Parse kernel command-line arguments to obtain the unique hardware identifier from the kernel command-line arguments; or, read the unique hardware identifier from non-volatile memory.

6. The method according to claim 5, characterized in that, The method also includes: If the unique hardware identifier is not obtained, the subsequent key generation and mounting steps will be stopped.

7. The method according to claim 1, characterized in that, The unique hardware identifier includes at least one of the following: chip serial number, device MAC address, identifier burned into one-time programmable memory, key hash value stored in trusted execution environment, and circuit board level unique identifier.

8. The method according to claim 7, characterized in that, Based on the unique hardware identifier, a derived key is generated, including: The unique hardware identifier is passed to the trusted execution environment, a derived key is generated based on the unique hardware identifier in the trusted execution environment, and the derived key released by the trusted execution environment is obtained.

9. The method according to claim 7, characterized in that, Based on the unique hardware identifier, a derived key is generated, including: In the normal execution environment of the operating system, a derived key is generated based on the unique hardware identifier.

10. The method according to claim 8 or 9, characterized in that, Based on the unique hardware identifier, a derived key is generated, including any one of the following: Use any one of the unique hardware identifiers directly as the derived key; The derived key is a combination of at least two identifiers from the unique hardware identifier. The derived key is obtained by encrypting at least one of the unique hardware identifiers using a preset key derivation function.

11. The method according to claim 1, characterized in that, Based on the derived key, decrypt the secure storage partition to obtain the file system stored within the secure storage partition, including: Based on the derived key, the secure storage partition is decrypted using a preset decryption tool to obtain the file system within the secure storage partition.

12. The method according to claim 1, characterized in that, After the operating system of the embedded device starts, the method further includes: Query the file system write status of all block device partitions within the embedded device; If none of the block device partitions in the embedded device have been written to the file system, then the process of obtaining the unique hardware identifier and subsequent mounting steps will be stopped. If it is found that any block device partition within the embedded device has been written to the file system and the block device partition is in an unencrypted state, then the unique hardware identifier is obtained, and the block device partition is encrypted based on the derived key generated by the unique hardware identifier, and the encrypted block device partition is used as a secure storage partition. Based on the partition identifier of the secure storage partition and the block device identifier of the block device partition, a correspondence between the partition identifier of the secure storage partition and the block device identifier of the block device is constructed, and the correspondence is passed to a pre-made partition mapping table or written to kernel command line parameters.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer execution flag, which, when executed by a processor, is used to implement the method as described in any one of claims 1-12.

14. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method described in any one of claims 1-12.

15. An embedded device, characterized in that, include: The memory has a secure storage partition, in which a file system is stored; A processor for performing the method according to any one of claims 1-12.

Images