Security authentication multi-start method for Linux system of development board

Abstract

The invention discloses a development board Linux system security authentication multi-start method, which comprises the steps of 1, hardware trust root initialization and storage area division, 2, hardware trust root self-inspection and measurement, 3, starting item dynamic loading and multi-stage authentication, 4, security context establishment and system switching, and 5, multi-system isolation and collaboration. Step 6, performing security audit and exception handling; full-link authentication is realized by taking a hardware trust root as an anchor point, malicious mirror startup and inter-system data leakage are effectively resisted in combination with a storage and resource isolation mechanism, scenes such as on-demand dynamic switching, flexible adaptation debugging, upgrading and fault recovery of multiple systems can be realized, and the system reliability is improved by optimizing the lightweight design of an authentication algorithm and resource management. Limited computing power of the development board is adapted, the starting process and abnormal events can be completely recorded, and illegal operation can be traced conveniently.

Description

Technical Field

[0001] This invention relates to the field of information security technology, and in particular to a method for secure authentication and multi-booting of a Linux system on a development board. Background Technology

[0002] With the widespread application of development boards in edge computing, industrial IoT and other fields, a single operating system can no longer meet diverse needs. Traditional multi-boot solutions do not authenticate the boot items. Attackers can inject malicious code by tampering with the boot configuration or replacing the system image, resulting in poor security. Traditional solutions lack isolation mechanisms. When multiple systems share storage partitions, data is easily leaked to each other. System crashes may also affect other systems. Furthermore, it is impossible to trace the source of the boot operation and it is difficult to locate illegal boot events.

[0003] While existing improvement schemes introduce digital signature verification, they rely on specific hardware and are not optimized for the needs of limited development board resources and dynamic switching between multiple systems. In particular, they lack support for independent storage and runtime isolation of multiple systems. Therefore, this invention proposes a multi-boot method for secure authentication of Linux systems on development boards to solve the problems existing in the prior art. Summary of the Invention

[0004] To address the aforementioned problems, the present invention aims to propose a method for secure authentication and multi-booting of a Linux system on a development board.

[0005] To achieve the objectives of this invention, the invention is implemented through the following technical solution: a method for secure authentication and multi-booting of a Linux system on a development board, comprising the following steps:

[0006] Step 1: Hardware Trust Root Initialization and Storage Area Division. The hardware security module built into the development board is used as the hardware trust root to generate an asymmetric key pair. Then, the development board storage medium is divided into a boot area, a system area, and an authentication area. The private key is permanently stored in the hardware security area and cannot be exported, while the public key is exported and solidified into the boot area.

[0007] Step 2: Hardware Trust Root Self-Test and Measurement. After powering on the development board, the bootloader calls the hardware trust root to perform a self-test.

[0008] Step 3: Dynamic loading and multi-level authentication of boot items. The bootloader reads all available system partition information from the system area and dynamically generates a list of candidate boot items by combining the boot policy rules of the authentication area. Then, image integrity authentication and digital signature authentication are performed on each candidate system.

[0009] Step 4: Security Context Establishment and System Switching. After successful authentication, the Bootloader loads the target system kernel and initial RAM disk, generates a one-time session key through the hardware root of trust for encryption of inter-system communication, and then triggers system switching through physical buttons, remote commands or timed policies, and re-executes multi-level authentication.

[0010] Step 5: Multi-system isolation and collaboration. Storage isolation is achieved by allocating an independent encrypted partition to each system, resource isolation is achieved by using Linux kernel cgroups and namespaces, and finally, a standardized API is defined for whitelisted systems to communicate and interact collaboratively via one-time session key encrypted communication.

[0011] Step Six: Security Audit and Anomaly Handling. Record the information data of each startup to the tamper-proof storage area of ​​the authentication zone. Then, use blockchain-style chain verification to ensure that the audit log is immutable. If N consecutive authentication failures occur, the hardware root of trust locks the startup function and triggers an alarm. It is necessary to reset through the hardware recovery interface to achieve full-link authentication with the hardware root of trust as the anchor point. Combined with storage and resource isolation mechanisms, it effectively resists malicious image startup and data leakage between systems. At the same time, it can realize dynamic switching of multiple systems on demand and flexibly adapt to scenarios such as debugging, upgrading, and fault recovery. Through the optimized authentication algorithm and lightweight design of resource management, it is adapted to the limited computing power of the development board and can completely record the startup process and abnormal events, which is convenient for tracing illegal operations.

[0012] A further improvement is that the asymmetric key pair generated in step one is an RSA key pair or an ECC key pair, wherein the RSA key length is 2048 bits or more, and the ECC key length is 256 bits or more.

[0013] The further improvement is that the boot area divided in step one is used to store the bootloader, hardware trust root firmware and boot configuration metadata. The boot configuration metadata includes the UUID, boot priority and kernel command line parameter template of each system partition. The bootloader dynamically matches the parameter template according to the system ID and injects it into the kernel.

[0014] The system area allocates an independent encrypted partition for each Linux system to be booted. The independent encrypted partition contains the system kernel, root file system, and partition table. The partition table records the system ID, version number, system image hash value, and encryption key index.

[0015] The authentication area is used to store the system public key whitelist, startup policy rules, and operation audit logs. The startup policy rules include a list of systems that can be started, time window limits, operator permission levels, and system version compatibility checks. The operator's identity is determined by user credentials entered via physical keys, digital certificates for remote commands, or biometric identification. The system version compatibility check ensures that only systems with version numbers within a preset range are allowed to be started.

[0016] Further improvements are made in the following: the self-test in step two includes verifying the integrity of the Bootloader itself and measuring the status of key hardware components, generating measurement logs and storing them in the authentication area, while verifying the integrity of the storage medium partition table and detecting partition tampering by comparing the pre-stored partition table hash value.

[0017] The further improvement lies in the following: In step three, the image integrity authentication is specifically completed by calculating the system image hash value and comparing it with the hash value pre-stored in the system partition table; wherein the system image hash value is the Bootloader hash value and the kernel hash value.

[0018] The further improvement is that: in step three, the digital signature authentication specifically uses the system developer's private key to sign the hash value to generate a digital signature. The Bootloader calls the public key whitelist pre-stored in the authentication area to verify the signature, confirming that the image has not been tampered with and that its source is trustworthy. The public key whitelist is stored according to the system ID index.

[0019] Further improvements are made in the following aspects: In step four, the one-time session key is generated by the random number generator of the hardware root of trust. The session validity period is one system switching cycle, and it is automatically destroyed after expiration. The inter-system communication encryption adopts the AES-GCM mode, and a message authentication code is generated to prevent tampering.

[0020] The further improvement is that: in step four, triggering the system switch specifically involves the current system sending a switch request to the kernel, the system restarting and executing the authentication process in step three to verify the legitimacy of the target system. During the switch, the original system state is saved, the memory data is encrypted and saved using the hardware root of trust derived key, and irrelevant memory areas are cleared before the target system is loaded.

[0021] The encryption method for saving the original system state is to derive a key based on the original system ID using the hardware trust root and encrypt the memory data using the XTS mode. The encrypted data is temporarily stored in the suspended buffer reserved in the system area.

[0022] A further improvement is that the multiple systems in step five include at least two of the following: a production system, a debugging system, a backup system, and a testing system.

[0023] Storage isolation specifically employs the AES-256-XTS algorithm to encrypt multiple systems, with independent keys for different systems. The encryption key for each system partition is dynamically derived by the hardware root of trust based on the system ID and the hardware unique identifier.

[0024] Resource isolation specifically involves limiting CPU / memory quotas for each system through Linux kernel cgroups, isolating peripheral access permissions through namespaces, where peripheral access permissions are configured through Linux kernel udev rules or device trees, prohibiting debugging systems from accessing production data partitions, and limiting network bandwidth quotas for standby systems.

[0025] Further improvements are made in the following ways: the information data for each startup in step six includes system ID, authentication result, operator identity, timestamp, and abnormal event; the tamper-proof storage area adopts a circular log structure, with each log containing the hash value of the previous log, forming a chain-like verification relationship;

[0026] The number of consecutive authentication failures, N, is a configurable parameter. The alarm methods triggered include changes in LED indicator status, buzzer alarms, network SNMP Trap notifications, or email pushes. When the target system fails to start, the Bootloader automatically switches to the previous stable version system ID recorded in the authentication area and records the rollback event in the audit log.

[0027] The beneficial effects of the present invention are as follows: The method of the present invention uses hardware root of trust as the anchor point to realize full-link authentication, and combined with storage and resource isolation mechanisms, it can effectively resist malicious image boot and data leakage between systems. At the same time, it can realize dynamic switching of multiple systems on demand and flexibly adapt to scenarios such as debugging, upgrading, and fault recovery.

[0028] By optimizing the authentication algorithm and the lightweight design of resource management, it is adapted to the limited computing power of the development board and can fully record the startup process and abnormal events, making it easy to trace illegal operations. It provides reliable multi-system operation protection for IoT, industrial control and other scenarios, taking into account both security bottom line and functional flexibility. Attached Figure Description

[0029] Figure 1 This is a flowchart of the multi-startup method of the present invention. Detailed Implementation

[0030] To enhance understanding of the present invention, the present invention will be further described in detail below with reference to embodiments. These embodiments are only used to explain the present invention and do not constitute a limitation on the scope of protection of the present invention.

[0031] With the widespread application of development boards in edge computing, industrial IoT, and other fields, a single operating system can no longer meet diverse needs, such as main business systems, debugging systems, and backup systems. Traditional multi-boot solutions, such as GRUB booting and U-Boot menu selection, have the following drawbacks:

[0032] Insufficient security: Traditional methods do not authenticate startup items, allowing attackers to inject malicious code by tampering with startup configurations or replacing system images.

[0033] Lack of isolation mechanisms: When multiple systems share a storage partition, data is easily leaked to each other, and system crashes may affect other systems.

[0034] Relies on complex configurations: Traditional methods require manual maintenance of the boot menu, kernel parameters, and file system mappings, which can easily lead to boot failures due to configuration errors.

[0035] Lack of auditing capabilities: Traditional methods cannot trace the source of the startup operation, making it difficult to locate illegal startup events.

[0036] Existing solutions such as UEFI-based secure boot, while introducing digital signature verification, rely on specific hardware such as x86 platform UEFI and are not optimized for the needs of limited development board resources and dynamic switching between multiple systems. In particular, they lack support for independent storage of multiple systems and runtime isolation.

[0037] Based on the above, according to Figure 1 As shown, this embodiment provides a method for secure authentication multi-booting of a Linux system on a development board, including the following steps:

[0038] Step 1: Hardware Trust Root Initialization and Storage Area Division. The hardware security module built into the development board is used as the hardware trust root to generate an asymmetric key pair. Then, the development board storage medium is divided into a boot area, a system area, and an authentication area. The private key is permanently stored in the hardware security area and cannot be exported, while the public key is exported and solidified into the boot area.

[0039] The development board is an embedded development board equipped with an ARM Cortex-A series processor, and the storage medium is eMMC, SD card, UFS or SPI Flash;

[0040] The hardware root of trust is the TPM 2.0 chip, RPMB partition, SE security engine, or ARM TrustZone;

[0041] The generated asymmetric key pair is either an RSA key pair or an ECC key pair, wherein the RSA key length is 2048 bits or more, and the ECC key length is 256 bits or more;

[0042] The partitioned boot sector is used to store bootloaders such as U-Boot, hardware trust root firmware, and boot configuration metadata. The boot configuration metadata includes the UUID of each system partition, boot priority, and kernel command line parameter template. The bootloader dynamically matches the parameter template based on the system ID and injects it into the kernel.

[0043] The system area allocates an independent encrypted partition for each Linux system to be booted, containing the kernel and root file system. The independent encrypted partition contains the system kernel, root file system, and partition table. The partition table records the system ID, version number, system image hash value, and encryption key index.

[0044] The authentication area is used to store the system public key whitelist, startup policy rules, and operation audit logs. The startup policy rules include a list of systems that can be started, time window limits, operator permission levels, and system version compatibility checks. The operator's identity is determined by user credentials entered via physical keys, digital certificates for remote commands, or biometric identification. The system version compatibility check ensures that only systems with version numbers within a preset range are allowed to be started.

[0045] Step 2: Hardware Trust Root Self-Test and Measurement. After powering on the development board, the bootloader calls the hardware trust root to perform a self-test.

[0046] The self-test includes verifying the integrity of the Bootloader itself and measuring the status of key hardware components, generating measurement logs and storing them in the authentication area, while verifying the integrity of the storage medium partition table and detecting partition tampering by comparing the pre-stored partition table hash value.

[0047] Its integrity is achieved by comparing the Bootloader hash value pre-stored in the hardware trust root; key hardware components include DDR controllers, storage controllers, etc.

[0048] Step 3: Dynamic loading and multi-level authentication of boot items. The bootloader reads all available system partition information from the system area and dynamically generates a list of candidate boot items by combining the boot policy rules of the authentication area. The boot policy is such as "only allow the boot of the system with ID S1 / S2". Then, image integrity authentication and digital signature authentication are performed on each candidate system.

[0049] Image integrity authentication is specifically accomplished by calculating the system image hash value, such as SHA-256 or SHA-3, and comparing it with the hash value pre-stored in the system partition table; where the system image hash value is the Bootloader hash value and the kernel hash value.

[0050] Digital signature authentication specifically involves using the system developer's private key to sign the hash value and generate a digital signature. The Bootloader then calls the public key whitelist pre-stored in the authentication area to verify the signature, confirming that the image has not been tampered with and that its source is trustworthy. The public key whitelist is stored indexed by system ID.

[0051] Step 4: Security Context Establishment and System Switching. After successful authentication, the Bootloader loads the target system kernel and initial RAM disk, generates a one-time session key through the hardware root of trust for encryption of inter-system communication, and then triggers system switching through physical buttons, remote commands or timed policies, and re-executes multi-level authentication.

[0052] The one-time session key is generated by a random number generator from a hardware root of trust. The session is valid for one system switch cycle and is automatically destroyed after expiration. Inter-system communication encryption uses AES-GCM mode, and a message authentication code is generated to prevent tampering.

[0053] The system switching is triggered by the current system sending a switching request to the Bootloader. The Bootloader then re-executes the authentication process in step three to verify the legitimacy of the target system and completes the switching. During the switching, the original system state is saved, and the memory data is encrypted and saved using the hardware root of trust derived key. Irrelevant memory areas are cleared before the target system is loaded.

[0054] The encryption method for saving the original system state is that the hardware trust root derives a key based on the original system ID and uses XTS mode to encrypt the memory data. The encrypted data is temporarily stored in the storage buffer reserved in the system area.

[0055] Step 5: Multi-system isolation and collaboration. Storage isolation is achieved by allocating an independent encrypted partition to each system, and resource isolation is achieved by using Linux kernel cgroups and namespaces. Finally, a standardized API is defined for whitelisted systems to communicate and interact collaboratively via one-time session key encryption. The whitelist supports dynamic updates, which require signature verification of update requests through a hardware root of trust. Update operations are recorded in the audit log and trigger alarms.

[0056] The system includes at least two of the following: production system, debugging system, backup system, and testing system. The capacity of each system partition is dynamically allocated according to functional requirements, and the total capacity of the system partition does not exceed 80% of the storage medium capacity.

[0057] Storage isolation specifically employs the AES-256-XTS algorithm to encrypt multiple systems, with independent keys for different systems. The encryption key for each system partition is dynamically derived by the hardware root of trust based on the system ID and the hardware unique identifier.

[0058] Resource isolation specifically involves limiting CPU / memory quotas for each system through Linux kernel cgroups, isolating peripheral access permissions through namespaces, such as prohibiting unauthorized systems from accessing sensitive partitions, where peripheral access permissions are configured through Linux kernel udev rules or device trees, prohibiting debugging systems from accessing production data partitions, and limiting network bandwidth quotas for standby systems.

[0059] Step 6: Security Audit and Anomaly Handling. Record the information data of each startup to the tamper-proof storage area of ​​the authentication area. Then, use blockchain-style chain verification to ensure that the audit log is tamper-proof. If there are N consecutive authentication failures, the hardware root of trust will lock the startup function and trigger an alarm. It is necessary to reset through the hardware recovery interface, which is a combination of physical buttons or a dedicated debugging port.

[0060] Each startup data includes system ID, authentication result, operator identity (e.g., local key press / remote IP), timestamp, and abnormal events;

[0061] The tamper-proof storage area adopts a circular log structure, where each log entry contains the hash value of the previous log entry, forming a chain of verification relationships.

[0062] The number of consecutive authentication failures N is a configurable parameter, with a default value of 3. The alarm methods triggered include changes in LED indicator status, buzzer alarm, network SNMP Trap notification, or email push.

[0063] When the target system fails to start, the Bootloader automatically switches to the previous stable version system based on the system ID recorded in the authentication area and records the rollback event in the audit log.

[0064] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely illustrative of the principles of the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the present invention as claimed. The scope of protection of the present invention is defined by the appended claims and their equivalents.

Claims

1. A development board Linux system security authentication multi-starting method, characterized in that, The method comprises the following steps: Step one, hardware root of trust initialization and storage partitioning, using the built-in hardware security module of the development board as the hardware root of trust, generating an asymmetric key pair, and then dividing the storage medium of the development board into a boot area, a system area and an authentication area, permanently storing the private key in the hardware security area which cannot be exported, and exporting and solidifying the public key to the boot area; Step two, hardware root of trust self-checking and measurement, after powering on the development board, the Bootloader calls the hardware root of trust to perform self-checking; Step three, starting item dynamic loading and multi-level authentication, the Bootloader reads all available system partition information from the system area, dynamically generates a candidate starting item list in combination with the starting strategy rules of the authentication area, and then performs image integrity authentication and digital signature authentication on each candidate system; Step four, secure context establishment and system switching, after authentication, the Bootloader loads the target system kernel and initial RAM disk, generates a one-time session key through the hardware root of trust for system-to-system communication encryption, and then triggers the switching of the system through a physical key, a remote instruction or a timing strategy, and re-executes the multi-level authentication; Step five, multi-system isolation and cooperation, each system is allocated an independent encrypted partition for storage isolation, then resource isolation is performed with the help of Linux kernel cgroups and namespaces, and finally a standardized API is defined for white-listed systems to communicate with each other through the one-time session key encryption; Step six, security audit and exception handling, information data of each start is recorded to the tamper-proof storage area of the authentication area, and then a blockchain-like chain check is adopted to ensure that the audit log is tamper-proof, if there are N consecutive authentication failures, the hardware root of trust locks the starting function and triggers an alarm, which needs to be reset through the hardware recovery interface.

2. The development board Linux system security authentication multi-starting method of claim 1, wherein: The asymmetric key pair generated in step one is an RSA key pair or an ECC key pair, wherein the RSA key length is 2048 bits or more, and the ECC key length is 256 bits or more.

3. The development board Linux system security authentication multi-starting method of claim 1, wherein: The boot area divided in step one is used to store the Bootloader, the hardware root of trust firmware and the starting configuration metadata, wherein the starting configuration metadata includes the UUID, the starting priority, the kernel command line parameter template of each system partition, and the Bootloader dynamically matches the parameter template and injects the kernel according to the system ID; The system area allocates an independent encrypted partition for each Linux system to be started, and the independent encrypted partition contains the system kernel, the root file system and the partition table, and the partition table records the system ID, the version number, the system image hash value and the encryption key index; The authentication area is used to store the system public key white list, the starting strategy rules and the operation audit log, wherein the starting strategy rules include the list of systems allowed to start, the time window limit, the operator permission level and the system version compatibility check, the identity of the operator is determined through the user credentials input by the physical key, the digital certificate of the remote instruction or the biometric recognition, and the system version compatibility check allows only the system whose version number is within the preset range to start.

4. The development board Linux system security authentication multi-booting method of claim 1, wherein: The self-checking in the step two includes verifying the integrity of the Bootloader itself and the state of the key hardware components, generating a measurement log and storing it in the authentication area, verifying the integrity of the storage medium partition table, and detecting partition tampering by comparing a pre-stored partition table hash value.

5. The development board Linux system security authentication multi-booting method of claim 1, wherein: The mirror integrity authentication in the step three is specifically completed by calculating a system image hash value and comparing it with a pre-stored hash value in the system partition table; wherein the system image hash value is a Bootloader hash value and a kernel hash value.

6. The development board Linux system security authentication multi-booting method of claim 1, wherein: The digital signature authentication in the step three is specifically completed by signing the hash value using a system developer private key to generate a digital signature, and Bootloader calling a pre-stored public key whitelist in the authentication area to verify the signature, confirming that the image has not been tampered with and the source is trustworthy, wherein the public key whitelist is stored according to the system ID.

7. The development board Linux system security authentication multi-booting method of claim 1, wherein: The one-time session key in the step four is specifically generated by a random number generator of the hardware root of trust, the session validity period is a single system switching cycle, and it is automatically destroyed after expiration; the system-to-system communication encryption adopts the AES-GCM mode, and a message authentication code is generated to prevent tampering.

8. The development board Linux system security authentication multi-booting method of claim 1, wherein: The step four triggers the switching of the system, specifically, after the current system sends a switching request to the kernel, the system restarts and performs the authentication process of step three to verify the legitimacy of the target system, the state of the original system is saved, the memory data is encrypted and saved by the hardware root of trust derived key, and the target system is loaded before the irrelevant memory area is emptied; The encryption method of the original system state saving is that the hardware root of trust derives a key according to the original system ID, encrypts the memory data in the XTS mode, and temporarily stores the encrypted data in the suspended buffer area reserved in the system area.

9. The development board Linux system security authentication multi-booting method of claim 1, wherein: The multiple systems in the step five include at least two of the production system, the debugging system, the standby system, and the test system. The storage isolation is specifically to encrypt the multiple systems using the AES-256-XTS algorithm, and the keys of different systems are independent, and the encryption key of each system partition is dynamically derived by the hardware root of trust according to the system ID and the hardware unique identifier; The resource isolation is specifically to limit the CPU / memory quota of each system through the Linux kernel cgroups, and to isolate the peripheral access permission through the namespaces, wherein the peripheral access permission is configured through the Linux kernel udev rule or the device tree, the production data partition is prohibited to be accessed by the debugging system, and the network bandwidth quota of the standby system is limited.

10. The development board Linux system security authentication multi-booting method of claim 1, wherein: The information data of each start in the step six includes the system ID, the authentication result, the operator identity, the timestamp, and the abnormal event; the anti-tampering storage area adopts a circular log structure, each log contains a hash value of the previous log, forming a chain check relationship; The number of consecutive authentication failures N is a configurable parameter, and the triggered alarm modes include the state change of the LED indicator, the buzzer alarm, the network SNMP Trap notification, or the email push; when the target system fails to start, the Bootloader automatically switches to the last stable version system according to the system ID recorded in the authentication area, and records the rollback event to the audit log.

Images