A method for verifying the trustworthiness of a system program based on an edge Internet of Things proxy device

Abstract

The present application relates to a method for verifying the trust level of a system program based on an edge Internet of Things proxy device, including the following specific steps: Considering the characteristic that the one-time programmable memory eFuse can only be programmed once, the hash value of the secure root key SRK based on the eFuse characteristic is burned in and used as the root of trust; Starting from the boot of the operating system, multi-level verification is carried out until the trust level verification program for boot-up is completed to ensure the security of the boot of the operating system. Based on the premise of being granted credit by the "trust level verification program", the present application verifies the trust levels of the system's built-in application programs and newly added application programs later, eliminating the risk that the traditional "whitelist" protection mechanism loses its protection effectiveness due to the uncontrollability of the secure boot of the operating system, and fundamentally solving the trust problem of the programs running within the system.

Description

Technical Field

[0001] This application relates to the field of power communication technologies, and particularly to a method for verifying the trust level of a system program based on an edge Internet of Things proxy device. Background Art

[0002] Through the analysis of security incidents of edge Internet of Things proxy devices in recent years, malicious code penetration attacks and means of implanting or disguising system programs (note: system programs specifically refer to system service programs in this solution) for attacks have become increasingly fierce. How to protect against such attack means has become a hot research topic in recent years.

[0003] Currently, the more recognized method for protecting system programs is to use the program "whitelist" method. However, this is far from enough. Since the implementation method of the "whitelist" can only ensure that the system program is trustworthy on the premise that the operating system starts securely. If an attacker changes the startup parameters of the system, obtains root privileges, or replaces the root file system and the operating system during the startup process of the operating system, the whitelist mechanism will lose its protection effect. Summary of the Invention

[0004] The purpose of the embodiments of this application is to provide a method for verifying the trust level of a system program based on an edge Internet of Things proxy device, so as to solve the security risks caused by the existing "whitelist" protection mechanism being unable to cope with the insecure startup of the operating system.

[0005] To achieve the above purpose, this application provides the following technical solutions:

[0006] The embodiments of this application provide a method for verifying the trust level of a system program based on an edge Internet of Things proxy device, including the following specific steps:

[0007] In view of the characteristic that the one-time programmable memory eFuse can only be programmed once, burn in the hash value of the security root key SRK based on the eFuse characteristic, and use this as the root of trust;

[0008] Starting from the startup of the operating system, perform multi-level verification until the trust level verification program for startup is completed to ensure the security of the startup of the operating system.

[0009] The specific operation of burning in the hash value of the SRK based on the eFuse characteristic and using this as the root of trust is as follows:

[0010] Write the hash value of the SRK into the eFuse and use this as the root of trust;

[0011] Based on the edge IoT proxy hardware, SRK and the corresponding private key are generated, and the hash value of SRK is written into the one-time programmable memory eFuse. SRK is packaged into uboot, and the private key corresponding to SRK signs uboot, and the signature is packaged into uboot. Bootrom reads the SRK in uboot, calculates the hash value of SRK, and compares it with the hash value in efuse. If they are consistent, it means that SRK is legal, and then the next level of authentication is performed based on SRK.

[0012] Write different public keys into the uboot image, operating system image, and trust verification program respectively;

[0013] Sign the uboot image with the private key corresponding to the SRK of eFuse;

[0014] Bootrom uses SRK to verify the signature at the end of the system boot program uboot file. If the signature verification is successful, the boot will continue, otherwise it will terminate;

[0015] Sign the operating system with the uboot image private key;

[0016] Use the public key in uboot to verify the signature at the end of the operating system. If the signature verification is successful, the operating system will be started, otherwise it will be terminated. Since the root file system is also inside the operating system, this process also ensures the credibility of the root file system;

[0017] Sign the trust verification program with the operating system private key;

[0018] Use the public key in the operating system to verify the signature at the end of the trust verification program file. If the verification succeeds, the trust verification program is started, otherwise the system hangs.

[0019] The multi-level verification is performed from the start of the operating system until the trust verification program for booting is completed, ensuring the security of the operating system startup. Specifically,

[0020] The system comes with trusted authentication for applications;

[0021] After the trust verification program is started, the trusted program list is verified. If the verification fails, the system exits.

[0022] The trust verification program loads the kernel startup process interception module and writes the hash value of each system program in the trusted program list to the kernel space;

[0023] The trust verification program starts the system program;

[0024] The kernel intercepts the system call to start the system program, calculates the hash value of the system program at this time according to the path of the started system program, and compares this hash value with the hash value inside the trusted program list. If they are the same, it is legal; otherwise, it is illegal. If it is illegal, the startup is prohibited.

[0025] Subsequently, add the trusted verification of application programs.

[0026] Signature information signed with the private key needs to be added at the end of such system programs. The private key is the private key corresponding to the public key in the trust verification program.

[0027] The trust verification program verifies the signature of the system program. If the signature verification is successful, the hash value of the system program is written into the trusted program list, and the signature information of the trusted program list is updated.

[0028] The trust verification program synchronously updates the trusted program list in the kernel space memory.

[0029] The trust verification program starts this system program.

[0030] The kernel intercepts the system call to start the system program, calculates the hash value of the system program at this time according to the path of the started system program, and compares this hash value with the hash value inside the trusted program list. If they are the same, it is legal; otherwise, it is illegal. If it is illegal, the startup is prohibited.

[0031] Compared with the prior art, the beneficial effects of the present invention are:

[0032] The present invention is based on the eFuse public key as the trust root, and combines the public and private key signature authentication of Uboot, the operating system, and the "trust verification program" to create a secure and trusted operating system startup environment. The "trust verification program" scans and identifies the startup program and incorporates it into the trusted program list file. At the same time, the application programs in the trusted program list are signed with the private key. Subsequently, the startup program and the newly added application programs are verified by the public key to ensure the legality of the running programs. The trusted program list is placed in the operating system kernel memory, and the hash values of each system program in the trusted program list are written into the kernel space to construct the "kernel startup program interception" module, striving to filter the application programs from the system startup stage and effectively ensuring the security of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following will briefly introduce the drawings required to be used in the embodiments of the present application. It should be understood that the following drawings only show some embodiments of the present application, and therefore should not be regarded as limiting the scope. For those of ordinary skill in the art, other related drawings can also be obtained based on these drawings without creative efforts.

[0034] Figure 1 Flow chart of a method for verifying the trust level of a system program based on an edge Internet of Things agent device provided for the application;

[0035] Figure 2 Flow chart of the secure boot of the operating system provided for the application;

[0036] Figure 3 Flow chart of a method for verifying the boot program provided for the application;

[0037] Figure 4 Flow chart of the verification of the newly added system program provided for the application. Specific implementation manners

[0038] The technical solutions in the embodiments of the present application will be described below with reference to the accompanying drawings in the embodiments of the present application. It should be noted that: similar reference numerals and letters denote similar items in the following drawings. Therefore, once an item is defined in one drawing, it does not need to be further defined and explained in subsequent drawings.

[0039] The term "including", "comprising" or any other variant thereof is intended to cover a non-exclusive inclusion, such that a process, method, article or device including a series of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article or device. Without further limitation, an element defined by the phrase "including a..." does not exclude the existence of additional identical elements in the process, method, article or device including the element.

[0040] The terms "first", "second", etc. are only used to distinguish one entity or operation from another entity or operation, and cannot be construed as indicating or implying relative importance, nor can it be construed as requiring or implying any actual relationship or order between these entities or operations.

[0041] See Figure 1 , which is the flow chart of a method for verifying the trust level of a system program based on an edge Internet of Things agent device provided for the application. It can be seen that the present application provides burning the hash value of the secure root key SRK into the eFuse to construct the trust root of the edge Internet of Things agent device system; burning different public keys into Uboot, the operating system, and the trust level verification program, and based on the trust root, performing hierarchical signature and hierarchical verification to construct a secure and reliable operating system startup environment; constructing a "kernel authentication" level whitelist protection mechanism through the trust level verification program, striving to filter application programs from the system startup stage, and effectively ensuring the security of the system. The trust level authentication method includes:

[0042] S1: Set the eFuse public key as the root of trust, and perform multi-level authentication starting from the boot of the operating system to ensure the secure boot of the operating system;

[0043] S11: Write the hash value of the secure root key SRK into the eFuse and use it as the root of trust

[0044] S12: Write different public keys into the uboot image, the operating system image, and the trust verification program respectively;

[0045] S13: Sign the uboot image with the private key of the eFuse

[0046] S14: Sign the operating system with the private key of the uboot image

[0047] S15: Sign the "trust verification program" with the private key of the operating system

[0048] S2: Trust verification of application programs

[0049] S21: Trust verification of system-built-in application programs

[0050] S22: Add trust verification of subsequent application programs.

[0051] See Figure 2 , the flowchart of the secure boot of the operating system provided by this application. It can be seen that the process of screening the secure boot of the operating system is as follows:

[0052] S1: Set the eFuse public key as the root of trust, and perform multi-level authentication starting from the boot of the operating system to ensure the secure boot of the operating system;

[0053] S11: Write the public key into the eFuse and use it as the root of trust

[0054] S111: Based on the edge IoT agent hardware, generate a pair of public and private keys, write the public key into the eFuse (one-time programmable memory), and use this public key as the root for the next-level authentication.

[0055] S12: Write different public keys into the uboot image, the operating system image, and the "trust verification program" respectively;

[0056] S13: Sign the uboot image with the private key of the eFuse

[0057] S131: The bootrom reads the public key in the eFuse and verifies the signature at the end of the uboot (system bootloader, similar to the BIOS in Windows) file. If the verification is successful, continue to boot; otherwise, terminate.

[0058] S14: Sign the operating system with the uboot image private key

[0059] S141: Use the public key in uboot to verify the signature at the end of the operating system. If the signature verification is successful, the operating system is started, otherwise it is terminated. Since the root file system is also inside the operating system, this process also ensures the credibility of the root file system.

[0060] S15: Sign the "trust verification program" with the operating system private key

[0061] S151: Use the public key in the operating system to verify the signature at the end of the "trust verification program" file. If the verification is successful, the "trust verification program" is started, otherwise the system hangs.

[0062] See also Figure 3 , which is a flow chart of the method for verifying the screening startup program provided in this application, it can be seen that the process of verifying the screening startup program is as follows:

[0063] S21: System-provided application trusted verification

[0064] S211: After the "trust verification program" is started, the trusted program list is verified. If the verification fails, the system exits.

[0065] S212: The "trust verification program" loads the "kernel startup process interception" module and writes the hash value of each system program in the trusted program list into the kernel space.

[0066] S213: The “trust verification program” starts the system program.

[0067] S214: The kernel intercepts the system call to start the system program, calculates the hash value of the system program at this time according to the path of the started system program, and compares this hash value with the hash value in the trusted program list. If they are consistent, it is legal, otherwise it is illegal. If it is illegal, startup is prohibited.

[0068] See also Figure 4 , which is a flow chart of the method for screening new system program verification provided by this application, it can be seen that the process of screening new system program verification is as follows:

[0069] S22: Application trust verification will be added later.

[0070] S221: At the end of such system programs, signature information signed with a private key needs to be added. The private key is the private key corresponding to the public key in the "Trust Verification Program".

[0071] S222: The "Trust Verification Program" verifies the signature of the system program. If the signature verification is successful, it writes the hash value of the system program into the trusted program list and updates the signature information of the trusted program list.

[0072] S223: The "Trust Verification Program" synchronously updates the trusted program list in the kernel space memory.

[0073] S224: The "Trust Verification Program" starts this system program.

[0074] S225: When the kernel intercepts the system call to start the system program, it calculates the hash value of the system program at this time according to the path of the started system program, and compares this hash value with the hash value inside the trusted program list. If they are the same, it is legal; otherwise, it is illegal. If it is illegal, the startup is prohibited.

[0075] The trust verification method, as one of the methods for constructing the whitelist security mechanism, overcomes the deficiency of other whitelist software protection methods in lacking the guarantee ability for the secure startup of the operating system, verifies and filters the startup program from the kernel layer, moves the gateway of host protection forward, truly provides a trusted host environment for the edge IoT agent device system, and effectively guarantees the security of the system. It provides a technical basis for the subsequent research on similar host-level security protection measures.

[0076] The key core points of this method include constructing a secure and reliable operating system startup environment and a kernel-level whitelist protection mechanism based on the "Trust Verification Program".

[0077] The technologies for constructing a secure and reliable operating system startup environment include:

[0078] Based on the characteristics of efuse that it can only be burned once and the source code is not public, burn in the public key to create the trust root; set different public and private keys for Uboot, the operating system, and the "Trust Verification Program", and conduct hierarchical verification in combination with the trust root to ensure the security of the operating system startup.

[0079] The technical points of the kernel-level whitelist protection mechanism based on the "Trust Verification Program" include:

[0080] The "Trust Verification Program" scans and identifies the startup program and incorporates it into the trusted program list file. At the same time, it signs the application programs in the trusted program list with the private key. The subsequent startup programs and newly added application programs are verified through the public key to ensure the legality of the running programs. The trusted program list is placed in the operating system kernel memory, and the hash values of each system program in the trusted program list are written into the kernel space to construct the "Kernel Startup Program Interception" module, striving to filter the application programs from the system startup stage and effectively guarantee the security of the system.

[0081] The present application provides a trustworthiness verification method based on the system program of an edge Internet of Things proxy device. Taking eFuse as the trust root, a trust system for the edge Internet of Things proxy device system is constructed. Starting from the boot of the operating system, multi-level verification is carried out until the "trustworthiness verification program" for boot-up is verified, and a secure boot environment for the operating system is constructed; in the environment of the secure boot of the operating system, a whitelist protection mechanism based on the "trustworthiness verification program" is constructed. When the device leaves the factory, all running programs of the system are scanned, these running programs are written into a trusted program list file, and the trusted program list is signed with the private key corresponding to the public key stored in the "trustworthiness verification program", and the signature is written at the end of the trusted program list for subsequent signature verification. Subsequent application programs are allowed to run after being verified by the "trustworthiness verification program".

[0082] The above are only the embodiments of the present application and are not intended to limit the protection scope of the present application. For those skilled in the art, the present application can have various changes and modifications. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims

1. A method for verifying the trust level of a system program based on an edge IoT agent device, characterized in that The specific steps include: In view of the fact that the one-time programmable memory eFuse can only be burned once, the hash value of the secure root key SRK based on the eFuse feature is burned in and used as the root of trust; Starting from the startup of the operating system, multi-level verification is performed until the trust verification program of the boot is completed to ensure the security of the operating system startup; The method of burning the hash value of the SRK based on the eFuse feature and using it as the root of trust is as follows: Write the hash value of SRK in eFuse and use it as the root of trust; Based on the edge IoT proxy hardware, SRK and the corresponding private key are generated, and the hash value of SRK is written into the one-time programmable memory eFuse. SRK is packaged into uboot, and the private key corresponding to SRK signs uboot, and the signature is packaged into uboot. Bootrom reads the SRK in uboot, calculates the hash value of SRK, and compares it with the hash value in efuse. If they are consistent, it means that SRK is legal, and then the next level of authentication is performed based on SRK. Write different public keys into the uboot image, operating system image, and trust verification program respectively; Sign the uboot image with the private key corresponding to the SRK of eFuse; Bootrom uses SRK to verify the signature at the end of the system boot program uboot file. If the signature verification is successful, the boot will continue, otherwise it will terminate; Sign the operating system with the uboot image private key; Use the public key in uboot to verify the signature at the end of the operating system. If the signature verification is successful, the operating system will be started, otherwise it will be terminated. Since the root file system is also inside the operating system, this process also ensures the credibility of the root file system; Sign the trust verification program with the operating system private key; Use the public key in the operating system to verify the signature at the end of the trust verification program file. If the verification succeeds, the trust verification program is started, otherwise the system hangs.

2. The trustworthiness verification method for a system program of an edge Internet of Things proxy device according to claim 1, wherein The multi-level verification is performed from the start of the operating system until the trust verification program for booting is completed, ensuring the security of the operating system startup. Specifically, The system comes with trusted authentication for applications; After the trust verification program is started, the trusted program list is verified. If the verification fails, the system exits. The trust verification program loads the kernel startup process interception module and writes the hash value of each system program in the trusted program list to the kernel space; The trust verification program starts the system program; The kernel intercepts the system call to start the system program, calculates the hash value of the system program at this time according to the path of the started system program, and compares this hash value with the hash value in the trusted program list. If they are consistent, it is legal, otherwise it is illegal. If it is illegal, it is prohibited to start; The application trust verification will be added later; At the end of such system programs, signature information signed with a private key needs to be added. The private key is the private key corresponding to the public key in the trust verification program. The trust verification program verifies the signature of the system program. If the signature verification is successful, it writes the hash value of the system program into the trusted program list and updates the signature information of the trusted program list. The trust verification program synchronously updates the trusted program list in the kernel space memory. The trust verification program starts this system program. The kernel intercepts the system call to start the system program. According to the path of the started system program, it calculates the hash value of the system program at this time and compares this hash value with the hash value inside the trusted program list. If they are the same, it is legal; otherwise, it is illegal. If it is illegal, the startup is prohibited.

Images