SDK integrity check

Abstract

An SDK integrity check method and apparatus, and a medium and a device. A first hash value is calculated for normative information of integrity-related files in an SDK, and the first hash value is then stored in a trusted execution environment on an electronic device, such that it can be ensured that the first hash value cannot be tampered with locally on the electronic device. In this way, the SDK then calls the trusted execution environment to perform secure and trusted integrity checking, that is, the trusted execution environment is called to determine, by means of comparison, whether the first hash value is consistent with a second hash value.

Description

SDK integrity verification Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a method, device, medium and equipment for verifying SDK integrity. Background Art

[0002] A software development kit (SDK) is a collection of documentation, examples, and tools that aid in the development of a specific type of software. Some technical service providers will package their technical service solutions into SDKs and provide them to application developers, who then integrate the SDK into their applications.

[0003] To protect SDK data security and ensure SDK functional compliance, SDK integrity verification is required during SDK initialization within the application software. The purpose of SDK integrity verification is to ensure that integrity-related files within the SDK (such as configuration files and API call links) related to data security and functional compliance requirements have not been tampered with.

[0004] Based on the above, a technical solution is needed that can verify the integrity of the SDK in an offline environment. Summary of the Invention

[0005] An embodiment of the present specification provides a method for verifying the integrity of an SDK. An electronic device has a trusted execution environment, wherein a first hash value is stored in the trusted execution environment. The first hash value is a hash value of specification information of integrity-related files in a software development kit (SDK). The SDK is built into application software on the electronic device. The method includes: initializing the SDK in response to a request from the application software, reading current information of integrity-related files in the SDK, and calculating a hash value of the current information as a second hash value; calling the trusted execution environment, and comparing the first hash value with the second hash value; and determining that the SDK integrity check has passed if the comparison is consistent.

[0006] An embodiment of the present specification provides a device for verifying the integrity of an SDK. An electronic device has a trusted execution environment, wherein a first hash value is stored in the trusted execution environment. The first hash value is a hash value of specification information of integrity-related files in a software development kit (SDK). The SDK is built into the application software on the electronic device. The device includes: a reading module, which initializes the SDK in response to a request from the application software, reads current information of integrity-related files in the SDK, and calculates a hash value of the current information as a second hash value; a calling module, which calls the trusted execution environment and compares the first hash value with the second hash value; and a determination module, which determines that the SDK integrity check has passed if the comparison is consistent.

[0007] An embodiment of this specification also provides a computer program product, which stores at least one instruction, and the at least one instruction is suitable for being loaded by a processor and executing the above method steps.

[0008] An embodiment of this specification further provides a storage medium, wherein the storage medium stores a computer program, and the computer program is suitable for being loaded by a processor and executing the steps of the above method.

[0009] An embodiment of this specification further provides an electronic device, comprising: a processor and a memory; wherein the memory stores a computer program, and the computer program is suitable for being loaded by the processor and executing the steps of the above method.

[0010] In the embodiments of this specification, a hash value (i.e., a first hash value) is calculated for the specification information (i.e., information that the SDK provider determines to be correct and compliant) of integrity-related files within the SDK (files that involve integrity verification and need to be ensured not to have been tampered with), and the first hash value is stored in a trusted execution environment (TEE) on the electronic device. This ensures that the first hash value will not be tampered with locally on the electronic device. In this way, when the SDK calls the trusted execution environment, it performs a secure and reliable integrity check, i.e., it calls the trusted execution environment to compare the first hash value with the second hash value (the hash value of the current information of the integrity-related files within the SDK that may have been tampered with) to see if they are consistent.

[0011] Through the embodiments of this specification, the process of verifying the integrity of the SDK does not depend on the online environment of the electronic device (this technical solution can be implemented in an online environment of the electronic device), and the integrity of the SDK can be verified even in an offline environment of the electronic device. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] FIG1 is a flow chart of a method for verifying SDK integrity provided by the present disclosure.

[0013] FIG2 is a schematic diagram of a method for verifying SDK integrity provided by the present disclosure.

[0014] FIG3 is a schematic diagram of another SDK integrity verification method provided by the present disclosure.

[0015] FIG4 is a schematic diagram of storing a first hash value based on an online environment of an electronic device according to the present disclosure.

[0016] FIG5 is a schematic diagram of another SDK integrity verification method provided by the present disclosure.

[0017] FIG6 is a schematic structural diagram of an SDK integrity verification device provided by the present disclosure.

[0018] FIG7 is a schematic diagram of the structure of an electronic device provided in an embodiment of this specification. DETAILED DESCRIPTION

[0019] To make the objectives, technical solutions, and advantages of this specification more clear, the following will clearly and completely describe the technical solutions of this specification in conjunction with the specific embodiments of this specification and the corresponding drawings. Obviously, the embodiments described are only part of the embodiments of this specification, not all of the embodiments. Based on the embodiments in this specification, all other embodiments obtained by ordinary technicians in this field without making any creative efforts are within the scope of protection of this specification.

[0020] An SDK assists in application development through compilers, debuggers, and software frameworks. It simply provides documentation for the application programming interface (API) for a specific programming language. SDKs also often include sample code, supporting technical notes, or other supporting documentation to clarify underlying reference material.

[0021] In this disclosure, the party that develops application software is referred to as the application software developer, and the technical service provider that provides SDK to the application software is referred to as the SDK provider. The application software developer embeds the SDK into the application software it develops.

[0022] SDK providers must ensure that key information within the SDK is not tampered with by application developers. If this key information is tampered with by application developers, it could lead to data privacy leaks (such as core code leaks) within the SDK and potentially render the SDK's functionality non-compliant.

[0023] For example, an SDK provides a transaction payment settlement solution. An e-commerce application software has the SDK built in. The application software developer modifies some configuration files in the SDK, resulting in the user inputting a payment amount of X each time, and the deduction amount transmitted to the transaction payment backend becoming 2X.

[0024] In order to protect the data security of the SDK and ensure the functional compliance of the SDK, the SDK integrity needs to be verified when the SDK built into the application software is initialized. This disclosure refers to the key files in the SDK that are related to data security, functional compliance, and other requirements as integrity-related files (such as certain configuration files and interface call links). The purpose of verifying the integrity of the SDK is to ensure that the information of the integrity-related files related to data security, functional compliance, and other requirements in the SDK has not been tampered with.

[0025] Typically, application software is installed on electronic devices (mobile phones, personal computers, tablets, etc.), and the application software has a built-in SDK. During initialization, the SDK can perform integrity verification by interacting with the SDK provider's server over the network. However, if the electronic device is offline, the SDK cannot interact with the SDK provider's server over the network, making integrity verification impossible.

[0026] To this end, in one or more embodiments of the present disclosure, a hash value (i.e., a first hash value) is calculated for the specification information (i.e., information that the SDK provider determines to be correct and compliant) of the integrity-related files within the SDK (files that involve integrity verification and need to be ensured not to have been tampered with), and the first hash value is stored in a trusted execution environment on the electronic device. This ensures that the first hash value will not be tampered with locally on the electronic device. In this way, when the SDK calls the trusted execution environment, it performs a secure and reliable integrity check, i.e., it calls the trusted execution environment to compare the first hash value with the second hash value (the hash value of the current information of the integrity-related files within the SDK that may have been tampered with) to see if they are consistent.

[0027] In this way, the process of verifying the integrity of the SDK does not need to rely on the online environment of the electronic device (this technical solution can be implemented when the electronic device is online). Even when the electronic device is offline, the integrity of the SDK can be verified.

[0028] FIG1 is a flow chart of the SDK integrity verification method provided by the present disclosure, which includes the following steps.

[0029] S200: In response to the application software requesting to initialize the SDK, read current information of integrity-related files in the SDK.

[0030] In one or more embodiments of the present disclosure, the electronic device has a trusted execution environment, in which a first hash value is stored. The first hash value is a hash value of specification information of integrity-related files in a software development kit (SDK), and the application software on the electronic device has the SDK built in.

[0031] The aforementioned standard information can be understood as information certified as correct and compliant by the SDK provider. If the specific information in the integrity-related files within the SDK is standard, then the integrity-related files within the SDK have not been tampered with, the SDK's integrity has not been compromised, and the SDK will pass the integrity check.

[0032] The first hash value mentioned above needs to be stored in a trusted execution environment to ensure that the local electronic device (eg, application software developers, users of the electronic device, etc.) cannot tamper with the first hash value.

[0033] It should be noted that in practice, there may be many different application software, all of which may have built-in SDKs. Different applications may have different integrity-related files within the SDK. This means that the integrity verification of their built-in SDKs may involve different integrity-related files for each application. In this case, the trusted execution environment may store the first hash values ​​corresponding to each application.

[0034] The execution subject of the method flow shown in FIG1 may be the application software (specifically, the application module within the application software) or the SDK.

[0035] When an application needs to call SDK functions during runtime, it must request SDK initialization. When requesting SDK initialization, the SDK integrity must be verified. Only after the SDK integrity verification passes can the SDK initialization be allowed so that the application can call SDK functions.

[0036] When performing an integrity check on the SDK, the information read from the complete set of relevant files within the SDK is called the current information. This information may be consistent with the specification, or it may have been tampered with (and therefore inconsistent with the specification). The essence of integrity checking is to verify whether the current information is consistent with the specification. If they are consistent, the check passes; if they are inconsistent, the check fails.

[0037] S102: Calculate a hash value of the current information as a second hash value.

[0038] The present disclosure does not limit the hash algorithm used. Generally, the hash algorithm used when performing hash calculations on the specification information and the current information must be consistent.

[0039] S104: Invoke a trusted execution environment and compare the first hash value with the second hash value.

[0040] The process of comparing the first hash value and the second hash value using the trusted execution environment is safe, and the comparison process will not be locally interfered with by the electronic device, so the comparison result is also reliable.

[0041] Specifically, when the application software or SDK calls the trusted execution environment, the second hash value can be sent to the trusted execution environment, and the logic of comparing the first hash value and the second hash value to see whether they are consistent is executed in the trusted execution environment. The trusted execution environment can feed back the comparison result to the application software or SDK that calls the trusted execution environment.

[0042] S106: If the comparison is determined to be consistent, it is determined that the SDK integrity check has passed.

[0043] After confirming that the SDK integrity check has passed, you can start initializing the SDK.

[0044] S108: If the comparison is determined to be inconsistent, it is determined that the SDK integrity check fails.

[0045] After determining that the SDK integrity check fails, you can refuse to initialize the SDK.

[0046] Furthermore, in some embodiments, considering that different applications may have different integrity-related files in their built-in SDKs (meaning that the integrity-related file specifications may differ), and considering that the same application may have its built-in SDK version updated iteratively (resulting in updates and changes to the integrity-related file specifications), the electronic device's trusted execution environment may store multiple first hash values, with different first hash values ​​based on different applications or different SDK versions.

[0047] That is, the trusted execution environment can store the association between the first hash value, the software identifier of the application software, and the version identifier of the SDK. The trusted execution environment can have multiple first hash values ​​and multiple of the above associations.

[0048] Thus, the method flow shown in Figure 1 is for a specific application software (with a specific software identifier) ​​and a specific SDK version (with a specific version identifier). In step S104, the trusted execution environment can be called to determine the first hash value associated with the software identifier and the version identifier, and the first hash value can be compared with the second hash value.

[0049] In some embodiments, the SDK provider can specify a set of keys (including a decryption key and an encryption key) and pre-synchronize the decryption key to the trusted execution environment of the electronic device. Before providing the SDK to the application software developer, the SDK provider can encrypt the first hash value of the canonical information of the integrity-related files in the SDK using the encryption key and include the ciphertext of the first hash value in the SDK.

[0050] In this way, when the application software first requests to initialize the SDK, it can provide the ciphertext of the first hash value in the SDK and the second hash value of the current information of the integrity-related files in the SDK to the trusted execution environment. The trusted execution environment is then called to decrypt the ciphertext of the first hash value and compare the first hash value with the second hash value. The trusted execution environment can also store the first hash value. This way, when the application software subsequently requests to initialize the SDK again, it does not need to pass the ciphertext of the first hash value to the trusted execution environment, thus saving the trusted execution environment's decryption computing power.

[0051] Furthermore, in an embodiment where the association relationship between multiple sets of first hash values, software identifiers, and SDK version identifiers is maintained in the SDK, the step of storing the first hash value in a trusted execution environment may include: obtaining the software identifier of the application software and the version identifier of the SDK; decrypting the ciphertext of the first hash value and storing the first hash value; and storing the association relationship between the first hash value, the software identifier of the application software, and the version identifier of the SDK.

[0052] Figure 2 is a schematic diagram of a verification method for the integrity of an SDK provided by the present disclosure. As shown in Figure 2, the SDK contains a ciphertext of the first hash value. The application software (specifically, the application module outside the SDK in the application software) sends an initialization request to the SDK. The SDK needs to perform an integrity check on itself. On the one hand, the SDK reads the ciphertext of the first hash value contained in itself, and on the other hand, reads the current information of the integrity-related file and calculates the second hash value. The SDK passes the first hash value, the second hash value, the software identification of the application software, and the version identification of the SDK to the trusted execution environment, and calls the trusted execution environment for comparison (comparing the first hash value with the second hash value). If it is the first time to initialize the integrity check involved in the SDK, then the trusted execution environment will also store the first hash value, as well as the relationship between the first hash value, the software identification of the application software, and the version identification of the SDK. The trusted execution environment feeds back the comparison result to the SDK. If the SDK determines that the comparison is consistent, it starts initialization. Based on Figure 2, if it is not the first time to initialize the integrity check involved, please refer to Figure 3.

[0053] In addition, in some embodiments, the SDK provider may specify a set of keys (including decryption keys and encryption keys) and pre-synchronize the decryption key to the trusted execution environment of the electronic device. The SDK provider may encrypt the first hash value of the specification information of the integrity-related files in the SDK using the encryption key. The step of storing the first hash value in the trusted execution environment may include: before the application software requests to initialize the SDK, the ciphertext of the first hash value may be obtained from the server of the SDK provider in advance in the online environment of the electronic device, the first hash value ciphertext may be passed to the trusted execution environment, the trusted execution environment may be called, the ciphertext of the first hash value may be decrypted and the first hash value may be stored. The above-mentioned step of storing the first hash value in the trusted execution environment may be executed by the application software.

[0054] It can be understood that in the above embodiment, the step of storing the first hash value in the trusted execution environment needs to rely on the online environment of the electronic device, while the integrity verification process performed when requesting to initialize the SDK still does not need to rely on the online environment of the electronic device.

[0055] Furthermore, in an embodiment where the association relationship between multiple sets of first hash values, software identifiers, and SDK version identifiers is maintained in the SDK, the step of storing the first hash value in a trusted execution environment may include: obtaining the software identifier of the application software and the version identifier of the SDK; decrypting the ciphertext of the first hash value and storing the first hash value; and storing the association relationship between the first hash value, the software identifier of the application software, and the version identifier of the SDK.

[0056] Figure 4 is a schematic diagram of the present disclosure providing a method for storing a first hash value based on an online environment of an electronic device. As shown in Figure 4, the application software (specifically, the application module outside the SDK in the application software) can request the SDK provider's server to obtain the ciphertext of the first hash value of the specification information of the SDK's integrity-related files before requesting to initialize the SDK. The SDK provider's server sends the ciphertext of the first hash value to the application software, and the application software passes the software identification of the application software, the version identification of the SDK, and the ciphertext of the first hash value to the trusted execution environment, calls the trusted execution environment to decrypt the ciphertext of the first hash value, and then the trusted execution environment stores the first hash value, as well as the association relationship between the first hash value, the software identification of the application software, and the version identification of the SDK.

[0057] Based on Figure 4, Figure 5 is a schematic diagram of another SDK integrity verification method provided by the present disclosure. As shown in Figure 5, the application software (specifically the application module outside the SDK in the application software) sends an initialization request to the SDK. The SDK needs to perform integrity verification on itself. The SDK reads the current information of the integrity-related files and calculates the second hash value. The SDK passes the first hash value, the second hash value, the software identifier of the application software, and the version identifier of the SDK to the trusted execution environment, and calls the trusted execution environment for comparison (first determine the first hash value associated with the software identifier and version identifier, and then determine the first hash value and the second hash value for comparison). The trusted execution environment feeds back the comparison results to the SDK. If the SDK determines that the comparison is consistent, it starts initialization.

[0058] In addition, an embodiment of this specification also provides a structural diagram of a device for verifying the integrity of an SDK, see Figure 6, the electronic device has a trusted execution environment, and the trusted execution environment stores a first hash value, the first hash value is the hash value of the specification information of the integrity-related files in the software development kit SDK, the application software on the electronic device has the SDK built-in, and the device includes: a reading module 601, which responds to the application software's request to initialize the SDK, reads the current information of the integrity-related files in the SDK, and calculates the hash value of the current information as a second hash value; a calling module 602, which calls the trusted execution environment and compares the first hash value with the second hash value; a determination module 603, which determines that the SDK integrity check has passed if the comparison is consistent.

[0059] The above-mentioned device embodiments correspond to the method embodiments. For detailed descriptions, please refer to the description of the method embodiments, which will not be repeated here. The device embodiments are obtained based on the corresponding method embodiments and have the same technical effects as the corresponding method embodiments. For detailed descriptions, please refer to the corresponding method embodiments.

[0060] The embodiments of this specification also provide a computer storage medium, which can store multiple instructions, and the instructions are suitable for being loaded by a processor to execute the method of the embodiments of this disclosure.

[0061] This specification also provides a computer program product, which stores at least one instruction. The at least one instruction is loaded by the processor and executes the method of the embodiment of the present disclosure.

[0062] The embodiments of this specification also provide a schematic diagram of the electronic device shown in Figure 7. As shown in Figure 7, at the hardware level, the electronic device includes a processor, an internal bus, a network interface, memory, and non-volatile storage, and may also include other necessary hardware. The processor reads the corresponding computer program from the non-volatile storage into the memory and then executes it to implement the above-mentioned voice activity detection method.

[0063] Of course, in addition to software implementation, this specification does not exclude other implementation methods, such as logic devices or a combination of software and hardware, etc. That is to say, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0064] In the 1990s, technological improvements could be clearly distinguished as either hardware improvements (for example, improvements to circuit structures like diodes, transistors, and switches) or software improvements (improvements to process flows). However, with the advancement of technology, many process flow improvements today can now be considered direct improvements to hardware circuit structures. Designers almost always create the corresponding hardware circuit structure by programming the improved process flow into the hardware circuit. Therefore, it cannot be said that a process flow improvement cannot be implemented using hardware modules. For example, a programmable logic device (PLD), such as a field programmable gate array (FPGA), is an integrated circuit whose logical function is determined by user programming. Designers can "integrate" a digital system on a PLD by programming it themselves, without having to hire a chip manufacturer to design and manufacture a dedicated integrated circuit chip. Moreover, nowadays, instead of manually fabricating integrated circuit chips, this programming is mostly done using "logic compiler" software. This is similar to the software compiler used when developing programs. Before compilation, the original code must also be written in a specific programming language, called a hardware description language (HDL). There is not just one HDL, but many, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc. The most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art will also understand that by simply programming the method flow in one of these hardware description languages ​​and then programming it into an integrated circuit, a hardware circuit that implements the logic method flow can be easily obtained.

[0065] The controller can be implemented in any suitable manner. For example, the controller can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320. The memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also know that in addition to implementing the controller in a purely computer-readable program code format, the controller can be implemented in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers by logically programming the method steps. Therefore, such a controller can be considered a hardware component, and the devices included therein for implementing various functions can also be considered as structures within the hardware component. Or even, the devices for implementing various functions can be considered as both software modules that implement the method and structures within the hardware component.

[0066] The systems, devices, modules, or units described in the above embodiments may be implemented by computer chips or entities, or by products having certain functions. A typical implementation device is a computer. Specifically, the computer may be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

[0067] For the convenience of description, the above devices are described as being divided into various units according to their functions. Of course, when implementing this specification, the functions of each unit can be implemented in the same or multiple software and / or hardware.

[0068] Those skilled in the art will appreciate that the embodiments of this specification may be provided as methods, systems, or computer program products. Therefore, this specification may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Furthermore, this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0069] This specification is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of this specification. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device produce a device for implementing the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0070] These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce a product including an instruction device that implements the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0071] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, so that the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0072] In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0073] Memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.

[0074] Computer-readable media includes permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. The information can be computer-readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory computer-readable media (transitory media), such as modulated data signals and carrier waves.

[0075] It should also be noted that the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, commodity, or apparatus that includes a series of elements includes not only those elements but also other elements not explicitly listed, or includes elements inherent to such process, method, commodity, or apparatus. In the absence of further limitations, an element defined by the phrase "comprises a ..." does not exclude the presence of other identical elements in the process, method, commodity, or apparatus that includes the element.

[0076] Those skilled in the art will appreciate that the embodiments of this specification may be provided as methods, systems, or computer program products. Thus, this specification may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Furthermore, this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0077] This specification may be described in the general context of computer-executable instructions, such as program modules, executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, and the like that perform specific tasks or implement specific abstract data types. This specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media, including storage devices.

[0078] The various embodiments in this specification are described in a progressive manner. Similar parts between the various embodiments can be referred to in conjunction with each other. Each embodiment focuses on the differences between the other embodiments. In particular, the system embodiments are generally similar to the method embodiments, so the description is relatively simple. For relevant parts, refer to the description of the method embodiments.

[0079] The foregoing is merely an example of the present invention and is not intended to limit the present invention. Various modifications and variations are possible for those skilled in the art. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of the present invention are intended to be included within the scope of the claims of the present invention.

Claims

1. A method for verifying the integrity of an SDK, wherein an electronic device has a trusted execution environment (TEE), wherein the TEE stores a first hash value, the first hash value being a hash value of specification information of integrity-related files within a software development kit (SDK), and wherein the SDK is built into application software on the electronic device, the method comprising: In response to the application software requesting to initialize the SDK, reading current information of integrity-related files in the SDK, and calculating a hash value of the current information as a second hash value; Invoking the trusted execution environment and comparing the first hash value with the second hash value; If the comparison is determined to be consistent, it is determined that the SDK integrity check has passed.

2. The method according to claim 1, wherein the trusted execution environment further stores an association relationship between the first hash value, the software identifier of the application software, and the version identifier of the SDK; Invoking the trusted execution environment and comparing the first hash value with the second hash value includes: The trusted execution environment is called to determine the first hash value associated with the software identifier and the version identifier, and the first hash value is compared with the second hash value.

3. The method of claim 1 , wherein the trusted execution environment stores a decryption key specified by an SDK provider, the SDK including a ciphertext of a first hash value, the ciphertext of the first hash value being encrypted using an encryption key corresponding to the decryption key; The step of storing the first hash value in the trusted execution environment comprises: In response to the application software's first request to initialize the SDK, the trusted execution environment is called, the ciphertext of the first hash value is decrypted, and the first hash value is stored.

4. The method of claim 1, wherein the trusted execution environment stores a decryption key specified by the SDK provider; The step of storing the first hash value in the trusted execution environment comprises: Before the application software requests to initialize the SDK, obtaining a ciphertext of the first hash value from a server of the SDK provider, where the ciphertext of the first hash value is obtained by encrypting the encryption key corresponding to the decryption key; The trusted execution environment is called, the ciphertext of the first hash value is decrypted, and the first hash value is stored.

5. The method of claim 4, wherein obtaining the ciphertext of the first hash value from the SDK provider's server comprises: The application software obtains the ciphertext of the first hash value from the service end of the SDK provider.

6. The method according to any one of claims 3 to 5, wherein calling the trusted execution environment, decrypting the ciphertext of the first hash value, and storing the first hash value comprises: Call the trusted execution environment and execute: Obtaining the software identification of the application software and the version identification of the SDK; Decrypt the ciphertext of the first hash value and store the first hash value; and store an association relationship between the first hash value, the software identifier of the application software, and the version identifier of the SDK.

7. The method of claim 1, further comprising: If it is determined that the SDK integrity check passes, the SDK is initialized.

8. The method according to any one of claims 1 to 4 and 7, wherein the method is applied to the SDK.

9. A device for verifying the integrity of a software development kit (SDK), wherein an electronic device has a trusted execution environment (TEE), wherein the TEE stores a first hash value, the first hash value being a hash value of specification information of integrity-related files within a software development kit (SDK), and wherein the SDK is built into application software on the electronic device, the device comprising: a reading module, configured to initialize the SDK in response to a request from the application software, read current information of integrity-related files in the SDK, and calculate a hash value of the current information as a second hash value; A calling module calls the trusted execution environment and compares the first hash value with the second hash value; The module is determined, and if the comparison is determined to be consistent, it is determined that the SDK integrity check has passed.

10. A storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 8 are implemented.

11. An electronic device, characterized in that: include: A processor and a memory; wherein the memory stores a computer program, and the computer program is suitable for being loaded by the processor and executing the steps of the method according to any one of claims 1 to 8.

12. A computer program product having at least one instruction stored thereon, characterized in that: When the at least one instruction is executed by the processor, the steps of the method according to any one of claims 1 to 8 are implemented.

Images