Password calling method and device based on interceptor, equipment, medium and program product

Abstract

The embodiment of the invention provides a password calling method and device based on an interceptor, equipment, a medium and a program product, and relates to the technical field of password calling management. The method comprises the following steps: determining an access source of a password function calling request in response to the password function calling request at an REE side; and allowing the password function calling request to execute access processing on the TEE side and returning a result under the condition that the access source is determined to meet the permission condition based on a preset permission rule table. According to the embodiment of the invention, the interceptor is added in the TEE to perform authority verification and request interception on the access source of the password function calling request, so that the password function calling security can be improved, and the maintenance convenience can be improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of password calling management, in particular to a password calling method and device based on an interceptor, equipment, a medium and a program product. BACKGROUND

[0002] Confidential Computing (CC) technology is a technology route based on underlying hardware security capabilities, and its basic idea is to achieve logical isolation effect based on TEE (Trusted Execution Environment) and cryptographic technology provided by hardware, and to realize the secure isolation of data and code used for calculation by constructing a closed and secure computing environment. In contrast to TEE, REE (Rich Execution Environment) is an open and vulnerable environment for running general operating systems and applications.

[0003] In order to ensure the security of data during processing, professional cryptographic modules are usually integrated in TEE, which provide comprehensive cryptographic services, including key generation and management, data encryption and decryption, digital signature creation and verification, etc. External applications on the REE side can call the cryptographic modules through related SDK interfaces to realize various cryptographic functions.

[0004] However, if the cryptographic modules in TEE provide traditional "data decryption, return decrypted result" type interfaces to the SDK on the REE side, the REE side may actively or be attacked to call such interfaces, and input specific ciphertext to receive decrypted plaintext, thereby infringing the data provider's rights and interests in data. If the TEE side only provides cryptographic functions of "decrypting and calculating and analyzing to return analysis results", it is necessary to customize special cryptographic modules according to different business scenarios, and the business scenarios will evolve over time and with demand in actual application, which requires frequent modification of cryptographic modules for business changes, resulting in complex and tedious management and maintenance.

[0005] In summary, a cryptographic function management scheme that takes into account data security and maintenance convenience is needed. SUMMARY

[0006] The purpose of the embodiments of the present application is to provide a password calling method, device, equipment, medium and program product based on an interceptor, so as to improve the security and maintenance convenience of cryptographic function management.

[0007] In a first aspect, the embodiments of the present application provide a password calling method based on an interceptor, applied to an interceptor in TEE, comprising: In response to the password function call request on the REE side, determine the access source of the password function call request; In a case where it is determined that the access source meets the permission condition based on the preset permission rule table, allow the password function call request to perform access processing on the TEE side and return a result.

[0008] In the embodiments of the present application, by adding an interceptor in the TEE, the access source of the password function call request is verified for permission and intercepted, so that the security of the password function call can be improved while the maintenance convenience is improved.

[0009] In some embodiments, the determining that the access source meets the permission condition based on the preset permission rule table comprises: performing at least one permission verification on the access source based on the preset permission rule table; wherein the permission verification comprises one or more of IP permission verification, interface permission verification, function permission verification, and key permission verification; In a case where it is determined that the access source successfully passes all permission verifications, it is determined that the access source meets the permission condition.

[0010] In the embodiments of the present application, the access source is verified by one or more verification processes such as IP verification and interface verification, and access is allowed only when all permission verifications are passed, so as to further improve the reliability of the permission verification.

[0011] In some embodiments, the performing at least one permission verification on the access source based on the preset permission rule table comprises: performing multiple permission verifications on the access source based on the preset permission rule table in a preset verification order; In a case where it is determined that the access source does not pass any one of the permission verifications, the password function call request is rejected.

[0012] In the embodiments of the present application, multiple permission verifications are performed in a specific verification order, so as to further improve the flexibility of the permission verification.

[0013] In some embodiments, the performing at least one permission verification on the access source based on the preset permission rule table comprises: In a case where it is determined that the IP of the access source matches an IP white list in the permission rule table, or it is determined that the IP of the access source does not match an IP black list in the permission rule table, it is determined that the access source successfully passes the IP permission verification.

[0014] In the embodiments of the present application, the access source is verified by matching based on the IP white list or the IP black list, so as to further improve the flexibility of the password call service configuration.

[0015] In some embodiments, the at least one permission verification on the access source based on the preset permission rule table comprises: obtaining a development tool interface type corresponding to the password function call request; In a case where it is determined that the development tool interface type matches an interface type white list in the permission rule table or that the development tool interface type does not match an interface type black list in the permission rule table, it is determined that the access source passes the interface permission verification successfully.

[0016] In the embodiments of the present application, the access source is verified based on the interface type white list or the interface type black list, so as to further improve the reliability of the permission call.

[0017] In some embodiments, the at least one permission verification on the access source based on the preset permission rule table comprises: obtaining a development tool interface identifier corresponding to the password function call request; wherein the development tool interface identifier is pre-allocated based on basic information of the development tool according to a preset identifier strategy; In a case where it is determined that the development tool interface identifier matches an interface identifier white list in the permission rule table or that the development tool interface identifier does not match an interface identifier black list in the permission rule table, it is determined that the access source passes the interface permission verification successfully.

[0018] In the embodiments of the present application, the access source is verified based on the interface identifier white list or the interface identifier black list, so as to further improve the reliability of the permission call.

[0019] In some embodiments, the at least one permission verification on the access source based on the preset permission rule table comprises: obtaining a target password function corresponding to the password function call request; In a case where it is determined that the target password function matches a function allowed call list in the permission rule table, it is determined that the access source passes the function permission verification successfully.

[0020] In the embodiments of the present application, the access source is verified based on the function allowed call list, so as to further improve the reliability of the permission call.

[0021] In some embodiments, the determining that the access source meets the permission condition based on the preset permission rule table comprises: obtain the basic information and the key information of the access source based on the password function call request, wherein the key information is pre-assigned based on the basic information of the access source according to a preset policy algorithm; determine the verification key information based on the basic information according to the policy algorithm; determine that the access source passes the key permission verification successfully in a case where the key information matches the verification key information.

[0022] In the embodiments of the present application, the access source is matched and verified based on the pre-assigned key information, thereby further improving the reliability of permission call.

[0023] In a second aspect, the embodiments of the present application provide an interceptor-based password calling device applied to an interceptor in a TEE, comprising: A request response module is configured to determine an access source of a password function call request in response to the password function call request on a REE side. A calling control module is configured to allow the password function call request to perform access processing on the TEE side and return a result in a case where the access source meets permission conditions based on a preset permission rule table.

[0024] In a third aspect, the embodiments of the present application provide an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the method of any of the embodiments of the first aspect when executing the program.

[0025] In a fourth aspect, the embodiments of the present application provide a computer readable storage medium, wherein the computer readable storage medium stores a computer program, and the computer program is executable on a processor to implement the method of any of the embodiments of the first aspect.

[0026] In a fifth aspect, the embodiments of the present application provide a computer program product, comprising a computer program, wherein the computer program is executable on a processor to implement the method of any of the embodiments of the first aspect. BRIEF DESCRIPTION OF DRAWINGS

[0027] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following will briefly introduce the drawings needed to be used in the embodiments of the present application. It should be understood that the following drawings only show some embodiments of the present application, and therefore should not be regarded as a limitation on the scope, and for those skilled in the art, other related drawings can also be obtained without creative labor on the basis of these drawings.

[0028] Figure 1A flowchart of a password calling method based on an interceptor provided by an embodiment of the present application is shown in the figure. Figure 2 An architecture diagram of a calling management system customized for a password module of the prior art is shown in the figure. Figure 3 An overall architecture diagram of a full-featured password module calling management provided by an embodiment of the present application is shown in the figure. Figure 4 A structure diagram of a password calling device based on an interceptor provided by an embodiment of the present application is shown in the figure. Figure 5 A structure diagram of an electronic device provided by an embodiment of the present application is shown in the figure. DETAILED DESCRIPTION

[0029] The technical solutions in the embodiments of the present application will be described below with reference to the accompanying drawings.

[0030] It should be noted that similar reference numerals and letters refer to similar items in the following drawings, and therefore, once an item is defined in one drawing, it need not be further defined and explained in subsequent drawings. Meanwhile, in the description of the present application, the terms “first”, “second”, etc. are only used for distinguishing description, and cannot be understood as indicating or implying relative importance.

[0031] It should be noted that in confidential computing, TEE and REE are two important concepts, representing different execution environments: TEE represents a trusted execution environment, which is an independent processing environment with computing and storage functions, capable of providing security and integrity protection; REE represents a rich execution environment, which is an open and vulnerable environment for running general operating systems and applications.

[0032] The core mission of the trusted execution environment is to ensure the security of data during processing. In order to achieve this high level of security protection, TEE usually integrates professional password modules, which provide comprehensive password services, including key generation and management, data encryption and decryption, digital signature creation and verification, etc.

[0033] Considering the unique needs of different application scenarios, existing technical solutions aim to customize embedded password modules, which run in the trusted execution environment. External applications on the REE side can call password functions through the SDK interface of the password module, and trusted applications (TA) in the TEE can also call password functions, as shown in the figure. Figure 2

[0034] ​In the above confidential computing application, there may be some security risks. For example, in a typical confidential computing scenario, an external application sends encrypted data to a cryptographic module through an SDK, hoping that the cryptographic module will decrypt the data and perform statistical analysis, data mining, and other calculations based on the decrypted data in a TEE environment, and finally output the analysis results. Since the TEE protects internal data from being accessed, probed, tampered with, deleted, and deleted by external parties through a series of measures, it can effectively protect data from being "available but invisible" throughout the computing process.

[0035] However, in this process, if the cryptographic module in the TEE provides a traditional interface such as "decrypt data and return decrypted results" to the SDK on its REE side, the REE side may actively or passively (be exploited by attacks) call such interfaces, and by inputting ciphertext, the REE side can receive the decrypted plaintext, so the REE side may see the data plaintext, thereby infringing the data provider's rights and interests in the data, and there is a certain security risk.

[0036] To solve the above problems, the current main approach is to set the cryptographic module to only provide a cryptographic function such as "decrypt and calculate analysis, return analysis results". However, due to the ever-changing business scenarios, if this method is used, a separate cryptographic module needs to be configured for each type of business, and moreover, businesses often evolve over time and with changing needs, and the corresponding cryptographic function requirements also need to change, which makes the management of cryptographic calls extremely complex.

[0037] To address the problems of the prior art described above, the embodiments of the present application provide a cryptographic call method based on an interceptor, which adds an interceptor on the TEE side to perform permission verification and request interception on the access source of a cryptographic function call request, so that only a full-featured cryptographic module needs to be provided to ensure the security of the cryptographic function call, while improving the convenience of cryptographic call maintenance and management.

[0038] As shown in Figure 1 The embodiments of the present application provide a cryptographic call method based on an interceptor, which is applied to an interceptor in a TEE, and can include the following steps: S1, in response to a cryptographic function call request from the REE side, determining the access source of the cryptographic function call request.

[0039] It should be noted that an interceptor is added on the TEE side, as shown in Figure 3 supports external definition of cryptographic function access control rules required by upper-layer businesses, forming a corresponding permission rule table, such as IP or interface white list, black list, and other permission verification functions.

[0040] It can be understood that the permission configuration table maintained by the interceptor is a list of access control rules of the cryptographic function, and an example of a permission configuration table for indicating whether different execution environment domains have the function calling permission can be shown in Table 1. The content in the table mainly stipulates which functions of the TEE cryptographic module are allowed to be called by the REE side SDK, and the specific functions can be flexibly configured by the upper business according to different scene characteristics. The administrator can manage these permission lists according to the security needs of itself, and the means include but are not limited to configuration files, web configuration interfaces, unified management, etc.

[0041] Table 1: Permission configuration table

[0042] The user can process various business logic through the upper application on the REE side, and in the process of processing the business, it can be necessary to call the cryptographic module on the TEE side to implement functions such as key generation and management, data encryption and decryption, digital signature creation and verification, etc.

[0043] When the upper application on the REE side needs to call the cryptographic module on the TEE side, a cryptographic function calling request is generated and transmitted to the TEE side. After the cryptographic function calling request enters the TEE side, it will first pass through the interceptor. The interceptor can obtain relevant information according to the currently received cryptographic function calling request, including the IP of the access source, the SDK (development tool) interface type, the type of cryptographic function to be called, etc.

[0044] S2, in the case where it is determined that the access source meets the permission condition based on the preset permission rule table, the cryptographic function calling request is allowed to perform access processing on the TEE side and return a result.

[0045] Then, the interceptor can perform permission verification based on the extracted relevant information according to the preset permission rule table. If it is confirmed that the permission verification is passed (meets the permission condition), the cryptographic function calling request on the REE side is allowed to perform access processing on the TEE side, such as calling the cryptographic module to generate a key, decrypt data, etc. and return the processing result to the corresponding access source on the REE side. If it is judged that the permission condition is not met, the cryptographic function calling request is rejected and an error is returned.

[0046] It should be noted that since the interceptor is designed to run in a trusted execution environment, it fully utilizes the hardware security isolation mechanism provided by the TEE to ensure the code security of the interceptor function module and prevent malicious software, attackers or other untrusted code from tampering or destroying it.

[0047] Based on this, by adding an interceptor in the TEE to perform permission verification and request interception on the access source of the cryptographic function call request, a full-featured cryptographic module is used without the need to customize the cryptographic module according to the business scenario, thereby improving the security of the cryptographic function call while improving the maintenance convenience.

[0048] In some embodiments, determining that the access source meets the permission condition based on the preset permission rule table comprises: performing at least one permission verification on the access source based on the preset permission rule table; wherein the permission verification comprises one or more of IP permission verification, interface permission verification, function permission verification, and key permission verification; In the case where it is determined that the access source successfully passes all permission verifications, it is determined that the access source meets the permission condition.

[0049] It should be noted that the permission rule table can include a rule sub-list corresponding to each permission verification to implement multiple verifications, safe and controllable calling of the full-featured cryptographic module. Each rule sub-list is used as a verification basis for IP permission verification, interface permission verification, function permission verification, and key permission verification.

[0050] Exemplarily, each permission verification can exist independently, or can be parallel or serial, and can be set according to business needs.

[0051] It should be noted that only in the case where all permission verification items pass, is the cryptographic function call request of the access source allowed to be accessed and processed on the TEE side, otherwise, if any one of the permission verifications fails, the cryptographic function call request of the access source is directly rejected.

[0052] Based on this, by performing one or more verification processes such as IP verification and interface verification on the access source, and only allowing access in the case where all permission verifications pass, the reliability of the permission verification is further improved.

[0053] In some embodiments, performing at least one permission verification on the access source based on the preset permission rule table comprises: performing multiple permission verifications on the access source based on the preset permission rule table in a preset verification order; In the case where it is determined that the access source does not pass any one of the permission verifications, the cryptographic function call request is rejected.

[0054] It should be noted that the verification order of the multiple permission verifications can be set according to needs, and when the cryptographic function call request is received, the multiple permission verifications are performed on the access source in the verification order.

[0055] Exemplarily, according to the business analysis, if it is determined that the IP does not match, the calling request is rejected. In this case, the verification order can be set as: the IP permission verification is performed first, and only when the IP permission verification is passed, other permission verifications are performed. If the IP permission verification is not passed, the calling request is directly rejected, so as to avoid unnecessary verification process and improve the overall verification efficiency.

[0056] It should be noted that, on the basis of performing permission verification according to the preset verification order, a verification mechanism of step-by-step mapping can also be configured. Exemplarily, assuming that the IP permission verification is performed first and then the interface permission verification is performed, different interface permission verification strategies (for example, different interface white lists / black and white lists) can be configured for different IP sets. Exemplarily, assuming that the interface permission verification is performed first, different IP permission verification strategies can be configured for different interface types.

[0057] It can be understood that, compared with the prior art scheme of using MAC as the verification basis, the scheme further improves the flexibility of verification by using IP to perform permission verification. Specifically, if the MAC identifier is used as the verification basis, when the user end encounters a fault or damage and needs to replace the device, the permission list needs to be reconfigured to pass the permission verification. If the IP verification scheme is used, even if the user replaces the device, the permission list does not need to be modified.

[0058] Therefore, by performing multiple permission verifications according to a specific verification order, the overall efficiency and flexibility of permission verification are further improved.

[0059] In some embodiments, at least one permission verification is performed on the access source based on the preset permission rule table, including: In a case where it is determined that the IP of the access source matches the IP white list in the permission rule table, or it is determined that the IP of the access source does not match the IP black list in the permission rule table, it is determined that the access source successfully passes the IP permission verification.

[0060] It should be noted that, in the permission rule table, the IP white list and / or the IP black list can be configured. If it is determined that the IP of the access source matches the IP white list, it is determined that the access source successfully passes the IP permission verification. If it is determined that the IP of the access source matches the IP black list, it is determined that the access source does not pass the IP permission verification.

[0061] Exemplarily, after an IP is added to the white list, the IP is no longer allowed to be added to the black list. If the IP is to be added to the black list, it is necessary to determine whether the IP is deleted from the white list, so as to prevent the white list matching logic and the black list matching logic from conflicting.

[0062] Based on this, the access source is matched and verified based on the IP white list or black list, thereby further improving the flexibility of the password calling service configuration.

[0063] In some embodiments, at least one permission verification is performed on the access source based on a preset permission rule table, including: Obtaining a development tool interface type corresponding to the password function calling request; In a case where it is determined that the development tool interface type matches an interface type white list in the permission rule table or that the development tool interface type does not match an interface type black list in the permission rule table, it is determined that the access source passes the interface permission verification.

[0064] It should be noted that, in the interface permission verification process, the development tool (Software Development Kit, SDK) interface applied by the access source is mainly verified.

[0065] Specifically, first, the development tool interface type corresponding to the current password function calling request is obtained, and then the development tool interface type is verified based on the interface type white list and / or the interface type black list in the permission rule table. If it is determined that the development tool interface type matches the interface type white list, it is determined that the access source passes the interface permission verification. If it is determined that the development tool interface type matches the interface type black list, it is determined that the access source does not pass the interface permission verification.

[0066] Similar to the IP permission verification, when a certain interface type is added to the white list, the interface type is no longer allowed to be added to the black list. If it is to be added to the black list, it is necessary to determine whether the interface type is deleted from the white list, so as to prevent the white list matching logic and the black list matching logic from conflicting. Therefore, if there are both a white list and a black list, when it is confirmed that the development tool interface type matches the interface type white list, it can be considered that the interface type does not exist in the black list. At this time, it is not necessary to perform permission verification based on the interface type black list, and it is directly determined that the access source passes the interface permission verification.

[0067] Based on this, the access source is matched and verified based on the interface type white list or black list, thereby further improving the reliability of the permission calling.

[0068] In some embodiments, at least one permission verification is performed on the access source based on a preset permission rule table, including: Obtaining a development tool interface type corresponding to the password function calling request; In a case where it is determined that the development tool interface identifier matches the interface identifier white list in the permission rule table or that the development tool interface identifier does not match the interface identifier black list in the permission rule table, it is determined that the access source passes the interface permission verification successfully.

[0069] It should be noted that in the interface permission verification process, the development tool interface identifier corresponding to the password function call request can also be obtained for verification.

[0070] Exemplarily, the interceptor can generate an identifier based on the basic information of the development tool transmitted by the user system (access source) when the user system first requests or registers, and identify the development tool, and the identifier is stored in the SDK side of the REE side. At the same time, the interceptor maintains the corresponding identifier white list or black list through the permission rule table.

[0071] In this way, when the REE side subsequently calls the SDK and generates a password function call request, the corresponding development tool interface identifier will be carried. The interceptor extracts the development tool interface identifier corresponding to the password function call request, and performs interface permission verification according to the interface identifier white list / interface identifier black list in the permission rule table.

[0072] Further, the assigned development tool interface identifier can also be associated and bound with the user end IP, which serves as the basis for joint permission verification, thereby avoiding the security problem of repeated use of the same SDK in multiple places.

[0073] Based on this, the access source is matched and verified based on the interface identifier white list or black list, thereby further improving the reliability of permission call.

[0074] In some embodiments, at least one permission verification is performed on the access source based on the preset permission rule table, including: Obtaining a target password function corresponding to the password function call request; In a case where it is determined that the target password function matches the function allowed call list in the permission rule table, it is determined that the access source passes the function permission verification successfully.

[0075] It should be noted that the password module is configured with a plurality of password functions, such as SM4 encryption function, SM4 decryption function, SM2 signature function, SM2 signature verification function, etc.

[0076] The REE side application specifies which cryptographic function (target cryptographic function) needs to be called this time when sending a cryptographic function call request each time, so that the interceptor can determine whether the target cryptographic function of the cryptographic module is allowed to be called by the REE side application according to the function allowed call list in the permission rule table. Specifically, if it is determined that the target cryptographic function matches the function allowed call list, it is determined that the access source passes the function permission verification.

[0077] Exemplarily, different function allowed call lists can be set according to different access source IPs or different SDK interfaces, to further improve the flexibility of function permission verification.

[0078] Based on this, by matching and verifying the access source based on the function allowed call list, any cryptographic module interface that is not expected to be exposed can be effectively blocked, further improving the reliability of permission call.

[0079] In some embodiments, determining that the access source meets the permission condition based on the preset permission rule table includes: obtaining the basic information and key information of the access source based on the cryptographic function call request; wherein the key information is pre-allocated based on the basic information of the access source according to a preset strategy algorithm; determining the verification key information based on the basic information according to the strategy algorithm; In the case where the key information matches the verification key information, it is determined that the access source successfully passes the key permission verification.

[0080] It should be noted that when the REE side user system is registered, the basic information of the user, such as the unit name, system name, and docking time, can be sent to the TEE side, and the interceptor can generate the corresponding username and / or secret key based on these information according to the preset strategy algorithm. For example, a hash value can be calculated based on the basic information and any n-bit value thereof can be taken as a username, and an 8n-bit secret key (which can include uppercase and lowercase letters, special characters, data, etc.) can be calculated using a national secret algorithm as the key information of the access source.

[0081] In this way, when the REE side subsequently sends a cryptographic function call request, the interceptor can extract the corresponding basic information therefrom and calculate the verification key based on the same algorithm, and verify it with the key information carried in the cryptographic function call request. If the two match, it is determined that the access source successfully passes the key permission verification.

[0082] Based on this, by further authenticating the access source based on the pre-allocated key information, the reliability of the cryptographic module call is further improved.

[0083] It should be noted that in some embodiments, different interface calling permissions can also be configured for different REE side SDKs according to different needs of the business system. For example, the interface name, SDK end secret key, and hsah value are generated and configured at the SDK end. When the business system calls the SDK, first, the SDK end of the REE is verified to confirm whether the business system has the permission to call the SDK, thereby further improving the reliability of the password calling management.

[0084] Reference is made to Figure 4 , Figure 4 A composition block diagram of an interceptor-based password calling apparatus provided by some embodiments of the present application is shown. It should be understood that the interceptor-based password calling apparatus corresponds to the above-mentioned method embodiments, and can perform each step involved in the above-mentioned method embodiments. The specific functions of the interceptor-based password calling apparatus can be referred to the description in the foregoing, and the detailed description is appropriately omitted here to avoid repetition. Figure 1

[0085] Figure 4 The interceptor-based password calling apparatus includes at least one software function module that can be stored in the memory in the form of software or firmware or solidified in the interceptor-based password calling apparatus. The interceptor-based password calling apparatus is applied to an interceptor in the TEE, and includes: The request response module 410 is configured to determine the access source of the password function calling request in response to the password function calling request of the REE side. The calling control module 420 is configured to allow the password function calling request to perform access processing at the TEE side and return a result in a case where the access source is determined to meet the permission condition based on the preset permission rule table.

[0086] It can be understood that the above-mentioned apparatus item embodiments correspond to the method item embodiments of the present application. The interceptor-based password calling apparatus provided by the embodiments of the present application can implement the interceptor-based password calling method provided by any one of the method item embodiments of the present application.

[0087] It can be clearly understood by those skilled in the art that, for the convenience and brevity of description, the specific working process of the apparatus described above can refer to the corresponding process in the foregoing method, and will not be described in more detail here.

[0088] As Figure 5 ​As shown, some embodiments of the present application provide an electronic device 500, comprising a memory 510, a processor 520, and a computer program stored in the memory 510 and capable of running on the processor 520, wherein the processor 520 reads the program from the memory 510 through the bus 530 and implements the method of any embodiment of the above-mentioned interceptor-based password calling method when executing the program.

[0089] The processor 520 can process digital signals and can include various computing structures. For example, a complex instruction set computer structure, a structure reduced instruction set computer structure, or a structure implementing a combination of multiple instruction sets. In some examples, the processor 520 can be a microprocessor.

[0090] The memory 510 can be used to store instructions executed by the processor 520 or data related to the execution process of the instructions. These instructions and / or data can include code for implementing some or all of the functions of one or more modules described in the embodiments of the present application. The processor 520 of the embodiments of the present disclosure can be used to execute the instructions in the memory 510 to implement the above-mentioned methods. The memory 510 includes dynamic random access memory, static random access memory, flash memory, optical memory, or other memory well known to those skilled in the art.

[0091] Some embodiments of the present application also provide a computer readable storage medium having a computer program stored thereon, which, when executed by a processor, performs the method described in the method embodiment.

[0092] Some embodiments of the present application also provide a computer program product, which, when executed on a computer, causes the computer to perform the method described in the method embodiment.

[0093] It should be noted that each of the embodiments in the present specification is described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same and similar parts of each embodiment can be referred to each other. For device embodiments, since they are basically similar to method embodiments, the description is relatively simple, and the relevant parts can be referred to the part of the method embodiment.

[0094] It should be understood that the disclosed apparatus and method can also be implemented in other ways. The apparatus embodiments described above are merely exemplary. For example, the flowcharts and block diagrams in the accompanying drawings illustrate the possible implementation architectures, functions and operations of the apparatus, method and computer program product according to the embodiments of the present application. In this regard, each block in the flowcharts or block diagrams can represent a module, a program segment or a part of code, which includes one or more executable instructions for implementing the specified logic function. It should also be noted that in some alternative implementations, the functions noted in the blocks can occur in a different order than that noted in the accompanying drawings. For example, two consecutive blocks can actually be executed substantially in parallel, and sometimes in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and the combination of blocks in the block diagrams and / or flowcharts, can be implemented by a dedicated hardware-based system for implementing the specified functions or actions, or can be implemented by a combination of dedicated hardware and computer instructions.

[0095] In addition, the functional modules in the various embodiments of the present application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0096] If the functions are implemented in the form of software function modules and sold or used as independent products, they can be stored in a computer readable storage medium. Based on this understanding, the technical solutions of the present application can be embodied in the form of a software product, and the computer software product is stored in a storage medium, and includes a number of instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present application. The aforementioned storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM, Read-Only Memory), a random access memory (RAM, Random Access Memory), a magnetic disk or an optical disk, and various program code storage media.

[0097] The above merely provides an example of the present application and is not intended to limit the protection scope of the present application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application. It should be noted that similar reference numerals and letters represent similar items in the following drawings, and thus, once an item is defined in one drawing, it need not be further defined and explained in subsequent drawings.

[0098] The above merely provides an example of the present application and is not intended to limit the protection scope of the present application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application. It should be noted that similar reference numerals and letters represent similar items in the following drawings, and thus, once an item is defined in one drawing, it need not be further defined and explained in subsequent drawings.

[0099] It should be noted that the relational terms herein such as first and second and the like are used solely to distinguish one from another entity or action without necessarily requiring or implying any actual relationship or order between such entities or actions. Moreover, the terms "comprises", "comprising", or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but can include other elements not expressly listed or inherent to such process, method, article, or apparatus. An element proceeded by "comprises... a" does not, without more constraints, exclude the existence of additional identical elements in the process, method, article, or apparatus that comprises the element.

Claims

1. A cryptographic invocation method based on interceptors, characterized in that, Interceptors used in TEE include: In response to a cryptographic function call request from the REE side, determine the access source of the cryptographic function call request; If the access source is determined to meet the permission conditions based on the preset permission rule table, the password function call request is allowed to perform access processing on the TEE side and return the result.

2. The interceptor-based cryptographic invocation method according to claim 1, characterized in that, The determination that the access source meets the permission conditions based on the preset permission rule table includes: The access source is subject to at least one permission verification based on a preset permission rule table; wherein the permission verification includes one or more of the following: IP permission verification, interface permission verification, function permission verification, and key permission verification. If the access source successfully passes all permission verifications, the access source is deemed to meet the permission requirements.

3. The interceptor-based cryptographic invocation method according to claim 2, characterized in that, The method of performing at least one permission verification on the access source based on a preset permission rule table includes: Multiple permission verifications are performed on the access source according to a preset verification order and based on a preset permission rule table. If it is determined that the access source has failed any of the permission verifications, the password function call request is rejected.

4. The interceptor-based cryptographic invocation method according to claim 2, characterized in that, The method of performing at least one permission verification on the access source based on a preset permission rule table includes: If the IP address of the access source matches the IP whitelist in the permission rules table, or if the IP address of the access source does not match the IP blacklist in the permission rules table, then the access source has successfully passed the IP permission verification.

5. The interceptor-based cryptographic invocation method according to claim 2, characterized in that, The method of performing at least one permission verification on the access source based on a preset permission rule table includes: Obtain the development tool interface type corresponding to the password function call request; If the development tool interface type is determined to match the interface type whitelist in the permission rule table, or if the development tool interface type is determined not to match the interface type blacklist in the permission rule table, then the access source is determined to have successfully passed the interface permission verification.

6. The interceptor-based cryptographic invocation method according to claim 2, characterized in that, The method of performing at least one permission verification on the access source based on a preset permission rule table includes: Obtain the development tool interface identifier corresponding to the password function call request; wherein, the development tool interface identifier is pre-assigned based on the basic information of the development tool according to a preset identifier strategy; If the development tool interface identifier matches the interface identifier whitelist in the permission rule table, or if the development tool interface identifier does not match the interface identifier blacklist in the permission rule table, then the access source has successfully passed the interface permission verification.

7. The interceptor-based cryptographic invocation method according to claim 2, characterized in that, The method of performing at least one permission verification on the access source based on a preset permission rule table includes: Obtain the target password function corresponding to the password function call request; If the target password function is determined to match the list of functions allowed to be called in the permission rules table, the access source is determined to have successfully passed the function permission verification.

8. The interceptor-based cryptographic invocation method according to claim 2, characterized in that, The determination that the access source meets the permission conditions based on the preset permission rule table includes: Based on the password function call request, the basic information and key information of the access source are obtained; wherein, the key information is pre-allocated based on the basic information of the access source according to a preset strategy algorithm; The verification key information is determined based on the basic information according to the described strategy algorithm; If the key information matches the verification key information, the access source is determined to have successfully passed the key permission verification.

9. A cryptographic invocation device based on an interceptor, characterized in that, Interceptors used in TEE include: The request-response module is used to respond to a cryptographic function call request from the REE side and determine the access source of the cryptographic function call request. The call control module is used to allow the password function call request to perform access processing on the TEE side and return the result when the access source is determined to meet the permission conditions based on a preset permission rule table.

10. An electronic device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, it can implement the interceptor-based cryptographic invocation method according to any one of claims 1-8.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the interceptor-based cryptographic invocation method as described in any one of claims 1-8.

12. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the interceptor-based cryptographic invocation method according to any one of claims 1-8.

Images