CN111625846B - System state recording method of mobile terminal equipment - Google Patents
System state recording method of mobile terminal equipment Download PDFInfo
- Publication number
- CN111625846B CN111625846B CN202010331686.8A CN202010331686A CN111625846B CN 111625846 B CN111625846 B CN 111625846B CN 202010331686 A CN202010331686 A CN 202010331686A CN 111625846 B CN111625846 B CN 111625846B
- Authority
- CN
- China
- Prior art keywords
- trusted
- code
- content
- mobile terminal
- status register
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/604—Tools and structures for managing or administering access control systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D30/00—Reducing energy consumption in communication networks
- Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks
Abstract
The invention discloses a system state recording method of mobile terminal equipment, which belongs to the technical field of mobile terminal state recording methods and is characterized in that software and hardware information loaded at each stage in the starting process of a mobile terminal is stored in a non-rewritable and modified manner based on a register with a specially designed trusted root, so that all started software and hardware resource records in a system are established. Because the record can be reset only when the system is restarted and the power supply is reset, even if a system has a vulnerability, an attacker acquires the system authority, the record before and during the attack cannot be erased, and the purpose of identifying the state of the terminal is achieved. When the record is exported from the trusted root, the signature can be carried out through the cipher equipment and the private key arranged in the trusted root, so that the record has the characteristics of being unable to forge, repudiation and falsification by middle people, the detection of the attack is realized, and the safety and the controllability of the system are improved.
Description
Technical Field
The invention relates to the technical field of mobile terminal state recording methods, in particular to a system state recording method of mobile terminal equipment.
Background
At present, the mobile terminal and the scene application thereof have remarkable effects in the aspect of industrial application, are more and more widely used in public security, transportation, politics and other industries, and are often defined as special mobile terminal equipment (such as handheld intelligent mobile police terminal equipment used in the public security industry). With popularization of special mobile terminal equipment and national regulations and requirements for information security, demands for system security protection, state monitoring, reliability and the like of the mobile terminal equipment are increasingly emerging.
The system security state and security protection of the existing mobile terminal equipment are more application-level security policies and measures (such as application sandboxes), and the system-level security policies and measures have larger technical scheme defects in the aspects of system-level, especially bottom software and hardware driving layers, startup powering-up and security state recording and measurement in the system loading process, so that the prior art cannot express and report terminal state changes and corresponding security risks caused by injection attacks, malicious applications, trojan horse attacks and the like possibly suffered after the system startup is completed.
Disclosure of Invention
The invention aims to provide a system state recording method of mobile terminal equipment, so as to solve the problems in the background technology.
In order to achieve the above purpose, the present invention provides the following technical solutions: a system state recording method of mobile terminal equipment based on a register with a specially designed trusted root, which stores the software and hardware information loaded at each stage in the starting process of the mobile terminal in a non-rewritable and modified way, thereby establishing all the started software and hardware resource records in the system. Because the record can be reset only when the system is restarted and the power supply is reset, even if a system has a vulnerability, an attacker acquires the system authority, the record before and during the attack cannot be erased, and the purpose of identifying the state of the terminal is achieved. When the record is exported from the trusted root, the record can be signed by the cryptographic equipment and the private key which are built in the trusted root, so that the record has the characteristics of being non-counterfeitable, non-repudiation and non-falsification by middle people.
The effectiveness of the present invention depends on the following three conditions:
1. there is a trusted status register that can be cleared for reset only when the system is restarted, and the power is reset. In the running process of the system, the register does not accept the copying and modifying request and can only carry out expansion writing (or addition writing) through a specific interface;
2. the register can be linked with the cryptographic device and the cryptographic resource, and the content stored in the register and the externally input extension information (data input by an upper user) can be signed (user in the cryptographic device or other certificate). The signature flow and the corresponding certificate are packaged in the trusted root and can not be directly called or modified by external functions;
3. after the system is powered up or restarted, the code that was first loaded and booted (hereinafter primary boot code) cannot be modified.
According to the relevant technical scheme and standard of the trusted computing in China, the three conditions can be met by the trusted root devices in different forms at different security levels, and the trusted root function framework in the requirements of the invention is shown in the attached figure 1.
The main working flow of the invention comprises two parts of recording the trusted state and generating the trusted static state report, and the flow is shown in figure 4, wherein the two typical flows are used for recording the trusted state according to different terminal trusted function realization forms.
Firstly, on a complete trusted terminal with a trusted boot function, the method comprises the following specific steps:
step 1: the device is powered on and started, firstly, an operating code (marked as a first-stage boot code) is loaded, a hardware ID driven by the code is obtained and written into a trusted state register, then, a hash value of a work code (marked as a second-stage loading code) to be loaded is calculated, the hash value is written into the trusted state register, and after the writing is successful, the second-stage loading code is loaded and the system control right is handed over;
step 2: the second-level loading code obtains the hardware ID driven by the second-level loading code, writes the hardware ID into a trusted state register, calculates a hash value of a subsequent working code (marked as a third-level loading code) to be loaded, and writes the hash value into the trusted state register;
step 3: repeating the above operation until the loading of the operating system and the core service of the mobile terminal is completed.
Secondly, on the trusted enhancement terminal realized by modifying firmware or software, the condition of establishing a complete trusted support mechanism is not provided, and the program can be reversely measured and executed by a subsequently started program to generate equipment and system state records. In this case, the security capability of the system is equivalent to that of the measurement start point. The typical flow is as follows:
step 1: the device is powered on, loads various firmware and software and runs (recorded as first to N levels of loading codes);
step 2: when loading is carried out to the (N+1) -th stage, the trusted module is started, the hardware ID driven by the trusted module is obtained, and the hardware ID is written into a trusted status register;
step 3: the trusted module sequentially calculates hash values of the loaded first to N stages of loading codes and writes the hash values into a trusted status register;
step 4: the trusted module calculates the hash value of the N+2 level code loaded subsequently and writes the hash value into a trusted state register, and loads and executes the N+2 level code after the hash value is written successfully, so as to transfer the control right of the system;
step 5: repeating the above operation until the loading of the operating system and the core service of the mobile terminal is completed.
The writing of the trusted status register in the above steps includes two modes of expansion writing and addition writing, and both the two modes and the variation and combination mode derived based on the two modes are all within the protection scope of the patent.
The step of expanding writing is as follows:
step 1: receiving the content which is input externally and needs to be expanded and written into the W, reading the content of a trusted status register, and marking the content as O;
step 2: combining the content W needing to be expanded and written with the read trusted status register content O, marking as { O|W }, calculating a hash value of the content W, and marking as H { O|W };
step 3: h { O|W } is written into the trusted status register, and whether the write operation is successful is returned to the outside.
The step of adding the write is:
step 1: the content which is input from the outside and needs to be expanded and written is W, and the length of the content which is recorded at present and is read by a trusted status register is recorded as L0;
step 2: writing the content W at the end of the register used content (typically at the L0+1 character from the register header);
step 3: the length of W is calculated as WL, the recorded content length is updated as L0+WL, and whether the writing operation is successful is returned to the outside.
The flow of generating the trusted static status report is shown in fig. 6, and the specific steps are as follows:
step 1: receiving additional report information in an externally generated trusted static status report request, denoted as a (this additional information may be null information);
step 2: reading the content of a trusted status register, namely O, and combining the trusted status register with external additional report information, namely { O|A };
step 3: calling a mobile terminal trusted static state report private key, signing the information, and recording the information as Sig { O|A };
step 4: and outputting the signed terminal trusted static state report Sig { O|A } to an external caller, and ending the flow.
Compared with the prior art, the invention has the beneficial effects that:
1. on the basis of the characteristics of unique file format, fixed operation system updating mode, system updating content and fixed sequence of the mobile terminal equipment, on one hand, the logic for acquiring the trusted state is changed from passive calling to active checking, the system safety and configurability are enhanced, meanwhile, checking content is further refined, checking points are added, when the system state needs to be judged, the current state is judged according to the state when loaded, and the state information is included in a trusted static state report, so that the detection of the attack is realized;
2. the invention can generate a report describing the hardware state of the terminal and the integrity state of the operating system and the bottom system service (bottom software which can be modified only by OTA upgrade in normal operation) based on the trusted register extension characteristic of the trusted root, the report uniquely characterizes the terminal identity based on the terminal hardware ID and records the integrity of the main hardware and the bottom core software driven in the system starting process, and meanwhile, the report is signed and protected by a built-in certificate of the trusted root equipment, and has the same security intensity and reliability as those of the first-stage guide code and the internal storage space of the trusted root;
3. the invention discloses a mobile terminal device and a recording method of system state, which describe the state of the system when the system is started by the hash value of the running firmware and software in the system through the hardware information of the mobile terminal, support the generation of a trusted static state report with password guarantee and trusted root security protection strength, and support the addition of externally defined extension content in the report. Through the report, the manager can judge the trusted state of the current terminal, thereby improving the safety and the controllability of the system.
Drawings
FIG. 1 is a functional framework of the root of trust of the present invention;
FIG. 2 is a diagram of a conventional root of trust architecture framework;
FIG. 3 is a schematic diagram of a trusted TPM-based boot of the prior art;
FIG. 4 is a primary workflow diagram of the present invention;
FIG. 5 is a flowchart illustrating the recording system status operation of the present invention;
FIG. 6 is a flow chart of the trusted static status report generation workflow of the present invention.
Detailed Description
The following description of the embodiments of the present invention will be made clearly and completely with reference to the accompanying drawings, in which it is apparent that the embodiments described are only some embodiments of the present invention, but not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the invention without making any inventive effort, are intended to be within the scope of the invention.
Trusted computing technology: based on special software and hardware, the password is used as a support, and the information security technology with reliable information system and application state is ensured.
Trusted software base: and a set of trusted software modules for realizing the control of checking and measuring the hardware, the operating system and the application program on the terminal based on the trusted root.
Prior art implementation scheme
Referring to fig. 2 and 3, existing technologies such as mobile device management, online asset management, mobile application management, and remote access management all need to identify the identity of the managed device, but only trusted computing technologies currently can further provide status identification of the managed device, as shown in fig. 2, in the conventional TCG standard, the status from power-up to completion of the system is recorded by a trusted root, and a signature and reporting mechanism, and a conventional trusted root structure frame diagram is shown in fig. 3, where the conventional technologies cannot express and report a terminal status change and a corresponding security risk caused by injection attack, malicious application, trojan and other attacks that may be suffered after the system is started.
The invention provides a technical scheme that: a system state recording method of mobile terminal equipment based on a register with a specially designed trusted root, which stores the software and hardware information loaded at each stage in the starting process of the mobile terminal in a non-rewritable and modified way, thereby establishing all the started software and hardware resource records in the system. Because the record can be reset only when the system is restarted and the power supply is reset, even if a system has a vulnerability, an attacker acquires the system authority, the record before and during the attack cannot be erased, and the purpose of identifying the state of the terminal is achieved. When the record is exported from the trusted root, the record can be signed by the cryptographic equipment and the private key which are built in the trusted root, so that the record has the characteristics of being non-counterfeitable, non-repudiation and non-falsification by middle people.
The effectiveness of the present invention depends on the following three conditions:
1. there is a trusted status register that can be cleared for reset only when the system is restarted, and the power is reset. In the running process of the system, the register does not accept the copying and modifying request and can only carry out expansion writing (or addition writing) through a specific interface;
2. the register can be linked with the cryptographic device and the cryptographic resource, and the content stored in the register and the externally input extension information (data input by an upper user) can be signed (user in the cryptographic device or other certificate). The signature flow and the corresponding certificate are packaged in the trusted root and can not be directly called or modified by external functions;
3. after the system is powered up or restarted, the code that was first loaded and booted (hereinafter primary boot code) cannot be modified.
According to the relevant technical scheme and standard of the trusted computing in China, the three conditions can be met by the trusted root devices in different forms at different security levels, and the trusted root function framework in the requirements of the invention is shown in the attached figure 1.
The main working flow of the invention comprises two parts of recording the trusted state and generating the trusted static state report, and the flow is shown in figure 4, wherein the two typical flows are used for recording the trusted state according to different terminal trusted function realization forms.
Firstly, on a complete trusted terminal with a trusted boot function, the method comprises the following specific steps:
step 1: the device is powered on and started, firstly, an operating code (marked as a first-stage boot code) is loaded, a hardware ID driven by the code is obtained and written into a trusted state register, then, a hash value of a work code (marked as a second-stage loading code) to be loaded is calculated, the hash value is written into the trusted state register, and after the writing is successful, the second-stage loading code is loaded and the system control right is handed over;
step 2: the second-level loading code obtains the hardware ID driven by the second-level loading code, writes the hardware ID into a trusted state register, calculates a hash value of a subsequent working code (marked as a third-level loading code) to be loaded, and writes the hash value into the trusted state register;
step 3: repeating the above operation until the loading of the operating system and the core service of the mobile terminal is completed.
Secondly, on the trusted enhancement terminal realized by modifying firmware or software, the condition of establishing a complete trusted support mechanism is not provided, and the program can be reversely measured and executed by a subsequently started program to generate equipment and system state records. In this case, the security capability of the system is equivalent to that of the measurement start point. The typical flow is as follows:
step 1: the device is powered on, loads various firmware and software and runs (recorded as first to N levels of loading codes);
step 2: when loading is carried out to the (N+1) -th stage, the trusted module is started, the hardware ID driven by the trusted module is obtained, and the hardware ID is written into a trusted status register;
step 3: the trusted module sequentially calculates hash values of the loaded first to N stages of loading codes and writes the hash values into a trusted status register;
step 4: the trusted module calculates the hash value of the N+2 level code loaded subsequently and writes the hash value into a trusted state register, and loads and executes the N+2 level code after the hash value is written successfully, so as to transfer the control right of the system;
step 5: repeating the above operation until the loading of the operating system and the core service of the mobile terminal is completed.
The writing of the trusted status register in the above steps includes two modes of expansion writing and addition writing, and both the two modes and the variation and combination mode derived based on the two modes are all within the protection scope of the patent.
The step of expanding writing is as follows:
step 1: receiving the content which is input externally and needs to be expanded and written into the W, reading the content of a trusted status register, and marking the content as O;
step 2: combining the content W needing to be expanded and written with the read trusted status register content O, marking as { O|W }, calculating a hash value of the content W, and marking as H { O|W };
step 3: h { O|W } is written into the trusted status register, and whether the write operation is successful is returned to the outside.
The step of adding the write is:
step 1: the content which is input from the outside and needs to be expanded and written is W, and the length of the content which is recorded at present and is read by a trusted status register is recorded as L0;
step 2: writing the content W at the end of the register used content (typically at the L0+1 character from the register header);
step 3: the length of W is calculated as WL, the recorded content length is updated as L0+WL, and whether the writing operation is successful is returned to the outside.
The flow of generating the trusted static status report is shown in fig. 6, and the specific steps are as follows:
step 1: receiving additional report information in an externally generated trusted static status report request, denoted as a (this additional information may be null information);
step 2: reading the content of a trusted status register, namely O, and combining the trusted status register with external additional report information, namely { O|A };
step 3: calling a mobile terminal trusted static state report private key, signing the information, and recording the information as Sig { O|A };
step 4: and outputting the signed terminal trusted static state report Sig { O|A } to an external caller, and ending the flow.
Embodiment 1 implements the root of trust function in the form of a separate chip on a mobile terminal device. Referring to fig. 5, the trusted status recording process includes the following steps:
step 1: the equipment is powered on, the trusted root chip is started before the CPU is powered on, and the trusted root chip is accessed to the system bus in the form of the main equipment;
step 2: the primary boot code built in the trusted root actively acquires a secondary loading code (in the mobile terminal, usually a basic firmware code), calculates a hash value of the secondary loading code, and writes the hash value into a trusted status register in the trusted root;
step 3: the trusted root releases the control right of the bus, the CPU is powered on and started, and the secondary loading code measured in the step 3 is loaded and executed;
step 4: the secondary loading code obtains the ID of the main hardware and writes the ID into a trusted status register in the trusted root;
step 5: the second-level loading code obtains a third-level loading code (in the mobile terminal, a boot program uboot is usually adopted), and after a hash value of the third-level loading code is calculated, the third-level loading code is written into a trusted status register in the trusted root;
step 6: the second-level loading code loads and executes the third-level loading code measured in the step 5;
step 7: the third-level loading code obtains a fourth-level loading code (in the mobile terminal, the Secure World partition mirror image of the Trust Zone is usually used), and after the hash value is calculated, the trusted status register in the trusted root is written;
step 8: the third-level loading codes load and execute the fourth-level loading codes measured in the step 7;
step 9: the four-level loading code obtains five-level loading code (in the mobile terminal, a boot program or boot partition mirror image or kernel file in Normal World of the Trust Zone is usually used), calculates a hash value of the five-level loading code, and writes the hash value into a trusted status register in the trusted root;
step 10: loading the four-level loading codes and executing the five-level loading codes measured in the step 9;
step 11: five-level loading codes acquire six-level loading codes (in a mobile terminal, the six-level loading codes are usually system images or core system services in Normal World), and after the hash value of the six-level loading codes is calculated, the six-level loading codes are written into a trusted status register in a trusted root;
step 12: the five-level loading code loads and executes the six-level loading code measured in the step 11, and the process ends.
As shown in fig. 6, the trusted static status report generation flow includes the following steps:
step 1: receiving an externally generated trusted static state report request through a hardware IO interface, and recording additional information in the request as A (the additional information can be empty);
step 2: (execution subject) reads the trusted status register content in the trusted root (hardware chip), denoted as O, combined with external additional reporting information, denoted as { o|a };
step 3: the (execution body) calls a mobile terminal trusted static state report private key stored in a trusted root (a password hardware module), signs the information, and marks the information as Sig { O|A };
step 4: and outputting the signed terminal trusted static state report Sig { O|A } to an external caller, and ending the flow.
Embodiment 2 provides an implementation manner of implementing a root of trust function by using an on-board cryptographic chip in combination with a CPU Trusted Execution Environment (TEE) mechanism on a mobile terminal device. In this embodiment, the primary boot code is implemented in the form of a system service in a trusted execution environment, and the trusted state recording process includes the following steps:
step 1: the device is powered on, the CPU is powered on and started, and corresponding basic firmware, a boot program in a trusted execution environment, a kernel in the trusted execution environment and a primary boot code are sequentially loaded and executed;
step 2: the primary boot code obtains the ID of the main hardware and writes the ID into a trusted status register in the trusted root;
step 3: the first-level boot code obtains a second-level loading code (in the mobile terminal, a boot program or boot partition mirror image or kernel file in Normal World of a Trust Zone is usually used), calculates a hash value of the second-level loading code, and writes the hash value into a trusted status register in a trusted root;
step 4: the second-level loading code loads and executes the third-level loading code measured in the step 3;
step 5: the third-level loading code obtains a fourth-level loading code (in the mobile terminal, the system mirror image or the core system service in Normal World is usually adopted), and after calculating the hash value, the hash value is written into a trusted status register in the trusted root;
step 6: and (5) loading and executing the four-level loading codes measured in the step (5) by the secondary loading program, and ending the flow.
The trusted static state report generation flow comprises the following steps:
step 1: receiving an externally generated trusted static state report request through a TEE external communication (usually a TEE Client API) interface, and recording additional information in the request as A (the additional information can be null);
step 2: reading the content of a trusted status register in a trusted root (system service of a trusted execution environment), which is marked as O, and combining with external additional report information, which is marked as { O|A };
step 3: calling a mobile terminal trusted static state report private key stored in a trusted root (password chip), signing the information, and recording the information as Sig { O|A };
step 4: and outputting the signed terminal trusted static state report Sig { O|A } to an external caller, and ending the flow.
Embodiment 3 provides an implementation manner of matching an external cryptographic device (such as a TF card) with a trusted root function of a trusted software module on a mobile terminal device. In this embodiment, the primary boot code is implemented in the form of a system boot program or a kernel driver in an operating system, and the trusted status record flow includes the following steps:
step 1: powering up the device, powering up and starting the CPU, sequentially loading and executing corresponding firmware and software, and loading a first-stage boot code after the external password device is successfully driven;
step 2: the primary boot code obtains the ID of the main hardware and writes the ID into a trusted status register in the trusted root;
step 3: the first-level boot code obtains a boot program and a kernel file of the current system, sequentially calculates a hash value, and writes a trusted status register in the trusted root;
step 4: the primary boot code obtains a secondary loading code (in the mobile terminal, usually a system mirror image or core system service in Normal World), calculates a hash value of the secondary loading code, and writes the hash value into a trusted status register in the trusted root;
step 5: and (3) loading the first-stage boot code and executing the third-stage loaded code measured in the step (4), and ending the flow.
The trusted static state report generation flow comprises the following steps:
step 1: receiving an externally generated trusted static status report request through a kernel/application communication interface (typically a netlink or ioctl of a system call, etc.), and recording additional information in the request as a (the additional information may be null);
step 2: reading the content of a trusted status register in a trusted root (kernel driver), marking as O, combining with external additional report information, marking as { O|A };
step 3: calling a mobile terminal trusted static state report private key stored in a trusted root (external password equipment), signing the information, and recording the information as Sig { O|A };
step 4: and outputting the signed terminal trusted static state report Sig { O|A } to an external caller, and ending the flow.
In addition, the following techniques and algorithms are included in this patent, in addition to the relevant general techniques:
digital encryption technology, a method, means and theory that uses mathematical algorithms to transform plaintext into impossible ciphertext and vice versa.
Hashing algorithms, a conversion technique that converts an arbitrary length input into a fixed length output by a hashing algorithm, is unidirectional and irreversible, and is commonly used in data verification, digital signature, and authentication protocols.
Description:
TCG standard: trusted platform module specification (Trusted Platform Module Specifications)
TCG architecture general Specification (Architecture Overview)
National trusted computing standard: gb_t 29828/information security technology/trusted computing specification/trusted connection architecture.
Trusted root: a trusted root is hardware that trusted computing technology relies on, typically including cryptographic cores, metric code, protected memory space, and the like.
CPU: central Processing Unit the CPU is the operation core and the control core of a computer.
OTA: over The Air, over The Air.
TCG: trusted Computing Group, trusted computing organization.
TEE: trusted Execution Environment, trusted execution environment.
TPM: trusted Platform Module, trusted platform module.
Although embodiments of the present invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made therein without departing from the principles and spirit of the invention, the scope of which is defined in the appended claims and their equivalents.
Claims (4)
1. A system state recording method of mobile terminal equipment is characterized in that: based on the trusted status register, the software and hardware information loaded at each stage in the starting process of the mobile terminal is stored in a non-rewritable and modified mode, and accordingly all started software and hardware resource records in the system are established, and when the records are exported from the trusted root, signature is carried out through the cryptographic equipment and the private key arranged in the trusted root; the method relies on the following three conditions:
(1) The trusted status register can be cleared and reset only when the system is restarted, and can only be expanded and written through a specific interface without receiving copying and modifying requests in the running process of the system;
(2) The trusted status register is linked with the password equipment and the password resource, the content stored in the trusted status register and the externally input extension information are signed, and the signature flow and the corresponding certificate are packaged in the trusted root and cannot be directly invoked or modified by external functions;
(3) After the system is powered on or restarted, the code which is firstly loaded and booted cannot be modified; the method comprises two parts of recording the trusted state and generating the trusted static state report, wherein the trusted state is different in implementation form according to the trusted function of the mobile terminal, and the trusted state recording has two typical processes: firstly, on a complete trusted terminal with a trusted boot function, the method comprises the following specific steps:
step 1: the method comprises the steps of powering on equipment, firstly loading an operating code, namely a first-stage guide code, obtaining a hardware ID driven by the first-stage guide code, writing the hardware ID into a trusted state register, then calculating a hash value of a work code to be loaded, namely a second-stage load code, writing the hash value into the trusted state register, loading the second-stage load code after successful writing and handing over a system control right;
step 2: the second-level loading code obtains the hardware ID driven by the second-level loading code, writes the hardware ID into a trusted state register, calculates a hash value of a subsequent working code to be loaded, namely a third-level loading code, and writes the hash value into the trusted state register;
step 3: repeating the step 1-2 until the loading of the operating system and the core service of the mobile terminal is completed;
secondly, on the trusted enhancement mobile terminal realized by modifying firmware or software, the method does not have the condition of establishing a complete trusted support mechanism, and the program which can be started later reversely measures the executed program to generate equipment and system state records, and comprises the following specific steps:
step 1: the equipment is powered on and started, loads various firmware and software and operates, and is recorded as first to N levels of loading codes;
step 2: when the (n+1) -th level code is loaded, the trusted module is started, the hardware ID driven by the trusted module is obtained, and the hardware ID is written into a trusted status register;
step 3: the trusted module sequentially calculates hash values of the loaded first to N stages of loading codes, and writes the hash values into a trusted status register;
step 4: the trusted module calculates the hash value of the N+2 level code loaded subsequently and writes the hash value into a trusted state register, and loads and executes the N+2 level code after the hash value is written successfully, so as to transfer the control right of the system;
step 5: repeating the steps 1-4 until the loading of the operating system and the core service of the mobile terminal is completed;
the specific steps of generating the trusted static state report are as follows:
step 1: receiving additional report information in an externally generated trusted static state report request, and marking the additional report information as A;
step 2: reading the content of a trusted status register, namely O, and combining the trusted status register with external additional report information, namely { O|A };
step 3: calling a mobile terminal trusted static state report private key, signing the above information combination, and recording as Sig { O|A };
step 4: and outputting the signed mobile terminal trusted static state report Sig { O|A } to an external caller, and ending the flow.
2. The method according to claim 1, characterized in that: the operation of writing the trusted status register includes both extended writing and additive writing.
3. The method according to claim 2, characterized in that: the step of expanding writing is as follows:
step 1: receiving the content which is input externally and needs to be expanded and written into the W, reading the content of a trusted status register, and marking the content as O;
step 2: combining the content W needing to be expanded and written with the read trusted status register content O, marking as { O|W }, calculating a hash value of the content W, and marking as H { O|W };
step 3: h { O|W } is written into the trusted status register, and whether the write operation is successful is returned to the outside.
4. The method according to claim 2, characterized in that: the writing adding step comprises the following steps:
step 1: the content which is input from the outside and needs to be expanded and written is W, and the length of the content which is recorded at present and is read by a trusted status register is recorded as L0;
step 2: writing the content W needing to be expanded and written at the tail part of the used content of the register;
step 3: and (3) counting the length of the content W needing to be written in an expanding way as WL, updating the recorded content length as L0+WL, and returning whether the writing operation is successful or not to the outside.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010331686.8A CN111625846B (en) | 2020-04-24 | 2020-04-24 | System state recording method of mobile terminal equipment |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010331686.8A CN111625846B (en) | 2020-04-24 | 2020-04-24 | System state recording method of mobile terminal equipment |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111625846A CN111625846A (en) | 2020-09-04 |
| CN111625846B true CN111625846B (en) | 2023-08-29 |
Family
ID=72270822
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010331686.8A Active CN111625846B (en) | 2020-04-24 | 2020-04-24 | System state recording method of mobile terminal equipment |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111625846B (en) |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101458743A (en) * | 2007-12-12 | 2009-06-17 | 中国长城计算机深圳股份有限公司 | Method for protecting computer system |
| CN102289612A (en) * | 2010-06-21 | 2011-12-21 | 英特尔公司 | System and method for n-ary locality in a security co-processor |
| CN102436566A (en) * | 2012-01-12 | 2012-05-02 | 冶金自动化研究设计院 | Dynamic trusted measurement method and safe embedded system |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20050138393A1 (en) * | 2003-12-22 | 2005-06-23 | Challener David C. | Determining user security level using trusted hardware device |
-
2020
- 2020-04-24 CN CN202010331686.8A patent/CN111625846B/en active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101458743A (en) * | 2007-12-12 | 2009-06-17 | 中国长城计算机深圳股份有限公司 | Method for protecting computer system |
| CN102289612A (en) * | 2010-06-21 | 2011-12-21 | 英特尔公司 | System and method for n-ary locality in a security co-processor |
| CN102436566A (en) * | 2012-01-12 | 2012-05-02 | 冶金自动化研究设计院 | Dynamic trusted measurement method and safe embedded system |
Non-Patent Citations (1)
| Title |
|---|
| 于培 ; .基于信任链度量机制的安全登录终端系统研究.信息技术.2013,(06),全文. * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111625846A (en) | 2020-09-04 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP3694170B1 (en) | Method and device for withstanding denial-of-service attack | |
| CN109558748B (en) | Data processing method and device, electronic equipment and storage medium | |
| JP6014286B2 (en) | Method and apparatus for providing security to equipment | |
| JP5061110B2 (en) | Simple, scalable and configurable secure boot for reliable mobile phones | |
| US8161285B2 (en) | Protocol-Independent remote attestation and sealing | |
| US10771264B2 (en) | Securing firmware | |
| KR101276409B1 (en) | System and method for n-ary locality in a security co-processor | |
| US11757924B2 (en) | Third-party application risk assessment in an authorization service | |
| US20090298468A1 (en) | System and method for deleting data in a communication device | |
| CN110597839A (en) | Transaction data processing method, device, equipment and storage medium | |
| Nauman et al. | Using trusted computing for privacy preserving keystroke-based authentication in smartphones | |
| US20220019676A1 (en) | Threat analysis and risk assessment for cyber-physical systems based on physical architecture and asset-centric threat modeling | |
| CN107908977A (en) | Intelligent mobile terminal trust chain safety transmitting method and system based on TrustZone | |
| WO2022001944A1 (en) | Method for modifying linux kernel, and terminal device and storage medium | |
| US8750520B2 (en) | Appraising systems with zero knowledge proofs | |
| CN111625846B (en) | System state recording method of mobile terminal equipment | |
| CN110717770A (en) | Anti-counterfeiting detection method, device, equipment and storage medium for vehicle parts | |
| CN109302442A (en) | A kind of data storage method of proof and relevant device | |
| CN108875385B (en) | Method and device for communication between applications | |
| CN111478770A (en) | Security verification method and device, computer equipment and storage medium | |
| CN113672994B (en) | Cooking equipment data management method, device and system based on blockchain | |
| CN110543769A (en) | Trusted starting method based on encrypted TF card | |
| CN113553231B (en) | Embedded operating system running environment monitoring method based on security chip | |
| CN109068320B (en) | Base station Internet of things verification method and system based on 5G, computer and storage medium | |
| Di Lorenzo | Formal verification of security properties for remote attestation protocols |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |