WO2023045744A1 - Procédé de renforcement, procédé d'enregistrement, procédé d'exécution, dispositif électronique et support de stockage - Google Patents

Procédé de renforcement, procédé d'enregistrement, procédé d'exécution, dispositif électronique et support de stockage Download PDF

Info

Publication number
WO2023045744A1
WO2023045744A1 PCT/CN2022/117070 CN2022117070W WO2023045744A1 WO 2023045744 A1 WO2023045744 A1 WO 2023045744A1 CN 2022117070 W CN2022117070 W CN 2022117070W WO 2023045744 A1 WO2023045744 A1 WO 2023045744A1
Authority
WO
WIPO (PCT)
Prior art keywords
hidden
protected application
application
smc
shell program
Prior art date
Application number
PCT/CN2022/117070
Other languages
English (en)
Chinese (zh)
Inventor
李晖
陈明翔
刁亮
杨超锋
张文
许人杰
Original Assignee
中兴通讯股份有限公司
北京邮电大学
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by 中兴通讯股份有限公司, 北京邮电大学 filed Critical 中兴通讯股份有限公司
Publication of WO2023045744A1 publication Critical patent/WO2023045744A1/fr

Links

Images

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/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G06F21/12—Protecting executable software
    • 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/62—Protecting access to data via a platform, e.g. using keys or access control rules

Definitions

  • the embodiments of the present disclosure relate to the field of computers, and in particular to a reinforcement method, a registration method, an operation method, electronic equipment, and a storage medium.
  • the third-generation shell represented by the virtual execution shell has greatly increased the difficulty of unpacking and cracking, but after a long period of research, the third-generation shell still cannot avoid the result of being unpacked. From this point of view, no matter how complex and tiny the software shell is designed, after a long period of research, it will still be cracked and become invalid, that is, the security of the shell program protection is low.
  • the main purpose of the embodiments of the present disclosure is to provide a reinforcement method, a registration method, an operation method, an electronic device and a storage medium, so that the security of the shell program protection can be improved.
  • the embodiment of the present disclosure provides a hardening method applied to the server, including: determining the object to be hidden in the first shell program of the protected application; determining the security monitoring mode call corresponding to the object to be hidden smc instruction; replace the object to be hidden with the smc instruction corresponding to the object to be hidden, and obtain the second shell program after reinforcement; according to the second shell program after reinforcement, the application package APK of the protected application is reinforced to obtain reinforcement After the APK.
  • an embodiment of the present disclosure also provides a registration method applied to a terminal, including: after detecting that an APK is installed, determining whether the protected application corresponding to the APK is in the trusted application TA of the secure world SW Registered; wherein, APK is the hardened APK obtained by any one of the above hardening methods; if the protected application is not registered in the trusted application TA of the secure world SW, register the protected application in the TA of the SW.
  • an embodiment of the present disclosure also provides an operation method for running the protected application registered by the above registration method.
  • the method includes: during the running of the protected application, when the TA in the secure world SW When receiving the smc instruction of the protected application, determine the object to be hidden corresponding to the smc instruction; execute the object to be hidden in the TA of the secure world SW according to the semantics represented by the object to be hidden.
  • an embodiment of the present disclosure further provides an electronic device, including: at least one processor; and a memory connected to the at least one processor in communication; wherein, when the electronic device is a server , the memory stores instructions executable by the at least one processor, the instructions are executed by the at least one processor, so that the at least one processor can execute the above-mentioned strengthening method; in the electronic device In the case of a terminal, the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor, so that the at least one processor can execute the above registration method, Or execute the above-mentioned running method.
  • an embodiment of the present disclosure also provides a computer-readable storage medium, which stores a computer program.
  • the computer program is executed by a processor, the above-mentioned hardening method is realized, or any of the above-mentioned registration methods is realized, or the above-mentioned method of operation.
  • Fig. 1 is a flowchart of a strengthening method according to an embodiment of the present disclosure.
  • Fig. 2 is a flow chart of calling an smc instruction in a hardening method according to an embodiment of the present disclosure.
  • Fig. 3 is a schematic diagram of a hiding method according to an embodiment of the present disclosure.
  • FIG. 4 is a schematic diagram of a server reinforcement process according to an embodiment of the present disclosure.
  • Fig. 5 is a schematic diagram of a terminal system structure in an embodiment of the present disclosure:
  • FIG. 6 is a flowchart of a registration method in another embodiment of the present disclosure.
  • FIG. 7 is a flow chart of an operating method in another embodiment of the present disclosure.
  • FIG. 8 is a schematic diagram of an electronic device in another embodiment of the present disclosure.
  • TrustZone proposed by ARM divides processor resources into Normal World (NW) and Secure World (SW).
  • NW Normal World
  • SW Secure World
  • This hardware isolation mechanism provides a solid hardware foundation for the development of Trust Execution Environment (TEE).
  • TEE Trust Execution Environment
  • the shell program of TEE Under the situation that pure software protection faces the threat of attack, it is necessary to protect the shell program of TEE, and the main target of protection is the original code (native code) of the shell program, that is, the so file (also known as shell.so file).
  • An embodiment of the present disclosure provides a hardening method, which is applied to the server.
  • the implementation details of the hardening method in this embodiment are described in detail below. The following content is only the implementation details provided for easy understanding, and is not the implementation of this solution. must.
  • the application scenarios of the embodiments of the present disclosure may include but not limited to the software shell program protection of TEE, and the strengthening method includes: determining the object to be hidden in the first shell program of the protected application; determining the security monitoring mode call corresponding to the object to be hidden smc instruction; replace the object to be hidden with the smc instruction corresponding to the object to be hidden, and obtain the second shell program after reinforcement; according to the second shell program after reinforcement, the application package APK of the protected application is reinforced to obtain reinforcement After the APK.
  • the first shell program can be understood as the original shell program
  • the second shell program can be understood as the shell program after strengthening the original shell program.
  • the specific flow of the reinforcement method in this embodiment may be shown in FIG. 1 .
  • Step 101 Determine the object to be hidden in the first shell program of the protected application
  • all logic hidden objects in the first shell program may be determined according to the user's expected security and performance consumption evaluation.
  • the object to be hidden can be a logic hidden object in the first shell program shell.so file of the protected application, and the object to be hidden can be understood as: when the first shell program attacker attacks the first shell program, if these If all objects to be hidden are cracked and analyzed clearly, the first shell program may be completely cracked, that is, the object to be hidden is an object that is crucial to the first shell program and can be protected from being cracked by hiding protection.
  • the object to be hidden includes any one or combination of the following, for example, key instructions, key code fragments, and key functions in the first shell program.
  • the key instructions include memory read and write instructions, control flow transfer instructions, general register operation instructions and other instructions with relatively clear semantics
  • the key code fragment can be a small piece of assembly code, for example, a few lines of code, a few instructions, this A small piece of assembly code can make the CPU register conversion more clear, that is, the key code segment can be understood as a code segment with clear semantics
  • the key function is relatively the largest, and can include thousands of instruction code segments.
  • the object to be hidden may also be an instruction, a code segment, a function, etc. in a shell program preset by those skilled in the art and desired to be protected according to actual needs.
  • the preset instructions, code fragments, and functions in the shell program to be protected can be respectively used as the above-mentioned key instructions, key code fragments, and key functions.
  • Step 102 determine the security monitoring mode corresponding to the object to be hidden and call the smc command
  • the server can obtain the correspondence between the object to be hidden in the first shell program of the protected application according to the mapping relationship between the pre-stored object to be hidden and the call command of the security monitoring mode (Secure Monitor Call, referred to as smc for short).
  • the smc command can obtain the correspondence between the object to be hidden in the first shell program of the protected application according to the mapping relationship between the pre-stored object to be hidden and the call command of the security monitoring mode (Secure Monitor Call, referred to as smc for short).
  • the smc command can obtain the correspondence between the object to be hidden in the first shell program of the protected application according to the mapping relationship between the pre-stored object to be hidden and the call command of the security monitoring mode (Secure Monitor Call, referred to as smc for short).
  • determining the security monitoring mode corresponding to the object to be hidden and calling the smc instruction can be implemented by the sub-steps shown in Figure 2, specifically including:
  • Step 1021 Obtain the feature information of the protected application and the identity of the object to be hidden;
  • the characteristic information of the protected application may be a package name pkg_name, an application version number, and the like.
  • the server can calculate the hash value for the object to be hidden according to the type and offset information of all objects to be hidden, and convert it into hexadecimal as the hidden point label, and each hidden point label is the hash value of each object to be hidden A unique identifier, wherein the offset information of the object to be hidden is an offset relative to the first line of native code of the shell program.
  • the type of object to be hidden can include: key instructions, key code fragments and key functions.
  • key instructions in Figure 4 include: str x1, x2, ldr x3, x4; key code fragments include: mov x0, x7str x1, [x0 ]ldr x2, x3 key functions include: key_func().
  • Step 1022 According to the feature information, generate a first mapping relationship between the identity of the object to be hidden and the confusion parameter;
  • the server can input the characteristic information of the protected application (such as the package name pkg_name, the application version number) into the random algorithm as a random factor, and generate a random obfuscation parameter a for each object to be hidden to cover up the real label.
  • the set of obfuscation parameters corresponding to the identities of all objects to be hidden is mapping A.
  • This set is an injective set, that is, the identity of an object to be hidden corresponds to only one obfuscation parameter.
  • the mapping between the identity of an object to be hidden and the obfuscation parameter is A mapping relationship.
  • the identity of the object to be hidden that is, the labels of each hidden point are Ox3D456F7B, 0x2AB35732, 0x3F5F7AOCD, 0x80848EAF, 0Xea206721
  • the confusion parameter set A is ⁇ 76, 24, 12, 33, 89 ⁇
  • the mapping between each hidden point label and the elements of the confusion parameter set A is a one-to-one correspondence
  • one hidden point label corresponds to one confusion parameter, for example, the mapping of Ox3D456F7B is 76.
  • a second mapping relationship may also be generated according to the first mapping relationship; wherein, the second mapping relationship is the same as the first mapping relationship
  • the first mapping relationship is a reverse mapping to each other; the trusted application TA is generated to simulate and execute the logic code of the object to be hidden, that is, the handler code;
  • the hash value and logic code generate the trusted application TA image corresponding to the protected application, and compile the TA image into the terminal operating system.
  • An input for generating the TA image can be regarded as the second mapping relationship.
  • the generated TA image will be compiled into the terminal operating system, which will help prevent the TA image corresponding to the protected application from being attacked and ensure that the relevant information contained in the TA image (Part 1) Two-mapping relationship, hash value of non-hidden code interval and logic code) security.
  • the TA image in the operating system facilitates subsequent registration of protected applications or running protected applications in TA to obtain relevant information. For example, the hash value of the non-hidden code interval (shared information ), verify that the hardened second shell program shell.so has not been tampered with.
  • the second mapping relationship is used in the process of running the protected application to obtain the object to be hidden corresponding to the obfuscation parameter.
  • Step 1023 According to the first mapping relationship, determine the smc instruction corresponding to the obfuscation parameter mapped from the identity of the object to be hidden.
  • step 1022 obtains the mapping relationship between hidden point labels and confusing parameters
  • the selected objects to be hidden in the shell.so are replaced with smc instructions respectively, and the replaced smc instruction format is: [smc hash(pkg_name) , a].
  • hash (pkg_name) is the hash value of the characteristic information of the protected application, that is, the hash value of the package name, and a segment of the general register size (such as the first 64 bits of the arm64-v8a architecture processor) is used as a parameter of the smc command
  • a is a confusing parameter, which is another parameter of the smc command.
  • the parameters of the smc command are fixed at 64 bits. If the hash value is not calculated, an app package name may be very long, which does not match the parameter length of the smc command. Therefore, it is necessary to take a fragment of the size of a general register (such as the first 64bit for an arm64-v8a architecture processor), and use the hash value to convert the app package name of different lengths into a fixed length, for example, take 64 bits from the fixed length as a hash (pkg_name).
  • the smc instruction corresponding to the object to be hidden can be determined in the manner shown in Fig. , so the obfuscation parameters of each output must be different theoretically. Therefore, it is beneficial to increase the difficulty of cracking the corresponding relationship between the object to be hidden and the smc instruction, and improve the security of the second shell program after reinforcement.
  • Step 103 replacing the object to be hidden with the smc command corresponding to the object to be hidden, to obtain the second shell program after reinforcement;
  • the object to be hidden is the key instruction in the first shell program shell.so file, and the key instruction in the original shell.so file is [str x1, x2], then the replaced The smc command is [smc app, 76]; if the object to be hidden is the key code segment in the first shell program shell.so file, the key code segment in the original shell.so file is [mov x0, x7str x1, [x0]ldr x2x3], then the replaced smc command is [smc app, 31]; if the object to be hidden is the key function in the first shell program shell.so file, the key function in the original shell.so file is [key_fun1()], Then the replaced smc instruction is [smc app, 35].
  • the instructions in the original shell.so file are executed in NW, and the replaced smc instructions are executed in SW.
  • Step 104 According to the second hardened shell program, harden the application package APK of the protected application to obtain the hardened APK.
  • the server carries out subsequent shelling and hardening processes according to the hardened second shell program shell.so file, and finally outputs a hardened Android application package (Android application package, referred to as APK).
  • APK is the installation package of the Android application
  • the shell program is the software used to protect the APK. In this embodiment, it mainly protects the shell program.
  • the protection shell program can also be understood as a reinforced shell program, so that the reinforced second shell can be reused. The program then hardens the APK of the protected application.
  • the non-hidden code interval between adjacent objects to be hidden in the first shell program of the protected application calculates the hash value of the non-hidden code interval, and use the hash value as the server and the shared information between terminals registering the protected application; when compiling the trusted application (Trust Application, TA for short) of the secure world SW, the shared information is compiled into the operating system of the terminal, wherein the shared information is used for The terminal verifies the security of the protected application when registering the protected application. That is to say, the non-hidden code intervals in the object to be hidden are all unsubstituted code intervals in the shell.so file. As shown in FIG.
  • all unsubstituted code intervals in the shell.so file are the blank spaces, that is, all unsubstituted code intervals in the shell.so file, that is, non-hidden code intervals. Calculate the hash value of each non-hidden code interval, and use the hash value as the shared information between the server and the registered protected app. When the server compiles the TA in the SW, it compiles the shared information into the operating system.
  • the attacker After the logical hidden object in the first shell program shell.so file is replaced, except for the part replaced with the smc command, the rest of the first shell program shell.so file will no longer change. Therefore, after determining the smc instruction of shell.so, count the code intervals of all unchanged parts (that is, non-hidden code intervals) and calculate the hash value of each interval, and input the hash value data of these unchanged intervals during compiling TA As the shared information of the server and the terminal, the attacker cannot obtain this secret. Utilizing the shared information allows the protected app to perform an initial integrity check during the registration phase, which is beneficial to prevent the attacker's shell program shell.so from spoofing attacks.
  • the reinforcement method provided by the embodiment of the present disclosure first determines the object to be hidden in the first shell program of the protected application; determines the smc command corresponding to the object to be hidden; replaces the object to be hidden with the smc command corresponding to the object to be hidden, The hardened second shell program; the object to be hidden in the first shell program is replaced, that is, the object to be hidden in the first shell program is hidden, and there is no complete semantic information, which can completely prevent the static analysis of the shell program by the attacker .
  • the embodiments of the present disclosure can also greatly increase the difficulty of the attacker's dynamic analysis of the shell program, because the attacker can only debug the shell program in the NW, and analyze the changes of the entire processor state and memory space before and after the smc command. Under the premise of the current terminal's processor complexity and large memory space, this search space is very large, and subsequent logical analysis is even more difficult. Therefore, the hardened second shell program obtained in the embodiment of the present disclosure is extremely difficult to be attacked, which can improve the security of the shell program protection.
  • the APK of the protected application is reinforced by using the reinforced second shell program to obtain the reinforced APK, thereby improving the security of using the reinforced second shell program to protect the APK.
  • An embodiment of the present disclosure also provides a registration method, which is applied to a terminal, and specifically includes: after detecting that an APK is installed, determining whether the protected application corresponding to the APK is registered in the trusted application TA of the secure world SW; , the APK is a hardened APK obtained based on the hardening method of the above embodiment; if the protected application is not registered in the trusted application TA of the secure world SW, register the protected application in the TA of the SW.
  • the terminal system has two states: normal world (Normal Word, NW for short) and secure world (Secure Word, SW for short), both of which have their own independent registers, that is, the environment of the CPU.
  • the CPU can only be in one state at a time. For example, when running in the NW state, the NW register is used, and when the CPU is running in the SW state, the SW register is used.
  • the NW register and the SW register are independent and isolated from each other.
  • Both the reinforcement agent and the reinforcement TA in FIG. 5 may be software modules.
  • the hardened agent in the terminal system runs in the EL1 kernel state of the NW, and is responsible for detecting whether the common application is a protected application, collecting the characteristic information of the protected application, implementing the sys_call_enforce() system call logic, communicating with the hardened TA in the SW, and according to The return information of the hardening TA controls the running status of the protected application app.
  • the hardening agent detects whether the application is protected. By hooking the Android system PackageManager class, it detects whether the application is protected when the application is installed. If the protected application has been hardened, continue. The registration process is also detected when the application is uninstalled. If it has already been registered, the hardened TA of the SW will be notified to cancel the registration.
  • the hardened agent is consistent with the server when collecting application feature information.
  • the parameter accepted by the sys_call_enforce() system call is the package name of the application, and then notifies the hardened TA to register the application through the smc command.
  • the reinforcement agent may receive various return values from the reinforcement TA. For example, the reinforcement TA returns false after the integrity verification fails. At this time, the reinforcement agent is responsible for immediately stopping the application whose integrity is damaged.
  • the reinforcement TA running in the EL0 user state in the TEE is responsible for responding to the registration process at startup of the protected application and receiving the smc command request at runtime.
  • the registration process mainly includes initial integrity verification and generation of dynamic integrity benchmark values.
  • the reinforcement agent can be regarded as a transmission medium between NW and SW.
  • the shell.so file of the shell program when it is detected that the APK is installed, the shell.so file of the shell program is loaded, enters the JNI_onLoad() function, executes the system call sys_call_enforce(pkg_name), and the reinforcement agent in the NW responds.
  • the reinforcement agent receives the pkg_name parameter , calculate the hash(pkg_name), and then call [smc hash(pkg_name), 0] to enter the SW to let the hardened TA query whether the protected application app is registered in the trusted application TA of the safe world SW, if the protected application is not in the safe world If registered in the trusted application TA of the SW, the protected application is registered in the TA of the SW.
  • the server when the server compiles the trusted application TA of the secure world SW, it compiles the shared information between the server and the terminal into the operating system of the terminal, and then registers the protected application in the TA of the SW, as shown in the figure 6, the specific steps are:
  • Step 201 in the normal world NW, find the start address and end address of the hardened second shell program in memory;
  • the hardening agent will collect the start address and end address (addr_start, addr_end) mapped in the memory of the protected application shell program shell.so file.
  • Step 202 in the TA of the secure world SW, according to the target smc command from the normal world NW, obtain the start address and the end address carried by the target smc command;
  • the target smc command of NW in the ordinary world can be [smc hash(pkg_name), 1, addr_start, addr_end] command, and the hardened TA obtains the start address and end address through the target smc command of NW.
  • [smc hash(pkg_name), 0] and [smc hash(pkg_name), 1, addr_start, addr_end] the second parameters 0 and 1 of the two smc instructions are exclusively used by this system call, and are specially used in the registration phase Information exchange is performed with the hardened TA, so the two elements 0 and 1 cannot be used in the value field of the server-side hardened creation map A.
  • the second parameter of the two smc commands specially used for information exchange with the TA during the registration phase may also use other values, so as to ensure that the value range of creating the mapping A is different from the other values.
  • Step 203 in the TA of the secure world SW, according to the start address and the end address, determine the non-hidden code interval in the hardened second shell program, and calculate the hash value of the non-hidden code interval;
  • SW hardening TA locates all non-hidden code intervals of the shell.so file of the protected app according to the start address and end address (addr_start, addr_end), and calculates the hash values of all non-hidden code intervals, among which, non- The code-behind section is an invariant section of shell.so.
  • the invariant interval of shell.so is divided into many blocks after excluding the smc command.
  • the server calculates the hash value for the invariant interval of each block, and there are as many hash values as there are invariant intervals.
  • another hash value may be calculated as the hash value of all the constant intervals according to the hash values of all the constant intervals.
  • an smc instruction for triggering dynamic integrity verification is inserted into a preset position of the hardened second shell program, and a non-hidden key in the hardened second shell program is determined according to the start address and end address
  • the hash value of the hardened second shell program can also be calculated and stored according to the start address and end address; wherein, the hash value of the hardened second shell program is used for running the protected application.
  • the hardened TA in SW records the shell.so address range (addr_start, addr_end) of the protected application, and calculates the hash value of shell.so to record as subsequent dynamic integrity Validated baseline value.
  • the app information saved by the SW hardened TA during the registration phase includes: (pkg_name, addr_start, addr_end, hash(mem[addr_start, addr_end])). These information are stored in the secure memory of TEE through HashMap, called Map_enforce, which cannot be obtained by attackers.
  • Map_enforce the shell.so in the shell program will no longer change (the constant interval plus all smc commands cannot be changed), and this hash value calculation is based on the entire content of the shell program shell.so.
  • Hash value can verify whether the shell program shell.so has been tampered with during the running process of the protected application, and register the protected application in the TA of the SW if it has not been tampered with, ensuring the security during the running process .
  • Step 204 if the hash value of the non-concealed code interval is the same as the shared information, register the protected application in the TA of the SW.
  • the registration failure information will be returned to the reinforcement agent immediately, and the NW reinforcement agent will terminate the operation of the protected app. If all invariant intervals pass the verification, the protected application is registered in the TA of the SW.
  • the protected application in the TA of the SW after registering the protected application in the TA of the SW, it further includes: querying the second mapping relationship corresponding to the name identifier of the protected application in the TA of the SW, and combining the name identifier of the protected application with the The second mapping relationship is bound.
  • the TA image corresponding to the protected application is generated, and after the TA image is compiled into the operating system of the terminal, the TA image contains the second mapping corresponding to the name identifier of the protected application
  • the name identifier of the protected application is bound to the second mapping relationship, so that when the subsequent protected application is running, the second mapping relationship can be obtained according to the name identifier of the protected application carried by the smc command, Therefore, the object to be hidden corresponding to the obfuscation parameter carried by the smc instruction is obtained based on the second mapping relationship.
  • An embodiment of the present disclosure also provides an operation method for running the protected application registered by the registration method of the above embodiment, including: during the process of running the protected application, when the protected application is received in the TA of the secure world SW When applying the smc instruction, determine the object to be hidden corresponding to the smc instruction; execute the object to be hidden in the TA of the secure world SW according to the semantics represented by the object to be hidden.
  • the smc command of the protected application carries the confusion parameter and the name identifier of the protected application, and according to the name identifier of the protected application, determines the second mapping relationship bound to the name identifier of the protected application; according to the bound first
  • the second mapping relationship is to determine the object to be hidden corresponding to the obfuscation parameter carried by the smc command, and execute the object to be hidden in the TA of the safe world SW according to the semantics represented by the object to be hidden.
  • Step 301 receiving the smc instruction of the protected application
  • the TA of the safe world SW receives the smc command of the protected application, for example, the smc command is [smc hash(pkg_name), a], and hash(pkg_name) is the package name parameter , a is the confusion parameter.
  • Step 302 determining the object to be hidden corresponding to the smc instruction
  • the second mapping relationship bound to the name identifier of the protected application determines the second mapping relationship bound to the name identifier of the protected application; according to the bound second mapping relationship, determine the object to be hidden corresponding to the confusion parameter carried by the smc instruction , so as to obtain the semantics represented by the object to be hidden.
  • Step 303 according to the semantics represented by the object to be hidden, execute the semantics represented by the object to be hidden in the TA of the secure world SW;
  • the semantics represented by the object to be hidden are: the semantics represented by key instructions, the semantics represented by key code fragments, or the semantics represented by key functions.
  • the TA of Safe World SW can modify the register or memory of NW according to the semantics of key instructions and key code fragments, and after completion, point the pc pointer of NW to the next instruction of smc and then directly return to NW to continue execution.
  • the simulation execution of key functions is basically the same as the execution of key instructions and key code fragments.
  • the parameters carried by the smc instruction are obtained from the NW stack and then executed, and the results are fed back to the NW stack and then returned to NW to continue execution.
  • the logic code that generates the trusted application TA to simulate and execute the object to be hidden is executed in the hardened TA.
  • the hardened TA needs to process various logical hidden objects.
  • Each hidden logic requires the hardened TA to set up a processing module to be responsible for execution.
  • This processing module is handler0, for example, the key instruction simulation execution handler, the key code fragment simulation execution handler, the key function simulation execution handler, and the dynamic integrity verification handler.
  • the SW when the semantics represented by the object to be hidden is switched in the TA of the safe world SW, the SW needs to use the NW register, which involves the issue of register transfer, and the relevant state of the SW register can be transferred by stack Set to the relevant state of the NW register.
  • the smc instruction is smc(app_name, 76), and only the two parts of app_name and 76 can be set in the relevant state.
  • the smc(app_name, 76) two parameters can be passed, one is app_name, and the other is 76. These two parameters can occupy two registers and are saved through the stack.
  • Step 304 whether the dynamic integrity check is passed
  • the current running The current hash value of the hardened second shell program; determine whether the current hash value is the same as the stored shared information for dynamic integrity verification.
  • Step 305 return to NW to continue execution
  • the hardened TA calculates the hash value of the non-hidden interval of shell. The known value of the information is compared, and if the interval is found to be consistent, the shell.so of NW is returned to continue execution.
  • Step 306 return to the NW hardening agent to stop the process.
  • the hardened TA calculates the hash value of the non-hidden interval of shell.so based on the addr_start and addr_end information registered by the protected application at startup, and compares it with the known value of the shared information. If an inconsistent interval is found, it dynamically If the integrity check fails, immediately return the information that the dynamic integrity check fails to the hardening agent, and the NW hardening agent stops the running of the protected app.
  • the operation method provided by this embodiment can completely prevent an attacker from statically analyzing shell.so in NW, because the shell.so after logic hiding does not have any complete semantic information at all; in addition, this disclosure can greatly increase dynamic analysis
  • the difficulty is because the security assumption is that the attacker cannot break through the TEE to obtain the handler for processing the smc request.
  • the attacker can only debug shell.so in the NW, and analyze the changes of the entire processor state and memory space before and after the smc command.
  • the search space is very large, and the subsequent logical analysis is more difficult.
  • the embodiments of the present disclosure can provide very high shell program protection security.
  • step division of the above various methods is only for the sake of clarity of description. During implementation, it can be combined into one step or some steps can be split and decomposed into multiple steps. As long as they include the same logical relationship, they are all within the scope of protection of this patent. ; Adding insignificant modifications or introducing insignificant designs to the algorithm or process, but not changing the core design of the algorithm and process are all within the scope of protection of this patent.
  • An embodiment of the present disclosure also provides an electronic device, as shown in FIG. 8 , including: at least one processor 701; and a memory 702 communicatively connected to at least one processor; wherein, when the electronic device is a server, The memory 702 stores instructions that can be executed by at least one processor 701, and the instructions are executed by the at least one processor 701, so that the at least one processor 701 can perform the above-mentioned strengthening method; In the case of a terminal, the memory 702 stores instructions executable by the at least one processor 701, and the instructions are executed by the at least one processor 701, so that the at least one processor 701 can execute the above-mentioned Register method, or execute the run method above.
  • the memory and the processor are connected by a bus
  • the bus may include any number of interconnected buses and bridges, and the bus connects one or more processors and various circuits of the memory together.
  • the bus may also connect together various other circuits such as peripherals, voltage regulators, and power management circuits, all of which are well known in the art and therefore will not be further described herein.
  • the bus interface provides an interface between the bus and the transceivers.
  • a transceiver may be a single element or multiple elements, such as multiple receivers and transmitters, providing means for communicating with various other devices over a transmission medium.
  • the data processed by the processor is transmitted on the wireless medium through the antenna, further, the antenna also receives the data and transmits the data to the processor.
  • the processor is responsible for managing the bus and general processing, and can also provide various functions, including timing, peripheral interface, voltage regulation, power management, and other control functions. Instead, memory can be used to store data that the processor uses when performing operations.
  • an embodiment of the present disclosure also provides a computer-readable storage medium, which stores a computer program.
  • the computer program is executed by a processor, the above-mentioned hardening method is realized, or any of the above-mentioned registration methods is realized, or the above-mentioned method of operation.
  • the program is stored in a storage medium, and includes several instructions to make a device ( It may be a single chip microcomputer, a chip, etc.) or a processor (processor) to execute all or part of the steps in the methods of the various embodiments of the present disclosure.
  • the aforementioned storage media include: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), magnetic disk or optical disc, etc., which can store program codes. .

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Multimedia (AREA)
  • Technology Law (AREA)
  • Storage Device Security (AREA)

Abstract

Les modes de réalisation de la présente divulgation se rapportent au domaine des logiciels informatiques, et concernent en particulier un procédé de renforcement, un procédé d'enregistrement, un procédé d'exécution, un dispositif électronique et un support de stockage. Le procédé de renforcement consiste : à déterminer un objet à cacher dans un premier générique de développement d'une application protégée ; à déterminer une instruction d'appel de moniteur sécurisé (SMC) correspondant audit objet ; à remplacer ledit objet par l'instruction SMC correspondant audit objet, de manière à obtenir un second générique de développement renforcé ; et à renforcer un progiciel d'application (APK) de l'application protégée suivant le second générique de développement renforcé, de manière à obtenir un APK renforcé. Le procédé de renforcement décrit dans les modes de réalisation de la présente divulgation vise à améliorer la sécurité de protection de générique de développement.
PCT/CN2022/117070 2021-09-23 2022-09-05 Procédé de renforcement, procédé d'enregistrement, procédé d'exécution, dispositif électronique et support de stockage WO2023045744A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202111115444.6A CN115859225A (zh) 2021-09-23 2021-09-23 加固方法、注册方法、运行方法、电子设备和存储介质
CN202111115444.6 2021-09-23

Publications (1)

Publication Number Publication Date
WO2023045744A1 true WO2023045744A1 (fr) 2023-03-30

Family

ID=85653003

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/117070 WO2023045744A1 (fr) 2021-09-23 2022-09-05 Procédé de renforcement, procédé d'enregistrement, procédé d'exécution, dispositif électronique et support de stockage

Country Status (2)

Country Link
CN (1) CN115859225A (fr)
WO (1) WO2023045744A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016188134A1 (fr) * 2015-05-22 2016-12-01 中兴通讯股份有限公司 Procédé et appareil de mise en œuvre de renforcement d'application
CN106897587A (zh) * 2017-02-27 2017-06-27 百度在线网络技术（北京）有限公司 加固应用、加载加固应用的方法和装置
CN109784057A (zh) * 2019-01-04 2019-05-21 国家计算机网络与信息安全管理中心 安卓应用加固识别方法、控制器及介质
US20190163450A1 (en) * 2017-11-30 2019-05-30 Google Llc Systems and methds of developments, testing, and distribution of applications in a computer network
CN110008693A (zh) * 2019-04-12 2019-07-12 深圳市趣创科技有限公司 安全应用程序加密保证方法及装置与系统和存储介质

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016188134A1 (fr) * 2015-05-22 2016-12-01 中兴通讯股份有限公司 Procédé et appareil de mise en œuvre de renforcement d'application
CN106897587A (zh) * 2017-02-27 2017-06-27 百度在线网络技术（北京）有限公司 加固应用、加载加固应用的方法和装置
US20190163450A1 (en) * 2017-11-30 2019-05-30 Google Llc Systems and methds of developments, testing, and distribution of applications in a computer network
CN109784057A (zh) * 2019-01-04 2019-05-21 国家计算机网络与信息安全管理中心 安卓应用加固识别方法、控制器及介质
CN110008693A (zh) * 2019-04-12 2019-07-12 深圳市趣创科技有限公司 安全应用程序加密保证方法及装置与系统和存储介质

Also Published As

Publication number Publication date
CN115859225A (zh) 2023-03-28

Similar Documents

Publication Publication Date Title
US11520611B2 (en) Secure public cloud using extended paging and memory integrity
Weiser et al. Timber-v: Tag-isolated memory bringing fine-grained enclaves to risc-v
KR102255767B1 (ko) 가상 머신 감사를 위한 시스템 및 방법들
US11093601B2 (en) Dynamic switching between pointer authentication regimes
CN109918919B (zh) 认证变量的管理
US6978018B2 (en) Technique to support co-location and certification of executable content from a pre-boot space into an operating system runtime environment
US8375221B1 (en) Firmware-based trusted platform module for arm processor architectures and trustzone security extensions
US6941458B1 (en) Managing a secure platform using a hierarchical executive architecture in isolated execution mode
WO2006086301A1 (fr) Systeme et procede de realisation d'une architecture d'initialisation securisee
JP5410445B2 (ja) オンチップデバイス管理のためのノウングットコード
US10218508B2 (en) Methods and apparatus to provide isolated execution environments
CN105205401A (zh) 基于安全密码芯片的可信计算机系统及其可信引导方法
CN112800429B (zh) 一种基于基础性的uefi bios固件系统中驱动程序保护的方法
US20060200680A1 (en) Attestation key memory device and bus
CN101297280A (zh) 隔离扩展和设备驱动程序的配置
US8806474B2 (en) Computer-hardware, life-extension apparatus and method
WO2022017242A1 (fr) Procédé et appareil pour exécuter une application de second système dans un premier système, dispositif et support
WO2023045744A1 (fr) Procédé de renforcement, procédé d'enregistrement, procédé d'exécution, dispositif électronique et support de stockage
Iooss et al. Ghost in the Wireless, iwlwifi edition
CN112540857B (zh) 处理工作量证明计算任务的方法、装置和系统
US20240119139A1 (en) Securing critical data in a storage device of a computer system
Nunes et al. A verified architecture for proofs of execution on remote devices under full software compromise
Zhang et al. DRSA: Debug Register-Based Self-relocating Attack Against Software-Based Remote Authentication
Dettenborn Open virtual trusted execution environment
CN118093202A (zh) 一种访存异常的处理方法、计算设备、存储介质及程序产品

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22871793

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE